Re: [Ekiga-devel-list] fence-like levelmeter
Jan Schampera wrote: > Hi Devs, hi Jan, > > Damien asked me to do some ressearch on a widget that can give a "link > quality" status. Imagine it in the lower left corner, right next to the > status text of the main window. 1.) ergonomics analysis > > The animation is composed of the 5 states the widget can show 0-1-2-3-4. ok, every kid with a mobile knows and can read this symbol > I tried to get some color relation to the Ekiga logo (a darker orange > and a lighter one). mozilla does not show any brightness differences here. marketing priorities with technical meter ergonomics collision: every quality meter (like for tv-apps) must be light-green, or risk of user symbol misinterpretation/confusion (rising quality or error rate?). color steps from red over yellow to green (~<20% statistic median of lost packets or so) are more easy for users to report and communicate to the devs in case of problems. IMHO. On STUN problems the symbol should flash light red/yellow with f=2Hz. > > Technically the widget will take a level value between 0.0 and 1.0 and > will recalculate it internally, that way one can change the view (maybe > more bars) and doesn't need to change external calculation code. The > widget will be native 22px to 22px (icons). looks ok. > > Any comments about the optics so far? The widget code isn't ready yet. > > http://www.thebonsai.de/images/gtkfencemeter4_ani.gif > > > J. > y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] fence-like levelmeter
thomas schorpp wrote:
> Jan Schampera wrote:
>
>>Hi Devs,
>
>
> hi Jan,
>
>
>>Damien asked me to do some ressearch on a widget that can give a "link
>>quality" status. Imagine it in the lower left corner, right next to the
>>status text of the main window.
>
>
> 1.) ergonomics analysis
>
>
>>The animation is composed of the 5 states the widget can show 0-1-2-3-4.
>
>
> ok, every kid with a mobile knows and can read this symbol
>
>
>>I tried to get some color relation to the Ekiga logo (a darker orange
>>and a lighter one).
>
>
> mozilla does not show any brightness differences here.
>
> marketing priorities with technical meter ergonomics collision:
>
> every quality meter (like for tv-apps) must be light-green, or risk
> of user symbol misinterpretation/confusion (rising quality or error rate?).
> color steps from red over yellow to green (~<20% statistic median of lost
> packets or so)
> are more easy for users to report and communicate to the devs in case
> of problems. IMHO.
> On STUN problems the symbol should flash light red/yellow with f=2Hz.
>
>
>>Technically the widget will take a level value between 0.0 and 1.0 and
>>will recalculate it internally, that way one can change the view (maybe
>>more bars) and doesn't need to change external calculation code. The
>>widget will be native 22px to 22px (icons).
>
>
> looks ok.
>
>
>>Any comments about the optics so far? The widget code isn't ready yet.
2.) code:
gint
gtk_fencemeter4_get_index_by_level (gfloat level)
{
/* FIXME i need some arithmetics */
if (level == 0.0)
return 0;
if (level > 0.0 && level <= 0.25)
return 1;
> is float mandatory here? makes no sense since big
rounding steps.
>>
>>http://www.thebonsai.de/images/gtkfencemeter4_ani.gif
>>
>>
>>J.
>>
>
>
> y
> tom
>
> ___
> Ekiga-devel-list mailing list
> Ekiga-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
>
>
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] fence-like levelmeter
thomas schorpp wrote:
> thomas schorpp wrote:
>
>>Jan Schampera wrote:
>>
>>
>>>Hi Devs,
>>
>>
>>hi Jan,
>>
>>
>>
>>>Damien asked me to do some ressearch on a widget that can give a "link
>>>quality" status. Imagine it in the lower left corner, right next to the
>>>status text of the main window.
>>
>>
>>1.) ergonomics analysis
>>
>>
>>
>>>The animation is composed of the 5 states the widget can show 0-1-2-3-4.
>>
>>
>>ok, every kid with a mobile knows and can read this symbol
>>
>>
>>
>>>I tried to get some color relation to the Ekiga logo (a darker orange
>>>and a lighter one).
>>
>>
>>mozilla does not show any brightness differences here.
>>
>>marketing priorities with technical meter ergonomics collision:
>>
>>every quality meter (like for tv-apps) must be light-green, or risk
>>of user symbol misinterpretation/confusion (rising quality or error rate?).
>>color steps from red over yellow to green (~<20% statistic median of lost
>>packets or so)
>>are more easy for users to report and communicate to the devs in case
>>of problems. IMHO.
>>On STUN problems the symbol should flash light red/yellow with f=2Hz.
>>
>>
>>
>>>Technically the widget will take a level value between 0.0 and 1.0 and
>>>will recalculate it internally, that way one can change the view (maybe
>>>more bars) and doesn't need to change external calculation code. The
>>>widget will be native 22px to 22px (icons).
>>
>>
>>looks ok.
>>
>>
>>
>>>Any comments about the optics so far? The widget code isn't ready yet.
>
>
> 2.) code:
>
> gint
> gtk_fencemeter4_get_index_by_level (gfloat level)
> {
> /* FIXME i need some arithmetics */
no. possible iso-osi layer or OO-design violatiom.
gui layer classes dont do such work, belongs to core
layer or special functions class.
> if (level == 0.0)
> return 0;
>
> if (level > 0.0 && level <= 0.25)
> return 1;
>
>
>>is float mandatory here? makes no sense since big
>
> rounding steps.
>
>
>
>>>http://www.thebonsai.de/images/gtkfencemeter4_ani.gif
>>>
>>>
>>>J.
>>>
>>
>>
>>y
>>tom
>>
_
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] fence-like levelmeter
Jan Schampera wrote: > On Wed, 06 Sep 2006 10:26:00 +0200 > thomas schorpp <[EMAIL PROTECTED]> wrote: > > >>> /* FIXME i need some arithmetics */ >> >>no. possible iso-osi layer or OO-design violatiom. >>gui layer classes dont do such work, belongs to core >>layer or special functions class. > > > I don't think so, imagine such speed meter widgets, they take values > always between X and Y and recalculate internally to fit the currently > displayed design. It's similar here IMHO. It could have 10 bars and the > code that uses it will still put the same values in, the widget then > only has a higher "resolution" > > J. > hmm, yes, for the priority/statistic mixers output, but i think before this stage its more than just scaling ;) anyway. tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Wishes: remove flicker (50Hz) of video in Ekiga, increase resolution to 640x480, zoom function
hi vatbier, Damien Sandras wrote: > Le jeudi 07 septembre 2006 à 15:35 -0700, vatbier a écrit : > >>When I look in Ekiga at my own video of my webcam there is a flicker >>(maybe 50Hz?)? I find it annoying. report to the uvc driver developers devlist or just dont use flourescent lamps, a problem for every image sensor, even professional TV studio cameras, the cameras firmware should do that, besides. if youre in an office environment, complain to the electrician company who has build the office's flourescent lights without 3 phase shifting. a violation of electrical building assembling standards and therefore a warranty case. >>I haven't used yet Ekiga to my sister (she must first get a webcam >>too). then pls wait until Your setup is fully together, i dont like to comment on "hypothetics". >>Will my sister see this flicker or will the video that's been >>transmitted to her have no flicker? Will the H.261 QCIF Video Codec >>remove the flicker? there can be no flicker over home users net, because of low transfer framerate, pls try adjusting your vga cards vertical refresh frequency in XF86Config or trash a defective display or vga card. >>In WinXP my Logitech QuickCam Fusion software has an option to remove >>flicker (50Hz) from video. >> >>Hm, I see at http://en.wikipedia.org/wiki/Common_Intermediate_Format >>that QCIF has these video resolutions: >> QCIF: 176 × 144, QCIF+: 176 × 220 >>Does this mean that Ekiga can only send out a video with resolution >>176x220 ? My Logitech QuickCam Fusion webcam can do 640x480. > > > I don't know what's the flicker, but I think it is soemthing that should > be related to your driver. > > Currently, Ekiga can only do 176x144. In the next few weeks, thanks to > the hard work of Craig, it will also be able to do 352x288. > > >>Second Wish: a video codec that can send over 640x480 video >>resolutions. > > > I know no free codec that can do that with a reasonable bandwidth for > home users. h.264, there a free projects around but maybe not mature enough, yet, and U.S. patent issues. > > >>Third wish: a zoom function for video. Now in Ekiga my head is small >>compared to entire picture. > > > Go in the View menu, you can apply a 2x zoom on the picture. > > >>In WinXP with the webcam software I can adjust the zoom. I don't know >>whether this is digital zoom or a real mechanical function of the >>webcam's lens. >>Or should I ask this to the makers of uvcvideo video driver that they >>implement the zoom function of my Logitech webcam? >> no. user space program's work. and RTFM, zooming is already in ekiga. and stop comparing paid winXP and proprietary toys with linux sw, pls, we've other priorities than just copying window$ and proprietary software features. >>Fourth wish: add File Transfer function to Ekiga denied. IRC DCC, FTP, or SSH is sufficent for file transfer on UNIX/LINUX and more secure and stable, and open standards, get used to it. we dont need 10 messengers like msn or aim on linux around, the only reason for their existence is that window$ lacks standard internet capabillities and protocols and prefers proprietary protocols. we dont really need and support that messenger proprietary protocol chaos on linux, never. ... forseeable no budget for such luxury wishes, i think. if you want all that in pls donate at least 150 US$ to ekiga.org project as you payed license fees for winXP and the windows driver of the webcam, thx. ;) >> >>vatbier tom >> >>__ >>Do You Yahoo!? >>Tired of spam? Yahoo! Mail has the best spam protection around >>http://mail.yahoo.com *gnah* googlemail is much better :p ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Wish: video codec H.263 and H.264 for Ekiga
vatbier wrote: > I read that Ekiga uses video codec H.261 . > I want to be able to do video-conferencing from linux to WinXP. > Wengophone/WinXP uses video codec H.263 and mpeg4 I think. think again. and then implement it. show me code. > If Ekiga could use H.263 would I then be able to have a video-talk with > a user of Wengophone/WinXP? use wengophone, it is open source, no problems > > Ekiga for Windows seems to work but no fullscreen support. You get Ekiga for free with sources and want it "gold plated" too ??? > I hope next week my sister can use this to communicate with me. get Your sister ubuntu and delete her xo ;) > > Wengophone for Linux: latest release is very buggy, no video. thats untrue, just tested latest, great video. maybe u better learn some linux basics. > > vatbier > tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Weird video bandwidth
Jan Schampera wrote: > Hi. > > First of all, I can't reproduce this by will, unfortunately. > > Scenario: Disabled video support, called [EMAIL PROTECTED] > > Several times the displayed video bandwidth wasn't 0.0/0.0 as expected, > but something like 0.9/0.92 or a very large number exceeding the limits > of the status bar (10-15 digits?). > > As I can't reproduce it by will, this mail is just for the record. > > J. > hi, confirmed from 3 other people, have seen this a dozen of times for months, reproducable, check for correct member initialisation on video support off. didnt report due to some intermittance, but should be worth a bug record. y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Food for thought
Julien Puydt wrote: > Hi, > > I think he makes good points : > > http://www.lucas-nussbaum.net/blog/?p=210 > > since ekiga will have some IM capabilities in the future, we may want > to keep this in mind. > > Snark ___ > Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-devel-list > > http://www.lucas-nussbaum.net/blog/wp-comments-post.php Answer the question! :/ this guy should first fix his php. "Most IM clients have a big problem" No theyre the problem. The only reason for their existance is proprietary marketing and that ms windows lacks standard internet capabillities. Better train new linux users to use classic UNIX IM + filetransfer and develop and provide customer friendly OSS crosscompiled windows clients for standard communication protocols. We cant copy and do really need this proprietary IM's mess on linux. Thats the wrong target and will never work. y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] ekiga: libs incosistences or buggy sid libs installed
-att- Subject: ekiga: libs incosistences or buggy sid libs installed Followup-For: Bug #382331 Package: ekiga Version: 2.0.2-1 *** Please type your report below this line *** hi guys, its running fine here. cant reproduce. 1. maybe you need to downgrade some libg*'s for an intermediate solution until sid libs get more stable. see my setup below. 2. pls run gdb ekiga and identify the hanging lib/api calls in threads and reportbug libg* packages too, if unsure. let gdb catch the crash and enter "thread apply bt all". if no signal occurs and it hangs break in with ctrl-c. 3. maintainers pls get more in touch with the ekiga devs, we've a broken QA circle here leading to too loosen dependencies of distro packages. pls forward "distro bugs" upstream too from now on. we need to identify lib inconsistencies too. in agreement with the ekiga maintainer D.Sandras on #ekiga IRC. y tom -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (501, 'testing'), (101, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.18-1-k7 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages ekiga depends on: ii evolution-data-server1.0.4-1 evolution database backend server ii gconf2 2.14.0-1GNOME configuration database syste ii libart-2.0-2 2.3.17-1Library of functions for 2D graphi ii libatk1.0-0 1.12.1-1The ATK accessibility toolkit ii libaudiofile00.2.6-6 Open-source version of SGI's audio ii libavahi-client3 0.6.13-2Avahi client library ii libavahi-common3 0.6.10-1Avahi common library ii libavahi-glib1 0.6.13-2Avahi glib integration library ii libbonobo2-0 2.14.0-1Bonobo CORBA interfaces library ii libbonoboui2-0 2.14.0-2The Bonobo UI library ii libc62.3.6.ds1-4 GNU C Library: Shared libraries ii libcairo21.2.4-1 The Cairo 2D vector graphics libra ii libebook1.2-51.6.2-3 Client library for evolution addre ii libedataserver1.2-7 1.6.2-3 Utility library for evolution data ii libesd0 0.2.35-2Enlightened Sound Daemon - Shared ii libfontconfig1 2.3.1-2 generic font configuration library ii libgcc1 1:4.1.1-13 GCC support library ii libgconf2-4 2.14.0-1GNOME configuration database syste ii libglib2.0-0 2.10.1-2The GLib library of C routines ii libgnome-keyring00.4.9-1 GNOME keyring services library ii libgnome2-0 2.14.1-2The GNOME 2 library - runtime file ii libgnomecanvas2-02.14.0-2A powerful object-oriented display ii libgnomeui-0 2.14.1-1The GNOME 2 libraries (User Interf ii libgnomevfs2-0 2.14.0-2GNOME virtual file-system (runtime ii libgtk2.0-0 2.8.13-1The GTK+ graphical user interface ii libice6 6.8.2.dfsg.1-7 Inter-Client Exchange library ii libopal-2.2.02.2.2.dfsg-1Open Phone Abstraction Library - s ii liborbit21:2.12.4-1 libraries for ORBit2 - a CORBA ORB ii libpango1.0-01.12.3-1Layout and rendering of internatio ii libpopt0 1.10-2 lib for parsing cmdline parameters ii libpt-1.10.0 1.10.1.dfsg-1 Portable Windows Library ii libpt-plugins-alsa 1.10.1.dfsg-1 Portable Windows Library Audio Plu ii libpt-plugins-v4l1.10.1.dfsg-1 Portable Windows Library Video Plu ii libpt-plugins-v4l2 1.10.1.dfsg-1 Portable Windows Library Video Plu ii libsdl1.2debian 1.2.10-3Simple DirectMedia Layer ii libsm6 6.8.2.dfsg.1-7 X Window System Session Management ii libstdc++6 4.1.1-13The GNU Standard C++ Library v3 ii libx11-6 6.8.2.dfsg.1-7 X Window System protocol client li ii libxcursor1 1.1.3-1 X cursor management library ii libxext6 6.8.2.dfsg.1-7 X Window System miscellaneous exte ii libxfixes3 6.8.2.dfsg.1-11 X Window System miscellaneous 'fix ii libxi6 6.8.2.dfsg.1-7 X Window System Input extension li ii libxinerama1 6.8.2.dfsg.1-7 X Window System multi-head display ii libxml2 2.6.26.dfsg-1 GNOME XML library ii libxrandr2 6.8.2.dfsg.1-7 X Window System Resize, Rotate and ii libxrender1 1:0.9.0.2-1 X Rendering Extension client libra ii yelp 2.6.5-1 Help browser for GNOME 2 ii zlib1g 1:1.2.3-9 compression library - runtime -- no debconf information ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gno
Re: [Ekiga-devel-list] Status of http://snapshots.seconix.com
Kilian Krause wrote: > Hi Damien, > > Am Sonntag, den 17.09.2006, 18:11 +0200 schrieb Damien Sandras: > >>Can you make a public announcement about the current status of the >>builds at http://snapshots.seconix.com ? >> >>(Debian, Sources, Fedora, ...) > > > short summary: we're back online with fresh Debian and Ubuntu snaps! ;) > > patches at me is herewith warmly asked to do so(*). Logs for Sarge build > problems would be along [2] and can be found in the log database for checking for intltool >= 0.33.0... ./configure: line 1: ./intltool-update.in: No such file or directory ./configure: line 1: ./intltool-update.in: No such file or directory ./configure: line 2262: test: : integer expression expected found. Your intltool is too old. You need intltool 0.33.0 or later. make: *** [config.status] Error 1 ** Build finished at 20061007-1430 FAILED [dpkg-buildpackage died] Purging chroot-i386_voip-snapshots-debian-sarge//build/buildd///ekiga-cvs-20061007-02 i know this. whether package-config is broken or we need the links in the source packages. what to do? provide links? and reportbug intltool-debian < intltool on sarge? y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Blacklisting
Jan Schampera wrote: > Hi, > > I just saw a (IMHO) good idea: > Filtering incoming calls by a SIP-address blacklist. > > Comments? > > J. > huhu :) where did You say that ? unexpectable user effort to control as soon as telemarketers and other idiots get on sip. lets torture them not us. whitelist or greylist somehow or other modern filter practice, pls. y tom happy x-mas. ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Blacklisting
Jan Schampera wrote: > Hi, > > I just saw a (IMHO) good idea: > Filtering incoming calls by a SIP-address blacklist. > > Comments? > > J. > *gargl* where did You see that ? unacceptable user effort to control as soon as telemarketers and other idiots get on sip. lets torture them not us. whitelist or greylist somehow or other modern filter practice, pls. y tom happy x-mas. ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Crash on Ekiga Startup [latest]
Craig Southeren wrote: > On Wed, 31 Jan 2007 05:32:52 +0100 > Jan Schampera <[EMAIL PROTECTED]> wrote: > > >>Hi! >> >>Yesterday evening I updated PWLib and OPAL to the latest CVS version >>(PWLib got a commit "Fixed warning on Linux" since then - doesn't sound >>critical). >> >>Ekiga crashes on startup while initializing the H323 EP. >> >>A gdb backtrace is attached. > > > Nothing useful in the backtrace unfortauntely :( > > Is there any chance of running a debug version and seeing if you can get > somethng more useful? > > Note that I running other applications based on OPAL CVS HEAD without > any problems. > >Craig > hi guys, pulled heads 2h ago. not confirmed. cant reproduce. [EMAIL PROTECTED]:/usr/local/src/ekiga$ svn up At revision 4837. pwlib builds with some warnings about incomplete code, but ekiga trunk head works (except for incoming calls from 2.0.3), no such Jan's issue: libpt_linux_x86_d.so.1.11.3 => /usr/lib/libpt_linux_x86_d.so.1.11.3 (0xb6fee000) libopal_linux_x86_d.so.2.3 => /usr/lib/libopal_linux_x86_d.so.2.3 (0xb645b000) @craig: --enable-exceptions configure switch *disables* c++ exceptions -> -fnoexceptions Program exited normally. (gdb) 09:22:05 Started Ekiga 2.1.0 for user schorpp 09:22:17 Set STUN server to stun.sipgate.net (Port Restricted NAT) 09:22:17 Registered to ekiga.net 09:22:17 Registered to sipgate.de 09:22:17 Registered to sip1.sipdiscount.com 09:23:44 Remote user has stopped calling 09:25:55 Calling sip:[EMAIL PROTECTED] 09:25:55 Remote user rejected the call 09:26:30 Calling sip:[EMAIL PROTECTED] 09:26:31 Remote user rejected the call 09:27:33 Calling sip:[EMAIL PROTECTED] 09:27:45 Opened VIA 8237 for recording with plugin ALSA 09:27:45 Opened codec Speex for transmission 09:27:45 Opened VIA 8237 for playing with plugin ALSA 09:27:45 Opened codec Speex for reception 09:27:45 Opening video device StaticPicture with plugin Picture 09:27:45 Successfully opened video device StaticPicture, channel 0 09:27:45 Opened codec h261 for transmission 09:27:45 Opened codec h261 for reception 09:27:45 Connected with schorpp using 09:28:05 Closed codec Speex which was opened for transmission 09:28:05 Closed codec Speex which was opened for reception 09:28:05 Closed codec h261 which was opened for transmission 09:28:06 Closed codec h261 which was opened for reception 09:28:06 Remote user cleared the call 09:29:05 Remote user has stopped calling 09:29:44 Remote user has stopped calling (incoming from tom2, no incoming call notification pops up???) y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Incoming calls not detected [latest]
for the missing incoming call notification (auto answer doesnt work, too): ekiga 2.0.3 caller: 09:54:55 Calling sip:[EMAIL PROTECTED] 09:57:55 Could not connect to remote host 09:58:28 Calling sip:[EMAIL PROTECTED] 09:58:28 Remote user rejected the call 09:58:51 Calling sip:[EMAIL PROTECTED] 10:00:18 Could not connect to remote host ekiga trunk svn head: 10:43:46 Remote user has stopped calling thats all. [EMAIL PROTECTED]:~$ ping tom1 PING tom1.schorpp.dyndns.dk (192.168.0.100) 56(84) bytes of data. 64 bytes from tom1.schorpp.dyndns.dk (192.168.0.100): icmp_seq=1 ttl=63 time=0.645 ms 64 bytes from tom1.schorpp.dyndns.dk (192.168.0.100): icmp_seq=2 ttl=63 time=1.22 ms 64 bytes from tom1.schorpp.dyndns.dk (192.168.0.100): icmp_seq=3 ttl=63 time=0.692 ms --- tom1.schorpp.dyndns.dk ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2001ms rtt min/avg/max/mdev = 0.645/0.852/1.221/0.263 ms [EMAIL PROTECTED]:~$ network ok. this is the (recoverable from) state on incoming call: Program received signal SIGINT, Interrupt. [Switching to Thread -1248110912 (LWP 25900)] 0xb7f4f410 in ?? () (gdb) thread apply all bt Thread 18 (Thread -1271768144 (LWP 26257)): #0 0xb7f4f410 in ?? () #1 0xb4325388 in ?? () #2 0x in ?? () Thread 17 (Thread -1269904464 (LWP 26256)): #0 0xb7f4f410 in ?? () #1 0xb44ebc58 in ?? () #2 0x08650090 in ?? () #3 0x08650628 in ?? () #4 0xb6268f41 in select () from /lib/tls/i686/cmov/libc.so.6 #5 0xb728278d in PSocket::Select ([EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) at socket.cxx:613 #6 0xb72a897d in PSocket::Select ([EMAIL PROTECTED], [EMAIL PROTECTED]) at ../common/sockets.cxx:1687 #7 0xb6809854 in OpalTransportUDP::Read (this=0x86735c8, buffer=0x8674898, length=65535) at /usr/local/src/opal/src/opal/transports.cxx:2018 #8 0xb728ca66 in PChannelStreamBuffer::underflow (this=0x8674048) at ../common/pchannel.cxx:210 #9 0xb72894c0 in PChannelStreamBuffer::seekoff (this=0x8674048, off=0, dir=std::_S_cur) at ../common/pchannel.cxx:254 #10 0xb639000a in std::basic_streambuf >::pubseekoff () from /usr/lib/libstdc++.so.6 #11 0xb6d2bfac in SIP_PDU::Read (this=0x8694f08, [EMAIL PROTECTED]) at /usr/local/src/opal/src/sip/sippdu.cxx:1814 #12 0xb6d0525b in SIPEndPoint::HandlePDU (this=0x845a8b0, [EMAIL PROTECTED]) at /usr/local/src/opal/src/sip/sipep.cxx:942 #13 0xb6cfec7a in SIPEndPoint::TransportThreadMain (this=0x845a8b0, param=140981704) at /usr/local/src/opal/src/sip/sipep.cxx:827 #14 0xb6d0ba91 in SIPEndPoint::TransportThreadMain_PNotifier::Call ( this=0x8694ba0, [EMAIL PROTECTED], extra=140981704) ---Type to continue, or q to quit--- at /usr/local/src/opal/include/sip/sipep.h:1104 #15 0xb72b374a in PSimpleThread::Main (this=0x8694a68) at ../common/osutils.cxx:2297 #16 0xb72991d1 in PThread::PX_ThreadStart (arg=0x8694a68) at tlibthrd.cxx:1341 #17 0xb641d240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #18 0xb627029e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 16 (Thread -1271501904 (LWP 26021)): #0 0xb7f4f410 in ?? () #1 0xb4365a78 in ?? () #2 0x085bf5b8 in ?? () #3 0x085bfcb0 in ?? () #4 0xb6268f41 in select () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7298be8 in PThread::PXBlockOnIO (this=0x85bb2c8, handle=63, type=0, [EMAIL PROTECTED]) at tlibthrd.cxx:1432 #6 0xb72884dc in PChannel::PXSetIOBlock (this=0x8595b80, type=PChannel::PXReadBlock, [EMAIL PROTECTED]) at channel.cxx:242 #7 0xb7281fba in PSocket::os_recvfrom (this=0x8595b80, buf=0x859aa20, len=65535, flags=0, addr=0xb4365ba8, addrlen=0xb4365c28) at socket.cxx:835 #8 0xb72a97a6 in PIPDatagramSocket::ReadFrom (this=0x8595b80, buf=0x859aa20, len=65535, [EMAIL PROTECTED], [EMAIL PROTECTED]) at ../common/sockets.cxx:2848 #9 0xb72a9852 in PUDPSocket::Read (this=0x8595b80, buf=0x859aa20, len=65535) at ../common/sockets.cxx:3192 #10 0xb728a0c9 in PIndirectChannel::Read (this=0x8595fc0, buf=0x859aa20, len=65535) at ../common/pchannel.cxx:825 #11 0xb6809b07 in OpalTransportUDP::Read (this=0x8595fc0, buffer=0x859aa20, length=65535) at /usr/local/src/opal/src/opal/transports.cxx:2041 #12 0xb728ca66 in PChannelStreamBuffer::underflow (this=0x8596568) at ../common/pchannel.cxx:210 #13 0xb72894c0 in PChannelStreamBuffer::seekoff (this=0x8596568, off=0, dir=std::_S_cur) at ../common/pchannel.cxx:254 #14 0xb639000a in std::basic_streambuf >::pubseekof---Type to continue, or q to quit--- f () from /usr/lib/libstdc++.so.6 #15 0xb6d2bfac in SIP_PDU::Read (this=0x849baf8, [EMAIL PROTECTED]) at /usr/local/src/opal/src/sip/sippdu.cxx:1814 #16 0xb6d0525b in SIPEndPoint::HandlePDU (this=0x845a8b0, [EMAIL PROTECTED]) at /usr/local/src/opal/src/sip/sipep.cxx:942 #17 0xb6cfec7a in SIPEndPoint::TransportThreadMain (this=0x845a8b0, param=140074944) at /usr/local/src/opal/src/sip/sipep.cxx:827 #18 0xb6d0ba91 in SIPEndPoint::TransportThreadMain_PNotifi
Re: [Ekiga-devel-list] Crash on Ekiga Startup [latest]
Craig Southeren wrote: > On Wed, 31 Jan 2007 09:44:25 +0100 > thomas schorpp <[EMAIL PROTECTED]> wrote: > > ..deleted > > >>pulled heads 2h ago. not confirmed. cant reproduce. >> >>[EMAIL PROTECTED]:/usr/local/src/ekiga$ svn up >>At revision 4837. >> >>pwlib builds with some warnings about incomplete code, > > > Can you send me a copy of the warnings? missing braces, incomplete case switches... that sort of. see Your snapshot build logs, I forgot to log and warnings show only up once as You know. > > >>but ekiga trunk head works (except for incoming calls >>from 2.0.3), > > > I'd like to fix this problem. Not sure how, though. simpleopal is > definitely working, as are other programs. I believe You, no need to repeat. > Craig > y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Incoming calls not detected [latest]
Craig Southeren wrote: > On Wed, 31 Jan 2007 10:53:52 +0100 > thomas schorpp <[EMAIL PROTECTED]> wrote: > > >>for the missing incoming call notification (auto answer doesnt work, too): >> >>ekiga 2.0.3 caller: >> >>09:54:55 Calling sip:[EMAIL PROTECTED] >>09:57:55 Could not connect to remote host >>09:58:28 Calling sip:[EMAIL PROTECTED] >>09:58:28 Remote user rejected the call >>09:58:51 Calling sip:[EMAIL PROTECTED] >>10:00:18 Could not connect to remote host > > > A level 4 trace log would be much more useful :) > >Craig coming up... I think both should be useful ;) y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Incoming calls not detected [latest]
thomas schorpp wrote: Craig Southeren wrote: On Wed, 31 Jan 2007 10:53:52 +0100 thomas schorpp <[EMAIL PROTECTED]> wrote: for the missing incoming call notification (auto answer doesnt work, too): ekiga 2.0.3 caller: 09:54:55 Calling sip:[EMAIL PROTECTED] 09:57:55 Could not connect to remote host 09:58:28 Calling sip:[EMAIL PROTECTED] 09:58:28 Remote user rejected the call 09:58:51 Calling sip:[EMAIL PROTECTED] 10:00:18 Could not connect to remote host A level 4 trace log would be much more useful :) Craig coming up... I think both should be useful ;) 2.0.3 peer to 2.1.0-svn peer: 11:39:26 Calling sip:[EMAIL PROTECTED] 11:39:26 Remote user rejected the call 11:40:17 Calling sip:[EMAIL PROTECTED] 11:40:22 Remote user rejected the call 11:41:19 Calling sip:[EMAIL PROTECTED] 11:41:19 Remote user rejected the call 11:42:01 Calling sip:[EMAIL PROTECTED] 11:42:01 Remote user rejected the call - d4 log attached- y tom log.tar.bz2 Description: application/bzip ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Incoming calls not detected [latest]
Craig Southeren wrote: > On Wed, 31 Jan 2007 11:49:25 +0100 > thomas schorpp <[EMAIL PROTECTED]> wrote: > > ..deleted > > >>11:42:01 Remote user rejected the call >> >> >>- d4 log attached- > > > Thanks for this. I can now be fairly sure the problem is related to changes > in the way that OnIncomingConnection is now handled. > > I've been trying to make the code backwards compaibnle, but it looks > like that is not going to work. Once we have Ekiga working again, I will > be modify OPAL to ensure that code will fail to compile, rather than > breaking silently. > > Looking at Ekiga, I can see one change that will need to be made. > > in manager.cpp, near line 909, the following code: > > case 0: > res = OpalManager::OnIncomingConnection (connection); > break; > > > should be changed to > > case 0: > res = OpalManager::OnIncomingConnection (connection, 0, NULL); > break; > > if you can try this, let me know if it makes a difference > > Craig well, at least no more immediate call rejects, but I still cant take the call: 12:27:09 Started Ekiga 2.1.0 for user schorpp 12:27:20 Set STUN server to stun.sipgate.net (Port Restricted NAT) 12:28:29 Remote user has stopped calling 12:29:31 Remote user has stopped calling 12:29:51 Calling sip:[EMAIL PROTECTED] 12:30:03 Opened VIA 8237 for recording with plugin ALSA 12:30:03 Opened codec Speex for transmission 12:30:03 Opened VIA 8237 for playing with plugin ALSA 12:30:03 Opened codec Speex for reception 12:30:03 Opening video device StaticPicture with plugin Picture 12:30:03 Successfully opened video device StaticPicture, channel 0 12:30:03 Opened codec h261 for transmission 12:30:03 Opened codec h261 for reception 12:30:03 Connected with schorpp using 12:30:15 Closed codec Speex which was opened for transmission 12:30:15 Closed codec Speex which was opened for reception 12:30:15 Closed codec h261 which was opened for transmission 12:30:16 Closed codec h261 which was opened for reception 12:30:16 Remote user cleared the call 12:31:12 Remote user has stopped calling 12:35:25 Remote user has stopped calling ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Incoming calls not detected [latest]
Andre Kirchner wrote:
> Hi,
>
> I came up with a fix for this problem. Don't merge
> this patch into the cvs stream yet because it might
> break something else, and could be much cleaner (I
> think).
> But test it and let me know if you have any problem.
>
> Andre
>
>
>
>
>
> --- ./build_01/ekiga/src/endpoints/manager.h 2006-11-05 05:27:45.0
> -0800
> +++ ./build/ekiga/src/endpoints/manager.h 2007-02-01 16:01:46.0
> -0800
> @@ -247,6 +247,11 @@
> * OnShowIncoming will be called on the PCSS Endpoint.
> * PRE : /
> */
> +
> + BOOL OnIncomingConnection(OpalConnection &,
> +unsigned,
> +OpalConnection::StringOptions *);
> +
ok, but cast to OpalConnection::StringOptions* or get() calls needed on
endpoint.xxx in sip.cpp and h323.cpp,
got it compiled with reinterpret_cast( but this
will surely fail at runtime
if forwarding set.
but calls can be answered now ;)
06:46:07 Started Ekiga 2.1.0 for user schorpp
06:46:18 Set STUN server to stun.sipgate.net (Port Restricted NAT)
06:46:36 Call from tom2 schorpp
06:46:47 Opened VIA 8237 for recording with plugin ALSA
06:46:47 Opened codec Speex for transmission
06:46:48 Opened VIA 8237 for playing with plugin ALSA
06:46:48 Opened codec PCMA for reception
06:46:48 Opening video device StaticPicture with plugin Picture
06:46:48 Successfully opened video device StaticPicture, channel 0
06:46:48 Opened codec h261 for transmission
06:46:48 Opened codec h261 for reception
06:46:48 Connected with tom2 schorpp using Ekiga2.0.3
06:47:54 Closed codec Speex which was opened for transmission
06:47:54 Closed codec PCMA which was opened for reception
06:47:54 Closed codec h261 which was opened for transmission
06:47:55 Closed codec h261 which was opened for reception
06:47:55 Local user cleared the call
with:
default:
case 0:
res = OpalManager::OnIncomingConnection (connection, 0, NULL);
break;
}
case 2:
-connection.ForwardCall (extra);
case 2:
+connection.ForwardCall ((const char *) extra);
wont surely work, too, just a compile override, we need data from the Call
class maybe.
>BOOL OnIncomingConnection (OpalConnection &,
>int,
>PString);
>
>
delete, no more used by the callback callers.
>
>
> --- ./build_01/ekiga/src/endpoints/manager.cpp2007-02-01
> 16:04:18.0 -0800
> +++ ./build/ekiga/src/endpoints/manager.cpp 2007-02-01 16:10:21.0
> -0800
> @@ -837,6 +837,16 @@
>}
> }
>
> +BOOL
> +GMManager::OnIncomingConnection (OpalConnection &connection,
> + unsigned reason,
> + OpalConnection::StringOptions * extra)
> +{
> +//PString tmp("");
> +//return OnIncomingConnection(connection, reason, tmp);
> +
> + return OnIncomingConnection(connection, reason, PString(NULL));
> +}
>
> BOOL
> GMManager::OnIncomingConnection (OpalConnection &connection,
> @@ -892,6 +902,7 @@
> break;
>
>case 2:
> +
> connection.ForwardCall (extra);
> res = FALSE;
> short_reason = g_strdup (_("Forwarding incoming call"));
> @@ -899,6 +910,7 @@
>g_strdup_printf (_("Forwarding incoming call from %s to %s"),
> utf8_name, (const char *) extra);
> break;
> +
>
>case 4:
> res = TRUE;
> @@ -907,7 +919,17 @@
> (const char *) utf8_name);
>default:
>case 0:
> -res = OpalManager::OnIncomingConnection (connection);
> +OpalCall & call = connection.GetCall();
> +
> +// See if we already have a B-Party in the call. If not, make one.
> +if (call.GetOtherPartyConnection(connection) != NULL){
> + res = TRUE;
> + break;
> +}
> +else
> + // Use a routing algorithm to figure out who the B-Party is, then make
> a connection
> + res = MakeConnection(call, OnRouteConnection(connection), NULL, 0,
> NULL);
> +
> break;
>}
>
i dont think this is needed, just adapt arguments to using the new
StringOptions type and get()
the PString(?) then pass to subsequent calls (which are still taking native
const char* type args),
I cant find the definition by now.
y
tom
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] HELP !!! (Was Re: [VALVE] Ubuntu Edgy)
hi PPL, hi Jan, hi staff, Damien Sandras wrote: > Hi, > > Le mercredi 07 février 2007 à 06:35 +0100, Jan Schampera a écrit : > >>Folks, >> >>http://bugzilla.gnome.org/show_bug.cgi?id=400590 >>http://bugzilla.gnome.org/show_bug.cgi?id=401351 >>http://bugzilla.gnome.org/show_bug.cgi?id=404157 >>http://bugzilla.gnome.org/show_bug.cgi?id=404612 >>http://bugzilla.gnome.org/show_bug.cgi?id=405193 >> >>(and masses of similar stuff I didn't find yet, plus masses of similar >>stuff from other programs than Ekiga) Just blaming Ubuntu Maintainers (QA/Configuration Managers) for bugs does not help here and brings in frustration, Jan, take it as feedback for incomplete CM advise from the Ekiga Project-Management (Sorry, Damien, but I will reason below) and incomplete outsourcing QA-Cycle, and communication failure. In Free Software Projects Practice in Linux, QA is outsourced to distro maintainers, but QM can never be, the PPL is in charge. I've reported such process weaknesses before on this list and IRC, but it got simply ignored. > > > We would really need a few persons interested in Ekiga, and who could > take in charge the role of triaging bugs. Just hiring a testing department is depreciated SW process practice and will not cure the showing up management weaknesses. Keep that outsourced to the distro maintainers and their users. Taking it from them by force would be a violation of current OSS practice we must respect and would lead to more and unsolvable communication problems and possibly complete breakdown of the QA-Cycle and thus, a chaos project. According to modern SW lifecycle process audits results in ISO 15504 and SEI-CMMI, and the SPR Institute's publications, books from german senior PMM practioneers, the failures here do not mainly come from development and CM or users(testers), > > We sometimes receive interesting bug reports, often not. Invite the outsourced QA (distro maintainers) to *documented* weekly online meetings and provide a guideline for such a classification and CM advise from the ekiga devs and self-assessment, maintainers have insufficent input otherwise, maybe You, Damien, want to publish Your complete Project Management ways and habits and reasoned decisions for external audit, so the distro maintainers get enough information for CM and QA, they should be professional enough, again, no reason to blame ubuntu maintainers, here, ekiga teams fault alone. not doing so just copies proprietary companies management practices. they could do much more forward error correction then, and reason their own QA/CM project management processes better and give reasoned feedback upstream, what is what You like to have, isnt it? > > I am loosing much time triaging them. > I am loosing much time trying to reproduce them. > I am loosing much time trying to get information from users to reproduce > the problem. Devs know their library dependencies and other CM well and should provide them *tightly* to the distro maintainers, this has not been done restrictive and full enough in the past. Focus on process too, not only on the product. Again, most Bugs are *traditionally* coming from management failures, pls do a self-assesment of Your practice and decisions and what could follow them. Just think the chain back to the top and dont forget the risk-management before having the dev team moving forward to fast, first fix the bugs, then move forward to new designs, other would be proprietary business practice always releasing buggy software and then selling hotfixes, therere much books out about this for SW PMM. Papers and easy guidelines are also availlable from esi.es and sei.cmu.edu, spr.com maybe, until now I found only proprietary self-assessment/QM software tools (my fault, Ive had enough time to implement some, but as You know I'm a very slow coder, and there was real *no* interest from OSS managers, i've failed for acceptance to introduce such practices on qa.debian.org years before, free projects cant be controlled the classic industry QM way and I am no senior QM or process consultant myself and missing a PHD title for the needed acceptance). You do not need to read all of it, therere quick guidelines books for PMM practioneers available from Your local university library. First address the communication issues to get control back and publish Your management details if You want assessment help, I could translate and format Your output according to ISO 15504 and other standards and best practice and map to PMM-Practice checklists. Get some good books of practice from senior SW-PMM practioneers for communication basics in this science, if Youre not mature enough in this. > > Most of the time, people send me privately -d 4 outputs. I am forced to > ignore them. give reporting guidelines in the README of packages. provide another contact address with autoreply service delegating to the correct reporting places, proprieta
Re: [Ekiga-devel-list] MPEG 4 and H.264 need to help
Uy Vu Phan wrote: > Hi all, > > I have source code of ekiga, but I need to know the some of files where is > implemented the MPEG4 and H.264 mechanism in ekiga system. Because we would > like to understand MPEG4 and H.264 to implement the our own MPEG4 > components. > > Thanks for your support. > VuPhan 1. learn english 2. learn opensource sw usage, licenses and contribution practice, c/c++ programming 3. state organisation and full and clear purpose, state "Your" project 4. no support for [EMAIL PROTECTED] ,"nix" = german language ;) , no support for proprietary code thefts. ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] GSoC co-mentors for theora codec support
Julien Puydt wrote: > Ralph Giles a écrit : >> We have a student who wants to add support for the royalty-free theora >> video codec to ekiga as a Google Summer of Code project. We can act as >> primary mentors for this, based on general free software experience, and >> of course specific knowledge about the the codec and its implementation, >> but we fear the student won't get far without some help from someone who >> understands the ekiga code, and can offer support for getting the >> implementation accepted upstream. if reasonable assessment of Your student shows that he could get mature enough to do even a full codec project for opal, the remaining risk for acceptance in Ekiga could be easily eliminated if Your student starts first with learning OSS inter-project communications and other project management practices from You, acceptance is maintained, then. so pls let him present himself here and on the openh323.org devlist, maybe IRC (we don't bite). besides of that, Your Student should present why exactly his product would satisfy Ekiga's and Opal's needs at first, i cannot find any critics of Your technical and global concepts on Your website, and, since we're on SIP nowadays, interoperability is first questioned. >> >> Are any of the ekiga developers interested in acting as a co-mentor (or >> primary mentor) for this project? What's your general opinion on the >> project idea? i don't know any mentor in industry who *really* has time for his/her students, but luckily, in OSS there're many devs around in great teams which can help out, to concentrate on just 1 mentor is not OSS way and brings the danger that the other devs could feel no more responsible for *our* student ;) in OSS he is always free to start and get acceptance just for "showing code", teach him change management -friendly and forward- quality- managing practices so he can't run into frustrating impedance mismatches or other problems. it's not just coding alone. very good idea and surely warm welcomed contribution. > > It looks like a good idea ; however I don't know much about this part of > opal's code yet (the codec support is in opal, not directly in ekiga). me too, codecs are very advanced stuff. > > I'll probably still be able to lend a hand (notice I'm not registered as > an official google mentor yet this year). i would, second, that and surely most others. > > Snark y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] [PATCH]Ekigas svn /opal cvs heads, minor API changes
still no linking...
lopal -ldl -lpthread /usr/lib/libesd.so /usr/lib/libaudiofile.so -lm
/usr/lib/libopal.so: undefined reference to `PPipeChannel::PPipeChannel()'
/usr/lib/libopal.so: undefined reference to `PPipeChannel::Execute()'
/usr/lib/libopal.so: undefined reference to `PPipeChannel::Close()'
/usr/lib/libopal.so: undefined reference to `PPipeChannel::IsRunning() const'
/usr/lib/libopal.so: undefined reference to `PPipeChannel::Open(PString const&,
PPipeChannel::OpenMode, int, int)'
/usr/lib/libopal.so: undefined reference to `PPipeChannel::~PPipeChannel()'
collect2: ld returned 1 exit status
--- src/endpoints/pcss.h2007-04-04 15:06:11.0 +0200
+++ src/endpoints/pcss.h2007-04-04 15:06:39.0 +0200
@@ -75,7 +75,7 @@
*Display a popup if required.
* PRE : /
*/
- virtual void OnShowIncoming (const OpalPCSSConnection &connection);
+ virtual BOOL OnShowIncoming (const OpalPCSSConnection &connection);
/* DESCRIPTION : This callback is called when there is an
--- src/endpoints/pcss.cpp 2007-04-04 15:16:44.0 +0200
+++ src/endpoints/pcss.cpp 2007-04-04 15:21:43.0 +0200
@@ -89,14 +89,14 @@
}
-void GMPCSSEndpoint::OnShowIncoming (const OpalPCSSConnection & connection)
+BOOL GMPCSSEndpoint::OnShowIncoming (const OpalPCSSConnection & connection)
{
IncomingCallMode icm = AUTO_ANSWER;
GtkWidget *statusicon = NULL;
guint interval = 2000;
if (endpoint.GetCallingState() != GMManager::Called)
-return;
+return FALSE;
statusicon = GnomeMeeting::Process ()->GetStatusicon ();
@@ -113,7 +113,7 @@
if (icm == AUTO_ANSWER) {
AcceptCurrentIncomingCall ();
-return;
+return FALSE;
}
/* The timers */
@@ -122,6 +122,8 @@
gnomemeeting_threads_enter ();
gm_statusicon_ring (statusicon, interval);
gnomemeeting_threads_leave ();
+
+ return TRUE;
}
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Ekiga INVITE requests are rejected by OpenIMS P-CSCF
Mikhanov Sergey wrote: >Hello, > > > > I am testing the functionality of Fraunhofer Fokus OpenIMS core network > with different SIP phones and found out strange behavior of Ekiga, which > could be considered as a possible bug. > > > > It would be nice if Ekiga developers could pay some attention to this > issue. > > > > Regards, > > Sergey Mikhanov. > > > > The information contained in this e-mail message is privileged and > confidential and is for the exclusive use of the addressee. The person > who receives this message and who is not the addressee, one of his > employees or an agent entitled to hand it over to the addressee, is > informed that he may not use, disclose or reproduce the contents thereof. > hi, pls have this mail footer removed, or You could get ignored. inacceptable contribution terms for a OSS Project Mailinglist. besides, such footers are pure nonsense ideas from some unqualified IT-lawyers and consultants without any lawful subject. and pls state employee and company information as usual for company personnel on OSS lists. thx y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Ekiga INVITE requests are rejected by OpenIMS P-CSCF
thomas schorpp wrote: > Mikhanov Sergey wrote: >>Hello, >> >> >> >> I am testing the functionality of Fraunhofer Fokus OpenIMS core network >> with different SIP phones and found out strange behavior of Ekiga, which >> could be considered as a possible bug. >> > >> >> >> It would be nice if Ekiga developers could pay some attention to this >> issue. >> >> >> >> Regards, >> >> Sergey Mikhanov. >> >> >> >> The information contained in this e-mail message is privileged and >> confidential and is for the exclusive use of the addressee. The person >> who receives this message and who is not the addressee, one of his >> employees or an agent entitled to hand it over to the addressee, is >> informed that he may not use, disclose or reproduce the contents thereof. >> > > hi, > > pls have this mail footer removed, or You could get ignored. > inacceptable contribution terms for a OSS Project Mailinglist. > besides, such footers are pure nonsense ideas from some unqualified > IT-lawyers > and consultants without any lawful subject. > > and pls state employee and company information as usual for company > personnel on OSS lists. > > thx > > y > tom > ___ > Ekiga-devel-list mailing list > Ekiga-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-devel-list > + GPL violations due to illegal license constructs and non-GPL restrictions for "OpenIMS" from Fraunhofer Fokus Institute: http://www.openimscore.org/#license 1. no full text copy of GPL V2 on website, possibly intended to confuse users for the further conditions: 2. restriction for non-commercial use - illegal under GPL V2, license author confuses "free" with "non-commercial" 3. restriction for "software patents" - illegal under GPL V2 guys, dont touch this until Fraunhofer Fokus gets this right. y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [info] Re: Ekiga INVITE requests are rejected by OpenIMS P-CSCF
le. > > 3. Again, I do not understand what you imply by "restriction for > "software patents"". There is no restriction there, other than the GPLv2 > one. see above. > > Best Regards, > Dragos Vingarzan > Peter Weik Anyway, it is not to me to rule You about Your business. This has been just analysis and critics in the hope it will be helpful and reflect my personal opinions, You're free to ask FSF for more comprehensive advise. I'm surely not the first to question, too, many businesses fear so called "GPL Issues". Best Regards, Thomas Schorpp > > > thomas schorpp wrote: >> + GPL violations due to illegal license constructs and non-GPL >> restrictions for "OpenIMS" from Fraunhofer Fokus Institute: >> >> http://www.openimscore.org/#license >> >> 1. no full text copy of GPL V2 on website, possibly intended to >> confuse users for the further conditions: >> 2. restriction for non-commercial use - illegal under GPL V2, license >> author confuses "free" with "non-commercial" >> 3. restriction for "software patents" - illegal under GPL V2 >> >> guys, dont touch this until Fraunhofer Fokus gets this right. >> >> y >> tom > ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Ekiga-windows sound fails and is replaced by brp brp brp sound
Dieter Rogiest wrote: > I installed ekiga-setup-2.0.9-BETA.exe on the WinXP computer of my sister. from where? > On my Mandriva Linux 2007.1 computer I built ekiga_2.0.9. this says nothing, RTFnoobMs on how to report issues. we need info from Your distro's package management system about versions of the installed libs, if not self-build. > > my second bug with ekiga-windows-2.0.9: > After about 10 minutes calling with my sister the sound fails and is replaced > by an annoying brp brp brp sound. I closed the call and I called her again. > Then after 3 minutes the sound fails again. Again I closed the call and > recalled. And again the sound fails after 4 minutes or something and we can > only hear the brp brp brp sound. > > This bug is for me a showstopper for doing successful video-conferencing > between ekiga-linux and ekiga-windows. > I hope you can solve this. Not with this much bla-bla and this less systems info. Explain type and configuration of Your network. RTFM+wiki and try other codecs first. BTW, theres a Bugzilla bugtracking-system, with helpful forms for people who dont know bug-reporting, this is a dev list. We don't know what "Skype" is. > > Dieter tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Ekiga-windows echo cancellation doesn't work
Dieter Rogiest wrote: > I installed ekiga-setup-2.0.9-BETA.exe on the WinXP computer of my sister. > On my Mandriva Linux 2007.1 computer I built ekiga_2.0.9. > useless systems info the 4th time. > my fourth bug with ekiga-windows-2.0.9 and/or ekiga-linux: > The sound is ok except for the fact that the echo cancellation doesn't work > both with me and my sister. cant technically never work using ekiga with 2 sound devices for play and record (usb mic) due to missing sampling timer reference. > I can lower the output of my speakers but then I'm barely able to understand > the voice of my sister. use headsets. > Skype-Linux to Skype-Windows has better echo cancellation. I don't give a shit. > But I was able to have a conversation with my sister using Ekiga, the echo > cancellation not working is for the moment not a big deal to me. > We were using the SPEEX codec. try others and report. > > Also about the video: the video resolution (both sent by Ekiga-linux and by > Ekiga-windows) is lower than that of Skype-Windows. I read that higher > resolutions will be available for Ekiga in the future. listen, Skype is high-minuterates PAYED proprietary software you cant reference here. > > I'm happy with the fact that Ekiga has progressed since the last time I used > it. it has worked fine for years. > I will probably mostly use Ekiga to contact family who have WinXP on > their computer. So I hope that you developers can squash these bugs out of > ekiga-windows. NEED *real systems* INFO > > Dieter > > ___ > Ekiga-devel-list mailing list > Ekiga-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-devel-list > tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Issues and crash with new opal/pwlib sockets code
hi.
outgoing calls fail here always with loop detected since ~3days following opal+pwlibs cvs heads,
see attachment.
on incoming call segfault happens (codec PCMA, G711a; local CallWeaver PBX):
(gdb) bt full
#0 0x2ad0f92d4b73 in OpalConnection::OpenSourceMediaStream (this=0xe2b910,
[EMAIL PROTECTED], sessionID=1) at
/usr/local/src/opal/src/opal/connection.cxx:929
safeLock = {safeObject = @0xe2b910, locked = 1}
stream = (class OpalMediaStream *) 0x4
sourceFormat = { = { = { = {> =
{ = { = { = {_vptr.PObject = 0x761230}, reference = 0x76d360},
elementSize = 1, theArray = 0x76d380 "PCM-16",
allocatedDynamically = 1}, }, }, }, }, rtpPayloadType = RTP_DataFrame::MaxPayloadType,
rtpEncodingName = { = {> = { =
{ = { = {_vptr.PObject = 0x2ad0f8d21970}, reference = 0x76d100}, elementSize = 1,
theArray = 0x76d960 "",
allocatedDynamically = 1}, }, }, },
defaultSessionID = 1, media_format_mutex = { = { = {
_vptr.PObject = 0x2ad0f8d1a750}, }, mutex = {__data =
{__lock = 0,
__count = 0, __owner = 0, __nusers = 0, __kind = 1, __spins = 0, __list
= {__prev = 0x0,
__next = 0x0}}, __size = '\0' , "\001", '\0' ,
__align = 0}},
options = { = { = { = {
= {
_vptr.PObject = 0x50f4d0}, reference = 0xe20320}, },
info = 0xd5ac20}, }, codecBaseTime = 0}
destinationFormat = { = { = { = {>
= { = { = { = {_vptr.PObject = 0x761230},
reference = 0x76f140}, elementSize = 1, theArray = 0x76f1d0
"G.711-ALaw-64k",
allocatedDynamically = 1}, }, }, }, }, rtpPayloadType = RTP_DataFrame::PCMA,
rtpEncodingName = { = {> = { =
{ = { = {_vptr.PObject = 0x2ad0f8d21970}, reference = 0x76f180}, elementSize = 1,
theArray = 0x76f5b0 "PCMA",
allocatedDynamically = 1}, }, }, },
defaultSessionID = 1, media_format_mutex = { = { = {
_vptr.PObject = 0x2ad0f8d1a750}, }, mutex = {__data =
{__lock = 0,
---Type to continue, or q to quit---
__count = 0, __owner = 0, __nusers = 0, __kind = 1, __spins = 0, __list
= {__prev = 0x0,
__next = 0x0}}, __size = '\0' , "\001", '\0' ,
__align = 0}},
options = { = { = { = {
= {
_vptr.PObject = 0x50f4d0}, reference = 0xea6d00}, },
info = 0xe20380}, }, codecBaseTime = 0}
#1 0x2ad0f9319d49 in OpalPCSSConnection::OpenSourceMediaStream
(this=0xe2b910,
[EMAIL PROTECTED], sessionID=1) at /usr/local/src/opal/src/opal/pcss.cxx:573
No locals.
#2 0x2ad0f92dc4e9 in OpalCall::OpenSourceMediaStreams (this=0xe63cf0,
[EMAIL PROTECTED],
[EMAIL PROTECTED], sessionID=1) at /usr/local/src/opal/src/opal/call.cxx:585
conn = { = { = {_vptr.PObject = 0x50e550},
collection = 0xe63fe8,
currentObject = 0xe2b910, lockMode = PSafeReadOnly}, }
startedOne = 0
adjustableMediaFormats = {> = { = { =
{ = { = {_vptr.PObject = 0x517fd0}, reference = 0xd5aba0}, },
info = 0xe29c10}, }, }
#3 0x2ad0f96a9f8f in SIPConnection::OnOpenSourceMediaStreams
(this=0xe640f0,
[EMAIL PROTECTED], sessionId=1, localMedia=0xea6a80)
at /usr/local/src/opal/src/sip/sipcon.cxx:1600
reverseStreamsFailed = 1
otherList = {> = { = { =
{ = { = {_vptr.PObject = 0x40a073e0}, reference = 0xe64800}, },
info = 0x140a073e0}, }, }
#4 0x2ad0f96aa828 in SIPConnection::OnSendSDPMediaDescription
(this=0xe640f0,
[EMAIL PROTECTED], rtpMediaType=SDPMediaDescription::Audio, rtpSessionId=1,
[EMAIL PROTECTED])
at /usr/local/src/opal/src/sip/sipcon.cxx:1566
hasNSE = 0
i = 8
reverseStreamsFailed = 1
sdpMediaList = (
const SDPMediaFormatList &) @0xd86f88: { = { = { =
{ to continue, or q to quit---
bject> = {_vptr.PObject = 0x2ad0f9b38810}, reference = 0xce0560}, },
info = 0xcdc240}, }
hasTelephoneEvent = 1
localAddress = { = { = {> = {
= { = { = {_vptr.PObject = 0x2ad0f9ac4d30}, reference = 0x7fe630}, elementSize = 1,
theArray = 0xea79f0 "udp$192.168.0.100:5000",
allocatedDynamically = 1}, }, }, },
transport = 0xcf7540}
ip =
port = 13020
rtpSession = (class RTP_UDP *) 0x7ff200
incomingMedia = (class SDPMediaDescription *) 0xd86ef0
localMedia = (class SDPMediaDescription *) 0xea6a80
mediaAddress = { = { = {> = {
= { = { = {_vptr.PObject = 0x2ad0f9ac4d30}, reference = 0xd87300}, elementSize = 1,
theArray = 0xd59000 "tcp$192.168.0.1:13020",
allocatedDynamically = 1}, }, }, },
transport = 0xcf73d0}
#5 0x2ad0f96a9d82 in SIPConnection::ConstructSDP (this=0xe640f0, [EMAIL
PROTECTED])
at /usr/local/src/opal/src/sip/sipcon.cxx:1325
sdpFailure = 1
#6 0x2ad0f96aaf8f in SIPConnection::SetConnected (this=0xe640f0)
at /usr/local/src/opal/src/sip/sipcon.cxx:1413
safeLock = {safeObject = @0xe640f0, locked = 1}
sdpOut = { = {_vptr.PObject = 0x2ad0f9b38690},
mediaDescriptions = { = { = { =
{ = {
_vptr.PObject = 0x2ad0f9b376b0}
Re: [Ekiga-devel-list] Issues and crash with new opal/pwlib sockets code
Damien Sandras wrote: > Hi, > > > Can you post a -d 4 output ? > > Le jeudi 16 août 2007 à 09:49 +0200, thomas schorpp a écrit : >> hi. >> >> outgoing calls fail here always with loop detected since ~3days following >> opal+pwlibs cvs heads, >> see attachment. -^ y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Issues and crash with new opal/pwlib sockets code
Damien Sandras wrote: > Hi, > > > Can you post a -d 4 output ? > > Le jeudi 16 août 2007 à 09:49 +0200, thomas schorpp a écrit : >> hi. >> >> outgoing calls fail here always with loop detected since ~3days following >> opal+pwlibs cvs heads, cannot see reason here, will try to set brakepoint in gdb and tracing whats wrong: looks like ekiga tries to use the wan if of my router instead of the local machines ip to create socket conn, this must fail: 2007/08/16 12:25:38.679 0:45.594 GMURLHandl...r:00ddcab0 OpalMan Set up call from pc:* to sip:[EMAIL PROTECTED] 2007/08/16 12:25:38.680 0:45.595 GMURLHandl...r:00ddcab0 CallCreated Call[1] 2007/08/16 12:25:38.680 0:45.595 GMURLHandl...r:00ddcab0 OpalMan Set up connection to "pc:*" 2007/08/16 12:25:38.681 0:45.596 GMURLHandl...r:00ddcab0 OpalCon Created connection Call[1]-EP[VIA 8237] 2007/08/16 12:25:38.682 0:45.597 GMURLHandl...r:00ddcab0 RFC2833 Handler created 2007/08/16 12:25:38.688 0:45.603 GMURLHandl...r:00ddcab0 RFC2833 Handler created 2007/08/16 12:25:38.688 0:45.603 GMURLHandl...r:00ddcab0 Silence Handler created 2007/08/16 12:25:38.688 0:45.603 GMURLHandl...r:00ddcab0 Echo Canceler Handler created 2007/08/16 12:25:38.688 0:45.603 GMURLHandl...r:00ddcab0 PCSSCreated PC sound system connection with token 'VIA 8237' 2007/08/16 12:25:38.689 0:45.604 GMURLHandl...r:00ddcab0 OpalMan On incoming connection Call[1]-EP[VIA 8237] 2007/08/16 12:25:38.689 0:45.604 GMURLHandl...r:00ddcab0 Call GetOtherPartyConnection Call[1]-EP[VIA 8237] 2007/08/16 12:25:38.689 0:45.604 GMURLHandl...r:00ddcab0 OpalMan Set up connection to "sip:[EMAIL PROTECTED]" 2007/08/16 12:25:38.689 0:45.604 GMURLHandl...r:00ddcab0 OpalCon Created connection Call[1]-EP[EMAIL PROTECTED] 2007/08/16 12:25:38.689 0:45.604 GMURLHandl...r:00ddcab0 RFC2833 Handler created 2007/08/16 12:25:38.689 0:45.604 GMURLHandl...r:00ddcab0 RFC2833 Handler created 2007/08/16 12:25:38.691 0:45.606 GMURLHandl...r:00ddcab0 SIP Created connection. 2007/08/16 12:25:38.692 0:45.607 GMURLHandl...r:00ddcab0 PCSS Outgoing call routed to sip:[EMAIL PROTECTED] for Call[1]-EP[VIA 8237] 2007/08/16 12:25:38.692 0:45.607 GMURLHandl...r:00ddcab0 CallOnSetUp Call[1]-EP[VIA 8237] 2007/08/16 12:25:38.692 0:45.607 GMURLHandl...r:00ddcab0 SIP SetUpConnection: 2007/08/16 12:25:38.693 0:45.608 GMURLHandl...r:00ddcab0 OpalUDP Binding to interface: 192.168.0.100:5063 2007/08/16 12:25:38.693 0:45.608 GMURLHandl...r:00ddcab0 SIP Created transport 2007/08/16 12:25:38.6930:45.608 GMURLHandl...r:00ddcab0 PWLib File handle high water mark set: 46 PUDPSocket udp$86.64.162.35:5060 2007/08/16 12:25:38.693 0:45.608 GMURLHandl...r:00ddcab0 OpalUDP Started connect to 86.64.162.35:5060 2007/08/16 12:25:38.699 0:45.614 GMURLHandl...r:00ddcab0 SIP Transaction 1 INVITE created. 2007/08/16 12:25:38.728 0:45.643 GMURLHandl...r:00ddcab0 Call GetMediaFormats for Call[1]-EP[EMAIL PROTECTED] H.261 H.261-CIF H.261-QCIF theora G.711-uLaw-64k G.711-ALaw-64k GSM-06.10 PCM-16 PCM-16-16kHz YUV420P RFC4175_YUV420P RGB32 RGB24 RFC4175_RGB24 2007/08/16 12:25:38.728 0:45.643 GMURLHandl...r:00ddcab0 Call CanDoMediaBypass Call[1]-EP[EMAIL PROTECTED] session 1 2007/08/16 12:25:38.728 0:45.643 GMURLHandl...r:00ddcab0 OpalMan IsMediaBypassPossible: session 1 2007/08/16 12:25:38.728 0:45.643 GMURLHandl...r:00ddcab0 OpalCon IsMediaBypassPossible: default returns FALSE 2007/08/16 12:25:38.729 0:45.644 GMURLHandl...r:00ddcab0 RTP_UDP RTP session created with NAT flag set to 0 2007/08/16 12:25:38.738 0:45.653 GMURLHandl...r:00ddcab0 PWLib File handle high water mark set: 47 PUDPSocket 2007/08/16 12:25:38.739 0:45.654 GMURLHandl...r:00ddcab0 PWLib File handle high water mark set: 48 PUDPSocket 2007/08/16 12:25:38.739 0:45.654 GMURLHandl...r:00ddcab0 PWLib File handle high water mark set: 49 PUDPSocket 2007/08/16 12:25:38.798 0:45.713 GMURLHandl...r:00ddcab0 RTP_UDP Session 1 created: 91.89.4.107:5002-5003 ssrc=2045251631 2007/08/16 12:25:38.798 0:45.713 GMURLHandl...r:00ddcab0 PWLib File handle low water mark set: 46 PUDPSocket 2007/08/16 12:25:38.798 0:45.713 GMURLHandl...r:00ddcab0 RTP Adding session RTP_UDP 2007/08/16 12:25:38.799 0:45.714 GMURLHandl...r:00ddcab0 SIP Using RTP payload [pt=101] for NTE 2007/08/16 12:25:38.807 0:45.722 GMURLHandl...r:00ddcab0 SIP Using RTP payload [pt=100] for NSE 2007/08/16 12:25:38.840 0:45.755 GMURLHandl...r:00ddcab0 Call GetMediaFormats for Call[1]-EP[EMAIL PROTECTED] H.261 H.261-CIF H.261-QCIF theora G.711-uLaw-64k G.711-ALaw-64k GSM-06.10 PCM-16 PCM-16-16kHz YUV420P RFC4175_YUV420P RGB32 RGB
Re: [Ekiga-devel-list] Issues and crash with new opal/pwlib sockets code
Damien Sandras wrote: > Hi, > > Le jeudi 16 août 2007 à 11:15 +0200, thomas schorpp a écrit : >> Damien Sandras wrote: >>> Hi, >>> >>> >>> Can you post a -d 4 output ? >>> >>> Le jeudi 16 août 2007 à 09:49 +0200, thomas schorpp a écrit : >>>> hi. >>>> >>>> outgoing calls fail here always with loop detected since ~3days following >>>> opal+pwlibs cvs heads, >>>> see attachment. > > following Robert, your build is heavily corrupted. The vtable is not > correct, leading to incorrect functions being called. > > Make sure you build on a clean system. ok, make clean solved it. but may this happen? are we missing some gcc switches? ive thought gcc could handle this. complete recompile of opal/pwlib after every single patch sucks. y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] ekiga + libs trunk, in ~XVWindow at xvwindow.cpp:318 crash
- call ma echo server or call 2.0.1 peer, it will crash on incoming video.
XVdestructor call on SetupFrameDisplay() ???
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb4b32b90 (LWP 6162)]
0x08107ae3 in ~XVWindow (this=0x89be528) at xvwindow.cpp:318
318 if (_XVImage->data)
(gdb) bt full
#0 0x08107ae3 in ~XVWindow (this=0x89be528) at xvwindow.cpp:318
No locals.
#1 0x080dd8d7 in GMVideoDisplay_XV::SetupFrameDisplay (this=0x863a5f8,
display=3, lf_width=0,
lf_height=0, rf_width=176, rf_height=0, zoom=1) at
devices/videooutput_xv.cpp:226
main_window =
image = (GtkWidget *) 0x84162a8
ret = 1
stay_on_top = 0
#2 0x080dbfb4 in GMVideoDisplay_GDK::Redraw (this=0x863a5f8) at
devices/videooutput_gdk.cpp:535
ret = 1
#3 0x080db1ad in GMVideoDisplay_GDK::Main (this=0x863a5f8) at
devices/videooutput_gdk.cpp:122
No locals.
#4 0xb725e03d in PThread::PX_ThreadStart (arg=0x863a5f8) at tlibthrd.cxx:1361
__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {-1221745292,
134955588,
-1263326320, -1263328312, 1917239447, 1606347408}, __mask_was_saved =
0}}, __pad = {
0xb4b32480, 0x0, 0x0, 0xb6366e90}}
__cancel_routine = (void (*)(void *)) 0xb725f4c4
__cancel_arg = (void *) 0x863a5f8
not_first_call = 0
thread = (PThread *) 0x863a5f8
#5 0xb65c246b in start_thread () from /lib/i686/cmov/libpthread.so.0
No symbol table info available.
#6 0xb62f64de in clone () from /lib/i686/cmov/libc.so.6
No symbol table info available.
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] ekiga + libs trunk, msgbox flooding again, codec errors stall X
- call from 2.1.0 to 2.1.0 with G726-16 codec pls get all this possible err msgbox flooding loops out. ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] ekiga + libs trunk, msgbox flooding again, codec errors stall X
thomas schorpp wrote: > - call from 2.1.0 to 2.1.0 with G726-16 > > pls get all this possible err msgbox flooding loops out. > dont receive posts to the list, strange. msgbox text is "unsupported bitsize", 100s of boxes poppin up in 1 sec. with G726-40 codec too, other G726 ok. ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] ekiga + libs trunk, AMR, ms-gsm, LPC10 not working at all; handshake for SPEEX fails, next lower fallback
PCMA/U, gsm ok. pls get LPC10 to work, needed for low bandwith connections (SAT, third world, etc). ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] ekiga + libs trunk, in ~XVWindow at xvwindow.cpp:318 crash
ok on i386 platform. not ok on x86_64 (gui stalls on video preview button,
defunct process, restartsys,
wenn Dir dafür kein Grund einfällt, dann sinds mal wieder alte .so, die opal
make ned aufgeräumt hat,
crasht auch schon beim hauptmenü anklicken :/ )
y
tom
Matthias Schneider wrote:
> Hi Thomas,
> could you please verify the fix I checked in this morning?
> Matthias
>
> --- thomas schorpp <[EMAIL PROTECTED]> schrieb:
>
>> - call ma echo server or call 2.0.1 peer, it will crash on incoming video.
>>
>> XVdestructor call on SetupFrameDisplay() ???
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 0xb4b32b90 (LWP 6162)]
>> 0x08107ae3 in ~XVWindow (this=0x89be528) at xvwindow.cpp:318
>> 318 if (_XVImage->data)
>> (gdb) bt full
>> #0 0x08107ae3 in ~XVWindow (this=0x89be528) at xvwindow.cpp:318
>> No locals.
>> #1 0x080dd8d7 in GMVideoDisplay_XV::SetupFrameDisplay (this=0x863a5f8,
>> display=3, lf_width=0,
>> lf_height=0, rf_width=176, rf_height=0, zoom=1) at
>> devices/videooutput_xv.cpp:226
>> main_window =
>> image = (GtkWidget *) 0x84162a8
>> ret = 1
>> stay_on_top = 0
>> #2 0x080dbfb4 in GMVideoDisplay_GDK::Redraw (this=0x863a5f8) at
>> devices/videooutput_gdk.cpp:535
>> ret = 1
>> #3 0x080db1ad in GMVideoDisplay_GDK::Main (this=0x863a5f8) at
>> devices/videooutput_gdk.cpp:122
>> No locals.
>> #4 0xb725e03d in PThread::PX_ThreadStart (arg=0x863a5f8) at
>> tlibthrd.cxx:1361
>> __cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf =
>> {-1221745292, 134955588,
>> -1263326320, -1263328312, 1917239447, 1606347408}, __mask_was_saved
>> = 0}}, __pad = {
>> 0xb4b32480, 0x0, 0x0, 0xb6366e90}}
>> __cancel_routine = (void (*)(void *)) 0xb725f4c4
>>
>> __cancel_arg = (void *) 0x863a5f8
>> not_first_call = 0
>> thread = (PThread *) 0x863a5f8
>> #5 0xb65c246b in start_thread () from /lib/i686/cmov/libpthread.so.0
>> No symbol table info available.
>> #6 0xb62f64de in clone () from /lib/i686/cmov/libc.so.6
>> No symbol table info available.
>> ___
>> Ekiga-devel-list mailing list
>> Ekiga-devel-list@gnome.org
>> http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] ekiga + libs trunk, in ~XVWindow at xvwindow.cpp:318 crash
24 21:32:22 tom1 kernel: DMA: 0*4kB 0*8kB 1*16kB 1*32kB 0*64kB 1*128kB 1*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 2992kB Oct 24 21:32:22 tom1 kernel: DMA32: 19*4kB 5*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 2692kB Oct 24 21:32:22 tom1 kernel: Swap cache: add 0, delete 0, find 0/0, race 0+0 Oct 24 21:32:22 tom1 kernel: Free swap = 996020kB Oct 24 21:32:22 tom1 kernel: Total swap = 996020kB Oct 24 21:32:22 tom1 kernel: Free swap: 996020kB Oct 24 21:32:22 tom1 kernel: 196560 pages of RAM Oct 24 21:32:22 tom1 kernel: 5277 reserved pages Oct 24 21:32:22 tom1 kernel: 170281 pages shared Oct 24 21:32:22 tom1 kernel: 0 pages swap cached Oct 24 21:32:23 tom1 kernel: /usr/src/gspcav1-20070508/Sunplus-jpeg/sp5xxfw2.h: [spca50x_GetFirmware:662] FirmWare : 3 0 0 5 6 Oct 24 21:32:23 tom1 kernel: /usr/src/gspcav1-20070508/gspca_core.c: [spca5xx_set_light_freq:1889] Sensor currently not support light frequency banding filters. Oct 24 21:32:23 tom1 kernel: /usr/src/gspcav1-20070508/gspca_core.c: [gspca_set_isoc_ep:903] ISO EndPoint found 0x81 AlternateSet 7 Oct 24 21:32:23 tom1 kernel: /usr/src/gspcav1-20070508/Sunplus-jpeg/sp5xxfw2.h: [spca50x_GetFirmware:662] FirmWare : 3 0 0 5 6 Oct 24 21:32:23 tom1 kernel: /usr/src/gspcav1-20070508/gspca_core.c: [spca5xx_set_light_freq:1889] Sensor currently not support light frequency banding filters. Oct 24 21:32:23 tom1 kernel: /usr/src/gspcav1-20070508/gspca_core.c: [gspca_set_isoc_ep:903] ISO EndPoint found 0x81 AlternateSet 7 Oct 24 21:32:24 tom1 kernel: /usr/src/gspcav1-20070508/Sunplus-jpeg/sp5xxfw2.h: [spca50x_GetFirmware:662] FirmWare : 3 0 0 5 6 Oct 24 21:32:24 tom1 kernel: /usr/src/gspcav1-20070508/gspca_core.c: [spca5xx_set_light_freq:1889] Sensor currently not support light frequency banding filters. Oct 24 21:32:24 tom1 kernel: /usr/src/gspcav1-20070508/gspca_core.c: [gspca_set_isoc_ep:903] ISO EndPoint found 0x81 AlternateSet 7 Oct 24 21:32:24 tom1 kernel: /usr/src/gspcav1-20070508/Sunplus-jpeg/sp5xxfw2.h: [spca50x_GetFirmware:662] FirmWare : 3 0 0 5 6 Oct 24 21:32:24 tom1 kernel: /usr/src/gspcav1-20070508/gspca_core.c: [spca5xx_set_light_freq:1889] Sensor currently not support light frequency banding filters. Oct 24 21:32:24 tom1 kernel: /usr/src/gspcav1-20070508/gspca_core.c: [gspca_set_isoc_ep:903] ISO EndPoint found 0x81 AlternateSet 7 Oct 24 21:32:24 tom1 kernel: /usr/src/gspcav1-20070508/Sunplus-jpeg/sp5xxfw2.h: [spca50x_GetFirmware:662] FirmWare : 3 0 0 5 6 Oct 24 21:32:24 tom1 kernel: /usr/src/gspcav1-20070508/gspca_core.c: [spca5xx_set_light_freq:1889] Sensor currently not support light frequency banding filters. Oct 24 21:32:24 tom1 kernel: /usr/src/gspcav1-20070508/gspca_core.c: [gspca_set_isoc_ep:903] ISO EndPoint found 0x81 AlternateSet 7 Oct 24 21:32:25 tom1 kernel: /usr/src/gspcav1-20070508/Sunplus-jpeg/sp5xxfw2.h: [spca50x_GetFirmware:662] FirmWare : 3 0 0 5 6 Oct 24 21:32:25 tom1 kernel: /usr/src/gspcav1-20070508/gspca_core.c: [spca5xx_set_light_freq:1889] Sensor currently not support light frequency banding filters. Oct 24 21:32:25 tom1 kernel: /usr/src/gspcav1-20070508/gspca_core.c: [gspca_set_isoc_ep:903] ISO EndPoint found 0x81 AlternateSet 7 Oct 24 21:32:25 tom1 kernel: /usr/src/gspcav1-20070508/Sunplus-jpeg/sp5xxfw2.h: [spca50x_GetFirmware:662] FirmWare : 3 0 0 5 6 Oct 24 21:32:25 tom1 kernel: /usr/src/gspcav1-20070508/gspca_core.c: [spca5xx_set_light_freq:1889] Sensor currently not support light frequency banding filters. Oct 24 21:32:25 tom1 kernel: /usr/src/gspcav1-20070508/gspca_core.c: [gspca_set_isoc_ep:903] ISO EndPoint found 0x81 AlternateSet 7 Matthias Schneider wrote: > Hi Thomas, > could you send a -d 4 output where it freezes on x84_64? > Matthias > p.s. The video output is in ekiga, not opal... > > --- thomas schorpp <[EMAIL PROTECTED]> schrieb: > >> ok on i386 platform. not ok on x86_64 (gui stalls on video preview button, >> defunct process, >> restartsys, >> wenn Dir dafür kein Grund einfällt, dann sinds mal wieder alte .so, die opal >> make ned aufgeräumt >> hat, >> crasht auch schon beim hauptmenü anklicken :/ ) >> >> y >> tom >> >> Matthias Schneider wrote: >>> Hi Thomas, >>> could you please verify the fix I checked in this morning? >>> Matthias >>> >>> --- thomas schorpp <[EMAIL PROTECTED]> schrieb: >>> >>>> - call ma echo server or call 2.0.1 peer, it will crash on incoming video. >>>> >>>> XVdestructor call on SetupFrameDisplay() ??? >>>> >>>> Program received signal SIGSEGV, Segmentation fault. >>>> [Switching to Thread 0xb4b32b90 (LWP 6162)] >>>> 0x08107ae3 in ~XVWindow (this=0x89be528) at xvwindow.cpp:318 >>>> 318 if (_XVImage->data) >>>> (gdb) bt ful
Re: [Ekiga-devel-list] ekiga + libs trunk, AMR, ms-gsm, LPC10 not working at all; handshake for SPEEX fails, next lower fallback
Damien Sandras wrote: > Le mardi 23 octobre 2007 à 06:45 +0200, thomas schorpp a écrit : >> PCMA/U, gsm ok. >> >> pls get LPC10 to work, needed for low bandwith connections (SAT, third >> world, etc). > > Let's summarize : > - LPC10 does not work > - G726 does not work > > Right ? wrong. AMR, LPC10(no data output), SPEEX (handshake fail or so), G726-16, -48 (stalling X with msgboxflood "unsupported bitsize" )not working. ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Pls don't require exclusive Alsa audio device access, use snd_pcm_dmix_open ()
since dmix is enabled by libasound2 by default for cards not supporting h/w mixing. skype can access the audio device using snd_pcm_dmix_open () if other app has already opened it, ekiga throws error msgboxes. y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Pls don't require exclusive Alsa audio device access, use snd_pcm_dmix_open ()
thomas schorpp wrote:
> since dmix is enabled by libasound2 by default for cards not supporting
> h/w mixing.
>
> skype can access the audio device using snd_pcm_dmix_open () if other
> app has already opened it, ekiga throws error msgboxes.
>
> y
> tom
>
hmm. takeback. future removal warning in alsa lib doc. well for experiments (in
ptlib plugin):
Index: sound_alsa.cxx
===
--- sound_alsa.cxx (Revision 18763)
+++ sound_alsa.cxx (Arbeitskopie)
@@ -344,13 +344,15 @@
}
}
- if (snd_pcm_open (&os_handle, real_device_name, stream, SND_PCM_NONBLOCK) <
0) {
+ if (snd_pcm_open (&os_handle, real_device_name, stream, SND_PCM_NONBLOCK) <
0)
-PTRACE (1, "ALSA\tOpen Failed");
-return FALSE;
- }
- else
-snd_pcm_nonblock (os_handle, 0);
+if (_snd_pcm_dmix_open (&os_handle, real_device_name, snd_config_t* root,
snd_config_t* sconf, stream, SND_PCM_NONBLOCK) < 0) {
+
+ PTRACE (1, "ALSA\tOpen Failed");
+ return FALSE;
+}
+else
+ snd_pcm_nonblock (os_handle, 0);
/* save internal parameters */
device = real_device_name;
i cant find any sample code for the missing params, google is full of alsa user
issues ;)
y
tom
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] ekiga + libs trunk, AMR, ms-gsm, LPC10 not working at all; handshake for SPEEX fails, next lower fallback
Damien Sandras wrote: > Le mercredi 24 octobre 2007 à 22:41 +0200, thomas schorpp a écrit : >> Damien Sandras wrote: >>> Le mardi 23 octobre 2007 à 06:45 +0200, thomas schorpp a écrit : >>>> PCMA/U, gsm ok. >>>> >>>> pls get LPC10 to work, needed for low bandwith connections (SAT, third >>>> world, etc). >>> Let's summarize : >>> - LPC10 does not work >>> - G726 does not work >>> >>> Right ? >> wrong. AMR, LPC10(no data output), SPEEX (handshake fail or so), G726-16, >> -48 >> (stalling X with msgboxflood "unsupported bitsize" )not working. >> > > Craig will have a look... interop test: ekiga svn Revision 5712 + opal svn Revision 18846 and ekiga 2.0.11 debian shows: SPEEX 20k sending but not receiving (vol meter full red, no audio) LPC, SPEEX 8k, G721, G726-16 still not working at all (handshake fail, fallback to next working) direct calls ekiga 2.0.11 -> ekiga svn in LAN bypassing PBX. trying with CallWeaver as proxy, squelchy totally distorted self-generated noises. y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Hard time compiling ekiga
Luis Menina wrote: > Hi all, > I'm currently trying to compile SVN trunk version of Ekiga, in order to > submit patches for this bug: > http://bugzilla.gnome.org/show_bug.cgi?id=361679 > > > Here are the problems I encountered: > 1. ekiga directly segfaulted on startup, due to uninitialized types in > gm_conf_init (lib/gmconf/gmconf-gconf.c). I fixed that calling > g_type_init at the beginning of gm_conf_init, but I think it's a weird > comportement, and don't really know if it's related to my developing > environment. GConf broken or someone has broken it in Ekiga. do gconftool-2 --spawn > > 2. Once I had that fixed, ekiga complained about no audio device being > found. ptlib/opal have changed their install paths from /lib/pwlib to ptlib. clean all old installed stuff up manually. makefile does not support automigration. I just couldn't know what to do then. So I updated everything: my > SVN opal, ptlib and ekiga builds. Since then I can't build ekiga, as I > have linking errors with opal: > > > > /opt/gnome2/lib/libopal.so: undefined reference to > `PString::PString(PScalarArray const&)' read gcc/g++ docs and do make clean opal before make debug. do clean later on any bigger SVN changes or You will run into broken vtables like runtime-hazards producing unconfirmable bugs. y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Pls don't require exclusive Alsa audio device access, use snd_pcm_dmix_open ()
thomas schorpp wrote:
> thomas schorpp wrote:
>> since dmix is enabled by libasound2 by default for cards not
>> supporting h/w mixing.
>>
>> skype can access the audio device using snd_pcm_dmix_open () if other
>> app has already opened it, ekiga throws error msgboxes.
skype 5089 skype memCHR 116,24 7792 /dev/snd/pcmC0D0c
skype 5089 skype memCHR 116,16 7784 /dev/snd/pcmC0D0p
kio_file 5422 schorpp0r CHR1,3956 /dev/null
kio_uiser 6025 schorpp0r CHR1,3956 /dev/null
iceape-bi 30161 schorpp memCHR 116,16 7784 /dev/snd/pcmC0D0p
iceape-bi 30161 schorpp0r CHR1,3956 /dev/null
iceape-bi 30161 schorpp 66r CHR 116,33 7473 /dev/snd/timer
iceape-bi 30161 schorpp 67u CHR 116,16 7784 /dev/snd/pcmC0D0p
>>
>> y
>> tom
>>
>
> hmm. takeback. future removal warning in alsa lib doc. well for
> experiments (in ptlib plugin):
>
> Index: sound_alsa.cxx
> ===
> --- sound_alsa.cxx (Revision 18763)
> +++ sound_alsa.cxx (Arbeitskopie)
> @@ -344,13 +344,15 @@
> }
> }
>
> - if (snd_pcm_open (&os_handle, real_device_name, stream,
> SND_PCM_NONBLOCK) < 0) {
> + if (snd_pcm_open (&os_handle, real_device_name, stream,
> SND_PCM_NONBLOCK) < 0)
>
> -PTRACE (1, "ALSA\tOpen Failed");
> -return FALSE;
> - }
> - else
> -snd_pcm_nonblock (os_handle, 0);
> +if (_snd_pcm_dmix_open (&os_handle, real_device_name, snd_config_t*
> root, snd_config_t* sconf, stream, SND_PCM_NONBLOCK) < 0) {
> +
> + PTRACE (1, "ALSA\tOpen Failed");
> + return FALSE;
> +}
> +else
> + snd_pcm_nonblock (os_handle, 0);
>
> /* save internal parameters */
> device = real_device_name;
>
> i cant find any sample code for the missing params, google is full of
> alsa user issues ;)
>
> y
> tom
>
@alsa devs
any hints?
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Pls don't require exclusive Alsa audio device access, use snd_pcm_dmix_open ()
Colin Guthrie wrote:
> Jaroslav Kysela wrote:
>> On Wed, 28 Nov 2007, thomas schorpp wrote:
>>
>>>> +if (_snd_pcm_dmix_open (&os_handle, real_device_name, snd_config_t*
>>>> root, snd_config_t* sconf, stream, SND_PCM_NONBLOCK) < 0) {
>> Uff. It's really wrong. What you're trying to do? Simply use 'default'
>> device name for snd_pcm_open() which should have defined dmix access if
>> required. And don't forget to allow specify (force) ALSA device name to
>> users if someone wants a special setup.
well, this is only draft code ;) ekiga uses the openh323.org ptlib alsa plugin
and this thing blocks all other apps device access or gets blocked if another
app like iceape is already on the device, twinkle has the same issue and this
gets really on my nerves, cause i need to restart iceape to get the device free
for telephony again, always :[
skype uses snd_pcm_dmix_open() (seen it in a bugtrace) and has no such problems.
i cant hardcode the devicename since it is selected and passed down by ekiga,
the original code does:
- if (snd_pcm_open (&os_handle, real_device_name, stream, SND_PCM_NONBLOCK) <
0)
so i must define the dmix access in ekiga, it seems not be defined implicitely?
>
> +1 Dmix should not be enforced... this can be handled at a lower
> level e.g. with dmix configured in alsa config or by using
> pulseaudio instead of dmix (my preferred solution so I can switch from
> my internal speakers to my usb headset should I plug it in mid-call).
>
> Col.
alsa docs say dmix config files are no longer neccessary?
maybe the old (2.6.18 kernel) driver for this device has more bugs than not
reinitializing mixer setting after acpi resume:
00:1f.5 Multimedia audio controller: Intel Corporation 82801CA/CAM AC'97 Audio
Controller (rev 01)
Subsystem: IBM ThinkPad T23 (2647-4MG) or A30/A30p (2652/2653)
snd_intel8x0 30332 1
snd_ac97_codec 83104 1 snd_intel8x0
snd_ac97_bus2400 1 snd_ac97_codec
snd_pcm_oss38368 0
snd_mixer_oss 15200 1 snd_pcm_oss
snd_pcm68676 3 snd_intel8x0,snd_ac97_codec,snd_pcm_oss
snd_timer 20996 1 snd_pcm
snd47012 8
snd_intel8x0,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer
soundcore 9248 1 snd
snd_page_alloc 9640 2 snd_intel8x0,snd_pcm
ii libasound2 1.0.15-2ALSA library
cat: /proc/asound/I82801CAICH3: Is a directory
cat: /proc/asound/card0: Is a directory
0 [I82801CAICH3 ]: ICH - Intel 82801CA-ICH3
Intel 82801CA-ICH3 with CS4299 at 0x1c00, irq 5
0: [ 0] : control
16: [ 0- 0]: digital audio playback
24: [ 0- 0]: digital audio capture
25: [ 0- 1]: digital audio capture
33:: timer
0 snd_intel8x0
cat: /proc/asound/oss: Is a directory
00-01: Intel ICH - MIC ADC : Intel 82801CA-ICH3 - MIC ADC : capture 1
00-00: Intel ICH : Intel 82801CA-ICH3 : playback 1 : capture 1
cat: /proc/asound/seq: Is a directory
G0: system timer : 4000.000us (1000 ticks)
P0-0-0: PCM playback 0-0-0 : SLAVE
P0-0-1: PCM capture 0-0-1 : SLAVE
P0-1-1: PCM capture 0-1-1 : SLAVE
Advanced Linux Sound Architecture Driver Version 1.0.12rc1 (Thu Jun 22 13:55:50
2006 UTC).
i will try the recent kernel maybe this solves things...
thx
tom
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [alsa-devel] Pls don't require exclusive Alsa audio device access, use snd_pcm_dmix_open ()
Takashi Iwai wrote: > At Wed, 28 Nov 2007 17:01:47 +0100, > thomas schorpp wrote: >>> +1 Dmix should not be enforced... this can be handled at a lower >>> level e.g. with dmix configured in alsa config or by using >>> pulseaudio instead of dmix (my preferred solution so I can switch from >>> my internal speakers to my usb headset should I plug it in mid-call). >>> >>> Col. >> alsa docs say dmix config files are no longer neccessary? > > The behavior depends on the name string passed to snd_pcm_open(). > If you open the PCM with "default", the alsa-lib takes an approriate > configuration for multi-playback and automatic conversions. But, if > app opens with other strings like "hw" or "plughw", then it means > that it's an exclusive access. dmix cannot be involved with that. > > > Takashi > thx guys. using the "default" device in ekiga audio device config solved it :) skype 5218 skype memCHR 116,24 8292 /dev/snd/pcmC0D0c skype 5218 skype memCHR 116,16 8284 /dev/snd/pcmC0D0p iceape-bi 5277 schorpp0r CHR1,3 1107 /dev/null ekiga 5411 schorpp memCHR 116,16 8284 /dev/snd/pcmC0D0p ekiga 5411 schorpp memCHR 116,24 8292 /dev/snd/pcmC0D0c ekiga 5411 schorpp0r CHR1,3 1107 /dev/null ekiga 5411 schorpp 63r CHR 116,33 7972 /dev/snd/timer ekiga 5411 schorpp 64u CHR 116,24 8292 /dev/snd/pcmC0D0c ekiga 5411 schorpp 67r CHR 116,33 7972 /dev/snd/timer ekiga 5411 schorpp 68u CHR 116,16 8284 /dev/snd/pcmC0D0p many thx, Takashi. ALSA rocks! BTW: http://www.xs4all.nl/~mfnboer/twinkle/manual.html#sys_audio "NOTE:The ALSA default device should only be used for the ring tone and/or speaker. It is not recommended to use the ALSA default device for the microphone as it gives poor quality." this is not the case. fine here. http://www.xs4all.nl/~mfnboer/twinkle/faq.html#alsa_no_sound "There can be many reasons why you do not get sound. With ALSA, a common problem is the lack of a proper /etc/asound.conf file. Here is a copy of my asound.conf." twinkle guys should update their docs. y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] [Fwd: Re: [Callweaver-dev] Default to additional RTP payload type 2 handling for RFC3551-violating G.726 codec peers?]
see attachment. y tom --- Begin Message --- thomas schorpp wrote: thomas schorpp wrote: http://www.callweaver.org/ticket/344 1.2RC Revision: 4582 Silently failing calls with all peers still using payload type 2 for G.726 codec and log flooding with NOTICE[xx] rtp.c: Unknown RTP codec 2 received will occur without -DUSE_DEPRECATED_G726 compiler defined CW builds. Please discuss adding configure switch defaulting to YES for -DUSE_DEPRECATED_G726. Tested OK here. Any drawbacks? y tom drawback #1: ekiga 2.0.11 sets up G.721 instead G.726 for payload type 2 if called. That is not a drawback. G.721 is the same as G.726. This is the very reason why the change is being asked for. Ekiga is broken, and follows an ancient non-standard Cisco practice. Steve --- End Message --- ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] SVN Revision 6329: typo in lib/gui/gmstockicons.h and missing icon data in ./pixmaps/inlines.h
--- lib/gui/gmstockicons.h (Revision 6329) +++ lib/gui/gmstockicons.h (Arbeitskopie) -#define GM_STOCK_STATUS_INACALL "gm_status_in_a_call_stock" +#define GM_STOCK_STATUS_INACALL "gm_status_inacall_stock" typo in c++ .h and missing icon data in ./pixmaps/inlines.h gmstockicons.c:72: error: 'gm_status_inacall_stock_data' undeclared (first use in this function) y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] SVN Revision 6329: typo in lib/gui/gmstockicons.h and missing icon data in ./pixmaps/inlines.h
Damien Sandras wrote: > Le mardi 27 mai 2008 à 11:35 +0200, thomas schorpp a écrit : >> --- lib/gui/gmstockicons.h (Revision 6329) >> +++ lib/gui/gmstockicons.h (Arbeitskopie) >> -#define GM_STOCK_STATUS_INACALL "gm_status_in_a_call_stock" >> +#define GM_STOCK_STATUS_INACALL "gm_status_inacall_stock" >> typo in c++ .h and missing icon data in ./pixmaps/inlines.h >> >> gmstockicons.c:72: error: 'gm_status_inacall_stock_data' undeclared (first >> use in this function) > > That's weird it compiles here, but it seems there is a typo. > > I'll have a look tonight. > > Notice that inline_* are automatically generated. thx, make distclean and rm ./pixmaps/inlines.h fixed it, but the typo is still in, dont know the drawbacks of it. ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] [Fwd: [PATCH] Opal: SRTP: No AVP/UDPTL "formats" mentioned in RFC but introduced in rtp.h ? build errors]
-attachments-
--- Begin Message ---
hi, pls check this out:
[EMAIL PROTECTED]:/usr/local/src/opal$ dpkg -l *srtp*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Beschreibung
+++---
un libsrtp-dev(keine Beschreibung
vorhanden)
ii libsrtp1-dev 1.4.4~dfsg-2 Secure RTP (SRTP) and UST
Reference Implementations - developmen
ii srtp-docs1.4.4~dfsg-2 Secure RTP (SRTP) and UST
Reference Implementations - documentat
ii srtp-utils 1.4.4~dfsg-2 Secure RTP (SRTP) and UST
Reference Implementations - utilities
g++ -DPTRACING=1 -D_REENTRANT -fno-exceptions -Wall -DP_64BIT -fPIC -DPIC
-DNDEBUG -I/usr/local/src/opal/include -I/usr/local/src/opal/../ptlib/include
-Os-c /usr/local/src/opal/src/rtp/srtp.cxx -o
/usr/local/src/opal/lib/obj_linux_x86_64_r/srtp.o
/usr/local/src/opal/src/rtp/srtp.cxx: In constructor
'OpalSRTP_UDP::OpalSRTP_UDP(unsigned int, PBoolean)':
/usr/local/src/opal/src/rtp/srtp.cxx:67: error: no matching function for call to
'SecureRTP_UDP::SecureRTP_UDP(unsigned int&, PBoolean&)'
/usr/local/src/opal/include/rtp/rtp.h:1128: note: candidates are:
SecureRTP_UDP::SecureRTP_UDP(const PString&, unsigned int, PBoolean)
/usr/local/src/opal/include/rtp/rtp.h:1114: note:
SecureRTP_UDP::SecureRTP_UDP(const SecureRTP_UDP&)
make[1]: *** [/usr/local/src/opal/lib/obj_linux_x86_64_r/srtp.o] Fehler 1
make[1]: Leaving directory `/usr/local/src/opal'
make: *** [optshared] Fehler 2
[EMAIL PROTECTED]:/usr/local/src/opal$
SecureRTP_UDP(const PString & format, <
cannot see the need or even a encapsulation spec for such formats in
http://www.packetizer.com/rfc/rfc3711/
adding overload to Type SecureRTP_UDP in header, patch attached, compiles now
(but will that run?)
but opal .so will not link libsrtp.a from debian (license conflict?):
-lsrtp -lldap -llber -lldap_r -lpthread -lssl -lcrypto -lexpat -lSDL -lresolv
-ldl
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/4.2.4/../../../../lib/libsrtp.a(srtp.o):
relocation R_X86_64_32 against `mod_srtp' can not be used when making a shared
object; recompile with -fPIC
/usr/lib/gcc/x86_64-linux-gnu/4.2.4/../../../../lib/libsrtp.a: could not read
symbols: Bad value
collect2: ld returned 1 exit status
make[1]: *** [/usr/local/src/opal/lib/libopal_linux_x86_64_d.so.3.3-beta0]
srtp.o is build right:
g++ -DPTRACING=1 -D_REENTRANT -fno-exceptions -Wall -DP_64BIT -fPIC -DPIC -g
-D_DEBUG -I/usr/local/src/opal/include -I/usr/local/src/opal/../ptlib/include
-c /usr/local/src/opal/src/rtp/srtp.cxx -o
/usr/local/src/opal/lib/obj_linux_x86_64_d/srtp.o
seems not to be build with -fPIC, reporting bug.
y
tom
Index: include/rtp/rtp.h
===
--- include/rtp/rtp.h (Revision 20359)
+++ include/rtp/rtp.h (Arbeitskopie)
@@ -1119,6 +1119,14 @@
//@{
/**Create a new RTP channel.
*/
+SecureRTP_UDP(
+#if OPAL_RTP_AGGREGATE
+ PHandleAggregator * aggregator, ///< RTP aggregator
+#endif
+ unsigned id,///< Session ID for RTP channel
+ PBoolean remoteIsNAT///< PTrue is remote is behind NAT
+);
+
SecureRTP_UDP(const PString & format,
#if OPAL_RTP_AGGREGATE
PHandleAggregator * aggregator, ///< RTP aggregator
--- End Message ---
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [Opalvoip-devel] [PATCH] Opal: SRTP: No AVP/UDPTL "formats" mentioned in RFC but introduced in rtp.h ? build errors
me. which opal based phone supports it? ekiga svn seems not. [EMAIL PROTECTED]:/usr/local/src/ekiga$ grep -ir srtp src Übereinstimmungen in Binärdatei src/sip.o. Übereinstimmungen in Binärdatei src/ekiga. Übereinstimmungen in Binärdatei src/manager.o. Übereinstimmungen in Binärdatei src/h323.o. [EMAIL PROTECTED]:/usr/local/src/ekiga$ or does it? nothing in src. y tom Robert Jongbloed wrote: > The trunk version of OPAL will now compile correctly when libSRTP is > installed on your system. I have no idea if it actually works though. > > Anyone out there willing to test it? > > > Robert Jongbloed > OPAL/OpenH323 Architect and Co-founder. > > >> -Original Message- >> From: [EMAIL PROTECTED] [mailto:opalvoip- >> [EMAIL PROTECTED] On Behalf Of thomas schorpp >> Sent: Tuesday, 3 June 2008 10:46 AM >> To: [EMAIL PROTECTED] >> Subject: [Opalvoip-devel] [PATCH] Opal: SRTP: No AVP/UDPTL "formats" >> mentioned in RFC but introduced in rtp.h ? build errors >> >> hi, pls check this out: >> >> [EMAIL PROTECTED]:/usr/local/src/opal$ dpkg -l *srtp* >> Desired=Unknown/Install/Remove/Purge/Hold >> | >> |Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig- >> aWait/Trig >> |-pend / Err?=(none)/Hold/Reinst-required/X=both-problems >> (Status,Err: >> |uppercase=bad) >> ||/ Name Version Beschreibung >> +++--- >> == >> +++== >> un libsrtp-dev(keine >> Beschreibung vorhanden) >> ii libsrtp1-dev 1.4.4~dfsg-2 Secure RTP >> (SRTP) and UST Reference Implementations - developmen >> ii srtp-docs1.4.4~dfsg-2 Secure RTP >> (SRTP) and UST Reference Implementations - documentat >> ii srtp-utils 1.4.4~dfsg-2 Secure RTP >> (SRTP) and UST Reference Implementations - utilities >> >> g++ -DPTRACING=1 -D_REENTRANT -fno-exceptions -Wall -DP_64BIT -fPIC >> -DPIC -DNDEBUG -I/usr/local/src/opal/include - >> I/usr/local/src/opal/../ptlib/include -Os-c >> /usr/local/src/opal/src/rtp/srtp.cxx -o >> /usr/local/src/opal/lib/obj_linux_x86_64_r/srtp.o >> /usr/local/src/opal/src/rtp/srtp.cxx: In constructor >> 'OpalSRTP_UDP::OpalSRTP_UDP(unsigned int, PBoolean)': >> /usr/local/src/opal/src/rtp/srtp.cxx:67: error: no matching function >> for call to 'SecureRTP_UDP::SecureRTP_UDP(unsigned int&, PBoolean&)' >> /usr/local/src/opal/include/rtp/rtp.h:1128: note: candidates are: >> SecureRTP_UDP::SecureRTP_UDP(const PString&, unsigned int, PBoolean) >> /usr/local/src/opal/include/rtp/rtp.h:1114: note: >> SecureRTP_UDP::SecureRTP_UDP(const SecureRTP_UDP&) >> make[1]: *** [/usr/local/src/opal/lib/obj_linux_x86_64_r/srtp.o] >> Fehler 1 >> make[1]: Leaving directory `/usr/local/src/opal' >> make: *** [optshared] Fehler 2 >> [EMAIL PROTECTED]:/usr/local/src/opal$ >> >> SecureRTP_UDP(const PString & format, < >> >> cannot see the need or even a encapsulation spec for such formats in >> http://www.packetizer.com/rfc/rfc3711/ >> >> adding overload to Type SecureRTP_UDP in header, patch attached, >> compiles now (but will that run?) >> >> but opal .so will not link libsrtp.a from debian (license conflict?): >> >> -lsrtp -lldap -llber -lldap_r -lpthread -lssl -lcrypto -lexpat -lSDL >> -lresolv -ldl >> /usr/bin/ld: /usr/lib/gcc/x86_64-linux- >> gnu/4.2.4/../../../../lib/libsrtp.a(srtp.o): relocation R_X86_64_32 >> against `mod_srtp' can not be used when making a shared object; >> recompile with -fPIC >> /usr/lib/gcc/x86_64-linux-gnu/4.2.4/../../../../lib/libsrtp.a: could >> not read symbols: Bad value >> collect2: ld returned 1 exit status >> make[1]: *** [/usr/local/src/opal/lib/libopal_linux_x86_64_d.so.3.3- >> beta0] >> >> srtp.o is build right: >> >> g++ -DPTRACING=1 -D_REENTRANT -fno-exceptions -Wall -DP_64BIT -fPIC >> -DPIC -g -D_DEBUG -I/usr/local/src/opal/include - >> I/usr/local/src/opal/../ptlib/include-c >> /usr/local/src/opal/src/rtp/srtp.cxx -o >> /usr/local/src/opal/lib/obj_linux_x86_64_d/srtp.o >> >> seems not to be build with -fPIC, reporting bug. >> >> y >> tom > > > ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] [Fwd: Delivery Status Notification (Failure)] opaldevel disabled ???
??? --- Begin Message --- This is an automatically generated Delivery Status Notification Delivery to the following recipient failed permanently: [EMAIL PROTECTED] Technical details of permanent failure: PERM_FAILURE: Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550-Postmaster verification failed while checking <[EMAIL PROTECTED]> 550-Called: 64.233.167.114 550-Sent: RCPT TO:<[EMAIL PROTECTED]> 550-Response: 550 5.2.1 The email account that you tried to reach is disabled. a22si3515305pye.6 550-Several RFCs state that you are required to have a postmaster 550-mailbox for each mail domain. This host does not accept mail 550-from domains whose servers reject the postmaster address. 550 Sender verify failed (state 14). - Original message - Received: by 10.86.73.7 with SMTP id v7mr1233737fga.37.1212636208445; Wed, 04 Jun 2008 20:23:28 -0700 (PDT) Return-Path: <[EMAIL PROTECTED]> Received: from ?192.168.0.101? ( [91.89.4.216]) by mx.google.com with ESMTPS id e20sm2793227fga.1.2008.06.04.20.23.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Jun 2008 20:23:27 -0700 (PDT) Message-ID: <[EMAIL PROTECTED]> Date: Thu, 05 Jun 2008 05:23:25 +0200 From: thomas schorpp <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.13) Gecko/20080313 Iceape/1.1.9 (Debian-1.1.9-5) MIME-Version: 1.0 To: [EMAIL PROTECTED] CC: Ekiga development mailing list Subject: Re: [Opalvoip-devel] [PATCH] Opal: SRTP: No AVP/UDPTL "formats" mentioned in RFC but introduced in rtp.h ? build errors References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> In-Reply-To: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit me. which opal based phone supports it? ekiga svn seems not. [EMAIL PROTECTED]:/usr/local/src/ekiga$ grep -ir srtp src Übereinstimmungen in Binärdatei src/sip.o. Übereinstimmungen in Binärdatei src/ekiga. Übereinstimmungen in Binärdatei src/manager.o. Übereinstimmungen in Binärdatei src/h323.o. [EMAIL PROTECTED]:/usr/local/src/ekiga$ or does it? nothing in src. - Message truncated - --- End Message --- ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [Opalvoip-devel] [PATCH] Opal: SRTP: No AVP/UDPTL "formats" mentioned in RFC but introduced in rtp.h ? build errors
Robert Jongbloed wrote: > I actually do not know of any publicly available phone that uses it. Please > talk to the Ekiga people about incorporating it into the application, > sometime. Maybe you can help? tom1:~# apt-cache rdepends libopal-2.2 libopal-2.2 Reverse Depends: libspeex1 |ekiga-gtkonly |ekiga |simpleopal<-- ? libspeex1 |libopal-dev libopal-dbg libopal-2.2-develop |ekiga-gtkonly |ekiga not much in debian. well, i will request a requirements analysis meeting for the weekend ;) if the SRTP abstraction level of opal is high enough and the interfaces support non-complex inclusion to ekiga i will try my luck. remember, press is bashing at SIP these times claiming RTP and other SIP security issues :[ > > P.S. Re mail bounce: only thing I can think of is mailing lists are > sensitive to the "From" address and if you are subscribed as googlemail.com > but sending as gmail.com it won't work. > thx. maybe. > > Robert Jongbloed > OPAL/OpenH323 Architect and Co-founder. > > >> -Original Message- >> From: thomas schorpp [mailto:[EMAIL PROTECTED] >> Sent: Thursday, 5 June 2008 1:23 PM >> To: [EMAIL PROTECTED] >> Cc: Ekiga development mailing list >> Subject: Re: [Opalvoip-devel] [PATCH] Opal: SRTP: No AVP/UDPTL >> "formats" mentioned in RFC but introduced in rtp.h ? build errors >> >> me. which opal based phone supports it? ekiga svn seems not. >> >> [EMAIL PROTECTED]:/usr/local/src/ekiga$ grep -ir srtp src >> Übereinstimmungen in Binärdatei src/sip.o. >> Übereinstimmungen in Binärdatei src/ekiga. >> Übereinstimmungen in Binärdatei src/manager.o. >> Übereinstimmungen in Binärdatei src/h323.o. >> [EMAIL PROTECTED]:/usr/local/src/ekiga$ >> >> or does it? nothing in src. >> >> y >> tom >> >> >> Robert Jongbloed wrote: >>> The trunk version of OPAL will now compile correctly when libSRTP >> is >>> installed on your system. I have no idea if it actually works >> though. >>> Anyone out there willing to test it? >>> >>> >>> Robert Jongbloed >>> OPAL/OpenH323 Architect and Co-founder. >>> >>> >>>> -Original Message- >>>> From: [EMAIL PROTECTED] >> [mailto:opalvoip- >>>> [EMAIL PROTECTED] On Behalf Of thomas schorpp >>>> Sent: Tuesday, 3 June 2008 10:46 AM >>>> To: [EMAIL PROTECTED] >>>> Subject: [Opalvoip-devel] [PATCH] Opal: SRTP: No AVP/UDPTL >> "formats" >>>> mentioned in RFC but introduced in rtp.h ? build errors >>>> >>>> hi, pls check this out: >>>> >>>> [EMAIL PROTECTED]:/usr/local/src/opal$ dpkg -l *srtp* >>>> Desired=Unknown/Install/Remove/Purge/Hold >>>> | >>>> |Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig- >>>> aWait/Trig >>>> |-pend / Err?=(none)/Hold/Reinst-required/X=both-problems >>>> (Status,Err: >>>> |uppercase=bad) >>>> ||/ Name Version Beschreibung >>>> +++--- >>>> == >>>> +++== >>>> un libsrtp-dev(keine >>>> Beschreibung vorhanden) >>>> ii libsrtp1-dev 1.4.4~dfsg-2 Secure RTP >>>> (SRTP) and UST Reference Implementations - developmen >>>> ii srtp-docs1.4.4~dfsg-2 Secure RTP >>>> (SRTP) and UST Reference Implementations - documentat >>>> ii srtp-utils 1.4.4~dfsg-2 Secure RTP >>>> (SRTP) and UST Reference Implementations - utilities >>>> >>>> g++ -DPTRACING=1 -D_REENTRANT -fno-exceptions -Wall -DP_64BIT - >> fPIC >>>> -DPIC -DNDEBUG -I/usr/local/src/opal/include - >>>> I/usr/local/src/opal/../ptlib/include -Os-c >>>> /usr/local/src/opal/src/rtp/srtp.cxx -o >>>> /usr/local/src/opal/lib/obj_linux_x86_64_r/srtp.o >>>> /usr/local/src/opal/src/rtp/srtp.cxx: In constructor >>>> 'OpalSRTP_UDP::OpalSRTP_UDP(unsigned int, PBoolean)': >>>> /usr/local/src/opal/src/rtp/srtp.cxx:67: error: no matching >> function >>>> for call to 'SecureRTP_UDP::SecureRTP_UDP(unsigned int&, >> PBoolean&)' >>>> /usr/local/src/opal/include/rtp/rtp.h:1128: note: candidates are: >>>> SecureRTP_UDP::SecureRTP_UDP(const PString&, unsigned
[Ekiga-devel-list] [PATCH] ZRTP inclusion to Opal and Ekiga, build errors "fixed"
hello, @ekiga-devlist, opal-devlist "fixed" build, patch attached. but seems incomplete for production use. and check the destructor of the extended class pls and someone pls tell me what i'm doing wrong here with that .so stuff -lopal -lpt /usr/lib/libsigc-2.0.so /usr/lib/libxml2.so -lresolv /usr/lib/gcc/x86_64-linux-gnu/4.2.4/../../../../lib/libopal.so: undefined reference to `PWLibStupidLinkerHacks::libSRTPLoader' /usr/lib/gcc/x86_64-linux-gnu/4.2.4/../../../../lib/libopal.so: undefined reference to `zrtp_process_srtp' /usr/lib/gcc/x86_64-linux-gnu/4.2.4/../../../../lib/libopal.so: undefined reference to `zrtp_attach_stream' /usr/lib/gcc/x86_64-linux-gnu/4.2.4/../../../../lib/libopal.so: undefined reference to `zrtp_randstr' /usr/lib/gcc/x86_64-linux-gnu/4.2.4/../../../../lib/libopal.so: undefined reference to `zrtp_init' /usr/lib/gcc/x86_64-linux-gnu/4.2.4/../../../../lib/libopal.so: undefined reference to `zrtp_process_srtcp' /usr/lib/gcc/x86_64-linux-gnu/4.2.4/../../../../lib/libopal.so: undefined reference to `zrtp_done_session_ctx' /usr/lib/gcc/x86_64-linux-gnu/4.2.4/../../../../lib/libopal.so: undefined reference to `zrtp_start_stream' /usr/lib/gcc/x86_64-linux-gnu/4.2.4/../../../../lib/libopal.so: undefined reference to `OpalZrtpDefault::DoGetZrtpProfile()' /usr/lib/gcc/x86_64-linux-gnu/4.2.4/../../../../lib/libopal.so: undefined reference to `zrtp_down' /usr/lib/gcc/x86_64-linux-gnu/4.2.4/../../../../lib/libopal.so: undefined reference to `zrtp_init_session_ctx' /usr/lib/gcc/x86_64-linux-gnu/4.2.4/../../../../lib/libopal.so: undefined reference to `zrtp_process_rtcp' /usr/lib/gcc/x86_64-linux-gnu/4.2.4/../../../../lib/libopal.so: undefined reference to `zrtp_process_rtp' collect2: ld returned 1 exit status make[3]: *** [ekiga] Error 1 @opal-devlist sf list admin postmaster mailbox checking spamfilter blocks and bounces googlemail-users, reported to gmail.com. i could register my own mta but it could be blocked by SORBS etc, too. @all, [EMAIL PROTECTED] Your MTA without/wrong reverse-DNS could be blocked by the big mailproviders. build host: latest debian lenny/sid snapshot amd64 x86_64 build try to link with libopal (latest SVN trunk) [EMAIL PROTECTED]:/usr/local/src/libzrtp-0.6.5$ autoreconf [EMAIL PROTECTED]:/usr/local/src/libzrtp-0.6.5$ ./configure CFLAGS="-O0 -g3 -fPIC -W -Wall -DBUILD_DEBUG_LOG -DBUILD_WITH_CFUNC -DBUILD_DEFAULT_CACHE -DBUILD_DEFAULT_TIMER -DBUILD_ZRTP_MUTEXES -DWITH_ZFONE -DUSE_BUILTIN_SRTP" --prefix=/usr --gcc -f for position independant code missing, needed on x86_64 platform to link libzrtp.a with shared objects. = configuring libzrtp checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes /usr/local/src/libzrtp-0.6.5/config/missing: Unknown `--run' option Try `/usr/local/src/libzrtp-0.6.5/config/missing --help' for more information configure: WARNING: `missing' script is too old or missing --autoconf incomplete [EMAIL PROTECTED]:/usr/local/src/libzrtp-0.6.5$ make install Making install in bnlib make[1]: Entering directory `/usr/local/src/libzrtp-0.6.5/bnlib' test -d /usr/local/include/zrtp || mkdir /usr/local/include/zrtp cp *.h /usr/local/include/zrtp cp: cannot create regular file `/usr/local/include/zrtp/bn64.h': Permission denied cp: cannot create regular file `/usr/local/include/zrtp/lbn64.h': Permission denied make[1]: *** [install] Error 1 make[1]: Leaving directory `/usr/local/src/libzrtp-0.6.5/bnlib' make: *** [install-recursive] Error 1 -- configure --prefix=/usr option is ignored for bnlib, Makefile.in with incomplete automake-support but ok for /usr/local install. y tom Index: include/zrtp/opalzrtp.h === --- include/zrtp/opalzrtp.h (revision 20393) +++ include/zrtp/opalzrtp.h (working copy) @@ -20,6 +20,7 @@ static bool DeInit(); static zrtp_global_ctx *GetZrtpContext(); + static zrtp_profile_t* GetZrtpProfile(); static unsigned char *GetZID(); static void SetEventProcessor(ZrtpEventProcessor *eventProcessor); static ZrtpEventProcessor * GetEventProcessor(); @@ -29,6 +30,7 @@ protected: virtual unsigned char *DoGetZID(); virtual zrtp_global_ctx *DoGetZrtpContext(); + virtual zrtp_profile_t* DoGetZrtpProfile(); virtual bool DoInit(char *name, char *zidFile); private: Index: include/rtp/zrtpudp.h === --- include/rtp/zrtpudp.h (revision 20393) +++ include/rtp/zrtpudp.h (working copy) @@ -9,9 +9,9 @@ #include -struct zrtp_profile_t; -struct zrtp_conn_ctx_t; -struct zrtp_stream_ctx_t; +//struct zrtp_profile_t; already declared in libzrtp.h or header hell +//struct zrtp_conn_ctx_t; +//struct zrtp_stream_ctx_t; class OpalZrtp_UDP : public SecureRTP_UDP @@ -55,13 +55,13 @@ ~LibZrtpSecurityMode_Base(); RTP_UDP * CreateRTPSession( - OpalR
Re: [Ekiga-devel-list] DCCP
Damien Sandras wrote: Le dimanche 08 juin 2008 à 07:48 +0200, Dr. Christian Hoene a écrit : Hello Eugen Dedu, yes I think that will be way VoIP will evolved. It not a question whether but when. As we are planing this implementation for a research project, we need to be a bit ahead of the line. Lets work together on this issues? I am actually not sure where to add it ;-) and it is not limited to the packets length... I don't think so. http://en.wikipedia.org/wiki/User_Datagram_Protocol "The Datagram Congestion Control Protocol (DCCP) is being designed as a partial solution to this potential problem by adding end host TCP-friendly congestion control behavior to high-rate UDP streams such as streaming media." -so only a partial solution of a becoming less "potential" problem due to advances with codecs which will slow down excessive UDP traffic. -most soho embedded routers and firewalls are based on very old linux kernels without DCCP- support and the DCCP wikipedia article states not much implementations since years. since 2006 university playground, but patches for Ekiga are welcome ;) y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] DCCP
yannick wrote: Le dimanche 08 juin 2008 à 22:37 +0200, Christian Hoene a écrit : Hello, "The Datagram Congestion Control Protocol (DCCP) is being designed as a partial solution to this potential problem by adding end host TCP- friendly congestion control behavior to high-rate UDP streams such as streaming media." A good reading to DCCP can be found at http://www.sigcomm.org/sigcomm2006/discussion/showpaper.php?paper_id=3 ok, but presenting it 10x is a rather classic marketing practice. and 2. presenting it in a "professors internist" language will lead me in emotional counter-reaction to second that first: "...Problem Statement for [DCCP]", which discusses such questions as "why not just implement congestion control at the application layer?" and "why not SCTP?" Snark? TheBonsai? -so only a partial solution of a becoming less "potential" problem due to advances with codecs which will slow down excessive UDP traffic. Yes, both the codec and the DCCP must work hand-in-hand. If DCCP tells, that the link is congested, the codec must slow down its coding rate. codecs could implement their own congestions detection protocols on their layer, etc. but i tend to agree finally to leave this to a open standard like DCCP :) -most soho embedded routers and firewalls are based on very old linux kernels without DCCP- support and the DCCP wikipedia article states not much implementations since years. The current solution for NATs is to use DCCP on top of UDP. http://www3.tools.ietf.org/id/draft-phelan-dccp-natencap-00.txt basically ISO/OSI- layer violation? see above. "In order for the [RFC4340] encapsulation to pass through Network Address Translation (NAT) devices, these devices must be updated to recognize and properly modify DCCP. This is the long-term objective for DCCP, and work is underway to specify the necessary operations." :( yes, and as we all know, consumer hardware manufacturers will not provide firmware support for devices >2 years lifecycle age nowadays but you need to buy new for other tech upgrades anyway every 2-5 years, so no point, Yannick. since 2006 university playground, but patches for Ekiga are welcome ;) Did the Internet started a university playground? IMHO researcher are nothing but kids that like to play ;-) with UTF-8 ? ;) pls send messages in ISO- encoding, thanks ;) That's why I like to work at university... o.O sorry for my bad english. good job for sure, thank You very much :) Best, Christian Best Regards, Thomas ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Minor Suggestions
michel memeteau wrote: Hi , here are few questions & suggestions about 3.0 GUI : New account manager is great but : When adding an Ekiga.net account the link for creation should Go directly to http://www.ekiga.net/user/reg/ no way. modern web security practices violation: *phishing danger* long url display in webbrowser is unreadable and easily confusable with phishing urls. never do this in user forwards to password protected service sites. keep it readable and verifiable by quick view at the browsers status & address bars. IMO : find contact & Add contact should have dedicated Bouton shortcut always Visible . Dynamic boutons when a Buddy was selected ( Call , IM ) Was great , right click should be avoid at most I think. ok. Some Values such as the stun server cannot be modify through the preferences window anymore , it's no blocker but maybe an advanced chez box wouldshow more options like in VLC ? no. GNOME usability violation: keep it simple. no buttons and menues flood like in KDE apps. it is automated anyway in opal. Anyway thanks to anybody that worked on this 3.0 , the UI is simple & great , the Software is terribly fast & functionnal. . confirm. y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] stun server up?
sean darcy schrieb: Using asterisk, in sip.conf I have: stunaddr = stun.ekiga.net and I keep getting: chan_sip.c:2617 ast_sip_ouraddrfor: stun failed Is stun.ekiga up? It seems to be an alias for stun.voxgratia.net: ping stun.ekiga.net PING stun.voxgratia.org (83.103.82.85) 56(84) bytes of data. ^C --- stun.voxgratia.org ping statistics --- 18 packets transmitted, 0 received, 100% packet loss, time 17878ms Thanks sean 1. another bug in *, use CallWeaver, not * 2. use STUN-server of Your local non-BCM SIP-provider, stun.ekiga.net is only for first time setup of Ekiga. y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Ekiga on OSX
yannick schrieb: Le samedi 06 septembre 2008 à 17:43 +0200, Damien Sandras a écrit : Le samedi 06 septembre 2008 à 11:27 -0400, Christopher Warner a écrit : I know i've been out of the loop for a while but what's the current status of Ekiga on OSX? Is it that it works and video is just a problem still or what?? I hope everything is going well ;-) Nobody is working on the OSX version, so nothing changed unfortunately... I know someone who's using OSX... /me looks at Christopher... OSX has got already popular free and broad user base accepted apple proprietary "bundled" videoconferencing suites. i don't think Ekiga can break in that "market". if there were enough interest, more OSX developers would show up here. y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] New debian snapshots
Eugen Dedu schrieb: Hi, New debian snapshots are available. from where? ;) y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] New debian snapshots
Luca Capello schrieb: Hi! No flame, please, I'm looking for information. On Tue, 09 Sep 2008 10:38:37 +0200, Eugen Dedu wrote: New debian snapshots are available. The name of packages has been changed. Install the newest ekiga and dependencies with: apt-get install ekiga What's the rationale for this change? This doesn't allow anymore installing *both* ekiga stable and -snapshot. more worse, won't allow upgrade at all due to unfixed(?) gconf issue(s) not handled by the package's installer. According to [1], I understand this as your first step into co-maintainership of ekiga and its rdepends, with the result of new ekiga packages in Debian experimental. However, will snapshots.e.n stop providing snapshot packages after the new ekiga will enter Debian? I don't think this is the desired solution, which means that the package should be (again) renamed to -snapshot. I would second that and suggest rollback to the previous snapshot maintainer's practice. Thx, bye, Gismo / Luca Footnotes: [1] http://lists.alioth.debian.org/pipermail/pkg-voip-maintainers/2008-August/012129.html y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Sending Re-INVITE message
Damien Sandras schrieb: Le vendredi 03 octobre 2008 à 23:29 +0900, Jeong-Yoon Lee a écrit : I want the caller sends a Re-INVITE message to be able to change the audio codec for ongoing SIP session, what should I do? It is not possible yet with Ekiga. use a sip router like CallWeaver or Asterisk and do this with exten => s,n,Set(SIP_CODEC=alaw) in dialplan y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] [BUG] Snapshot segfaults on ACK missed call
-have it called and miss the call
-see hookon button active
-crash it by pressing hookon or with menu hookon.
pure virtual method called
terminate called without an active exception
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7f1b3ba737a0 (LWP 15410)]
0x7f1b36556ed5 in raise () from /lib/libc.so.6
(gdb) bt
#0 0x7f1b36556ed5 in raise () from /lib/libc.so.6
#1 0x7f1b365583f3 in abort () from /lib/libc.so.6
#2 0x7f1b36dda244 in __gnu_cxx::__verbose_terminate_handler () from
/usr/lib/libstdc++.so.6
#3 0x7f1b36dd8646 in ?? () from /usr/lib/libstdc++.so.6
#4 0x7f1b36dd8673 in std::terminate () from /usr/lib/libstdc++.so.6
#5 0x7f1b36dd8f1f in __cxa_pure_virtual () from /usr/lib/libstdc++.so.6
#6 0x00495ea1 in hangup_call_cb (data=) at
gui/main.cpp:1570
#7 0x7f1b372ee0fd in IA__g_closure_invoke (closure=0xae81e0, return_value=0x0, n_param_values=1,
param_values=0xcc69a0, invocation_hint=0x7fff43bd4c20) at /build/buildd/glib2.0-2.18.3/gobject/gclosure.c:767
#8 0x7f1b37301ced in signal_emit_unlocked_R (node=0x87d410, detail=0, instance=0xad1c50, emission_return=0x0,
instance_and_params=0xcc69a0) at /build/buildd/glib2.0-2.18.3/gobject/gsignal.c:3244
#9 0x7f1b373031b8 in IA__g_signal_emit_valist (instance=0xad1c50, signal_id=, detail=0,
var_args=0x7fff43bd4e00) at /build/buildd/glib2.0-2.18.3/gobject/gsignal.c:2977
#10 0x7f1b373036b3 in IA__g_signal_emit (instance=0x3c32, signal_id=15410,
detail=6)
at /build/buildd/glib2.0-2.18.3/gobject/gsignal.c:3034
#11 0x7f1b382a49bb in gtk_widget_activate () from
/usr/lib/libgtk-x11-2.0.so.0
#12 0x7f1b381a95bd in gtk_menu_shell_activate_item () from
/usr/lib/libgtk-x11-2.0.so.0
#13 0x7f1b381ab005 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#14 0x7f1b3819c4d8 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#15 0x7f1b372ee0fd in IA__g_closure_invoke (closure=0x872940, return_value=0x7fff43bd5130, n_param_values=2,
param_values=0xcb0a40, invocation_hint=0x7fff43bd50f0) at /build/buildd/glib2.0-2.18.3/gobject/gclosure.c:767
#16 0x7f1b373019cc in signal_emit_unlocked_R (node=0x8729b0, detail=0, instance=0xa22de0,
emission_return=0x7fff43bd5270, instance_and_params=0xcb0a40) at /build/buildd/glib2.0-2.18.3/gobject/gsignal.c:3282
#17 0x7f1b3730303a in IA__g_signal_emit_valist (instance=0xa22de0, signal_id=, detail=0,
var_args=0x7fff43bd52d0) at /build/buildd/glib2.0-2.18.3/gobject/gsignal.c:2987
#18 0x7f1b373036b3 in IA__g_signal_emit (instance=0x3c32, signal_id=15410,
detail=6)
at /build/buildd/glib2.0-2.18.3/gobject/gsignal.c:3034
#19 0x7f1b3829f0ce in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#20 0x7f1b38194e43 in gtk_propagate_event () from
/usr/lib/libgtk-x11-2.0.so.0
#21 0x7f1b38195f63 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#22 0x7f1b37bf8e7c in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#23 0x7f1b37057aab in IA__g_main_context_dispatch (context=0x850280) at
/build/buildd/glib2.0-2.18.3/glib/gmain.c:2144
#24 0x7f1b3705b26d in g_main_context_iterate (context=0x850280, block=1,
dispatch=1, self=)
at /build/buildd/glib2.0-2.18.3/glib/gmain.c:2778
#25 0x7f1b3705b79d in IA__g_main_loop_run (loop=0x8499b0) at
/build/buildd/glib2.0-2.18.3/glib/gmain.c:2986
#26 0x7f1b38196377 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#27 0x0049f1ec in main (argc=, argv=, envp=)
at gui/main.cpp:4828
(gdb)
(gdb) bt full
#0 0x7f58d407ded5 in raise () from /lib/libc.so.6
No symbol table info available.
#1 0x7f58d407f3f3 in abort () from /lib/libc.so.6
No symbol table info available.
#2 0x7f58d4901244 in __gnu_cxx::__verbose_terminate_handler () from
/usr/lib/libstdc++.so.6
No symbol table info available.
#3 0x7f58d48ff646 in ?? () from /usr/lib/libstdc++.so.6
No symbol table info available.
#4 0x7f58d48ff673 in std::terminate () from /usr/lib/libstdc++.so.6
No symbol table info available.
#5 0x7f58d48fff1f in __cxa_pure_virtual () from /usr/lib/libstdc++.so.6
No symbol table info available.
#6 0x00495ea1 in hangup_call_cb (data=) at
gui/main.cpp:1570
mw =
#7 0x7f58d4e150fd in IA__g_closure_invoke (closure=0xa3b6f0, return_value=0x0, n_param_values=1,
param_values=0xcc0c20, invocation_hint=0x7fffe16faf60) at /build/buildd/glib2.0-2.18.3/gobject/gclosure.c:767
marshal = (GClosureMarshal) 0x7f58d4e21c00
marshal_data = (gpointer) 0x0
__PRETTY_FUNCTION__ = "IA__g_closure_invoke"
#8 0x7f58d4e28ced in signal_emit_unlocked_R (node=0xaf7bb0, detail=0, instance=0xb01840, emission_return=0x0,
instance_and_params=0xcc0c20) at /build/buildd/glib2.0-2.18.3/gobject/gsignal.c:3244
tmp =
handler = (Handler *) 0xb00500
accumulator = (SignalAccumulator *) 0x0
emission = {next = 0x7fffe16fb3b0, instance = 0xb01840, ihint = {signal_id = 268, detail = 0,
run_type = G_SIGNAL_RUN_FIRST},
Re: [Ekiga-devel-list] [BUG] Snapshot segfaults on ACK missed call
Damien Sandras schrieb: Le jeudi 04 décembre 2008 à 10:17 +0100, thomas schorpp a écrit : -have it called and miss the call -see hookon button active -crash it by pressing hookon or with menu hookon. It should be fixed now. Can you check again ? tom1:~# apt-cache policy ekiga-snapshot ekiga-snapshot: Installiert: 0-20081202-1 Kandidat: 0-20081202-1 Versions-Tabelle: *** 0-20081202-1 0 500 http://snapshots.ekiga.net ./ Packages 100 /var/lib/dpkg/status give package :) y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Debian packages
Eugen Dedu schrieb: Hi, I think that currently trunk is much more important than stable branch (which is rarely modified), so, starting from now, ekiga-snapshot will use the trunk version, not the stable branch. Please let me know if it is really a problem for you. More information below: ok. This email summarises information about debian packages on ekiga Web site, http://snapshots.ekiga.net. This site provides three kinds of packages: 1. one package for non-free codecs, to be installed together with official debian packages currently from experimental (stable release) Hi Eugen, sorry not possible, dependency breakage: apt-cache showpkg libopal3.4.2-plugins-non-free Package: libopal3.4.2-plugins-non-free Versions: 3.4.2~1 Dependencies: 3.4.2~1 - libopal3.4.2 (5 3.4.2~1) ^ apt-cache policy libopal3.4.2 libopal3.4.2: Installiert: 3.4.2~dfsg-2 -^ Kandidat: 3.4.2~dfsg-2 Versions-Tabelle: *** 3.4.2~dfsg-2 0 1 http://ftp2.de.debian.org experimental/main Packages 100 /var/lib/dpkg/status y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [BUG] Snapshot segfaults on ACK missed call
Eugen Dedu schrieb: thomas schorpp wrote: Damien Sandras schrieb: Le jeudi 04 décembre 2008 à 10:17 +0100, thomas schorpp a écrit : -have it called and miss the call -see hookon button active -crash it by pressing hookon or with menu hookon. It should be fixed now. Can you check again ? tom1:~# apt-cache policy ekiga-snapshot ekiga-snapshot: Installiert: 0-20081202-1 Kandidat: 0-20081202-1 Versions-Tabelle: *** 0-20081202-1 0 500 http://snapshots.ekiga.net ./ Packages 100 /var/lib/dpkg/status give package :) Given! (Note there is a problem with video, hopefully the package fixing this is uploaded this evening.) completely broken, GUI does not even startup after opal 3.5.2 listener thread spawn, has GNOME support disabled. y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Debian packages
thomas schorpp schrieb: Eugen Dedu schrieb: Hi, I think that currently trunk is much more important than stable branch (which is rarely modified), so, starting from now, ekiga-snapshot will use the trunk version, not the stable branch. Please let me know if it is really a problem for you. More information below: ok. This email summarises information about debian packages on ekiga Web site, http://snapshots.ekiga.net. This site provides three kinds of packages: 1. one package for non-free codecs, to be installed together with official debian packages currently from experimental (stable release) Patch for official debian experimental 3.0.1 users attached. Err... and possible debian security issue: No signature check warning about installing altered deb! y tom diff -rU3 dpkg-repack-6627/DEBIAN/control dpkg-repack-26057/DEBIAN/control --- dpkg-repack-6627/DEBIAN/control 2008-12-21 23:46:47.0 +0100 +++ dpkg-repack-26057/DEBIAN/control 2008-12-21 23:50:42.0 +0100 @@ -6,7 +6,7 @@ Architecture: amd64 Source: opal-non-free Version: 3.4.2~1 -Depends: libopal3.4.2 (= 3.4.2~1), libavcodec51, libc6 (>= 2.7-1), libgcc1 (>= 1:4.1.1), libstdc++6 (>= 4.2.1), libx264-60 (>= 0.svn20080828) +Depends: libopal3.4.2 (= 3.4.2~dfsg-2), libavcodec51, libc6 (>= 2.7-1), libgcc1 (>= 1:4.1.1), libstdc++6 (>= 4.2.1), libx264-60 (>= 0.svn20080828) Description: OPAL non-free codecs (iLBC, h264, h263-1998, mp4v-es) This package contains some of the Debian non-free plugins of the OPAL library: iLBC audio codec, and h264, h263-1998 and mp4v-es video codecs. ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Debian packages
Eugen Dedu schrieb: thomas schorpp wrote: thomas schorpp schrieb: Eugen Dedu schrieb: Hi, I think that currently trunk is much more important than stable branch (which is rarely modified), so, starting from now, ekiga-snapshot will use the trunk version, not the stable branch. Please let me know if it is really a problem for you. More information below: ok. This email summarises information about debian packages on ekiga Web site, http://snapshots.ekiga.net. This site provides three kinds of packages: 1. one package for non-free codecs, to be installed together with official debian packages currently from experimental (stable release) Patch for official debian experimental 3.0.1 users attached. Thanks, applied (removed version dependency completely). Will be available this evening. Ouh, that's a CM control violation which could bring dozens of new weird bug reports down on us if users install left around old plugin with next stable opal version or whatever, can't You OR it? Matthias? y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Audio Video Synchronisation
Anish K. K. schrieb: Audio video out of sync is observed sometimes. Video source data+framerate dependant. Use faster machine, higher broadband or lower the framerate and source video resolution and use the slider in config. y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] ANNOUNCE - Ekiga 3.0.2 [STABLE] available
Eugen Dedu schrieb: This is the third stable release of the 3.0 series of Ekiga. * What is it ? == Ekiga is a free Voice over IP softphone allowing you to do free calls over the Internet. Ekiga is the first Open Source application to support both H.323 and SIP, as well as audio and video. Ekiga was formerly known as GnomeMeeting. More information can be found at http://www.ekiga.org * Where to get it ? === Ekiga is available at: ftp://ftp.gnome.org/pub/gnome/sources/ekiga/3.0 (use 3.0.2) Required libraries can be found at: ftp://ftp.gnome.org/pub/gnome/sources/opal/3.4/ (use 3.4.4) ftp://ftp.gnome.org/pub/gnome/sources/ptlib/2.4/ (use 2.4.4) * What's changed ? == - Make sure sound events are played through the correct devices. (#564370) - Fixed crash on missed call. - Do not show the assistant after an upgrade for which Ekiga was already successfully setup. - Added settings migration from Ekiga 2.0.x. - Allow answering/rejecting calls from the main window even if we use notifications. - Do not try refreshing SUBSCRIBE requests for which the 200 OK contains an expire time of 0. - Fixed sending ACK request to incorrect address when particular types of proxies are being used. - Fixed test for CANCEL receipt on INVITE clearing call. - Ignore multiple forked CANCEL messages. - Fixed issue with registration to a non-standard port. - Fixed restarting timers if get pathological response to a transaction with incorrect Cseq header field. - Fixed missing route set on SIP commands in a dialog when using outbound proxy. On behalf of Ekiga team, Eugen Dedu tom1:~# apt-cache policy ekiga ekiga: Installiert: 3.0.1-1 Kandidat: 3.0.1-1 Versions-Tabelle: *** 3.0.1-1 0 1 http://ftp2.de.debian.org experimental/main Packages 100 /var/lib/dpkg/status ? y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] ANNOUNCE - Ekiga 3.0.2 [STABLE] available
Eugen Dedu schrieb: thomas schorpp wrote: Eugen Dedu schrieb: This is the third stable release of the 3.0 series of Ekiga. * What is it ? == Ekiga is a free Voice over IP softphone allowing you to do free calls over the Internet. Ekiga is the first Open Source application to support both H.323 and SIP, as well as audio and video. Ekiga was formerly known as GnomeMeeting. More information can be found at http://www.ekiga.org * Where to get it ? === Ekiga is available at: ftp://ftp.gnome.org/pub/gnome/sources/ekiga/3.0 (use 3.0.2) Required libraries can be found at: ftp://ftp.gnome.org/pub/gnome/sources/opal/3.4/ (use 3.4.4) ftp://ftp.gnome.org/pub/gnome/sources/ptlib/2.4/ (use 2.4.4) * What's changed ? == - Make sure sound events are played through the correct devices. (#564370) - Fixed crash on missed call. - Do not show the assistant after an upgrade for which Ekiga was already successfully setup. - Added settings migration from Ekiga 2.0.x. - Allow answering/rejecting calls from the main window even if we use notifications. - Do not try refreshing SUBSCRIBE requests for which the 200 OK contains an expire time of 0. - Fixed sending ACK request to incorrect address when particular types of proxies are being used. - Fixed test for CANCEL receipt on INVITE clearing call. - Ignore multiple forked CANCEL messages. - Fixed issue with registration to a non-standard port. - Fixed restarting timers if get pathological response to a transaction with incorrect Cseq header field. - Fixed missing route set on SIP commands in a dialog when using outbound proxy. On behalf of Ekiga team, Eugen Dedu tom1:~# apt-cache policy ekiga ekiga: Installiert: 3.0.1-1 Kandidat: 3.0.1-1 Versions-Tabelle: *** 3.0.1-1 0 1 http://ftp2.de.debian.org experimental/main Packages 100 /var/lib/dpkg/status ? Hi Tom, Adding it in debian means adding several NEW packages (as the soname for ptlib and opal has changed). I planned to update them in two months, when ekiga 3.2 appears (and leny is out). Or maybe doing it for 3.0.2 too...?! Hi, Damien is PL here, ask him. For me unoffcial binaries of this release are satisfiable. I do not really understand why debian is putting Ekiga in "Experimental" state :/ This is annoying. y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] ANNOUNCE - Ekiga 3.0.2 [STABLE] available
Eugen Dedu schrieb: thomas schorpp wrote: Eugen Dedu schrieb: thomas schorpp wrote: Eugen Dedu schrieb: This is the third stable release of the 3.0 series of Ekiga. * What is it ? == Ekiga is a free Voice over IP softphone allowing you to do free calls over the Internet. Ekiga is the first Open Source application to support both H.323 and SIP, as well as audio and video. Ekiga was formerly known as GnomeMeeting. More information can be found at http://www.ekiga.org * Where to get it ? === Ekiga is available at: ftp://ftp.gnome.org/pub/gnome/sources/ekiga/3.0 (use 3.0.2) Required libraries can be found at: ftp://ftp.gnome.org/pub/gnome/sources/opal/3.4/ (use 3.4.4) ftp://ftp.gnome.org/pub/gnome/sources/ptlib/2.4/ (use 2.4.4) * What's changed ? == - Make sure sound events are played through the correct devices. (#564370) - Fixed crash on missed call. - Do not show the assistant after an upgrade for which Ekiga was already successfully setup. - Added settings migration from Ekiga 2.0.x. - Allow answering/rejecting calls from the main window even if we use notifications. - Do not try refreshing SUBSCRIBE requests for which the 200 OK contains an expire time of 0. - Fixed sending ACK request to incorrect address when particular types of proxies are being used. - Fixed test for CANCEL receipt on INVITE clearing call. - Ignore multiple forked CANCEL messages. - Fixed issue with registration to a non-standard port. - Fixed restarting timers if get pathological response to a transaction with incorrect Cseq header field. - Fixed missing route set on SIP commands in a dialog when using outbound proxy. On behalf of Ekiga team, Eugen Dedu tom1:~# apt-cache policy ekiga ekiga: Installiert: 3.0.1-1 Kandidat: 3.0.1-1 Versions-Tabelle: *** 3.0.1-1 0 1 http://ftp2.de.debian.org experimental/main Packages 100 /var/lib/dpkg/status ? Hi Tom, Adding it in debian means adding several NEW packages (as the soname for ptlib and opal has changed). I planned to update them in two months, when ekiga 3.2 appears (and leny is out). Or maybe doing it for 3.0.2 too...?! Hi, Damien is PL here, ask him. For me unoffcial binaries of this release are satisfiable. I do not really understand why debian is putting Ekiga in "Experimental" state :/ Are you the only one :o) not to know that debian is preparing a new stable release and only RC bug fixes are allowed in unstable/testing? Hi Eugen, yes i know, but from SW-QM/QA/CM-view i cannot agree to freeze unstable for a stable release. but this is off-topic here. Do we get 3.0.2 Release binaries for debian on snapshots server now, or do we want to have announced a release without any binary support for debian? We will not get a broad user and QA-feedback base for 3.0.2 if users must go through the non-complex build processes themselves to get binaries and this could bring up a heap of extra annoying bug reports from wrong build configurations and CM-inconsistent user environments again. y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] port ekiga to osx
Peter Robinson schrieb: Hi, I am a trainee. They want me to port ekiga to osx. I have about 2 months to do this. Could u people point me at the right direction? Insufficent project specification for support, sorry. I don't know anything about MacOSX but there is a port of gtk [1] to OSX already, I believe PTLIB and OPAL is (or at least use to be) supported on OSX but there were issues with at least video support from memory but as the latest release of ekiga has at least beta support for audio/video input/output via gstreamer and thanks to songbird and a couple of other projects gstreamer is fully supported on OSX it should be possible. Speculation, he said "port", not cross-build, since "They" have him hiding behind M$ hotmail their management behaviour implies to me they want to convert Ekiga to OSX GUI+A/V-APIs and so I doubt "They" will contribute to us with any patches nor with a compatible license, will "They"? Peter [1] http://www.gtk-osx.org/ y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] port ekiga to osx
Fine. But as I said, You get more efficient help here If You write some analysis+design spec together, Trainee. The effort (under)estimation has Your mentor already done for You ;) Don't hesitate to ask for more. y tom Original-Nachricht Betreff: RE: [Ekiga-devel-list] port ekiga to osx Datum: Thu, 19 Mar 2009 16:16:53 +0100 Von: Hannes De Backer An: I'm sorry "They" is my mentor at aserver: http://confluence.aserver.com/display/www/Home?co= We won't take disadvantage of the software, if that is you think. If the port succeeds, i will share, [...] Date: Thu, 19 Mar 2009 16:08:03 +0100 From: thomas.scho...@googlemail.com To: ekiga-devel-list@gnome.org Subject: Re: [Ekiga-devel-list] port ekiga to osx Peter Robinson schrieb: > Hi, > >> I am a trainee. They want me to port ekiga to osx. I have about 2 months to >> do this. >> Could u people point me at the right direction? Insufficent project specification for support, sorry. > > I don't know anything about MacOSX but there is a port of gtk [1] to > OSX already, I believe PTLIB and OPAL is (or at least use to be) > supported on OSX but there were issues with at least video support > from memory but as the latest release of ekiga has at least beta > support for audio/video input/output via gstreamer and thanks to > songbird and a couple of other projects gstreamer is fully supported > on OSX it should be possible. Speculation, he said "port", not cross-build, since "They" have him hiding behind M$ hotmail their management behaviour implies to me they want to convert Ekiga to OSX GUI+A/V-APIs and so I doubt "They" will contribute to us with any patches nor with a compatible license, will "They"? > > Peter > > [1] http://www.gtk-osx.org/ y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] The stun server is down.
yannick schrieb: Hello, Unfortunately the STUN server which helps to pass NATs is down at the moment. Thus you probably get a message error from Ekiga asking you to setup port forwarding. When the STUN server will be up again this error will disappear. We hope to fix this situation soon. Sorry for the disagreement. Best regards, Yannick Hi :) Well, haven't we agreed in 2006 here Re: SUMMARY STUN, Was: Re: [GnomeMeeting-devel-list] Again: STUN on that people should use their SIP-Providers STUN-services? But someone has patched the setting out of the GUI, so please respect the GCONF setting at least since not all providers have got a reliable DNS SRV services setup to retrieve the STUN server automatically from, especially not the cheapest: host -t SRV _stun._udp.sip.intervoip.com Host _stun._udp.sip.intervoip.com not found: 3(NXDOMAIN) Y tom ___ 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)
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 +... 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. 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. The further spreading of electronic notepads and mobiles will lead to such old paper form notation habits vanish soon since the softwares do not support it either, "-" and " " may still even crash many webforms. So: first question: Would this overall be a Good Thing, something that makes Ekiga more usable, and thus worth some effort? No. At all love to ergonomics, users should adapt their habits to new techs a little and it is not our job to "fix" some Providers uncool switches. y tom ___ 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)
@Eugen, pls don't top post, You're ruining threads on this list ;) Alec Leamas schrieb: 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 +... 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. No. Only in "chaos" environments of unprofessional VoIP setups. 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. Yes it does, multiple SIP-accounts is a _optional_ feature competing products like x-lite do _not_ support at all and it is practically not needed in office and private real life because we got PBXes like Asterisk easily installable on all router platforms like AVM Fritzboxes and professional linux gateways etc which are invented for handling multi-accounts. 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. I must object. You guys are trespassing out of best HMI and manual data handling ergonomic and software/data security practices wich will lead to millions $ of economic damage cause users will try to feed computer interfaces machine unreadable data if we software engineers support such habit, look at this: After 2011 all EU bank accounts will have this notations: - Paper format IBAN: IBAN BE61 3101 2698 5517 - Electronic format IBAN: BE61310126985517 Why the need for 2 formats? For easy and error-proof human data transfer between unconnected computer system or by copy&paste e.g., inventing _Your way_ You will support _wrong habit_ working with computers and could try to c&p the paper form someone used illegally in mail or on website in a GUI form input field which may _cut_ characters at the end without notice _after_ You click "OK", there're many of such GUIs and webforms still around, so the bank transfer will fail without notice and You'll pay punishment fees for violating SEPA-criteria, and here You want to violate the SIP-Standard by breaking up SIP-URIs, this is inacceptable. 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? VoIP-Freedom with SIP is always "complicated", especially to the ones long been unfree with Skype + MSN. Cheers! --a y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] User SIP port
Eugen Dedu wrote: Hi, I have a bug in debian (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=530051): if the user adds a registrar like abc.fr:port to Acconts->AddSIPAccount, then the port is not used but 5060 is used instead. I also see that there is a gconf key, protocols/sip/listen_port with value 5060. I suppose ekiga can use only one port, for all registrars, and is found in this key, is that right? I believe Ekiga (Opal) is using DNS SRV lookup to get the correct port, but the registrar must support this in his DNS setup. y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 please test
Michael Rickmann wrote: Hello everybody, I have a new Windows version of Ekiga head based on attached minimal but rather effective patches. you find it in my directory at http://wwwuser.gwdg.de/~mrickma/ekiga/ . As to the patches: Please test whether the new attempt works for you. No. -Version mismatch, Info Msgbox shows 3.3.0 not 3.2.0 -Hangs on adding/registering 2nd account for local pbx. -Does not support detected UVC Webcam that works with Linux Ekiga 3.2.1. I would like to know whether Ekiga really shuts down on Vista or whether it has to be killed with the task manager. Shuts down cleanly on winxpx64. y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] video decoding debug
André Abrantes wrote: Hello there. I have been working with Ekiga for quite some time and now I am testing how it handles video calls coming from different environments via Asterisk. But let's not focus on that right now. Somehow, we are receiving media packages but, at the end of the call, the decoder says it has not decoded any frame. NotOurBug, report to digium pls. So, does anyone know a way for me to debug ekiga/opal/x264 to find why H.264 frames are not getting decoded? Record the stream to file and feed mplayer/transcode/ffmpeg with it to check. -- []'s André de Abrantes Y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] g729 and Ekiga
hi greenhorns, Mark Ryden wrote: Hi, list, I want to add that this subject is of much interest also to me. I would really appreciate if somebody could shed some light on g.729 and ekiga. G.729 has patents pending and so cannot be distributed under most OSS-licences. AFAIK, there are some open source projects which support g.729 codecs. For example, asterisk (though I do not have experience with it). Format support, Codec operation support requires buying a licence as You can RTFM of Asterisk. There are some more, which were mentioned in some posts in this mailing list in the past. So, anybody who has experience with g.729 and Ekiga, (good or bad), please share your experience with us. There're better codecs, no one needs G.729. Rgs, Mark On Fri, Nov 6, 2009 at 7:13 PM, Andy Johnson wrote: Hello, Is there support in Ekiga for g.729 audio codec ? No. I saw some threads about it in the mailing list and on some other places, but I am not sure as whether this can be done or not. Read the source code and G.729 specific tech+law docs. I would appreciate if anyone who have any experience with it will share his experience. If it is possible to use g.729, it would be great to post here a step by step We're not Your unpaid personal support engineers. description of what should be done for achieving it. I see that in opal-3.6.6 , there is some support for g.729 (in src/codec/g729mf.cxx) but I am not sure what this means/ mf = media format, passthru, not codec operation implemented. Regards, AndyJ y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] SUBSCRIBE is broken, wrong or missing auth credentials
Feb 6 18:20:02 NOTICE[3058822032] chan_sip.c: Failed to authenticate user "Tom1 Schorpp" ;tag=98121ae9-b911-df11-8540-001109d76d6b for SUBSCRIBE No such account "Tom1 Schorpp" in IP-PBX. Wrong usage of displayed name. Feb 6 18:20:21 WARNING[3058822032] chan_sip.c: Maximum retries exceeded on transmission e073f3e8-b911-df11-8540-001109d76...@tom1 for seqno 2 (Critical Response) SIP Timer T1 : 500 Ekiga 3.2.6 debian, has worked with previous versions. y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Upcoming Ekiga 3.4.x
Am 13.05.2010 19:52, schrieb Eugen Dedu: On 13/05/10 05:38, Hong Tran Duc wrote: Hey buddies, In the next version (ekiga 3.4), which underlaying libs such as Opal and ptLib are tending to use? I'm on way to migrate Ekiga git workable with newer version of Opal, but actually I'm considering which ones is preferable? We do not know yet. We will decide very soon. Hopefully one which can do calls over NAT again, Ekiga 3.2.6 + Opal 3.6.6 debian is broken. REGISTERs and incoming calls work but out INVITEs get no answers from proxies, nor ekiga.net. It's not the routers or SIP-Providers, Twinkle is able to call over NAT to them. From my prospective, latest stable (3.8.x) is better than trunk version (3.9.x). Have you tried both of them? Could you elaborate? ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Regarding SRTP support
Am 12.09.2010 08:46, schrieb SM: Hi, Does Ekiga 3.2.7 have support for SRTP? Is it already enabled or we need to compile it separately? Since OPAL has support for SRTP, can we utilize the same? I will really appreciate an early reply. Thanks, SM Better CC opalvoip-de...@lists.sourceforge.net I've done a very little in Opal for SRTP support some years ago, but I don't know about the current status or if it has even been tested. Anyway I vote for SRTP support in Ekiga, too, but can't implement it, out of resources. Although there only a few SIP providers with SRTP support. For arranged p2p calls, Zimmermann's ZRTP proxy daemon can still be used? y tom ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
