From patrick.smart at gmail.com Wed Nov 1 01:07:11 2006 From: patrick.smart at gmail.com (Patriiiiiiiiiick) Date: Wed, 1 Nov 2006 02:07:11 +0100 Subject: [Ekiga-list] crash with 2.0.3 In-Reply-To: <1159197581.3843.62.camel@golgoth01> References: <6eda068e0609151350y166faea4q3a0d409f43815846@mail.gmail.com> <1158398205.3685.7.camel@golgoth01> <6eda068e0609160926k19141b53he6ad1b4137f57ae2@mail.gmail.com> <1158499101.3727.7.camel@golgoth01> <6eda068e0609171438k5b477029ie3424989021ee834@mail.gmail.com> <1158565143.3789.8.camel@golgoth01> <6eda068e0609221200w1e003d14vd9e71c806a536809@mail.gmail.com> <1159003382.5171.6.camel@golgoth01> <6eda068e0609231718n1f8dea39nc07b0eae755b69a1@mail.gmail.com> <1159197581.3843.62.camel@golgoth01> Message-ID: <6eda068e0610311707k66633477yaef53c4d10470935@mail.gmail.com> On 9/25/06, Damien Sandras wrote: > > http://phpfi.com/156472 > Unfortunately there are no debug symbols. I suppose that to have the debug symbols, I need to have the debuginfo packages installed. I could rebuild the opal src.rpm but with pwlib, I get stuck at: File not found: /var/tmp/pwlib-1.10.2-build/usr/lib/pwlib/devices/videoinput/avc_pwplugin.so I have pwlib-plugins-avc-1.10.2-1.pm.1.i586.rpm installed but the requested file is at another place: /usr/lib/pwlib/devices/videoinput/avc_pwplugin.so. Where does this issue come from? I saw that pwlib 1.11 and opal 2.3 were available from SUSE's build service. This would be the solution to the issue above. What chance is there that it will work with Ekiga 2.0.3? Or any plan to release a new version of Ekiga soon? Thanks for your time! Patrick From dsandras at seconix.com Wed Nov 1 11:35:49 2006 From: dsandras at seconix.com (Damien Sandras) Date: Wed, 01 Nov 2006 12:35:49 +0100 Subject: [Ekiga-list] need documentation of how to get Ekiga working with other programs In-Reply-To: <20061031172456.2c8e036c@localhost.localdomain> References: <1162233295.5416.17.camel@localhost> <1162284716.31104.23.camel@achille> <1162300027.15370.2.camel@golgoth01> <20061031172456.2c8e036c@localhost.localdomain> Message-ID: <1162380949.3830.3.camel@golgoth01> Le mardi 31 octobre 2006 ? 17:24 +0100, Jan Schampera a ?crit : > On Tue, 31 Oct 2006 14:07:07 +0100 > Damien Sandras wrote: > > > Hi Yannick, > > > > I can open it to everyone again. What do people think? > > > > It is ok if we backup... > > Can it be done partially? I've no idea unfortunately. -- Damien Sandras Ekiga Softphone : http://www.ekiga.org NOVACOM : http://www.novacom.be FOSDEM : http://www.fosdem.org SIP Phone : sip:dsandras at ekiga.net From dsandras at seconix.com Wed Nov 1 11:36:31 2006 From: dsandras at seconix.com (Damien Sandras) Date: Wed, 01 Nov 2006 12:36:31 +0100 Subject: [Ekiga-list] crash with 2.0.3 In-Reply-To: <6eda068e0610311707k66633477yaef53c4d10470935@mail.gmail.com> References: <6eda068e0609151350y166faea4q3a0d409f43815846@mail.gmail.com> <1158398205.3685.7.camel@golgoth01> <6eda068e0609160926k19141b53he6ad1b4137f57ae2@mail.gmail.com> <1158499101.3727.7.camel@golgoth01> <6eda068e0609171438k5b477029ie3424989021ee834@mail.gmail.com> <1158565143.3789.8.camel@golgoth01> <6eda068e0609221200w1e003d14vd9e71c806a536809@mail.gmail.com> <1159003382.5171.6.camel@golgoth01> <6eda068e0609231718n1f8dea39nc07b0eae755b69a1@mail.gmail.com> <1159197581.3843.62.camel@golgoth01> <6eda068e0610311707k66633477yaef53c4d10470935@mail.gmail.com> Message-ID: <1162380991.3830.5.camel@golgoth01> Le mercredi 01 novembre 2006 ? 02:07 +0100, Patriiiiiiiiiick a ?crit : > On 9/25/06, Damien Sandras wrote: > > > http://phpfi.com/156472 > > Unfortunately there are no debug symbols. > > I suppose that to have the debug symbols, I need to have the debuginfo > packages installed. > > I could rebuild the opal src.rpm but with pwlib, I get stuck at: > > File not found: > /var/tmp/pwlib-1.10.2-build/usr/lib/pwlib/devices/videoinput/avc_pwplugin.so > > I have pwlib-plugins-avc-1.10.2-1.pm.1.i586.rpm installed but the > requested file is at another place: > /usr/lib/pwlib/devices/videoinput/avc_pwplugin.so. > > Where does this issue come from? > >From the src.rpm. > I saw that pwlib 1.11 and opal 2.3 were available from SUSE's build > service. This would be the solution to the issue above. What chance is > there that it will work with Ekiga 2.0.3? Or any plan to release a new > version of Ekiga soon? > I can not tell. Just try ;-) > Thanks for your time! > > Patrick > _______________________________________________ > ekiga-list mailing list > ekiga-list at gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list -- _ Damien Sandras (o- //\ Ekiga Softphone : http://www.ekiga.org/ v_/_ NOVACOM : http://www.novacom.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsandras at ekiga.net From paul.barron at dsl.pipex.com Wed Nov 1 21:16:21 2006 From: paul.barron at dsl.pipex.com (Paul Barron) Date: Wed, 01 Nov 2006 21:16:21 +0000 Subject: [Ekiga-list] Registration failed:not acceptable In-Reply-To: <1161723963.5810.29.camel@golgoth01> References: <453E5D4B.3060200@dsl.pipex.com> <1161723963.5810.29.camel@golgoth01> Message-ID: <45490EA5.6050006@dsl.pipex.com> Thanks for the reply, and the great software, I found that if I change NAT settings to IP translation every thing worked again. So we were able to see the family again. Damien Sandras wrote: > Le mardi 24 octobre 2006 ? 19:36 +0100, Paul Barron a ?crit : > >> This software has been operating very well, allowing us to see and speak >> to family overseas. >> when I tried to communicate at the weekend we both got the message >> Registration failed:not acceptable >> > > That means that you are behind NAT and not configured. > Is STUN enabled? > > Notice that our STUN server was down recently, so it could cause the > problem you experienced this week-end. Perhaps now it works again. > > >> I also don't seem able to log in to the website ekiga.net >> using the information sent to me when I first registered I have checked >> and rechecked the information and >> ekiga is able to register with freeworld dialup. >> >> > > Same, we had a small downtime until yesterday. Everything should work > again now. > > From patrick.smart at gmail.com Wed Nov 1 23:52:02 2006 From: patrick.smart at gmail.com (Patriiiiiiiiiick) Date: Thu, 2 Nov 2006 00:52:02 +0100 Subject: [Ekiga-list] crash with 2.0.3 In-Reply-To: <1162380991.3830.5.camel@golgoth01> References: <6eda068e0609151350y166faea4q3a0d409f43815846@mail.gmail.com> <1158499101.3727.7.camel@golgoth01> <6eda068e0609171438k5b477029ie3424989021ee834@mail.gmail.com> <1158565143.3789.8.camel@golgoth01> <6eda068e0609221200w1e003d14vd9e71c806a536809@mail.gmail.com> <1159003382.5171.6.camel@golgoth01> <6eda068e0609231718n1f8dea39nc07b0eae755b69a1@mail.gmail.com> <1159197581.3843.62.camel@golgoth01> <6eda068e0610311707k66633477yaef53c4d10470935@mail.gmail.com> <1162380991.3830.5.camel@golgoth01> Message-ID: <6eda068e0611011552r69ed018cu9dd50d8cd01019a3@mail.gmail.com> On 11/1/06, Damien Sandras wrote: > Le mercredi 01 novembre 2006 ? 02:07 +0100, Patriiiiiiiiiick a ?crit : > > Where does this issue come from? > From the src.rpm. I could work this issue around by copying the file during the compilation after the clean-up. > > I saw that pwlib 1.11 and opal 2.3 were available from SUSE's build > > service. This would be the solution to the issue above. What chance is > > there that it will work with Ekiga 2.0.3? Or any plan to release a new > > version of Ekiga soon? > > > I can not tell. Just try ;-) No, it doesn't work at all, even when putting symbolic links to the new version. Now, logically the famous crash with debugging symbols: http://phpfi.com/170052 You will/might see that: - the beginning is missing but I presume it's not relevant; - the crash did not occur immediately but the incoming call did not make it through (continue to ring on the phone side). Parick From dmk at ucsc.edu Thu Nov 2 01:42:51 2006 From: dmk at ucsc.edu (David M. Kaplan) Date: Wed, 01 Nov 2006 17:42:51 -0800 Subject: [Ekiga-list] need for documentation In-Reply-To: References: Message-ID: <1162431771.5370.28.camel@localhost> Hi, Yes, mediawiki can be partially opened depending on what you mean by partially opened. You can either only allow the administrator to add users (and email new users temp passwords) or allow users to create accounts, but require a confirmed email address to begin editing. You would also want to prohibit anonymous edits. The following page is a bit longwinded, but explains how: http://meta.wikimedia.org/wiki/Preventing_Access Hope this helps. Cheers, David From geboyd53 at comcast.net Thu Nov 2 03:56:28 2006 From: geboyd53 at comcast.net (George Boyd) Date: Wed, 01 Nov 2006 19:56:28 -0800 Subject: [Ekiga-list] Weird Sound problem With Ekiga In-Reply-To: <1162283165.4038.4.camel@golgoth01> References: <1162256241.7497.4.camel@george> <1162283165.4038.4.camel@golgoth01> Message-ID: <1162439788.19554.1.camel@george> oops, looks like I spoke to soon. This only fixed the problem to Ekiga's echo server. But still have the same problems making phone calls :( On Tue, 2006-10-31 at 09:26 +0100, Damien Sandras wrote: > Hi, > > Thank you for reporting back, that's interesting! > > Le lundi 30 octobre 2006 ? 16:57 -0800, George Boyd a ?crit : > > Hi Damien, > > > > I finally found what was causing the "helicopter" sound and the reason > > the jitter buffer was racing so high. It turns out that my TV card has > > somehow affected my system audio. It uses the line in port to my audio > > card and if I mute the line in, Ekiga works great! > > > > I don't know why that has happened, but it was the fix. So I hope that > > others that may be having the sane problem can benefit from this. > > > > Thanks for your help, > > George > > > > > > _______________________________________________ > > ekiga-list mailing list > > ekiga-list at gnome.org > > http://mail.gnome.org/mailman/listinfo/ekiga-list From dsandras at seconix.com Thu Nov 2 12:50:10 2006 From: dsandras at seconix.com (Damien Sandras) Date: Thu, 02 Nov 2006 13:50:10 +0100 Subject: [Ekiga-list] crash with 2.0.3 In-Reply-To: <6eda068e0611011552r69ed018cu9dd50d8cd01019a3@mail.gmail.com> References: <6eda068e0609151350y166faea4q3a0d409f43815846@mail.gmail.com> <1158499101.3727.7.camel@golgoth01> <6eda068e0609171438k5b477029ie3424989021ee834@mail.gmail.com> <1158565143.3789.8.camel@golgoth01> <6eda068e0609221200w1e003d14vd9e71c806a536809@mail.gmail.com> <1159003382.5171.6.camel@golgoth01> <6eda068e0609231718n1f8dea39nc07b0eae755b69a1@mail.gmail.com> <1159197581.3843.62.camel@golgoth01> <6eda068e0610311707k66633477yaef53c4d10470935@mail.gmail.com> <1162380991.3830.5.camel@golgoth01> <6eda068e0611011552r69ed018cu9dd50d8cd01019a3@mail.gmail.com> Message-ID: <1162471810.5152.10.camel@golgoth01> Le jeudi 02 novembre 2006 ? 00:52 +0100, Patriiiiiiiiiick a ?crit : > On 11/1/06, Damien Sandras wrote: > > Le mercredi 01 novembre 2006 ? 02:07 +0100, Patriiiiiiiiiick a ?crit : > > > Where does this issue come from? > > From the src.rpm. > > I could work this issue around by copying the file during the > compilation after the clean-up. > > > > > I saw that pwlib 1.11 and opal 2.3 were available from SUSE's build > > > service. This would be the solution to the issue above. What chance is > > > there that it will work with Ekiga 2.0.3? Or any plan to release a new > > > version of Ekiga soon? > > > > > I can not tell. Just try ;-) > > No, it doesn't work at all, even when putting symbolic links to the new version. > > Now, logically the famous crash with debugging symbols: > > http://phpfi.com/170052 > > You will/might see that: > > - the beginning is missing but I presume it's not relevant; > - the crash did not occur immediately but the incoming call did not > make it through (continue to ring on the phone side). > I don't see a crash but a SIGABRT, which can happen with memory problems. And I see this: #9 0xb7ef5e51 in operator delete () from /usr/lib/libstdc++.so.6 #10 0xb7ef5e51 in operator delete () from /usr/lib/libstdc++.so.6 #11 0xb54cd8fc in QPen::~QPen () from /usr/lib/qt3/lib/libqt-mt.so.3 #12 0xb54cdcad in QPainter::~QPainter () from /usr/lib/qt3/lib/libqt-mt.so.3 #13 0xb594da84 in drawFrame () from /opt/gnome/lib/gtk-2.0/2.4.0/engines/libqtengine.so #14 0xb594a684 in qtengine_style_register_type () from /opt/gnome/lib/gtk-2.0/2.4.0/engines/libqtengine.so Can you try with another theme than the QT theme? Thanks, -- _ Damien Sandras (o- //\ Ekiga Softphone : http://www.ekiga.org/ v_/_ NOVACOM : http://www.novacom.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsandras at ekiga.net From geboyd53 at comcast.net Thu Nov 2 22:51:29 2006 From: geboyd53 at comcast.net (George Boyd) Date: Thu, 02 Nov 2006 14:51:29 -0800 Subject: [Ekiga-list] Fedora Binaries for Ekiga Message-ID: <1162507889.3581.4.camel@c-71-193-191-8.hsd1.wa.comcast.net> I had offered a while back to help making the fedora binaries and someone answered me. But after an arduous time of installing Fedora Core 6, in the process I lost my email. I am now up and running again, so I can help. If the person who replied to me before would send me another email, I can get started. They will be Fedora Core 6 binaries, don't know if that matters or not. George From sevmek at free.fr Sat Nov 4 18:07:42 2006 From: sevmek at free.fr (yannick) Date: Sat, 04 Nov 2006 19:07:42 +0100 Subject: [Ekiga-list] FWD account Message-ID: <1162663663.6944.119.camel@achille> Hi folks ! In order to have a "call me" feature, i'm trying to set up a Free World Dialup account in Ekiga. I poorly failed. Here is my config : My Ekiga works great with ekiga.net (no nat or stuffs like that). Account window : Registrar: fwd.pulver.com User: My number 80XXXX Password: XXXXXX But that fail. Regards, Yannick -- Me joindre en t?l?phonie IP / vid?oconf?rence ? sip:yannick at ekiga.net From typhoon at aanet.com.au Sat Nov 4 20:51:57 2006 From: typhoon at aanet.com.au (Typhoon) Date: Sun, 5 Nov 2006 07:51:57 +1100 Subject: [Ekiga-list] FWD account In-Reply-To: <1162663663.6944.119.camel@achille> References: <1162663663.6944.119.camel@achille> Message-ID: <20061105075157.98c161f1.typhoon@aanet.com.au> On Sat, 04 Nov 2006 19:07:42 +0100 yannick wrote: > Hi folks ! > > In order to have a "call me" feature, i'm trying to set up a Free > World Dialup account in Ekiga. I poorly failed. > > Here is my config : > > My Ekiga works great with ekiga.net (no nat or stuffs like that). > > Account window : > Registrar: fwd.pulver.com > User: My number 80XXXX > Password: XXXXXX > > But that fail. Works for me, Yannick. I am using STUN through a NAT router. Alan > > Regards, > Yannick > -- > Me joindre en t?l?phonie IP / vid?oconf?rence ? > sip:yannick at ekiga.net > > _______________________________________________ > ekiga-list mailing list > ekiga-list at gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list From sevmek at free.fr Sat Nov 4 21:31:59 2006 From: sevmek at free.fr (yannick) Date: Sat, 04 Nov 2006 22:31:59 +0100 Subject: [Ekiga-list] FWD account In-Reply-To: <1162663663.6944.119.camel@achille> References: <1162663663.6944.119.camel@achille> Message-ID: <1162675919.6944.129.camel@achille> Hi, Alan told me my setup is fine. Thank you. I looked in the -d 4 output : (...) SUBSCRIBE sip:80XXXX at fwd.pulver.com SIP/2.0 <- The number is correct, i just hide the end here... (...) SIP/2.0 100 Trying (...) SIP/2.0 404 No Such User Here (...) SIP/2.0 100 Trying (...) SIP/2.0 401 Unauthorized (...) Seems the problem is in their database... I've no luck... Maybe it takes some times to update their database, i'll give a try tomorrow. Yannick Le samedi 04 novembre 2006 ? 19:07 +0100, yannick a ?crit : > Hi folks ! > > In order to have a "call me" feature, i'm trying to set up a Free World > Dialup account in Ekiga. I poorly failed. > > Here is my config : > > My Ekiga works great with ekiga.net (no nat or stuffs like that). > > Account window : > Registrar: fwd.pulver.com > User: My number 80XXXX > Password: XXXXXX > > But that fail. > > Regards, > Yannick > -- > Me joindre en t?l?phonie IP / vid?oconf?rence ? > sip:yannick at ekiga.net > > _______________________________________________ > ekiga-list mailing list > ekiga-list at gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list -- Me joindre en t?l?phonie IP / vid?oconf?rence ? sip:yannick at ekiga.net From bbagger at gmail.com Sun Nov 5 08:59:22 2006 From: bbagger at gmail.com (Bent Bagger) Date: Sun, 5 Nov 2006 09:59:22 +0100 Subject: [Ekiga-list] FWD account In-Reply-To: <1162675919.6944.129.camel@achille> References: <1162663663.6944.119.camel@achille> <1162675919.6944.129.camel@achille> Message-ID: <2e19719f0611050059o3896188aqf78f3c25c4b5883d@mail.gmail.com> Here is my Asterisk setup for FWD (slightly masked): in sip.conf: [general] .... register => 524517:MYPASSWD at fwd.pulver.com/191 ; Register 524517 at Freeworld Dialup as 191 here [fwd-out] type=friend username=524517 secret=MYPASSWD host=fwd.pulver.com insecure=very ; required for incoming FWD calls and in extensions.conf: [home] .... ; Call a number at Free World Dialup exten => _91.,1,Dial(SIP/fwd-out/${EXTEN:2},20,r)) I use the 91 prefix for FWD (Ekiga.net is 99) Yannick, there is no reason to hide your FWD number, it is in their White Pages. The last two digits of your number is 53 Bent From geboyd53 at comcast.net Sun Nov 5 11:25:58 2006 From: geboyd53 at comcast.net (George Boyd) Date: Sun, 05 Nov 2006 03:25:58 -0800 Subject: [Ekiga-list] Ekiga and FWD Message-ID: <1162725958.5920.4.camel@george> Can anyone on the list please advice me on how to set up FWD on ekiga to receive incoming calls from the forward network and also how to use it to call yahoo, MSN, etc contacts from forward using Ekiga? I've looked at the forward help, but it doesn't tell how to do it from ekiga. Thanks, George From dsandras at seconix.com Sun Nov 5 11:33:21 2006 From: dsandras at seconix.com (Damien Sandras) Date: Sun, 05 Nov 2006 12:33:21 +0100 Subject: [Ekiga-list] Ekiga and FWD In-Reply-To: <1162725958.5920.4.camel@george> References: <1162725958.5920.4.camel@george> Message-ID: <1162726401.4839.4.camel@golgoth01> Le dimanche 05 novembre 2006 ? 03:25 -0800, George Boyd a ?crit : > Can anyone on the list please advice me on how to set up FWD on ekiga to > receive incoming calls from the forward network and also how to use it > to call yahoo, MSN, etc contacts from forward using Ekiga? > Yahoo and MSN do not work with SIP. So I don't think it is possible, sorry. > I've looked at the forward help, but it doesn't tell how to do it from > ekiga. > > Thanks, > George > > _______________________________________________ > ekiga-list mailing list > ekiga-list at gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list -- Damien Sandras Ekiga Softphone : http://www.ekiga.org NOVACOM : http://www.novacom.be FOSDEM : http://www.fosdem.org SIP Phone : sip:dsandras at ekiga.net From geboyd53 at comcast.net Sun Nov 5 11:35:16 2006 From: geboyd53 at comcast.net (George Boyd) Date: Sun, 05 Nov 2006 03:35:16 -0800 Subject: [Ekiga-list] Ekiga and FWD In-Reply-To: <1162726401.4839.4.camel@golgoth01> References: <1162725958.5920.4.camel@george> <1162726401.4839.4.camel@golgoth01> Message-ID: <1162726516.6742.4.camel@george> The new microsoft messenger works with sip, bit my main problem is that I can't receive calls from the FWD network. I'm actually pretty confused about how it works anyway. I have an account and I can check my voice messages from ekiga, but when I use the "call me" test on FWD, ekiga doesn't see it and it sends me an email saying that I missed a call because the user is not online, or something like that. On Sun, 2006-11-05 at 12:33 +0100, Damien Sandras wrote: > Le dimanche 05 novembre 2006 ? 03:25 -0800, George Boyd a ?crit : > > Can anyone on the list please advice me on how to set up FWD on ekiga to > > receive incoming calls from the forward network and also how to use it > > to call yahoo, MSN, etc contacts from forward using Ekiga? > > > > > Yahoo and MSN do not work with SIP. So I don't think it is possible, > sorry. > > > I've looked at the forward help, but it doesn't tell how to do it from > > ekiga. > > > > Thanks, > > George > > > > _______________________________________________ > > ekiga-list mailing list > > ekiga-list at gnome.org > > http://mail.gnome.org/mailman/listinfo/ekiga-list From dsandras at seconix.com Sun Nov 5 15:23:54 2006 From: dsandras at seconix.com (Damien Sandras) Date: Sun, 05 Nov 2006 16:23:54 +0100 Subject: [Ekiga-list] Ekiga and FWD In-Reply-To: <1162726516.6742.4.camel@george> References: <1162725958.5920.4.camel@george> <1162726401.4839.4.camel@golgoth01> <1162726516.6742.4.camel@george> Message-ID: <1162740234.4839.42.camel@golgoth01> Le dimanche 05 novembre 2006 ? 03:35 -0800, George Boyd a ?crit : > The new microsoft messenger works with sip, bit my main problem is that > I can't receive calls from the FWD network. I'm actually pretty confused > about how it works anyway. > > I have an account and I can check my voice messages from ekiga, but when > I use the "call me" test on FWD, ekiga doesn't see it and it sends me an > email saying that I missed a call because the user is not online, or > something like that. > Either you are not registered, or some sort of NAT or firewall is dropping the INVITE message. > > > On Sun, 2006-11-05 at 12:33 +0100, Damien Sandras wrote: > > Le dimanche 05 novembre 2006 ? 03:25 -0800, George Boyd a ?crit : > > > Can anyone on the list please advice me on how to set up FWD on ekiga to > > > receive incoming calls from the forward network and also how to use it > > > to call yahoo, MSN, etc contacts from forward using Ekiga? > > > > > > > > > Yahoo and MSN do not work with SIP. So I don't think it is possible, > > sorry. > > > > > I've looked at the forward help, but it doesn't tell how to do it from > > > ekiga. > > > > > > Thanks, > > > George > > > > > > _______________________________________________ > > > ekiga-list mailing list > > > ekiga-list at gnome.org > > > http://mail.gnome.org/mailman/listinfo/ekiga-list > > _______________________________________________ > ekiga-list mailing list > ekiga-list at gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list -- _ Damien Sandras (o- //\ Ekiga Softphone : http://www.ekiga.org/ v_/_ NOVACOM : http://www.novacom.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsandras at ekiga.net From bbagger at gmail.com Sun Nov 5 15:23:43 2006 From: bbagger at gmail.com (Bent Bagger) Date: Sun, 5 Nov 2006 16:23:43 +0100 Subject: [Ekiga-list] Ekiga.net peering - and 'call me' Message-ID: <2e19719f0611050723u793fcb9fu1d6cd90f6ebc2ce1@mail.gmail.com> Which other SIP network providers does ekiga.net peer with. I have searched but not found anything. I miss a 'call me' feature on ekiga.net but having the possibility to call myself by way of another network may act as a 'poor man's call me'. Best regards, Bent From dsandras at seconix.com Sun Nov 5 15:37:17 2006 From: dsandras at seconix.com (Damien Sandras) Date: Sun, 05 Nov 2006 16:37:17 +0100 Subject: [Ekiga-list] Ekiga.net peering - and 'call me' In-Reply-To: <2e19719f0611050723u793fcb9fu1d6cd90f6ebc2ce1@mail.gmail.com> References: <2e19719f0611050723u793fcb9fu1d6cd90f6ebc2ce1@mail.gmail.com> Message-ID: <1162741037.27195.2.camel@golgoth01> Le dimanche 05 novembre 2006 ? 16:23 +0100, Bent Bagger a ?crit : > Which other SIP network providers does ekiga.net peer with. I have > searched but not found anything. > > I miss a 'call me' feature on ekiga.net but having the possibility to > call myself by way of another network may act as a 'poor man's call > me'. > Do you propose yourself to code the "rich man's call me" and implement peering? The software we are using is a combination of SER and Asterisk. And unfortunately, I don't have the time to improve the situation right now, or I would have to cancel the development of Ekiga for a few weeks, which is not a good idea. The mailing list, the bugzilla (mainly due to the unstable Edgy that was released a few days ago), the website, the documentation, Ekiga itself, ekiga.net are taking a lot of time, and unfortunately my spare time is not extensible. So if a few of you want to propose their help in some areas (not necessarily coding), they are welcome! -- Damien Sandras Ekiga Softphone : http://www.ekiga.org NOVACOM : http://www.novacom.be FOSDEM : http://www.fosdem.org SIP Phone : sip:dsandras at ekiga.net From sevmek at free.fr Sun Nov 5 17:57:35 2006 From: sevmek at free.fr (yannick) Date: Sun, 05 Nov 2006 18:57:35 +0100 Subject: [Ekiga-list] Ekiga.net peering - and 'call me' In-Reply-To: <1162741037.27195.2.camel@golgoth01> References: <2e19719f0611050723u793fcb9fu1d6cd90f6ebc2ce1@mail.gmail.com> <1162741037.27195.2.camel@golgoth01> Message-ID: <1162749455.6944.147.camel@achille> Le dimanche 05 novembre 2006 ? 16:37 +0100, Damien Sandras a ?crit : > Le dimanche 05 novembre 2006 ? 16:23 +0100, Bent Bagger a ?crit : > > Which other SIP network providers does ekiga.net peer with. I have > > searched but not found anything. Hi Bent, I've put some informations about this here in french. http://doc.ubuntu-fr.org//applications/ekiga#communications_avec_les_telephones_fixesmobiles If you have interest in one provider in particular, I can translate here. But be aware, this came mostly from writings I found on the net. There is no quality assurance. > > > > I miss a 'call me' feature on ekiga.net but having the possibility to > > call myself by way of another network may act as a 'poor man's call > > me'. > > > > Do you propose yourself to code the "rich man's call me" and implement > peering? > > The software we are using is a combination of SER and Asterisk. > > And unfortunately, I don't have the time to improve the situation right > now, or I would have to cancel the development of Ekiga for a few weeks, > which is not a good idea. > > The mailing list, the bugzilla (mainly due to the unstable Edgy that was > released a few days ago), the website, the documentation, Ekiga itself, > ekiga.net are taking a lot of time, and unfortunately my spare time is > not extensible. > Damien, I proposed you to do some work on the design of ekiga.net, using the template system of SER, but since Bent and I are working on some documentation about asterisk+ekiga, I've delayed this to later. We should be able to provide how-to install asterisk (i've compiled it libpri+zaptel modules+asterisk, not particularly difficult) / use asterisk in a LAN on the router / use asterisk as a local gateway (ekiga and asterisk on the same machine). We will probably need more work on NAT issues. Currently we have problems with incoming calls from ekiga.net. Regards, Yannick > So if a few of you want to propose their help in some areas (not > necessarily coding), they are welcome! -- Me joindre en t?l?phonie IP / vid?oconf?rence ? sip:yannick at ekiga.net From dsandras at seconix.com Sun Nov 5 18:12:07 2006 From: dsandras at seconix.com (Damien Sandras) Date: Sun, 05 Nov 2006 19:12:07 +0100 Subject: [Ekiga-list] Ekiga.net peering - and 'call me' In-Reply-To: <1162749455.6944.147.camel@achille> References: <2e19719f0611050723u793fcb9fu1d6cd90f6ebc2ce1@mail.gmail.com> <1162741037.27195.2.camel@golgoth01> <1162749455.6944.147.camel@achille> Message-ID: <1162750328.4510.4.camel@golgoth01> Le dimanche 05 novembre 2006 ? 18:57 +0100, yannick a ?crit : > > The mailing list, the bugzilla (mainly due to the unstable Edgy that was > > released a few days ago), the website, the documentation, Ekiga itself, > > ekiga.net are taking a lot of time, and unfortunately my spare time is > > not extensible. > > > > Damien, I proposed you to do some work on the design of ekiga.net, using > the template system of SER, but since Bent and I are working on some > documentation about asterisk+ekiga, I've delayed this to later. > Yes, Yannick. We are missing more guys like you. Thanks for your great work on the documentation! -- Damien Sandras Ekiga Softphone : http://www.ekiga.org NOVACOM : http://www.novacom.be FOSDEM : http://www.fosdem.org SIP Phone : sip:dsandras at ekiga.net From sevmek at free.fr Sun Nov 5 18:32:00 2006 From: sevmek at free.fr (yannick) Date: Sun, 05 Nov 2006 19:32:00 +0100 Subject: [Ekiga-list] FWD account In-Reply-To: <2e19719f0611050059o3896188aqf78f3c25c4b5883d@mail.gmail.com> References: <1162663663.6944.119.camel@achille> <1162675919.6944.129.camel@achille> <2e19719f0611050059o3896188aqf78f3c25c4b5883d@mail.gmail.com> Message-ID: <1162751521.6944.151.camel@achille> Thank you. I'll try it when i'll have more spar time ;) You're probably right about my FWD number, but as i receive large number of calls on my ekiga account, i was just willing to show people I don't want them to use this one. bah. useless probably. Regards, Yannick Le dimanche 05 novembre 2006 ? 09:59 +0100, Bent Bagger a ?crit : > Here is my Asterisk setup for FWD (slightly masked): > > in sip.conf: > > [general] > .... > register => 524517:MYPASSWD at fwd.pulver.com/191 ; Register 524517 at > Freeworld Dialup as 191 here > > [fwd-out] > type=friend > username=524517 > secret=MYPASSWD > host=fwd.pulver.com > insecure=very ; required for incoming FWD calls > > > and in extensions.conf: > > [home] > .... > ; Call a number at Free World Dialup > exten => _91.,1,Dial(SIP/fwd-out/${EXTEN:2},20,r)) > > I use the 91 prefix for FWD (Ekiga.net is 99) > > > Yannick, there is no reason to hide your FWD number, it is in their > White Pages. The last two digits of your number is 53 > > Bent > _______________________________________________ > ekiga-list mailing list > ekiga-list at gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list > -- Me joindre en t?l?phonie IP / vid?oconf?rence ? sip:yannick at ekiga.net From bbagger at gmail.com Sun Nov 5 20:14:17 2006 From: bbagger at gmail.com (Bent Bagger) Date: Sun, 5 Nov 2006 21:14:17 +0100 Subject: [Ekiga-list] FWD account In-Reply-To: <1162751521.6944.151.camel@achille> References: <1162663663.6944.119.camel@achille> <1162675919.6944.129.camel@achille> <2e19719f0611050059o3896188aqf78f3c25c4b5883d@mail.gmail.com> <1162751521.6944.151.camel@achille> Message-ID: <2e19719f0611051214u29b44d06jff021ba5249ff1d2@mail.gmail.com> Hi Yannick On 05/11/06, yannick wrote: > > You're probably right about my FWD number, but as i receive large number > of calls on my ekiga account, i was just willing to show people I don't > want them to use this one. bah. useless probably. > I didn't know your were in that situation. I understand your attitude perfectly now. When I wrote about peering and 'call me' I hand in mind a situation where I could use my FWD account to call my ekiga number - had there been peering between FWD and ekiga.net. This would make it possible for me to call myself without my having to disturb good people like you and ask you to help me. Best regards, Bent From simon at mungewell.org Sat Nov 4 19:25:42 2006 From: simon at mungewell.org (simon) Date: Sat, 04 Nov 2006 12:25:42 -0700 Subject: [Ekiga-list] FWD account In-Reply-To: <2e19719f0611051214u29b44d06jff021ba5249ff1d2@mail.gmail.com> References: <1162663663.6944.119.camel@achille> <1162675919.6944.129.camel@achille> <2e19719f0611050059o3896188aqf78f3c25c4b5883d@mail.gmail.com> <1162751521.6944.151.camel@achille> <2e19719f0611051214u29b44d06jff021ba5249ff1d2@mail.gmail.com> Message-ID: <20061104192542.GA20979@mungewell.org> On Sun, Nov 05, 2006 at 09:14:17PM +0100, Bent Bagger wrote: > > When I wrote about peering and 'call me' I hand in mind a situation > where I could use my FWD account to call my ekiga number - had there > been peering between FWD and ekiga.net. This would make it possible > for me to call myself without my having to disturb good people like > you and ask you to help me. > Hi Bent, You can call from FWD to Ekiga.net, via SipBroker. Dial: '**275*673' If you're calling from/to the same location (without using a proxy somewhere on the internet) then the call will be set up, but the audio/rtp stream will fail as the softphones will be attempting to talk to your public IP. Hope this helps, Simon From jonny.strom at netikka.fi Mon Nov 6 08:47:30 2006 From: jonny.strom at netikka.fi (=?ISO-8859-1?Q?johnny_Str=F6m?=) Date: Mon, 06 Nov 2006 10:47:30 +0200 Subject: [Ekiga-list] Fedora Binaries for Ekiga In-Reply-To: <1162507889.3581.4.camel@c-71-193-191-8.hsd1.wa.comcast.net> References: <1162507889.3581.4.camel@c-71-193-191-8.hsd1.wa.comcast.net> Message-ID: <454EF6A2.6080402@netikka.fi> George Boyd wrote: > I had offered a while back to help making the fedora binaries and > someone answered me. But after an arduous time of installing Fedora Core > 6, in the process I lost my email. > > I am now up and running again, so I can help. If the person who replied > to me before would send me another email, I can get started. They will > be Fedora Core 6 binaries, don't know if that matters or not. > Hello It was me who offered to help I have an build script here it is wery hacky one :) Do you want I can send it by email to you. Cheers Johnny > George > > _______________________________________________ > ekiga-list mailing list > ekiga-list at gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list > From rankincj at yahoo.com Mon Nov 6 08:54:13 2006 From: rankincj at yahoo.com (Chris Rankin) Date: Mon, 6 Nov 2006 08:54:13 +0000 (GMT) Subject: [Ekiga-list] Fedora Binaries for Ekiga In-Reply-To: <454EF6A2.6080402@netikka.fi> Message-ID: <20061106085413.72051.qmail@web52901.mail.yahoo.com> George Boyd wrote: > They will be Fedora Core 6 binaries, don't know if that matters or not. So long as SRPMs are also available, it doesn't matter if the RPMs are for FC6 only. Cheers, Chris Send instant messages to your online friends http://uk.messenger.yahoo.com From bbagger at gmail.com Mon Nov 6 22:24:00 2006 From: bbagger at gmail.com (Bent Bagger) Date: Mon, 6 Nov 2006 23:24:00 +0100 Subject: [Ekiga-list] FWD account In-Reply-To: <20061104192542.GA20979@mungewell.org> References: <1162663663.6944.119.camel@achille> <1162675919.6944.129.camel@achille> <2e19719f0611050059o3896188aqf78f3c25c4b5883d@mail.gmail.com> <1162751521.6944.151.camel@achille> <2e19719f0611051214u29b44d06jff021ba5249ff1d2@mail.gmail.com> <20061104192542.GA20979@mungewell.org> Message-ID: <2e19719f0611061424hd39e334xd5be054e9ec145e3@mail.gmail.com> Hi Simon > > Dial: '**275*673' > Asterisk said this when I tried: -- Executing Dial("SIP/191-082985c0", "SIP/fwd-out/**275*673652501|20|r)") in new stack -- Called fwd-out/**275*673652501 -- Got SIP response 482 "Loop Detected" back from 69.90.155.70 which is the same I get when I call my ekiga.net (or FWD) number directly. (69.90.155.70 is fwd.pulver.com) So I guess it is back to square one... Thanks for your help anyway. Best regards, Bent From dsandras at seconix.com Mon Nov 6 22:34:25 2006 From: dsandras at seconix.com (Damien Sandras) Date: Mon, 06 Nov 2006 23:34:25 +0100 Subject: [Ekiga-list] FWD account In-Reply-To: <2e19719f0611061424hd39e334xd5be054e9ec145e3@mail.gmail.com> References: <1162663663.6944.119.camel@achille> <1162675919.6944.129.camel@achille> <2e19719f0611050059o3896188aqf78f3c25c4b5883d@mail.gmail.com> <1162751521.6944.151.camel@achille> <2e19719f0611051214u29b44d06jff021ba5249ff1d2@mail.gmail.com> <20061104192542.GA20979@mungewell.org> <2e19719f0611061424hd39e334xd5be054e9ec145e3@mail.gmail.com> Message-ID: <1162852465.3890.46.camel@golgoth01> Le lundi 06 novembre 2006 ? 23:24 +0100, Bent Bagger a ?crit : > Hi Simon > > > > > Dial: '**275*673' > > > Asterisk said this when I tried: > > -- Executing Dial("SIP/191-082985c0", > "SIP/fwd-out/**275*673652501|20|r)") in new stack > -- Called fwd-out/**275*673652501 > -- Got SIP response 482 "Loop Detected" back from 69.90.155.70 > > which is the same I get when I call my ekiga.net (or FWD) number directly. > > (69.90.155.70 is fwd.pulver.com) > > So I guess it is back to square one... > Try from ekiga. -- Damien Sandras Ekiga Softphone : http://www.ekiga.org NOVACOM : http://www.novacom.be FOSDEM : http://www.fosdem.org SIP Phone : sip:dsandras at ekiga.net From simon at mungewell.org Sun Nov 5 16:50:13 2006 From: simon at mungewell.org (simon) Date: Sun, 05 Nov 2006 09:50:13 -0700 Subject: [Ekiga-list] FWD account In-Reply-To: <2e19719f0611061424hd39e334xd5be054e9ec145e3@mail.gmail.com> References: <1162663663.6944.119.camel@achille> <1162675919.6944.129.camel@achille> <2e19719f0611050059o3896188aqf78f3c25c4b5883d@mail.gmail.com> <1162751521.6944.151.camel@achille> <2e19719f0611051214u29b44d06jff021ba5249ff1d2@mail.gmail.com> <20061104192542.GA20979@mungewell.org> <2e19719f0611061424hd39e334xd5be054e9ec145e3@mail.gmail.com> Message-ID: <20061105165013.GA27803@mungewell.org> This sounds like Asterisk is detecting the problem that you are call from and to the same IP address (your public/external IP address). I have used this technique to call from a HardIP phone (on FWD) to a Softphone (Ekiga on Ekiga.net), both located on a local NAT'ed network. The call was sucessfully setup (Ekiga 'Rings'), but RTP stream fails. Another thing that might help is that I have 'moved' the ports that the hardphone(s) uses so that I can have multiple phones behind one router. Simon On Mon, Nov 06, 2006 at 11:24:00PM +0100, Bent Bagger wrote: > Hi Simon > > > > >Dial: '**275*673' > > > Asterisk said this when I tried: > > -- Executing Dial("SIP/191-082985c0", > "SIP/fwd-out/**275*673652501|20|r)") in new stack > -- Called fwd-out/**275*673652501 > -- Got SIP response 482 "Loop Detected" back from 69.90.155.70 > > which is the same I get when I call my ekiga.net (or FWD) number directly. > > (69.90.155.70 is fwd.pulver.com) > > So I guess it is back to square one... > > Thanks for your help anyway. > > Best regards, > > Bent From prakashb at tataelxsi.co.in Tue Nov 7 05:11:40 2006 From: prakashb at tataelxsi.co.in (Prakash B) Date: Tue, 7 Nov 2006 10:41:40 +0530 (IST) Subject: [Ekiga-list] problem while starting the ekiga Message-ID: <20061107104140.CBW95995@mail.tataelxsi.co.in> I am using linux FC5. I have installed ekiga. While starting, it gave error as " The Application "ekiga" has quit unexpectedly. You can inform the developers of what happened to help them fix it. Or you can restart the application right now" and asking me to quit me the application. also in the terminal its coming as " It appears that you do not have ekiga.server installed in a valid location. Factory mode disabled." help me please. thanks in advance. - prakash From jan.schampera at web.de Tue Nov 7 05:27:07 2006 From: jan.schampera at web.de (Jan Schampera) Date: Tue, 7 Nov 2006 06:27:07 +0100 Subject: [Ekiga-list] problem while starting the ekiga In-Reply-To: <20061107104140.CBW95995@mail.tataelxsi.co.in> References: <20061107104140.CBW95995@mail.tataelxsi.co.in> Message-ID: <20061107062707.3f7f67d4@localhost.localdomain> On Tue, 7 Nov 2006 10:41:40 +0530 (IST) Prakash B wrote: > > I am using linux FC5. > I have installed ekiga. While starting, it gave error as > " The Application "ekiga" has quit unexpectedly. > You can inform the developers of what happened to help them fix it. > Or you can restart the application right now" and asking me to quit > me the application. That's the so-called bug-buddy, a dialog that appears on a crash. Gnome stuff. You can: - install gdb (GNU debugger) - run in a shell terminal: gdb $(which ekiga) - on gdb prompt: run - when it crashes, on gdb prompt: thread apply all bt - mail the output (a backtrace, hopefully without unknown symbols) > also in the terminal its coming as > " It appears that you do not have ekiga.server installed in a valid > location. Factory mode disabled." Shouldn't be related to a crash. J. -- "One of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs" --Robert Firth From prakashb at tataelxsi.co.in Tue Nov 7 10:51:18 2006 From: prakashb at tataelxsi.co.in (Prakash B) Date: Tue, 7 Nov 2006 16:21:18 +0530 (IST) Subject: [Ekiga-list] problem while starting the ekiga Message-ID: <20061107162118.CBX45136@mail.tataelxsi.co.in> while running ekiga in gdb, its giving as " Starting program: /usr/local/bin/ekiga Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0xaba000 [Thread debugging using libthread_db enabled] [New Thread -1208858960 (LWP 9347)] It appears that you do not have ekiga.server installed in a valid location. Factory mode disabled. [New Thread -1210958944 (LWP 9350)] [New Thread -1211225184 (LWP 9351)] Program received signal SIG33, Real-time event 33. [Switching to Thread -1211225184 (LWP 9351)] 0x00aba402 in __kernel_vsyscall () at /usr/local/include/ptclib/http.h:494 warning: Source file is more recent than executable. " help pls. thanks. - prakash From erik at epo.dk Tue Nov 7 17:14:30 2006 From: erik at epo.dk (Erik P. Olsen) Date: Tue, 07 Nov 2006 18:14:30 +0100 Subject: [Ekiga-list] Newbie getting started problem. Message-ID: <4550BEF6.3030305@epo.dk> I am trying to setup Ekiga so that I can communicate with other PC-users, in particular my daughter in New Zealand. She is on Windows XP and I am on Linux (Fedora Core 5). Is there a piece of documentation which step-by-step explains how to setup Ekiga especially for communication between the Linux and Windows worlds? A documentation I could start reading before asking silly questions? Thanks, -- Erik P. Olsen, Civilingeni?r, MSc Solsortvej 30, DK-2000 Frederiksberg, Denmark Phone: +45 38346480, Fax: +45 20655783, Mobil: +45 40765300 From jan.schampera at web.de Tue Nov 7 17:28:27 2006 From: jan.schampera at web.de (Jan Schampera) Date: Tue, 7 Nov 2006 18:28:27 +0100 Subject: [Ekiga-list] Newbie getting started problem. In-Reply-To: <4550BEF6.3030305@epo.dk> References: <4550BEF6.3030305@epo.dk> Message-ID: <20061107182827.60ac1675@localhost.localdomain> On Tue, 07 Nov 2006 18:14:30 +0100 "Erik P. Olsen" wrote: > I am trying to setup Ekiga so that I can communicate with other > PC-users, in particular my daughter in New Zealand. She is on Windows > XP and I am on Linux (Fedora Core 5). Is there a piece of > documentation which step-by-step explains how to setup Ekiga > especially for communication between the Linux and Windows worlds? A > documentation I could start reading before asking silly questions? You need a SIP client on the other side, no matter which operating system. Soon you can use Ekiga/WIN32. Check: http://wiki.ekiga.org/index.php/Wich_programs_work_with_Ekiga_%3F J. -- Live as if you were to die tomorrow. Learn as if you were to live forever. From erik at epo.dk Tue Nov 7 21:30:07 2006 From: erik at epo.dk (Erik P. Olsen) Date: Tue, 07 Nov 2006 22:30:07 +0100 Subject: [Ekiga-list] Newbie getting started problem. In-Reply-To: <20061107182827.60ac1675@localhost.localdomain> References: <4550BEF6.3030305@epo.dk> <20061107182827.60ac1675@localhost.localdomain> Message-ID: <4550FADF.4040008@epo.dk> Jan Schampera wrote: > On Tue, 07 Nov 2006 18:14:30 +0100 > "Erik P. Olsen" wrote: > >> I am trying to setup Ekiga so that I can communicate with other >> PC-users, in particular my daughter in New Zealand. She is on Windows >> XP and I am on Linux (Fedora Core 5). Is there a piece of >> documentation which step-by-step explains how to setup Ekiga >> especially for communication between the Linux and Windows worlds? A >> documentation I could start reading before asking silly questions? > > You need a SIP client on the other side, no matter which operating > system. Soon you can use Ekiga/WIN32. Check: > http://wiki.ekiga.org/index.php/Wich_programs_work_with_Ekiga_%3F Interesting site. It looks like Windows Messenger (I assume it's MSN Messenger) can work with Ekiga but I don't understand what the various accronyms stand for :-( Regards, -- Erik P. Olsen, Civilingeni?r, MSc Solsortvej 30, DK-2000 Frederiksberg, Denmark Phone: +45 38346480, Fax: +45 20655783, Mobil: +45 40765300 From typhoon at aanet.com.au Tue Nov 7 21:34:23 2006 From: typhoon at aanet.com.au (Typhoon) Date: Wed, 8 Nov 2006 08:34:23 +1100 Subject: [Ekiga-list] Newbie getting started problem. In-Reply-To: <4550BEF6.3030305@epo.dk> References: <4550BEF6.3030305@epo.dk> Message-ID: <20061108083423.a4fb690a.typhoon@aanet.com.au> On Tue, 07 Nov 2006 18:14:30 +0100 "Erik P. Olsen" wrote: > I am trying to setup Ekiga so that I can communicate with other > PC-users, in particular my daughter in New Zealand. She is on Windows > XP and I am on Linux (Fedora Core 5). Is there a piece of > documentation which step-by-step explains how to setup Ekiga > especially for communication between the Linux and Windows worlds? A > documentation I could start reading before asking silly questions? Hi Erik, I talk from Australia with my daughter in the USA all the time. She uses Gizmo on a Windows machine. I have found it easiest to set up a Gizmo account for myself as well. Ekiga works very well with it. You can't do Ekiga <-> Gizmo instant messages, but if that is important to you, Gaim works well with the Gizmo client. HTH, Alan > > Thanks, > -- > Erik P. Olsen, Civilingeni?r, MSc > Solsortvej 30, DK-2000 Frederiksberg, Denmark > Phone: +45 38346480, Fax: +45 20655783, Mobil: +45 40765300 > _______________________________________________ > ekiga-list mailing list > ekiga-list at gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list > From jan.schampera at web.de Wed Nov 8 05:00:05 2006 From: jan.schampera at web.de (Jan Schampera) Date: Wed, 8 Nov 2006 06:00:05 +0100 Subject: [Ekiga-list] Newbie getting started problem. In-Reply-To: <4550FADF.4040008@epo.dk> References: <4550BEF6.3030305@epo.dk> <20061107182827.60ac1675@localhost.localdomain> <4550FADF.4040008@epo.dk> Message-ID: <20061108060005.3313e4a4@localhost.localdomain> On Tue, 07 Nov 2006 22:30:07 +0100 "Erik P. Olsen" wrote: > Interesting site. It looks like Windows Messenger (I assume it's MSN > Messenger) can work with Ekiga Windows Messenger != MSN Messenger, two different programs. > but I don't understand what the > various accronyms stand for :-( Yes, good argument, if we have time, we write sub-pages to explain them or make links to external sites (Wikipedia?), mostly that are codec names and protocol names, from what I can see now. J. -- God is real... unless declared as integer. From geboyd53 at comcast.net Wed Nov 8 08:19:49 2006 From: geboyd53 at comcast.net (George Boyd) Date: Wed, 08 Nov 2006 00:19:49 -0800 Subject: [Ekiga-list] Hi Damien And The Group In-Reply-To: <1162852465.3890.46.camel@golgoth01> References: <1162663663.6944.119.camel@achille> <1162675919.6944.129.camel@achille> <2e19719f0611050059o3896188aqf78f3c25c4b5883d@mail.gmail.com> <1162751521.6944.151.camel@achille> <2e19719f0611051214u29b44d06jff021ba5249ff1d2@mail.gmail.com> <20061104192542.GA20979@mungewell.org> <2e19719f0611061424hd39e334xd5be054e9ec145e3@mail.gmail.com> <1162852465.3890.46.camel@golgoth01> Message-ID: <1162973989.7768.8.camel@c-71-193-191-8.hsd1.wa.comcast.net> It sure has been quite on this group, is that good or bad news? Damien, I thought you may like to know about the problem I was having with the distorted and "helicopter" sound using Ekiga and Fedora. Today I noticed that when I installed Fedora Core 6, that it mistakenly installed the i586 kernel instead of the i686 kernel. I removed the i586 kernel and installed the i686 one and was able to make the first successful (and clear) call using Ekiga through VoIP Buster to a land line. I don't know what the difference is between them, but I was able to make the call with a reasonable amount of jitter buffer and clear. I don't know if this will help anyone else or not, but it made a big difference here. Take Care, George From sevmek at free.fr Wed Nov 8 09:01:06 2006 From: sevmek at free.fr (yannick) Date: Wed, 08 Nov 2006 10:01:06 +0100 Subject: [Ekiga-list] Newbie getting started problem. In-Reply-To: <20061108060005.3313e4a4@localhost.localdomain> References: <4550BEF6.3030305@epo.dk> <20061107182827.60ac1675@localhost.localdomain> <4550FADF.4040008@epo.dk> <20061108060005.3313e4a4@localhost.localdomain> Message-ID: <1162976467.17666.14.camel@achille> Le mercredi 08 novembre 2006 ? 06:00 +0100, Jan Schampera a ?crit : > > but I don't understand what the > > various accronyms stand for :-( > Yes, good argument, if we have time, we write sub-pages to explain > them or make links to external sites (Wikipedia?), mostly that are > codec > names and protocol names, from what I can see now. Thru. IMHO, first we should spilt protocols and codecs in the table (by adding a colomn "protocols"), then document both of them (Jan, wikipedia seems good idea for that as hyperlinks won't bloat the table !). Thank you for the feedback. I'll change that soon when i'll have more spar time. Regards, Yannick -- Me joindre en t?l?phonie IP / vid?oconf?rence ? sip:yannick at ekiga.net From sevmek at free.fr Wed Nov 8 09:16:54 2006 From: sevmek at free.fr (yannick) Date: Wed, 08 Nov 2006 10:16:54 +0100 Subject: [Ekiga-list] Newbie getting started problem. In-Reply-To: <20061108083423.a4fb690a.typhoon@aanet.com.au> References: <4550BEF6.3030305@epo.dk> <20061108083423.a4fb690a.typhoon@aanet.com.au> Message-ID: <1162977414.17666.17.camel@achille> Le mercredi 08 novembre 2006 ? 08:34 +1100, Typhoon a ?crit : > You can't do Ekiga <-> Gizmo instant messages, but if that is > important > to you, Gaim works well with the Gizmo client. Here is a list of working clients with Gizmo for instant messages (and presence probably) : http://www.imfederation.com/software.html Regards, Yannick -- Me joindre en t?l?phonie IP / vid?oconf?rence ? sip:yannick at ekiga.net From dsandras at seconix.com Wed Nov 8 09:45:13 2006 From: dsandras at seconix.com (Damien Sandras) Date: Wed, 08 Nov 2006 10:45:13 +0100 Subject: [Ekiga-list] Hi Damien And The Group In-Reply-To: <1162973989.7768.8.camel@c-71-193-191-8.hsd1.wa.comcast.net> References: <1162663663.6944.119.camel@achille> <1162675919.6944.129.camel@achille> <2e19719f0611050059o3896188aqf78f3c25c4b5883d@mail.gmail.com> <1162751521.6944.151.camel@achille> <2e19719f0611051214u29b44d06jff021ba5249ff1d2@mail.gmail.com> <20061104192542.GA20979@mungewell.org> <2e19719f0611061424hd39e334xd5be054e9ec145e3@mail.gmail.com> <1162852465.3890.46.camel@golgoth01> <1162973989.7768.8.camel@c-71-193-191-8.hsd1.wa.comcast.net> Message-ID: <1162979113.4614.10.camel@golgoth01> Le mercredi 08 novembre 2006 ? 00:19 -0800, George Boyd a ?crit : > It sure has been quite on this group, is that good or bad news? I would say good news. There is a bug in GNOME affecting Ekiga on Edgy, and believe me, the bugzilla has been too much active ;-) > > Damien, I thought you may like to know about the problem I was having > with the distorted and "helicopter" sound using Ekiga and Fedora. Today > I noticed that when I installed Fedora Core 6, that it mistakenly > installed the i586 kernel instead of the i686 kernel. I removed the i586 > kernel and installed the i686 one and was able to make the first > successful (and clear) call using Ekiga through VoIP Buster to a land > line. > > I don't know what the difference is between them, but I was able to make > the call with a reasonable amount of jitter buffer and clear. I don't > know if this will help anyone else or not, but it made a big difference > here. Thank you for the feedback! That is weird however, as a behavior. -- Damien Sandras Ekiga Softphone : http://www.ekiga.org NOVACOM : http://www.novacom.be FOSDEM : http://www.fosdem.org SIP Phone : sip:dsandras at ekiga.net From sevmek at free.fr Wed Nov 8 11:27:17 2006 From: sevmek at free.fr (yannick) Date: Wed, 08 Nov 2006 12:27:17 +0100 Subject: [Ekiga-list] Hi Damien And The Group In-Reply-To: <1162979113.4614.10.camel@golgoth01> References: <1162663663.6944.119.camel@achille> <1162675919.6944.129.camel@achille> <2e19719f0611050059o3896188aqf78f3c25c4b5883d@mail.gmail.com> <1162751521.6944.151.camel@achille> <2e19719f0611051214u29b44d06jff021ba5249ff1d2@mail.gmail.com> <20061104192542.GA20979@mungewell.org> <2e19719f0611061424hd39e334xd5be054e9ec145e3@mail.gmail.com> <1162852465.3890.46.camel@golgoth01> <1162973989.7768.8.camel@c-71-193-191-8.hsd1.wa.comcast.net> <1162979113.4614.10.camel@golgoth01> Message-ID: <1162985237.17666.40.camel@achille> Le mercredi 08 novembre 2006 ? 10:45 +0100, Damien Sandras a ?crit : > > It sure has been quite on this group, is that good or bad news? > > I would say good news. George, As an old timer user of ekiga, this may interest you : I'm giving time to support the french ubuntu community (especially in the french forum/french documentation, and believe me : most of time i can fix problems there and i'm involved in all threads related to ekiga. I'm even starting to help using -d 4 output !) and some on the english documentation for ubuntu (but much more work has to be done in this area, especially in forums). We have also done some work on the wiki.ekiga.org (compiling/interoperabilty/sound problems mostly). I'm the author of this : https://help.ubuntu.com/community/Ekiga http://doc.ubuntu-fr.org/applications/ekiga (the far more complet documentation I'm aware of for one distro...) http://wiki.ekiga.org/index.php/Which_programs_work_with_Ekiga_%3F http://wiki.ekiga.org/index.php/Getting_several_applications_using_the_sound_card_at_the_same_time_%3F (part of it, with damien) As far as I know, all this documentations adress commonly asked questions about ekiga. Of course, lot of work has still to be done, and people willing to help are welcome and blessed by me ;) This is something I've planned : having general doc on wiki.ekiga.org, distro specific doc on their help platform if any (but as a single person, i only support my distro : ubuntu.) Beside that, i do not recommend ubuntu edgy to be used with ekiga... Forget it, better use dapper which is LTS (Long Time Support, and this tag really means something in the ubuntu dev process!) Let's hope the more we document, the less we will have complains ;) Regards, Yannick -- Me joindre en t?l?phonie IP / vid?oconf?rence ? sip:yannick at ekiga.net From prakashb at tataelxsi.co.in Wed Nov 8 13:57:15 2006 From: prakashb at tataelxsi.co.in (Prakash B) Date: Wed, 8 Nov 2006 19:27:15 +0530 Subject: [Ekiga-list] problem while starting the ekiga In-Reply-To: <20061107162118.CBX45136@mail.tataelxsi.co.in> Message-ID: <000201c7033d$cc8009a0$54a9c5cb@telxsi.com> i am having the error still. what can i do for " ekiga.server to be installed in proper location" ? help me please - prakash. -----Original Message----- From: ekiga-list-bounces at gnome.org [mailto:ekiga-list-bounces at gnome.org]On Behalf Of Prakash B Sent: Tuesday, November 07, 2006 4:21 PM To: Ekiga mailing list Subject: Re: [Ekiga-list] problem while starting the ekiga while running ekiga in gdb, its giving as " Starting program: /usr/local/bin/ekiga Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0xaba000 [Thread debugging using libthread_db enabled] [New Thread -1208858960 (LWP 9347)] It appears that you do not have ekiga.server installed in a valid location. Factory mode disabled. [New Thread -1210958944 (LWP 9350)] [New Thread -1211225184 (LWP 9351)] Program received signal SIG33, Real-time event 33. [Switching to Thread -1211225184 (LWP 9351)] 0x00aba402 in __kernel_vsyscall () at /usr/local/include/ptclib/http.h:494 warning: Source file is more recent than executable. " help pls. thanks. - prakash _______________________________________________ ekiga-list mailing list ekiga-list at gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list On Tue, 7 Nov 2006 10:41:40 +0530 (IST) Prakash B wrote: > > I am using linux FC5. > I have installed ekiga. While starting, it gave error as > " The Application "ekiga" has quit unexpectedly. > You can inform the developers of what happened to help them fix it. > Or you can restart the application right now" and asking me to quit > me the application. That's the so-called bug-buddy, a dialog that appears on a crash. Gnome stuff. You can: - install gdb (GNU debugger) - run in a shell terminal: gdb $(which ekiga) - on gdb prompt: run - when it crashes, on gdb prompt: thread apply all bt - mail the output (a backtrace, hopefully without unknown symbols) > also in the terminal its coming as > " It appears that you do not have ekiga.server installed in a valid > location. Factory mode disabled." Shouldn't be related to a crash. J. -- "One of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs" --Robert Firth _______________________________________________ ekiga-list mailing list ekiga-list at gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list From rodney at melecom.com.au Wed Nov 8 23:02:11 2006 From: rodney at melecom.com.au (Rodney Mitchell) Date: Thu, 09 Nov 2006 09:32:11 +1030 Subject: [Ekiga-list] Where is Gnomemeeting.....it worked! Message-ID: <1163026931.4269.14.camel@toshy.melecom.com.au> Hiya to All, Running Fedora this way....and hoping to removed Ekiga and go back to Gnomemeeting which worked very well for VIDEO CONFERENCING. Sad that Ekiga is now crook with FC5...someone was talking about a RPM for FC5, why has Fedora been "left out" ? I did manage to make Ekiga work in FC5, well half work, it refused to find the sound card I/O and the WEBCAM sound too. So...does anyone know how to retro fit Gnomemeeting? Thanks, Rod.` From dsandras at seconix.com Fri Nov 10 09:00:07 2006 From: dsandras at seconix.com (Damien Sandras) Date: Fri, 10 Nov 2006 10:00:07 +0100 Subject: [Ekiga-list] Where is Gnomemeeting.....it worked! In-Reply-To: <1163026931.4269.14.camel@toshy.melecom.com.au> References: <1163026931.4269.14.camel@toshy.melecom.com.au> Message-ID: <1163149207.5706.2.camel@golgoth01> Le jeudi 09 novembre 2006 ? 09:32 +1030, Rodney Mitchell a ?crit : > Hiya to All, > > Running Fedora this way....and hoping to removed Ekiga and go back to > Gnomemeeting which worked very well for VIDEO CONFERENCING. > > Sad that Ekiga is now crook with FC5...someone was talking about a RPM > for FC5, why has Fedora been "left out" ? > > I did manage to make Ekiga work in FC5, well half work, it refused to > find the sound card I/O and the WEBCAM sound too. > > So...does anyone know how to retro fit Gnomemeeting? There is no way. And btw, the code for the H.323 part in ekiga and gnomemeeting is identical. If your problem is that it doesn't find the sound card, or the webcam, then it is a distribution problem (or an user problem). Damien From dsandras at seconix.com Fri Nov 10 09:06:20 2006 From: dsandras at seconix.com (Damien Sandras) Date: Fri, 10 Nov 2006 10:06:20 +0100 Subject: [Ekiga-list] Where is Gnomemeeting.....it worked! In-Reply-To: <1163149207.5706.2.camel@golgoth01> References: <1163026931.4269.14.camel@toshy.melecom.com.au> <1163149207.5706.2.camel@golgoth01> Message-ID: <1163149580.5706.4.camel@golgoth01> Le vendredi 10 novembre 2006 ? 10:00 +0100, Damien Sandras a ?crit : > Le jeudi 09 novembre 2006 ? 09:32 +1030, Rodney Mitchell a ?crit : > > Hiya to All, > > > > Running Fedora this way....and hoping to removed Ekiga and go back to > > Gnomemeeting which worked very well for VIDEO CONFERENCING. > > > > Sad that Ekiga is now crook with FC5...someone was talking about a RPM > > for FC5, why has Fedora been "left out" ? > > > > I did manage to make Ekiga work in FC5, well half work, it refused to > > find the sound card I/O and the WEBCAM sound too. > > > > So...does anyone know how to retro fit Gnomemeeting? > > There is no way. > > And btw, the code for the H.323 part in ekiga and gnomemeeting is > identical. > > If your problem is that it doesn't find the sound card, or the webcam, > then it is a distribution problem (or an user problem). I meant "user configuration problem". No offense. -- Damien Sandras Ekiga Softphone : http://www.ekiga.org NOVACOM : http://www.novacom.be FOSDEM : http://www.fosdem.org SIP Phone : sip:dsandras at ekiga.net From kuschelbug01-ekigalist at yahoo.de Sat Nov 11 16:49:04 2006 From: kuschelbug01-ekigalist at yahoo.de (kuschelbug01-ekigalist at yahoo.de) Date: Sat, 11 Nov 2006 17:49:04 +0100 (CET) Subject: [Ekiga-list] basic NAT problem from fedora core 6 Message-ID: <20061111164904.31250.qmail@web54702.mail.yahoo.com> I am trying to set up ekiga from a fedora core 6 system behind a Linksys WRT54G router. The detection of my NAT type ends up with Symmetric NAT recommending port forwarding. So I set up the router to forward ports 5000-5100 (both TCP and UDP) to my system but the NAT detection still returns Symmetric NAT and not Cone NAT. So I dissabled the Firewall and SE-Linux completly just to get the Symmetric NAT detection again. Am I missing something simple here? I of course have a SIP account, and tried the ekiga setup as the system root without success. Thanks for suggesstions. ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de From jan.schampera at web.de Sat Nov 11 18:35:48 2006 From: jan.schampera at web.de (Jan Schampera) Date: Sat, 11 Nov 2006 19:35:48 +0100 Subject: [Ekiga-list] basic NAT problem from fedora core 6 In-Reply-To: <20061111164904.31250.qmail@web54702.mail.yahoo.com> References: <20061111164904.31250.qmail@web54702.mail.yahoo.com> Message-ID: <20061111193548.0ce24663@localhost.localdomain> On Sat, 11 Nov 2006 17:49:04 +0100 (CET) wrote: "kuschelbug"? heh :) > The detection of my NAT type ends up with Symmetric NAT recommending > port forwarding. So I set up the router to forward ports 5000-5100 > (both TCP and UDP) to my system but the NAT detection still returns > Symmetric NAT and not Cone NAT. So I dissabled the Firewall and > SE-Linux completly just to get the Symmetric NAT detection again. Maybe http://www.ekiga.org/index.php?rub=3&pos=0&faqpage=x161.html helps. It also mentions the ports to forward etc... As far as I can tell, you only forwarded the ports that operate the payload, but not the H.323 or SIP *control* ports. J. -- "Be liberal in what you accept, and conservative in what you send." - J. B. Postel, master of the net. From mariofutire at googlemail.com Sun Nov 12 16:25:34 2006 From: mariofutire at googlemail.com (Mario Rossi) Date: Sun, 12 Nov 2006 16:25:34 +0000 Subject: [Ekiga-list] Poor audio quality Message-ID: <53d94280611120825h44527e1t764cc9d3bb8f9098@mail.gmail.com> Hi I've finally installed ekiga 2.0.3 (compiled from sources) and I've done some testing using the dmix plugin. During the tests I've used no webcam (so to avoid any overload of the system) and tried the echo server of ekiga. Using the direct alsa output, jitter buffer goes at 20 and the quality is very good. In my tests sometimes it increases to 40, most of the times stays at 20. Using the "default" (i.e. dmix) the quality is bad while the jitter buffer increases. In the worst cases it keeps increasing till 500 (very fast), other times it slowly increases, sometimes it stabilises at around 300. Usually (but not always) the quality improves when the jitter stops. If there is an other application playing sond, the growth of the jitter to 500 is usually faster. Sorry about my ignorance, but what is the jitter buffer? How does it interact with dmix and alsa? I've found that using the sound event settings I can have the "ring" with dmix and then before answering I have to stop other applications playing sound, so in my case the limitation of dmix is not really that big, but anyway... Thanks >> >> If I use the hardware directly the quality improves but I still have >> some problems when I set the full screen. >> >> Is there any setting that could affect audio quality? >> >If it happens when you set to fullscreen, you are probably using too >much CPU ressources. >Be careful also that you are perhaps wasting your bandwidth with too >large video transmission or too high settings. >Just check the value of your jitter, it will help a lot to determine if >there is a problem related to CPU/Bandwidth (if it goes over 500ms, then >the problem is at this side, if not, then the problem is on the ALSA >side). From sevmek at free.fr Sun Nov 12 16:56:42 2006 From: sevmek at free.fr (yannick) Date: Sun, 12 Nov 2006 17:56:42 +0100 Subject: [Ekiga-list] Poor audio quality In-Reply-To: <53d94280611120825h44527e1t764cc9d3bb8f9098@mail.gmail.com> References: <53d94280611120825h44527e1t764cc9d3bb8f9098@mail.gmail.com> Message-ID: <1163350602.25028.1.camel@achille> Hi Le dimanche 12 novembre 2006 ? 16:25 +0000, Mario Rossi a ?crit : > Hi > > I've finally installed ekiga 2.0.3 (compiled from sources) and I've > done some testing using the dmix plugin. http://wiki.ekiga.org/index.php/Getting_several_applications_using_the_sound_card_at_the_same_time_%3F as a start. Regards, Yannick > > During the tests I've used no webcam (so to avoid any overload of the > system) and tried the echo server of ekiga. > > Using the direct alsa output, jitter buffer goes at 20 and the quality > is very good. In my tests sometimes it increases to 40, most of the > times stays at 20. > > Using the "default" (i.e. dmix) the quality is bad while the jitter > buffer increases. > In the worst cases it keeps increasing till 500 (very fast), other > times it slowly increases, sometimes it stabilises at around 300. > Usually (but not always) the quality improves when the jitter stops. > > If there is an other application playing sond, the growth of the > jitter to 500 is usually faster. > > Sorry about my ignorance, but what is the jitter buffer? How does it > interact with dmix and alsa? > > I've found that using the sound event settings I can have the "ring" > with dmix and then before answering I have to stop other applications > playing sound, so in my case the limitation of dmix is not really that > big, but anyway... > > Thanks > > >> > >> If I use the hardware directly the quality improves but I still have > >> some problems when I set the full screen. > >> > >> Is there any setting that could affect audio quality? > >> > > >If it happens when you set to fullscreen, you are probably using too > >much CPU ressources. > > >Be careful also that you are perhaps wasting your bandwidth with too > >large video transmission or too high settings. > > >Just check the value of your jitter, it will help a lot to determine if > >there is a problem related to CPU/Bandwidth (if it goes over 500ms, then > >the problem is at this side, if not, then the problem is on the ALSA > >side). > _______________________________________________ > ekiga-list mailing list > ekiga-list at gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list > -- Me joindre en t?l?phonie IP / vid?oconf?rence ? sip:yannick at ekiga.net From dsandras at seconix.com Sun Nov 12 17:38:02 2006 From: dsandras at seconix.com (Damien Sandras) Date: Sun, 12 Nov 2006 18:38:02 +0100 Subject: [Ekiga-list] Poor audio quality In-Reply-To: <53d94280611120825h44527e1t764cc9d3bb8f9098@mail.gmail.com> References: <53d94280611120825h44527e1t764cc9d3bb8f9098@mail.gmail.com> Message-ID: <1163353082.4114.1.camel@golgoth01> Hi, The jitter buffer is the reception buffer where audio frames gets accumulated until they are ready to be played. It explodes with DMIX because DMIX is adding much latency. 2.0.4 will have a workaround for that. I am waiting that the Ubuntu guys sort #359655 before releasing 2.0.4, but I think I won't wait a long time anymore because they seem unable to test if the proposed patch fixes the problem. Ah well, Ubuntu Edgy... Our daily nightmare. Le dimanche 12 novembre 2006 ? 16:25 +0000, Mario Rossi a ?crit : > Hi > > I've finally installed ekiga 2.0.3 (compiled from sources) and I've > done some testing using the dmix plugin. > > During the tests I've used no webcam (so to avoid any overload of the > system) and tried the echo server of ekiga. > > Using the direct alsa output, jitter buffer goes at 20 and the quality > is very good. In my tests sometimes it increases to 40, most of the > times stays at 20. > > Using the "default" (i.e. dmix) the quality is bad while the jitter > buffer increases. > In the worst cases it keeps increasing till 500 (very fast), other > times it slowly increases, sometimes it stabilises at around 300. > Usually (but not always) the quality improves when the jitter stops. > > If there is an other application playing sond, the growth of the > jitter to 500 is usually faster. > > Sorry about my ignorance, but what is the jitter buffer? How does it > interact with dmix and alsa? > > I've found that using the sound event settings I can have the "ring" > with dmix and then before answering I have to stop other applications > playing sound, so in my case the limitation of dmix is not really that > big, but anyway... > > Thanks > > >> > >> If I use the hardware directly the quality improves but I still have > >> some problems when I set the full screen. > >> > >> Is there any setting that could affect audio quality? > >> > > >If it happens when you set to fullscreen, you are probably using too > >much CPU ressources. > > >Be careful also that you are perhaps wasting your bandwidth with too > >large video transmission or too high settings. > > >Just check the value of your jitter, it will help a lot to determine if > >there is a problem related to CPU/Bandwidth (if it goes over 500ms, then > >the problem is at this side, if not, then the problem is on the ALSA > >side). > _______________________________________________ > ekiga-list mailing list > ekiga-list at gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list -- _ Damien Sandras (o- //\ Ekiga Softphone : http://www.ekiga.org/ v_/_ NOVACOM : http://www.novacom.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsandras at ekiga.net From geboyd53 at comcast.net Mon Nov 13 11:07:01 2006 From: geboyd53 at comcast.net (George Boyd) Date: Mon, 13 Nov 2006 03:07:01 -0800 Subject: [Ekiga-list] Hi Damien And The Group In-Reply-To: <1162973989.7768.8.camel@c-71-193-191-8.hsd1.wa.comcast.net> References: <1162663663.6944.119.camel@achille> <1162675919.6944.129.camel@achille> <2e19719f0611050059o3896188aqf78f3c25c4b5883d@mail.gmail.com> <1162751521.6944.151.camel@achille> <2e19719f0611051214u29b44d06jff021ba5249ff1d2@mail.gmail.com> <20061104192542.GA20979@mungewell.org> <2e19719f0611061424hd39e334xd5be054e9ec145e3@mail.gmail.com> <1162852465.3890.46.camel@golgoth01> <1162973989.7768.8.camel@c-71-193-191-8.hsd1.wa.comcast.net> Message-ID: <1163416021.4104.18.camel@localhost.localdomain> As a follow up to this last post. Fedora came out with a yum update that included another kernel. After installing the updates, I discovered that Ekiga is even running better then before the last post. I was able to make a land line call to Indonesia from the US with the jitter buffer at 20%, the lowest default. The call was crystal clear and the jitter buffer stayed between 20 - 30 with no distortion. Another thing that changed is the lag and echo I used to get during voice conversations, that cleared up too. Damien, as you said, that is a weird as a behavior, but the results speak for themselves. I duplicated the results by calling from the US to other land line numbers in the US with the same excellent results. Then tried another overseas call and again, perfect. You're the expert, and these have been the results. You probably understand and can make sense out of this much more then I can. I'm just very happy that Ekiga is working so well now. By the way, I downloaded and installed the Ekiga 2.03 and I'm not really sure where you all are going with the interface, but I really do like the interface for 2.02 much better. It's cleaner and easier to us. I guess that after the vote, the new interface is what the majority wanted, so I'll deal with it. But for now I'll stick to the 2.02 Thanks Again, Ekiga Rocks (even better then before!) George On Wed, 2006-11-08 at 00:19 -0800, George Boyd wrote: > It sure has been quite on this group, is that good or bad news? > > Damien, I thought you may like to know about the problem I was having > with the distorted and "helicopter" sound using Ekiga and Fedora. Today > I noticed that when I installed Fedora Core 6, that it mistakenly > installed the i586 kernel instead of the i686 kernel. I removed the i586 > kernel and installed the i686 one and was able to make the first > successful (and clear) call using Ekiga through VoIP Buster to a land > line. > > I don't know what the difference is between them, but I was able to make > the call with a reasonable amount of jitter buffer and clear. I don't > know if this will help anyone else or not, but it made a big difference > here. > > Take Care, > George > > _______________________________________________ > ekiga-list mailing list > ekiga-list at gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list From prakashb at tataelxsi.co.in Mon Nov 13 14:37:37 2006 From: prakashb at tataelxsi.co.in (Prakash B) Date: Mon, 13 Nov 2006 20:07:37 +0530 (IST) Subject: [Ekiga-list] help me to run ekiga Message-ID: <20061113200737.CCC92773@mail.tataelxsi.co.in> i have compiled the source trees of the ekiga. Now while running the ekiga, its giving the error as "Xlib: unexpected async reply (sequence 0x778)! " and also a seprate gui with message that unexpected error occurs, and the only option is to Quit the application. help me pls to run the ekiga. thanks in advance. - prakash. From dsandras at seconix.com Mon Nov 13 15:39:28 2006 From: dsandras at seconix.com (Damien Sandras) Date: Mon, 13 Nov 2006 16:39:28 +0100 Subject: [Ekiga-list] Hi Damien And The Group In-Reply-To: <1163416021.4104.18.camel@localhost.localdomain> References: <1162663663.6944.119.camel@achille> <1162675919.6944.129.camel@achille> <2e19719f0611050059o3896188aqf78f3c25c4b5883d@mail.gmail.com> <1162751521.6944.151.camel@achille> <2e19719f0611051214u29b44d06jff021ba5249ff1d2@mail.gmail.com> <20061104192542.GA20979@mungewell.org> <2e19719f0611061424hd39e334xd5be054e9ec145e3@mail.gmail.com> <1162852465.3890.46.camel@golgoth01> <1162973989.7768.8.camel@c-71-193-191-8.hsd1.wa.comcast.net> <1163416021.4104.18.camel@localhost.localdomain> Message-ID: <1163432368.30789.12.camel@golgoth01> Le lundi 13 novembre 2006 ? 03:07 -0800, George Boyd a ?crit : > As a follow up to this last post. Fedora came out with a yum update that > included another kernel. After installing the updates, I discovered that > Ekiga is even running better then before the last post. > > I was able to make a land line call to Indonesia from the US with the > jitter buffer at 20%, the lowest default. The call was crystal clear and > the jitter buffer stayed between 20 - 30 with no distortion. Another > thing that changed is the lag and echo I used to get during voice > conversations, that cleared up too. > That's an excellent news for you! (and for others using Fedora). > Damien, as you said, that is a weird as a behavior, but the results > speak for themselves. I duplicated the results by calling from the US to > other land line numbers in the US with the same excellent results. Then > tried another overseas call and again, perfect. > Excellent. > You're the expert, and these have been the results. You probably > understand and can make sense out of this much more then I can. I'm just > very happy that Ekiga is working so well now. > I would say that overseas calls depend on the network quality, but also on the quality of the audio drivers. Probably the default setup on Fedora has been improved with a direct impact on Ekiga's quality. Again, that is just a proof the problem was external to Ekiga. > By the way, I downloaded and installed the Ekiga 2.03 and I'm not really > sure where you all are going with the interface, but I really do like > the interface for 2.02 much better. It's cleaner and easier to us. I don't understand what you mean by that because the user interface has not changed between 2.0.2 and 2.0.3. We have only made changes in CVS HEAD with a new interface with a contacts list. > > I guess that after the vote, the new interface is what the majority > wanted, so I'll deal with it. But for now I'll stick to the 2.02 > > Thanks Again, Ekiga Rocks (even better then before!) > > George > > > > > On Wed, 2006-11-08 at 00:19 -0800, George Boyd wrote: > > It sure has been quite on this group, is that good or bad news? > > > > Damien, I thought you may like to know about the problem I was having > > with the distorted and "helicopter" sound using Ekiga and Fedora. Today > > I noticed that when I installed Fedora Core 6, that it mistakenly > > installed the i586 kernel instead of the i686 kernel. I removed the i586 > > kernel and installed the i686 one and was able to make the first > > successful (and clear) call using Ekiga through VoIP Buster to a land > > line. > > > > I don't know what the difference is between them, but I was able to make > > the call with a reasonable amount of jitter buffer and clear. I don't > > know if this will help anyone else or not, but it made a big difference > > here. > > > > Take Care, > > George > > > > _______________________________________________ > > ekiga-list mailing list > > ekiga-list at gnome.org > > http://mail.gnome.org/mailman/listinfo/ekiga-list > > _______________________________________________ > ekiga-list mailing list > ekiga-list at gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list -- Damien Sandras Ekiga Softphone : http://www.ekiga.org NOVACOM : http://www.novacom.be FOSDEM : http://www.fosdem.org SIP Phone : sip:dsandras at ekiga.net From geboyd53 at comcast.net Mon Nov 13 19:56:12 2006 From: geboyd53 at comcast.net (George Boyd) Date: Mon, 13 Nov 2006 11:56:12 -0800 Subject: [Ekiga-list] Hi Damien And The Group In-Reply-To: <1163432368.30789.12.camel@golgoth01> References: <1162663663.6944.119.camel@achille> <1162675919.6944.129.camel@achille> <2e19719f0611050059o3896188aqf78f3c25c4b5883d@mail.gmail.com> <1162751521.6944.151.camel@achille> <2e19719f0611051214u29b44d06jff021ba5249ff1d2@mail.gmail.com> <20061104192542.GA20979@mungewell.org> <2e19719f0611061424hd39e334xd5be054e9ec145e3@mail.gmail.com> <1162852465.3890.46.camel@golgoth01> <1162973989.7768.8.camel@c-71-193-191-8.hsd1.wa.comcast.net> <1163416021.4104.18.camel@localhost.localdomain> <1163432368.30789.12.camel@golgoth01> Message-ID: <1163447772.19420.2.camel@localhost.localdomain> My bad Damien, I meant in the CVS Head. The Linux version looks like the windows version. > > I don't understand what you mean by that because the user interface has > not changed between 2.0.2 and 2.0.3. We have only made changes in CVS > HEAD with a new interface with a contacts list. From James.DiGuglielmo at aei.mpg.de Mon Nov 13 22:17:13 2006 From: James.DiGuglielmo at aei.mpg.de (James DiGuglielmo) Date: Mon, 13 Nov 2006 23:17:13 +0100 Subject: [Ekiga-list] Abnormal Call Termination Message-ID: Hello, I have recently upgraded my Ubuntu operating system to Ubuntu 6.06 LTS and have configured Ekiga for pc-to-phone calls. I have a diamond account that is working, I can call the echo test and it works, but when I try to call the US e.g. "1(city code)(phonenumber)@eugw.ast.diamond.us" I keep getting the message "Abnormal Call Termination". What could be causing that? Thank you for your help James From dsandras at seconix.com Tue Nov 14 09:08:36 2006 From: dsandras at seconix.com (Damien Sandras) Date: Tue, 14 Nov 2006 10:08:36 +0100 Subject: [Ekiga-list] Abnormal Call Termination In-Reply-To: References: Message-ID: <1163495316.5333.6.camel@golgoth01> Le lundi 13 novembre 2006 ? 23:17 +0100, James DiGuglielmo a ?crit : > > Hello, > > I have recently upgraded my Ubuntu operating system to Ubuntu 6.06 LTS > and have configured Ekiga for pc-to-phone calls. I have a diamond > account that is working, I can call the echo test and it works, but > when I try to call the US e.g. "1(city > code)(phonenumber)@eugw.ast.diamond.us" I keep getting the message > "Abnormal Call Termination". What could be causing that? > > Thank you for your help > What's the -d 4 debug output? -- Damien Sandras Ekiga Softphone : http://www.ekiga.org NOVACOM : http://www.novacom.be FOSDEM : http://www.fosdem.org SIP Phone : sip:dsandras at ekiga.net From johan_brn at yahoo.com Tue Nov 14 09:10:30 2006 From: johan_brn at yahoo.com (Johan Brannlund) Date: Tue, 14 Nov 2006 09:10:30 +0000 (UTC) Subject: [Ekiga-list] Call latency Message-ID: Hi. I just read a comment by Damien that dmix causes quite a bit of latency, so I tried turning it off by selecting the "ATI IXP" device (the name of my sound card) instead of the "Default" device and the difference was very noticeable. I don't have any hard numbers, but roughly speaking the latency went from "annoying" to "insignificant". Is there anything that can be done about the dmix latency? Are the alsa developers aware of the problem? - Johan From dsandras at seconix.com Tue Nov 14 16:52:20 2006 From: dsandras at seconix.com (Damien Sandras) Date: Tue, 14 Nov 2006 17:52:20 +0100 Subject: [Ekiga-list] Call latency In-Reply-To: References: Message-ID: <1163523140.3852.13.camel@golgoth01> Hi, Le mardi 14 novembre 2006 ? 09:10 +0000, Johan Brannlund a ?crit : > Hi. I just read a comment by Damien that dmix causes quite a bit of > latency, so I tried turning it off by selecting the "ATI IXP" device > (the name of my sound card) instead of the "Default" device and the > difference was very noticeable. > > I don't have any hard numbers, but roughly speaking the latency went > from "annoying" to "insignificant". > > Is there anything that can be done about the dmix latency? Are the alsa > developers aware of the problem? > I think so, I had reported a bug, but they do not really care I think. However, somebody has found a workaround in PWLIB to improve things, it will be available from 2.0.4. -- Damien Sandras Ekiga Softphone : http://www.ekiga.org NOVACOM : http://www.novacom.be FOSDEM : http://www.fosdem.org SIP Phone : sip:dsandras at ekiga.net From James.DiGuglielmo at aei.mpg.de Tue Nov 14 18:45:45 2006 From: James.DiGuglielmo at aei.mpg.de (James DiGuglielmo) Date: Tue, 14 Nov 2006 19:45:45 +0100 Subject: [Ekiga-list] Abnormal Call Termination Message-ID: Hello Damien, Thank you for responding! Here is the -d 4 output as an attachment. Tonight was the first night that I was able to make a call, however, when I finally got through, although the person on the other end could hear me I could not hear them. I was also only able to do this once. The -d 4 output kept reading " SIP Handler:86dlc08 STUN could not create socket pair!". When I tried to hange up ctrl+D, nothing happend, I had to force quit the application. Does any of this make sense? Thank you for your time James (See attached file: ekiga-d4) -------------- next part -------------- A non-text attachment was scrubbed... Name: ekiga-d4 Type: application/octet-stream Size: 26927 bytes Desc: not available URL: From windy_willows_01 at yahoo.ca Tue Nov 14 18:50:04 2006 From: windy_willows_01 at yahoo.ca (Robert Fraser) Date: Tue, 14 Nov 2006 13:50:04 -0500 (EST) Subject: [Ekiga-list] No video images from webcam in Ekiga for Windows Message-ID: <20061114185004.71432.qmail@web57805.mail.re3.yahoo.com> I was testing the Windows version of Ekiga. Before initiating a call, I selected the icon to "Display images from your camera device". During a call to sip:500 at ekiga.net, where images from the webcam should appear, there appeared a solid green screen/image. The webcam I am using is a Logitech Quickcam Communicate STX. I used a shareware program called 263Set to test the webcam. This program uses "Video for Windows/Microsoft WDM Image Capture (Win32)" to capture images from a webcam like Ekiga does. The program displayed images from the webcam. Is there something I need to do to get Ekiga to display the video images from the webcam? I downloaded the Windows version of Ekiga from: http://snapshots.voxgratia.org/win32.php Thanks. --------------------------------- Now you can have a huge leap forward in email: get the new Yahoo! Mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schampera at web.de Tue Nov 14 19:08:55 2006 From: jan.schampera at web.de (Jan Schampera) Date: Tue, 14 Nov 2006 20:08:55 +0100 Subject: [Ekiga-list] No video images from webcam in Ekiga for Windows In-Reply-To: <20061114185004.71432.qmail@web57805.mail.re3.yahoo.com> References: <20061114185004.71432.qmail@web57805.mail.re3.yahoo.com> Message-ID: <20061114200855.2e733025@localhost.localdomain> On Tue, 14 Nov 2006 13:50:04 -0500 (EST) Robert Fraser wrote: > I used a shareware program called 263Set to test the webcam. This > program uses "Video for Windows/Microsoft WDM Image Capture (Win32)" > to capture images from a webcam like Ekiga does. The program > displayed images from the webcam. Maybe the cam doesn't send the required format or so. I have no expirience with that, just a sidenote. J. -- Der Mensch, der bereit ist, seine Freiheit aufzugeben, um Sicherheit zu gewinnen, wird beides verlieren. - Benjamin Franklin From dsandras at seconix.com Tue Nov 14 20:01:20 2006 From: dsandras at seconix.com (Damien Sandras) Date: Tue, 14 Nov 2006 21:01:20 +0100 Subject: [Ekiga-list] Abnormal Call Termination In-Reply-To: References: Message-ID: <1163534480.3852.26.camel@golgoth01> Hi, I need a full output. Le mardi 14 novembre 2006 ? 19:45 +0100, James DiGuglielmo a ?crit : > Hello Damien, > > Thank you for responding! Here is the -d 4 output as an attachment. > Tonight was the first night that I was able to make a call, however, when I > finally got through, although the person on the other end could hear me I > could not hear them. I was also only able to do this once. The -d 4 > output kept reading " SIP Handler:86dlc08 STUN could not create socket > pair!". > When I tried to hange up ctrl+D, nothing happend, I had to force quit the > application. Does any of this make sense? > No, but we will figure it out :) Make sure you do not have a local firewall on your machine dropping packets. The only thing I can see from your log is that you were sending audio but receiving nothing. -- Damien Sandras Ekiga Softphone : http://www.ekiga.org NOVACOM : http://www.novacom.be FOSDEM : http://www.fosdem.org SIP Phone : sip:dsandras at ekiga.net From dsandras at seconix.com Tue Nov 14 20:02:06 2006 From: dsandras at seconix.com (Damien Sandras) Date: Tue, 14 Nov 2006 21:02:06 +0100 Subject: [Ekiga-list] No video images from webcam in Ekiga for Windows In-Reply-To: <20061114200855.2e733025@localhost.localdomain> References: <20061114185004.71432.qmail@web57805.mail.re3.yahoo.com> <20061114200855.2e733025@localhost.localdomain> Message-ID: <1163534526.3852.28.camel@golgoth01> Le mardi 14 novembre 2006 ? 20:08 +0100, Jan Schampera a ?crit : > On Tue, 14 Nov 2006 13:50:04 -0500 (EST) > Robert Fraser wrote: > > > I used a shareware program called 263Set to test the webcam. This > > program uses "Video for Windows/Microsoft WDM Image Capture (Win32)" > > to capture images from a webcam like Ekiga does. The program > > displayed images from the webcam. > > Maybe the cam doesn't send the required format or so. I have no > expirience with that, just a sidenote. > Same here. In other words, you are on your own :( -- Damien Sandras Ekiga Softphone : http://www.ekiga.org NOVACOM : http://www.novacom.be FOSDEM : http://www.fosdem.org SIP Phone : sip:dsandras at ekiga.net From cwg at falma.de Wed Nov 15 08:52:28 2006 From: cwg at falma.de (Christoph Groth) Date: Wed, 15 Nov 2006 09:52:28 +0100 Subject: [Ekiga-list] druid keeps reporting symmetric nat Message-ID: <87y7qdhz1v.fsf@falma.de> Dear all, My box sits behind a configurable NAT router. The ekiga 2.0.3 druid complains about symmetic nat. Consequently I forward UDP ports 5000 to 5100 to my box. I do not use a local iptables firewall. But ekiga keeps complaining about symmetric NAT. Shouldn't it detect cone nat now? (I surely know how to forward ports in our router. I've done that for my ssh server and it works perfectly.) I can "call" my box from outside using sipsak, so the ports _are_ really forwarded (see attached snippet of an ekiga log). Thanks! Christoph 2006/11/15 09:46:16.093 0:51.926 Opal Listener:837de00 OpalUDP Pre-bound to interface: 192.168.1.80:5060 2006/11/15 09:46:16.095 0:51.928 Opal Listener:837de00 SIP Waiting for PDU on udp$0.0.0.0 2006/11/15 09:46:16.098 0:51.931 Opal Listener:837de00 SIP PDU Received on udp$132.229.227.251:51922 INVITE sip:cwg at mybox.dyndns.org SIP/2.0 CSeq: 1 OPTIONS Via: SIP/2.0/UDP 132.229.227.25:51921;branch=z9hG4bK.39fa7c19;rport;alias Via: SIP/2.0/UDP 132.229.227.25:45466;branch=z9hG4bK.0f1be157;rport;alias User-Agent: sipsak 0.9.6 From: sip:sipsak at 132.229.227.25:45466;tag=63402e62 Call-ID: 1665150562 at 132.229.227.25 To: sip:cwg at mybox.dyndns.org Contact: sip:sipsak at 132.229.227.25:45466 Accept: text/plain Content-Length: 0 Max-Forwards: 0 From dsandras at seconix.com Wed Nov 15 09:07:40 2006 From: dsandras at seconix.com (Damien Sandras) Date: Wed, 15 Nov 2006 10:07:40 +0100 Subject: [Ekiga-list] druid keeps reporting symmetric nat In-Reply-To: <87y7qdhz1v.fsf@falma.de> References: <87y7qdhz1v.fsf@falma.de> Message-ID: <1163581660.7916.0.camel@golgoth01> Hi, Yes it should report Cone NAT. But if you forwarded all ports, you can simply use IP Translation instead of STUN. Le mercredi 15 novembre 2006 ? 09:52 +0100, Christoph Groth a ?crit : > Dear all, > > My box sits behind a configurable NAT router. The ekiga 2.0.3 druid > complains about symmetic nat. Consequently I forward UDP ports 5000 > to 5100 to my box. I do not use a local iptables firewall. > > But ekiga keeps complaining about symmetric NAT. Shouldn't it detect > cone nat now? > > (I surely know how to forward ports in our router. I've done that for > my ssh server and it works perfectly.) > > I can "call" my box from outside using sipsak, so the ports _are_ > really forwarded (see attached snippet of an ekiga log). > > Thanks! > Christoph > > > 2006/11/15 09:46:16.093 0:51.926 Opal Listener:837de00 OpalUDP Pre-bound to interface: 192.168.1.80:5060 > 2006/11/15 09:46:16.095 0:51.928 Opal Listener:837de00 SIP Waiting for PDU on udp$0.0.0.0 > 2006/11/15 09:46:16.098 0:51.931 Opal Listener:837de00 SIP PDU Received on udp$132.229.227.251:51922 > INVITE sip:cwg at mybox.dyndns.org SIP/2.0 > CSeq: 1 OPTIONS > Via: SIP/2.0/UDP 132.229.227.25:51921;branch=z9hG4bK.39fa7c19;rport;alias > Via: SIP/2.0/UDP 132.229.227.25:45466;branch=z9hG4bK.0f1be157;rport;alias > User-Agent: sipsak 0.9.6 > From: sip:sipsak at 132.229.227.25:45466;tag=63402e62 > Call-ID: 1665150562 at 132.229.227.25 > To: sip:cwg at mybox.dyndns.org > Contact: sip:sipsak at 132.229.227.25:45466 > Accept: text/plain > Content-Length: 0 > Max-Forwards: 0 > _______________________________________________ > ekiga-list mailing list > ekiga-list at gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list -- _ Damien Sandras (o- //\ Ekiga Softphone : http://www.ekiga.org/ v_/_ NOVACOM : http://www.novacom.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsandras at ekiga.net From cwg at falma.de Wed Nov 15 13:01:25 2006 From: cwg at falma.de (Christoph Groth) Date: Wed, 15 Nov 2006 14:01:25 +0100 Subject: [Ekiga-list] druid keeps reporting symmetric nat In-Reply-To: <1163581660.7916.0.camel@golgoth01> (Damien Sandras's message of "Wed, 15 Nov 2006 10:07:40 +0100") References: <87y7qdhz1v.fsf@falma.de> <1163581660.7916.0.camel@golgoth01> Message-ID: <87bqn86eze.fsf@falma.de> Hi again, thanks for the quick answer! > Yes it should report Cone NAT. > > But if you forwarded all ports, you can simply use IP Translation > instead of STUN. Setting it to IP Translation works. But I still do not understand why Cone NAT is not reported. Is this a problem with ekiga or with my router? Christoph From dsandras at seconix.com Wed Nov 15 13:11:35 2006 From: dsandras at seconix.com (Damien Sandras) Date: Wed, 15 Nov 2006 14:11:35 +0100 Subject: [Ekiga-list] druid keeps reporting symmetric nat In-Reply-To: <87bqn86eze.fsf@falma.de> References: <87y7qdhz1v.fsf@falma.de> <1163581660.7916.0.camel@golgoth01> <87bqn86eze.fsf@falma.de> Message-ID: <1163596295.15913.0.camel@golgoth01> Le mercredi 15 novembre 2006 ? 14:01 +0100, Christoph Groth a ?crit : > Hi again, > > thanks for the quick answer! > > > Yes it should report Cone NAT. > > > > But if you forwarded all ports, you can simply use IP Translation > > instead of STUN. > > Setting it to IP Translation works. But I still do not understand why > Cone NAT is not reported. Is this a problem with ekiga or with my > router? > I have no idea... -- Damien Sandras Ekiga Softphone : http://www.ekiga.org NOVACOM : http://www.novacom.be FOSDEM : http://www.fosdem.org SIP Phone : sip:dsandras at ekiga.net From cwg at falma.de Wed Nov 15 13:11:59 2006 From: cwg at falma.de (Christoph Groth) Date: Wed, 15 Nov 2006 14:11:59 +0100 Subject: [Ekiga-list] direct connection does not work. why? Message-ID: <877ixw6ehs.fsf@falma.de> Hello, I have two computers which are connected to the internet independently. A is behind a firewall but has an own internet IP address. B is behind NAT with the relevant ports being forwarded. Thus, for SIP purposes, B should appear to be connected to the internet directly. Both computers use different @ekiga.net accounts. Then calling from A to B, and from B to A seems to work flawlessly. Computer B has a dyndns account. When A (logged in as xyz at ekiga.net) calls sip:somone at mybox.dyndns.org, computer B notices the call, but A does not notice the call being answered or accepted. I wonder why this is so. Is there a way to make direct calls work in this configuration? thanks Christoph From jpuydt at free.fr Wed Nov 15 13:19:00 2006 From: jpuydt at free.fr (Julien Puydt) Date: Wed, 15 Nov 2006 14:19:00 +0100 Subject: [Ekiga-list] direct connection does not work. why? In-Reply-To: <877ixw6ehs.fsf@falma.de> References: <877ixw6ehs.fsf@falma.de> Message-ID: <455B13C4.7000503@free.fr> Christoph Groth a ?crit : > Computer B has a dyndns account. When A (logged in as xyz at ekiga.net) > calls sip:somone at mybox.dyndns.org, computer B notices the call, but A > does not notice the call being answered or accepted. Then A doesn't get the acceptation from B : firewall issue. Snark on #ekiga From daniel.odonnell at uleth.ca Wed Nov 15 14:53:14 2006 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Wed, 15 Nov 2006 07:53:14 -0700 Subject: [Ekiga-list] Noob (to Ekiga) question Message-ID: <1163602394.24469.8.camel@caedmon> Hi all, I've tried searching the archives for this, because I am told it is a common setup issue, but had no luck under usb or soundcards | sound cards. Basically my problem is the following: I have a logitech 250 USB headphone which works fine with Gizmo and Skype, and often with Ekiga. BUT, when I use it with Ekiga it frequently drops out. When I try to close Ekiga in these circumstances, it tends to freeze, sometimes freezing the whole computer, and a reboot is required. Even if it doesn't freeze, it takes its time closing and seems to be using a fair bit of resources. If the computer doesn't freeze, other resources can't write to the device after Ekiga closes down. This problem occurs whether the headphone is set to the default sound card or not (the slow exiting/freezing). If the sound card is not default, Ekiga doesn't recognise it, though Gizmo and Skype seem to. I am using a new install of Ubuntu Etch. My other sound card is Intel 82801DB-ICH4. Any suggestions? -dan -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell at uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ From sevmek at free.fr Wed Nov 15 15:07:28 2006 From: sevmek at free.fr (yannick) Date: Wed, 15 Nov 2006 16:07:28 +0100 Subject: [Ekiga-list] Noob (to Ekiga) question In-Reply-To: <1163602394.24469.8.camel@caedmon> References: <1163602394.24469.8.camel@caedmon> Message-ID: <1163603249.25028.11.camel@achille> Le mercredi 15 novembre 2006 ? 07:53 -0700, Daniel O'Donnell a ?crit : > I am using a new install of Ubuntu Etch. What is that?! Plz never mix ubuntu and debian, the result could be a monster... Like when cousins cross... ;) Regards, Yannick -- Me joindre en t?l?phonie IP / vid?oconf?rence ? sip:yannick at ekiga.net From dsandras at seconix.com Wed Nov 15 16:11:00 2006 From: dsandras at seconix.com (Damien Sandras) Date: Wed, 15 Nov 2006 17:11:00 +0100 Subject: [Ekiga-list] direct connection does not work. why? In-Reply-To: <877ixw6ehs.fsf@falma.de> References: <877ixw6ehs.fsf@falma.de> Message-ID: <1163607060.15913.6.camel@golgoth01> Le mercredi 15 novembre 2006 ? 14:11 +0100, Christoph Groth a ?crit : > Hello, > > I have two computers which are connected to the internet > independently. A is behind a firewall but has an own internet IP > address. B is behind NAT with the relevant ports being forwarded. > Thus, for SIP purposes, B should appear to be connected to the > internet directly. > > Both computers use different @ekiga.net accounts. Then calling from A > to B, and from B to A seems to work flawlessly. > > Computer B has a dyndns account. When A (logged in as xyz at ekiga.net) > calls sip:somone at mybox.dyndns.org, computer B notices the call, but A > does not notice the call being answered or accepted. > > I wonder why this is so. Is there a way to make direct calls work in > this configuration? > > Check the messages exchange using ekiga -d 4. Check where the 200 OK message is being sent. -- Damien Sandras Ekiga Softphone : http://www.ekiga.org NOVACOM : http://www.novacom.be FOSDEM : http://www.fosdem.org SIP Phone : sip:dsandras at ekiga.net From dsandras at seconix.com Wed Nov 15 16:27:35 2006 From: dsandras at seconix.com (Damien Sandras) Date: Wed, 15 Nov 2006 17:27:35 +0100 Subject: [Ekiga-list] Noob (to Ekiga) question In-Reply-To: <1163602394.24469.8.camel@caedmon> References: <1163602394.24469.8.camel@caedmon> Message-ID: <1163608055.15913.17.camel@golgoth01> Hi, Le mercredi 15 novembre 2006 ? 07:53 -0700, Daniel O'Donnell a ?crit : > Hi all, > > I've tried searching the archives for this, because I am told it is a > common setup issue, but had no luck under usb or soundcards | sound > cards. > > Basically my problem is the following: I have a logitech 250 USB > headphone which works fine with Gizmo and Skype, and often with Ekiga. > BUT, when I use it with Ekiga it frequently drops out. When I try to > close Ekiga in these circumstances, it tends to freeze, sometimes > freezing the whole computer, and a reboot is required. Even if it When the computer freezes, on Linux, it is because a kernel module crashed. So I suppose your USB driver has a bug which is only triggered by Ekiga. I would try upgrading the USB driver and I would look at the kernel messages. > doesn't freeze, it takes its time closing and seems to be using a fair > bit of resources. If the computer doesn't freeze, other resources can't > write to the device after Ekiga closes down. > Again, it indicates that the driver is in an inconsistent state. > This problem occurs whether the headphone is set to the default sound > card or not (the slow exiting/freezing). If the sound card is not > default, Ekiga doesn't recognise it, though Gizmo and Skype seem to. > > I am using a new install of Ubuntu Etch. My other sound card is Intel > 82801DB-ICH4. > > Any suggestions? > > -dan -- Damien Sandras Ekiga Softphone : http://www.ekiga.org NOVACOM : http://www.novacom.be FOSDEM : http://www.fosdem.org SIP Phone : sip:dsandras at ekiga.net From bbagger at gmail.com Thu Nov 16 08:27:11 2006 From: bbagger at gmail.com (Bent Bagger) Date: Thu, 16 Nov 2006 09:27:11 +0100 Subject: [Ekiga-list] Ekiga 2.0.3. calls for version 1.10.1 of libpt_linux_x86_r Message-ID: <2e19719f0611160027s6d619fa7hcddf5d05c676685@mail.gmail.com> Hi I have just updated Ekiga from version 2.0.2. to 2.0.3. The update ended up by being successful, but I made an observation which I will bring to your attention: As part of the process I did a 'make uninstall' in all three 'old' directories (pwlib-1.10.1, opal-2.2.2 and ekiga-2.0.2) to have a 'clean slate'. After a successful build I could not run ekiga: # ekiga -d 4 ekiga: error while loading shared libraries: libpt_linux_x86_r.so.1.10.1: cannot open shared object file: No such file or directory A 'll /usr/lib/libpt_linux_x86_r.so*' reveals this: lrwxrwxrwx 1 root root 27 Nov 16 08:37 /usr/lib/libpt_linux_x86_r.so -> libpt_linux_x86_r.so.1.10.2 lrwxrwxrwx 1 root root 27 Nov 16 08:37 /usr/lib/libpt_linux_x86_r.so.1 -> libpt_linux_x86_r.so.1.10.2 lrwxrwxrwx 1 root root 27 Nov 16 08:37 /usr/lib/libpt_linux_x86_r.so.1.10 -> libpt_linux_x86_r.so.1.10.2 -r--r--r-- 1 root root 3737696 Nov 16 08:37 /usr/lib/libpt_linux_x86_r.so.1.10.2 libpt_linux_x86_r.so.1.10.1 is part of the pwlib-1.10.1 package. I 'fixed' the problem by linking: # cd /usr/lib # ln -s libpt_linux_x86_r.so.1.10.2 libpt_linux_x86_r.so.1.10.1 and then Ekiga ran as it should. If I hadn't done the 'make uninstall' I would probably never had seen this behaviour (I wouldn't call it an error). Best regards, Bent From dsandras at seconix.com Thu Nov 16 11:52:45 2006 From: dsandras at seconix.com (Damien Sandras) Date: Thu, 16 Nov 2006 12:52:45 +0100 Subject: [Ekiga-list] Ekiga 2.0.3. calls for version 1.10.1 of libpt_linux_x86_r In-Reply-To: <2e19719f0611160027s6d619fa7hcddf5d05c676685@mail.gmail.com> References: <2e19719f0611160027s6d619fa7hcddf5d05c676685@mail.gmail.com> Message-ID: <1163677965.3257.16.camel@golgoth01> Hi, Le jeudi 16 novembre 2006 ? 09:27 +0100, Bent Bagger a ?crit : > Hi > > I have just updated Ekiga from version 2.0.2. to 2.0.3. The update > ended up by being successful, but I made an observation which I will > bring to your attention: > > As part of the process I did a 'make uninstall' in all three 'old' > directories (pwlib-1.10.1, opal-2.2.2 and ekiga-2.0.2) to have a > 'clean slate'. > > After a successful build I could not run ekiga: > # ekiga -d 4 > ekiga: error while loading shared libraries: libpt_linux_x86_r.so.1.10.1: cannot > open shared object file: No such file or directory > > A 'll /usr/lib/libpt_linux_x86_r.so*' reveals this: > lrwxrwxrwx 1 root root 27 Nov 16 08:37 /usr/lib/libpt_linux_x86_r.so -> > libpt_linux_x86_r.so.1.10.2 > lrwxrwxrwx 1 root root 27 Nov 16 08:37 /usr/lib/libpt_linux_x86_r.so.1 -> > libpt_linux_x86_r.so.1.10.2 > lrwxrwxrwx 1 root root 27 Nov 16 08:37 /usr/lib/libpt_linux_x86_r.so.1.10 > -> libpt_linux_x86_r.so.1.10.2 > -r--r--r-- 1 root root 3737696 Nov 16 08:37 /usr/lib/libpt_linux_x86_r.so.1.10.2 > > libpt_linux_x86_r.so.1.10.1 is part of the pwlib-1.10.1 package. I > 'fixed' the problem by linking: > > # cd /usr/lib > # ln -s libpt_linux_x86_r.so.1.10.2 libpt_linux_x86_r.so.1.10.1 > > and then Ekiga ran as it should. > > If I hadn't done the 'make uninstall' I would probably never had seen > this behaviour (I wouldn't call it an error). That means that when Ekiga was compiled, it linked against the old libpt_linux which was still present in /usr/lib. The symlink you created is potentially dangerous and could lead to unexpected crashes if the library is binary incompatible with the older 1.10.1. -- Damien Sandras Ekiga Softphone : http://www.ekiga.org NOVACOM : http://www.novacom.be FOSDEM : http://www.fosdem.org SIP Phone : sip:dsandras at ekiga.net From merameo at yahoo.com Thu Nov 16 15:00:31 2006 From: merameo at yahoo.com (pippo pippo) Date: Thu, 16 Nov 2006 07:00:31 -0800 (PST) Subject: [Ekiga-list] Problems with Ekiga and GnuGk...Ekiga doesn't register! Message-ID: <304584.64705.qm@web55503.mail.re4.yahoo.com> Hi, I've a problem with Ekiga and GnuGk. Ekiga doesn't register to the gatekeeper. I created an account with this information about the gatekeeper: Name:gnugk Gatekeeper: 192.168.0.1 Protocol: H323 User: user1 Password: pass1 ID Gatekeeper: gnugk (IP address of Ekiga is 192.168.0.2) The configuration file of GnuGk is this: [Gatekeeper::Main] Fourtytwo=42 Name=gnugk [Gatekeeper::Auth] SimplePasswordAuth=required [Password] KeyFilled=123 CheckID=1 PasswordTimeout=1000 I add the password to GnuGk with the utility addpasswd with this command: addpasswd gnugk.ini Password user1 pass1 When I try to register Ekiga, GnuGk doesn't check the password. The output log of GnuGk is this: 2006/11/16 15:32:27.187 2 singleton.cxx(32) Create instance: Toolkit(1) 2006/11/16 15:32:27.258 2 Toolkit.cxx(264) Network=192.168.0.0/255.255.255.0, IP=192.168.0.1 2006/11/16 15:32:27.259 2 Toolkit.cxx(264) Network=127.0.0.0/255.0.0.0, IP=127.0.0.1 2006/11/16 15:32:27.322 2 Toolkit.cxx(264) Network=127.0.0.0/255.0.0.0, IP=127.0.0.1 2006/11/16 15:32:27.385 2 Toolkit.cxx(265) Default IP=127.0.0.1 2006/11/16 15:32:27.386 2 Toolkit.cxx(342) GK H.323 Proxy disabled 2006/11/16 15:32:27.449 2 Toolkit.cxx(527) GK Loaded per GW rewrite data: 2006/11/16 15:32:27.513 2 Toolkit.cxx(530) GK No per GW data loaded 2006/11/16 15:32:27.514 2 singleton.cxx(32) Create instance: CapacityControl(2) OpenH323 Gatekeeper - The GNU Gatekeeper with ID 'gnugk' started Gatekeeper(GNU) Version(2.2.4) Ext(pthreads=1,radius=1,mysql=0,pgsql=0,large_fdset=0) Build(Nov 9 2006, 10:41:23) Sys(Linux i686 2.6.16.21-0.25-default) 2006/11/16 15:32:27.642 1 gk.cxx(510) OpenH323 Gatekeeper - The GNU Gatekeeper with ID 'gnugk' started Gatekeeper(GNU) Version(2.2.4) Ext(pthreads=1,radius=1,mysql=0,pgsql=0,large_fdset=0) Build(Nov 9 2006, 10:41:23) Sys(Linux i686 2.6.16.21-0.25-default) Listen on 127.0.0.1,192.168.0.1 This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. 2006/11/16 15:32:27.643 2 singleton.cxx(32) Create instance: CallTable(3) Disable Bandwidth Management 2006/11/16 15:32:27.702 2 gk.cxx(548) GK TimeToLive for Registrations: -1 2006/11/16 15:32:27.757 2 singleton.cxx(32) Create instance: RasSrv(4) 2006/11/16 15:32:27.812 2 ProxyChannel.cxx(181) RTPPortRange: 1024-65535 2006/11/16 15:32:27.870 2 singleton.cxx(32) Create instance: Agent(5) 2006/11/16 15:32:27.871 2 RasSrv.cxx(717) GK Using Routed Signalling 2006/11/16 15:32:27.925 2 RasSrv.cxx(718) GK H.245 Routed Enabled 2006/11/16 15:32:27.925 2 singleton.cxx(32) Create instance: GkStatus(6) 2006/11/16 15:32:27.979 2 singleton.cxx(32) Create instance: RegistrationTable(7) 2006/11/16 15:32:28.033 2 RasSrv.cxx(754) GK Home = 127.0.0.1,192.168.0.1 2006/11/16 15:32:28.087 1 RasSrv.cxx(505) Listening to 127.0.0.1:1719(U) 2006/11/16 15:32:28.140 1 RasSrv.cxx(505) Listening to 127.0.0.1:1721 2006/11/16 15:32:28.194 1 RasSrv.cxx(505) Listening to 127.0.0.1:7000 2006/11/16 15:32:28.248 1 RasSrv.cxx(505) Listening to 192.168.0.1:1719(U) 2006/11/16 15:32:28.249 1 RasSrv.cxx(505) Listening to 192.168.0.1:1718(Mcast) 2006/11/16 15:32:28.304 1 RasSrv.cxx(505) Listening to 192.168.0.1:1721 2006/11/16 15:32:28.360 1 RasSrv.cxx(505) Listening to 192.168.0.1:7000 2006/11/16 15:32:28.416 1 RasSrv.cxx(813) RAS Broadcast listener listening at 0.0.0.0:1719(Bcast) 2006/11/16 15:32:28.417 1 gkauth.cxx(283) GKAUTH SimplePasswordAuth rule added to check RAS: ARQ BRQ DRQ GRQ IRQ LRQ RRQ URQ, OTHER: SETUP SETUPUNREG 2006/11/16 15:32:28.474 1 gkauth.cxx(1063) GKAUTH SimplePasswordAuth KeyFilled config variable is missing 2006/11/16 15:32:28.583 2 Routing.cxx(657) VQueue (CTI) Virtual queues disabled - no virtual queues configured 2006/11/16 15:32:28.584 2 singleton.cxx(32) Create instance: Routing::Analyzer(8) 2006/11/16 15:32:28.637 2 gkacct.cxx(1014) GKACCT Successfully logged event 8 2006/11/16 15:32:42.864 2 RasSrv.cxx(174) RAS Read from 192.168.0.2:5071 2006/11/16 15:32:42.865 3 RasSrv.cxx(220) RAS gatekeeperRequest { requestSeqNum = 25269 protocolIdentifier = 0.0.8.2250.0.4 rasAddress = ipAddress { ip = 4 octets { c0 a8 00 02 .... } port = 5071 } endpointType = { vendor = { vendor = { t35CountryCode = 9 t35Extension = 0 manufacturerCode = 61 } productId = 7 octets { 65 6b 69 67 61 00 00 ekiga.. } versionId = 21 octets { 32 2e 30 2e 33 20 28 4f 50 41 4c 20 76 32 2e 32 2.0.3 (OPAL v2.2 2e 33 29 00 00 .3).. } } terminal = { } mc = FALSE undefinedNode = FALSE } gatekeeperIdentifier = 5 characters { 0067 006e 0075 0067 006b gnugk } endpointAlias = 2 entries { [0]=h323_ID 5 characters { 0075 0073 0065 0072 0031 user1 } [1]=h323_ID 7 characters { 0050 0061 006f 006c 006f 0020 0050 Paolo P } } authenticationCapability = 2 entries { [0]=pwdHash <> [1]=authenticationBES radius <> } algorithmOIDs = 3 entries { [0]=0.0.8.235.0.2.6 [1]=1.2.840.113548.10.1.2.1 [2]=1.2.840.113549.2.5 } supportsAltGK = <> } 2006/11/16 15:32:42.867 1 RasSrv.cxx(344) RAS GRQ Received 2006/11/16 15:32:42.867 3 gkauth.h(834) GKAUTH SimplePasswordAuth GRQ check failed 2006/11/16 15:32:42.891 2 RasSrv.cxx(389) GRJ|192.168.0.2|user1:h323_ID=Paolo P:h323_ID|terminal|securityDenial; 2006/11/16 15:32:42.892 3 RasSrv.cxx(232) RAS Send to 192.168.0.2:5071 gatekeeperReject { requestSeqNum = 25269 protocolIdentifier = 0.0.8.2250.0.4 gatekeeperIdentifier = 5 characters { 0067 006e 0075 0067 006b gnugk } rejectReason = securityDenial <> } 2006/11/16 15:32:42.973 2 RasSrv.cxx(174) RAS Read from 192.168.0.2:5071 2006/11/16 15:32:42.973 3 RasSrv.cxx(220) RAS gatekeeperRequest { requestSeqNum = 25269 protocolIdentifier = 0.0.8.2250.0.4 rasAddress = ipAddress { ip = 4 octets { c0 a8 00 02 .... } port = 5071 } endpointType = { vendor = { vendor = { t35CountryCode = 9 t35Extension = 0 manufacturerCode = 61 } productId = 7 octets { 65 6b 69 67 61 00 00 ekiga.. } versionId = 21 octets { 32 2e 30 2e 33 20 28 4f 50 41 4c 20 76 32 2e 32 2.0.3 (OPAL v2.2 2e 33 29 00 00 .3).. } } terminal = { } mc = FALSE undefinedNode = FALSE } gatekeeperIdentifier = 5 characters { 0067 006e 0075 0067 006b gnugk } endpointAlias = 2 entries { [0]=h323_ID 5 characters { 0075 0073 0065 0072 0031 user1 } [1]=h323_ID 7 characters { 0050 0061 006f 006c 006f 0020 0050 Paolo P } } authenticationCapability = 2 entries { [0]=pwdHash <> [1]=authenticationBES radius <> } algorithmOIDs = 3 entries { [0]=0.0.8.235.0.2.6 [1]=1.2.840.113548.10.1.2.1 [2]=1.2.840.113549.2.5 } supportsAltGK = <> } 2006/11/16 15:32:42.995 1 RasSrv.cxx(344) RAS GRQ Received 2006/11/16 15:32:42.996 3 gkauth.h(834) GKAUTH SimplePasswordAuth GRQ check failed 2006/11/16 15:32:42.996 2 RasSrv.cxx(389) GRJ|192.168.0.2|user1:h323_ID=Paolo P:h323_ID|terminal|securityDenial; 2006/11/16 15:32:42.996 3 RasSrv.cxx(232) RAS Send to 192.168.0.2:5071 gatekeeperReject { requestSeqNum = 25269 protocolIdentifier = 0.0.8.2250.0.4 gatekeeperIdentifier = 5 characters { 0067 006e 0075 0067 006b gnugk } rejectReason = securityDenial <> } I think is Ekiga doesn't send the password to GnuGk in the GRQ message.I tried to check another RAS message like ARQ or RRQ but it doesn't work. I think the problem is that in the authenticationCapability section the pwdHash is set to NULL. Can anyone help me? Thanks... Sorry for my English...:-) --------------------------------- Check out the all-new Yahoo! Mail beta - Fire up a more powerful email and get things done faster. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbagger at gmail.com Thu Nov 16 20:21:52 2006 From: bbagger at gmail.com (Bent Bagger) Date: Thu, 16 Nov 2006 21:21:52 +0100 Subject: [Ekiga-list] Ekiga 2.0.3. calls for version 1.10.1 of libpt_linux_x86_r In-Reply-To: <1163677965.3257.16.camel@golgoth01> References: <2e19719f0611160027s6d619fa7hcddf5d05c676685@mail.gmail.com> <1163677965.3257.16.camel@golgoth01> Message-ID: <2e19719f0611161221x2948d888s5b0a86780b7c05d9@mail.gmail.com> Hi Damien On 16/11/06, Damien Sandras wrote: > > That means that when Ekiga was compiled, it linked against the old > libpt_linux which was still present in /usr/lib. > Your argumentation sounds convincing but I'm afraid that it does not stand. I did the following: - I deleted the old directories (opal-2.2.2, pwlib.1.10.1 and ekiga-2.0.2.) - I furthermore deleted ekiga-2.0.3 and unpacked the tar file once more - I deleted the link I had made from the 1.10.1 library to the 1.10.2 library - I rerun the build (./configue, make and make install) but Ekiga still comes out with the message: ekiga: error while loading shared libraries: libpt_linux_x86_r.so.1.10.1: cannot open shared object file: No such file or directory when I run it. If I didn't know better, I would conclude that the library version is somehow hard-wired into Ekiga... > The symlink you created is potentially dangerous and could lead to > unexpected crashes if the library is binary incompatible with the older > 1.10.1. > I hope not, and I believe it is safe, because even if Ekiga *thinks* it links to the 1.10.1 version it is actually linked to the 1.10.2 version. This is furthermore borne out by my tests: All the call I have made have been successful, including the one to 500 at ekiga.net - video end everything. Kind regards, Bent From jpuydt at free.fr Thu Nov 16 20:27:56 2006 From: jpuydt at free.fr (Julien Puydt) Date: Thu, 16 Nov 2006 21:27:56 +0100 Subject: [Ekiga-list] Ekiga 2.0.3. calls for version 1.10.1 of libpt_linux_x86_r In-Reply-To: <2e19719f0611161221x2948d888s5b0a86780b7c05d9@mail.gmail.com> References: <2e19719f0611160027s6d619fa7hcddf5d05c676685@mail.gmail.com> <1163677965.3257.16.camel@golgoth01> <2e19719f0611161221x2948d888s5b0a86780b7c05d9@mail.gmail.com> Message-ID: <455CC9CC.2030905@free.fr> Bent Bagger a ?crit : > If I didn't know better, I would conclude that the library version is > somehow hard-wired into Ekiga... It isn't. >> The symlink you created is potentially dangerous and could lead to >> unexpected crashes if the library is binary incompatible with the older >> 1.10.1. >> > I hope not, and I believe it is safe, because even if Ekiga *thinks* > it links to the 1.10.1 version it is actually linked to the 1.10.2 > version. It isn't ekiga which says so, it's the linker. If the linker thinks so, it's probably because you *do* have an old libpt*so file somewhere around. Look for that file, I'm pretty sure it's there somewhere. Snark on #ekiga From bbagger at gmail.com Thu Nov 16 21:24:47 2006 From: bbagger at gmail.com (Bent Bagger) Date: Thu, 16 Nov 2006 22:24:47 +0100 Subject: [Ekiga-list] Ekiga 2.0.3. calls for version 1.10.1 of libpt_linux_x86_r In-Reply-To: <455CC9CC.2030905@free.fr> References: <2e19719f0611160027s6d619fa7hcddf5d05c676685@mail.gmail.com> <1163677965.3257.16.camel@golgoth01> <2e19719f0611161221x2948d888s5b0a86780b7c05d9@mail.gmail.com> <455CC9CC.2030905@free.fr> Message-ID: <2e19719f0611161324x9d22eddt83f7ec80a4562238@mail.gmail.com> Hi Julien On 16/11/06, Julien Puydt wrote: > Bent Bagger a ?crit : > > If I didn't know better, I would conclude that the library version is > > somehow hard-wired into Ekiga... > > It isn't. > Just kidding. I forgot a ;-) > It isn't ekiga which says so, it's the linker. If the linker thinks so, > it's probably because you *do* have an old libpt*so file somewhere around. > > Look for that file, I'm pretty sure it's there somewhere. > I have serached the whole machine, both with 'locate' and 'find'. No trace of libpt_linux_x86_r.so.1.10.1. :-( I redid the build once more after having rerun 'ldconfig' - Same sad result.. The ./configure call ends with these lines: ================ Final configuration =================== Installing into prefix : /usr OPAL Version is : 2.2.3 OPAL Directory is : /usr PWLIB Version is : 1.10.2 PWLIB Directory is : /usr ptlib-config is : /usr/bin/ptlib-config SDL Fullscreen support : enabled DBUS support : disabled mDNS/DNS-SD support : disabled OS Type : linux-gnu Machine Type : i686 If all settings are OK, type make and make install ======================================================== Is this turning into a mystery? Kind regards, Bent From dsandras at seconix.com Thu Nov 16 21:40:20 2006 From: dsandras at seconix.com (Damien Sandras) Date: Thu, 16 Nov 2006 22:40:20 +0100 Subject: [Ekiga-list] Ekiga 2.0.3. calls for version 1.10.1 of libpt_linux_x86_r In-Reply-To: <2e19719f0611161324x9d22eddt83f7ec80a4562238@mail.gmail.com> References: <2e19719f0611160027s6d619fa7hcddf5d05c676685@mail.gmail.com> <1163677965.3257.16.camel@golgoth01> <2e19719f0611161221x2948d888s5b0a86780b7c05d9@mail.gmail.com> <455CC9CC.2030905@free.fr> <2e19719f0611161324x9d22eddt83f7ec80a4562238@mail.gmail.com> Message-ID: <1163713220.3582.1.camel@golgoth01> Le jeudi 16 novembre 2006 ? 22:24 +0100, Bent Bagger a ?crit : > > It isn't ekiga which says so, it's the linker. If the linker thinks so, > > it's probably because you *do* have an old libpt*so file somewhere around. > > > > Look for that file, I'm pretty sure it's there somewhere. > > > I have serached the whole machine, both with 'locate' and 'find'. No > trace of libpt_linux_x86_r.so.1.10.1. :-( > > I redid the build once more after having rerun 'ldconfig' - Same sad > result.. The ./configure call ends with these lines: > ================ Final configuration =================== > Installing into prefix : /usr > > OPAL Version is : 2.2.3 > OPAL Directory is : /usr > PWLIB Version is : 1.10.2 > PWLIB Directory is : /usr > ptlib-config is : /usr/bin/ptlib-config > > SDL Fullscreen support : enabled > DBUS support : disabled > mDNS/DNS-SD support : disabled > > OS Type : linux-gnu > Machine Type : i686 > > If all settings are OK, type make and make install > ======================================================== > > Is this turning into a mystery? > Unfortunately yes and I'm also 100% sure that if Ekiga requests libpt_linux_x86_r.so.1.10.1, it is because the instance you are trying to run was linked against it. Try ldd src/ekiga and ldd /usr/bin/ekiga and ldd /usr/local/bin/ekiga Damien From James.DiGuglielmo at aei.mpg.de Thu Nov 16 21:44:22 2006 From: James.DiGuglielmo at aei.mpg.de (James DiGuglielmo) Date: Thu, 16 Nov 2006 22:44:22 +0100 Subject: [Ekiga-list] Abnormal Call Termination Message-ID: Hi Damien, my posts keep getting held because the attached files are probably to big. They contain the full output from a very short ekiga session. How else can I send these? James From bbagger at gmail.com Thu Nov 16 21:50:25 2006 From: bbagger at gmail.com (Bent Bagger) Date: Thu, 16 Nov 2006 22:50:25 +0100 Subject: [Ekiga-list] Ekiga 2.0.3. calls for version 1.10.1 of libpt_linux_x86_r In-Reply-To: <1163713220.3582.1.camel@golgoth01> References: <2e19719f0611160027s6d619fa7hcddf5d05c676685@mail.gmail.com> <1163677965.3257.16.camel@golgoth01> <2e19719f0611161221x2948d888s5b0a86780b7c05d9@mail.gmail.com> <455CC9CC.2030905@free.fr> <2e19719f0611161324x9d22eddt83f7ec80a4562238@mail.gmail.com> <1163713220.3582.1.camel@golgoth01> Message-ID: <2e19719f0611161350k6dad548ao5fdabcfbe8fbd055@mail.gmail.com> Hi On 16/11/06, Damien Sandras wrote: > > Try ldd src/ekiga and ldd /usr/bin/ekiga and ldd /usr/local/bin/ekiga > Here goes: bent at yosie:/usr/local/src/ekiga-2.0.3> ldd src/ekiga | grep libpt libpt_linux_x86_r.so.1.10.2 => /usr/lib/libpt_linux_x86_r.so.1.10.2 (0xb6e79000) libpthread.so.0 => /lib/libpthread.so.0 (0xb6573000) bent at yosie:/usr/local/src/ekiga-2.0.3> ldd /usr/bin/ekiga | grep libpt libpt_linux_x86_r.so.1.10.2 => /usr/lib/libpt_linux_x86_r.so.1.10.2 (0xb6e39000) libpthread.so.0 => /lib/libpthread.so.0 (0xb6533000) bent at yosie:/usr/local/src/ekiga-2.0.3> ldd /usr/local/bin/ekiga | grep libpt ldd: /usr/local/bin/ekiga: No such file or directory bent at yosie:/usr/local/src/ekiga-2.0.3> I have used 'grep'. I hope it is OK. Ekiga links to quite a few libraries - 94 to be exact. BTW, if there is no obvious explanation to this, then don't use too much time on it. Just let it simmer in the back of your head. Eventually we will get the explanation, but for the time being I'm happy with the link and I can live with it. Bent From dsandras at seconix.com Thu Nov 16 21:59:40 2006 From: dsandras at seconix.com (Damien Sandras) Date: Thu, 16 Nov 2006 22:59:40 +0100 Subject: [Ekiga-list] Ekiga 2.0.3. calls for version 1.10.1 of libpt_linux_x86_r In-Reply-To: <2e19719f0611161350k6dad548ao5fdabcfbe8fbd055@mail.gmail.com> References: <2e19719f0611160027s6d619fa7hcddf5d05c676685@mail.gmail.com> <1163677965.3257.16.camel@golgoth01> <2e19719f0611161221x2948d888s5b0a86780b7c05d9@mail.gmail.com> <455CC9CC.2030905@free.fr> <2e19719f0611161324x9d22eddt83f7ec80a4562238@mail.gmail.com> <1163713220.3582.1.camel@golgoth01> <2e19719f0611161350k6dad548ao5fdabcfbe8fbd055@mail.gmail.com> Message-ID: <1163714380.3582.4.camel@golgoth01> Le jeudi 16 novembre 2006 ? 22:50 +0100, Bent Bagger a ?crit : > Hi > > On 16/11/06, Damien Sandras wrote: > > > > Try ldd src/ekiga and ldd /usr/bin/ekiga and ldd /usr/local/bin/ekiga > > > Here goes: > > bent at yosie:/usr/local/src/ekiga-2.0.3> ldd src/ekiga | grep libpt > libpt_linux_x86_r.so.1.10.2 => > /usr/lib/libpt_linux_x86_r.so.1.10.2 (0xb6e79000) > libpthread.so.0 => /lib/libpthread.so.0 (0xb6573000) > bent at yosie:/usr/local/src/ekiga-2.0.3> ldd /usr/bin/ekiga | grep libpt > libpt_linux_x86_r.so.1.10.2 => > /usr/lib/libpt_linux_x86_r.so.1.10.2 (0xb6e39000) > libpthread.so.0 => /lib/libpthread.so.0 (0xb6533000) > bent at yosie:/usr/local/src/ekiga-2.0.3> ldd /usr/local/bin/ekiga | grep libpt > ldd: /usr/local/bin/ekiga: No such file or directory > bent at yosie:/usr/local/src/ekiga-2.0.3> > > I have used 'grep'. I hope it is OK. Ekiga links to quite a few > libraries - 94 to be exact. > > BTW, if there is no obvious explanation to this, then don't use too > much time on it. Just let it simmer in the back of your head. > Eventually we will get the explanation, but for the time being I'm > happy with the link and I can live with it. And if you launch /usr/bin/ekiga Does it really need the link? Because ldd explicitely tells it has been linked to 1.10.2, not 1.10.1, so the version requiring 1.10.1 is probably not the one in /usr/bin ... Damien From dsandras at seconix.com Thu Nov 16 22:00:00 2006 From: dsandras at seconix.com (Damien Sandras) Date: Thu, 16 Nov 2006 23:00:00 +0100 Subject: [Ekiga-list] Abnormal Call Termination In-Reply-To: References: Message-ID: <1163714400.3582.5.camel@golgoth01> Le jeudi 16 novembre 2006 ? 22:44 +0100, James DiGuglielmo a ?crit : > Hi Damien, > > my posts keep getting held because the attached files are probably > to big. They contain the full output from a very short ekiga > session. How else can I send these? > Use pastebin... -- Damien Sandras Ekiga Softphone : http://www.ekiga.org NOVACOM : http://www.novacom.be FOSDEM : http://www.fosdem.org SIP Phone : sip:dsandras at ekiga.net From lurch at gmx.li Fri Nov 17 02:26:52 2006 From: lurch at gmx.li (Stefan Bruens) Date: Fri, 17 Nov 2006 03:26:52 +0100 Subject: [Ekiga-list] =?iso-8859-15?q?Ekiga_2=2E0=2E3=2E_calls_for_version?= =?iso-8859-15?q?_1=2E10=2E1=09of_libpt=5Flinux=5Fx86=5Fr?= In-Reply-To: <1163713220.3582.1.camel@golgoth01> References: <2e19719f0611160027s6d619fa7hcddf5d05c676685@mail.gmail.com> <2e19719f0611161324x9d22eddt83f7ec80a4562238@mail.gmail.com> <1163713220.3582.1.camel@golgoth01> Message-ID: <200611170326.59828.lurch@gmx.li> Am Donnerstag, 16. November 2006 22:40 schrieb Damien Sandras: > Unfortunately yes and I'm also 100% sure that if Ekiga requests > libpt_linux_x86_r.so.1.10.1, it is because the instance you are > trying to run was linked against it. > > Try ldd src/ekiga and ldd /usr/bin/ekiga and ldd /usr/local/bin/ekiga I think Damien meant to say: ldd `which ekiga` | grep libpt Cu, Lurchi -- Stefan Br?ns / Kastanienweg 6 - Zimmer 1206 / 52074 Aachen mailto:lurch at gmx.li http://www.kawo1.rwth-aachen.de/~lurchi/ phone: +49 241 169-4206 mobile: +49 160 3797725 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bbagger at gmail.com Fri Nov 17 08:54:14 2006 From: bbagger at gmail.com (Bent Bagger) Date: Fri, 17 Nov 2006 09:54:14 +0100 Subject: [Ekiga-list] Ekiga 2.0.3. calls for version 1.10.1 of libpt_linux_x86_r In-Reply-To: <1163714380.3582.4.camel@golgoth01> References: <2e19719f0611160027s6d619fa7hcddf5d05c676685@mail.gmail.com> <1163677965.3257.16.camel@golgoth01> <2e19719f0611161221x2948d888s5b0a86780b7c05d9@mail.gmail.com> <455CC9CC.2030905@free.fr> <2e19719f0611161324x9d22eddt83f7ec80a4562238@mail.gmail.com> <1163713220.3582.1.camel@golgoth01> <2e19719f0611161350k6dad548ao5fdabcfbe8fbd055@mail.gmail.com> <1163714380.3582.4.camel@golgoth01> Message-ID: <2e19719f0611170054j1ee563f6k40f27efa5b06fd4f@mail.gmail.com> Solved!!! It was Opal that was the culprit. When I grepped for libpt in the sources: bent at yosie:/usr/local/src> grep -r libpt_linux * Binary file ekiga-2.0.3/src/ekiga matches ekiga-2.0.3/config.log:/usr/lib/gcc/i586-suse-linux/4.1.0/../../../../i586-suse-linux/bin/ld: warning: libpt_linux_x86_r.so.1.10.1, needed by /usr/lib//libopal.so, not found (try using -rpath or -rpath-link) something dawned upon me: I had not rebuit Opal after having deleted the old sources. When I did that, the problem disappeared. There is a morale in this, but I'm not quite sure which ;-) Anyway, thanks for your help. It is nice to know that there is somebody out there, ready to help. Best regards, Bent From jpuydt at free.fr Fri Nov 17 08:58:20 2006 From: jpuydt at free.fr (Julien Puydt) Date: Fri, 17 Nov 2006 09:58:20 +0100 Subject: [Ekiga-list] Ekiga 2.0.3. calls for version 1.10.1 of libpt_linux_x86_r In-Reply-To: <2e19719f0611170054j1ee563f6k40f27efa5b06fd4f@mail.gmail.com> References: <2e19719f0611160027s6d619fa7hcddf5d05c676685@mail.gmail.com> <1163677965.3257.16.camel@golgoth01> <2e19719f0611161221x2948d888s5b0a86780b7c05d9@mail.gmail.com> <455CC9CC.2030905@free.fr> <2e19719f0611161324x9d22eddt83f7ec80a4562238@mail.gmail.com> <1163713220.3582.1.camel@golgoth01> <2e19719f0611161350k6dad548ao5fdabcfbe8fbd055@mail.gmail.com> <1163714380.3582.4.camel@golgoth01> <2e19719f0611170054j1ee563f6k40f27efa5b06fd4f@mail.gmail.com> Message-ID: <455D79AC.8040106@free.fr> Bent Bagger a ?crit : > There is a morale in this, but I'm not quite sure which ;-) The morale is that you always have to build pwlib, then opal, then ekiga. Snark From bbagger at gmail.com Fri Nov 17 09:11:59 2006 From: bbagger at gmail.com (Bent Bagger) Date: Fri, 17 Nov 2006 10:11:59 +0100 Subject: [Ekiga-list] Ekiga 2.0.3. calls for version 1.10.1 of libpt_linux_x86_r In-Reply-To: <455D79AC.8040106@free.fr> References: <2e19719f0611160027s6d619fa7hcddf5d05c676685@mail.gmail.com> <1163677965.3257.16.camel@golgoth01> <2e19719f0611161221x2948d888s5b0a86780b7c05d9@mail.gmail.com> <455CC9CC.2030905@free.fr> <2e19719f0611161324x9d22eddt83f7ec80a4562238@mail.gmail.com> <1163713220.3582.1.camel@golgoth01> <2e19719f0611161350k6dad548ao5fdabcfbe8fbd055@mail.gmail.com> <1163714380.3582.4.camel@golgoth01> <2e19719f0611170054j1ee563f6k40f27efa5b06fd4f@mail.gmail.com> <455D79AC.8040106@free.fr> Message-ID: <2e19719f0611170111p3f60e8fai1491102b65fbaeb7@mail.gmail.com> Hi Julien On 17/11/06, Julien Puydt wrote: > > The morale is that you always have to build pwlib, then opal, then ekiga. > Well, I did, but I did not do 'make uninstall' in the old directories, so somehow Opal picked up the 1.10.1 version of libpt although the 1.10.2 was also present. Bent From James.DiGuglielmo at aei.mpg.de Fri Nov 17 18:33:42 2006 From: James.DiGuglielmo at aei.mpg.de (James DiGuglielmo) Date: Fri, 17 Nov 2006 19:33:42 +0100 Subject: [Ekiga-list] Abnormal Call Termination Message-ID: Hi Damien, I have now posted the full output at http://pastebin.com/826793 or look under the name james. I started the program, did an echo test, which was successful, and tried to make a call, only to get "Abnormal call termination". James From cwg at falma.de Fri Nov 17 19:09:03 2006 From: cwg at falma.de (Christoph Groth) Date: Fri, 17 Nov 2006 20:09:03 +0100 Subject: [Ekiga-list] connection, but no sound Message-ID: <87lkm96gc0.fsf@falma.de> Hi all, I would like to call a friend with ekiga. Both of us sit behind a router/firewall: Mine is configured to forward UDP ports 5000-5100 to my machine. I do not know anything about my friend's firewall. We both have accounts with at the German sip-phone-service "web.de freephone". Using this service communication works. Both of us can call other (traditional) phones via the web.de gateway. Also I can call my friend. I think web.de is routing all the media data, because when we connect via web.de we are both forced to PCMU and the service quality is quite bad. Furthermore it is often necessary to try setting up a call many times until it actually succeeds. That is why we tried using ekiga.net accounts. This time we can reliably achieve a connection either way at the first try. SPEEX is being negotiated as audio codec, however, no one can hear anything. After receiving ACK from the other computer my machine keeps logging things like: 2006/11/15 22:46:30.623 0:24.037 SIP Transport:848c368 SIP Queueing PDU: 1 ACK sip:cwg at 86.83.156.104:5065;transport=udp 2006/11/15 22:46:30.623 0:24.037 SIP Transport:848c368 SIP Waiting for PDU on udp$213.186.62.145:5060 2006/11/15 22:46:30.623 0:24.037 SIP Handler:84acae0 SIP Handling PDU 1 ACK sip:cwg at 86.83.156.104:5065;transport=udp 2006/11/15 22:46:30.623 0:24.038 SIP Handler:84acae0 SIP ACK received: ConnectedPhase 2006/11/15 22:46:30.624 0:24.038 SIP Handler:84acae0 GMSIPEndpoint SIP connection established 2006/11/15 22:46:30.634 0:24.048 SIP Handler:84acae0 RTP Found existing session 1 2006/11/15 22:46:30.634 0:24.048 SIP Handler:84acae0 RTP Found existing session 2 2006/11/15 22:46:30.634 0:24.048 SIP Handler:84acae0 GMManager Will establish the connection 2006/11/15 22:46:30.634 0:24.048 SIP Handler:84acae0 OpalMan OnEstablished Call[1]-EP[e6f8f96b-6073-db11-95ca-0003c909570f at spheniscus] 2006/11/15 22:46:30.634 0:24.048 SIP Handler:84acae0 Call OnEstablished Call[1]-EP[e6f8f96b-6073-db11-95ca-0003c909570f at spheniscus] 2006/11/15 22:46:30.637 0:24.051 SIP Handler:84acae0 OpalCon Media stream threads started. 2006/11/15 22:46:30.637 0:24.051 SIP Handler:84acae0 SIP Awaiting next PDU. 2006/11/15 22:46:30.688 0:24.103 Media Patch:8396180 Silence Threshold increased to: 7 2006/11/15 22:46:31.008 0:24.423 Media Patch:8396180 Silence Threshold increased to: 8 2006/11/15 22:46:31.328 0:24.742 Media Patch:8396180 Silence Threshold increased to: 9 2006/11/15 22:46:31.637 0:25.051 Housekeeper RTP Found existing session 1 2006/11/15 22:46:31.637 0:25.051 Housekeeper RTP Found existing session 2 2006/11/15 22:46:31.648 0:25.062 Media Patch:8396180 Silence Threshold increased to: 10 2006/11/15 22:46:31.968 0:25.382 Media Patch:8396180 Silence Threshold increased to: 11 2006/11/15 22:46:32.288 0:25.702 Media Patch:8396180 Silence Threshold increased to: 12 2006/11/15 22:46:32.349 0:25.763 Media Patch:8396180 RTP Transmit statistics: packets=101 octets=5252 avgTime=20 maxTime=40 minTime=16 2006/11/15 22:46:32.608 0:26.022 Media Patch:8396180 Silence Threshold increased to: 13 I wonder if someone has an idea how to solve this problem? I especially wonder why RTP works with the web.de service but not with ekiga.net. Thank you in advance Christoph From welko at web.de Sat Nov 18 11:46:20 2006 From: welko at web.de (Velko Hristov) Date: Sat, 18 Nov 2006 12:46:20 +0100 Subject: [Ekiga-list] No audio - small red exclamation icon Message-ID: <20061118124620.38b27409.welko@web.de> Hello, I'm trying to connect with ekiga to my parents and the video connection is OK. After we connect they get an audio error message and a small red exclamation icon is shown over the main ekiga icon in the system tray. Initially I thought it may indicate a sound card full duplex problem and urged them to buy another sound card. Now with the new one the problem persist. I tried to look up google and the mail archives about this problem but looking for "small red exclamation" has not been the most rewarding experience. Could somebody tell me what this icon means? Thank you - Velko -- When the only tool you own is a hammer, every problem begins to resemble a nail. -- Abraham Maslow From dsandras at seconix.com Sat Nov 18 12:59:53 2006 From: dsandras at seconix.com (Damien Sandras) Date: Sat, 18 Nov 2006 13:59:53 +0100 Subject: [Ekiga-list] Abnormal Call Termination In-Reply-To: References: Message-ID: <1163854793.3581.18.camel@golgoth01> Hi James, Unfortunately the log is not complete. However, I looked in the administrative interface of the mailing list and found your email that was rejected because it was too big. It seems that when you are calling out, you are not calling the right thing. You should call : sip:yournumber at eugw.ast.diamondcard.us or sip:00yournumber if you are registered to ekiga.net and to diamondcard, if ekiga.net is set as the default account. Ekiga should rewrite sip:00yournumber into sip:yournumber at eugw.ast.diamondcard.us Please also notice that upgrading to 2.0.3 might be a great idea! Le vendredi 17 novembre 2006 ? 19:33 +0100, James DiGuglielmo a ?crit : > Hi Damien, > > I have now posted the full output at http://pastebin.com/826793 or > look under the name james. I started the program, did an echo test, > which was successful, and tried to make a call, only to get "Abnormal > call termination". > > James > > _______________________________________________ > ekiga-list mailing list > ekiga-list at gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list -- Damien Sandras Ekiga Softphone : http://www.ekiga.org NOVACOM : http://www.novacom.be FOSDEM : http://www.fosdem.org SIP Phone : sip:dsandras at ekiga.net From dsandras at seconix.com Sat Nov 18 13:01:24 2006 From: dsandras at seconix.com (Damien Sandras) Date: Sat, 18 Nov 2006 14:01:24 +0100 Subject: [Ekiga-list] connection, but no sound In-Reply-To: <87lkm96gc0.fsf@falma.de> References: <87lkm96gc0.fsf@falma.de> Message-ID: <1163854884.3581.20.camel@golgoth01> Le vendredi 17 novembre 2006 ? 20:09 +0100, Christoph Groth a ?crit : > Hi all, > > I would like to call a friend with ekiga. Both of us sit behind a > router/firewall: Mine is configured to forward UDP ports 5000-5100 to > my machine. I do not know anything about my friend's firewall. > > We both have accounts with at the German sip-phone-service "web.de > freephone". Using this service communication works. Both of us can > call other (traditional) phones via the web.de gateway. Also I can > call my friend. I think web.de is routing all the media data, because > when we connect via web.de we are both forced to PCMU and the service > quality is quite bad. Furthermore it is often necessary to try > setting up a call many times until it actually succeeds. > > That is why we tried using ekiga.net accounts. This time we can > reliably achieve a connection either way at the first try. SPEEX is > being negotiated as audio codec, however, no one can hear anything. > > After receiving ACK from the other computer my machine keeps logging > things like: > > 2006/11/15 22:46:30.623 0:24.037 SIP Transport:848c368 SIP Queueing PDU: 1 ACK sip:cwg at 86.83.156.104:5065;transport=udp > 2006/11/15 22:46:30.623 0:24.037 SIP Transport:848c368 SIP Waiting for PDU on udp$213.186.62.145:5060 > 2006/11/15 22:46:30.623 0:24.037 SIP Handler:84acae0 SIP Handling PDU 1 ACK sip:cwg at 86.83.156.104:5065;transport=udp > 2006/11/15 22:46:30.623 0:24.038 SIP Handler:84acae0 SIP ACK received: ConnectedPhase > 2006/11/15 22:46:30.624 0:24.038 SIP Handler:84acae0 GMSIPEndpoint SIP connection established > 2006/11/15 22:46:30.634 0:24.048 SIP Handler:84acae0 RTP Found existing session 1 > 2006/11/15 22:46:30.634 0:24.048 SIP Handler:84acae0 RTP Found existing session 2 > 2006/11/15 22:46:30.634 0:24.048 SIP Handler:84acae0 GMManager Will establish the connection > 2006/11/15 22:46:30.634 0:24.048 SIP Handler:84acae0 OpalMan OnEstablished Call[1]-EP[e6f8f96b-6073-db11-95ca-0003c909570f at spheniscus] > 2006/11/15 22:46:30.634 0:24.048 SIP Handler:84acae0 Call OnEstablished Call[1]-EP[e6f8f96b-6073-db11-95ca-0003c909570f at spheniscus] > 2006/11/15 22:46:30.637 0:24.051 SIP Handler:84acae0 OpalCon Media stream threads started. > 2006/11/15 22:46:30.637 0:24.051 SIP Handler:84acae0 SIP Awaiting next PDU. > 2006/11/15 22:46:30.688 0:24.103 Media Patch:8396180 Silence Threshold increased to: 7 > 2006/11/15 22:46:31.008 0:24.423 Media Patch:8396180 Silence Threshold increased to: 8 > 2006/11/15 22:46:31.328 0:24.742 Media Patch:8396180 Silence Threshold increased to: 9 > 2006/11/15 22:46:31.637 0:25.051 Housekeeper RTP Found existing session 1 > 2006/11/15 22:46:31.637 0:25.051 Housekeeper RTP Found existing session 2 > 2006/11/15 22:46:31.648 0:25.062 Media Patch:8396180 Silence Threshold increased to: 10 > 2006/11/15 22:46:31.968 0:25.382 Media Patch:8396180 Silence Threshold increased to: 11 > 2006/11/15 22:46:32.288 0:25.702 Media Patch:8396180 Silence Threshold increased to: 12 > 2006/11/15 22:46:32.349 0:25.763 Media Patch:8396180 RTP Transmit statistics: packets=101 octets=5252 avgTime=20 maxTime=40 minTime=16 > 2006/11/15 22:46:32.608 0:26.022 Media Patch:8396180 Silence Threshold increased to: 13 > > I wonder if someone has an idea how to solve this problem? I > especially wonder why RTP works with the web.de service but not with > ekiga.net. > Please post a full output. Again, I would say that for some obscure reason your router is not relaying the media. -- Damien Sandras Ekiga Softphone : http://www.ekiga.org NOVACOM : http://www.novacom.be FOSDEM : http://www.fosdem.org SIP Phone : sip:dsandras at ekiga.net From dsandras at seconix.com Sat Nov 18 13:04:00 2006 From: dsandras at seconix.com (Damien Sandras) Date: Sat, 18 Nov 2006 14:04:00 +0100 Subject: [Ekiga-list] No audio - small red exclamation icon In-Reply-To: <20061118124620.38b27409.welko@web.de> References: <20061118124620.38b27409.welko@web.de> Message-ID: <1163855040.3581.24.camel@golgoth01> Hi, Le samedi 18 novembre 2006 ? 12:46 +0100, Velko Hristov a ?crit : > Hello, > > I'm trying to connect with ekiga to my parents and the video > connection is OK. After we connect they get an audio error message and a > small red exclamation icon is shown over the main ekiga icon in the > system tray. Initially I thought it may indicate a sound card full > duplex problem and urged them to buy another sound card. Now with the > new one the problem persist. > I would say that another process is locking the soundcard. If they are using Ubuntu, there are many bugs. One of them is that ESD is always locking the soundcard, even when it is told not to lock it at all. That's one of the numerous bugs in the distribution. > I tried to look up google and the mail archives about this problem but > looking for "small red exclamation" has not been the most rewarding > experience. Could somebody tell me what this icon means? Unfortunately, I have no idea. There is no exclamation mark icon in Ekiga, and I have never coded something that would display such an exclamation mark in the status icon. Perhaps they can do a screenshot? -- Damien Sandras Ekiga Softphone : http://www.ekiga.org NOVACOM : http://www.novacom.be FOSDEM : http://www.fosdem.org SIP Phone : sip:dsandras at ekiga.net From dsandras at seconix.com Sat Nov 18 15:42:05 2006 From: dsandras at seconix.com (Damien Sandras) Date: Sat, 18 Nov 2006 16:42:05 +0100 Subject: [Ekiga-list] direct connection does not work. why? In-Reply-To: <87d57kn7rl.fsf@falma.de> References: <877ixw6ehs.fsf@falma.de> <1163607060.15913.6.camel@golgoth01> <87psbnrxvv.fsf@falma.de> <1163709677.4201.24.camel@golgoth01> <87psbl6h1g.fsf@falma.de> <1163856470.3581.48.camel@golgoth01> <87d57kn7rl.fsf@falma.de> Message-ID: <1163864525.3581.67.camel@golgoth01> Hi, In ekiga1.gz, I see you receive this PDU : INVITE sip:cwg at 192.168.1.80:5063;transport=udp SIP/2.0 It means that the the direct connection happens from a machine behind the same NAT (as you can reach it using a private IP address). The SDP in the INVITE contains this : 132.229.227.85 The problem is that it will send data to the public IP address (as STUN is active), leading to that problem. Very few NAT implementations will allow a packet coming from the inside to the public interface going back to the inside, even if the port on the public interface is associated with the internal machine. When STUN determines that port XYZ on the public interface is associated to port ABC on some internal machine, in most of the cases, a packet reaching port XYZ on the public interface will only be forwarded to the internal machine, port ABC, only if it comes from the outside. As you have configured port forwarding, make sure it also works for packets coming from the inside. Anyway, the end of the log clearly indicates you receive no data at all. Le samedi 18 novembre 2006 ? 15:34 +0100, Christoph Groth a ?crit : > Hi, > > of course, I had forgotten the attachements. Both logs are from > machine B. > > bye > Christoph -- Damien Sandras Ekiga Softphone : http://www.ekiga.org NOVACOM : http://www.novacom.be FOSDEM : http://www.fosdem.org SIP Phone : sip:dsandras at ekiga.net From dsandras at seconix.com Sat Nov 18 15:50:41 2006 From: dsandras at seconix.com (Damien Sandras) Date: Sat, 18 Nov 2006 16:50:41 +0100 Subject: [Ekiga-list] complete logs for "connection, but no sound" In-Reply-To: <878xi8n7db.fsf@falma.de> References: <878xi8n7db.fsf@falma.de> Message-ID: <1163865041.3581.73.camel@golgoth01> Hi, Suddenly, I understood what was the problem. This : INVITE sip:cwg at 192.168.1.80:5063;transport=udp SIP/2.0 is clearly not normal, except if the remote person typed sip:cwg at 192.168.1.80:5063 in the URL bar of Ekiga. I think you are the happy owner of one of those crappy routers (sorry) that thinks understands SIP. The role of a router that understands SIP is to replace all occurrences of private IP addresses by the public IP address and the corresponding port. Apparently, your router is also doing the opposite, ie replacing public IP addresses (coming from STUN or IP Translation) by private ones, which doesn't make sense. Perhaps you could try to disable SIP support in your router. You could also try keeping it enabled and not configure STUN or IP translation at all. I don't really know, but having the INVITE URL I see is clearly not normal. And from Ekiga's point of view, the routing of the messages is normal. It just happens that audio and video streams do not reach it. Le samedi 18 novembre 2006 ? 15:42 +0100, Christoph Groth a ?crit : > Hi Damien, > > here are the complete logs taken from my machine, maybe you can give > me some hints. I'll check out the router of Elisa's (my friend's) > machine on the next time I have opportunity to do so. > > Christoph -- Damien Sandras Ekiga Softphone : http://www.ekiga.org NOVACOM : http://www.novacom.be FOSDEM : http://www.fosdem.org SIP Phone : sip:dsandras at ekiga.net From James.DiGuglielmo at aei.mpg.de Sat Nov 18 16:50:49 2006 From: James.DiGuglielmo at aei.mpg.de (James DiGuglielmo) Date: Sat, 18 Nov 2006 17:50:49 +0100 Subject: [Ekiga-list] Abnormal Call Termination Message-ID: Thank you Damien, I did the upgrade and have been able to make some phone calls. James From welko at web.de Sat Nov 18 19:14:34 2006 From: welko at web.de (Velko Hristov) Date: Sat, 18 Nov 2006 20:14:34 +0100 Subject: [Ekiga-list] No audio - small red exclamation icon In-Reply-To: <1163855040.3581.24.camel@golgoth01> References: <20061118124620.38b27409.welko@web.de> <1163855040.3581.24.camel@golgoth01> Message-ID: <20061118201434.93b0a1df.welko@web.de> On Sat, 18 Nov 2006 14:04:00 +0100 Damien Sandras wrote: Hi, thank you for the quick response. > I would say that another process is locking the soundcard. If they are > using Ubuntu, there are many bugs. One of them is that ESD is always > locking the soundcard, even when it is told not to lock it at all. > That's one of the numerous bugs in the distribution. Indeed - it's Ubuntu. I stopped ESD and all other programs which use the sound card for no avail. I'll attach the exclamation sign to this email. Some ideas what might be wrong, anyone? Thank you - Velko -- It's not manufacturers trying to rip anybody off or anything like that. There's nobody getting rich writing software that I know of. -- Bill Gates (1980) -------------- next part -------------- A non-text attachment was scrubbed... Name: exclam.png Type: image/png Size: 899 bytes Desc: not available URL: From jpuydt at free.fr Sat Nov 18 19:55:27 2006 From: jpuydt at free.fr (Julien Puydt) Date: Sat, 18 Nov 2006 20:55:27 +0100 Subject: [Ekiga-list] No audio - small red exclamation icon In-Reply-To: <20061118124620.38b27409.welko@web.de> References: <20061118124620.38b27409.welko@web.de> Message-ID: <455F652F.3050302@free.fr> Velko Hristov a ?crit : > Hello, > > I'm trying to connect with ekiga to my parents and the video > connection is OK. After we connect they get an audio error message and a > small red exclamation icon is shown over the main ekiga icon in the > system tray. Initially I thought it may indicate a sound card full > duplex problem and urged them to buy another sound card. Now with the > new one the problem persist. > > I tried to look up google and the mail archives about this problem but > looking for "small red exclamation" has not been the most rewarding > experience. Could somebody tell me what this icon means? Of course you didn't find that icon in the archives... it's an ubuntu patch ; after some research it means you're in a call. Snark on #ekiga From geboyd53 at comcast.net Sat Nov 18 21:04:00 2006 From: geboyd53 at comcast.net (George Boyd) Date: Sat, 18 Nov 2006 13:04:00 -0800 Subject: [Ekiga-list] Sources For 2.03 Message-ID: <1163883840.17662.3.camel@george> Damien, where can I get the sources for 2.03? I had offered to help Johhny make RPM's for Fedora Core 6, but as yet he hasn't sent me the program he was using to do it. I would like to compile them for myself. I'm not sure how to do it and make them publicly available, but if I can get a little help, I'll be glad to try. George From welko at web.de Sat Nov 18 21:26:54 2006 From: welko at web.de (Velko Hristov) Date: Sat, 18 Nov 2006 22:26:54 +0100 Subject: [Ekiga-list] No audio - small red exclamation icon In-Reply-To: <455F652F.3050302@free.fr> References: <20061118124620.38b27409.welko@web.de> <455F652F.3050302@free.fr> Message-ID: <20061118222654.3a401d53.welko@web.de> On Sat, 18 Nov 2006 20:55:27 +0100 Julien Puydt wrote: > Of course you didn't find that icon in the archives... it's an ubuntu > patch ; after some research it means you're in a call. So this is not an error indication?!? Can some Ubuntu user who uses Ekiga successfully confirm that information please? > Snark on #ekiga I tried but I was scared away by the "Do not ask here support questions" topic :-) Greetings - Velko -- Giving the Linus Torvalds Award to the Free Software Foundation is a bit like giving the Han Solo Award to the Rebel Alliance. -- Richard Stallman upon receiving the Linus Torvalds Award From typhoon at aanet.com.au Sat Nov 18 23:57:39 2006 From: typhoon at aanet.com.au (Typhoon) Date: Sun, 19 Nov 2006 10:57:39 +1100 Subject: [Ekiga-list] No audio - small red exclamation icon In-Reply-To: <20061118222654.3a401d53.welko@web.de> References: <20061118124620.38b27409.welko@web.de> <455F652F.3050302@free.fr> <20061118222654.3a401d53.welko@web.de> Message-ID: <20061119105739.f5fbcd9f.typhoon@aanet.com.au> On Sat, 18 Nov 2006 22:26:54 +0100 Velko Hristov wrote: > On Sat, 18 Nov 2006 20:55:27 +0100 > Julien Puydt wrote: > > > Of course you didn't find that icon in the archives... it's an > > ubuntu patch ; after some research it means you're in a call. > > So this is not an error indication?!? Can some Ubuntu user who uses > Ekiga successfully confirm that information please? I can confirm it. It looks like an error marker, but in fact it shows a call in progress. Ubuntu Edgy. Alan > > > Snark on #ekiga > > I tried but I was scared away by the "Do not ask here support > questions" topic :-) > > Greetings - Velko > > -- > Giving the Linus Torvalds Award to the Free Software Foundation > is a bit like giving the Han Solo Award to the Rebel Alliance. > -- Richard Stallman upon receiving the Linus Torvalds Award > _______________________________________________ > ekiga-list mailing list > ekiga-list at gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list > From jpuydt at free.fr Sun Nov 19 06:40:42 2006 From: jpuydt at free.fr (Julien Puydt) Date: Sun, 19 Nov 2006 07:40:42 +0100 Subject: [Ekiga-list] Sources For 2.03 In-Reply-To: <1163883840.17662.3.camel@george> References: <1163883840.17662.3.camel@george> Message-ID: <455FFC6A.3000100@free.fr> George Boyd a ?crit : > Damien, where can I get the sources for 2.03? I had offered to help > Johhny make RPM's for Fedora Core 6, but as yet he hasn't sent me the > program he was using to do it. I would like to compile them for myself. > I'm not sure how to do it and make them publicly available, but if I can > get a little help, I'll be glad to try. Uh... don't we have them in the download section of ekiga.org !? Snark on #ekiga From cwg at falma.de Sun Nov 19 11:50:47 2006 From: cwg at falma.de (Christoph Groth) Date: Sun, 19 Nov 2006 12:50:47 +0100 Subject: [Ekiga-list] logitech quickcam messenger: video image not scaled Message-ID: <87k61r7izs.fsf@falma.de> Hi, I tried a "logitech quickcam messenger" webcam with Ekiga. The linux kernel has build-in support for this model since 2.6.18. The cam works fine, but the image it produces (320x240) is not being scaled down by Ekiga 2.0.3 (Debian testing). Christoph From dsandras at seconix.com Sun Nov 19 14:03:21 2006 From: dsandras at seconix.com (Damien Sandras) Date: Sun, 19 Nov 2006 15:03:21 +0100 Subject: [Ekiga-list] complete logs for "connection, but no sound" In-Reply-To: <87odr37j68.fsf@falma.de> References: <878xi8n7db.fsf@falma.de> <1163865041.3581.73.camel@golgoth01> <87odr37j68.fsf@falma.de> Message-ID: <1163945001.4865.8.camel@golgoth01> Hi! Le dimanche 19 novembre 2006 ? 12:46 +0100, Christoph Groth a ?crit : > Hi Damien, > > you were right: the router was somehow half-knowingly meddling with > the SIP communication. I had to tell him > > :connection unbind application=SIP port=5060 > > That did the trick (I have a speedtouch 716). > Thanks for the feedback, good to know it works! > Thanks a lot for the help! > > Christoph -- Damien Sandras Ekiga Softphone : http://www.ekiga.org NOVACOM : http://www.novacom.be FOSDEM : http://www.fosdem.org SIP Phone : sip:dsandras at ekiga.net From dsandras at seconix.com Sun Nov 19 14:04:24 2006 From: dsandras at seconix.com (Damien Sandras) Date: Sun, 19 Nov 2006 15:04:24 +0100 Subject: [Ekiga-list] logitech quickcam messenger: video image not scaled In-Reply-To: <87k61r7izs.fsf@falma.de> References: <87k61r7izs.fsf@falma.de> Message-ID: <1163945064.4865.10.camel@golgoth01> Hi, Is it cropped by the driver or by ekiga itself? Le dimanche 19 novembre 2006 ? 12:50 +0100, Christoph Groth a ?crit : > Hi, > > I tried a "logitech quickcam messenger" webcam with Ekiga. The linux > kernel has build-in support for this model since 2.6.18. > > The cam works fine, but the image it produces (320x240) is not being > scaled down by Ekiga 2.0.3 (Debian testing). > > Christoph > _______________________________________________ > ekiga-list mailing list > ekiga-list at gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list -- Damien Sandras Ekiga Softphone : http://www.ekiga.org NOVACOM : http://www.novacom.be FOSDEM : http://www.fosdem.org SIP Phone : sip:dsandras at ekiga.net From cwg at falma.de Sun Nov 19 14:09:39 2006 From: cwg at falma.de (Christoph Groth) Date: Sun, 19 Nov 2006 15:09:39 +0100 Subject: [Ekiga-list] logitech quickcam messenger: video image not scaled In-Reply-To: <1163945064.4865.10.camel@golgoth01> (Damien Sandras's message of "Sun, 19 Nov 2006 15:04:24 +0100") References: <87k61r7izs.fsf@falma.de> <1163945064.4865.10.camel@golgoth01> Message-ID: <87fycf7ckc.fsf@falma.de> Damien Sandras writes: > > Is it cropped by the driver or by ekiga itself? Other programs (like gqcam) show the image in 320x240, uncropped. Christoph From dsandras at seconix.com Sun Nov 19 14:25:23 2006 From: dsandras at seconix.com (Damien Sandras) Date: Sun, 19 Nov 2006 15:25:23 +0100 Subject: [Ekiga-list] logitech quickcam messenger: video image not scaled In-Reply-To: <87fycf7ckc.fsf@falma.de> References: <87k61r7izs.fsf@falma.de> <1163945064.4865.10.camel@golgoth01> <87fycf7ckc.fsf@falma.de> Message-ID: <1163946323.4865.12.camel@golgoth01> Le dimanche 19 novembre 2006 ? 15:09 +0100, Christoph Groth a ?crit : > Damien Sandras writes: > > > > > Is it cropped by the driver or by ekiga itself? > > Other programs (like gqcam) show the image in 320x240, uncropped. > Sure, but what happens if other programs request the same size than Ekiga to the driver? (176x144 or 352x288) ? -- Damien Sandras Ekiga Softphone : http://www.ekiga.org NOVACOM : http://www.novacom.be FOSDEM : http://www.fosdem.org SIP Phone : sip:dsandras at ekiga.net From cwg at falma.de Sun Nov 19 15:47:39 2006 From: cwg at falma.de (Christoph Groth) Date: Sun, 19 Nov 2006 16:47:39 +0100 Subject: [Ekiga-list] logitech quickcam messenger: video image not scaled In-Reply-To: <1163946323.4865.12.camel@golgoth01> (Damien Sandras's message of "Sun, 19 Nov 2006 15:25:23 +0100") References: <87k61r7izs.fsf@falma.de> <1163945064.4865.10.camel@golgoth01> <87fycf7ckc.fsf@falma.de> <1163946323.4865.12.camel@golgoth01> Message-ID: <87bqn37810.fsf@falma.de> Damien Sandras writes: >> > >> > Is it cropped by the driver or by ekiga itself? >> >> Other programs (like gqcam) show the image in 320x240, uncropped. >> > > Sure, but what happens if other programs request the same size than > Ekiga to the driver? (176x144 or 352x288) ? I'm new to V4L. If you give me a hint how to try this out, I will do it. Christoph From antoine.boutet at irisa.fr Mon Nov 20 09:21:32 2006 From: antoine.boutet at irisa.fr (aboutet) Date: Mon, 20 Nov 2006 10:21:32 +0100 Subject: [Ekiga-list] Ekiga & IPv6 In-Reply-To: <2e19719f0611161221x2948d888s5b0a86780b7c05d9@mail.gmail.com> References: <2e19719f0611160027s6d619fa7hcddf5d05c676685@mail.gmail.com> <1163677965.3257.16.camel@golgoth01> <2e19719f0611161221x2948d888s5b0a86780b7c05d9@mail.gmail.com> Message-ID: <4561739C.9020903@irisa.fr> Hi all, Gnomemeeting was very useful to test stack IPv6, network or other things based on IPv6. Ekiga is its successor but does not support this protocol and gnommeting is now not available per default in a majority of repositories. Is it planned to add IPv6 support ? Thanks, Antoine From jpuydt at free.fr Mon Nov 20 09:44:28 2006 From: jpuydt at free.fr (Julien Puydt) Date: Mon, 20 Nov 2006 10:44:28 +0100 Subject: [Ekiga-list] Ekiga & IPv6 In-Reply-To: <4561739C.9020903@irisa.fr> References: <2e19719f0611160027s6d619fa7hcddf5d05c676685@mail.gmail.com> <1163677965.3257.16.camel@golgoth01> <2e19719f0611161221x2948d888s5b0a86780b7c05d9@mail.gmail.com> <4561739C.9020903@irisa.fr> Message-ID: <456178FC.3030208@free.fr> aboutet a ?crit : > Gnomemeeting was very useful to test stack IPv6, network or other things > based on IPv6. > Ekiga is its successor but does not support this protocol and gnommeting > is now not available per default in a majority of repositories. > > Is it planned to add IPv6 support ? Please don't post off-thread. Snark on #ekiga From jpuydt at free.fr Mon Nov 20 10:00:53 2006 From: jpuydt at free.fr (Julien Puydt) Date: Mon, 20 Nov 2006 11:00:53 +0100 Subject: [Ekiga-list] Ekiga & IPv6 In-Reply-To: <456178FC.3030208@free.fr> References: <2e19719f0611160027s6d619fa7hcddf5d05c676685@mail.gmail.com> <1163677965.3257.16.camel@golgoth01> <2e19719f0611161221x2948d888s5b0a86780b7c05d9@mail.gmail.com> <4561739C.9020903@irisa.fr> <456178FC.3030208@free.fr> Message-ID: <45617CD5.7040108@free.fr> Julien Puydt a ?crit : > aboutet a ?crit : > >> Gnomemeeting was very useful to test stack IPv6, network or other things >> based on IPv6. >> Ekiga is its successor but does not support this protocol and gnommeting >> is now not available per default in a majority of repositories. >> >> Is it planned to add IPv6 support ? > > Please don't post off-thread. Another netiquette guideline is that such messages should be sent privately... arg! ;-) Snark on #ekiga From dsandras at seconix.com Mon Nov 20 11:37:39 2006 From: dsandras at seconix.com (Damien Sandras) Date: Mon, 20 Nov 2006 12:37:39 +0100 Subject: [Ekiga-list] Ekiga & IPv6 In-Reply-To: <4561739C.9020903@irisa.fr> References: <2e19719f0611160027s6d619fa7hcddf5d05c676685@mail.gmail.com> <1163677965.3257.16.camel@golgoth01> <2e19719f0611161221x2948d888s5b0a86780b7c05d9@mail.gmail.com> <4561739C.9020903@irisa.fr> Message-ID: <1164022659.3736.5.camel@golgoth01> Hi, Le lundi 20 novembre 2006 ? 10:21 +0100, aboutet a ?crit : > Hi all, > > Gnomemeeting was very useful to test stack IPv6, network or other things > based on IPv6. > Ekiga is its successor but does not support this protocol and gnommeting > is now not available per default in a majority of repositories. > > Is it planned to add IPv6 support ? > I don't plan to add IPv6 support, but patches are welcome. -- Damien Sandras Ekiga Softphone : http://www.ekiga.org NOVACOM : http://www.novacom.be FOSDEM : http://www.fosdem.org SIP Phone : sip:dsandras at ekiga.net From dsandras at seconix.com Mon Nov 20 11:39:26 2006 From: dsandras at seconix.com (Damien Sandras) Date: Mon, 20 Nov 2006 12:39:26 +0100 Subject: [Ekiga-list] logitech quickcam messenger: video image not scaled In-Reply-To: <87bqn37810.fsf@falma.de> References: <87k61r7izs.fsf@falma.de> <1163945064.4865.10.camel@golgoth01> <87fycf7ckc.fsf@falma.de> <1163946323.4865.12.camel@golgoth01> <87bqn37810.fsf@falma.de> Message-ID: <1164022766.3736.8.camel@golgoth01> Le dimanche 19 novembre 2006 ? 16:47 +0100, Christoph Groth a ?crit : > Damien Sandras writes: > > >> > > >> > Is it cropped by the driver or by ekiga itself? > >> > >> Other programs (like gqcam) show the image in 320x240, uncropped. > >> > > > > Sure, but what happens if other programs request the same size than > > Ekiga to the driver? (176x144 or 352x288) ? > > I'm new to V4L. If you give me a hint how to try this out, I will do > it. > Xawtv has parameters for that. Actually, if Ekiga asks for 176x144 and the driver doesn't support, the driver should tell it to Ekiga and Ekiga should be able to capture at a higher resolution and resize the image. However, some drivers do things differently and will send back a cropped image instead of telling that the resolution is not supported. So it could be a limitation of the driver, or a bug in Ekiga (that wouldn't support resizing for the given palette). -- Damien Sandras Ekiga Softphone : http://www.ekiga.org NOVACOM : http://www.novacom.be FOSDEM : http://www.fosdem.org SIP Phone : sip:dsandras at ekiga.net From danyroma80 at tiscali.it Tue Nov 21 22:55:24 2006 From: danyroma80 at tiscali.it (Daniele) Date: Tue, 21 Nov 2006 23:55:24 +0100 Subject: [Ekiga-list] A simple question Message-ID: <456383DC.2060009@tiscali.it> I know that Ekiga is compatible with h261 coded in both sip and h323 configurations. When I use Ekiga as SIP client, the h261 codec is named as H261/9000 in SDP body . Which is the equivalent in h323 protocol? I'm making a sip/h323 gateway for videoconferences and I need this information for correct signalling between protocols. thanks! From agustin.treceno at gmail.com Wed Nov 22 19:42:44 2006 From: agustin.treceno at gmail.com (=?ISO-8859-1?Q?Agust=EDn_Trece=F1o?=) Date: Wed, 22 Nov 2006 20:42:44 +0100 Subject: [Ekiga-list] =?iso-8859-1?q?ekiga_answers_with_delay_=BF=2E=2E=2E?= =?iso-8859-1?q?=3F?= Message-ID: Hello everybody! I have a pbx asterisk configured and i want to try ekiga like softphone (until now i use twinkle). Everything is ok, but when i make a call, i receive the ring tone for 2 seconds, therefore i ear the message "you are trying to reach" insted of "enter the extension of the person you are trying to reach". So, ekiga wastes 1 or 2 seconds for establishing the connexion ?...?. With twinkle there isn't this delay. Cheers! Agust?n Trece?o. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpuydt at free.fr Wed Nov 22 20:13:28 2006 From: jpuydt at free.fr (Julien Puydt) Date: Wed, 22 Nov 2006 21:13:28 +0100 Subject: [Ekiga-list] =?iso-8859-1?q?ekiga_answers_with_delay_=BF=2E=2E=2E?= =?iso-8859-1?q?=3F?= In-Reply-To: References: Message-ID: <4564AF68.4080506@free.fr> Agust?n Trece?o a ?crit : > Hello everybody! > > I have a pbx asterisk configured and i want to try ekiga like softphone > (until now i use twinkle). Everything is ok, but when i make a call, i > receive the ring tone for 2 seconds, therefore i ear the message "you are > trying to reach" insted of "enter the extension of the person you are > trying > to reach". So, ekiga wastes 1 or 2 seconds for establishing the connexion > ?...?. With twinkle there isn't this delay. Known bug : asterisk begins to send the voice before it acknowledged which codec it will use for that! Snark on #ekiga From sevmek at free.fr Wed Nov 22 20:18:15 2006 From: sevmek at free.fr (yannick) Date: Wed, 22 Nov 2006 21:18:15 +0100 Subject: [Ekiga-list] =?iso-8859-1?q?ekiga_answers_with_delay_=BF=2E=2E=2E?= =?iso-8859-1?q?=3F?= In-Reply-To: References: Message-ID: <1164226695.25028.39.camel@achille> Le mercredi 22 novembre 2006 ? 20:42 +0100, Agust?n Trece?o a ?crit : > Hello everybody! > > I have a pbx asterisk configured and i want to try ekiga like > softphone (until now i use twinkle). Everything is ok, but when i make > a call, i receive the ring tone for 2 seconds, therefore i ear the > message "you are trying to reach" insted of "enter the extension of > the person you are trying to reach". So, ekiga wastes 1 or 2 seconds > for establishing the connexion ?...?. With twinkle there isn't this > delay. Hi, This a know bug in ekiga. As a workaround, add a delay in asterisk... Regards. > > Cheers! > > Agust?n Trece?o. > _______________________________________________ > ekiga-list mailing list > ekiga-list at gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list -- Me joindre en t?l?phonie IP / vid?oconf?rence ? sip:yannick at ekiga.net From devel at tootai.net Thu Nov 23 11:40:51 2006 From: devel at tootai.net (Daniel Huhardeaux) Date: Thu, 23 Nov 2006 12:40:51 +0100 Subject: [Ekiga-list] =?iso-8859-1?q?ekiga_answers_with_delay_=BF=2E=2E=2E?= =?iso-8859-1?q?=3F?= In-Reply-To: <4564AF68.4080506@free.fr> References: <4564AF68.4080506@free.fr> Message-ID: <456588C3.8040106@tootai.net> Julien Puydt a ?crit : > [...] >> to reach". So, ekiga wastes 1 or 2 seconds for establishing the connexion >> ?...?. With twinkle there isn't this delay. >> > > Known bug : asterisk begins to send the voice before it acknowledged > which codec it will use for that! > Not a bug in Asterisk: Ekiga is not ready but should be. -- Daniel From agustin.treceno at gmail.com Thu Nov 23 12:05:21 2006 From: agustin.treceno at gmail.com (=?ISO-8859-1?Q?Agust=EDn_Trece=F1o?=) Date: Thu, 23 Nov 2006 13:05:21 +0100 Subject: [Ekiga-list] =?iso-8859-1?q?ekiga_answers_with_delay_=BF=2E=2E=2E?= =?iso-8859-1?q?=3F?= In-Reply-To: References: Message-ID: Julien Puydt a ?crit : [...] to reach". So, ekiga wastes 1 or 2 seconds for establishing the connexion ?...?. With twinkle there isn't this delay. Known bug : asterisk begins to send the voice before it acknowledged which codec it will use for that! Not a bug in Asterisk: Ekiga is not ready but should be. -- Daniel ------------------------------ Julien, if it's a bug in asterisk, why twinkle doesn't have this problem? So, anyway, how can we fix this? Putting "exten => 1000, n, Wait(2)" into all extensions in asterisk for waiting 2 seconds doesn't seem a great solution. Cheers, Agust?n T. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsandras at seconix.com Thu Nov 23 12:16:12 2006 From: dsandras at seconix.com (Damien Sandras) Date: Thu, 23 Nov 2006 13:16:12 +0100 Subject: [Ekiga-list] =?iso-8859-1?q?ekiga_answers_with_delay_=BF=2E=2E=2E?= =?iso-8859-1?q?=3F?= In-Reply-To: References: Message-ID: <1164284172.4546.25.camel@golgoth01> Le jeudi 23 novembre 2006 ? 13:05 +0100, Agust?n Trece?o a ?crit : ________________________________________________________________________ > Julien, if it's a bug in asterisk, why twinkle doesn't have this > problem? So, anyway, how can we fix this? > Putting "exten => 1000, n, Wait(2)" into all extensions in asterisk > for waiting 2 seconds doesn't seem a great solution. > The easiest solution is to provide a patch for OPAL to fix the problem... -- _ Damien Sandras (o- //\ Ekiga Softphone : http://www.ekiga.org/ v_/_ NOVACOM : http://www.novacom.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsandras at ekiga.net From agustin.treceno at gmail.com Thu Nov 23 13:16:00 2006 From: agustin.treceno at gmail.com (=?ISO-8859-1?Q?Agust=EDn_Trece=F1o?=) Date: Thu, 23 Nov 2006 14:16:00 +0100 Subject: [Ekiga-list] =?iso-8859-1?q?ekiga_answers_with_delay_=BF=2E=2E=2E?= =?iso-8859-1?q?=3F?= In-Reply-To: References: Message-ID: > Julien, if it's a bug in asterisk, why twinkle doesn't have this > problem? So, anyway, how can we fix this? > Putting "exten => 1000, n, Wait(2)" into all extensions in asterisk > for waiting 2 seconds doesn't seem a great solution. > The easiest solution is to provide a patch for OPAL to fix the problem... -- _ Damien Sandras (o- //\ Ekiga Softphone : http://www.ekiga.org/ v_/_ NOVACOM : http://www.novacom.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsandras ekiga net Hi Damien, sorry about my rought knowledge but how can i get this patch for opal? i've taken the last souces from here: http://www.voxgratia.org/releases/opal-v2_2_3-src-tar.gz What should i do now? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsandras at seconix.com Thu Nov 23 19:00:57 2006 From: dsandras at seconix.com (Damien Sandras) Date: Thu, 23 Nov 2006 20:00:57 +0100 Subject: [Ekiga-list] =?iso-8859-1?q?ekiga_answers_with_delay_=BF=2E=2E=2E?= =?iso-8859-1?q?=3F?= In-Reply-To: References: Message-ID: <1164308457.3487.5.camel@golgoth01> Le jeudi 23 novembre 2006 ? 14:16 +0100, Agust?n Trece?o a ?crit : > The easiest solution is to provide a patch for OPAL to fix the > problem... [...] > Hi Damien, sorry about my rought knowledge but how can i get this > patch for opal? i've taken the last souces from here: > http://www.voxgratia.org/releases/opal-v2_2_3-src-tar.gz > What should i do now? I meant that the easiest to have the problem fixed is to fix it, and thus modify the code so that the problem disappears, then send the modifications back to the mailing list. -- _ Damien Sandras (o- //\ Ekiga Softphone : http://www.ekiga.org/ v_/_ NOVACOM : http://www.novacom.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsandras at ekiga.net From craigs at postincrement.com Fri Nov 24 02:26:29 2006 From: craigs at postincrement.com (Craig Southeren) Date: Fri, 24 Nov 2006 13:26:29 +1100 Subject: [Ekiga-list] =?iso-8859-1?q?ekiga_answers_with_delay_=BF=2E=2E=2E?= =?iso-8859-1?q?=3F?= In-Reply-To: <456588C3.8040106@tootai.net> References: <4564AF68.4080506@free.fr> <456588C3.8040106@tootai.net> Message-ID: <20061124131952.5F7C.CRAIGS@postincrement.com> On Thu, 23 Nov 2006 12:40:51 +0100 Daniel Huhardeaux wrote: > Julien Puydt a ?crit : > > [...] > >> to reach". So, ekiga wastes 1 or 2 seconds for establishing the connexion > >> ?...?. With twinkle there isn't this delay. > >> > > > > Known bug : asterisk begins to send the voice before it acknowledged > > which codec it will use for that! > > > Not a bug in Asterisk: Ekiga is not ready but should be. I've only just noticed this thread, so please accept my apologies for the late reply. It's not unusual for a calling endpoint to receive media before it receive acknwledgement that the call has been answered. With some protocols (like H.323) this can be due to the timing of the signalling (which is carried via TCP) and the RTP (which is carried on UDP). For SIP, it can be due to the media and signalling taking different paths. Or it can just be due to delays in the receiving endpoint. Regardless, the calling endpoint should be ready to receive RTP at any time after it sends to call offer and OPAL should do this already. However, if the receiving endpoint uses a different payload type than the one offered, then the receiving endpoint won't be able to accept the incoming RTP data until the signalling reply is received. I know that Asterisk has a nasty habit of changing the payload type - perhaps this is what is happening? Can anyone confirm? Craig ----------------------------------------------------------------------- Craig Southeren Post Increment ? VoIP Consulting and Software craigs at postincrement.com.au www.postincrement.com.au Phone: +61 243654666 ICQ: #86852844 Fax: +61 243656905 MSN: craig_southeren at hotmail.com Mobile: +61 417231046 Jabber: craigs at jabber.org "It takes a man to suffer ignorance and smile. Be yourself, no matter what they say." Sting From bbagger at gmail.com Fri Nov 24 09:46:28 2006 From: bbagger at gmail.com (Bent Bagger) Date: Fri, 24 Nov 2006 10:46:28 +0100 Subject: [Ekiga-list] =?iso-8859-1?q?ekiga_answers_with_delay_=BF=2E=2E=2E?= =?iso-8859-1?q?=3F?= In-Reply-To: <20061124131952.5F7C.CRAIGS@postincrement.com> References: <4564AF68.4080506@free.fr> <456588C3.8040106@tootai.net> <20061124131952.5F7C.CRAIGS@postincrement.com> Message-ID: <2e19719f0611240146r57490e82sc6693a4580da3a99@mail.gmail.com> On 24/11/06, Craig Southeren wrote: > > I know that Asterisk has a nasty habit of changing the payload type - > perhaps this is what is happening? Can anyone confirm? > I do not know how nasty Asterisk is with regards to changing payload type. I believe that after having finished the negotiation, Asterisk sticks to the selected codec. In any case, the order of codec preference is totally under the control of the Asterisk sysadm (order of 'allow's in the SIP channel configuration - sip.conf) I have just run an experiment on my asterisk where I forced both Ekiga and Asterisk to use one and the same codec - ulaw (PCMU) in this case. The problem still persists: I did not hear the first part of the echo test greeting. Best regards, Bent From devel at tootai.net Sat Nov 25 01:45:17 2006 From: devel at tootai.net (Daniel Huhardeaux) Date: Sat, 25 Nov 2006 02:45:17 +0100 Subject: [Ekiga-list] =?iso-8859-1?q?ekiga_answers_with_delay_=BF=2E=2E=2E?= =?iso-8859-1?q?=3F?= In-Reply-To: <20061124131952.5F7C.CRAIGS@postincrement.com> References: <4564AF68.4080506@free.fr> <456588C3.8040106@tootai.net> <20061124131952.5F7C.CRAIGS@postincrement.com> Message-ID: <4567A02D.7020500@tootai.net> Craig Southeren a ?crit : > On Thu, 23 Nov 2006 12:40:51 +0100 > Daniel Huhardeaux wrote: > > >> Julien Puydt a ?crit : >> >>> [...] >>> >>>> to reach". So, ekiga wastes 1 or 2 seconds for establishing the connexion >>>> ?...?. With twinkle there isn't this delay. >>>> >>>> >>> Known bug : asterisk begins to send the voice before it acknowledged >>> which codec it will use for that! >>> >>> >> Not a bug in Asterisk: Ekiga is not ready but should be. >> > > I've only just noticed this thread, so please accept my apologies for > the late reply. > > It's not unusual for a calling endpoint to receive media before it > receive acknwledgement that the call has been answered. With some > protocols (like H.323) this can be due to the timing of the signalling > (which is carried via TCP) and the RTP (which is carried on UDP). For > SIP, it can be due to the media and signalling taking different paths. > Or it can just be due to delays in the receiving endpoint. > > Regardless, the calling endpoint should be ready to receive RTP at any > time after it sends to call offer and OPAL should do this already. > > However, if the receiving endpoint uses a different payload type than > the one offered, then the receiving endpoint won't be able to accept the > incoming RTP data until the signalling reply is received. > > I know that Asterisk has a nasty habit of changing the payload type - > perhaps this is what is happening? Can anyone confirm? > Hi Craig, hereunder an exchange we had end of october about this behaviour -final answer from Damien-, after having open a bug on asterisk mantis. Le dimanche 29 octobre 2006 ? 17:52 +0100, Daniel Huhardeaux a ?crit : > > Damien Sandras a ?crit : > > > >>>>> > >>>> >>>>> >>>> > >>> [...] >>>> > >>> >>>> > >>> >>>> > >>> I have done a debug log using ethereal, and I notice the following >>>> > >>> behavior : >>>> > >>> >>>> > >>> 1) Ekiga sends the INVITE >>>> > >>> 2) Ekiga receives the 200 OK >>>> > >>> 3) Immediately after, Asterisk starts sending the media streams >>>> > >>> 4) Ekiga opens the audio channels and sends the ACK >>>> > >>> >>>> > >>> The RFC tells that the media streams should not be sent before the ACK >>>> > >>> is received. Asterisk doesn't follow this. So I conclude the bug is in >>>> > >>> Asterisk not in Ekiga... >>>> > >>> >>>> > >>> I'll see if I can find an easy to implement workaround. >>>> > >>> >>>> > >>> >>>> >>> > >> Would it not be better to open a bug on mantis (bugs.digium.com)? >>> > >> >>> >> > > >> > > Somebody can do it, yes. >> > > >> > > #8244 > > > > Damien, hereunder the response from Ole ;-) > > > Ah well yes, he is right, I was sure I had read something else elsewhere. I will see if it is easy to change OPAL for that (I have doubts). > > ---------------------------------------------------------------------- > > oej - 10-29-06 10:35 > > ---------------------------------------------------------------------- > > Well, you should be ready to receive media as soon as you send the INVITE. > > Let's try to find the various RFCs and throw them at each other... I am > > sure > > > > In reality, as soon as you make an offer, you need to be able to receive > > audio on the ports you specify. > > > > I don't see this as a bug. Check the implementations in various other > > phones. > > --------------- > > So here's my throw of RFC 3264, Section 5.1: > > > > "Once the offerer has sent the offer, it MUST be prepared to receive media > > for any recvonly streams described > > by that offer. It MUST be prepared to send and receive media for any > > sendrecv streams in the offer, and send > > media for any sendonly streams in the offer (of course, it cannot actually > > send until the peer provides an > > answer with the needed address and port information). In the case of RTP, > > even though it may receive media > > before the answer arrives, it will not be able to send RTCP receiver > > reports until the answer arrives." > > -------------------- > > Say hello to Damien from me, I hope that he can join us at AstriVideoCon > > in Paris! > > > > Good luck fixing this bug in Ekiga :-) > > > > ---------------------------------------------------------------------- > > oej - 10-29-06 10:37 > > ---------------------------------------------------------------------- > > Not a bug in Asterisk, bug in Ekiga until proven otherwise :-) > > > > > -- Daniel From geboyd53 at comcast.net Sat Nov 25 10:56:36 2006 From: geboyd53 at comcast.net (George Boyd) Date: Sat, 25 Nov 2006 02:56:36 -0800 Subject: [Ekiga-list] ATA or Hardware SIP Phones to use with EKIGA/VoIPBuster Message-ID: <1164452196.8826.8.camel@george> Trying to find an ATA or SIP hardware phones seems to be a daunting task. I love Ekiga for SIP communications and I like VOIPBUSTER for the price. I would like to find an ATA adapter or a SIP hardware phone that will work with Ekiga and/or VOIPBUSTER. I'm running Ekiga on Fedora Core 6 and connected to the internet via cable. Does such a device work with my setup? If so any help would be greatly appreciated. Of course the least cost solution would be best. Thanks, George From salvatore at iovene.com Sat Nov 25 13:06:01 2006 From: salvatore at iovene.com (Salvatore Iovene) Date: Sat, 25 Nov 2006 15:06:01 +0200 Subject: [Ekiga-list] Ekiga and AIGLX: webcam? Message-ID: <20061125150601.206b6a89@home> Hello, I run the AIGLX Xorg extension with the Beryl window manager and the XFCE4 Desktop Environment. Is Ekiga's support for webcam known to work with this setup (I think the most relevant keyword is AIGLX). All I can see, is a grey square. For the matter: same with camorama. Thanks, and keep up the great work.. -- Salvatore Iovene http://www.iovene.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sevmek at free.fr Sat Nov 25 15:20:53 2006 From: sevmek at free.fr (yannick) Date: Sat, 25 Nov 2006 16:20:53 +0100 Subject: [Ekiga-list] Ekiga and AIGLX: webcam? In-Reply-To: <20061125150601.206b6a89@home> References: <20061125150601.206b6a89@home> Message-ID: <1164468053.6317.4.camel@achille> Le samedi 25 novembre 2006 ? 15:06 +0200, Salvatore Iovene a ?crit : > Hello, > I run the AIGLX Xorg extension with the Beryl window manager and the > XFCE4 Desktop Environment. > Is Ekiga's support for webcam known to work with this setup (I think the > most relevant keyword is AIGLX). > All I can see, is a grey square. For the matter: same with camorama. I assume you are using Ubtuntu Edgy (6.10) and you webcam uses the pwc driver provided by ubuntu kernel. In this case, just fellow instructions here: https://help.ubuntu.com/community/Webcam?#head-836881f8aaa64508507ce1f2091b24b8aead02cb Regards. Yannick > > Thanks, and keep up the great work.. > > _______________________________________________ > ekiga-list mailing list > ekiga-list at gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list -- Me joindre en t?l?phonie IP / vid?oconf?rence ? sip:yannick at ekiga.net From salvatore at iovene.com Sat Nov 25 16:34:25 2006 From: salvatore at iovene.com (Salvatore Iovene) Date: Sat, 25 Nov 2006 18:34:25 +0200 Subject: [Ekiga-list] Ekiga and AIGLX: webcam? In-Reply-To: <1164468053.6317.4.camel@achille> References: <20061125150601.206b6a89@home> <1164468053.6317.4.camel@achille> Message-ID: <20061125183425.5721e20e@home> On Sat, 25 Nov 2006 16:20:53 +0100 yannick wrote: > Le samedi 25 novembre 2006 ? 15:06 +0200, Salvatore Iovene a ?crit : > > Hello, > > I run the AIGLX Xorg extension with the Beryl window manager and the > > XFCE4 Desktop Environment. > > Is Ekiga's support for webcam known to work with this setup (I > > think the most relevant keyword is AIGLX). > > All I can see, is a grey square. For the matter: same with camorama. > > I assume you are using Ubtuntu Edgy (6.10) and you webcam uses the pwc > driver provided by ubuntu kernel. Hi. Thanks for the reply. I use debian testing, and the pwc driver. > > In this case, just fellow instructions here: > https://help.ubuntu.com/community/Webcam?#head-836881f8aaa64508507ce1f2091b24b8aead02cb Thanks for the link, I'll do it and let you know. -- Salvatore Iovene http://www.iovene.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dsandras at seconix.com Sat Nov 25 16:56:31 2006 From: dsandras at seconix.com (Damien Sandras) Date: Sat, 25 Nov 2006 17:56:31 +0100 Subject: [Ekiga-list] ATA or Hardware SIP Phones to use with EKIGA/VoIPBuster In-Reply-To: <1164452196.8826.8.camel@george> References: <1164452196.8826.8.camel@george> Message-ID: <1164473791.3589.2.camel@golgoth01> Le samedi 25 novembre 2006 ? 02:56 -0800, George Boyd a ?crit : > Trying to find an ATA or SIP hardware phones seems to be a daunting > task. I love Ekiga for SIP communications and I like VOIPBUSTER for the > price. I would like to find an ATA adapter or a SIP hardware phone that > will work with Ekiga and/or VOIPBUSTER. > > I'm running Ekiga on Fedora Core 6 and connected to the internet via > cable. Does such a device work with my setup? If so any help would be > greatly appreciated. Of course the least cost solution would be best. > I do not have any recommendation, but this page should help: http://www.voip-info.org/wiki/view/Analog+Telephone+Adapters -- _ Damien Sandras (o- //\ Ekiga Softphone : http://www.ekiga.org/ v_/_ NOVACOM : http://www.novacom.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsandras at ekiga.net From salvatore at iovene.com Sat Nov 25 17:29:38 2006 From: salvatore at iovene.com (Salvatore Iovene) Date: Sat, 25 Nov 2006 19:29:38 +0200 Subject: [Ekiga-list] Ekiga and AIGLX: webcam? In-Reply-To: <1164468053.6317.4.camel@achille> References: <20061125150601.206b6a89@home> <1164468053.6317.4.camel@achille> Message-ID: <20061125192938.12176c7e@home> On Sat, 25 Nov 2006 16:20:53 +0100 yannick wrote: > Le samedi 25 novembre 2006 ? 15:06 +0200, Salvatore Iovene a ?crit : > > Hello, > > I run the AIGLX Xorg extension with the Beryl window manager and the > > XFCE4 Desktop Environment. > > Is Ekiga's support for webcam known to work with this setup (I > > think the most relevant keyword is AIGLX). > > All I can see, is a grey square. For the matter: same with camorama. > > I assume you are using Ubtuntu Edgy (6.10) and you webcam uses the pwc > driver provided by ubuntu kernel. > > In this case, just fellow instructions here: > https://help.ubuntu.com/community/Webcam?#head-836881f8aaa64508507ce1f2091b24b8aead02cb It worked. Thank you very much. -- Salvatore Iovene http://www.iovene.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From juha.leino at kapsi.fi Sat Nov 25 19:54:09 2006 From: juha.leino at kapsi.fi (Juha Leino) Date: Sat, 25 Nov 2006 21:54:09 +0200 (EET) Subject: [Ekiga-list] 500@ekiga.net, no video Message-ID: <10648.84.231.21.101.1164484449.squirrel@mail.kapsi.fi> Hello. I'm having a problem with video in 500 at ekiga.net. It used to work like a charm long time, but now it suddenly stopped working. The preview is ok before the call but as soon as call is started the video freezes. I have a Logitech UVC camera. I had problems with the driver but after I compiled the most recent version (split branch) it seems to be ok. My os is Ubuntu Edgy with a stock kernel. One thing that came into my mind is my ADSL router (Zyxel 660HW). It has NAT configured in it, and stun is used to bypass it. It also has a SIP ALG functionality that has been enabled (do you need stun still, or is my ALG dead somehow btw?). Do I perhaps need to open some ports (range of ports) for video perhaps? Is there any way of debugging the problem? With best regards, Juha Leino From juha.leino at kapsi.fi Sat Nov 25 19:56:32 2006 From: juha.leino at kapsi.fi (Juha Leino) Date: Sat, 25 Nov 2006 21:56:32 +0200 (EET) Subject: [Ekiga-list] Ekiga video problem Message-ID: <10650.84.231.21.101.1164484592.squirrel@mail.kapsi.fi> Hello. I'm having a problem with video in 500 at ekiga.net. It used to work like a charm, but now it suddenly stopped working. The preview is ok before the call but as soon as call is started the video freezes. I have a Logitech UVC camera. I had problems with the driver but after I compiled the most recent version (split branch) it seems to be ok. My OS is Ubuntu Edgy with a stock kernel. One thing that came into my mind is my ADSL router (Zyxel 660HW) and its setup. It has NAT configured in it, and stun is in use. Zyxel also has a SIP ALG functionality that has been enabled (do you need stun still, or is my ALG dead somehow btw?). Do I perhaps need to open some ports (range of ports) for video perhaps? Is there any way of debugging the problem? With best regards, Juha Leino From juha.leino at kapsi.fi Sat Nov 25 19:58:06 2006 From: juha.leino at kapsi.fi (Juha Leino) Date: Sat, 25 Nov 2006 21:58:06 +0200 (EET) Subject: [Ekiga-list] Ekiga video problem In-Reply-To: <10650.84.231.21.101.1164484592.squirrel@mail.kapsi.fi> References: <10650.84.231.21.101.1164484592.squirrel@mail.kapsi.fi> Message-ID: <10652.84.231.21.101.1164484686.squirrel@mail.kapsi.fi> Sorry about spamming duplicates :-( I apparently have problems with my e-mail client also. -- Juha From sevmek at free.fr Sat Nov 25 23:38:16 2006 From: sevmek at free.fr (yannick) Date: Sun, 26 Nov 2006 00:38:16 +0100 Subject: [Ekiga-list] Ekiga and AIGLX: webcam? In-Reply-To: <20061125192938.12176c7e@home> References: <20061125150601.206b6a89@home> <1164468053.6317.4.camel@achille> <20061125192938.12176c7e@home> Message-ID: <1164497896.6317.7.camel@achille> Le samedi 25 novembre 2006 ? 19:29 +0200, Salvatore Iovene a ?crit : > On Sat, 25 Nov 2006 16:20:53 +0100 yannick wrote: > > > Le samedi 25 novembre 2006 ? 15:06 +0200, Salvatore Iovene a ?crit : > > > Hello, > > > I run the AIGLX Xorg extension with the Beryl window manager and the > > > XFCE4 Desktop Environment. > > > Is Ekiga's support for webcam known to work with this setup (I > > > think the most relevant keyword is AIGLX). > > > All I can see, is a grey square. For the matter: same with camorama. > > > > I assume you are using Ubtuntu Edgy (6.10) and you webcam uses the pwc > > driver provided by ubuntu kernel. > > > > In this case, just fellow instructions here: > > https://help.ubuntu.com/community/Webcam?#head-836881f8aaa64508507ce1f2091b24b8aead02cb > > It worked. Thank you very much. Hum... Until now i think the problem was in Ubuntu, it seems in debian... IMHO this is worst... Thanks you for the report :) Regards, Yannick > > _______________________________________________ > ekiga-list mailing list > ekiga-list at gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list -- Me joindre en t?l?phonie IP / vid?oconf?rence ? sip:yannick at ekiga.net From ian_940 at yahoo.com.au Sun Nov 26 01:00:54 2006 From: ian_940 at yahoo.com.au (Ian House) Date: Sun, 26 Nov 2006 12:00:54 +1100 Subject: [Ekiga-list] Gconf key error Message-ID: <200611261200.54855.ian_940@yahoo.com.au> I have been using Ekiga without problem until a recent update. Now when I try to start the program I get: Gconf key error Ekiga got an invalid value for the Gconf key "/apps/ekiga/general/gconf_test_age" It probably means that your Gconf schemas have not been correctly installed or that the file permissions are not correct. It then directs me to check the FAQ and mailing lists. What I was able to find is; /etc/gconf/, contains only /schemas/ekiga.schemas. Ekiga config is in /etc/opt/gnome/gconf but when starting, Ekiga looks for it in /etc/gconf. I tried creating a symlink between /etc/opt/gnome/gconf and /etc/gconf; but still get the same error. Running Suse10.0 with KDE. Any help with fixing this please... -- Cheers, Ian... http://www.ians-tux-web.com.au.tt registered linux user; 423784 http://counter.li.org/ From craigs at postincrement.com Sun Nov 26 01:33:02 2006 From: craigs at postincrement.com (Craig Southeren) Date: Sun, 26 Nov 2006 12:33:02 +1100 Subject: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?] In-Reply-To: <4567A02D.7020500@tootai.net> References: <20061124131952.5F7C.CRAIGS@postincrement.com> <4567A02D.7020500@tootai.net> Message-ID: <20061126120055.2AED.CRAIGS@postincrement.com> On Sat, 25 Nov 2006 02:45:17 +0100 Daniel Huhardeaux wrote: ..deleted > > > I don't see this as a bug. Check the implementations in various other > > > phones. > > > --------------- > > > So here's my throw of RFC 3264, Section 5.1: > > > > > > "Once the offerer has sent the offer, it MUST be prepared to receive media > > > for any recvonly streams described > > > by that offer. It MUST be prepared to send and receive media for any > > > sendrecv streams in the offer, and send > > > media for any sendonly streams in the offer (of course, it cannot actually > > > send until the peer provides an > > > answer with the needed address and port information). In the case of RTP, > > > even though it may receive media > > > before the answer arrives, it will not be able to send RTCP receiver > > > reports until the answer arrives." > > > -------------------- > > > Say hello to Damien from me, I hope that he can join us at AstriVideoCon > > > in Paris! > > > > > > Good luck fixing this bug in Ekiga :-) > > > > > > ---------------------------------------------------------------------- > > > oej - 10-29-06 10:37 > > > ---------------------------------------------------------------------- > > > Not a bug in Asterisk, bug in Ekiga until proven otherwise :-) I think we differ in the interpretation of this paragraph, and I don't think this behaviour is a bug in Ekiga. If anything, it would be a bug in OPAL, and so I have copied this email to the correct OPAL mailing list so that other people who are knowledgeable in SIP may see it. My reading of this paragraph is that the offerer must have the UDP sockets ready to receive data before it sends the offer, so that the sender does not get ICMP "destination not ready" errors. This same requirement exists in other VoIP protocols such as H.323, because the media may arrive before the acknowledge (but this difference should be measured in milliseconds, not seconds). There are many reasons why it is not feasible to treat the arrival of an RTP packet as the de-facto start of the media session: 1) The receiving endpoint can use completely different payload types than the offering endpoint. As an example, an offering endpoint cannot assume that simply because it offered to send Speex using dynamic payload type 108 that any RTP data it receives with payload type 108 is Speex. If it does, it could end up trying to push H.263 video data or iLBC audio through a Speex codec. There is no way to avoid this unless the offerer waits for the session information. 2) In certain SIP scenarios, it is impossible to process received media until the SDP session information is received. Some video codecs (such as H.263 and H.264) transmit information in the SDP parameters that is required to decode the media. Media encryption also requires that the offerer have the encryption key (which is in the SDP session information) before the media can be decrypted. 3) It is a gaping security hole. It means that a black hat has simply to send an RTP packet to an endpoint that has sent a session offer, and the offering endpoint will then start allocating resources and presenting whatever media it receives to the user. When the real media starts arriving from the reaal endpoint, it could be lost or ignored. 4) For endpoints that offer a wide variety of codecs, being prepared to receive any offered media type at any time prior to receiving the session description would require the allocation of any infeasibly large amount of resources. For example, this would require Ekiga to allocate an instance of every audio and video codec and have them ready and prepared to receive media. When there are 10 different audio codecs, and two video codecs, this is not an option. 5) The correct way to start media before answer supervision starts (i.e. before sending the 200 OK) is to send a session description in an intermediate response, such as a 183. This will allow the offered to start the media session and receive any inband tones or early media prior to the start of answer supervision signalling. Craig ----------------------------------------------------------------------- Craig Southeren Post Increment ? VoIP Consulting and Software craigs at postincrement.com.au www.postincrement.com.au Phone: +61 243654666 ICQ: #86852844 Fax: +61 243656905 MSN: craig_southeren at hotmail.com Mobile: +61 417231046 Jabber: craigs at jabber.org "It takes a man to suffer ignorance and smile. Be yourself, no matter what they say." Sting From sevmek at free.fr Sun Nov 26 06:59:03 2006 From: sevmek at free.fr (yannick) Date: Sun, 26 Nov 2006 07:59:03 +0100 Subject: [Ekiga-list] Gconf key error In-Reply-To: <200611261200.54855.ian_940@yahoo.com.au> References: <200611261200.54855.ian_940@yahoo.com.au> Message-ID: <1164524343.6317.11.camel@achille> Le dimanche 26 novembre 2006 ? 12:00 +1100, Ian House a ?crit : > I have been using Ekiga without problem until a recent update. Now when I try > to start the program I get: > Gconf key error > Ekiga got an invalid value for the Gconf > key "/apps/ekiga/general/gconf_test_age" > It probably means that your Gconf schemas have not been correctly installed or > that the file permissions are not correct. Try: - exit ekiga - $ killall -9 gconfd-2 - restart ekiga Regards, Yannick > It then directs me to check the FAQ and mailing lists. > > What I was able to find is; /etc/gconf/, contains only /schemas/ekiga.schemas. > Ekiga config is in /etc/opt/gnome/gconf but when starting, Ekiga looks for it > in /etc/gconf. I tried creating a symlink between /etc/opt/gnome/gconf > and /etc/gconf; but still get the same error. > > Running Suse10.0 with KDE. Any help with fixing this please... > -- Me joindre en t?l?phonie IP / vid?oconf?rence ? sip:yannick at ekiga.net From ian_940 at yahoo.com.au Sun Nov 26 08:04:19 2006 From: ian_940 at yahoo.com.au (Ian House) Date: Sun, 26 Nov 2006 19:04:19 +1100 Subject: [Ekiga-list] Gconf key error In-Reply-To: <1164524343.6317.11.camel@achille> References: <200611261200.54855.ian_940@yahoo.com.au> <1164524343.6317.11.camel@achille> Message-ID: <200611261904.19821.ian_940@yahoo.com.au> On Sunday 26 November 2006 17:59, yannick wrote: > killall -9 gconfd-2 Got there thanks. Had to change permissions: linux:~> gconftool-2 --get-default-source xml::/etc/opt/gnome/gconf/gconf.xml.defaults linux:/ # chmod -R 4755 /etc/opt/gnome/gconf/gconf.xml.defaults linux: # killall -9 gconfd-2 Once I did that all is now OK. It didn't work the first time because I forgot to change the path...(/etc/gconf to /etc/opt/gnome/gconf) -- Cheers, Ian... http://www.ians-tux-web.com.au.tt registered linux user; 423784 http://counter.li.org/ From dsandras at seconix.com Sun Nov 26 11:05:21 2006 From: dsandras at seconix.com (Damien Sandras) Date: Sun, 26 Nov 2006 12:05:21 +0100 Subject: [Ekiga-list] Ekiga video problem In-Reply-To: <10650.84.231.21.101.1164484592.squirrel@mail.kapsi.fi> References: <10650.84.231.21.101.1164484592.squirrel@mail.kapsi.fi> Message-ID: <1164539121.3501.3.camel@golgoth01> Hi, Is video transmission enabled in the video codecs settings? Le samedi 25 novembre 2006 ? 21:56 +0200, Juha Leino a ?crit : > Hello. > > I'm having a problem with video in 500 at ekiga.net. It used to work like a > charm, but now it suddenly stopped working. The preview is ok before the > call but as soon as call is started the video freezes. > > I have a Logitech UVC camera. I had problems with the driver but after I > compiled the most recent version (split branch) it seems to be ok. My OS > is Ubuntu Edgy with a stock kernel. > > One thing that came into my mind is my ADSL router (Zyxel 660HW) and its > setup. It has NAT configured in it, and stun is in use. Zyxel also has a > SIP ALG functionality that has been enabled (do you need stun still, or is > my > ALG dead somehow btw?). > > Do I perhaps need to open some ports (range of ports) for video perhaps? > Is there any way of debugging the problem? > > With best regards, Juha Leino > > > _______________________________________________ > ekiga-list mailing list > ekiga-list at gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list -- _ Damien Sandras (o- //\ Ekiga Softphone : http://www.ekiga.org/ v_/_ NOVACOM : http://www.novacom.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsandras at ekiga.net From dsandras at seconix.com Sun Nov 26 11:12:02 2006 From: dsandras at seconix.com (Damien Sandras) Date: Sun, 26 Nov 2006 12:12:02 +0100 Subject: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?] In-Reply-To: <20061126120055.2AED.CRAIGS@postincrement.com> References: <20061124131952.5F7C.CRAIGS@postincrement.com> <4567A02D.7020500@tootai.net> <20061126120055.2AED.CRAIGS@postincrement.com> Message-ID: <1164539522.3501.11.camel@golgoth01> Le dimanche 26 novembre 2006 ? 12:33 +1100, Craig Southeren a ?crit : [...] > If anything, it would be a bug in OPAL, and so I have copied this email > to the correct OPAL mailing list so that other people who are > knowledgeable in SIP may see it. > Most of the OPAL bugs are inside the Ekiga bug tracker. I have moved those I don't plan to fix to the openh323 bug tracker. However, I think the paragraph in the SIP RFC is clear, when you send an offer, you must be ready to receive media for all codecs in that offer before the offer has been acknowledged. I understand it sounds weird, but that is one of the limitations of OPAL. Another limitation is that the codec to use is determined from the 200 OK answer in a way that is not necessarily correct. For example, if you send an INVITE with iLBC, PCMU and PCMA as available codecs, and the answer comes with PCMU, PCMA and iLBC (in that order) back, how do you determine if you have to send iLBC or PCMU? OPAL will send PCMU because it is the preferred codec in the answer. However, the codec to use should be determined by the RTP payload. So OPAL should be able to send and receive PCMU/PCMA/iLBC, and choose the correct one as soon as it receives RTP from the remote peer. However, that is a non trivial change to OPAL. What do you think? -- _ Damien Sandras (o- //\ Ekiga Softphone : http://www.ekiga.org/ v_/_ NOVACOM : http://www.novacom.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsandras at ekiga.net From jpuydt at free.fr Sun Nov 26 11:14:29 2006 From: jpuydt at free.fr (Julien Puydt) Date: Sun, 26 Nov 2006 12:14:29 +0100 Subject: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?] In-Reply-To: <1164539522.3501.11.camel@golgoth01> References: <20061124131952.5F7C.CRAIGS@postincrement.com> <4567A02D.7020500@tootai.net> <20061126120055.2AED.CRAIGS@postincrement.com> <1164539522.3501.11.camel@golgoth01> Message-ID: <45697715.8070009@free.fr> Damien Sandras a ?crit : > Le dimanche 26 novembre 2006 ? 12:33 +1100, Craig Southeren a ?crit : > > [...] > >> If anything, it would be a bug in OPAL, and so I have copied this email >> to the correct OPAL mailing list so that other people who are >> knowledgeable in SIP may see it. >> > > Most of the OPAL bugs are inside the Ekiga bug tracker. I have moved > those I don't plan to fix to the openh323 bug tracker. > > However, I think the paragraph in the SIP RFC is clear, when you send an > offer, you must be ready to receive media for all codecs in that offer > before the offer has been acknowledged. I understand it sounds weird, > but that is one of the limitations of OPAL. > > Another limitation is that the codec to use is determined from the 200 > OK answer in a way that is not necessarily correct. > > For example, if you send an INVITE with iLBC, PCMU and PCMA as available > codecs, and the answer comes with PCMU, PCMA and iLBC (in that order) > back, how do you determine if you have to send iLBC or PCMU? OPAL will > send PCMU because it is the preferred codec in the answer. > > However, the codec to use should be determined by the RTP payload. So > OPAL should be able to send and receive PCMU/PCMA/iLBC, and choose the > correct one as soon as it receives RTP from the remote peer. > > However, that is a non trivial change to OPAL. > > What do you think? Here is how gstreamer does, as far as I know : they get the data and feed it to their codecs, which return something which measures their confidente it is "correct data" for them. So by elimination, they get the right codec, which can then be confirmed and better tuned afterwards. Snark From craigs at postincrement.com Sun Nov 26 12:07:22 2006 From: craigs at postincrement.com (Craig Southeren) Date: Sun, 26 Nov 2006 23:07:22 +1100 Subject: [Ekiga-list] [OpenH323]Re: Receiving SIP RTP before media description [was ekiga answers with delay ...?] In-Reply-To: <1164539522.3501.11.camel@golgoth01> References: <20061126120055.2AED.CRAIGS@postincrement.com> <1164539522.3501.11.camel@golgoth01> Message-ID: <20061126225804.02B8.CRAIGS@postincrement.com> On Sun, 26 Nov 2006 12:12:02 +0100 Damien Sandras wrote: > Le dimanche 26 novembre 2006 ? 12:33 +1100, Craig Southeren a ?crit : > > [...] > > > If anything, it would be a bug in OPAL, and so I have copied this email > > to the correct OPAL mailing list so that other people who are > > knowledgeable in SIP may see it. > > > > Most of the OPAL bugs are inside the Ekiga bug tracker. I have moved > those I don't plan to fix to the openh323 bug tracker. Understood, and thanks. > However, I think the paragraph in the SIP RFC is clear, when you send an > offer, you must be ready to receive media for all codecs in that offer > before the offer has been acknowledged. I understand it sounds weird, > but that is one of the limitations of OPAL. I disagree. I think that this interpretation is wrong (see my previous email for why). > Another limitation is that the codec to use is determined from the 200 > OK answer in a way that is not necessarily correct. > > For example, if you send an INVITE with iLBC, PCMU and PCMA as available > codecs, and the answer comes with PCMU, PCMA and iLBC (in that order) > back, how do you determine if you have to send iLBC or PCMU? OPAL will > send PCMU because it is the preferred codec in the answer. The endpoint is free to chose any offered codec it wants. This may result in different codecs in each direction - this is OK and may be desirable in some cases. > However, the codec to use should be determined by the RTP payload. So > OPAL should be able to send and receive PCMU/PCMA/iLBC, and choose the > correct one as soon as it receives RTP from the remote peer. No, this is not correct because the receiving endpoint can chose a differend payload type. For example, you can offer to do iLBC with payload type 108, and Speex with payload type 109. The receiver then decides do Speex with payload type 108 and starts sending RTP with payload code 108. If the offerer starts processing media when it receives the first RTP packet, it will assume it is iLBC, which is wrong. There is no way to avoid this problem other than to wait for the session parameters. See my previous email for other reasons. > However, that is a non trivial change to OPAL. It is extremely non-trivial. Robert and I cannot even see a way to do it that would not require major surgery to OPAL. > What do you think? Robert and myself discussed this this topic yesterday. Our opinion is in my previous email Craig ----------------------------------------------------------------------- Craig Southeren Post Increment ? VoIP Consulting and Software craigs at postincrement.com.au www.postincrement.com.au Phone: +61 243654666 ICQ: #86852844 Fax: +61 243656905 MSN: craig_southeren at hotmail.com Mobile: +61 417231046 Jabber: craigs at jabber.org "It takes a man to suffer ignorance and smile. Be yourself, no matter what they say." Sting From craigs at postincrement.com Sun Nov 26 12:26:04 2006 From: craigs at postincrement.com (Craig Southeren) Date: Sun, 26 Nov 2006 23:26:04 +1100 Subject: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?] In-Reply-To: <45697715.8070009@free.fr> References: <1164539522.3501.11.camel@golgoth01> <45697715.8070009@free.fr> Message-ID: <20061126231728.02BF.CRAIGS@postincrement.com> On Sun, 26 Nov 2006 12:14:29 +0100 Julien Puydt wrote: ..deleted > Here is how gstreamer does, as far as I know : they get the data and > feed it to their codecs, which return something which measures their > confidente it is "correct data" for them. > > So by elimination, they get the right codec, which can then be confirmed > and better tuned afterwards. This sounds like it could require a lot of resources. Imagine a mobile device that has only limited CPU and supports a wide variety of audio and video codecs. Pushing every received RTP packet through every offered codec in order to find one that seems to works would require a lot of extra code to be written, and would require a lot of extra CPU. And it still doesn't address the other issues I described. I think there some other issue at work here. Can someone provide me with a trace log of a call that has the "three second delay"? I'm thinking that perhaps the remote end is sending a 183 with media session information, but for some reason OPAL is not processing the media until the 200 OK is received. But until I get a level 4 trace, I won't know for sure... Craig ----------------------------------------------------------------------- Craig Southeren Post Increment ? VoIP Consulting and Software craigs at postincrement.com.au www.postincrement.com.au Phone: +61 243654666 ICQ: #86852844 Fax: +61 243656905 MSN: craig_southeren at hotmail.com Mobile: +61 417231046 Jabber: craigs at jabber.org "It takes a man to suffer ignorance and smile. Be yourself, no matter what they say." Sting From geboyd53 at comcast.net Sun Nov 26 12:28:43 2006 From: geboyd53 at comcast.net (George Boyd) Date: Sun, 26 Nov 2006 04:28:43 -0800 Subject: [Ekiga-list] ATA or Hardware SIP Phones to use with EKIGA/VoIPBuster In-Reply-To: <1164473791.3589.2.camel@golgoth01> References: <1164452196.8826.8.camel@george> <1164473791.3589.2.camel@golgoth01> Message-ID: <1164544123.19623.3.camel@george> Thanks Damien, I believe you probably know what I'm trying to do. I would like to do the same thing as when gnomemeeting could use the Quicknet card :) On Sat, 2006-11-25 at 17:56 +0100, Damien Sandras wrote: > Le samedi 25 novembre 2006 ? 02:56 -0800, George Boyd a ?crit : > > Trying to find an ATA or SIP hardware phones seems to be a daunting > > task. I love Ekiga for SIP communications and I like VOIPBUSTER for the > > price. I would like to find an ATA adapter or a SIP hardware phone that > > will work with Ekiga and/or VOIPBUSTER. > > > > I'm running Ekiga on Fedora Core 6 and connected to the internet via > > cable. Does such a device work with my setup? If so any help would be > > greatly appreciated. Of course the least cost solution would be best. > > > > I do not have any recommendation, but this page should help: > http://www.voip-info.org/wiki/view/Analog+Telephone+Adapters > From juha.leino at kapsi.fi Sun Nov 26 13:00:45 2006 From: juha.leino at kapsi.fi (Juha Leino) Date: Sun, 26 Nov 2006 15:00:45 +0200 (EET) Subject: [Ekiga-list] Ekiga video problem In-Reply-To: <1164539121.3501.3.camel@golgoth01> References: <10650.84.231.21.101.1164484592.squirrel@mail.kapsi.fi> <1164539121.3501.3.camel@golgoth01> Message-ID: <11521.84.231.21.101.1164546045.squirrel@mail.kapsi.fi> Hi. Yes I think so. The first setting in 'video codec' settings: 'General settings', 'use video' is ticked. (my free translation from Finnish). -- Juha > Hi, > > Is video transmission enabled in the video codecs settings? > > Le samedi 25 novembre 2006 ? 21:56 +0200, Juha Leino a ?crit : >> Hello. >> >> I'm having a problem with video in 500 at ekiga.net. It used to work like a >> charm, but now it suddenly stopped working. The preview is ok before the >> call but as soon as call is started the video freezes. >> >> I have a Logitech UVC camera. I had problems with the driver but after I >> compiled the most recent version (split branch) it seems to be ok. My OS >> is Ubuntu Edgy with a stock kernel. >> >> One thing that came into my mind is my ADSL router (Zyxel 660HW) and its >> setup. It has NAT configured in it, and stun is in use. Zyxel also has a >> SIP ALG functionality that has been enabled (do you need stun still, or >> is >> my >> ALG dead somehow btw?). >> >> Do I perhaps need to open some ports (range of ports) for video perhaps? >> Is there any way of debugging the problem? >> >> With best regards, Juha Leino >> >> >> _______________________________________________ >> ekiga-list mailing list >> ekiga-list at gnome.org >> http://mail.gnome.org/mailman/listinfo/ekiga-list > -- > _ Damien Sandras > (o- > //\ Ekiga Softphone : http://www.ekiga.org/ > v_/_ NOVACOM : http://www.novacom.be/ > FOSDEM : http://www.fosdem.org/ > SIP Phone : sip:dsandras at ekiga.net > > > _______________________________________________ > ekiga-list mailing list > ekiga-list at gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list > From jpuydt at free.fr Sun Nov 26 13:42:33 2006 From: jpuydt at free.fr (Julien Puydt) Date: Sun, 26 Nov 2006 14:42:33 +0100 Subject: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?] In-Reply-To: <20061126231728.02BF.CRAIGS@postincrement.com> References: <1164539522.3501.11.camel@golgoth01> <45697715.8070009@free.fr> <20061126231728.02BF.CRAIGS@postincrement.com> Message-ID: <456999C9.2050708@free.fr> Craig Southeren a ?crit : > On Sun, 26 Nov 2006 12:14:29 +0100 > Julien Puydt wrote: > > ..deleted > >> Here is how gstreamer does, as far as I know : they get the data and >> feed it to their codecs, which return something which measures their >> confidente it is "correct data" for them. >> >> So by elimination, they get the right codec, which can then be confirmed >> and better tuned afterwards. > > This sounds like it could require a lot of resources. Eh, I didn't claim they were doing it right, just explaining how they did ;-) Can we buffer the incoming data until we know how to proceed it ? That would be a very dirty workaround, but would fly. Snark From bbagger at gmail.com Sun Nov 26 16:39:04 2006 From: bbagger at gmail.com (Bent Bagger) Date: Sun, 26 Nov 2006 17:39:04 +0100 Subject: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?] In-Reply-To: <20061126231728.02BF.CRAIGS@postincrement.com> References: <1164539522.3501.11.camel@golgoth01> <45697715.8070009@free.fr> <20061126231728.02BF.CRAIGS@postincrement.com> Message-ID: <2e19719f0611260839t7583734ahbf4e98b4b83c6524@mail.gmail.com> Hi Craig On 26/11/06, Craig Southeren wrote: > .... > Can someone provide me with a trace log of a call that has the "three > second delay"? I'm thinking that perhaps the remote end is sending a 183 > with media session information, but for some reason OPAL is not > processing the media until the 200 OK is received. > Here is a ethereal trace of a call from my Ekiga to my Asterisk. It has the 3 second delay in it. There are a few 'noice' frames in the trace but I hope you can use it anyway. Best regards, Bent -------------- next part -------------- A non-text attachment was scrubbed... Name: chat-ekiga-asterisk.trace Type: application/octet-stream Size: 10757 bytes Desc: not available URL: From bbagger at gmail.com Sun Nov 26 16:49:42 2006 From: bbagger at gmail.com (Bent Bagger) Date: Sun, 26 Nov 2006 17:49:42 +0100 Subject: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?] In-Reply-To: <2e19719f0611260841u125329f0s589d64d501b5451d@mail.gmail.com> References: <1164539522.3501.11.camel@golgoth01> <45697715.8070009@free.fr> <20061126231728.02BF.CRAIGS@postincrement.com> <2e19719f0611260839t7583734ahbf4e98b4b83c6524@mail.gmail.com> <2e19719f0611260841u125329f0s589d64d501b5451d@mail.gmail.com> Message-ID: <2e19719f0611260849o1f0d5202n9da1f6469bb625e4@mail.gmail.com> Hi The e-mail with the trace is now awaitinh moderator approval before it will be posted. Is there a better way of exchanging large files? The trace is approx 1.5 MB. Bent From craigs at postincrement.com Sun Nov 26 22:39:36 2006 From: craigs at postincrement.com (Craig Southeren) Date: Mon, 27 Nov 2006 09:39:36 +1100 Subject: [Ekiga-list] [OpenH323] Receiving SIP RTP before media description [was ekiga answers with delay ...?] In-Reply-To: <4569BF1A.4010007@pldtweroam.com> References: <20061126225804.02B8.CRAIGS@postincrement.com> <4569BF1A.4010007@pldtweroam.com> Message-ID: <20061127092356.2D1C.CRAIGS@postincrement.com> On Mon, 27 Nov 2006 00:21:46 +0800 "Joegen E. Baclor" wrote: ..deleted > > I think that this interpretation is wrong (see my previous email for why). > > > > > I agree with Damien, a offerer "MUST" be ready to accept any stream it > offered even without the the answer. > > Section 5.1, last paragraph > > Once the offerer has sent the offer, it MUST be prepared to receive > media for any recvonly streams described by that offer. It MUST be > prepared to send and receive media for any sendrecv streams in the > offer, and send media for any sendonly streams in the offer (of > course, it cannot actually send until the peer provides an answer > with the needed address and port information). We disagree on the interpretation of "prepared". "Prepared" in this context means that once an offer has been sent, it must be prepared to honor that offer. > Section 7, 3rd paragraph of RFC 3264 states: > > The offerer MAY immediately cease listening for media formats that > were listed in the initial offer, but not present in the answer. This means that once the reply has been received, it can free resources that may have been allocated as a result of the original offer. For example, an endpoint that offers both audio and video, and then receives a reply with only audio, can stop listening for video. > It is MUST and also clearly implied that the offerer should be prepared > to accept ANY payload it sent with the offer. There is no MUST in the para above. ..deleted > > The endpoint is free to chose any offered codec it wants. This may > > result in different codecs in each direction - this is OK and may be > > desirable in some cases. > > Although it is only a SHOULD in 3264, most implementations follow the > same dynamic payload type in the answer as they were mapped in the > offer. It is implied in the following section in 3264 ( Section 5.1 > Paragraph 4 ) The payload types can and do change - Asterisk is a good example of this. The fact that most endpoints don't do this is irrelevant. > For sendrecv RTP > streams, the payload type numbers indicate the value of the payload > type field the offerer expects to receive, and would prefer to send. > However, for sendonly and sendrecv streams, the answer might indicate > different payload type numbers for the same codecs, in which case, > the offerer MUST send with the payload type numbers from the answer. > > Different payload type numbers may be needed in each direction > because of interoperability concerns with H.323. I'm not sure why you think this. H.323 is the same as SIP in this regard - the called party determines whether the same or different payload types are used. > >> However, the codec to use should be determined by the RTP payload. So > >> OPAL should be able to send and receive PCMU/PCMA/iLBC, and choose the > >> correct one as soon as it receives RTP from the remote peer. > > > > I disagree that the first RTP Packet would signify the actual codec to > be used for the session. The final answer should still be considered. > During instances where the initial packet received is not equal to the > preferred codec in the answer, the offerer should honor the codec in the > answer for its outbound stream. If the offere want synchronized codec > for send and receive, then it should offer a reInvite with the single > codec preference it chooses based on the codecs it got from the answer. I disagree. You are proposing a system whereby there are potentially three different codec changes during call startup - first RTP payload detected, 183 Session Progress, and 200 OK. ..deleted Here are two references that show that RTP (even one way audio) is not established in a SIP session until the receipt of a 183 Session Progress or 200 OK. In fact, the 183 message was added specifically to allow the establishement of early media for PSTN progress tones I'm sure there are others Craig draft-ietf-music-183-00.txt ----------------------------- This was original source of the 183 message. There is an excellent explantion of the problem, along with very clear call flow diagrams showing the timing of RTP startup w.r.t to other SIP messages http://www3.ietf.org/proceedings/99jul/slides/mmusic-sip183-99jul/sld008.htm RFC 3666 - SIP Public Switched Telephone Network (PSTN) Call Flows ------------------------------------------------------------------ See call flow in section 2.3 ----------------------------------------------------------------------- Craig Southeren Post Increment ? VoIP Consulting and Software craigs at postincrement.com.au www.postincrement.com.au Phone: +61 243654666 ICQ: #86852844 Fax: +61 243656905 MSN: craig_southeren at hotmail.com Mobile: +61 417231046 Jabber: craigs at jabber.org "It takes a man to suffer ignorance and smile. Be yourself, no matter what they say." Sting From craigs at postincrement.com Sun Nov 26 22:45:14 2006 From: craigs at postincrement.com (Craig Southeren) Date: Mon, 27 Nov 2006 09:45:14 +1100 Subject: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?] In-Reply-To: <2e19719f0611260849o1f0d5202n9da1f6469bb625e4@mail.gmail.com> References: <2e19719f0611260841u125329f0s589d64d501b5451d@mail.gmail.com> <2e19719f0611260849o1f0d5202n9da1f6469bb625e4@mail.gmail.com> Message-ID: <20061127094356.D636.CRAIGS@postincrement.com> On Sun, 26 Nov 2006 17:49:42 +0100 "Bent Bagger" wrote: > Hi > > The e-mail with the trace is now awaitinh moderator approval before it > will be posted. Is there a better way of exchanging large files? The > trace is approx 1.5 MB. Please email the trace directly to me at craigs at postincrement.com BTW: your last message did have a small trace (10.5k) attached to it. Is this related to the trace you are trying to send? Craig ----------------------------------------------------------------------- Craig Southeren Post Increment ? VoIP Consulting and Software craigs at postincrement.com.au www.postincrement.com.au Phone: +61 243654666 ICQ: #86852844 Fax: +61 243656905 MSN: craig_southeren at hotmail.com Mobile: +61 417231046 Jabber: craigs at jabber.org "It takes a man to suffer ignorance and smile. Be yourself, no matter what they say." Sting From bbagger at gmail.com Sun Nov 26 23:01:28 2006 From: bbagger at gmail.com (Bent Bagger) Date: Mon, 27 Nov 2006 00:01:28 +0100 Subject: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?] In-Reply-To: <2e19719f0611260849o1f0d5202n9da1f6469bb625e4@mail.gmail.com> References: <1164539522.3501.11.camel@golgoth01> <45697715.8070009@free.fr> <20061126231728.02BF.CRAIGS@postincrement.com> <2e19719f0611260839t7583734ahbf4e98b4b83c6524@mail.gmail.com> <2e19719f0611260841u125329f0s589d64d501b5451d@mail.gmail.com> <2e19719f0611260849o1f0d5202n9da1f6469bb625e4@mail.gmail.com> Message-ID: <2e19719f0611261501l2a8a23f0j142bb3505b9e8c12@mail.gmail.com> I have uploaded the trace to Savefile.com http://www.savefile.com/files/293084 Regards, Bent From craigs at postincrement.com Sun Nov 26 23:15:29 2006 From: craigs at postincrement.com (Craig Southeren) Date: Mon, 27 Nov 2006 10:15:29 +1100 Subject: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?] In-Reply-To: <2e19719f0611261501l2a8a23f0j142bb3505b9e8c12@mail.gmail.com> References: <2e19719f0611260849o1f0d5202n9da1f6469bb625e4@mail.gmail.com> <2e19719f0611261501l2a8a23f0j142bb3505b9e8c12@mail.gmail.com> Message-ID: <20061127101517.D63E.CRAIGS@postincrement.com> On Mon, 27 Nov 2006 00:01:28 +0100 "Bent Bagger" wrote: > I have uploaded the trace to Savefile.com > > http://www.savefile.com/files/293084 Thank you for taking the time to do this, because hopefully we can now move on to solving the actual problem rather than continuing the rather ridiculous discussion about how to guess the contents of an RTP packet :) The log file you provided shows the following: 0.0513 Send INVITE 0.0555 Receive 100 Trying 0.0571 Receive 200 OK 0.0603 Send ACK 0.0619 Receive first G.711 RTP packet 2.7807 Receive first H.261 RTP packet This obviously shows that Asterisk waits until receiving the ACK before send RTP. I'd be curious to know if Asterisk supports early media via 183 Session Progress - if that is enabled we should see media after the 183 but before the 200. Back to the problem at hand... My guess is that OPAL/Ekiga is not playing the audio until the first H.261 packet is received. I can't think why this would be happening - I'll need a level 4 trace log from OPAL before I can determine why this would be happening. BTW: does simpleopal do the same thing? Craig ----------------------------------------------------------------------- Craig Southeren Post Increment ? VoIP Consulting and Software craigs at postincrement.com.au www.postincrement.com.au Phone: +61 243654666 ICQ: #86852844 Fax: +61 243656905 MSN: craig_southeren at hotmail.com Mobile: +61 417231046 Jabber: craigs at jabber.org "It takes a man to suffer ignorance and smile. Be yourself, no matter what they say." Sting From dsandras at seconix.com Mon Nov 27 08:27:12 2006 From: dsandras at seconix.com (Damien Sandras) Date: Mon, 27 Nov 2006 09:27:12 +0100 Subject: [Ekiga-list] [OpenH323]Re: Receiving SIP RTP before media description [was ekiga answers with delay ...?] In-Reply-To: <20061126231728.02BF.CRAIGS@postincrement.com> References: <1164539522.3501.11.camel@golgoth01> <45697715.8070009@free.fr> <20061126231728.02BF.CRAIGS@postincrement.com> Message-ID: <1164616032.3775.0.camel@golgoth01> Le dimanche 26 novembre 2006 ? 23:26 +1100, Craig Southeren a ?crit : > On Sun, 26 Nov 2006 12:14:29 +0100 > Julien Puydt wrote: > > ..deleted > > > Here is how gstreamer does, as far as I know : they get the data and > > feed it to their codecs, which return something which measures their > > confidente it is "correct data" for them. > > > > So by elimination, they get the right codec, which can then be confirmed > > and better tuned afterwards. > > This sounds like it could require a lot of resources. > > Imagine a mobile device that has only limited CPU and supports a wide > variety of audio and video codecs. Pushing every received RTP packet > through every offered codec in order to find one that seems to works > would require a lot of extra code to be written, and would require a lot > of extra CPU. And it still doesn't address the other issues I described. > > I think there some other issue at work here. > > Can someone provide me with a trace log of a call that has the "three > second delay"? I'm thinking that perhaps the remote end is sending a 183 > with media session information, but for some reason OPAL is not > processing the media until the 200 OK is received. > That's not the case. Asterisk just sends audio immediately after it received the initial INVITE. Just call any echo machine on the net and you will see the behavior. > But until I get a level 4 trace, I won't know for sure... > > Craig > > > ----------------------------------------------------------------------- > Craig Southeren Post Increment ? VoIP Consulting and Software > craigs at postincrement.com.au www.postincrement.com.au > > Phone: +61 243654666 ICQ: #86852844 > Fax: +61 243656905 MSN: craig_southeren at hotmail.com > Mobile: +61 417231046 Jabber: craigs at jabber.org > > "It takes a man to suffer ignorance and smile. > Be yourself, no matter what they say." Sting > > ------------------------------------------------------------------------ > Check the FAQ before asking! - http://www.openh323.org/~openh323/fom.cgi > The OpenH323 Project mailing list, using Mailman. To unsubscribe or > change your subscription options, goto > http://www.openh323.org/mailman/listinfo/openh323 > Maintained by Quicknet Technologies, Inc - http://www.quicknet.net > ------------------------------------------------------------------------ -- _ Damien Sandras (o- //\ Ekiga Softphone : http://www.ekiga.org/ v_/_ NOVACOM : http://www.novacom.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsandras at ekiga.net From dsandras at seconix.com Mon Nov 27 09:30:01 2006 From: dsandras at seconix.com (Damien Sandras) Date: Mon, 27 Nov 2006 10:30:01 +0100 Subject: [Ekiga-list] [OpenH323]Re: Receiving SIP RTP before media description [was ekiga answers with delay ...?] In-Reply-To: <20061126225804.02B8.CRAIGS@postincrement.com> References: <20061126120055.2AED.CRAIGS@postincrement.com> <1164539522.3501.11.camel@golgoth01> <20061126225804.02B8.CRAIGS@postincrement.com> Message-ID: <1164619801.3775.19.camel@golgoth01> Le dimanche 26 novembre 2006 ? 23:07 +1100, Craig Southeren a ?crit : > > > Another limitation is that the codec to use is determined from the 200 > > OK answer in a way that is not necessarily correct. > > > > For example, if you send an INVITE with iLBC, PCMU and PCMA as available > > codecs, and the answer comes with PCMU, PCMA and iLBC (in that order) > > back, how do you determine if you have to send iLBC or PCMU? OPAL will > > send PCMU because it is the preferred codec in the answer. > > The endpoint is free to chose any offered codec it wants. This may > result in different codecs in each direction - this is OK and may be > desirable in some cases. > I agree with you. However, if OPAL 1 offers PCMU, iLBC and PCMA through an INVITE, and OPAL 2 answers with iLBC, PCMA, PCMU in the 200 OK, how does OPAL 2 determine which codec it is receiving? It should do it using the RTP stream payload. Currently, it will decode the stream using one of the three codecs, which is not necessarily the one it is receiving, and it leads to failure. -- _ Damien Sandras (o- //\ Ekiga Softphone : http://www.ekiga.org/ v_/_ NOVACOM : http://www.novacom.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsandras at ekiga.net From dsandras at seconix.com Mon Nov 27 09:30:56 2006 From: dsandras at seconix.com (Damien Sandras) Date: Mon, 27 Nov 2006 10:30:56 +0100 Subject: [Ekiga-list] ATA or Hardware SIP Phones to use with EKIGA/VoIPBuster In-Reply-To: <1164544123.19623.3.camel@george> References: <1164452196.8826.8.camel@george> <1164473791.3589.2.camel@golgoth01> <1164544123.19623.3.camel@george> Message-ID: <1164619856.3775.21.camel@golgoth01> Le dimanche 26 novembre 2006 ? 04:28 -0800, George Boyd a ?crit : > Thanks Damien, I believe you probably know what I'm trying to do. I > would like to do the same thing as when gnomemeeting could use the > Quicknet card :) Well, with an ATA, you will be able to use your normal phone with a SIP account, but it is not Ekiga that will control that phone. -- _ Damien Sandras (o- //\ Ekiga Softphone : http://www.ekiga.org/ v_/_ NOVACOM : http://www.novacom.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsandras at ekiga.net From craigs at postincrement.com Mon Nov 27 09:40:16 2006 From: craigs at postincrement.com (Craig Southeren) Date: Mon, 27 Nov 2006 20:40:16 +1100 Subject: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?] In-Reply-To: <1164619618.3775.15.camel@golgoth01> References: <20061127101517.D63E.CRAIGS@postincrement.com> <1164619618.3775.15.camel@golgoth01> Message-ID: <20061127203750.4F91.CRAIGS@postincrement.com> On Mon, 27 Nov 2006 10:26:58 +0100 Damien Sandras wrote: ..deleted > > My guess is that OPAL/Ekiga is not playing the audio until the first > > H.261 packet is received. I can't think why this would be happening - > > I'll need a level 4 trace log from OPAL before I can determine why this > > would be happening. > > > > The problem is that OPAL opens the media streams when sending/receiving > the ACK and that opening the media streams (soundcard and so on) on a > GNU/Linux system takes about 2 seconds. Why does it take so long? > See the attached output.txt : > 2006/11/27 10:24:10.110 0:13.862 SIP Handle...er:843fa00 SIP > Sending PDU on udp$172.16.100.198:5060 > ACK sip:444 at 172.16.100.198 SIP/2.0^M > > (10:24:10.110) > > Then : > 2006/11/27 10:24:11.256 0:15.008 SIP Handle...er:843fa00 OpalCon > Media stream threads started. > 2006/11/27 10:24:11.257 0:15.009 SIP Handle...er:843fa00 OpalCon > Media stream threads started. > > (We are 1 second later) What is OPAL doing during the one second gap? Are there any log messages? > [...] > 2006/11/27 10:24:11.261 0:15.013 SIP Handle...er:843fa00 OpalMan > OnEstablished > Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] > 2006/11/27 10:24:11.261 0:15.013 SIP Handle...er:843fa00 Call > OnEstablished > Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] > 2006/11/27 10:24:11.274 0:15.026 SIP Handle...er:843fa00 SIP > Awaiting next PDU. > 2006/11/27 10:24:11.276 0:15.028 Media Patc...h:b5e38f18 RTP > Jitter buffer length exceeded > 2006/11/27 10:24:11.276 0:15.028 Media Patc...h:b5e38f18 RTP > Jitter buffer length exceed was prior to first write. Not increasing > buffer size Craig ----------------------------------------------------------------------- Craig Southeren Post Increment ? VoIP Consulting and Software craigs at postincrement.com.au www.postincrement.com.au Phone: +61 243654666 ICQ: #86852844 Fax: +61 243656905 MSN: craig_southeren at hotmail.com Mobile: +61 417231046 Jabber: craigs at jabber.org "It takes a man to suffer ignorance and smile. Be yourself, no matter what they say." Sting From dsandras at seconix.com Mon Nov 27 09:42:01 2006 From: dsandras at seconix.com (Damien Sandras) Date: Mon, 27 Nov 2006 10:42:01 +0100 Subject: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?] In-Reply-To: <20061127101517.D63E.CRAIGS@postincrement.com> References: <2e19719f0611260849o1f0d5202n9da1f6469bb625e4@mail.gmail.com> <2e19719f0611261501l2a8a23f0j142bb3505b9e8c12@mail.gmail.com> <20061127101517.D63E.CRAIGS@postincrement.com> Message-ID: <1164620521.3775.32.camel@golgoth01> Le lundi 27 novembre 2006 ? 10:15 +1100, Craig Southeren a ?crit : > Thank you for taking the time to do this, because hopefully we can now > move on to solving the actual problem rather than continuing the rather > ridiculous discussion about how to guess the contents of an RTP packet :) Do you know that in french "ridiculous" is an insult? ;-) Well, let's forget about that and summarize the results of that discussion. There are actually right now 2 problems in OPAL : 1: Establishing the media streams after having sent or received the ACK takes between 1 or 2 seconds during which the media stream is lost. 2: If OPAL sends an INVITE with 3 codecs in a given order, and that Asterisk supports the 3 same codecs but with a different priority order, it will send the 200 OK with those 3 codecs in the order it prefers. OPAL will then choose the codec it prefers and send the media with that codec. It could happen that Asterisk uses another codec from the list, ie a codec for which OPAL is not ready to receive a stream. e.g. : INVITE PCMU, iLBC, PCMA 200 OK iLBC, PCMA, PCMU OPAL will send the stream using iLBC. Asterisk could decide to send the stream using PCMU. However OPAL expects iLBC... -- _ Damien Sandras (o- //\ Ekiga Softphone : http://www.ekiga.org/ v_/_ NOVACOM : http://www.novacom.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsandras at ekiga.net From craigs at postincrement.com Mon Nov 27 09:50:04 2006 From: craigs at postincrement.com (Craig Southeren) Date: Mon, 27 Nov 2006 20:50:04 +1100 Subject: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?] In-Reply-To: <1164620521.3775.32.camel@golgoth01> References: <20061127101517.D63E.CRAIGS@postincrement.com> <1164620521.3775.32.camel@golgoth01> Message-ID: <20061127204756.4F94.CRAIGS@postincrement.com> On Mon, 27 Nov 2006 10:42:01 +0100 Damien Sandras wrote: ..deleted > Well, let's forget about that and summarize the results of that > discussion. There are actually right now 2 problems in OPAL : > > 1: Establishing the media streams after having sent or received the ACK > takes between 1 or 2 seconds during which the media stream is lost. This seems to be only a problem on Linux. I'm not seeing this problem on Windows. What is OPAL during the 1 or 2 seconds? Is this how long it takes to open the sound device on Linux? I'll need more information before I can work out how to fix the problem > 2: If OPAL sends an INVITE with 3 codecs in a given order, and that > Asterisk supports the 3 same codecs but with a different priority order, > it will send the 200 OK with those 3 codecs in the order it prefers. > OPAL will then choose the codec it prefers and send the media with that > codec. It could happen that Asterisk uses another codec from the list, > ie a codec for which OPAL is not ready to receive a stream. > > e.g. : > INVITE PCMU, iLBC, PCMA > 200 OK iLBC, PCMA, PCMU > > OPAL will send the stream using iLBC. > Asterisk could decide to send the stream using PCMU. > However OPAL expects iLBC... Replying to an INVITE with more than one codec has a very specific meaning, and OPAL does not support these semantics. Fortunately, very few devices seem to do this. Craig ----------------------------------------------------------------------- Craig Southeren Post Increment ? VoIP Consulting and Software craigs at postincrement.com.au www.postincrement.com.au Phone: +61 243654666 ICQ: #86852844 Fax: +61 243656905 MSN: craig_southeren at hotmail.com Mobile: +61 417231046 Jabber: craigs at jabber.org "It takes a man to suffer ignorance and smile. Be yourself, no matter what they say." Sting From joegen at pldtweroam.com Sun Nov 26 16:21:46 2006 From: joegen at pldtweroam.com (Joegen E. Baclor) Date: Mon, 27 Nov 2006 00:21:46 +0800 Subject: [Ekiga-list] [OpenH323]Re: Receiving SIP RTP before media description [was ekiga answers with delay ...?] In-Reply-To: <20061126225804.02B8.CRAIGS@postincrement.com> References: <20061126120055.2AED.CRAIGS@postincrement.com> <1164539522.3501.11.camel@golgoth01> <20061126225804.02B8.CRAIGS@postincrement.com> Message-ID: <4569BF1A.4010007@pldtweroam.com> Craig Southeren wrote: > On Sun, 26 Nov 2006 12:12:02 +0100 > Damien Sandras wrote: > > >> Le dimanche 26 novembre 2006 ? 12:33 +1100, Craig Southeren a ?crit : >> >> [...] >> >> >>> If anything, it would be a bug in OPAL, and so I have copied this email >>> to the correct OPAL mailing list so that other people who are >>> knowledgeable in SIP may see it. >>> >>> >> Most of the OPAL bugs are inside the Ekiga bug tracker. I have moved >> those I don't plan to fix to the openh323 bug tracker. >> > > Understood, and thanks. > > >> However, I think the paragraph in the SIP RFC is clear, when you send an >> offer, you must be ready to receive media for all codecs in that offer >> before the offer has been acknowledged. I understand it sounds weird, >> but that is one of the limitations of OPAL. >> > > I disagree. > > I think that this interpretation is wrong (see my previous email for why). > > I agree with Damien, a offerer "MUST" be ready to accept any stream it offered even without the the answer. Section 5.1, last paragraph Once the offerer has sent the offer, it MUST be prepared to receive media for any recvonly streams described by that offer. It MUST be prepared to send and receive media for any sendrecv streams in the offer, and send media for any sendonly streams in the offer (of course, it cannot actually send until the peer provides an answer with the needed address and port information). Section 7, 3rd paragraph of RFC 3264 states: The offerer MAY immediately cease listening for media formats that were listed in the initial offer, but not present in the answer. It is MUST and also clearly implied that the offerer should be prepared to accept ANY payload it sent with the offer. >> Another limitation is that the codec to use is determined from the 200 >> OK answer in a way that is not necessarily correct. >> >> For example, if you send an INVITE with iLBC, PCMU and PCMA as available >> codecs, and the answer comes with PCMU, PCMA and iLBC (in that order) >> back, how do you determine if you have to send iLBC or PCMU? OPAL will >> send PCMU because it is the preferred codec in the answer. >> > > The endpoint is free to chose any offered codec it wants. This may > result in different codecs in each direction - this is OK and may be > desirable in some cases. > > Although it is only a SHOULD in 3264, most implementations follow the same dynamic payload type in the answer as they were mapped in the offer. It is implied in the following section in 3264 ( Section 5.1 Paragraph 4 ) For sendrecv RTP streams, the payload type numbers indicate the value of the payload type field the offerer expects to receive, and would prefer to send. However, for sendonly and sendrecv streams, the answer might indicate different payload type numbers for the same codecs, in which case, the offerer MUST send with the payload type numbers from the answer. Different payload type numbers may be needed in each direction because of interoperability concerns with H.323. >> However, the codec to use should be determined by the RTP payload. So >> OPAL should be able to send and receive PCMU/PCMA/iLBC, and choose the >> correct one as soon as it receives RTP from the remote peer. >> > > I disagree that the first RTP Packet would signify the actual codec to be used for the session. The final answer should still be considered. During instances where the initial packet received is not equal to the preferred codec in the answer, the offerer should honor the codec in the answer for its outbound stream. If the offere want synchronized codec for send and receive, then it should offer a reInvite with the single codec preference it chooses based on the codecs it got from the answer. > No, this is not correct because the receiving endpoint can chose a > differend payload type. For example, you can offer to do iLBC with > payload type 108, and Speex with payload type 109. The receiver then > decides do Speex with payload type 108 and starts sending RTP with > payload code 108. > This scenario may indeed happen for dynamic payload type. However, given that the offer only contains standard only payloads, being prepared to receive them any time still holds. I think this is the main reason why synchronizing payload mapping is a mere should and not a MUST. The worse thing that would happen is that packets would be dropped by the UAC until a reInvite is sent to arrive at a single and final codec. > If the offerer starts processing media when it receives the first RTP > packet, it will assume it is iLBC, which is wrong. > > There is no way to avoid this problem other than to wait for the session > parameters. See my previous email for other reasons. > > From my understanding of RFC 3264, if the offer sent a sendrecv (default) using a certain payload mapping, the the offer should honor that mapping. The only time unsync streams can occur would be when the offer contains a sendonly attribute for the payload. However, given that indeed there are implementations out there that would ignore such implied "MUST" in 3264, this would result to temporary failure in processing media correctly but would still be corrected upon receipt of actual answer or with a reInvite if the answer contains multiple payloads. It is better to start processing media and hope that it works than not process it at all when it is present. The only fatal assumption here is to assume that the first received packet will be considered as the final negotiated codec. This is wrong in my opinion. >> However, that is a non trivial change to OPAL. >> > > It is extremely non-trivial. Robert and I cannot even see a way to do it > that would not require major surgery to OPAL. > > >> What do you think? >> > > Robert and myself discussed this this topic yesterday. Our opinion is in > my previous email > > Craig > > ----------------------------------------------------------------------- > Craig Southeren Post Increment ? VoIP Consulting and Software > craigs at postincrement.com.au www.postincrement.com.au > > Phone: +61 243654666 ICQ: #86852844 > Fax: +61 243656905 MSN: craig_southeren at hotmail.com > Mobile: +61 417231046 Jabber: craigs at jabber.org > > "It takes a man to suffer ignorance and smile. > Be yourself, no matter what they say." Sting > > ------------------------------------------------------------------------ > Check the FAQ before asking! - http://www.openh323.org/~openh323/fom.cgi > The OpenH323 Project mailing list, using Mailman. To unsubscribe or > change your subscription options, goto > http://www.openh323.org/mailman/listinfo/openh323 > Maintained by Quicknet Technologies, Inc - http://www.quicknet.net > ------------------------------------------------------------------------ > > From dsandras at seconix.com Mon Nov 27 09:26:58 2006 From: dsandras at seconix.com (Damien Sandras) Date: Mon, 27 Nov 2006 10:26:58 +0100 Subject: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?] In-Reply-To: <20061127101517.D63E.CRAIGS@postincrement.com> References: <2e19719f0611260849o1f0d5202n9da1f6469bb625e4@mail.gmail.com> <2e19719f0611261501l2a8a23f0j142bb3505b9e8c12@mail.gmail.com> <20061127101517.D63E.CRAIGS@postincrement.com> Message-ID: <1164619618.3775.15.camel@golgoth01> Le lundi 27 novembre 2006 ? 10:15 +1100, Craig Southeren a ?crit : > On Mon, 27 Nov 2006 00:01:28 +0100 > "Bent Bagger" wrote: > > > I have uploaded the trace to Savefile.com > > > > http://www.savefile.com/files/293084 > > Thank you for taking the time to do this, because hopefully we can now > move on to solving the actual problem rather than continuing the rather > ridiculous discussion about how to guess the contents of an RTP packet :) > > The log file you provided shows the following: > > 0.0513 Send INVITE > 0.0555 Receive 100 Trying > 0.0571 Receive 200 OK > 0.0603 Send ACK > 0.0619 Receive first G.711 RTP packet > 2.7807 Receive first H.261 RTP packet > > This obviously shows that Asterisk waits until receiving the ACK before > send RTP. I'd be curious to know if Asterisk supports early media via > 183 Session Progress - if that is enabled we should see media after the > 183 but before the 200. > > Back to the problem at hand... > > My guess is that OPAL/Ekiga is not playing the audio until the first > H.261 packet is received. I can't think why this would be happening - > I'll need a level 4 trace log from OPAL before I can determine why this > would be happening. > The problem is that OPAL opens the media streams when sending/receiving the ACK and that opening the media streams (soundcard and so on) on a GNU/Linux system takes about 2 seconds. See the attached output.txt : 2006/11/27 10:24:10.110 0:13.862 SIP Handle...er:843fa00 SIP Sending PDU on udp$172.16.100.198:5060 ACK sip:444 at 172.16.100.198 SIP/2.0^M (10:24:10.110) Then : 2006/11/27 10:24:11.256 0:15.008 SIP Handle...er:843fa00 OpalCon Media stream threads started. 2006/11/27 10:24:11.257 0:15.009 SIP Handle...er:843fa00 OpalCon Media stream threads started. (We are 1 second later) [...] 2006/11/27 10:24:11.261 0:15.013 SIP Handle...er:843fa00 OpalMan OnEstablished Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:11.261 0:15.013 SIP Handle...er:843fa00 Call OnEstablished Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:11.274 0:15.026 SIP Handle...er:843fa00 SIP Awaiting next PDU. 2006/11/27 10:24:11.276 0:15.028 Media Patc...h:b5e38f18 RTP Jitter buffer length exceeded 2006/11/27 10:24:11.276 0:15.028 Media Patc...h:b5e38f18 RTP Jitter buffer length exceed was prior to first write. Not increasing buffer size > BTW: does simpleopal do the same thing? Yes, it does the same thing... (both of them are using OPAL). -- _ Damien Sandras (o- //\ Ekiga Softphone : http://www.ekiga.org/ v_/_ NOVACOM : http://www.novacom.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsandras at ekiga.net -------------- next part -------------- 2006/11/27 10:23:56.481 0:00.234 ekiga Detected audio plugins: ALSA,OSS,ESD 2006/11/27 10:23:56.482 0:00.234 ekiga Detected video plugins: YUVFile,Shm,Picture,V4L 2006/11/27 10:23:56.482 0:00.234 ekiga Detected audio plugins: ALSA,OSS,ESD 2006/11/27 10:23:56.482 0:00.234 ekiga Detected video plugins: YUVFile,Shm,Picture,V4L 2006/11/27 10:23:56.488 0:00.240 ekiga Detected the following audio input devices: SiS SI7012,SiS SI7013 Modem,Default with plugin ALSA 2006/11/27 10:23:56.488 0:00.240 ekiga Detected the following audio output devices: SiS SI7012,SiS SI7013 Modem,Default with plugin ALSA 2006/11/27 10:23:56.488 0:00.240 ekiga Detected the following video input devices: StaticPicture,MovingLogo with plugin Picture 2006/11/27 10:23:56.488 0:00.240 ekiga Detected the following audio input devices: SiS SI7012,SiS SI7013 Modem,Default with plugin ALSA 2006/11/27 10:23:56.488 0:00.240 ekiga Detected the following audio output devices: SiS SI7012,SiS SI7013 Modem,Default with plugin ALSA 2006/11/27 10:23:56.488 0:00.240 ekiga Detected the following video input devices: StaticPicture,MovingLogo with plugin Picture 2006/11/27 10:23:56.960 0:00.713 ekiga Ekiga version 2.1.0 2006/11/27 10:23:56.961 0:00.713 ekiga OPAL version 2.3.2 2006/11/27 10:23:56.961 0:00.713 ekiga PWLIB version 1.11.2 2006/11/27 10:23:56.961 0:00.713 ekiga GNOME support disabled 2006/11/27 10:23:56.961 0:00.713 ekiga Fullscreen support enabled 2006/11/27 10:23:56.961 0:00.714 ekiga DBUS support enabled 2006/11/27 10:23:56.964 0:00.716 ekiga Set TCP port range to 30000:30010 2006/11/27 10:23:56.964 0:00.716 ekiga Set RTP port range to 5000:5059 2006/11/27 10:23:56.964 0:00.716 ekiga Set UDP port range to 5060:5100 2006/11/27 10:23:56.964 0:00.717 ekiga OpalEP Created endpoint: h323 2006/11/27 10:23:56.965 0:00.717 ekiga H460 Endpoint Attached 2006/11/27 10:23:56.965 0:00.717 ekiga H323 Created endpoint. 2006/11/27 10:23:56.965 0:00.717 ekiga OpalMan Added route "pc:.*=h323:" 2006/11/27 10:23:56.966 0:00.718 ekiga OpalEP Created endpoint: sip 2006/11/27 10:23:56.966 0:00.718 ekiga SIP Created endpoint. 2006/11/27 10:23:56.966 0:00.718 ekiga OpalMan Added route "pc:.*=sip:" 2006/11/27 10:23:56.966 0:00.718 ekiga OpalEP Created endpoint: pc 2006/11/27 10:23:57.012 0:00.765 ekiga PCSS Created PC sound system endpoint. 2006/11/27 10:23:57.013 0:00.765 ekiga OpalMan Added route "h323:.*=pc:" 2006/11/27 10:23:57.013 0:00.765 ekiga OpalMan Added route "sip:.*=pc:" 2006/11/27 10:23:57.018 0:00.770 Opal Liste...er:83f93c8 Listen Started listening thread on udp$172.16.100.166:1720 2006/11/27 10:23:57.018 0:00.770 Opal Liste...er:83f93c8 Listen Waiting on UDP packet on udp$172.16.100.166:1720 2006/11/27 10:23:57.019 0:00.771 Opal Liste...er:83fab50 Listen Started listening thread on udp$172.16.100.166:5060 2006/11/27 10:23:57.019 0:00.771 Opal Liste...er:83fab50 Listen Waiting on UDP packet on udp$172.16.100.166:5060 2006/11/27 10:23:57.043 0:00.795 ekiga Detected audio codecs: G.711-ALaw-64k,G.711-uLaw-64k,G.726-16k,G.726-24k,G.726-32k,G.726-40k,GSM-06.10,GSM-AMR,iLBC-13k3,LPC-10,SpeexNB,SpeexIETFNarrow-8k,SpeexWNarrow-8k,SpeexWB,SpeexIETFWide-20.6k 2006/11/27 10:23:57.092 0:00.844 ekiga Detected video codecs: H.261,H.261-CIF,H.261-QCIF 2006/11/27 10:23:57.179 0:00.931 GMAccounts...t:083fd178 SIP Could not find active REGISTER for dsandras at ekiga.net 2006/11/27 10:23:57.179 0:00.931 GMAccounts...t:083fd178 SIP Could not find active REGISTER for damien.sandras at voip.wengo.fr 2006/11/27 10:23:57.221 0:00.973 GMAccounts...t:083fd178 OpalUDP Binding to interface: 172.16.100.166:32791 2006/11/27 10:23:57.221 0:00.973 GMAccounts...t:083fd178 SIP Created transport udp$0.0.0.0 2006/11/27 10:23:57.222 0:00.974 GMAccounts...t:083fd178 OpalUDP Started connect to 172.16.100.198:5060 2006/11/27 10:23:57.223 0:00.975 GMAccounts...t:083fd178 OpalUDP Connect on pre-bound interface: 172.16.100.166 2006/11/27 10:23:57.224 0:00.976 GMAccounts...t:083fd178 SIP Created new transport for 172.16.100.198 : udp$172.16.100.198:5060 2006/11/27 10:23:57.230 0:00.982 GMAccounts...t:083fd178 SIP Sending PDU on udp$172.16.100.198:5060 REGISTER sip:172.16.100.198 SIP/2.0 CSeq: 1 REGISTER Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bK841b39ad-667c-db11-8a96-00c09f2d8163;rport User-Agent: Ekiga/2.1.0 From: ;tag=1e0439ad-667c-db11-8a96-00c09f2d8163 Call-ID: f49337ad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: Contact: Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE,INFO,PING,PUBLISH Expires: 3600 Content-Length: 0 Max-Forwards: 70 2006/11/27 10:23:57.232 0:00.984 GMAccounts...t:083fd178 SIP Could not find active REGISTER for 274738 at fwd.pulver.com 2006/11/27 10:23:57.232 0:00.984 GMAccounts...t:083fd178 SIP Could not find active REGISTER for 06213804954 at sip2.neophonex.hu 2006/11/27 10:23:57.233 0:00.985 GMAccounts...t:083fd178 SIP Could not find active REGISTER for 6359 at itbx-polymedis 2006/11/27 10:23:57.233 0:00.985 SIP Transp...t:b5e2cb40 SIP Read thread started. 2006/11/27 10:23:57.234 0:00.986 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:23:57.235 0:00.987 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 SIP/2.0 100 Trying CSeq: 1 REGISTER Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bK841b39ad-667c-db11-8a96-00c09f2d8163;rport;received=172.16.100.166 User-Agent: Asterisk PBX From: ;tag=1e0439ad-667c-db11-8a96-00c09f2d8163 Call-ID: f49337ad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 2006/11/27 10:23:57.237 0:00.989 SIP Transp...t:b5e2cb40 SIP Transaction 1 REGISTER proceeding. 2006/11/27 10:23:57.237 0:00.989 SIP Transp...t:b5e2cb40 OpalUDP Ended connect, selecting 172.16.100.166:5061 2006/11/27 10:23:57.238 0:00.990 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:23:57.239 0:00.991 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 SIP/2.0 401 Unauthorized CSeq: 1 REGISTER Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bK841b39ad-667c-db11-8a96-00c09f2d8163;rport;received=172.16.100.166 User-Agent: Asterisk PBX From: ;tag=1e0439ad-667c-db11-8a96-00c09f2d8163 Call-ID: f49337ad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: ;tag=as4b2f79e2 Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 WWW-Authenticate: Digest algorithm=MD5, realm="novacom", nonce="2c83b4d4" 2006/11/27 10:23:57.240 0:00.992 SIP Transp...t:b5e2cb40 SIP Transaction 1 REGISTER completed. 2006/11/27 10:23:57.240 0:00.993 SIP Transp...t:b5e2cb40 SIP Received Authentication Required response 2006/11/27 10:23:57.241 0:00.993 SIP Transp...t:b5e2cb40 SIP Updated realm to novacom 2006/11/27 10:23:57.245 0:00.997 SIP Transp...t:b5e2cb40 SIP Adding authentication information 2006/11/27 10:23:57.246 0:00.998 SIP Transp...t:b5e2cb40 SIP Sending PDU on udp$172.16.100.198:5060 REGISTER sip:172.16.100.198 SIP/2.0 CSeq: 2 REGISTER Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bKd6a83bad-667c-db11-8a96-00c09f2d8163;rport User-Agent: Ekiga/2.1.0 Authorization: Digest username="9197", realm="novacom", nonce="2c83b4d4", uri="sip:172.16.100.198", algorithm=md5, response="c45a43a6d7ee52b35ea35860d0344cd2" From: ;tag=1e0439ad-667c-db11-8a96-00c09f2d8163 Call-ID: f49337ad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: Contact: Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE,INFO,PING,PUBLISH Expires: 3600 Content-Length: 0 Max-Forwards: 70 2006/11/27 10:23:57.247 0:00.999 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:23:57.248 0:01.000 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 SIP/2.0 100 Trying CSeq: 2 REGISTER Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bKd6a83bad-667c-db11-8a96-00c09f2d8163;rport;received=172.16.100.166 User-Agent: Asterisk PBX From: ;tag=1e0439ad-667c-db11-8a96-00c09f2d8163 Call-ID: f49337ad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 2006/11/27 10:23:57.249 0:01.002 SIP Transp...t:b5e2cb40 SIP Transaction 2 REGISTER proceeding. 2006/11/27 10:23:57.250 0:01.002 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:23:57.252 0:01.004 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 OPTIONS sip:9197 at 172.16.100.166:5061;transport=udp SIP/2.0 Date: Mon, 27 Nov 2006 09:51:08 GMT CSeq: 102 OPTIONS Via: SIP/2.0/UDP 172.16.100.198:5060;branch=z9hG4bK50a7bacb;rport User-Agent: Asterisk PBX From: "asterisk" ;tag=as085fd1a2 Call-ID: 5d4666de20206c12242782446b178996 at 172.16.100.198 To: Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 Max-Forwards: 70 2006/11/27 10:23:57.253 0:01.006 SIP Transp...t:b5e2cb40 SIP Tranport remote address change from Via: udp$172.16.100.198:5060 2006/11/27 10:23:57.256 0:01.008 SIP Transp...t:b5e2cb40 SIP Sending PDU on udp$172.16.100.198:5060 SIP/2.0 200 OK CSeq: 102 OPTIONS Via: SIP/2.0/UDP 172.16.100.198:5060;branch=z9hG4bK50a7bacb;rport=5060;received=172.16.100.198 From: "asterisk" ;tag=as085fd1a2 Call-ID: 5d4666de20206c12242782446b178996 at 172.16.100.198 To: Contact: Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE,INFO,PING,PUBLISH Content-Length: 0 2006/11/27 10:23:57.257 0:01.009 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:23:57.258 0:01.010 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 SIP/2.0 200 OK Date: Mon, 27 Nov 2006 09:51:08 GMT CSeq: 2 REGISTER Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bKd6a83bad-667c-db11-8a96-00c09f2d8163;rport;received=172.16.100.166 User-Agent: Asterisk PBX From: ;tag=1e0439ad-667c-db11-8a96-00c09f2d8163 Call-ID: f49337ad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: ;tag=as4b2f79e2 Contact: ;expires=3600 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Expires: 3600 Content-Length: 0 2006/11/27 10:23:57.259 0:01.011 SIP Transp...t:b5e2cb40 SIP Transaction 2 REGISTER completed. 2006/11/27 10:23:57.356 0:01.108 SIP Transp...t:b5e2cb40 SIP Using existing transport udp$172.16.100.198:5060 for 172.16.100.198 2006/11/27 10:23:57.361 0:01.113 GMAccounts...t:083fd178 SIP Using existing transport udp$172.16.100.198:5060 for 172.16.100.198 2006/11/27 10:23:57.361 0:01.113 SIP Transp...t:b5e2cb40 SIP Sending PDU on udp$172.16.100.198:5060 PUBLISH sip:9197 at 172.16.100.198 SIP/2.0 CSeq: 3 PUBLISH Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bK98204dad-667c-db11-8a96-00c09f2d8163;rport User-Agent: Ekiga/2.1.0 From: ;tag=18194dad-667c-db11-8a96-00c09f2d8163 Call-ID: e6f54cad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: Contact: Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE,INFO,PING,PUBLISH Expires: 500 Event: presence Content-Type: application/pidf+xml Content-Length: 310 Max-Forwards: 70 Away open 9197 at 172.16.100.198 2006/11/27 10:23:57.362 0:01.114 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:23:57.363 0:01.115 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 SIP/2.0 501 Method Not Implemented CSeq: 3 PUBLISH Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bK98204dad-667c-db11-8a96-00c09f2d8163;rport;received=172.16.100.166 User-Agent: Asterisk PBX From: ;tag=18194dad-667c-db11-8a96-00c09f2d8163 Call-ID: e6f54cad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: ;tag=as6c1fb783 Accept: application/sdp Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 2006/11/27 10:23:57.364 0:01.116 SIP Transp...t:b5e2cb40 SIP Transaction 3 PUBLISH completed. 2006/11/27 10:23:57.365 0:01.117 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:23:57.365 0:01.118 GMAccounts...t:083fd178 SIP Sending PDU on udp$172.16.100.198:5060 SUBSCRIBE sip:9105 at 172.16.100.198 SIP/2.0 CSeq: 1 SUBSCRIBE Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bKc4f34dad-667c-db11-8a96-00c09f2d8163;rport User-Agent: Ekiga/2.1.0 From: ;tag=eac34dad-667c-db11-8a96-00c09f2d8163 Call-ID: 127e4dad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: Contact: Accept: application/pidf+xml Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE,INFO,PING,PUBLISH Expires: 500 Event: presence Content-Length: 0 Max-Forwards: 70 2006/11/27 10:23:57.367 0:01.120 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 SIP/2.0 401 Unauthorized CSeq: 1 SUBSCRIBE Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bKc4f34dad-667c-db11-8a96-00c09f2d8163;rport;received=172.16.100.166 User-Agent: Asterisk PBX From: ;tag=eac34dad-667c-db11-8a96-00c09f2d8163 Call-ID: 127e4dad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: ;tag=as12885a66 Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 WWW-Authenticate: Digest algorithm=MD5, realm="novacom", nonce="048b5552" 2006/11/27 10:23:57.369 0:01.121 SIP Transp...t:b5e2cb40 SIP Transaction 1 SUBSCRIBE completed. 2006/11/27 10:23:57.369 0:01.121 SIP Transp...t:b5e2cb40 SIP Received Authentication Required response 2006/11/27 10:23:57.372 0:01.124 SIP Transp...t:b5e2cb40 SIP Adding authentication information 2006/11/27 10:23:57.373 0:01.125 SIP Transp...t:b5e2cb40 SIP Sending PDU on udp$172.16.100.198:5060 SUBSCRIBE sip:9105 at 172.16.100.198 SIP/2.0 CSeq: 2 SUBSCRIBE Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bKaa1b4fad-667c-db11-8a96-00c09f2d8163;rport User-Agent: Ekiga/2.1.0 Authorization: Digest username="9197", realm="novacom", nonce="048b5552", uri="sip:9105 at 172.16.100.198", algorithm=md5, response="0c81d5a630f2c65f8826aa2646769e77" From: ;tag=eac34dad-667c-db11-8a96-00c09f2d8163 Call-ID: 127e4dad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: Contact: Accept: application/pidf+xml Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE,INFO,PING,PUBLISH Expires: 500 Event: presence Content-Length: 0 Max-Forwards: 70 2006/11/27 10:23:57.373 0:01.125 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:23:57.375 0:01.127 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 SIP/2.0 200 OK CSeq: 2 SUBSCRIBE Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bKaa1b4fad-667c-db11-8a96-00c09f2d8163;rport;received=172.16.100.166 User-Agent: Asterisk PBX From: ;tag=eac34dad-667c-db11-8a96-00c09f2d8163 Call-ID: 127e4dad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: ;tag=as12885a66 Contact: ;expires=500 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Expires: 500 Content-Length: 0 2006/11/27 10:23:57.376 0:01.128 SIP Transp...t:b5e2cb40 SIP Transaction 2 SUBSCRIBE completed. 2006/11/27 10:23:57.377 0:01.129 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:23:57.378 0:01.130 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 NOTIFY sip:9197 at 172.16.100.198 SIP/2.0 CSeq: 102 NOTIFY Via: SIP/2.0/UDP 172.16.100.198:5060;branch=z9hG4bK208a40f7;rport User-Agent: Asterisk PBX From: ;tag=as12885a66 Call-ID: 127e4dad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: ;tag=eac34dad-667c-db11-8a96-00c09f2d8163 Contact: Subscription-State: active Event: presence Content-Type: application/pidf+xml Content-Length: 483 Max-Forwards: 70 Ready sip:9105 at 172.16.100.198 open 2006/11/27 10:23:57.379 0:01.131 SIP Transp...t:b5e2cb40 SIP Tranport remote address change from Via: udp$172.16.100.198:5060 2006/11/27 10:23:57.379 0:01.131 SIP Transp...t:b5e2cb40 SIP Received NOTIFY 2006/11/27 10:23:57.380 0:01.132 SIP Transp...t:b5e2cb40 SIP Found a SUBSCRIBE corresponding to the NOTIFY 2006/11/27 10:23:57.380 0:01.132 SIP Transp...t:b5e2cb40 SIP Subscription is active 2006/11/27 10:23:57.384 0:01.136 SIP Transp...t:b5e2cb40 SIP Sending PDU on udp$172.16.100.198:5060 SIP/2.0 200 OK CSeq: 102 NOTIFY Via: SIP/2.0/UDP 172.16.100.198:5060;branch=z9hG4bK208a40f7;rport=5060;received=172.16.100.198 From: ;tag=as12885a66 Call-ID: 127e4dad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: ;tag=eac34dad-667c-db11-8a96-00c09f2d8163 Contact: Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE,INFO,PING,PUBLISH Content-Length: 0 2006/11/27 10:23:57.385 0:01.137 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:23:58.243 0:01.995 Housekeeper SIP Set state Terminated_Success for transaction 1 REGISTER 2006/11/27 10:23:58.259 0:02.011 Housekeeper SIP Set state Terminated_Success for transaction 2 REGISTER 2006/11/27 10:23:58.367 0:02.119 Housekeeper SIP Set state Terminated_Success for transaction 3 PUBLISH 2006/11/27 10:23:58.371 0:02.123 Housekeeper SIP Set state Terminated_Success for transaction 1 SUBSCRIBE 2006/11/27 10:23:58.379 0:02.131 Housekeeper SIP Set state Terminated_Success for transaction 2 SUBSCRIBE 2006/11/27 10:24:06.492 0:10.244 Housekeeper SIP Deleting SIPPublishInfo sip:9197 at 172.16.100.198 2006/11/27 10:24:06.492 0:10.245 Housekeeper SIP Deleting SIPInfo sip:9197 at 172.16.100.198 2006/11/27 10:24:08.382 0:12.134 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 NOTIFY sip:9197 at 172.16.100.166:5061;transport=udp SIP/2.0 CSeq: 102 NOTIFY Via: SIP/2.0/UDP 172.16.100.198:5060;branch=z9hG4bK5803d7b4;rport User-Agent: Asterisk PBX From: "asterisk" ;tag=as222fac2f Call-ID: 34323c203ec199a764bc23d952195410 at 172.16.100.198 To: Contact: Event: message-summary Content-Type: application/simple-message-summary Content-Length: 94 Max-Forwards: 70 Messages-Waiting: no Message-Account: sip:asterisk at 172.16.100.198 Voice-Message: 0/0 (0/0) 2006/11/27 10:24:08.383 0:12.135 SIP Transp...t:b5e2cb40 SIP Tranport remote address change from Via: udp$172.16.100.198:5060 2006/11/27 10:24:08.383 0:12.135 SIP Transp...t:b5e2cb40 SIP Received NOTIFY 2006/11/27 10:24:08.383 0:12.135 SIP Transp...t:b5e2cb40 SIP Could not find a SUBSCRIBE corresponding to the NOTIFY 2006/11/27 10:24:08.383 0:12.135 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:24:08.397 0:12.149 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 NOTIFY sip:9197 at 172.16.100.166:5061;transport=udp SIP/2.0 CSeq: 102 NOTIFY Via: SIP/2.0/UDP 172.16.100.198:5060;branch=z9hG4bK5803d7b4;rport User-Agent: Asterisk PBX From: "asterisk" ;tag=as222fac2f Call-ID: 34323c203ec199a764bc23d952195410 at 172.16.100.198 To: Contact: Event: message-summary Content-Type: application/simple-message-summary Content-Length: 94 Max-Forwards: 70 Messages-Waiting: no Message-Account: sip:asterisk at 172.16.100.198 Voice-Message: 0/0 (0/0) 2006/11/27 10:24:08.398 0:12.150 SIP Transp...t:b5e2cb40 SIP Tranport remote address change from Via: udp$172.16.100.198:5060 2006/11/27 10:24:08.398 0:12.150 SIP Transp...t:b5e2cb40 SIP Received NOTIFY 2006/11/27 10:24:08.399 0:12.151 SIP Transp...t:b5e2cb40 SIP Could not find a SUBSCRIBE corresponding to the NOTIFY 2006/11/27 10:24:08.399 0:12.151 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:24:08.414 0:12.166 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 NOTIFY sip:9197 at 172.16.100.166:5061;transport=udp SIP/2.0 CSeq: 102 NOTIFY Via: SIP/2.0/UDP 172.16.100.198:5060;branch=z9hG4bK5803d7b4;rport User-Agent: Asterisk PBX From: "asterisk" ;tag=as222fac2f Call-ID: 34323c203ec199a764bc23d952195410 at 172.16.100.198 To: Contact: Event: message-summary Content-Type: application/simple-message-summary Content-Length: 94 Max-Forwards: 70 Messages-Waiting: no Message-Account: sip:asterisk at 172.16.100.198 Voice-Message: 0/0 (0/0) 2006/11/27 10:24:08.414 0:12.166 SIP Transp...t:b5e2cb40 SIP Tranport remote address change from Via: udp$172.16.100.198:5060 2006/11/27 10:24:08.415 0:12.167 SIP Transp...t:b5e2cb40 SIP Received NOTIFY 2006/11/27 10:24:08.415 0:12.167 SIP Transp...t:b5e2cb40 SIP Could not find a SUBSCRIBE corresponding to the NOTIFY 2006/11/27 10:24:08.415 0:12.167 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:24:08.446 0:12.198 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 NOTIFY sip:9197 at 172.16.100.166:5061;transport=udp SIP/2.0 CSeq: 102 NOTIFY Via: SIP/2.0/UDP 172.16.100.198:5060;branch=z9hG4bK5803d7b4;rport User-Agent: Asterisk PBX From: "asterisk" ;tag=as222fac2f Call-ID: 34323c203ec199a764bc23d952195410 at 172.16.100.198 To: Contact: Event: message-summary Content-Type: application/simple-message-summary Content-Length: 94 Max-Forwards: 70 Messages-Waiting: no Message-Account: sip:asterisk at 172.16.100.198 Voice-Message: 0/0 (0/0) 2006/11/27 10:24:08.446 0:12.198 SIP Transp...t:b5e2cb40 SIP Tranport remote address change from Via: udp$172.16.100.198:5060 2006/11/27 10:24:08.447 0:12.199 SIP Transp...t:b5e2cb40 SIP Received NOTIFY 2006/11/27 10:24:08.447 0:12.199 SIP Transp...t:b5e2cb40 SIP Could not find a SUBSCRIBE corresponding to the NOTIFY 2006/11/27 10:24:08.447 0:12.199 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:24:08.510 0:12.262 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 NOTIFY sip:9197 at 172.16.100.166:5061;transport=udp SIP/2.0 CSeq: 102 NOTIFY Via: SIP/2.0/UDP 172.16.100.198:5060;branch=z9hG4bK5803d7b4;rport User-Agent: Asterisk PBX From: "asterisk" ;tag=as222fac2f Call-ID: 34323c203ec199a764bc23d952195410 at 172.16.100.198 To: Contact: Event: message-summary Content-Type: application/simple-message-summary Content-Length: 94 Max-Forwards: 70 Messages-Waiting: no Message-Account: sip:asterisk at 172.16.100.198 Voice-Message: 0/0 (0/0) 2006/11/27 10:24:08.510 0:12.262 SIP Transp...t:b5e2cb40 SIP Tranport remote address change from Via: udp$172.16.100.198:5060 2006/11/27 10:24:08.511 0:12.263 SIP Transp...t:b5e2cb40 SIP Received NOTIFY 2006/11/27 10:24:08.511 0:12.263 SIP Transp...t:b5e2cb40 SIP Could not find a SUBSCRIBE corresponding to the NOTIFY 2006/11/27 10:24:08.511 0:12.263 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:24:08.638 0:12.390 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 NOTIFY sip:9197 at 172.16.100.166:5061;transport=udp SIP/2.0 CSeq: 102 NOTIFY Via: SIP/2.0/UDP 172.16.100.198:5060;branch=z9hG4bK5803d7b4;rport User-Agent: Asterisk PBX From: "asterisk" ;tag=as222fac2f Call-ID: 34323c203ec199a764bc23d952195410 at 172.16.100.198 To: Contact: Event: message-summary Content-Type: application/simple-message-summary Content-Length: 94 Max-Forwards: 70 Messages-Waiting: no Message-Account: sip:asterisk at 172.16.100.198 Voice-Message: 0/0 (0/0) 2006/11/27 10:24:08.638 0:12.390 SIP Transp...t:b5e2cb40 SIP Tranport remote address change from Via: udp$172.16.100.198:5060 2006/11/27 10:24:08.639 0:12.391 SIP Transp...t:b5e2cb40 SIP Received NOTIFY 2006/11/27 10:24:08.639 0:12.391 SIP Transp...t:b5e2cb40 SIP Could not find a SUBSCRIBE corresponding to the NOTIFY 2006/11/27 10:24:08.639 0:12.391 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:24:08.897 0:12.650 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 NOTIFY sip:9197 at 172.16.100.166:5061;transport=udp SIP/2.0 CSeq: 102 NOTIFY Via: SIP/2.0/UDP 172.16.100.198:5060;branch=z9hG4bK5803d7b4;rport User-Agent: Asterisk PBX From: "asterisk" ;tag=as222fac2f Call-ID: 34323c203ec199a764bc23d952195410 at 172.16.100.198 To: Contact: Event: message-summary Content-Type: application/simple-message-summary Content-Length: 94 Max-Forwards: 70 Messages-Waiting: no Message-Account: sip:asterisk at 172.16.100.198 Voice-Message: 0/0 (0/0) 2006/11/27 10:24:08.898 0:12.650 SIP Transp...t:b5e2cb40 SIP Tranport remote address change from Via: udp$172.16.100.198:5060 2006/11/27 10:24:08.898 0:12.650 SIP Transp...t:b5e2cb40 SIP Received NOTIFY 2006/11/27 10:24:08.899 0:12.651 SIP Transp...t:b5e2cb40 SIP Could not find a SUBSCRIBE corresponding to the NOTIFY 2006/11/27 10:24:08.899 0:12.651 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:24:09.959 0:13.711 GMURLHandl...r:0843fa00 OpalMan Set up call from pc:* to sip:444 at 172.16.100.198 2006/11/27 10:24:09.959 0:13.711 GMURLHandl...r:0843fa00 Call Created Call[1] 2006/11/27 10:24:09.960 0:13.712 GMURLHandl...r:0843fa00 OpalMan Set up connection to "pc:*" 2006/11/27 10:24:10.012 0:13.767 GMURLHandl...r:0843fa00 OpalCon Created connection Call[1]-EP[Default] 2006/11/27 10:24:10.015 0:13.767 GMURLHandl...r:0843fa00 RFC2833 Handler created 2006/11/27 10:24:10.015 0:13.767 GMURLHandl...r:0843fa00 Silence Handler created 2006/11/27 10:24:10.015 0:13.767 GMURLHandl...r:0843fa00 Echo Canceler Handler created 2006/11/27 10:24:10.015 0:13.768 GMURLHandl...r:0843fa00 PCSS Created PC sound system connection. 2006/11/27 10:24:10.016 0:13.768 GMURLHandl...r:0843fa00 OpalMan On incoming connection Call[1]-EP[Default] 2006/11/27 10:24:10.016 0:13.768 GMURLHandl...r:0843fa00 Call GetOtherPartyConnection Call[1]-EP[Default] 2006/11/27 10:24:10.016 0:13.768 GMURLHandl...r:0843fa00 OpalMan Set up connection to "sip:444 at 172.16.100.198" 2006/11/27 10:24:10.017 0:13.769 GMURLHandl...r:0843fa00 OpalCon Created connection Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:10.017 0:13.769 GMURLHandl...r:0843fa00 RFC2833 Handler created 2006/11/27 10:24:10.018 0:13.770 GMURLHandl...r:0843fa00 SIP Created connection. 2006/11/27 10:24:10.018 0:13.770 GMURLHandl...r:0843fa00 PCSS Outgoing call routed to sip:444 at 172.16.100.198 for Call[1]-EP[Default] 2006/11/27 10:24:10.019 0:13.771 GMURLHandl...r:0843fa00 Call OnSetUp Call[1]-EP[Default] 2006/11/27 10:24:10.019 0:13.771 GMURLHandl...r:0843fa00 SIP SetUpConnection: 2006/11/27 10:24:10.020 0:13.772 GMURLHandl...r:0843fa00 OpalUDP Binding to interface: 172.16.100.166:32792 2006/11/27 10:24:10.020 0:13.772 GMURLHandl...r:0843fa00 SIP Created transport udp$0.0.0.0 2006/11/27 10:24:10.020 0:13.773 GMURLHandl...r:0843fa00 OpalUDP Started connect to 172.16.100.198:5060 2006/11/27 10:24:10.021 0:13.773 GMURLHandl...r:0843fa00 OpalUDP Connect on pre-bound interface: 172.16.100.166 2006/11/27 10:24:10.023 0:13.775 GMURLHandl...r:0843fa00 SIP Transaction 1 INVITE created. 2006/11/27 10:24:10.023 0:13.775 GMURLHandl...r:0843fa00 Call CanDoMediaBypass Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] session 1 2006/11/27 10:24:10.023 0:13.775 GMURLHandl...r:0843fa00 OpalMan IsMediaBypassPossible: session 1 2006/11/27 10:24:10.023 0:13.775 GMURLHandl...r:0843fa00 SIP IsMediaBypassPossible: session 1 2006/11/27 10:24:10.023 0:13.775 GMURLHandl...r:0843fa00 OpalCon IsMediaBypassPossible: default returns FALSE 2006/11/27 10:24:10.024 0:13.776 GMURLHandl...r:0843fa00 RTP_UDP RTP session created with NAT flag set to 0 2006/11/27 10:24:10.024 0:13.776 SIP Transp...rt:84677a8 SIP Read thread started. 2006/11/27 10:24:10.024 0:13.776 SIP Transp...rt:84677a8 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:24:10.024 0:13.776 GMURLHandl...r:0843fa00 RTP_UDP Session 1 created: 172.16.100.166:5000-5001 ssrc=37556996 2006/11/27 10:24:10.025 0:13.777 GMURLHandl...r:0843fa00 RTP Adding session RTP_UDP 2006/11/27 10:24:10.035 0:13.787 GMURLHandl...r:0843fa00 Call GetMediaFormats for Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] H.261 H.261-CIF H.261-QCIF GSM-06.10 G.711-uLaw-64k G.711-ALaw-64k iLBC-13k3 PCM-16 YUV420P RGB32 RGB24 2006/11/27 10:24:10.042 0:13.794 GMURLHandl...r:0843fa00 SIP Using RTP payload [pt=101] for NTE 2006/11/27 10:24:10.042 0:13.794 GMURLHandl...r:0843fa00 Call CanDoMediaBypass Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] session 2 2006/11/27 10:24:10.043 0:13.795 GMURLHandl...r:0843fa00 OpalMan IsMediaBypassPossible: session 2 2006/11/27 10:24:10.043 0:13.795 GMURLHandl...r:0843fa00 SIP IsMediaBypassPossible: session 2 2006/11/27 10:24:10.043 0:13.795 GMURLHandl...r:0843fa00 OpalCon IsMediaBypassPossible: default returns FALSE 2006/11/27 10:24:10.043 0:13.795 GMURLHandl...r:0843fa00 RTP_UDP RTP session created with NAT flag set to 0 2006/11/27 10:24:10.043 0:13.795 GMURLHandl...r:0843fa00 RTP_UDP Session 2 created: 172.16.100.166:5002-5003 ssrc=1969090190 2006/11/27 10:24:10.044 0:13.796 GMURLHandl...r:0843fa00 RTP Adding session RTP_UDP 2006/11/27 10:24:10.061 0:13.813 GMURLHandl...r:0843fa00 Call GetMediaFormats for Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] H.261 H.261-CIF H.261-QCIF GSM-06.10 G.711-uLaw-64k G.711-ALaw-64k iLBC-13k3 PCM-16 YUV420P RGB32 RGB24 2006/11/27 10:24:10.061 0:13.813 GMURLHandl...r:0843fa00 SIP Creating INVITE request 2006/11/27 10:24:10.062 0:13.814 GMURLHandl...r:0843fa00 SIP No authentication information present 2006/11/27 10:24:10.063 0:13.815 GMURLHandl...r:0843fa00 SIP Sending PDU on udp$172.16.100.198:5060 INVITE sip:444 at 172.16.100.198 SIP/2.0 Date: Mon, 27 Nov 2006 09:24:10 GMT CSeq: 1 INVITE Via: SIP/2.0/UDP 172.16.100.166:5062;branch=z9hG4bKc69ad9b4-667c-db11-8a96-00c09f2d8163;rport User-Agent: Ekiga/2.1.0 From: "Damien Sandras" ;tag=82b2d8b4-667c-db11-8a96-00c09f2d8163 Call-ID: e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01 To: Contact: Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE,INFO,PING,PUBLISH Content-Type: application/sdp Content-Length: 332 Max-Forwards: 70 v=0 o=- 1164619450 1164619450 IN IP4 172.16.100.166 s=Opal SIP Session c=IN IP4 172.16.100.166 t=0 0 m=audio 5000 RTP/AVP 3 0 8 107 101 a=rtpmap:3 gsm/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:107 iLBC/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 m=video 5002 RTP/AVP 31 a=rtpmap:31 h261/90000 2006/11/27 10:24:10.063 0:13.815 GMURLHandl...r:0843fa00 OpalCon OnSetUpConnectionCall[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:10.063 0:13.815 GMURLHandl...r:0843fa00 OpalEP OnSetUpConnection Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:10.063 0:13.815 GMURLHandl...r:0843fa00 SetUpCall succeeded, call=Call[1] 2006/11/27 10:24:10.065 0:13.817 SIP Transp...rt:84677a8 SIP PDU Received on udp$172.16.100.198:5060 SIP/2.0 407 Proxy Authentication Required CSeq: 1 INVITE Via: SIP/2.0/UDP 172.16.100.166:5062;branch=z9hG4bKc69ad9b4-667c-db11-8a96-00c09f2d8163;rport;received=172.16.100.166 User-Agent: Asterisk PBX From: "Damien Sandras" ;tag=82b2d8b4-667c-db11-8a96-00c09f2d8163 Call-ID: e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01 To: ;tag=as6959fcbc Contact: Proxy-Authenticate: Digest algorithm=MD5, realm="novacom", nonce="7667840a" Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 2006/11/27 10:24:10.065 0:13.817 SIP Transp...rt:84677a8 OpalUDP Ended connect, selecting 172.16.100.166:5062 2006/11/27 10:24:10.066 0:13.818 SIP Transp...rt:84677a8 SIP Queueing PDU: 1 INVITE <407> 2006/11/27 10:24:10.066 0:13.818 SIP Transp...rt:84677a8 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:24:10.066 0:13.818 SIP Handle...er:843fa00 SIP PDU handler thread started. 2006/11/27 10:24:10.066 0:13.818 SIP Handle...er:843fa00 SIP Awaiting next PDU. 2006/11/27 10:24:10.066 0:13.818 SIP Handle...er:843fa00 SIP Handling PDU 1 INVITE <407> 2006/11/27 10:24:10.067 0:13.819 SIP Handle...er:843fa00 SIP Transaction 1 INVITE completed. 2006/11/27 10:24:10.068 0:13.821 SIP Handle...er:843fa00 SIP Sending PDU on udp$172.16.100.198:5060 ACK sip:444 at 172.16.100.198 SIP/2.0 CSeq: 1 ACK Via: SIP/2.0/UDP 172.16.100.166:5062;branch=z9hG4bKc69ad9b4-667c-db11-8a96-00c09f2d8163;rport From: "Damien Sandras" ;tag=82b2d8b4-667c-db11-8a96-00c09f2d8163 Call-ID: e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01 To: ;tag=as6959fcbc Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE,INFO,PING,PUBLISH Content-Length: 0 Max-Forwards: 70 2006/11/27 10:24:10.069 0:13.821 SIP Handle...er:843fa00 SIP Received Proxy Authentication Required response 2006/11/27 10:24:10.070 0:13.822 SIP Handle...er:843fa00 SIP Transaction 2 INVITE created. 2006/11/27 10:24:10.070 0:13.822 SIP Handle...er:843fa00 Call CanDoMediaBypass Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] session 1 2006/11/27 10:24:10.070 0:13.822 SIP Handle...er:843fa00 OpalMan IsMediaBypassPossible: session 1 2006/11/27 10:24:10.070 0:13.822 SIP Handle...er:843fa00 SIP IsMediaBypassPossible: session 1 2006/11/27 10:24:10.070 0:13.822 SIP Handle...er:843fa00 OpalCon IsMediaBypassPossible: default returns FALSE 2006/11/27 10:24:10.071 0:13.823 SIP Handle...er:843fa00 RTP_UDP RTP session created with NAT flag set to 0 2006/11/27 10:24:10.071 0:13.823 SIP Handle...er:843fa00 RTP_UDP Session 1 created: 172.16.100.166:5004-5005 ssrc=1931258738 2006/11/27 10:24:10.071 0:13.823 SIP Handle...er:843fa00 RTP Adding session RTP_UDP 2006/11/27 10:24:10.081 0:13.833 SIP Handle...er:843fa00 Call GetMediaFormats for Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] H.261 H.261-CIF H.261-QCIF GSM-06.10 G.711-uLaw-64k G.711-ALaw-64k iLBC-13k3 PCM-16 YUV420P RGB32 RGB24 2006/11/27 10:24:10.082 0:13.834 SIP Handle...er:843fa00 SIP Using RTP payload [pt=101] for NTE 2006/11/27 10:24:10.082 0:13.834 SIP Handle...er:843fa00 Call CanDoMediaBypass Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] session 2 2006/11/27 10:24:10.082 0:13.834 SIP Handle...er:843fa00 OpalMan IsMediaBypassPossible: session 2 2006/11/27 10:24:10.082 0:13.834 SIP Handle...er:843fa00 SIP IsMediaBypassPossible: session 2 2006/11/27 10:24:10.083 0:13.835 SIP Handle...er:843fa00 OpalCon IsMediaBypassPossible: default returns FALSE 2006/11/27 10:24:10.083 0:13.835 SIP Handle...er:843fa00 RTP_UDP RTP session created with NAT flag set to 0 2006/11/27 10:24:10.083 0:13.835 SIP Handle...er:843fa00 RTP_UDP Session 2 created: 172.16.100.166:5006-5007 ssrc=65754113 2006/11/27 10:24:10.083 0:13.835 SIP Handle...er:843fa00 RTP Adding session RTP_UDP 2006/11/27 10:24:10.096 0:13.848 SIP Handle...er:843fa00 Call GetMediaFormats for Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] H.261 H.261-CIF H.261-QCIF GSM-06.10 G.711-uLaw-64k G.711-ALaw-64k iLBC-13k3 PCM-16 YUV420P RGB32 RGB24 2006/11/27 10:24:10.098 0:13.850 SIP Handle...er:843fa00 SIP Creating INVITE request 2006/11/27 10:24:10.099 0:13.851 SIP Handle...er:843fa00 SIP Adding authentication information 2006/11/27 10:24:10.100 0:13.852 SIP Handle...er:843fa00 SIP Sending PDU on udp$172.16.100.198:5060 INVITE sip:444 at 172.16.100.198 SIP/2.0 Date: Mon, 27 Nov 2006 09:24:10 GMT CSeq: 2 INVITE Via: SIP/2.0/UDP 172.16.100.166:5062;branch=z9hG4bK34d0e0b4-667c-db11-8a96-00c09f2d8163;rport User-Agent: Ekiga/2.1.0 From: "Damien Sandras" ;tag=82b2d8b4-667c-db11-8a96-00c09f2d8163 Call-ID: e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01 To: Contact: Proxy-Authorization: Digest username="9197", realm="novacom", nonce="7667840a", uri="sip:444 at 172.16.100.198", algorithm=md5, response="f0c88e73029e2ee264996aa51acfeb58" Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE,INFO,PING,PUBLISH Content-Type: application/sdp Content-Length: 332 Max-Forwards: 70 v=0 o=- 1164619450 1164619450 IN IP4 172.16.100.166 s=Opal SIP Session c=IN IP4 172.16.100.166 t=0 0 m=audio 5004 RTP/AVP 3 0 8 107 101 a=rtpmap:3 gsm/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:107 iLBC/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 m=video 5006 RTP/AVP 31 a=rtpmap:31 h261/90000 2006/11/27 10:24:10.101 0:13.853 SIP Handle...er:843fa00 SIP Awaiting next PDU. 2006/11/27 10:24:10.102 0:13.854 SIP Transp...rt:84677a8 SIP PDU Received on udp$172.16.100.198:5060 SIP/2.0 100 Trying CSeq: 2 INVITE Via: SIP/2.0/UDP 172.16.100.166:5062;branch=z9hG4bK34d0e0b4-667c-db11-8a96-00c09f2d8163;rport;received=172.16.100.166 User-Agent: Asterisk PBX From: "Damien Sandras" ;tag=82b2d8b4-667c-db11-8a96-00c09f2d8163 Call-ID: e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01 To: Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 2006/11/27 10:24:10.104 0:13.856 SIP Transp...rt:84677a8 SIP Queueing PDU: 2 INVITE <100> 2006/11/27 10:24:10.104 0:13.856 SIP Transp...rt:84677a8 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:24:10.105 0:13.857 SIP Transp...rt:84677a8 SDP Media session port=19144 2006/11/27 10:24:10.105 0:13.857 SIP Transp...rt:84677a8 SDP Adding media session with 2 formats 2006/11/27 10:24:10.106 0:13.858 SIP Transp...rt:84677a8 SDP Media attribute silenceSupp found for unknown RTP type PCMU 2006/11/27 10:24:10.106 0:13.858 SIP Transp...rt:84677a8 SIP PDU Received on udp$172.16.100.198:5060 SIP/2.0 200 OK CSeq: 2 INVITE Via: SIP/2.0/UDP 172.16.100.166:5062;branch=z9hG4bK34d0e0b4-667c-db11-8a96-00c09f2d8163;rport;received=172.16.100.166 User-Agent: Asterisk PBX From: "Damien Sandras" ;tag=82b2d8b4-667c-db11-8a96-00c09f2d8163 Call-ID: e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01 To: ;tag=as3d2c9853 Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Type: application/sdp Content-Length: 218 v=0 o=root 5150 5150 IN IP4 172.16.100.198 s=session c=IN IP4 172.16.100.198 t=0 0 m=audio 19144 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - 2006/11/27 10:24:10.107 0:13.859 SIP Transp...rt:84677a8 SIP Queueing PDU: 2 INVITE <200> 2006/11/27 10:24:10.107 0:13.859 SIP Transp...rt:84677a8 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:24:10.107 0:13.859 SIP Handle...er:843fa00 SIP Handling PDU 2 INVITE <100> 2006/11/27 10:24:10.107 0:13.859 SIP Handle...er:843fa00 SIP Transaction 2 INVITE proceeding. 2006/11/27 10:24:10.108 0:13.860 SIP Handle...er:843fa00 SIP Set targetAddress to sip:444 at 172.16.100.198 2006/11/27 10:24:10.108 0:13.860 SIP Handle...er:843fa00 SIP Received Trying response 2006/11/27 10:24:10.108 0:13.860 SIP Handle...er:843fa00 SIP Awaiting next PDU. 2006/11/27 10:24:10.108 0:13.860 SIP Handle...er:843fa00 SIP Handling PDU 2 INVITE <200> 2006/11/27 10:24:10.109 0:13.861 SIP Handle...er:843fa00 SIP Transaction 2 INVITE completed. 2006/11/27 10:24:10.109 0:13.861 SIP Handle...er:843fa00 SIP Set targetAddress to sip:444 at 172.16.100.198 2006/11/27 10:24:10.110 0:13.862 SIP Handle...er:843fa00 SIP Adding authentication information 2006/11/27 10:24:10.110 0:13.862 SIP Handle...er:843fa00 SIP Sending PDU on udp$172.16.100.198:5060 ACK sip:444 at 172.16.100.198 SIP/2.0 CSeq: 2 ACK Via: SIP/2.0/UDP 172.16.100.166:5062;branch=z9hG4bK1eefe6b4-667c-db11-8a96-00c09f2d8163;rport From: "Damien Sandras" ;tag=82b2d8b4-667c-db11-8a96-00c09f2d8163 Call-ID: e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01 To: ;tag=as3d2c9853 Contact: Proxy-Authorization: Digest username="9197", realm="novacom", nonce="7667840a", uri="sip:444 at 172.16.100.198", algorithm=md5, response="82ebe1ee326fe5e5c349e7f2569809a4" Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE,INFO,PING,PUBLISH Content-Length: 0 Max-Forwards: 70 2006/11/27 10:24:10.111 0:13.863 SIP Handle...er:843fa00 SIP Received INVITE OK response 2006/11/27 10:24:10.111 0:13.863 SIP Handle...er:843fa00 Call GetOtherPartyConnection Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:10.111 0:13.863 SIP Handle...er:843fa00 Call CanDoMediaBypass Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] session 1 2006/11/27 10:24:10.111 0:13.863 SIP Handle...er:843fa00 OpalMan IsMediaBypassPossible: session 1 2006/11/27 10:24:10.111 0:13.863 SIP Handle...er:843fa00 SIP IsMediaBypassPossible: session 1 2006/11/27 10:24:10.111 0:13.863 SIP Handle...er:843fa00 OpalCon IsMediaBypassPossible: default returns FALSE 2006/11/27 10:24:10.111 0:13.864 SIP Handle...er:843fa00 RTP Found existing session 1 2006/11/27 10:24:10.112 0:13.864 SIP Handle...er:843fa00 SIP RTP payload type PCMA matched to codec G.711-ALaw-64k 2006/11/27 10:24:10.113 0:13.865 SIP Handle...er:843fa00 Call OpenSourceMediaStreams for session 1 with media G.711-ALaw-64k 2006/11/27 10:24:10.114 0:13.866 SIP Handle...er:843fa00 OpalCon OpenSourceMediaStream for session 1 on Call[1]-EP[Default] 2006/11/27 10:24:10.115 0:13.867 SIP Handle...er:843fa00 OpalCon Selected media stream PCM-16 -> G.711-ALaw-64k 2006/11/27 10:24:11.192 0:14.944 Housekeeper SIP Set state Terminated_Success for transaction 2 INVITE 2006/11/27 10:24:11.198 0:14.950 SIP Handle...er:843fa00 OpalMan OnOpenMediaStream Call[1]-EP[Default],OpalAudioMediaStream-Source-PCM-16 2006/11/27 10:24:11.199 0:14.951 SIP Handle...er:843fa00 Call PatchMediaStreams Call[1]-EP[Default] 2006/11/27 10:24:11.199 0:14.951 SIP Handle...er:843fa00 OpalCon OpenSinkMediaStream Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] session=1 2006/11/27 10:24:11.200 0:14.952 SIP Handle...er:843fa00 OpalCon OpenSinkMediaStream, selected PCM-16 -> G.711-ALaw-64k 2006/11/27 10:24:11.200 0:14.952 SIP Handle...er:843fa00 Call CanDoMediaBypass Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] session 1 2006/11/27 10:24:11.200 0:14.952 SIP Handle...er:843fa00 OpalMan IsMediaBypassPossible: session 1 2006/11/27 10:24:11.201 0:14.953 SIP Handle...er:843fa00 SIP IsMediaBypassPossible: session 1 2006/11/27 10:24:11.201 0:14.953 SIP Handle...er:843fa00 OpalCon IsMediaBypassPossible: default returns FALSE 2006/11/27 10:24:11.201 0:14.953 SIP Handle...er:843fa00 RTP Found existing session 1 2006/11/27 10:24:11.201 0:14.953 SIP Handle...er:843fa00 RTP Found existing session 1 2006/11/27 10:24:11.202 0:14.954 SIP Handle...er:843fa00 OpalMan OnOpenMediaStream Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01],OpalRTPMediaStream-Sink-G.711-ALaw-64k 2006/11/27 10:24:11.206 0:14.958 SIP Handle...er:843fa00 Patch Added sink from PCM-16 Clock Rate = 8000 Frame Time = 8 Max Bit Rate = 64000 Max Frame Size = 16 Needs Jitter = 1 Rx Frames Per Packet = 240 Tx Frames Per Packet = 30 to G.711-ALaw-64k Clock Rate = 8000 Frame Time = 8 Max Bit Rate = 64000 Max Frame Size = 8 Needs Jitter = 1 Rx Frames Per Packet = 240 Tx Frames Per Packet = 30 2006/11/27 10:24:11.207 0:14.959 SIP Handle...er:843fa00 Codec G711-ALaw-64k encoder created 2006/11/27 10:24:11.208 0:14.960 SIP Handle...er:843fa00 Patch Added media stream sink OpalRTPMediaStream-Sink-G.711-ALaw-64k using transcoder PCM-16->G.711-ALaw-64k 2006/11/27 10:24:11.208 0:14.960 SIP Handle...er:843fa00 Media Audio source data size set to 320 bytes and 4 buffers. 2006/11/27 10:24:11.209 0:14.961 SIP Handle...er:843fa00 OpalCon New patch created 2006/11/27 10:24:11.209 0:14.961 SIP Handle...er:843fa00 OpalCon New patch created 2006/11/27 10:24:11.209 0:14.961 SIP Handle...er:843fa00 OpalCOn Adding RFC2833 transmit handler 2006/11/27 10:24:11.210 0:14.962 SIP Handle...er:843fa00 Call OpenSourceMediaStreams for session 1 adjusted media to G.711-ALaw-64k 2006/11/27 10:24:11.210 0:14.962 SIP Handle...er:843fa00 Call GetOtherPartyConnection Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:11.211 0:14.963 SIP Handle...er:843fa00 OpalCon OpenSourceMediaStream for session 1 on Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:11.212 0:14.964 SIP Handle...er:843fa00 OpalCon Selected media stream G.711-ALaw-64k -> PCM-16 2006/11/27 10:24:11.212 0:14.964 SIP Handle...er:843fa00 Call CanDoMediaBypass Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] session 1 2006/11/27 10:24:11.212 0:14.964 SIP Handle...er:843fa00 OpalMan IsMediaBypassPossible: session 1 2006/11/27 10:24:11.212 0:14.965 SIP Handle...er:843fa00 SIP IsMediaBypassPossible: session 1 2006/11/27 10:24:11.213 0:14.965 SIP Handle...er:843fa00 OpalCon IsMediaBypassPossible: default returns FALSE 2006/11/27 10:24:11.213 0:14.965 SIP Handle...er:843fa00 RTP Found existing session 1 2006/11/27 10:24:11.213 0:14.965 SIP Handle...er:843fa00 RTP Found existing session 1 2006/11/27 10:24:11.213 0:14.965 SIP Handle...er:843fa00 OpalMan OnOpenMediaStream Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01],OpalRTPMediaStream-Source-G.711-ALaw-64k 2006/11/27 10:24:11.213 0:14.965 SIP Handle...er:843fa00 Call PatchMediaStreams Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:11.213 0:14.965 SIP Handle...er:843fa00 OpalCon OpenSinkMediaStream Call[1]-EP[Default] session=1 2006/11/27 10:24:11.214 0:14.966 SIP Handle...er:843fa00 OpalCon OpenSinkMediaStream, selected G.711-ALaw-64k -> PCM-16 2006/11/27 10:24:11.217 0:14.969 SIP Handle...er:843fa00 OpalMan OnOpenMediaStream Call[1]-EP[Default],OpalAudioMediaStream-Sink-PCM-16 2006/11/27 10:24:11.218 0:14.970 SIP Handle...er:843fa00 Patch Added sink from G.711-ALaw-64k Clock Rate = 8000 Frame Time = 8 Max Bit Rate = 64000 Max Frame Size = 8 Needs Jitter = 1 Rx Frames Per Packet = 240 Tx Frames Per Packet = 30 to PCM-16 Clock Rate = 8000 Frame Time = 8 Max Bit Rate = 128000 Max Frame Size = 16 Needs Jitter = 1 Rx Frames Per Packet = 240 Tx Frames Per Packet = 30 2006/11/27 10:24:11.219 0:14.971 SIP Handle...er:843fa00 Codec G711-ALaw-64k decoder created 2006/11/27 10:24:11.219 0:14.971 SIP Handle...er:843fa00 Media Audio sink data size set to 320 bytes and 4 buffers. 2006/11/27 10:24:11.219 0:14.972 SIP Handle...er:843fa00 Patch Added media stream sink OpalAudioMediaStream-Sink-PCM-16 using transcoder G.711-ALaw-64k->PCM-16 2006/11/27 10:24:11.220 0:14.972 SIP Handle...er:843fa00 OpalCon New patch created 2006/11/27 10:24:11.220 0:14.972 SIP Handle...er:843fa00 OpalCon New patch created 2006/11/27 10:24:11.220 0:14.972 SIP Handle...er:843fa00 OpalCon Adding RFC2833 receive handler 2006/11/27 10:24:11.223 0:14.975 SIP Handle...er:843fa00 OpalCon OpenSourceMediaStream (already opened) for session 1 on Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:11.224 0:14.976 SIP Handle...er:843fa00 RTP_UDP SetRemoteSocketInfo: session=1 data channel, new=172.16.100.198:19144, local=172.16.100.166:5004-5005, remote=0.0.0.0:0-0 2006/11/27 10:24:11.224 0:14.976 SIP Handle...er:843fa00 SIP Could not find SDP media description for Video 2006/11/27 10:24:11.225 0:14.977 SIP Handle...er:843fa00 SIP Could not find SDP media description for Image 2006/11/27 10:24:11.225 0:14.977 SIP Handle...er:843fa00 OpalMan OnConnected Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:11.225 0:14.978 SIP Handle...er:843fa00 Call OnConnected Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:11.226 0:14.978 SIP Handle...er:843fa00 PCSS SetConnected() 2006/11/27 10:24:11.226 0:14.978 SIP Handle...er:843fa00 GMPCSSEndpoint PCSS connection established 2006/11/27 10:24:11.226 0:14.978 SIP Handle...er:843fa00 GMManager Will establish the connection 2006/11/27 10:24:11.226 0:14.978 SIP Handle...er:843fa00 OpalMan OnEstablished Call[1]-EP[Default] 2006/11/27 10:24:11.227 0:14.979 SIP Handle...er:843fa00 Call OnEstablished Call[1]-EP[Default] 2006/11/27 10:24:11.238 0:14.990 SIP Handle...er:843fa00 Call GetMediaFormats for Call[1]-EP[Default] G.711-ALaw-64k PCM-16 2006/11/27 10:24:11.238 0:14.990 SIP Handle...er:843fa00 Call OpenSourceMediaStreams for session 1 with media G.711-ALaw-64k,PCM-16 2006/11/27 10:24:11.238 0:14.990 SIP Handle...er:843fa00 OpalCon OpenSourceMediaStream (already opened) for session 1 on Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:11.239 0:14.991 SIP Handle...er:843fa00 Call OpenSourceMediaStreams for session 2 with media G.711-ALaw-64k,PCM-16 2006/11/27 10:24:11.239 0:14.991 SIP Handle...er:843fa00 Call OpenSourceMediaStreams for session 3 with media G.711-ALaw-64k,PCM-16 2006/11/27 10:24:11.250 0:15.002 SIP Handle...er:843fa00 Call GetMediaFormats for Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] G.711-ALaw-64k PCM-16 2006/11/27 10:24:11.251 0:15.003 SIP Handle...er:843fa00 Call OpenSourceMediaStreams for session 1 with media G.711-ALaw-64k,PCM-16 2006/11/27 10:24:11.251 0:15.003 SIP Handle...er:843fa00 OpalCon OpenSourceMediaStream (already opened) for session 1 on Call[1]-EP[Default] 2006/11/27 10:24:11.251 0:15.003 SIP Handle...er:843fa00 Call OpenSourceMediaStreams for session 1 adjusted media to PCM-16,G.711-ALaw-64k 2006/11/27 10:24:11.251 0:15.003 SIP Handle...er:843fa00 Call OpenSourceMediaStreams for session 2 with media G.711-ALaw-64k,PCM-16 2006/11/27 10:24:11.251 0:15.003 SIP Handle...er:843fa00 Call OpenSourceMediaStreams for session 3 with media G.711-ALaw-64k,PCM-16 2006/11/27 10:24:11.251 0:15.003 Media Patc...ch:8470550 Patch Thread started for Patch OpalAudioMediaStream-Source-PCM-16 -> OpalRTPMediaStream-Sink-G.711-ALaw-64k 2006/11/27 10:24:11.252 0:15.005 SIP Handle...er:843fa00 Media Starting thread Media Patch:8470550 2006/11/27 10:24:11.253 0:15.005 Media Patc...h:b5e38f18 Patch Thread started for Patch OpalRTPMediaStream-Source-G.711-ALaw-64k -> OpalAudioMediaStream-Sink-PCM-16 2006/11/27 10:24:11.253 0:15.005 Media Patc...h:b5e38f18 RTP Jitter buffer created: size=101 delay=160-4000/160 (20ms) obj=0x840c988 2006/11/27 10:24:11.255 0:15.007 RTP Jitter...er:84b0eb8 RTP Jitter RTP receive thread started: 0x840c988 2006/11/27 10:24:11.256 0:15.008 RTP Jitter...er:84b0eb8 RTP First receive data: ver=2 pt=PCMA psz=160 m=0 x=0 seq=40148 ts=160 src=803175037 ccnt=0 2006/11/27 10:24:11.256 0:15.008 SIP Handle...er:843fa00 Media Starting thread Media Patch:b5e38f18 2006/11/27 10:24:11.256 0:15.008 SIP Handle...er:843fa00 OpalCon Media stream threads started. 2006/11/27 10:24:11.257 0:15.009 SIP Handle...er:843fa00 OpalCon Media stream threads started. 2006/11/27 10:24:11.257 0:15.009 SIP Handle...er:843fa00 OpalCon SetPhase from UninitialisedPhase to EstablishedPhase 2006/11/27 10:24:11.257 0:15.009 SIP Handle...er:843fa00 GMSIPEndpoint SIP connection established 2006/11/27 10:24:11.260 0:15.012 SIP Handle...er:843fa00 RTP Found existing session 1 2006/11/27 10:24:11.260 0:15.012 SIP Handle...er:843fa00 RTP Found existing session 2 2006/11/27 10:24:11.260 0:15.013 SIP Handle...er:843fa00 GMManager Will establish the connection 2006/11/27 10:24:11.261 0:15.013 SIP Handle...er:843fa00 OpalMan OnEstablished Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:11.261 0:15.013 SIP Handle...er:843fa00 Call OnEstablished Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:11.274 0:15.026 SIP Handle...er:843fa00 SIP Awaiting next PDU. 2006/11/27 10:24:11.276 0:15.028 Media Patc...h:b5e38f18 RTP Jitter buffer length exceeded 2006/11/27 10:24:11.276 0:15.028 Media Patc...h:b5e38f18 RTP Jitter buffer length exceed was prior to first write. Not increasing buffer size 2006/11/27 10:24:11.279 0:15.031 Media Patc...ch:8470550 RTP First sent data: ver=2 pt=PCMA psz=160 m=1 x=0 seq=39800 ts=0 src=1931258738 ccnt=0 2006/11/27 10:24:12.139 0:15.891 RTP Jitter...er:84b0eb8 RTP Receive statistics: packets=102 octets=16320 lost=0 tooLate=0 order=0 avgTime=8 maxTime=22 minTime=0 jitter=0 maxJitter=2 2006/11/27 10:24:12.272 0:16.024 Housekeeper RTP Found existing session 1 2006/11/27 10:24:12.272 0:16.024 Housekeeper RTP Found existing session 2 2006/11/27 10:24:13.280 0:17.032 Housekeeper RTP Found existing session 1 2006/11/27 10:24:13.280 0:17.033 Housekeeper RTP Found existing session 2 2006/11/27 10:24:13.282 0:17.034 Media Patc...ch:8470550 RTP Transmit statistics: packets=101 octets=16160 avgTime=20 maxTime=28 minTime=15 2006/11/27 10:24:14.152 0:17.904 RTP Jitter...er:84b0eb8 RTP Receive statistics: packets=202 octets=32320 lost=0 tooLate=0 order=0 avgTime=20 maxTime=25 minTime=15 jitter=1 maxJitter=2 2006/11/27 10:24:14.302 0:18.054 Housekeeper RTP Found existing session 1 2006/11/27 10:24:14.302 0:18.054 Housekeeper RTP Found existing session 2 2006/11/27 10:24:15.297 0:19.050 Housekeeper RTP Found existing session 1 2006/11/27 10:24:15.298 0:19.050 Housekeeper RTP Found existing session 2 2006/11/27 10:24:15.365 0:19.117 Media Patc...ch:8470550 RTP Transmit statistics: packets=201 octets=32160 avgTime=20 maxTime=25 minTime=15 2006/11/27 10:24:15.935 0:19.687 ekiga Call Clearing Call[1] reason=EndedByLocalUser 2006/11/27 10:24:15.935 0:19.687 ekiga OpalCon SetPhase from EstablishedPhase to ReleasingPhase 2006/11/27 10:24:15.935 0:19.687 ekiga OpalCon Releasing Call[1]-EP[Default] 2006/11/27 10:24:15.935 0:19.687 ekiga OpalCon Call end reason for Default set to EndedByLocalUser 2006/11/27 10:24:15.936 0:19.688 ekiga OpalCon SetPhase from EstablishedPhase to ReleasingPhase 2006/11/27 10:24:15.936 0:19.688 ekiga OpalCon Releasing Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:15.936 0:19.688 ekiga OpalCon Call end reason for e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01 set to EndedByLocalUser 2006/11/27 10:24:15.936 0:19.688 OnRelease:...se:84fcbb8 SIP OnReleased: Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01], phase = ReleasingPhase 2006/11/27 10:24:15.936 0:19.689 OnRelease:...se:84fcbb8 OpalCon SetPhase from ReleasingPhase to ReleasingPhase 2006/11/27 10:24:15.938 0:19.691 OnRelease:...se:84fcbb8 SIP Transaction 4 BYE created. 2006/11/27 10:24:15.940 0:19.692 OnRelease:...se:84fcbb8 Media Closing RTP for OpalRTPMediaStream-Sink-G.711-ALaw-64k 2006/11/27 10:24:15.941 0:19.693 OnRelease:...se:84fcbb8 RTP_UDP Session 1, Shutting down write. 2006/11/27 10:24:15.941 0:19.693 OnRelease:...se:84fcbb8 Media Closing stream OpalRTPMediaStream-Sink-G.711-ALaw-64k 2006/11/27 10:24:15.941 0:19.693 OnRelease:...se:84fcbb8 Media Disconnecting OpalRTPMediaStream-Sink-G.711-ALaw-64k from patch thread Patch OpalAudioMediaStream-Source-PCM-16 -> OpalRTPMediaStream-Sink-G.711-ALaw-64k 2006/11/27 10:24:15.941 0:19.693 OnRelease:...se:84fcbb8 Patch Removing media stream sink OpalRTPMediaStream-Sink-G.711-ALaw-64k 2006/11/27 10:24:15.942 0:19.694 OnRelease:...se:84b20e0 OpalCon OnReleased Call[1]-EP[Default] 2006/11/27 10:24:15.943 0:19.695 OnRelease:...se:84b20e0 Media Closing raw media stream OpalAudioMediaStream-Source-PCM-16 2006/11/27 10:24:15.943 0:19.695 OnRelease:...se:84b20e0 Media Closing stream OpalAudioMediaStream-Source-PCM-16 2006/11/27 10:24:15.943 0:19.695 OnRelease:...se:84b20e0 Media Disconnecting OpalAudioMediaStream-Source-PCM-16 from patch thread Patch OpalAudioMediaStream-Source-PCM-16 2006/11/27 10:24:15.943 0:19.695 OnRelease:...se:84b20e0 Patch Closing media patch Patch OpalAudioMediaStream-Source-PCM-16 2006/11/27 10:24:15.943 0:19.695 OnRelease:...se:84b20e0 Media Closing raw media stream OpalAudioMediaStream-Source-PCM-16 2006/11/27 10:24:15.944 0:19.696 OnRelease:...se:84b20e0 Patch Waiting for media patch thread to stop Patch OpalAudioMediaStream-Source-PCM-16 2006/11/27 10:24:15.945 0:19.697 OnRelease:...se:84fcbb8 Media Closing RTP for OpalRTPMediaStream-Source-G.711-ALaw-64k 2006/11/27 10:24:15.945 0:19.697 OnRelease:...se:84fcbb8 RTP_UDP Session 1, Shutting down read. 2006/11/27 10:24:15.945 0:19.697 OnRelease:...se:84fcbb8 Media Closing stream OpalRTPMediaStream-Source-G.711-ALaw-64k 2006/11/27 10:24:15.946 0:19.698 OnRelease:...se:84fcbb8 Media Disconnecting OpalRTPMediaStream-Source-G.711-ALaw-64k from patch thread Patch OpalRTPMediaStream-Source-G.711-ALaw-64k -> OpalAudioMediaStream-Sink-PCM-16 2006/11/27 10:24:15.949 0:19.702 OnRelease:...se:84fcbb8 Patch Closing media patch Patch OpalRTPMediaStream-Source-G.711-ALaw-64k -> OpalAudioMediaStream-Sink-PCM-16 2006/11/27 10:24:15.950 0:19.702 Media Patc...ch:8470550 Patch Thread ended for Patch OpalAudioMediaStream-Source-PCM-16 2006/11/27 10:24:15.950 0:19.702 RTP Jitter...er:84b0eb8 RTP_UDP Session 1, Read shutdown. 2006/11/27 10:24:15.950 0:19.702 OnRelease:...se:84fcbb8 Media Closing RTP for OpalRTPMediaStream-Source-G.711-ALaw-64k 2006/11/27 10:24:15.950 0:19.702 OnRelease:...se:84fcbb8 RTP_UDP Session 1, Shutting down read. 2006/11/27 10:24:15.950 0:19.702 RTP Jitter...er:84b0eb8 RTP Jitter RTP receive thread ended 2006/11/27 10:24:15.950 0:19.702 OnRelease:...se:84fcbb8 Patch Removing media stream sink OpalAudioMediaStream-Sink-PCM-16 2006/11/27 10:24:15.950 0:19.702 RTP Jitter...er:84b0eb8 RTP Jitter RTP receive thread finished: 0x840c988 2006/11/27 10:24:15.951 0:19.703 OnRelease:...se:84fcbb8 Patch Waiting for media patch thread to stop Patch OpalRTPMediaStream-Source-G.711-ALaw-64k 2006/11/27 10:24:15.956 0:19.708 Media Patc...h:b5e38f18 Patch Thread ended for Patch OpalRTPMediaStream-Source-G.711-ALaw-64k 2006/11/27 10:24:15.956 0:19.708 OnRelease:...se:84b20e0 Patch Media patch thread Patch OpalAudioMediaStream-Source-PCM-16 destroyed. 2006/11/27 10:24:15.957 0:19.709 OnRelease:...se:84b20e0 Media Closing raw media stream OpalAudioMediaStream-Sink-PCM-16 2006/11/27 10:24:15.957 0:19.709 OnRelease:...se:84b20e0 Media Closing stream OpalAudioMediaStream-Sink-PCM-16 2006/11/27 10:24:15.957 0:19.709 OnRelease:...se:84b20e0 OpalCon Media stream threads closed. 2006/11/27 10:24:15.958 0:19.710 OnRelease:...se:84b20e0 GMPCSSEndpoint PCSS connection released 2006/11/27 10:24:15.958 0:19.710 OnRelease:...se:84b20e0 OpalEP OnReleased Call[1]-EP[Default] 2006/11/27 10:24:15.958 0:19.710 OnRelease:...se:84b20e0 GMManager Will release the connection 2006/11/27 10:24:15.959 0:19.711 OnRelease:...se:84b20e0 OpalMan OnReleased Call[1]-EP[Default] 2006/11/27 10:24:15.959 0:19.711 OnRelease:...se:84b20e0 Call OnReleased Call[1]-EP[Default] 2006/11/27 10:24:15.959 0:19.711 OnRelease:...se:84b20e0 OpalCon Already released Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:15.959 0:19.711 OnRelease:...se:84b20e0 OpalCon OnRelease thread completed for Default 2006/11/27 10:24:15.964 0:19.716 OnRelease:...se:84fcbb8 Patch Media patch thread Patch OpalRTPMediaStream-Source-G.711-ALaw-64k destroyed. 2006/11/27 10:24:15.964 0:19.716 OnRelease:...se:84fcbb8 OpalCon Media stream threads closed. 2006/11/27 10:24:15.965 0:19.717 OnRelease:...se:84fcbb8 SIP Adding authentication information 2006/11/27 10:24:15.965 0:19.717 OnRelease:...se:84fcbb8 SIP Sending PDU on udp$172.16.100.198:5060 BYE sip:444 at 172.16.100.198 SIP/2.0 CSeq: 4 BYE Via: SIP/2.0/UDP 172.16.100.166:5062;branch=z9hG4bK843960b8-667c-db11-8a96-00c09f2d8163;rport From: "Damien Sandras" ;tag=82b2d8b4-667c-db11-8a96-00c09f2d8163 Call-ID: e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01 To: ;tag=as3d2c9853 Contact: Proxy-Authorization: Digest username="9197", realm="novacom", nonce="7667840a", uri="sip:444 at 172.16.100.198", algorithm=md5, response="9e726640173d81fb90121f519715cecc" Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE,INFO,PING,PUBLISH Content-Length: 0 Max-Forwards: 70 2006/11/27 10:24:15.967 0:19.719 SIP Transp...rt:84677a8 SIP PDU Received on udp$172.16.100.198:5060 SIP/2.0 200 OK CSeq: 4 BYE Via: SIP/2.0/UDP 172.16.100.166:5062;branch=z9hG4bK843960b8-667c-db11-8a96-00c09f2d8163;received=172.16.100.166;rport=5062 User-Agent: Asterisk PBX From: "Damien Sandras" ;tag=82b2d8b4-667c-db11-8a96-00c09f2d8163 Call-ID: e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01 To: ;tag=as3d2c9853 Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 2006/11/27 10:24:15.967 0:19.719 SIP Transp...rt:84677a8 SIP Queueing PDU: 4 BYE <200> 2006/11/27 10:24:15.968 0:19.720 SIP Transp...rt:84677a8 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:24:15.968 0:19.720 SIP Handle...er:843fa00 SIP Handling PDU 4 BYE <200> 2006/11/27 10:24:15.968 0:19.720 SIP Handle...er:843fa00 SIP Transaction 4 BYE completed. 2006/11/27 10:24:15.969 0:19.721 SIP Handle...er:843fa00 SIP Received OK response for non INVITE 2006/11/27 10:24:15.969 0:19.721 OnRelease:...se:84fcbb8 SIP Transaction 4 BYE aborted. 2006/11/27 10:24:15.969 0:19.721 SIP Handle...er:843fa00 SIP Awaiting next PDU. 2006/11/27 10:24:15.969 0:19.721 OnRelease:...se:84fcbb8 SIP Transaction 4 BYE destroyed. 2006/11/27 10:24:15.969 0:19.721 OnRelease:...se:84fcbb8 OpalCon SetPhase from ReleasingPhase to ReleasedPhase 2006/11/27 10:24:15.970 0:19.722 SIP Handle...er:843fa00 SIP PDU handler thread finished. 2006/11/27 10:24:15.981 0:19.733 OnRelease:...se:84fcbb8 Opal Transport clean up on termination 2006/11/27 10:24:15.981 0:19.733 OnRelease:...se:84fcbb8 OpalUDP Close 2006/11/27 10:24:15.981 0:19.733 OnRelease:...se:84fcbb8 Opal Transport Close 2006/11/27 10:24:15.982 0:19.734 SIP Transp...rt:84677a8 SIP Read thread finished. 2006/11/27 10:24:15.992 0:19.744 OnRelease:...se:84fcbb8 OpalCon OnReleased Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:15.993 0:19.745 OnRelease:...se:84fcbb8 OpalCon Media stream threads closed. 2006/11/27 10:24:15.993 0:19.745 OnRelease:...se:84fcbb8 GMSIPEndpoint SIP connection released 2006/11/27 10:24:15.993 0:19.745 OnRelease:...se:84fcbb8 OpalEP OnReleased Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:16.028 0:19.780 OnRelease:...se:84fcbb8 GMManager Will release the connection 2006/11/27 10:24:16.029 0:19.781 OnRelease:...se:84fcbb8 OpalMan OnReleased Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:16.029 0:19.781 OnRelease:...se:84fcbb8 Call OnReleased Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:16.572 0:20.456 OpalGarbage PCSS Deleted PC sound system connection. 2006/11/27 10:24:16.705 0:20.457 OpalGarbage OpalCon Connection Call[1]-EP[Default] destroyed. 2006/11/27 10:24:18.112 0:21.865 ekiga Call Clearing Call[1] reason=EndedByLocalUser 2006/11/27 10:24:19.279 0:23.031 OnRelease:...se:84fcbb8 RTP_UDP Session 1, Shutting down read. 2006/11/27 10:24:19.279 0:23.031 OnRelease:...se:84fcbb8 RTP_UDP Session 1, Shutting down write. 2006/11/27 10:24:19.279 0:23.031 OnRelease:...se:84fcbb8 RTP_UDP Session 2, Shutting down read. 2006/11/27 10:24:19.279 0:23.032 OnRelease:...se:84fcbb8 RTP_UDP Session 2, Shutting down write. 2006/11/27 10:24:19.280 0:23.032 OnRelease:...se:84fcbb8 SIP Transaction 1 INVITE aborted. 2006/11/27 10:24:19.280 0:23.032 OnRelease:...se:84fcbb8 SIP Transaction 1 INVITE destroyed. 2006/11/27 10:24:19.280 0:23.032 OnRelease:...se:84fcbb8 SIP Transaction 2 INVITE destroyed. 2006/11/27 10:24:19.280 0:23.032 OnRelease:...se:84fcbb8 OpalCon OnRelease thread completed for e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01 2006/11/27 10:24:19.717 0:23.469 OpalGarbage Opal Transport clean up on termination 2006/11/27 10:24:19.717 0:23.469 OpalGarbage OpalUDP Close 2006/11/27 10:24:19.717 0:23.469 OpalGarbage Opal Transport Close 2006/11/27 10:24:19.717 0:23.469 OpalGarbage Opal Deleted transport udp$172.16.100.198:5060 2006/11/27 10:24:19.717 0:23.469 OpalGarbage SIP Deleted connection. 2006/11/27 10:24:19.718 0:23.470 OpalGarbage OpalCon Connection Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] destroyed. 2006/11/27 10:24:19.718 0:23.470 OpalGarbage RTP_UDP Session 1, Shutting down write. 2006/11/27 10:24:19.718 0:23.470 OpalGarbage RTP Final statistics: packetsSent = 229 octetsSent = 36640 averageSendTime = 20 maximumSendTime = 25 minimumSendTime = 15 packetsReceived = 287 octetsReceived = 45920 packetsLost = 0 packetsTooLate = 0 packetsOutOfOrder = 0 averageReceiveTime= 20 maximumReceiveTime= 25 minimumReceiveTime= 15 averageJitter = 0 maximumJitter = 3 2006/11/27 10:24:19.718 0:23.470 OpalGarbage RTP Removing jitter buffer 0x840c988 RTP Jitter:84b0eb8 2006/11/27 10:24:19.718 0:23.471 OpalGarbage RTP_UDP Session 2, Shutting down read. 2006/11/27 10:24:19.719 0:23.471 OpalGarbage RTP_UDP Session 2, Shutting down write. 2006/11/27 10:24:20.725 0:24.477 OpalGarbage Call Call[1] destroyed. 2006/11/27 10:24:22.733 0:26.485 ekiga Listen Stopping listening thread on udp$172.16.100.166:1720 2006/11/27 10:24:22.733 0:26.485 Opal Liste...er:83f93c8 Listen UDP select error: Appel syst?me interrompu 2006/11/27 10:24:22.745 0:26.497 ekiga H323 Deleted endpoint. 2006/11/27 10:24:22.745 0:26.497 ekiga OpalEP h323 endpoint destroyed. 2006/11/27 10:24:22.748 0:26.500 ekiga SIP Sending PDU on udp$172.16.100.198:5060 REGISTER sip:172.16.100.198 SIP/2.0 CSeq: 4 REGISTER Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bK0a326fbc-667c-db11-8a96-00c09f2d8163;rport User-Agent: Ekiga/2.1.0 From: ;tag=d2286fbc-667c-db11-8a96-00c09f2d8163 Call-ID: f49337ad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: Contact: Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE,INFO,PING,PUBLISH Expires: 0 Content-Length: 0 Max-Forwards: 70 2006/11/27 10:24:22.749 0:26.501 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 SIP/2.0 100 Trying CSeq: 4 REGISTER Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bK0a326fbc-667c-db11-8a96-00c09f2d8163;rport;received=172.16.100.166 User-Agent: Asterisk PBX From: ;tag=d2286fbc-667c-db11-8a96-00c09f2d8163 Call-ID: f49337ad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 2006/11/27 10:24:22.750 0:26.502 SIP Transp...t:b5e2cb40 SIP Transaction 4 REGISTER proceeding. 2006/11/27 10:24:22.750 0:26.502 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:24:22.751 0:26.503 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 SIP/2.0 401 Unauthorized CSeq: 4 REGISTER Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bK0a326fbc-667c-db11-8a96-00c09f2d8163;rport;received=172.16.100.166 User-Agent: Asterisk PBX From: ;tag=d2286fbc-667c-db11-8a96-00c09f2d8163 Call-ID: f49337ad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: ;tag=as432694d3 Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 WWW-Authenticate: Digest algorithm=MD5, realm="novacom", nonce="29deca2a" 2006/11/27 10:24:22.752 0:26.504 SIP Transp...t:b5e2cb40 SIP Transaction 4 REGISTER completed. 2006/11/27 10:24:22.752 0:26.504 SIP Transp...t:b5e2cb40 SIP Received Authentication Required response 2006/11/27 10:24:22.754 0:26.506 SIP Transp...t:b5e2cb40 SIP Adding authentication information 2006/11/27 10:24:22.754 0:26.506 SIP Transp...t:b5e2cb40 SIP Sending PDU on udp$172.16.100.198:5060 REGISTER sip:172.16.100.198 SIP/2.0 CSeq: 5 REGISTER Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bKe42470bc-667c-db11-8a96-00c09f2d8163;rport User-Agent: Ekiga/2.1.0 Authorization: Digest username="9197", realm="novacom", nonce="29deca2a", uri="sip:172.16.100.198", algorithm=md5, response="1304adc75acad701286422a13fd8deba" From: ;tag=d2286fbc-667c-db11-8a96-00c09f2d8163 Call-ID: f49337ad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: Contact: Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE,INFO,PING,PUBLISH Expires: 0 Content-Length: 0 Max-Forwards: 70 2006/11/27 10:24:22.755 0:26.507 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:24:22.756 0:26.508 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 SIP/2.0 100 Trying CSeq: 5 REGISTER Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bKe42470bc-667c-db11-8a96-00c09f2d8163;rport;received=172.16.100.166 User-Agent: Asterisk PBX From: ;tag=d2286fbc-667c-db11-8a96-00c09f2d8163 Call-ID: f49337ad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 2006/11/27 10:24:22.756 0:26.508 SIP Transp...t:b5e2cb40 SIP Transaction 5 REGISTER proceeding. 2006/11/27 10:24:22.757 0:26.509 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:24:22.758 0:26.510 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 SIP/2.0 200 OK Date: Mon, 27 Nov 2006 09:51:33 GMT CSeq: 5 REGISTER Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bKe42470bc-667c-db11-8a96-00c09f2d8163;rport;received=172.16.100.166 User-Agent: Asterisk PBX From: ;tag=d2286fbc-667c-db11-8a96-00c09f2d8163 Call-ID: f49337ad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: ;tag=as432694d3 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Expires: 0 Content-Length: 0 2006/11/27 10:24:22.758 0:26.510 SIP Transp...t:b5e2cb40 SIP Transaction 5 REGISTER completed. 2006/11/27 10:24:22.759 0:26.511 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:24:22.761 0:26.513 ekiga SIP Deleting SIPRegisterInfo sip:9197 at 172.16.100.198 2006/11/27 10:24:22.761 0:26.513 ekiga SIP Deleting SIPInfo sip:9197 at 172.16.100.198 2006/11/27 10:24:22.761 0:26.513 ekiga SIP Deleting SIPSubscribeInfo sip:9105 at 172.16.100.198 2006/11/27 10:24:22.761 0:26.513 ekiga SIP Deleting SIPInfo sip:9105 at 172.16.100.198 2006/11/27 10:24:22.761 0:26.513 ekiga Listen Stopping listening thread on udp$172.16.100.166:5060 2006/11/27 10:24:22.761 0:26.514 Opal Liste...er:83fab50 Listen UDP select error: Appel syst?me interrompu 2006/11/27 10:24:22.775 0:26.527 ekiga SIP Deleted endpoint. 2006/11/27 10:24:22.776 0:26.528 ekiga SIP Deleting transport udp$172.16.100.198:5060 2006/11/27 10:24:22.776 0:26.528 ekiga OpalUDP Close 2006/11/27 10:24:22.776 0:26.528 ekiga Opal Transport Close 2006/11/27 10:24:22.776 0:26.528 SIP Transp...t:b5e2cb40 SIP Read thread finished. 2006/11/27 10:24:22.776 0:26.528 ekiga Opal Transport clean up on termination 2006/11/27 10:24:22.776 0:26.528 ekiga OpalUDP Close 2006/11/27 10:24:22.776 0:26.528 ekiga Opal Transport Close 2006/11/27 10:24:22.777 0:26.529 ekiga Opal Deleted transport udp$172.16.100.198:5060 2006/11/27 10:24:22.777 0:26.529 ekiga OpalEP sip endpoint destroyed. 2006/11/27 10:24:22.777 0:26.529 ekiga PCSS Deleted PC sound system endpoint. 2006/11/27 10:24:22.779 0:26.531 ekiga OpalEP pc endpoint destroyed. 2006/11/27 10:24:22.779 0:26.531 ekiga OpalMan Deleted manager. From dsandras at seconix.com Mon Nov 27 09:51:16 2006 From: dsandras at seconix.com (Damien Sandras) Date: Mon, 27 Nov 2006 10:51:16 +0100 Subject: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?] In-Reply-To: <20061127203750.4F91.CRAIGS@postincrement.com> References: <20061127101517.D63E.CRAIGS@postincrement.com> <1164619618.3775.15.camel@golgoth01> <20061127203750.4F91.CRAIGS@postincrement.com> Message-ID: <1164621076.3775.37.camel@golgoth01> Le lundi 27 novembre 2006 ? 20:40 +1100, Craig Southeren a ?crit : > > What is OPAL doing during the one second gap? > Haven't you received the output.txt file? Here it is again. It is just doing stuff and starting threads and so on ;-) -- _ Damien Sandras (o- //\ Ekiga Softphone : http://www.ekiga.org/ v_/_ NOVACOM : http://www.novacom.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsandras at ekiga.net -------------- next part -------------- 2006/11/27 10:23:56.481 0:00.234 ekiga Detected audio plugins: ALSA,OSS,ESD 2006/11/27 10:23:56.482 0:00.234 ekiga Detected video plugins: YUVFile,Shm,Picture,V4L 2006/11/27 10:23:56.482 0:00.234 ekiga Detected audio plugins: ALSA,OSS,ESD 2006/11/27 10:23:56.482 0:00.234 ekiga Detected video plugins: YUVFile,Shm,Picture,V4L 2006/11/27 10:23:56.488 0:00.240 ekiga Detected the following audio input devices: SiS SI7012,SiS SI7013 Modem,Default with plugin ALSA 2006/11/27 10:23:56.488 0:00.240 ekiga Detected the following audio output devices: SiS SI7012,SiS SI7013 Modem,Default with plugin ALSA 2006/11/27 10:23:56.488 0:00.240 ekiga Detected the following video input devices: StaticPicture,MovingLogo with plugin Picture 2006/11/27 10:23:56.488 0:00.240 ekiga Detected the following audio input devices: SiS SI7012,SiS SI7013 Modem,Default with plugin ALSA 2006/11/27 10:23:56.488 0:00.240 ekiga Detected the following audio output devices: SiS SI7012,SiS SI7013 Modem,Default with plugin ALSA 2006/11/27 10:23:56.488 0:00.240 ekiga Detected the following video input devices: StaticPicture,MovingLogo with plugin Picture 2006/11/27 10:23:56.960 0:00.713 ekiga Ekiga version 2.1.0 2006/11/27 10:23:56.961 0:00.713 ekiga OPAL version 2.3.2 2006/11/27 10:23:56.961 0:00.713 ekiga PWLIB version 1.11.2 2006/11/27 10:23:56.961 0:00.713 ekiga GNOME support disabled 2006/11/27 10:23:56.961 0:00.713 ekiga Fullscreen support enabled 2006/11/27 10:23:56.961 0:00.714 ekiga DBUS support enabled 2006/11/27 10:23:56.964 0:00.716 ekiga Set TCP port range to 30000:30010 2006/11/27 10:23:56.964 0:00.716 ekiga Set RTP port range to 5000:5059 2006/11/27 10:23:56.964 0:00.716 ekiga Set UDP port range to 5060:5100 2006/11/27 10:23:56.964 0:00.717 ekiga OpalEP Created endpoint: h323 2006/11/27 10:23:56.965 0:00.717 ekiga H460 Endpoint Attached 2006/11/27 10:23:56.965 0:00.717 ekiga H323 Created endpoint. 2006/11/27 10:23:56.965 0:00.717 ekiga OpalMan Added route "pc:.*=h323:" 2006/11/27 10:23:56.966 0:00.718 ekiga OpalEP Created endpoint: sip 2006/11/27 10:23:56.966 0:00.718 ekiga SIP Created endpoint. 2006/11/27 10:23:56.966 0:00.718 ekiga OpalMan Added route "pc:.*=sip:" 2006/11/27 10:23:56.966 0:00.718 ekiga OpalEP Created endpoint: pc 2006/11/27 10:23:57.012 0:00.765 ekiga PCSS Created PC sound system endpoint. 2006/11/27 10:23:57.013 0:00.765 ekiga OpalMan Added route "h323:.*=pc:" 2006/11/27 10:23:57.013 0:00.765 ekiga OpalMan Added route "sip:.*=pc:" 2006/11/27 10:23:57.018 0:00.770 Opal Liste...er:83f93c8 Listen Started listening thread on udp$172.16.100.166:1720 2006/11/27 10:23:57.018 0:00.770 Opal Liste...er:83f93c8 Listen Waiting on UDP packet on udp$172.16.100.166:1720 2006/11/27 10:23:57.019 0:00.771 Opal Liste...er:83fab50 Listen Started listening thread on udp$172.16.100.166:5060 2006/11/27 10:23:57.019 0:00.771 Opal Liste...er:83fab50 Listen Waiting on UDP packet on udp$172.16.100.166:5060 2006/11/27 10:23:57.043 0:00.795 ekiga Detected audio codecs: G.711-ALaw-64k,G.711-uLaw-64k,G.726-16k,G.726-24k,G.726-32k,G.726-40k,GSM-06.10,GSM-AMR,iLBC-13k3,LPC-10,SpeexNB,SpeexIETFNarrow-8k,SpeexWNarrow-8k,SpeexWB,SpeexIETFWide-20.6k 2006/11/27 10:23:57.092 0:00.844 ekiga Detected video codecs: H.261,H.261-CIF,H.261-QCIF 2006/11/27 10:23:57.179 0:00.931 GMAccounts...t:083fd178 SIP Could not find active REGISTER for dsandras at ekiga.net 2006/11/27 10:23:57.179 0:00.931 GMAccounts...t:083fd178 SIP Could not find active REGISTER for damien.sandras at voip.wengo.fr 2006/11/27 10:23:57.221 0:00.973 GMAccounts...t:083fd178 OpalUDP Binding to interface: 172.16.100.166:32791 2006/11/27 10:23:57.221 0:00.973 GMAccounts...t:083fd178 SIP Created transport udp$0.0.0.0 2006/11/27 10:23:57.222 0:00.974 GMAccounts...t:083fd178 OpalUDP Started connect to 172.16.100.198:5060 2006/11/27 10:23:57.223 0:00.975 GMAccounts...t:083fd178 OpalUDP Connect on pre-bound interface: 172.16.100.166 2006/11/27 10:23:57.224 0:00.976 GMAccounts...t:083fd178 SIP Created new transport for 172.16.100.198 : udp$172.16.100.198:5060 2006/11/27 10:23:57.230 0:00.982 GMAccounts...t:083fd178 SIP Sending PDU on udp$172.16.100.198:5060 REGISTER sip:172.16.100.198 SIP/2.0 CSeq: 1 REGISTER Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bK841b39ad-667c-db11-8a96-00c09f2d8163;rport User-Agent: Ekiga/2.1.0 From: ;tag=1e0439ad-667c-db11-8a96-00c09f2d8163 Call-ID: f49337ad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: Contact: Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE,INFO,PING,PUBLISH Expires: 3600 Content-Length: 0 Max-Forwards: 70 2006/11/27 10:23:57.232 0:00.984 GMAccounts...t:083fd178 SIP Could not find active REGISTER for 274738 at fwd.pulver.com 2006/11/27 10:23:57.232 0:00.984 GMAccounts...t:083fd178 SIP Could not find active REGISTER for 06213804954 at sip2.neophonex.hu 2006/11/27 10:23:57.233 0:00.985 GMAccounts...t:083fd178 SIP Could not find active REGISTER for 6359 at itbx-polymedis 2006/11/27 10:23:57.233 0:00.985 SIP Transp...t:b5e2cb40 SIP Read thread started. 2006/11/27 10:23:57.234 0:00.986 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:23:57.235 0:00.987 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 SIP/2.0 100 Trying CSeq: 1 REGISTER Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bK841b39ad-667c-db11-8a96-00c09f2d8163;rport;received=172.16.100.166 User-Agent: Asterisk PBX From: ;tag=1e0439ad-667c-db11-8a96-00c09f2d8163 Call-ID: f49337ad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 2006/11/27 10:23:57.237 0:00.989 SIP Transp...t:b5e2cb40 SIP Transaction 1 REGISTER proceeding. 2006/11/27 10:23:57.237 0:00.989 SIP Transp...t:b5e2cb40 OpalUDP Ended connect, selecting 172.16.100.166:5061 2006/11/27 10:23:57.238 0:00.990 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:23:57.239 0:00.991 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 SIP/2.0 401 Unauthorized CSeq: 1 REGISTER Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bK841b39ad-667c-db11-8a96-00c09f2d8163;rport;received=172.16.100.166 User-Agent: Asterisk PBX From: ;tag=1e0439ad-667c-db11-8a96-00c09f2d8163 Call-ID: f49337ad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: ;tag=as4b2f79e2 Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 WWW-Authenticate: Digest algorithm=MD5, realm="novacom", nonce="2c83b4d4" 2006/11/27 10:23:57.240 0:00.992 SIP Transp...t:b5e2cb40 SIP Transaction 1 REGISTER completed. 2006/11/27 10:23:57.240 0:00.993 SIP Transp...t:b5e2cb40 SIP Received Authentication Required response 2006/11/27 10:23:57.241 0:00.993 SIP Transp...t:b5e2cb40 SIP Updated realm to novacom 2006/11/27 10:23:57.245 0:00.997 SIP Transp...t:b5e2cb40 SIP Adding authentication information 2006/11/27 10:23:57.246 0:00.998 SIP Transp...t:b5e2cb40 SIP Sending PDU on udp$172.16.100.198:5060 REGISTER sip:172.16.100.198 SIP/2.0 CSeq: 2 REGISTER Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bKd6a83bad-667c-db11-8a96-00c09f2d8163;rport User-Agent: Ekiga/2.1.0 Authorization: Digest username="9197", realm="novacom", nonce="2c83b4d4", uri="sip:172.16.100.198", algorithm=md5, response="c45a43a6d7ee52b35ea35860d0344cd2" From: ;tag=1e0439ad-667c-db11-8a96-00c09f2d8163 Call-ID: f49337ad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: Contact: Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE,INFO,PING,PUBLISH Expires: 3600 Content-Length: 0 Max-Forwards: 70 2006/11/27 10:23:57.247 0:00.999 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:23:57.248 0:01.000 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 SIP/2.0 100 Trying CSeq: 2 REGISTER Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bKd6a83bad-667c-db11-8a96-00c09f2d8163;rport;received=172.16.100.166 User-Agent: Asterisk PBX From: ;tag=1e0439ad-667c-db11-8a96-00c09f2d8163 Call-ID: f49337ad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 2006/11/27 10:23:57.249 0:01.002 SIP Transp...t:b5e2cb40 SIP Transaction 2 REGISTER proceeding. 2006/11/27 10:23:57.250 0:01.002 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:23:57.252 0:01.004 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 OPTIONS sip:9197 at 172.16.100.166:5061;transport=udp SIP/2.0 Date: Mon, 27 Nov 2006 09:51:08 GMT CSeq: 102 OPTIONS Via: SIP/2.0/UDP 172.16.100.198:5060;branch=z9hG4bK50a7bacb;rport User-Agent: Asterisk PBX From: "asterisk" ;tag=as085fd1a2 Call-ID: 5d4666de20206c12242782446b178996 at 172.16.100.198 To: Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 Max-Forwards: 70 2006/11/27 10:23:57.253 0:01.006 SIP Transp...t:b5e2cb40 SIP Tranport remote address change from Via: udp$172.16.100.198:5060 2006/11/27 10:23:57.256 0:01.008 SIP Transp...t:b5e2cb40 SIP Sending PDU on udp$172.16.100.198:5060 SIP/2.0 200 OK CSeq: 102 OPTIONS Via: SIP/2.0/UDP 172.16.100.198:5060;branch=z9hG4bK50a7bacb;rport=5060;received=172.16.100.198 From: "asterisk" ;tag=as085fd1a2 Call-ID: 5d4666de20206c12242782446b178996 at 172.16.100.198 To: Contact: Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE,INFO,PING,PUBLISH Content-Length: 0 2006/11/27 10:23:57.257 0:01.009 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:23:57.258 0:01.010 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 SIP/2.0 200 OK Date: Mon, 27 Nov 2006 09:51:08 GMT CSeq: 2 REGISTER Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bKd6a83bad-667c-db11-8a96-00c09f2d8163;rport;received=172.16.100.166 User-Agent: Asterisk PBX From: ;tag=1e0439ad-667c-db11-8a96-00c09f2d8163 Call-ID: f49337ad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: ;tag=as4b2f79e2 Contact: ;expires=3600 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Expires: 3600 Content-Length: 0 2006/11/27 10:23:57.259 0:01.011 SIP Transp...t:b5e2cb40 SIP Transaction 2 REGISTER completed. 2006/11/27 10:23:57.356 0:01.108 SIP Transp...t:b5e2cb40 SIP Using existing transport udp$172.16.100.198:5060 for 172.16.100.198 2006/11/27 10:23:57.361 0:01.113 GMAccounts...t:083fd178 SIP Using existing transport udp$172.16.100.198:5060 for 172.16.100.198 2006/11/27 10:23:57.361 0:01.113 SIP Transp...t:b5e2cb40 SIP Sending PDU on udp$172.16.100.198:5060 PUBLISH sip:9197 at 172.16.100.198 SIP/2.0 CSeq: 3 PUBLISH Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bK98204dad-667c-db11-8a96-00c09f2d8163;rport User-Agent: Ekiga/2.1.0 From: ;tag=18194dad-667c-db11-8a96-00c09f2d8163 Call-ID: e6f54cad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: Contact: Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE,INFO,PING,PUBLISH Expires: 500 Event: presence Content-Type: application/pidf+xml Content-Length: 310 Max-Forwards: 70 Away open 9197 at 172.16.100.198 2006/11/27 10:23:57.362 0:01.114 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:23:57.363 0:01.115 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 SIP/2.0 501 Method Not Implemented CSeq: 3 PUBLISH Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bK98204dad-667c-db11-8a96-00c09f2d8163;rport;received=172.16.100.166 User-Agent: Asterisk PBX From: ;tag=18194dad-667c-db11-8a96-00c09f2d8163 Call-ID: e6f54cad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: ;tag=as6c1fb783 Accept: application/sdp Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 2006/11/27 10:23:57.364 0:01.116 SIP Transp...t:b5e2cb40 SIP Transaction 3 PUBLISH completed. 2006/11/27 10:23:57.365 0:01.117 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:23:57.365 0:01.118 GMAccounts...t:083fd178 SIP Sending PDU on udp$172.16.100.198:5060 SUBSCRIBE sip:9105 at 172.16.100.198 SIP/2.0 CSeq: 1 SUBSCRIBE Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bKc4f34dad-667c-db11-8a96-00c09f2d8163;rport User-Agent: Ekiga/2.1.0 From: ;tag=eac34dad-667c-db11-8a96-00c09f2d8163 Call-ID: 127e4dad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: Contact: Accept: application/pidf+xml Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE,INFO,PING,PUBLISH Expires: 500 Event: presence Content-Length: 0 Max-Forwards: 70 2006/11/27 10:23:57.367 0:01.120 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 SIP/2.0 401 Unauthorized CSeq: 1 SUBSCRIBE Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bKc4f34dad-667c-db11-8a96-00c09f2d8163;rport;received=172.16.100.166 User-Agent: Asterisk PBX From: ;tag=eac34dad-667c-db11-8a96-00c09f2d8163 Call-ID: 127e4dad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: ;tag=as12885a66 Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 WWW-Authenticate: Digest algorithm=MD5, realm="novacom", nonce="048b5552" 2006/11/27 10:23:57.369 0:01.121 SIP Transp...t:b5e2cb40 SIP Transaction 1 SUBSCRIBE completed. 2006/11/27 10:23:57.369 0:01.121 SIP Transp...t:b5e2cb40 SIP Received Authentication Required response 2006/11/27 10:23:57.372 0:01.124 SIP Transp...t:b5e2cb40 SIP Adding authentication information 2006/11/27 10:23:57.373 0:01.125 SIP Transp...t:b5e2cb40 SIP Sending PDU on udp$172.16.100.198:5060 SUBSCRIBE sip:9105 at 172.16.100.198 SIP/2.0 CSeq: 2 SUBSCRIBE Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bKaa1b4fad-667c-db11-8a96-00c09f2d8163;rport User-Agent: Ekiga/2.1.0 Authorization: Digest username="9197", realm="novacom", nonce="048b5552", uri="sip:9105 at 172.16.100.198", algorithm=md5, response="0c81d5a630f2c65f8826aa2646769e77" From: ;tag=eac34dad-667c-db11-8a96-00c09f2d8163 Call-ID: 127e4dad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: Contact: Accept: application/pidf+xml Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE,INFO,PING,PUBLISH Expires: 500 Event: presence Content-Length: 0 Max-Forwards: 70 2006/11/27 10:23:57.373 0:01.125 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:23:57.375 0:01.127 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 SIP/2.0 200 OK CSeq: 2 SUBSCRIBE Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bKaa1b4fad-667c-db11-8a96-00c09f2d8163;rport;received=172.16.100.166 User-Agent: Asterisk PBX From: ;tag=eac34dad-667c-db11-8a96-00c09f2d8163 Call-ID: 127e4dad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: ;tag=as12885a66 Contact: ;expires=500 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Expires: 500 Content-Length: 0 2006/11/27 10:23:57.376 0:01.128 SIP Transp...t:b5e2cb40 SIP Transaction 2 SUBSCRIBE completed. 2006/11/27 10:23:57.377 0:01.129 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:23:57.378 0:01.130 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 NOTIFY sip:9197 at 172.16.100.198 SIP/2.0 CSeq: 102 NOTIFY Via: SIP/2.0/UDP 172.16.100.198:5060;branch=z9hG4bK208a40f7;rport User-Agent: Asterisk PBX From: ;tag=as12885a66 Call-ID: 127e4dad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: ;tag=eac34dad-667c-db11-8a96-00c09f2d8163 Contact: Subscription-State: active Event: presence Content-Type: application/pidf+xml Content-Length: 483 Max-Forwards: 70 Ready sip:9105 at 172.16.100.198 open 2006/11/27 10:23:57.379 0:01.131 SIP Transp...t:b5e2cb40 SIP Tranport remote address change from Via: udp$172.16.100.198:5060 2006/11/27 10:23:57.379 0:01.131 SIP Transp...t:b5e2cb40 SIP Received NOTIFY 2006/11/27 10:23:57.380 0:01.132 SIP Transp...t:b5e2cb40 SIP Found a SUBSCRIBE corresponding to the NOTIFY 2006/11/27 10:23:57.380 0:01.132 SIP Transp...t:b5e2cb40 SIP Subscription is active 2006/11/27 10:23:57.384 0:01.136 SIP Transp...t:b5e2cb40 SIP Sending PDU on udp$172.16.100.198:5060 SIP/2.0 200 OK CSeq: 102 NOTIFY Via: SIP/2.0/UDP 172.16.100.198:5060;branch=z9hG4bK208a40f7;rport=5060;received=172.16.100.198 From: ;tag=as12885a66 Call-ID: 127e4dad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: ;tag=eac34dad-667c-db11-8a96-00c09f2d8163 Contact: Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE,INFO,PING,PUBLISH Content-Length: 0 2006/11/27 10:23:57.385 0:01.137 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:23:58.243 0:01.995 Housekeeper SIP Set state Terminated_Success for transaction 1 REGISTER 2006/11/27 10:23:58.259 0:02.011 Housekeeper SIP Set state Terminated_Success for transaction 2 REGISTER 2006/11/27 10:23:58.367 0:02.119 Housekeeper SIP Set state Terminated_Success for transaction 3 PUBLISH 2006/11/27 10:23:58.371 0:02.123 Housekeeper SIP Set state Terminated_Success for transaction 1 SUBSCRIBE 2006/11/27 10:23:58.379 0:02.131 Housekeeper SIP Set state Terminated_Success for transaction 2 SUBSCRIBE 2006/11/27 10:24:06.492 0:10.244 Housekeeper SIP Deleting SIPPublishInfo sip:9197 at 172.16.100.198 2006/11/27 10:24:06.492 0:10.245 Housekeeper SIP Deleting SIPInfo sip:9197 at 172.16.100.198 2006/11/27 10:24:08.382 0:12.134 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 NOTIFY sip:9197 at 172.16.100.166:5061;transport=udp SIP/2.0 CSeq: 102 NOTIFY Via: SIP/2.0/UDP 172.16.100.198:5060;branch=z9hG4bK5803d7b4;rport User-Agent: Asterisk PBX From: "asterisk" ;tag=as222fac2f Call-ID: 34323c203ec199a764bc23d952195410 at 172.16.100.198 To: Contact: Event: message-summary Content-Type: application/simple-message-summary Content-Length: 94 Max-Forwards: 70 Messages-Waiting: no Message-Account: sip:asterisk at 172.16.100.198 Voice-Message: 0/0 (0/0) 2006/11/27 10:24:08.383 0:12.135 SIP Transp...t:b5e2cb40 SIP Tranport remote address change from Via: udp$172.16.100.198:5060 2006/11/27 10:24:08.383 0:12.135 SIP Transp...t:b5e2cb40 SIP Received NOTIFY 2006/11/27 10:24:08.383 0:12.135 SIP Transp...t:b5e2cb40 SIP Could not find a SUBSCRIBE corresponding to the NOTIFY 2006/11/27 10:24:08.383 0:12.135 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:24:08.397 0:12.149 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 NOTIFY sip:9197 at 172.16.100.166:5061;transport=udp SIP/2.0 CSeq: 102 NOTIFY Via: SIP/2.0/UDP 172.16.100.198:5060;branch=z9hG4bK5803d7b4;rport User-Agent: Asterisk PBX From: "asterisk" ;tag=as222fac2f Call-ID: 34323c203ec199a764bc23d952195410 at 172.16.100.198 To: Contact: Event: message-summary Content-Type: application/simple-message-summary Content-Length: 94 Max-Forwards: 70 Messages-Waiting: no Message-Account: sip:asterisk at 172.16.100.198 Voice-Message: 0/0 (0/0) 2006/11/27 10:24:08.398 0:12.150 SIP Transp...t:b5e2cb40 SIP Tranport remote address change from Via: udp$172.16.100.198:5060 2006/11/27 10:24:08.398 0:12.150 SIP Transp...t:b5e2cb40 SIP Received NOTIFY 2006/11/27 10:24:08.399 0:12.151 SIP Transp...t:b5e2cb40 SIP Could not find a SUBSCRIBE corresponding to the NOTIFY 2006/11/27 10:24:08.399 0:12.151 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:24:08.414 0:12.166 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 NOTIFY sip:9197 at 172.16.100.166:5061;transport=udp SIP/2.0 CSeq: 102 NOTIFY Via: SIP/2.0/UDP 172.16.100.198:5060;branch=z9hG4bK5803d7b4;rport User-Agent: Asterisk PBX From: "asterisk" ;tag=as222fac2f Call-ID: 34323c203ec199a764bc23d952195410 at 172.16.100.198 To: Contact: Event: message-summary Content-Type: application/simple-message-summary Content-Length: 94 Max-Forwards: 70 Messages-Waiting: no Message-Account: sip:asterisk at 172.16.100.198 Voice-Message: 0/0 (0/0) 2006/11/27 10:24:08.414 0:12.166 SIP Transp...t:b5e2cb40 SIP Tranport remote address change from Via: udp$172.16.100.198:5060 2006/11/27 10:24:08.415 0:12.167 SIP Transp...t:b5e2cb40 SIP Received NOTIFY 2006/11/27 10:24:08.415 0:12.167 SIP Transp...t:b5e2cb40 SIP Could not find a SUBSCRIBE corresponding to the NOTIFY 2006/11/27 10:24:08.415 0:12.167 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:24:08.446 0:12.198 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 NOTIFY sip:9197 at 172.16.100.166:5061;transport=udp SIP/2.0 CSeq: 102 NOTIFY Via: SIP/2.0/UDP 172.16.100.198:5060;branch=z9hG4bK5803d7b4;rport User-Agent: Asterisk PBX From: "asterisk" ;tag=as222fac2f Call-ID: 34323c203ec199a764bc23d952195410 at 172.16.100.198 To: Contact: Event: message-summary Content-Type: application/simple-message-summary Content-Length: 94 Max-Forwards: 70 Messages-Waiting: no Message-Account: sip:asterisk at 172.16.100.198 Voice-Message: 0/0 (0/0) 2006/11/27 10:24:08.446 0:12.198 SIP Transp...t:b5e2cb40 SIP Tranport remote address change from Via: udp$172.16.100.198:5060 2006/11/27 10:24:08.447 0:12.199 SIP Transp...t:b5e2cb40 SIP Received NOTIFY 2006/11/27 10:24:08.447 0:12.199 SIP Transp...t:b5e2cb40 SIP Could not find a SUBSCRIBE corresponding to the NOTIFY 2006/11/27 10:24:08.447 0:12.199 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:24:08.510 0:12.262 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 NOTIFY sip:9197 at 172.16.100.166:5061;transport=udp SIP/2.0 CSeq: 102 NOTIFY Via: SIP/2.0/UDP 172.16.100.198:5060;branch=z9hG4bK5803d7b4;rport User-Agent: Asterisk PBX From: "asterisk" ;tag=as222fac2f Call-ID: 34323c203ec199a764bc23d952195410 at 172.16.100.198 To: Contact: Event: message-summary Content-Type: application/simple-message-summary Content-Length: 94 Max-Forwards: 70 Messages-Waiting: no Message-Account: sip:asterisk at 172.16.100.198 Voice-Message: 0/0 (0/0) 2006/11/27 10:24:08.510 0:12.262 SIP Transp...t:b5e2cb40 SIP Tranport remote address change from Via: udp$172.16.100.198:5060 2006/11/27 10:24:08.511 0:12.263 SIP Transp...t:b5e2cb40 SIP Received NOTIFY 2006/11/27 10:24:08.511 0:12.263 SIP Transp...t:b5e2cb40 SIP Could not find a SUBSCRIBE corresponding to the NOTIFY 2006/11/27 10:24:08.511 0:12.263 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:24:08.638 0:12.390 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 NOTIFY sip:9197 at 172.16.100.166:5061;transport=udp SIP/2.0 CSeq: 102 NOTIFY Via: SIP/2.0/UDP 172.16.100.198:5060;branch=z9hG4bK5803d7b4;rport User-Agent: Asterisk PBX From: "asterisk" ;tag=as222fac2f Call-ID: 34323c203ec199a764bc23d952195410 at 172.16.100.198 To: Contact: Event: message-summary Content-Type: application/simple-message-summary Content-Length: 94 Max-Forwards: 70 Messages-Waiting: no Message-Account: sip:asterisk at 172.16.100.198 Voice-Message: 0/0 (0/0) 2006/11/27 10:24:08.638 0:12.390 SIP Transp...t:b5e2cb40 SIP Tranport remote address change from Via: udp$172.16.100.198:5060 2006/11/27 10:24:08.639 0:12.391 SIP Transp...t:b5e2cb40 SIP Received NOTIFY 2006/11/27 10:24:08.639 0:12.391 SIP Transp...t:b5e2cb40 SIP Could not find a SUBSCRIBE corresponding to the NOTIFY 2006/11/27 10:24:08.639 0:12.391 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:24:08.897 0:12.650 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 NOTIFY sip:9197 at 172.16.100.166:5061;transport=udp SIP/2.0 CSeq: 102 NOTIFY Via: SIP/2.0/UDP 172.16.100.198:5060;branch=z9hG4bK5803d7b4;rport User-Agent: Asterisk PBX From: "asterisk" ;tag=as222fac2f Call-ID: 34323c203ec199a764bc23d952195410 at 172.16.100.198 To: Contact: Event: message-summary Content-Type: application/simple-message-summary Content-Length: 94 Max-Forwards: 70 Messages-Waiting: no Message-Account: sip:asterisk at 172.16.100.198 Voice-Message: 0/0 (0/0) 2006/11/27 10:24:08.898 0:12.650 SIP Transp...t:b5e2cb40 SIP Tranport remote address change from Via: udp$172.16.100.198:5060 2006/11/27 10:24:08.898 0:12.650 SIP Transp...t:b5e2cb40 SIP Received NOTIFY 2006/11/27 10:24:08.899 0:12.651 SIP Transp...t:b5e2cb40 SIP Could not find a SUBSCRIBE corresponding to the NOTIFY 2006/11/27 10:24:08.899 0:12.651 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:24:09.959 0:13.711 GMURLHandl...r:0843fa00 OpalMan Set up call from pc:* to sip:444 at 172.16.100.198 2006/11/27 10:24:09.959 0:13.711 GMURLHandl...r:0843fa00 Call Created Call[1] 2006/11/27 10:24:09.960 0:13.712 GMURLHandl...r:0843fa00 OpalMan Set up connection to "pc:*" 2006/11/27 10:24:10.012 0:13.767 GMURLHandl...r:0843fa00 OpalCon Created connection Call[1]-EP[Default] 2006/11/27 10:24:10.015 0:13.767 GMURLHandl...r:0843fa00 RFC2833 Handler created 2006/11/27 10:24:10.015 0:13.767 GMURLHandl...r:0843fa00 Silence Handler created 2006/11/27 10:24:10.015 0:13.767 GMURLHandl...r:0843fa00 Echo Canceler Handler created 2006/11/27 10:24:10.015 0:13.768 GMURLHandl...r:0843fa00 PCSS Created PC sound system connection. 2006/11/27 10:24:10.016 0:13.768 GMURLHandl...r:0843fa00 OpalMan On incoming connection Call[1]-EP[Default] 2006/11/27 10:24:10.016 0:13.768 GMURLHandl...r:0843fa00 Call GetOtherPartyConnection Call[1]-EP[Default] 2006/11/27 10:24:10.016 0:13.768 GMURLHandl...r:0843fa00 OpalMan Set up connection to "sip:444 at 172.16.100.198" 2006/11/27 10:24:10.017 0:13.769 GMURLHandl...r:0843fa00 OpalCon Created connection Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:10.017 0:13.769 GMURLHandl...r:0843fa00 RFC2833 Handler created 2006/11/27 10:24:10.018 0:13.770 GMURLHandl...r:0843fa00 SIP Created connection. 2006/11/27 10:24:10.018 0:13.770 GMURLHandl...r:0843fa00 PCSS Outgoing call routed to sip:444 at 172.16.100.198 for Call[1]-EP[Default] 2006/11/27 10:24:10.019 0:13.771 GMURLHandl...r:0843fa00 Call OnSetUp Call[1]-EP[Default] 2006/11/27 10:24:10.019 0:13.771 GMURLHandl...r:0843fa00 SIP SetUpConnection: 2006/11/27 10:24:10.020 0:13.772 GMURLHandl...r:0843fa00 OpalUDP Binding to interface: 172.16.100.166:32792 2006/11/27 10:24:10.020 0:13.772 GMURLHandl...r:0843fa00 SIP Created transport udp$0.0.0.0 2006/11/27 10:24:10.020 0:13.773 GMURLHandl...r:0843fa00 OpalUDP Started connect to 172.16.100.198:5060 2006/11/27 10:24:10.021 0:13.773 GMURLHandl...r:0843fa00 OpalUDP Connect on pre-bound interface: 172.16.100.166 2006/11/27 10:24:10.023 0:13.775 GMURLHandl...r:0843fa00 SIP Transaction 1 INVITE created. 2006/11/27 10:24:10.023 0:13.775 GMURLHandl...r:0843fa00 Call CanDoMediaBypass Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] session 1 2006/11/27 10:24:10.023 0:13.775 GMURLHandl...r:0843fa00 OpalMan IsMediaBypassPossible: session 1 2006/11/27 10:24:10.023 0:13.775 GMURLHandl...r:0843fa00 SIP IsMediaBypassPossible: session 1 2006/11/27 10:24:10.023 0:13.775 GMURLHandl...r:0843fa00 OpalCon IsMediaBypassPossible: default returns FALSE 2006/11/27 10:24:10.024 0:13.776 GMURLHandl...r:0843fa00 RTP_UDP RTP session created with NAT flag set to 0 2006/11/27 10:24:10.024 0:13.776 SIP Transp...rt:84677a8 SIP Read thread started. 2006/11/27 10:24:10.024 0:13.776 SIP Transp...rt:84677a8 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:24:10.024 0:13.776 GMURLHandl...r:0843fa00 RTP_UDP Session 1 created: 172.16.100.166:5000-5001 ssrc=37556996 2006/11/27 10:24:10.025 0:13.777 GMURLHandl...r:0843fa00 RTP Adding session RTP_UDP 2006/11/27 10:24:10.035 0:13.787 GMURLHandl...r:0843fa00 Call GetMediaFormats for Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] H.261 H.261-CIF H.261-QCIF GSM-06.10 G.711-uLaw-64k G.711-ALaw-64k iLBC-13k3 PCM-16 YUV420P RGB32 RGB24 2006/11/27 10:24:10.042 0:13.794 GMURLHandl...r:0843fa00 SIP Using RTP payload [pt=101] for NTE 2006/11/27 10:24:10.042 0:13.794 GMURLHandl...r:0843fa00 Call CanDoMediaBypass Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] session 2 2006/11/27 10:24:10.043 0:13.795 GMURLHandl...r:0843fa00 OpalMan IsMediaBypassPossible: session 2 2006/11/27 10:24:10.043 0:13.795 GMURLHandl...r:0843fa00 SIP IsMediaBypassPossible: session 2 2006/11/27 10:24:10.043 0:13.795 GMURLHandl...r:0843fa00 OpalCon IsMediaBypassPossible: default returns FALSE 2006/11/27 10:24:10.043 0:13.795 GMURLHandl...r:0843fa00 RTP_UDP RTP session created with NAT flag set to 0 2006/11/27 10:24:10.043 0:13.795 GMURLHandl...r:0843fa00 RTP_UDP Session 2 created: 172.16.100.166:5002-5003 ssrc=1969090190 2006/11/27 10:24:10.044 0:13.796 GMURLHandl...r:0843fa00 RTP Adding session RTP_UDP 2006/11/27 10:24:10.061 0:13.813 GMURLHandl...r:0843fa00 Call GetMediaFormats for Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] H.261 H.261-CIF H.261-QCIF GSM-06.10 G.711-uLaw-64k G.711-ALaw-64k iLBC-13k3 PCM-16 YUV420P RGB32 RGB24 2006/11/27 10:24:10.061 0:13.813 GMURLHandl...r:0843fa00 SIP Creating INVITE request 2006/11/27 10:24:10.062 0:13.814 GMURLHandl...r:0843fa00 SIP No authentication information present 2006/11/27 10:24:10.063 0:13.815 GMURLHandl...r:0843fa00 SIP Sending PDU on udp$172.16.100.198:5060 INVITE sip:444 at 172.16.100.198 SIP/2.0 Date: Mon, 27 Nov 2006 09:24:10 GMT CSeq: 1 INVITE Via: SIP/2.0/UDP 172.16.100.166:5062;branch=z9hG4bKc69ad9b4-667c-db11-8a96-00c09f2d8163;rport User-Agent: Ekiga/2.1.0 From: "Damien Sandras" ;tag=82b2d8b4-667c-db11-8a96-00c09f2d8163 Call-ID: e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01 To: Contact: Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE,INFO,PING,PUBLISH Content-Type: application/sdp Content-Length: 332 Max-Forwards: 70 v=0 o=- 1164619450 1164619450 IN IP4 172.16.100.166 s=Opal SIP Session c=IN IP4 172.16.100.166 t=0 0 m=audio 5000 RTP/AVP 3 0 8 107 101 a=rtpmap:3 gsm/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:107 iLBC/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 m=video 5002 RTP/AVP 31 a=rtpmap:31 h261/90000 2006/11/27 10:24:10.063 0:13.815 GMURLHandl...r:0843fa00 OpalCon OnSetUpConnectionCall[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:10.063 0:13.815 GMURLHandl...r:0843fa00 OpalEP OnSetUpConnection Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:10.063 0:13.815 GMURLHandl...r:0843fa00 SetUpCall succeeded, call=Call[1] 2006/11/27 10:24:10.065 0:13.817 SIP Transp...rt:84677a8 SIP PDU Received on udp$172.16.100.198:5060 SIP/2.0 407 Proxy Authentication Required CSeq: 1 INVITE Via: SIP/2.0/UDP 172.16.100.166:5062;branch=z9hG4bKc69ad9b4-667c-db11-8a96-00c09f2d8163;rport;received=172.16.100.166 User-Agent: Asterisk PBX From: "Damien Sandras" ;tag=82b2d8b4-667c-db11-8a96-00c09f2d8163 Call-ID: e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01 To: ;tag=as6959fcbc Contact: Proxy-Authenticate: Digest algorithm=MD5, realm="novacom", nonce="7667840a" Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 2006/11/27 10:24:10.065 0:13.817 SIP Transp...rt:84677a8 OpalUDP Ended connect, selecting 172.16.100.166:5062 2006/11/27 10:24:10.066 0:13.818 SIP Transp...rt:84677a8 SIP Queueing PDU: 1 INVITE <407> 2006/11/27 10:24:10.066 0:13.818 SIP Transp...rt:84677a8 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:24:10.066 0:13.818 SIP Handle...er:843fa00 SIP PDU handler thread started. 2006/11/27 10:24:10.066 0:13.818 SIP Handle...er:843fa00 SIP Awaiting next PDU. 2006/11/27 10:24:10.066 0:13.818 SIP Handle...er:843fa00 SIP Handling PDU 1 INVITE <407> 2006/11/27 10:24:10.067 0:13.819 SIP Handle...er:843fa00 SIP Transaction 1 INVITE completed. 2006/11/27 10:24:10.068 0:13.821 SIP Handle...er:843fa00 SIP Sending PDU on udp$172.16.100.198:5060 ACK sip:444 at 172.16.100.198 SIP/2.0 CSeq: 1 ACK Via: SIP/2.0/UDP 172.16.100.166:5062;branch=z9hG4bKc69ad9b4-667c-db11-8a96-00c09f2d8163;rport From: "Damien Sandras" ;tag=82b2d8b4-667c-db11-8a96-00c09f2d8163 Call-ID: e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01 To: ;tag=as6959fcbc Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE,INFO,PING,PUBLISH Content-Length: 0 Max-Forwards: 70 2006/11/27 10:24:10.069 0:13.821 SIP Handle...er:843fa00 SIP Received Proxy Authentication Required response 2006/11/27 10:24:10.070 0:13.822 SIP Handle...er:843fa00 SIP Transaction 2 INVITE created. 2006/11/27 10:24:10.070 0:13.822 SIP Handle...er:843fa00 Call CanDoMediaBypass Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] session 1 2006/11/27 10:24:10.070 0:13.822 SIP Handle...er:843fa00 OpalMan IsMediaBypassPossible: session 1 2006/11/27 10:24:10.070 0:13.822 SIP Handle...er:843fa00 SIP IsMediaBypassPossible: session 1 2006/11/27 10:24:10.070 0:13.822 SIP Handle...er:843fa00 OpalCon IsMediaBypassPossible: default returns FALSE 2006/11/27 10:24:10.071 0:13.823 SIP Handle...er:843fa00 RTP_UDP RTP session created with NAT flag set to 0 2006/11/27 10:24:10.071 0:13.823 SIP Handle...er:843fa00 RTP_UDP Session 1 created: 172.16.100.166:5004-5005 ssrc=1931258738 2006/11/27 10:24:10.071 0:13.823 SIP Handle...er:843fa00 RTP Adding session RTP_UDP 2006/11/27 10:24:10.081 0:13.833 SIP Handle...er:843fa00 Call GetMediaFormats for Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] H.261 H.261-CIF H.261-QCIF GSM-06.10 G.711-uLaw-64k G.711-ALaw-64k iLBC-13k3 PCM-16 YUV420P RGB32 RGB24 2006/11/27 10:24:10.082 0:13.834 SIP Handle...er:843fa00 SIP Using RTP payload [pt=101] for NTE 2006/11/27 10:24:10.082 0:13.834 SIP Handle...er:843fa00 Call CanDoMediaBypass Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] session 2 2006/11/27 10:24:10.082 0:13.834 SIP Handle...er:843fa00 OpalMan IsMediaBypassPossible: session 2 2006/11/27 10:24:10.082 0:13.834 SIP Handle...er:843fa00 SIP IsMediaBypassPossible: session 2 2006/11/27 10:24:10.083 0:13.835 SIP Handle...er:843fa00 OpalCon IsMediaBypassPossible: default returns FALSE 2006/11/27 10:24:10.083 0:13.835 SIP Handle...er:843fa00 RTP_UDP RTP session created with NAT flag set to 0 2006/11/27 10:24:10.083 0:13.835 SIP Handle...er:843fa00 RTP_UDP Session 2 created: 172.16.100.166:5006-5007 ssrc=65754113 2006/11/27 10:24:10.083 0:13.835 SIP Handle...er:843fa00 RTP Adding session RTP_UDP 2006/11/27 10:24:10.096 0:13.848 SIP Handle...er:843fa00 Call GetMediaFormats for Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] H.261 H.261-CIF H.261-QCIF GSM-06.10 G.711-uLaw-64k G.711-ALaw-64k iLBC-13k3 PCM-16 YUV420P RGB32 RGB24 2006/11/27 10:24:10.098 0:13.850 SIP Handle...er:843fa00 SIP Creating INVITE request 2006/11/27 10:24:10.099 0:13.851 SIP Handle...er:843fa00 SIP Adding authentication information 2006/11/27 10:24:10.100 0:13.852 SIP Handle...er:843fa00 SIP Sending PDU on udp$172.16.100.198:5060 INVITE sip:444 at 172.16.100.198 SIP/2.0 Date: Mon, 27 Nov 2006 09:24:10 GMT CSeq: 2 INVITE Via: SIP/2.0/UDP 172.16.100.166:5062;branch=z9hG4bK34d0e0b4-667c-db11-8a96-00c09f2d8163;rport User-Agent: Ekiga/2.1.0 From: "Damien Sandras" ;tag=82b2d8b4-667c-db11-8a96-00c09f2d8163 Call-ID: e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01 To: Contact: Proxy-Authorization: Digest username="9197", realm="novacom", nonce="7667840a", uri="sip:444 at 172.16.100.198", algorithm=md5, response="f0c88e73029e2ee264996aa51acfeb58" Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE,INFO,PING,PUBLISH Content-Type: application/sdp Content-Length: 332 Max-Forwards: 70 v=0 o=- 1164619450 1164619450 IN IP4 172.16.100.166 s=Opal SIP Session c=IN IP4 172.16.100.166 t=0 0 m=audio 5004 RTP/AVP 3 0 8 107 101 a=rtpmap:3 gsm/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:107 iLBC/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 m=video 5006 RTP/AVP 31 a=rtpmap:31 h261/90000 2006/11/27 10:24:10.101 0:13.853 SIP Handle...er:843fa00 SIP Awaiting next PDU. 2006/11/27 10:24:10.102 0:13.854 SIP Transp...rt:84677a8 SIP PDU Received on udp$172.16.100.198:5060 SIP/2.0 100 Trying CSeq: 2 INVITE Via: SIP/2.0/UDP 172.16.100.166:5062;branch=z9hG4bK34d0e0b4-667c-db11-8a96-00c09f2d8163;rport;received=172.16.100.166 User-Agent: Asterisk PBX From: "Damien Sandras" ;tag=82b2d8b4-667c-db11-8a96-00c09f2d8163 Call-ID: e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01 To: Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 2006/11/27 10:24:10.104 0:13.856 SIP Transp...rt:84677a8 SIP Queueing PDU: 2 INVITE <100> 2006/11/27 10:24:10.104 0:13.856 SIP Transp...rt:84677a8 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:24:10.105 0:13.857 SIP Transp...rt:84677a8 SDP Media session port=19144 2006/11/27 10:24:10.105 0:13.857 SIP Transp...rt:84677a8 SDP Adding media session with 2 formats 2006/11/27 10:24:10.106 0:13.858 SIP Transp...rt:84677a8 SDP Media attribute silenceSupp found for unknown RTP type PCMU 2006/11/27 10:24:10.106 0:13.858 SIP Transp...rt:84677a8 SIP PDU Received on udp$172.16.100.198:5060 SIP/2.0 200 OK CSeq: 2 INVITE Via: SIP/2.0/UDP 172.16.100.166:5062;branch=z9hG4bK34d0e0b4-667c-db11-8a96-00c09f2d8163;rport;received=172.16.100.166 User-Agent: Asterisk PBX From: "Damien Sandras" ;tag=82b2d8b4-667c-db11-8a96-00c09f2d8163 Call-ID: e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01 To: ;tag=as3d2c9853 Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Type: application/sdp Content-Length: 218 v=0 o=root 5150 5150 IN IP4 172.16.100.198 s=session c=IN IP4 172.16.100.198 t=0 0 m=audio 19144 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - 2006/11/27 10:24:10.107 0:13.859 SIP Transp...rt:84677a8 SIP Queueing PDU: 2 INVITE <200> 2006/11/27 10:24:10.107 0:13.859 SIP Transp...rt:84677a8 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:24:10.107 0:13.859 SIP Handle...er:843fa00 SIP Handling PDU 2 INVITE <100> 2006/11/27 10:24:10.107 0:13.859 SIP Handle...er:843fa00 SIP Transaction 2 INVITE proceeding. 2006/11/27 10:24:10.108 0:13.860 SIP Handle...er:843fa00 SIP Set targetAddress to sip:444 at 172.16.100.198 2006/11/27 10:24:10.108 0:13.860 SIP Handle...er:843fa00 SIP Received Trying response 2006/11/27 10:24:10.108 0:13.860 SIP Handle...er:843fa00 SIP Awaiting next PDU. 2006/11/27 10:24:10.108 0:13.860 SIP Handle...er:843fa00 SIP Handling PDU 2 INVITE <200> 2006/11/27 10:24:10.109 0:13.861 SIP Handle...er:843fa00 SIP Transaction 2 INVITE completed. 2006/11/27 10:24:10.109 0:13.861 SIP Handle...er:843fa00 SIP Set targetAddress to sip:444 at 172.16.100.198 2006/11/27 10:24:10.110 0:13.862 SIP Handle...er:843fa00 SIP Adding authentication information 2006/11/27 10:24:10.110 0:13.862 SIP Handle...er:843fa00 SIP Sending PDU on udp$172.16.100.198:5060 ACK sip:444 at 172.16.100.198 SIP/2.0 CSeq: 2 ACK Via: SIP/2.0/UDP 172.16.100.166:5062;branch=z9hG4bK1eefe6b4-667c-db11-8a96-00c09f2d8163;rport From: "Damien Sandras" ;tag=82b2d8b4-667c-db11-8a96-00c09f2d8163 Call-ID: e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01 To: ;tag=as3d2c9853 Contact: Proxy-Authorization: Digest username="9197", realm="novacom", nonce="7667840a", uri="sip:444 at 172.16.100.198", algorithm=md5, response="82ebe1ee326fe5e5c349e7f2569809a4" Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE,INFO,PING,PUBLISH Content-Length: 0 Max-Forwards: 70 2006/11/27 10:24:10.111 0:13.863 SIP Handle...er:843fa00 SIP Received INVITE OK response 2006/11/27 10:24:10.111 0:13.863 SIP Handle...er:843fa00 Call GetOtherPartyConnection Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:10.111 0:13.863 SIP Handle...er:843fa00 Call CanDoMediaBypass Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] session 1 2006/11/27 10:24:10.111 0:13.863 SIP Handle...er:843fa00 OpalMan IsMediaBypassPossible: session 1 2006/11/27 10:24:10.111 0:13.863 SIP Handle...er:843fa00 SIP IsMediaBypassPossible: session 1 2006/11/27 10:24:10.111 0:13.863 SIP Handle...er:843fa00 OpalCon IsMediaBypassPossible: default returns FALSE 2006/11/27 10:24:10.111 0:13.864 SIP Handle...er:843fa00 RTP Found existing session 1 2006/11/27 10:24:10.112 0:13.864 SIP Handle...er:843fa00 SIP RTP payload type PCMA matched to codec G.711-ALaw-64k 2006/11/27 10:24:10.113 0:13.865 SIP Handle...er:843fa00 Call OpenSourceMediaStreams for session 1 with media G.711-ALaw-64k 2006/11/27 10:24:10.114 0:13.866 SIP Handle...er:843fa00 OpalCon OpenSourceMediaStream for session 1 on Call[1]-EP[Default] 2006/11/27 10:24:10.115 0:13.867 SIP Handle...er:843fa00 OpalCon Selected media stream PCM-16 -> G.711-ALaw-64k 2006/11/27 10:24:11.192 0:14.944 Housekeeper SIP Set state Terminated_Success for transaction 2 INVITE 2006/11/27 10:24:11.198 0:14.950 SIP Handle...er:843fa00 OpalMan OnOpenMediaStream Call[1]-EP[Default],OpalAudioMediaStream-Source-PCM-16 2006/11/27 10:24:11.199 0:14.951 SIP Handle...er:843fa00 Call PatchMediaStreams Call[1]-EP[Default] 2006/11/27 10:24:11.199 0:14.951 SIP Handle...er:843fa00 OpalCon OpenSinkMediaStream Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] session=1 2006/11/27 10:24:11.200 0:14.952 SIP Handle...er:843fa00 OpalCon OpenSinkMediaStream, selected PCM-16 -> G.711-ALaw-64k 2006/11/27 10:24:11.200 0:14.952 SIP Handle...er:843fa00 Call CanDoMediaBypass Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] session 1 2006/11/27 10:24:11.200 0:14.952 SIP Handle...er:843fa00 OpalMan IsMediaBypassPossible: session 1 2006/11/27 10:24:11.201 0:14.953 SIP Handle...er:843fa00 SIP IsMediaBypassPossible: session 1 2006/11/27 10:24:11.201 0:14.953 SIP Handle...er:843fa00 OpalCon IsMediaBypassPossible: default returns FALSE 2006/11/27 10:24:11.201 0:14.953 SIP Handle...er:843fa00 RTP Found existing session 1 2006/11/27 10:24:11.201 0:14.953 SIP Handle...er:843fa00 RTP Found existing session 1 2006/11/27 10:24:11.202 0:14.954 SIP Handle...er:843fa00 OpalMan OnOpenMediaStream Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01],OpalRTPMediaStream-Sink-G.711-ALaw-64k 2006/11/27 10:24:11.206 0:14.958 SIP Handle...er:843fa00 Patch Added sink from PCM-16 Clock Rate = 8000 Frame Time = 8 Max Bit Rate = 64000 Max Frame Size = 16 Needs Jitter = 1 Rx Frames Per Packet = 240 Tx Frames Per Packet = 30 to G.711-ALaw-64k Clock Rate = 8000 Frame Time = 8 Max Bit Rate = 64000 Max Frame Size = 8 Needs Jitter = 1 Rx Frames Per Packet = 240 Tx Frames Per Packet = 30 2006/11/27 10:24:11.207 0:14.959 SIP Handle...er:843fa00 Codec G711-ALaw-64k encoder created 2006/11/27 10:24:11.208 0:14.960 SIP Handle...er:843fa00 Patch Added media stream sink OpalRTPMediaStream-Sink-G.711-ALaw-64k using transcoder PCM-16->G.711-ALaw-64k 2006/11/27 10:24:11.208 0:14.960 SIP Handle...er:843fa00 Media Audio source data size set to 320 bytes and 4 buffers. 2006/11/27 10:24:11.209 0:14.961 SIP Handle...er:843fa00 OpalCon New patch created 2006/11/27 10:24:11.209 0:14.961 SIP Handle...er:843fa00 OpalCon New patch created 2006/11/27 10:24:11.209 0:14.961 SIP Handle...er:843fa00 OpalCOn Adding RFC2833 transmit handler 2006/11/27 10:24:11.210 0:14.962 SIP Handle...er:843fa00 Call OpenSourceMediaStreams for session 1 adjusted media to G.711-ALaw-64k 2006/11/27 10:24:11.210 0:14.962 SIP Handle...er:843fa00 Call GetOtherPartyConnection Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:11.211 0:14.963 SIP Handle...er:843fa00 OpalCon OpenSourceMediaStream for session 1 on Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:11.212 0:14.964 SIP Handle...er:843fa00 OpalCon Selected media stream G.711-ALaw-64k -> PCM-16 2006/11/27 10:24:11.212 0:14.964 SIP Handle...er:843fa00 Call CanDoMediaBypass Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] session 1 2006/11/27 10:24:11.212 0:14.964 SIP Handle...er:843fa00 OpalMan IsMediaBypassPossible: session 1 2006/11/27 10:24:11.212 0:14.965 SIP Handle...er:843fa00 SIP IsMediaBypassPossible: session 1 2006/11/27 10:24:11.213 0:14.965 SIP Handle...er:843fa00 OpalCon IsMediaBypassPossible: default returns FALSE 2006/11/27 10:24:11.213 0:14.965 SIP Handle...er:843fa00 RTP Found existing session 1 2006/11/27 10:24:11.213 0:14.965 SIP Handle...er:843fa00 RTP Found existing session 1 2006/11/27 10:24:11.213 0:14.965 SIP Handle...er:843fa00 OpalMan OnOpenMediaStream Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01],OpalRTPMediaStream-Source-G.711-ALaw-64k 2006/11/27 10:24:11.213 0:14.965 SIP Handle...er:843fa00 Call PatchMediaStreams Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:11.213 0:14.965 SIP Handle...er:843fa00 OpalCon OpenSinkMediaStream Call[1]-EP[Default] session=1 2006/11/27 10:24:11.214 0:14.966 SIP Handle...er:843fa00 OpalCon OpenSinkMediaStream, selected G.711-ALaw-64k -> PCM-16 2006/11/27 10:24:11.217 0:14.969 SIP Handle...er:843fa00 OpalMan OnOpenMediaStream Call[1]-EP[Default],OpalAudioMediaStream-Sink-PCM-16 2006/11/27 10:24:11.218 0:14.970 SIP Handle...er:843fa00 Patch Added sink from G.711-ALaw-64k Clock Rate = 8000 Frame Time = 8 Max Bit Rate = 64000 Max Frame Size = 8 Needs Jitter = 1 Rx Frames Per Packet = 240 Tx Frames Per Packet = 30 to PCM-16 Clock Rate = 8000 Frame Time = 8 Max Bit Rate = 128000 Max Frame Size = 16 Needs Jitter = 1 Rx Frames Per Packet = 240 Tx Frames Per Packet = 30 2006/11/27 10:24:11.219 0:14.971 SIP Handle...er:843fa00 Codec G711-ALaw-64k decoder created 2006/11/27 10:24:11.219 0:14.971 SIP Handle...er:843fa00 Media Audio sink data size set to 320 bytes and 4 buffers. 2006/11/27 10:24:11.219 0:14.972 SIP Handle...er:843fa00 Patch Added media stream sink OpalAudioMediaStream-Sink-PCM-16 using transcoder G.711-ALaw-64k->PCM-16 2006/11/27 10:24:11.220 0:14.972 SIP Handle...er:843fa00 OpalCon New patch created 2006/11/27 10:24:11.220 0:14.972 SIP Handle...er:843fa00 OpalCon New patch created 2006/11/27 10:24:11.220 0:14.972 SIP Handle...er:843fa00 OpalCon Adding RFC2833 receive handler 2006/11/27 10:24:11.223 0:14.975 SIP Handle...er:843fa00 OpalCon OpenSourceMediaStream (already opened) for session 1 on Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:11.224 0:14.976 SIP Handle...er:843fa00 RTP_UDP SetRemoteSocketInfo: session=1 data channel, new=172.16.100.198:19144, local=172.16.100.166:5004-5005, remote=0.0.0.0:0-0 2006/11/27 10:24:11.224 0:14.976 SIP Handle...er:843fa00 SIP Could not find SDP media description for Video 2006/11/27 10:24:11.225 0:14.977 SIP Handle...er:843fa00 SIP Could not find SDP media description for Image 2006/11/27 10:24:11.225 0:14.977 SIP Handle...er:843fa00 OpalMan OnConnected Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:11.225 0:14.978 SIP Handle...er:843fa00 Call OnConnected Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:11.226 0:14.978 SIP Handle...er:843fa00 PCSS SetConnected() 2006/11/27 10:24:11.226 0:14.978 SIP Handle...er:843fa00 GMPCSSEndpoint PCSS connection established 2006/11/27 10:24:11.226 0:14.978 SIP Handle...er:843fa00 GMManager Will establish the connection 2006/11/27 10:24:11.226 0:14.978 SIP Handle...er:843fa00 OpalMan OnEstablished Call[1]-EP[Default] 2006/11/27 10:24:11.227 0:14.979 SIP Handle...er:843fa00 Call OnEstablished Call[1]-EP[Default] 2006/11/27 10:24:11.238 0:14.990 SIP Handle...er:843fa00 Call GetMediaFormats for Call[1]-EP[Default] G.711-ALaw-64k PCM-16 2006/11/27 10:24:11.238 0:14.990 SIP Handle...er:843fa00 Call OpenSourceMediaStreams for session 1 with media G.711-ALaw-64k,PCM-16 2006/11/27 10:24:11.238 0:14.990 SIP Handle...er:843fa00 OpalCon OpenSourceMediaStream (already opened) for session 1 on Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:11.239 0:14.991 SIP Handle...er:843fa00 Call OpenSourceMediaStreams for session 2 with media G.711-ALaw-64k,PCM-16 2006/11/27 10:24:11.239 0:14.991 SIP Handle...er:843fa00 Call OpenSourceMediaStreams for session 3 with media G.711-ALaw-64k,PCM-16 2006/11/27 10:24:11.250 0:15.002 SIP Handle...er:843fa00 Call GetMediaFormats for Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] G.711-ALaw-64k PCM-16 2006/11/27 10:24:11.251 0:15.003 SIP Handle...er:843fa00 Call OpenSourceMediaStreams for session 1 with media G.711-ALaw-64k,PCM-16 2006/11/27 10:24:11.251 0:15.003 SIP Handle...er:843fa00 OpalCon OpenSourceMediaStream (already opened) for session 1 on Call[1]-EP[Default] 2006/11/27 10:24:11.251 0:15.003 SIP Handle...er:843fa00 Call OpenSourceMediaStreams for session 1 adjusted media to PCM-16,G.711-ALaw-64k 2006/11/27 10:24:11.251 0:15.003 SIP Handle...er:843fa00 Call OpenSourceMediaStreams for session 2 with media G.711-ALaw-64k,PCM-16 2006/11/27 10:24:11.251 0:15.003 SIP Handle...er:843fa00 Call OpenSourceMediaStreams for session 3 with media G.711-ALaw-64k,PCM-16 2006/11/27 10:24:11.251 0:15.003 Media Patc...ch:8470550 Patch Thread started for Patch OpalAudioMediaStream-Source-PCM-16 -> OpalRTPMediaStream-Sink-G.711-ALaw-64k 2006/11/27 10:24:11.252 0:15.005 SIP Handle...er:843fa00 Media Starting thread Media Patch:8470550 2006/11/27 10:24:11.253 0:15.005 Media Patc...h:b5e38f18 Patch Thread started for Patch OpalRTPMediaStream-Source-G.711-ALaw-64k -> OpalAudioMediaStream-Sink-PCM-16 2006/11/27 10:24:11.253 0:15.005 Media Patc...h:b5e38f18 RTP Jitter buffer created: size=101 delay=160-4000/160 (20ms) obj=0x840c988 2006/11/27 10:24:11.255 0:15.007 RTP Jitter...er:84b0eb8 RTP Jitter RTP receive thread started: 0x840c988 2006/11/27 10:24:11.256 0:15.008 RTP Jitter...er:84b0eb8 RTP First receive data: ver=2 pt=PCMA psz=160 m=0 x=0 seq=40148 ts=160 src=803175037 ccnt=0 2006/11/27 10:24:11.256 0:15.008 SIP Handle...er:843fa00 Media Starting thread Media Patch:b5e38f18 2006/11/27 10:24:11.256 0:15.008 SIP Handle...er:843fa00 OpalCon Media stream threads started. 2006/11/27 10:24:11.257 0:15.009 SIP Handle...er:843fa00 OpalCon Media stream threads started. 2006/11/27 10:24:11.257 0:15.009 SIP Handle...er:843fa00 OpalCon SetPhase from UninitialisedPhase to EstablishedPhase 2006/11/27 10:24:11.257 0:15.009 SIP Handle...er:843fa00 GMSIPEndpoint SIP connection established 2006/11/27 10:24:11.260 0:15.012 SIP Handle...er:843fa00 RTP Found existing session 1 2006/11/27 10:24:11.260 0:15.012 SIP Handle...er:843fa00 RTP Found existing session 2 2006/11/27 10:24:11.260 0:15.013 SIP Handle...er:843fa00 GMManager Will establish the connection 2006/11/27 10:24:11.261 0:15.013 SIP Handle...er:843fa00 OpalMan OnEstablished Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:11.261 0:15.013 SIP Handle...er:843fa00 Call OnEstablished Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:11.274 0:15.026 SIP Handle...er:843fa00 SIP Awaiting next PDU. 2006/11/27 10:24:11.276 0:15.028 Media Patc...h:b5e38f18 RTP Jitter buffer length exceeded 2006/11/27 10:24:11.276 0:15.028 Media Patc...h:b5e38f18 RTP Jitter buffer length exceed was prior to first write. Not increasing buffer size 2006/11/27 10:24:11.279 0:15.031 Media Patc...ch:8470550 RTP First sent data: ver=2 pt=PCMA psz=160 m=1 x=0 seq=39800 ts=0 src=1931258738 ccnt=0 2006/11/27 10:24:12.139 0:15.891 RTP Jitter...er:84b0eb8 RTP Receive statistics: packets=102 octets=16320 lost=0 tooLate=0 order=0 avgTime=8 maxTime=22 minTime=0 jitter=0 maxJitter=2 2006/11/27 10:24:12.272 0:16.024 Housekeeper RTP Found existing session 1 2006/11/27 10:24:12.272 0:16.024 Housekeeper RTP Found existing session 2 2006/11/27 10:24:13.280 0:17.032 Housekeeper RTP Found existing session 1 2006/11/27 10:24:13.280 0:17.033 Housekeeper RTP Found existing session 2 2006/11/27 10:24:13.282 0:17.034 Media Patc...ch:8470550 RTP Transmit statistics: packets=101 octets=16160 avgTime=20 maxTime=28 minTime=15 2006/11/27 10:24:14.152 0:17.904 RTP Jitter...er:84b0eb8 RTP Receive statistics: packets=202 octets=32320 lost=0 tooLate=0 order=0 avgTime=20 maxTime=25 minTime=15 jitter=1 maxJitter=2 2006/11/27 10:24:14.302 0:18.054 Housekeeper RTP Found existing session 1 2006/11/27 10:24:14.302 0:18.054 Housekeeper RTP Found existing session 2 2006/11/27 10:24:15.297 0:19.050 Housekeeper RTP Found existing session 1 2006/11/27 10:24:15.298 0:19.050 Housekeeper RTP Found existing session 2 2006/11/27 10:24:15.365 0:19.117 Media Patc...ch:8470550 RTP Transmit statistics: packets=201 octets=32160 avgTime=20 maxTime=25 minTime=15 2006/11/27 10:24:15.935 0:19.687 ekiga Call Clearing Call[1] reason=EndedByLocalUser 2006/11/27 10:24:15.935 0:19.687 ekiga OpalCon SetPhase from EstablishedPhase to ReleasingPhase 2006/11/27 10:24:15.935 0:19.687 ekiga OpalCon Releasing Call[1]-EP[Default] 2006/11/27 10:24:15.935 0:19.687 ekiga OpalCon Call end reason for Default set to EndedByLocalUser 2006/11/27 10:24:15.936 0:19.688 ekiga OpalCon SetPhase from EstablishedPhase to ReleasingPhase 2006/11/27 10:24:15.936 0:19.688 ekiga OpalCon Releasing Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:15.936 0:19.688 ekiga OpalCon Call end reason for e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01 set to EndedByLocalUser 2006/11/27 10:24:15.936 0:19.688 OnRelease:...se:84fcbb8 SIP OnReleased: Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01], phase = ReleasingPhase 2006/11/27 10:24:15.936 0:19.689 OnRelease:...se:84fcbb8 OpalCon SetPhase from ReleasingPhase to ReleasingPhase 2006/11/27 10:24:15.938 0:19.691 OnRelease:...se:84fcbb8 SIP Transaction 4 BYE created. 2006/11/27 10:24:15.940 0:19.692 OnRelease:...se:84fcbb8 Media Closing RTP for OpalRTPMediaStream-Sink-G.711-ALaw-64k 2006/11/27 10:24:15.941 0:19.693 OnRelease:...se:84fcbb8 RTP_UDP Session 1, Shutting down write. 2006/11/27 10:24:15.941 0:19.693 OnRelease:...se:84fcbb8 Media Closing stream OpalRTPMediaStream-Sink-G.711-ALaw-64k 2006/11/27 10:24:15.941 0:19.693 OnRelease:...se:84fcbb8 Media Disconnecting OpalRTPMediaStream-Sink-G.711-ALaw-64k from patch thread Patch OpalAudioMediaStream-Source-PCM-16 -> OpalRTPMediaStream-Sink-G.711-ALaw-64k 2006/11/27 10:24:15.941 0:19.693 OnRelease:...se:84fcbb8 Patch Removing media stream sink OpalRTPMediaStream-Sink-G.711-ALaw-64k 2006/11/27 10:24:15.942 0:19.694 OnRelease:...se:84b20e0 OpalCon OnReleased Call[1]-EP[Default] 2006/11/27 10:24:15.943 0:19.695 OnRelease:...se:84b20e0 Media Closing raw media stream OpalAudioMediaStream-Source-PCM-16 2006/11/27 10:24:15.943 0:19.695 OnRelease:...se:84b20e0 Media Closing stream OpalAudioMediaStream-Source-PCM-16 2006/11/27 10:24:15.943 0:19.695 OnRelease:...se:84b20e0 Media Disconnecting OpalAudioMediaStream-Source-PCM-16 from patch thread Patch OpalAudioMediaStream-Source-PCM-16 2006/11/27 10:24:15.943 0:19.695 OnRelease:...se:84b20e0 Patch Closing media patch Patch OpalAudioMediaStream-Source-PCM-16 2006/11/27 10:24:15.943 0:19.695 OnRelease:...se:84b20e0 Media Closing raw media stream OpalAudioMediaStream-Source-PCM-16 2006/11/27 10:24:15.944 0:19.696 OnRelease:...se:84b20e0 Patch Waiting for media patch thread to stop Patch OpalAudioMediaStream-Source-PCM-16 2006/11/27 10:24:15.945 0:19.697 OnRelease:...se:84fcbb8 Media Closing RTP for OpalRTPMediaStream-Source-G.711-ALaw-64k 2006/11/27 10:24:15.945 0:19.697 OnRelease:...se:84fcbb8 RTP_UDP Session 1, Shutting down read. 2006/11/27 10:24:15.945 0:19.697 OnRelease:...se:84fcbb8 Media Closing stream OpalRTPMediaStream-Source-G.711-ALaw-64k 2006/11/27 10:24:15.946 0:19.698 OnRelease:...se:84fcbb8 Media Disconnecting OpalRTPMediaStream-Source-G.711-ALaw-64k from patch thread Patch OpalRTPMediaStream-Source-G.711-ALaw-64k -> OpalAudioMediaStream-Sink-PCM-16 2006/11/27 10:24:15.949 0:19.702 OnRelease:...se:84fcbb8 Patch Closing media patch Patch OpalRTPMediaStream-Source-G.711-ALaw-64k -> OpalAudioMediaStream-Sink-PCM-16 2006/11/27 10:24:15.950 0:19.702 Media Patc...ch:8470550 Patch Thread ended for Patch OpalAudioMediaStream-Source-PCM-16 2006/11/27 10:24:15.950 0:19.702 RTP Jitter...er:84b0eb8 RTP_UDP Session 1, Read shutdown. 2006/11/27 10:24:15.950 0:19.702 OnRelease:...se:84fcbb8 Media Closing RTP for OpalRTPMediaStream-Source-G.711-ALaw-64k 2006/11/27 10:24:15.950 0:19.702 OnRelease:...se:84fcbb8 RTP_UDP Session 1, Shutting down read. 2006/11/27 10:24:15.950 0:19.702 RTP Jitter...er:84b0eb8 RTP Jitter RTP receive thread ended 2006/11/27 10:24:15.950 0:19.702 OnRelease:...se:84fcbb8 Patch Removing media stream sink OpalAudioMediaStream-Sink-PCM-16 2006/11/27 10:24:15.950 0:19.702 RTP Jitter...er:84b0eb8 RTP Jitter RTP receive thread finished: 0x840c988 2006/11/27 10:24:15.951 0:19.703 OnRelease:...se:84fcbb8 Patch Waiting for media patch thread to stop Patch OpalRTPMediaStream-Source-G.711-ALaw-64k 2006/11/27 10:24:15.956 0:19.708 Media Patc...h:b5e38f18 Patch Thread ended for Patch OpalRTPMediaStream-Source-G.711-ALaw-64k 2006/11/27 10:24:15.956 0:19.708 OnRelease:...se:84b20e0 Patch Media patch thread Patch OpalAudioMediaStream-Source-PCM-16 destroyed. 2006/11/27 10:24:15.957 0:19.709 OnRelease:...se:84b20e0 Media Closing raw media stream OpalAudioMediaStream-Sink-PCM-16 2006/11/27 10:24:15.957 0:19.709 OnRelease:...se:84b20e0 Media Closing stream OpalAudioMediaStream-Sink-PCM-16 2006/11/27 10:24:15.957 0:19.709 OnRelease:...se:84b20e0 OpalCon Media stream threads closed. 2006/11/27 10:24:15.958 0:19.710 OnRelease:...se:84b20e0 GMPCSSEndpoint PCSS connection released 2006/11/27 10:24:15.958 0:19.710 OnRelease:...se:84b20e0 OpalEP OnReleased Call[1]-EP[Default] 2006/11/27 10:24:15.958 0:19.710 OnRelease:...se:84b20e0 GMManager Will release the connection 2006/11/27 10:24:15.959 0:19.711 OnRelease:...se:84b20e0 OpalMan OnReleased Call[1]-EP[Default] 2006/11/27 10:24:15.959 0:19.711 OnRelease:...se:84b20e0 Call OnReleased Call[1]-EP[Default] 2006/11/27 10:24:15.959 0:19.711 OnRelease:...se:84b20e0 OpalCon Already released Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:15.959 0:19.711 OnRelease:...se:84b20e0 OpalCon OnRelease thread completed for Default 2006/11/27 10:24:15.964 0:19.716 OnRelease:...se:84fcbb8 Patch Media patch thread Patch OpalRTPMediaStream-Source-G.711-ALaw-64k destroyed. 2006/11/27 10:24:15.964 0:19.716 OnRelease:...se:84fcbb8 OpalCon Media stream threads closed. 2006/11/27 10:24:15.965 0:19.717 OnRelease:...se:84fcbb8 SIP Adding authentication information 2006/11/27 10:24:15.965 0:19.717 OnRelease:...se:84fcbb8 SIP Sending PDU on udp$172.16.100.198:5060 BYE sip:444 at 172.16.100.198 SIP/2.0 CSeq: 4 BYE Via: SIP/2.0/UDP 172.16.100.166:5062;branch=z9hG4bK843960b8-667c-db11-8a96-00c09f2d8163;rport From: "Damien Sandras" ;tag=82b2d8b4-667c-db11-8a96-00c09f2d8163 Call-ID: e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01 To: ;tag=as3d2c9853 Contact: Proxy-Authorization: Digest username="9197", realm="novacom", nonce="7667840a", uri="sip:444 at 172.16.100.198", algorithm=md5, response="9e726640173d81fb90121f519715cecc" Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE,INFO,PING,PUBLISH Content-Length: 0 Max-Forwards: 70 2006/11/27 10:24:15.967 0:19.719 SIP Transp...rt:84677a8 SIP PDU Received on udp$172.16.100.198:5060 SIP/2.0 200 OK CSeq: 4 BYE Via: SIP/2.0/UDP 172.16.100.166:5062;branch=z9hG4bK843960b8-667c-db11-8a96-00c09f2d8163;received=172.16.100.166;rport=5062 User-Agent: Asterisk PBX From: "Damien Sandras" ;tag=82b2d8b4-667c-db11-8a96-00c09f2d8163 Call-ID: e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01 To: ;tag=as3d2c9853 Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 2006/11/27 10:24:15.967 0:19.719 SIP Transp...rt:84677a8 SIP Queueing PDU: 4 BYE <200> 2006/11/27 10:24:15.968 0:19.720 SIP Transp...rt:84677a8 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:24:15.968 0:19.720 SIP Handle...er:843fa00 SIP Handling PDU 4 BYE <200> 2006/11/27 10:24:15.968 0:19.720 SIP Handle...er:843fa00 SIP Transaction 4 BYE completed. 2006/11/27 10:24:15.969 0:19.721 SIP Handle...er:843fa00 SIP Received OK response for non INVITE 2006/11/27 10:24:15.969 0:19.721 OnRelease:...se:84fcbb8 SIP Transaction 4 BYE aborted. 2006/11/27 10:24:15.969 0:19.721 SIP Handle...er:843fa00 SIP Awaiting next PDU. 2006/11/27 10:24:15.969 0:19.721 OnRelease:...se:84fcbb8 SIP Transaction 4 BYE destroyed. 2006/11/27 10:24:15.969 0:19.721 OnRelease:...se:84fcbb8 OpalCon SetPhase from ReleasingPhase to ReleasedPhase 2006/11/27 10:24:15.970 0:19.722 SIP Handle...er:843fa00 SIP PDU handler thread finished. 2006/11/27 10:24:15.981 0:19.733 OnRelease:...se:84fcbb8 Opal Transport clean up on termination 2006/11/27 10:24:15.981 0:19.733 OnRelease:...se:84fcbb8 OpalUDP Close 2006/11/27 10:24:15.981 0:19.733 OnRelease:...se:84fcbb8 Opal Transport Close 2006/11/27 10:24:15.982 0:19.734 SIP Transp...rt:84677a8 SIP Read thread finished. 2006/11/27 10:24:15.992 0:19.744 OnRelease:...se:84fcbb8 OpalCon OnReleased Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:15.993 0:19.745 OnRelease:...se:84fcbb8 OpalCon Media stream threads closed. 2006/11/27 10:24:15.993 0:19.745 OnRelease:...se:84fcbb8 GMSIPEndpoint SIP connection released 2006/11/27 10:24:15.993 0:19.745 OnRelease:...se:84fcbb8 OpalEP OnReleased Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:16.028 0:19.780 OnRelease:...se:84fcbb8 GMManager Will release the connection 2006/11/27 10:24:16.029 0:19.781 OnRelease:...se:84fcbb8 OpalMan OnReleased Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:16.029 0:19.781 OnRelease:...se:84fcbb8 Call OnReleased Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] 2006/11/27 10:24:16.572 0:20.456 OpalGarbage PCSS Deleted PC sound system connection. 2006/11/27 10:24:16.705 0:20.457 OpalGarbage OpalCon Connection Call[1]-EP[Default] destroyed. 2006/11/27 10:24:18.112 0:21.865 ekiga Call Clearing Call[1] reason=EndedByLocalUser 2006/11/27 10:24:19.279 0:23.031 OnRelease:...se:84fcbb8 RTP_UDP Session 1, Shutting down read. 2006/11/27 10:24:19.279 0:23.031 OnRelease:...se:84fcbb8 RTP_UDP Session 1, Shutting down write. 2006/11/27 10:24:19.279 0:23.031 OnRelease:...se:84fcbb8 RTP_UDP Session 2, Shutting down read. 2006/11/27 10:24:19.279 0:23.032 OnRelease:...se:84fcbb8 RTP_UDP Session 2, Shutting down write. 2006/11/27 10:24:19.280 0:23.032 OnRelease:...se:84fcbb8 SIP Transaction 1 INVITE aborted. 2006/11/27 10:24:19.280 0:23.032 OnRelease:...se:84fcbb8 SIP Transaction 1 INVITE destroyed. 2006/11/27 10:24:19.280 0:23.032 OnRelease:...se:84fcbb8 SIP Transaction 2 INVITE destroyed. 2006/11/27 10:24:19.280 0:23.032 OnRelease:...se:84fcbb8 OpalCon OnRelease thread completed for e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01 2006/11/27 10:24:19.717 0:23.469 OpalGarbage Opal Transport clean up on termination 2006/11/27 10:24:19.717 0:23.469 OpalGarbage OpalUDP Close 2006/11/27 10:24:19.717 0:23.469 OpalGarbage Opal Transport Close 2006/11/27 10:24:19.717 0:23.469 OpalGarbage Opal Deleted transport udp$172.16.100.198:5060 2006/11/27 10:24:19.717 0:23.469 OpalGarbage SIP Deleted connection. 2006/11/27 10:24:19.718 0:23.470 OpalGarbage OpalCon Connection Call[1]-EP[e6a8d8b4-667c-db11-8a96-00c09f2d8163 at golgoth01] destroyed. 2006/11/27 10:24:19.718 0:23.470 OpalGarbage RTP_UDP Session 1, Shutting down write. 2006/11/27 10:24:19.718 0:23.470 OpalGarbage RTP Final statistics: packetsSent = 229 octetsSent = 36640 averageSendTime = 20 maximumSendTime = 25 minimumSendTime = 15 packetsReceived = 287 octetsReceived = 45920 packetsLost = 0 packetsTooLate = 0 packetsOutOfOrder = 0 averageReceiveTime= 20 maximumReceiveTime= 25 minimumReceiveTime= 15 averageJitter = 0 maximumJitter = 3 2006/11/27 10:24:19.718 0:23.470 OpalGarbage RTP Removing jitter buffer 0x840c988 RTP Jitter:84b0eb8 2006/11/27 10:24:19.718 0:23.471 OpalGarbage RTP_UDP Session 2, Shutting down read. 2006/11/27 10:24:19.719 0:23.471 OpalGarbage RTP_UDP Session 2, Shutting down write. 2006/11/27 10:24:20.725 0:24.477 OpalGarbage Call Call[1] destroyed. 2006/11/27 10:24:22.733 0:26.485 ekiga Listen Stopping listening thread on udp$172.16.100.166:1720 2006/11/27 10:24:22.733 0:26.485 Opal Liste...er:83f93c8 Listen UDP select error: Appel syst?me interrompu 2006/11/27 10:24:22.745 0:26.497 ekiga H323 Deleted endpoint. 2006/11/27 10:24:22.745 0:26.497 ekiga OpalEP h323 endpoint destroyed. 2006/11/27 10:24:22.748 0:26.500 ekiga SIP Sending PDU on udp$172.16.100.198:5060 REGISTER sip:172.16.100.198 SIP/2.0 CSeq: 4 REGISTER Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bK0a326fbc-667c-db11-8a96-00c09f2d8163;rport User-Agent: Ekiga/2.1.0 From: ;tag=d2286fbc-667c-db11-8a96-00c09f2d8163 Call-ID: f49337ad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: Contact: Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE,INFO,PING,PUBLISH Expires: 0 Content-Length: 0 Max-Forwards: 70 2006/11/27 10:24:22.749 0:26.501 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 SIP/2.0 100 Trying CSeq: 4 REGISTER Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bK0a326fbc-667c-db11-8a96-00c09f2d8163;rport;received=172.16.100.166 User-Agent: Asterisk PBX From: ;tag=d2286fbc-667c-db11-8a96-00c09f2d8163 Call-ID: f49337ad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 2006/11/27 10:24:22.750 0:26.502 SIP Transp...t:b5e2cb40 SIP Transaction 4 REGISTER proceeding. 2006/11/27 10:24:22.750 0:26.502 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:24:22.751 0:26.503 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 SIP/2.0 401 Unauthorized CSeq: 4 REGISTER Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bK0a326fbc-667c-db11-8a96-00c09f2d8163;rport;received=172.16.100.166 User-Agent: Asterisk PBX From: ;tag=d2286fbc-667c-db11-8a96-00c09f2d8163 Call-ID: f49337ad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: ;tag=as432694d3 Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 WWW-Authenticate: Digest algorithm=MD5, realm="novacom", nonce="29deca2a" 2006/11/27 10:24:22.752 0:26.504 SIP Transp...t:b5e2cb40 SIP Transaction 4 REGISTER completed. 2006/11/27 10:24:22.752 0:26.504 SIP Transp...t:b5e2cb40 SIP Received Authentication Required response 2006/11/27 10:24:22.754 0:26.506 SIP Transp...t:b5e2cb40 SIP Adding authentication information 2006/11/27 10:24:22.754 0:26.506 SIP Transp...t:b5e2cb40 SIP Sending PDU on udp$172.16.100.198:5060 REGISTER sip:172.16.100.198 SIP/2.0 CSeq: 5 REGISTER Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bKe42470bc-667c-db11-8a96-00c09f2d8163;rport User-Agent: Ekiga/2.1.0 Authorization: Digest username="9197", realm="novacom", nonce="29deca2a", uri="sip:172.16.100.198", algorithm=md5, response="1304adc75acad701286422a13fd8deba" From: ;tag=d2286fbc-667c-db11-8a96-00c09f2d8163 Call-ID: f49337ad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: Contact: Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE,INFO,PING,PUBLISH Expires: 0 Content-Length: 0 Max-Forwards: 70 2006/11/27 10:24:22.755 0:26.507 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:24:22.756 0:26.508 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 SIP/2.0 100 Trying CSeq: 5 REGISTER Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bKe42470bc-667c-db11-8a96-00c09f2d8163;rport;received=172.16.100.166 User-Agent: Asterisk PBX From: ;tag=d2286fbc-667c-db11-8a96-00c09f2d8163 Call-ID: f49337ad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 2006/11/27 10:24:22.756 0:26.508 SIP Transp...t:b5e2cb40 SIP Transaction 5 REGISTER proceeding. 2006/11/27 10:24:22.757 0:26.509 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:24:22.758 0:26.510 SIP Transp...t:b5e2cb40 SIP PDU Received on udp$172.16.100.198:5060 SIP/2.0 200 OK Date: Mon, 27 Nov 2006 09:51:33 GMT CSeq: 5 REGISTER Via: SIP/2.0/UDP 172.16.100.166:5061;branch=z9hG4bKe42470bc-667c-db11-8a96-00c09f2d8163;rport;received=172.16.100.166 User-Agent: Asterisk PBX From: ;tag=d2286fbc-667c-db11-8a96-00c09f2d8163 Call-ID: f49337ad-667c-db11-8a96-00c09f2d8163 at golgoth01 To: ;tag=as432694d3 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Expires: 0 Content-Length: 0 2006/11/27 10:24:22.758 0:26.510 SIP Transp...t:b5e2cb40 SIP Transaction 5 REGISTER completed. 2006/11/27 10:24:22.759 0:26.511 SIP Transp...t:b5e2cb40 SIP Waiting for PDU on udp$172.16.100.198:5060 2006/11/27 10:24:22.761 0:26.513 ekiga SIP Deleting SIPRegisterInfo sip:9197 at 172.16.100.198 2006/11/27 10:24:22.761 0:26.513 ekiga SIP Deleting SIPInfo sip:9197 at 172.16.100.198 2006/11/27 10:24:22.761 0:26.513 ekiga SIP Deleting SIPSubscribeInfo sip:9105 at 172.16.100.198 2006/11/27 10:24:22.761 0:26.513 ekiga SIP Deleting SIPInfo sip:9105 at 172.16.100.198 2006/11/27 10:24:22.761 0:26.513 ekiga Listen Stopping listening thread on udp$172.16.100.166:5060 2006/11/27 10:24:22.761 0:26.514 Opal Liste...er:83fab50 Listen UDP select error: Appel syst?me interrompu 2006/11/27 10:24:22.775 0:26.527 ekiga SIP Deleted endpoint. 2006/11/27 10:24:22.776 0:26.528 ekiga SIP Deleting transport udp$172.16.100.198:5060 2006/11/27 10:24:22.776 0:26.528 ekiga OpalUDP Close 2006/11/27 10:24:22.776 0:26.528 ekiga Opal Transport Close 2006/11/27 10:24:22.776 0:26.528 SIP Transp...t:b5e2cb40 SIP Read thread finished. 2006/11/27 10:24:22.776 0:26.528 ekiga Opal Transport clean up on termination 2006/11/27 10:24:22.776 0:26.528 ekiga OpalUDP Close 2006/11/27 10:24:22.776 0:26.528 ekiga Opal Transport Close 2006/11/27 10:24:22.777 0:26.529 ekiga Opal Deleted transport udp$172.16.100.198:5060 2006/11/27 10:24:22.777 0:26.529 ekiga OpalEP sip endpoint destroyed. 2006/11/27 10:24:22.777 0:26.529 ekiga PCSS Deleted PC sound system endpoint. 2006/11/27 10:24:22.779 0:26.531 ekiga OpalEP pc endpoint destroyed. 2006/11/27 10:24:22.779 0:26.531 ekiga OpalMan Deleted manager. From dbm0572 at yahoo.es Mon Nov 27 09:59:22 2006 From: dbm0572 at yahoo.es (David Ballester Montolio) Date: Mon, 27 Nov 2006 09:59:22 +0000 (GMT) Subject: [Ekiga-list] OT ? Anyone using ekiga on a Dell Inspiron 630m ? Message-ID: <20061127095922.53305.qmail@web26206.mail.ukl.yahoo.com> Hi to all: My system is a Dell Inspiron 630m running Ubuntu Edgy. Before I used Dapper and with both releases I had the same problem with Ekiga ( may be is not Ekiga, but Ekiga fails ), when configuring the audio I can ear noise like pulses, seems 'the sound of circuits', and finally Ekiga crashes or freezes ( dependding on Edgy or Dapper ). May be is needed some type of Alsa extra config, but i've tried to find info about it without luck. This mails is only to know if here havfe people using Ekiga with Ubuntu and Dell Inspiron 630m. If someone is using this combo, any tip will be very apreciated. Thanks and regards D. ______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y m?viles desde 1 c?ntimo por minuto. http://es.voice.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsandras at seconix.com Mon Nov 27 10:02:14 2006 From: dsandras at seconix.com (Damien Sandras) Date: Mon, 27 Nov 2006 11:02:14 +0100 Subject: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?] In-Reply-To: <20061127204756.4F94.CRAIGS@postincrement.com> References: <20061127101517.D63E.CRAIGS@postincrement.com> <1164620521.3775.32.camel@golgoth01> <20061127204756.4F94.CRAIGS@postincrement.com> Message-ID: <1164621734.3830.4.camel@golgoth01> It seems this discussion will lead to nothing, as every side stays on its position. However, let me answer a last time, then I will move to something else. > > > Well, let's forget about that and summarize the results of that > > discussion. There are actually right now 2 problems in OPAL : > > > > 1: Establishing the media streams after having sent or received the ACK > > takes between 1 or 2 seconds during which the media stream is lost. > > This seems to be only a problem on Linux. I'm not seeing this problem on > Windows. > I can see that problem on Windows too. Have you tried reproducing the problem? If so, how? > What is OPAL during the 1 or 2 seconds? Is this how long it takes to > open the sound device on Linux? I'll need more information before I can > work out how to fix the problem > No, it is the time it takes to start the threads, open the device, start the codecs, and so on. You have a debug 4 output, so you can clearly see what happens. > > 2: If OPAL sends an INVITE with 3 codecs in a given order, and that > > Asterisk supports the 3 same codecs but with a different priority order, > > it will send the 200 OK with those 3 codecs in the order it prefers. > > OPAL will then choose the codec it prefers and send the media with that > > codec. It could happen that Asterisk uses another codec from the list, > > ie a codec for which OPAL is not ready to receive a stream. > > > > e.g. : > > INVITE PCMU, iLBC, PCMA > > 200 OK iLBC, PCMA, PCMU > > > > OPAL will send the stream using iLBC. > > Asterisk could decide to send the stream using PCMU. > > However OPAL expects iLBC... > > Replying to an INVITE with more than one codec has a very specific > meaning, and OPAL does not support these semantics. Fortunately, very > few devices seem to do this. Many devices are doing this, including Asterisk which is very popular, believe me. Some popular french ITSP's like Wengo are also working that way, so it is really not so uncommon... -- _ Damien Sandras (o- //\ Ekiga Softphone : http://www.ekiga.org/ v_/_ NOVACOM : http://www.novacom.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsandras at ekiga.net From craigs at postincrement.com Mon Nov 27 10:20:45 2006 From: craigs at postincrement.com (Craig Southeren) Date: Mon, 27 Nov 2006 21:20:45 +1100 Subject: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?] In-Reply-To: <1164621734.3830.4.camel@golgoth01> References: <20061127204756.4F94.CRAIGS@postincrement.com> <1164621734.3830.4.camel@golgoth01> Message-ID: <20061127210437.0E8A.CRAIGS@postincrement.com> On Mon, 27 Nov 2006 11:02:14 +0100 Damien Sandras wrote: ..deleted > > > 1: Establishing the media streams after having sent or received the ACK > > > takes between 1 or 2 seconds during which the media stream is lost. > > > > This seems to be only a problem on Linux. I'm not seeing this problem on > > Windows. > > > > I can see that problem on Windows too. Have you tried reproducing the > problem? If so, how? I've tried calling 411 at Free World Dialup, which I believe is an Asterisk server. If not, or if you know of another accessible Asterisk server I can use for testing, please let me know. I've also made SIP calls between two Windows simpleopal devices with no problems. > > What is OPAL during the 1 or 2 seconds? Is this how long it takes to > > open the sound device on Linux? I'll need more information before I can > > work out how to fix the problem > > No, it is the time it takes to start the threads, open the device, start > the codecs, and so on. > > You have a debug 4 output, so you can clearly see what happens. The delay occurs across these three log messages: 2006/11/27 10:24:10.115 0:13.867 SIP Handle...er:843fa00 OpalCon Selected media stream PCM-16 -> G.711-ALaw-64k 2006/11/27 10:24:11.192 0:14.944 Housekeeper SIP Set state Terminated_Success for transaction 2 INVITE 2006/11/27 10:24:11.198 0:14.950 SIP Handle...er:843fa00 OpalMan OnOpenMediaStream Call[1]-EP[Default],OpalAudioMediaStream-Source-PCM-16 There are no log messages during this one second, so OPAL must be doing something that does not contain logging. Looking at the code, the function that is executed during this time is the virtual function OpalConnection::CreateMediaStream, which is the code that opens the RTP device or the audio device. For a normal audio call, this will be either OpalPCSSConnection::CreateMediaStream or SIPConnection::CreateMediaStream. If you have time, you might try adding some logging to these functions to see what is consuming the time. If it turns out that opening the sound device is consuming the time, we may need to find a way to "pre-open" the audio device prior to making a call. > > > 2: If OPAL sends an INVITE with 3 codecs in a given order, and that > > > Asterisk supports the 3 same codecs but with a different priority order, > > > it will send the 200 OK with those 3 codecs in the order it prefers. > > > OPAL will then choose the codec it prefers and send the media with that > > > codec. It could happen that Asterisk uses another codec from the list, > > > ie a codec for which OPAL is not ready to receive a stream. > > > > > > e.g. : > > > INVITE PCMU, iLBC, PCMA > > > 200 OK iLBC, PCMA, PCMU > > > > > > OPAL will send the stream using iLBC. > > > Asterisk could decide to send the stream using PCMU. > > > However OPAL expects iLBC... > > > > Replying to an INVITE with more than one codec has a very specific > > meaning, and OPAL does not support these semantics. Fortunately, very > > few devices seem to do this. > > Many devices are doing this, including Asterisk which is very popular, > believe me. Some popular french ITSP's like Wengo are also working that > way, so it is really not so uncommon... I will look further at the appropriate RFCs and see what SIP expects to happen. Thanks for the information Craig ----------------------------------------------------------------------- Craig Southeren Post Increment ? VoIP Consulting and Software craigs at postincrement.com.au www.postincrement.com.au Phone: +61 243654666 ICQ: #86852844 Fax: +61 243656905 MSN: craig_southeren at hotmail.com Mobile: +61 417231046 Jabber: craigs at jabber.org "It takes a man to suffer ignorance and smile. Be yourself, no matter what they say." Sting From geboyd53 at comcast.net Mon Nov 27 10:37:42 2006 From: geboyd53 at comcast.net (George Boyd) Date: Mon, 27 Nov 2006 02:37:42 -0800 Subject: [Ekiga-list] ATA or Hardware SIP Phones to use with EKIGA/VoIPBuster In-Reply-To: <1164619856.3775.21.camel@golgoth01> References: <1164452196.8826.8.camel@george> <1164473791.3589.2.camel@golgoth01> <1164544123.19623.3.camel@george> <1164619856.3775.21.camel@golgoth01> Message-ID: <1164623862.32712.9.camel@george> I was afraid of that :( Ekiga is too good and versatile program to not use it. I know that you and all the other people that are working on it are very busy, is there any possibility that that feature may be included in future versions? It was a great idea at the time and I still believe that it would be a fantastic feature for Ekiga. No matter what programs I've played with, I've found nothing yet that performs as good as Ekiga and Ekiga has so many capabilities to do just about everything dealing with SIP and VOIP. I don't want to give up Ekiga because it is so versatile. If you don't mind, I'd like to add that as a feature request. Thanks, George On Mon, 2006-11-27 at 10:30 +0100, Damien Sandras wrote: > Le dimanche 26 novembre 2006 ? 04:28 -0800, George Boyd a ?crit : > > Thanks Damien, I believe you probably know what I'm trying to do. I > > would like to do the same thing as when gnomemeeting could use the > > Quicknet card :) > > Well, with an ATA, you will be able to use your normal phone with a SIP > account, but it is not Ekiga that will control that phone. From dsandras at seconix.com Mon Nov 27 11:33:08 2006 From: dsandras at seconix.com (Damien Sandras) Date: Mon, 27 Nov 2006 12:33:08 +0100 Subject: [Ekiga-list] ATA or Hardware SIP Phones to use with EKIGA/VoIPBuster In-Reply-To: <1164623862.32712.9.camel@george> References: <1164452196.8826.8.camel@george> <1164473791.3589.2.camel@golgoth01> <1164544123.19623.3.camel@george> <1164619856.3775.21.camel@golgoth01> <1164623862.32712.9.camel@george> Message-ID: <1164627188.3830.14.camel@golgoth01> Le lundi 27 novembre 2006 ? 02:37 -0800, George Boyd a ?crit : > I was afraid of that :( Ekiga is too good and versatile program to not > use it. I know that you and all the other people that are working on it > are very busy, is there any possibility that that feature may be > included in future versions? It was a great idea at the time and I still > believe that it would be a fantastic feature for Ekiga. No matter what > programs I've played with, I've found nothing yet that performs as good > as Ekiga and Ekiga has so many capabilities to do just about everything > dealing with SIP and VOIP. I don't want to give up Ekiga because it is > so versatile. If you don't mind, I'd like to add that as a feature > request. > Unfortunately having Ekiga controlling a hardware phone supposes that we have hardware : - either an USB phone - or Quicknet Hardware And Quicknet has gone bankrupt, so there is no hope in that direction. So perhaps supporting USB phone might be an alternative, but I think that it depends more on ALSA supporting it than Ekiga. -- _ Damien Sandras (o- //\ Ekiga Softphone : http://www.ekiga.org/ v_/_ NOVACOM : http://www.novacom.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsandras at ekiga.net From craigs at postincrement.com Mon Nov 27 22:04:27 2006 From: craigs at postincrement.com (Craig Southeren) Date: Tue, 28 Nov 2006 09:04:27 +1100 Subject: [Ekiga-list] [OpenH323]Re: Receiving SIP RTP before media description [was ekiga answers with delay ...?] In-Reply-To: <1164616032.3775.0.camel@golgoth01> References: <20061126231728.02BF.CRAIGS@postincrement.com> <1164616032.3775.0.camel@golgoth01> Message-ID: <20061128090230.E42B.CRAIGS@postincrement.com> On Mon, 27 Nov 2006 09:27:12 +0100 Damien Sandras wrote: ..deleted > > That's not the case. Asterisk just sends audio immediately after it > received the initial INVITE. Just call any echo machine on the net and > you will see the behavior. I've been sent an Ethereal trace from a call that has the 3 second problem and it clearly shows that Asterisk does not send audio until after receiving the ACK. If you have a trace that shows something different, please send it to me. Craig ----------------------------------------------------------------------- Craig Southeren Post Increment ? VoIP Consulting and Software craigs at postincrement.com.au www.postincrement.com.au Phone: +61 243654666 ICQ: #86852844 Fax: +61 243656905 MSN: craig_southeren at hotmail.com Mobile: +61 417231046 Jabber: craigs at jabber.org "It takes a man to suffer ignorance and smile. Be yourself, no matter what they say." Sting From dsandras at seconix.com Mon Nov 27 22:17:57 2006 From: dsandras at seconix.com (Damien Sandras) Date: Mon, 27 Nov 2006 23:17:57 +0100 Subject: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?] In-Reply-To: <20061127101517.D63E.CRAIGS@postincrement.com> References: <2e19719f0611260849o1f0d5202n9da1f6469bb625e4@mail.gmail.com> <2e19719f0611261501l2a8a23f0j142bb3505b9e8c12@mail.gmail.com> <20061127101517.D63E.CRAIGS@postincrement.com> Message-ID: <1164665877.3692.5.camel@golgoth01> Le lundi 27 novembre 2006 ? 10:15 +1100, Craig Southeren a ?crit : > On Mon, 27 Nov 2006 00:01:28 +0100 > "Bent Bagger" wrote: > > > I have uploaded the trace to Savefile.com > > > > http://www.savefile.com/files/293084 > > Thank you for taking the time to do this, because hopefully we can now > move on to solving the actual problem rather than continuing the rather > ridiculous discussion about how to guess the contents of an RTP packet :) > I found out what the problem was... I never really noticed it because I do not use the sound events in Ekiga. However, when using the sound events, there is a dial tone that is played every 3 seconds. That dial tone lasts for about half a second, that is the time during which incoming audio is being lost. I have changed Ekiga so that a dial tone is only played when the remote endpoint signals it is ringing (which is not the case with an echo test). I apologize Craig for having lost your time, but you put me on the right track! Thanks. -- _ Damien Sandras (o- //\ Ekiga Softphone : http://www.ekiga.org/ v_/_ NOVACOM : http://www.novacom.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsandras at ekiga.net From dsandras at seconix.com Mon Nov 27 22:19:31 2006 From: dsandras at seconix.com (Damien Sandras) Date: Mon, 27 Nov 2006 23:19:31 +0100 Subject: [Ekiga-list] [OpenH323]Re: Receiving SIP RTP before media description [was ekiga answers with delay ...?] In-Reply-To: <20061128090230.E42B.CRAIGS@postincrement.com> References: <20061126231728.02BF.CRAIGS@postincrement.com> <1164616032.3775.0.camel@golgoth01> <20061128090230.E42B.CRAIGS@postincrement.com> Message-ID: <1164665971.3692.8.camel@golgoth01> Le mardi 28 novembre 2006 ? 09:04 +1100, Craig Southeren a ?crit : > On Mon, 27 Nov 2006 09:27:12 +0100 > Damien Sandras wrote: > > ..deleted > > > > > That's not the case. Asterisk just sends audio immediately after it > > received the initial INVITE. Just call any echo machine on the net and > > you will see the behavior. > > I've been sent an Ethereal trace from a call that has the 3 second > problem and it clearly shows that Asterisk does not send audio until > after receiving the ACK. > > If you have a trace that shows something different, please send it to me. > You are right, that problem existed with Asterisk before 1.0.x and it doesn't exist anymore. I have spent a part of the evening on the problem and Asterisk only sends audio after having received the ACK or after a timeout if it doesn't receive it. -- _ Damien Sandras (o- //\ Ekiga Softphone : http://www.ekiga.org/ v_/_ NOVACOM : http://www.novacom.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsandras at ekiga.net From craigs at postincrement.com Mon Nov 27 22:16:57 2006 From: craigs at postincrement.com (Craig Southeren) Date: Tue, 28 Nov 2006 09:16:57 +1100 Subject: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?] In-Reply-To: <1164665877.3692.5.camel@golgoth01> References: <20061127101517.D63E.CRAIGS@postincrement.com> <1164665877.3692.5.camel@golgoth01> Message-ID: <20061128091331.E42E.CRAIGS@postincrement.com> On Mon, 27 Nov 2006 23:17:57 +0100 Damien Sandras wrote: ..deleted > I found out what the problem was... I never really noticed it because I > do not use the sound events in Ekiga. > > However, when using the sound events, there is a dial tone that is > played every 3 seconds. That dial tone lasts for about half a second, > that is the time during which incoming audio is being lost. > > I have changed Ekiga so that a dial tone is only played when the remote > endpoint signals it is ringing (which is not the case with an echo > test). This is excellent news :) I am glad the problem is fixed and we can move on to more fixing other problems > I apologize Craig for having lost your time, but you put me on the right > track! It was not lost time. I learnt a lot more about SIP and a serious problem was fixed - that sounds like useful work to me :) BTW: - I noticed from the log file you posted that were lots of SIP messages to do with presence. It certainly looks like you have been busy! Craig ----------------------------------------------------------------------- Craig Southeren Post Increment ? VoIP Consulting and Software craigs at postincrement.com.au www.postincrement.com.au Phone: +61 243654666 ICQ: #86852844 Fax: +61 243656905 MSN: craig_southeren at hotmail.com Mobile: +61 417231046 Jabber: craigs at jabber.org "It takes a man to suffer ignorance and smile. Be yourself, no matter what they say." Sting From sevmek at free.fr Tue Nov 28 17:43:26 2006 From: sevmek at free.fr (yannick) Date: Tue, 28 Nov 2006 18:43:26 +0100 Subject: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?] In-Reply-To: <20061128091331.E42E.CRAIGS@postincrement.com> References: <20061127101517.D63E.CRAIGS@postincrement.com> <1164665877.3692.5.camel@golgoth01> <20061128091331.E42E.CRAIGS@postincrement.com> Message-ID: <1164735806.15438.6.camel@achille> Le mardi 28 novembre 2006 ? 09:16 +1100, Craig Southeren a ?crit : > > I have changed Ekiga so that a dial tone is only played when the > remote > > endpoint signals it is ringing (which is not the case with an echo > > test). > > This is excellent news :) Yes, really. Comparing ekiga with other SIP compliant softwares on this point was bad for ekiga. And your talks were instructive :) Thank you guys ! Regards, Yannick > -- Me joindre en t?l?phonie IP / vid?oconf?rence ? sip:yannick at ekiga.net From jpgroux at gmail.com Tue Nov 28 17:46:49 2006 From: jpgroux at gmail.com (Groux) Date: Tue, 28 Nov 2006 14:46:49 -0300 Subject: [Ekiga-list] Out from your List Message-ID: <459d65b20611280946wd6a3492h853e4911c24c782a@mail.gmail.com> Im out from your List PLEASE -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schampera at web.de Tue Nov 28 18:03:57 2006 From: jan.schampera at web.de (Jan Schampera) Date: Tue, 28 Nov 2006 19:03:57 +0100 Subject: [Ekiga-list] Out from your List In-Reply-To: <459d65b20611280946wd6a3492h853e4911c24c782a@mail.gmail.com> References: <459d65b20611280946wd6a3492h853e4911c24c782a@mail.gmail.com> Message-ID: <20061128190357.56713153@localhost.localdomain> On Tue, 28 Nov 2006 14:46:49 -0300 Groux wrote: > Im out from your List PLEASE With every mail you receive from the listservers, a footer is included with the following URL: http://mail.gnome.org/mailman/listinfo/ekiga-list On that page you can unsubscribe. J. -- Live as if you were to die tomorrow. Learn as if you were to live forever. From afb at paradise.net.nz Wed Nov 29 21:48:23 2006 From: afb at paradise.net.nz (Adam Bogacki) Date: Thu, 30 Nov 2006 10:48:23 +1300 Subject: [Ekiga-list] http://pgk-voip.buildserver.net - still active ? Message-ID: <20061129214823.GD4083@paradise.net.nz> Hi, when trying to install libportaudio0 (a dependency for ethereal & wireshark) via Debian's apt-get dist-upgrade --fix-missing the install hangs at /etc/apt/sources.list entry deb http://pgk-voip.buildserver.net/debian/ sid main Does anyone know if this site is still active ? -- Adam Bogacki, --------------------------------------------------------------------- email: afb(at)paradise.net.nz adam(at)bogacki.net Key: 0x4E553910 - DABB 4963 8973 7CCD 33C0 DC27 D7C5 F516 4E55 3910 --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From Wolfram.Wagner at web.de Wed Nov 29 21:54:14 2006 From: Wolfram.Wagner at web.de (Wolfram Wagner) Date: Wed, 29 Nov 2006 22:54:14 +0100 Subject: [Ekiga-list] STUN registration Message-ID: <200611292254.15814.Wolfram.Wagner@web.de> Hello, I ran into problems which could not be solved by myself... Maybe you know quick answers. Manual, FAQ and Google have been checked already ... My setup: I am connected to Internet via a Fritzbox Surf & Fon2+. It delivers IP-Phone functions and blocks port forwarding to LAN of UDP 5060 to 5063 because they are likely used by this device itself... I guess, this is one of my problems. But at first, I always get timeouts when I try to register. I double checked my account and password on ekiga.net, then configured again and sniffed the traffic, still finding a SIP 404 message (unknown user)... A second problem is: I try to establish a connection to another ekiga in standard setup. This works more or less as long as we use H.323. Picture was fine, but voices have been heavily distorded. My partner is sometimes reaching me in a Donald duck voice, high and much faster as spoken and my voice comes in much slower and deeper... We have already tried different codecs. If we turn of video, sound is better most of the times. Is this because bandwith is not high enough for audio? Restriction video bandwith did not really help. To solve the double use problem of port UDP5060 I had the idear to change ports in control center: Leave TCP1720 leave RTP 5000-5059 change UDP5060-5100 to 5070-5110 change SIP listen port to 5070 In ekiga -d 4 I have seen that the new ports are used, but registration does not work... Please tell me what I am doing wrong! Thank you! Wolfram From dsandras at seconix.com Thu Nov 30 08:46:56 2006 From: dsandras at seconix.com (Damien Sandras) Date: Thu, 30 Nov 2006 09:46:56 +0100 Subject: [Ekiga-list] http://pgk-voip.buildserver.net - still active ? In-Reply-To: <20061129214823.GD4083@paradise.net.nz> References: <20061129214823.GD4083@paradise.net.nz> Message-ID: <1164876416.3652.1.camel@golgoth01> Le jeudi 30 novembre 2006 ? 10:48 +1300, Adam Bogacki a ?crit : > Hi, > > when trying to install libportaudio0 (a dependency for > ethereal & wireshark) via Debian's > > apt-get dist-upgrade --fix-missing > > the install hangs at /etc/apt/sources.list entry > > deb http://pgk-voip.buildserver.net/debian/ sid main > > Does anyone know if this site is still active ? You should use http://snapshots.seconix.com/ -- _ Damien Sandras (o- //\ Ekiga Softphone : http://www.ekiga.org/ v_/_ NOVACOM : http://www.novacom.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsandras at ekiga.net From cannewilson at tiscali.co.uk Thu Nov 30 10:15:46 2006 From: cannewilson at tiscali.co.uk (Anne Wilson) Date: Thu, 30 Nov 2006 10:15:46 +0000 Subject: [Ekiga-list] Protocols and registering accounts Message-ID: <200611301015.53042.cannewilson@tiscali.co.uk> I have registered an account at ekiga.net, which I intend to use to communicate with a friend using GnomeMeeting. However, I also want to communicate with a Win2K use, using NetMeeting. Will I need a separate h.323 account for this? If so, how do I get that? I have seen the 'Register Accounts' screen, but I think that is to be used after an account is created. I know that when I used GnomeMeeting, some time ago, my account was registered at ils.seconix.com. I tried to find a way to do this again by googling, but all results appear to point to GnomeMeeting. Anne -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rpolach at atlas.cz Thu Nov 30 15:19:19 2006 From: rpolach at atlas.cz (Roman Polach) Date: Thu, 30 Nov 2006 16:19:19 +0100 Subject: [Ekiga-list] Message "Registration failed: Timeout" Message-ID: <2c69e06d42064c579f22100d07aa6362@atlas.cz> I have problem with message "Registration failed: Timeout" after I proceed standard first-time druid launch and every next ekiga stratup. I have been registered at ekiga.net successfuly and I can login at its web interface. I have carefully read ekiga docs and faq but did not found the solution. I googled out that possible source of problem may be I am behind two NATs (and three packet-filters -including boxes of these NATs). The first filter+NAT is an ADSL router Well PTI 845G. The second filter+NAT is my gentoo-based router. Third packet-filter runs on my gentoo desktop-box. The first NAT translates between public address space and 10.*.*.* private space. The second NAT translates between 10.*.*.* private space and 168.192.1.* space. I am the only one who use SIP phone on both these private networks and I only want to connect peers on the outer public network. I use gentoo ekiga package: net-im/ekiga-2.0.3 USE="dbus debug gnome sdl -avahi -doc" I have checked that rp_filter value is set to "1" on both inner interface (eth0) and outer interface (wlan0) of the gentoo-router box and also on the only interface of my desktop-box (eth0). I also tried to set ip_conntrack_udp_timeout to 3600 on both of them, but it did not help I am running theese iptables settings: on my desktop-box # iptables -A INPUT -i lo -j ACCEPT # iptables -P INPUT DROP # iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT # iptables -A INPUT -i eth0 -p udp --dport 5000:5100 -j ACCEPT # iptables -A INPUT -i eth0 -p icmp --icmp-type 0 -j ACCEPT # iptables -A INPUT -i eth0 -p icmp --icmp-type 3 -j ACCEPT # iptables -A INPUT -i eth0 -p icmp --icmp-type 8 -j ACCEPT # iptables -A INPUT -i eth0 -p icmp --icmp-type 11 -j ACCEPT # iptables -A INPUT -i eth0 -p tcp --dport 113 -j REJECT # iptables -P OUTPUT ACCEPT and on my gentoo-router box: # iptables -A INPUT -i lo -j ACCEPT # iptables -A INPUT -i eth0 -j ACCEPT # iptables -P INPUT DROP # iptables -A INPUT -i wlan0 -m state --state ESTABLISHED,RELATED -j ACCEPT # iptables -A INPUT -i wlan0 -p icmp --icmp-type 0 -j ACCEPT # iptables -A INPUT -i wlan0 -p icmp --icmp-type 3 -j ACCEPT # iptables -A INPUT -i wlan0 -p icmp --icmp-type 8 -j ACCEPT # iptables -A INPUT -i wlan0 -p icmp --icmp-type 11 -j ACCEPT # iptables -A INPUT -i wlan0 -p tcp --dport 113 -j REJECT # iptables -P OUTPUT ACCEPT # iptables -A FORWARD -i eth0 -j ACCEPT # iptables -P FORWARD DROP # iptables -A FORWARD -i wlan0 -m state --state ESTABLISHED,RELATED -j ACCEPT # iptables -A FORWARD -i wlan0 -p udp --dport 5000:5100 -j ACCEPT # iptables -A FORWARD -i wlan0 -p icmp --icmp-type 0 -j ACCEPT # iptables -A FORWARD -i wlan0 -p icmp --icmp-type 3 -j ACCEPT # iptables -A FORWARD -i wlan0 -p icmp --icmp-type 8 -j ACCEPT # iptables -A FORWARD -i wlan0 -p icmp --icmp-type 11 -j ACCEPT # iptables -A FORWARD -i wlan0 -p tcp --dport 113 -j REJECT # iptables -t nat -I POSTROUTING -o wlan0 -j MASQUERADE and I have also set to allow 5000:5100 udp ports on my ADSL router (Well PTI 845G) Note 1: accepting all types of ICMP did not help... Note 2: Ekiga detects "Port restricted NAT", so I confirm STUN... If I set port forwarding on both NATs it did not help... only it detects "Cone NAT" instead of "Port restricted NAT" and no success with or without STUN enabled... Note 3: I have also tried to add an "ekiga.net" account information manually to Accounts dialog, but I also see "Registration failed" in this dialog after few seconds. Note 4: "ekiga -d 4" shows this: 2006/11/30 11:25:05.983 0:00.472 ekiga Detected audio plugins: ALSA 2006/11/30 11:25:05.984 0:00.472 ekiga Detected video plugins: Picture,V4L,V4L2 2006/11/30 11:25:05.984 0:00.472 ekiga Detected audio plugins: ALSA 2006/11/30 11:25:05.984 0:00.472 ekiga Detected video plugins: Picture,V4L,V4L2 2006/11/30 11:25:06.000 0:00.488 ekiga Detected the following audio input devices: SB Live [Unknown],Default with plugin ALSA 2006/11/30 11:25:06.000 0:00.488 ekiga Detected the following audio output devices: SB Live [Unknown],Default with plugin ALSA 2006/11/30 11:25:06.000 0:00.488 ekiga Detected the following video input devices: StaticPicture,MovingLogo with plugin Picture 2006/11/30 11:25:06.000 0:00.488 ekiga Detected the following audio input devices: SB Live [Unknown],Default with plugin ALSA 2006/11/30 11:25:06.000 0:00.488 ekiga Detected the following audio output devices: SB Live [Unknown],Default with plugin ALSA 2006/11/30 11:25:06.000 0:00.489 ekiga Detected the following video input devices: StaticPicture,MovingLogo with plugin Picture (ekiga:25369): gnome-vfs-modules-WARNING **: Could not initialize inotify 2006/11/30 11:25:06.917 0:01.406 ekiga Ekiga version 2.0.3 2006/11/30 11:25:06.926 0:01.415 ekiga OPAL version 2.2.3 2006/11/30 11:25:06.932 0:01.421 ekiga PWLIB version 1.10.2 2006/11/30 11:25:06.938 0:01.427 ekiga GNOME support enabled 2006/11/30 11:25:06.944 0:01.432 ekiga Fullscreen support enabled 2006/11/30 11:25:06.949 0:01.438 ekiga DBUS support enabled 2006/11/30 11:25:06.960 0:01.449 ekiga Set TCP port range to 30000:30010 2006/11/30 11:25:06.968 0:01.457 ekiga Set RTP port range to 5000:5059 2006/11/30 11:25:06.976 0:01.465 ekiga Set UDP port range to 5060:5100 no other output is generated by the time message "Registration failed: Timeout" appears in statusbar of ekiga gui. Thanks for any information how to get this work, maybe I will have to unify these two private networks together and connect directly from my desktop-box to ADSL router. From jan.schampera at web.de Thu Nov 30 16:31:12 2006 From: jan.schampera at web.de (Jan Schampera) Date: Thu, 30 Nov 2006 17:31:12 +0100 Subject: [Ekiga-list] Protocols and registering accounts In-Reply-To: <200611301015.53042.cannewilson@tiscali.co.uk> References: <200611301015.53042.cannewilson@tiscali.co.uk> Message-ID: <20061130173112.3a6100c1@localhost.localdomain> On Thu, 30 Nov 2006 10:15:46 +0000 Anne Wilson wrote: > I have registered an account at ekiga.net, which I intend to use to > communicate with a friend using GnomeMeeting. However, I also want > to communicate with a Win2K use, using NetMeeting. Will I need a > separate h.323 account for this? If so, how do I get that? Regardless firewall nightmare: h323: You can register to a so-called gatekeeper service, but I don't know a public service in the dimensions of the common SIP services off from head. Maybe Damien knows one? J. -- God is real... unless declared as integer. From cannewilson at tiscali.co.uk Thu Nov 30 17:09:21 2006 From: cannewilson at tiscali.co.uk (Anne Wilson) Date: Thu, 30 Nov 2006 17:09:21 +0000 Subject: [Ekiga-list] Protocols and registering accounts In-Reply-To: <20061130173112.3a6100c1@localhost.localdomain> References: <200611301015.53042.cannewilson@tiscali.co.uk> <20061130173112.3a6100c1@localhost.localdomain> Message-ID: <200611301709.21347.cannewilson@tiscali.co.uk> On Thursday 30 November 2006 16:31, Jan Schampera wrote: > On Thu, 30 Nov 2006 10:15:46 +0000 > > Anne Wilson wrote: > > I have registered an account at ekiga.net, which I intend to use to > > communicate with a friend using GnomeMeeting. However, I also want > > to communicate with a Win2K use, using NetMeeting. Will I need a > > separate h.323 account for this? If so, how do I get that? > > Regardless firewall nightmare: I remember well that the main problem we had when we both used GnomeMeeting, long ago, was a firewall problem. I'm not saying that I've got it right yet, but I'm aware of it :-) > h323: That sounds easy enough. > You can register to a so-called gatekeeper service, I don't realy understand where the gatekeeper service fits in. Any recommended reading on that? > but I don't know a > public service in the dimensions of the common SIP services off from > head. > Maybe Damien knows one? > Thanks for answering Anne -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: