Re: [Ekiga-list] Bad frequency response with Ekiga

[Craig Southeren]

Thanks for taking the time do this analysis and share the results!

The Ekiga output is definitely showing a filtered response. The only 
filter in the audio chain is the Automatic Echo Cancellation - did you 
have that enabled when doing the measurements?


This would certainly explain the output.

   Craig

On 5/05/2013 6:49 AM, geo cherchetout wrote:

Hello,

Using Ekiga v.3.9.90 and the line input of his soundcard, and PCMA
codec, Foo sends white noise to Bar who receives and records this sound
with Linphone v.3.5.99.0. (Recent versions of Linphone make recording
easy, the recorded sound being extracted from rtp streams, not from
soundcard.)
Then, using Audacity, Bar displays the spectrum of the recorded sound.
You can see it here: http://pix.toile-libre.org/?img=1367698438.png

Now, the same experiment is made with Foo and Bar using the same
Linphone v.3.5.99.0 softphone, and the spectrum is much better as you
can see there:
http://pix.toile-libre.org/?img=1367698567.png

Perhaps there is something like a wrong equation in Ekiga's or some
library's code ? Or this is a feature and not a bug ?
I am able to compile Ekiga but not to modify the code by myself...

___
ekiga-list mailing list
ekiga-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-list



--

-------
 Craig Southeren  Post Increment – VoIP Consulting and Software
 cra...@postincrement.com.au   www.postincrement.com.au

 Mobile: +61 417231046G+: craig.southe...@gmail.com
 US: +1 415 800 4201   MSN: craig_southe...@hotmail.com

"Science is the poetry of reality." Richard Dawkins
___
ekiga-list mailing list
ekiga-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] Welcome Victoria !

[Craig Southeren]

Congratulations!

   Craig

On 10/04/2012 9:07 PM, Damien Sandras wrote:

Dear all,


This is a little mail to inform you that I am the happy father of a little girl 
named Victoria.

She is born (5 weeks earlier than foreseen) on Sunday (Easter) at 8 am.

The mother is going fine and the father is happy !

Damien


___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list



--

---
 Craig Southeren  Post Increment – VoIP Consulting and Software
 cra...@postincrement.com.au   www.postincrement.com.au

 Phone:  +61 243654666  ICQ: #86852844
 Fax:+61 243656905  MSN: craig_southe...@hotmail.com
 Mobile: +61 417231046  Jabber: cra...@jabber.org

 "Science is the poetry of reality." Richard Dawkins
___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] Screencast video?

[Craig Southeren]

On 26/10/2011 1:34 AM, Eugen Dedu wrote:

On 05/10/11 19:17, OJ W wrote:

Ekiga on WindowsXP: Is it possible to use a screencast of your desktop
as the video source? (like netmeeting's "Desktop sharing" feature)


Sorry to answer so late. It is not possible, see 
https://bugzilla.gnome.org/show_bug.cgi?id=651544


Just so you know, PTLib has a window capture device on Windows. Adding 
one for XWindows would not be difficult.


With this, the above functionality could be implemented.

Craig

--

-------
 Craig Southeren  Post Increment – VoIP Consulting and Software
 cra...@postincrement.com.au   www.postincrement.com.au

 Phone:  +61 243654666  ICQ: #86852844
 Fax:+61 243656905  MSN: craig_southe...@hotmail.com
 Mobile: +61 417231046  Jabber: cra...@jabber.org

 "Science is the poetry of reality." Richard Dawkins

___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] Disconnect after about 30 sec

[Craig Southeren]

On 15/06/2011 11:39 AM, David Halliday wrote:

One more data point, I have also downloaded Ekiga 3.3.0 for XP and it shows the 
same problem of disconnecting after about 30 seconds so I don't suspect the 
Redhat OS from the previous post.


A quick look at the logs shows that it was the Tandberg that dropped the call.
So, we have to determine why it might do this.

Dropouts near the 30 second mark are sometimes due to one end dropping the call 
because they have not received media.
This may be due to a codec mismatch, or a NAT problem, or even lack of support 
for RTCP.

I would start with a simple call, say G.711 only, and see if that works.
If it does, try adding video but use low bandwidth and try different codecs.
Note that the Opal H.261 codec is very, very simple-minded. It could well be 
that it is too simple for the other end :)

   Craig


---
 Craig Southeren  Post Increment – VoIP Consulting and Software
 cra...@postincrement.com.au   www.postincrement.com.au

 Phone:  +61 243654666  ICQ: #86852844
 Fax:+61 243656905  MSN: craig_southe...@hotmail.com
 Mobile: +61 417231046  Jabber: cra...@jabber.org

 "Science is the poetry of reality." Richard Dawkins
___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] Modifying sent SDP data?

[Craig Southeren]

These kinds of questions are better asked on the Opal list 
(opalv...@sourceforge.net) which is the SIP library used by Ekiga.


There is a way to set arbitrary headers in the outgoing SIP using URL 
options. I can't remember the exact syntax - robe...@voxlucida.com.au 
will be able to help you.


   Craig

On 30/05/2011 8:34 AM, Tiberiu Breana wrote:
Thanks for your reply. I've browsed almost all the sources and 
couldn't find anything related to packet construction. Where exactly 
can I find this?



There is no config file.  You need to modify opal library.  See
the ekiga wiki for how to compile ptlib, opal and ekiga.
-- 
Eugen

___
ekiga-list mailing list
ekiga-list@gnome.org 
http://mail.gnome.org/mailman/listinfo/ekiga-list



___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list


___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] 16:9 aspect ratio

[Craig Southeren]

On 8/02/2011 12:15 PM, Andreas Weisker wrote:

Hi all,

does anyone know if there are plans to add support for 16:9 aspect 
ratio? I am using a HD camera over a HDMI capture card and it is not 
possible to get 4:3 out of that. Ekiga presses the 16:9 image in 4:3 
and everyone get eggheads. 720x405 should be easy to support if i am 
right, that this resolution must be only included in the list.
By the way, HD resolutions were also very interesting, but i read that 
there are problems inside libopal that prevents using them.
There's nothing inside Opal that prevent you from using any resolution 
or aspect ratio. It's a matter of choosing the correct codecs - not all 
codecs support all resolutions or aspect rations.


   Craig

___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] question of using Ekiga to KEK (fwd)

[Craig Southeren]

Joseph Comfort wrote:
Unfortunately, I have not found much in the way of good H323 alternatives 
to Ekiga.  There are alternatives for SIP.  I'm only a user, but it seems 
to me that Ekiga has gone too far out on the bleeding edge with all kinds 
of frilly add-ons which depend on OS systems and packages (even compilers) 
that are still in development.  Maintenance of the core functionality is 
drowning.  I have not yet had a successful compilation of the latest 
source.  Still, the basic issue may be in the audio stuff of the OS.


H.323 is still very actively maintained in the Opal library.

If you are having problems with H.323, please let us know on the Opal 
list (see www.opalvoip.org)


   Craig
--

---
 Craig Southeren  Post Increment – VoIP Consulting and Software
 cra...@postincrement.com.au   www.postincrement.com.au

 Phone:  +61 243654666  ICQ: #86852844
 Fax:+61 243656905  MSN: craig_southe...@hotmail.com
 Mobile: +61 417231046  Jabber: cra...@jabber.org

 "Science is the poetry of reality." Richard Dawkins
___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] Ekiga website

[Craig Southeren]

You can also try the Opal SVN browser at

http://www.opalvoip.org/websvn/listing.php?repname=Opal&path=%2F&sc=0

   Craig

Sent from my iPhone

On 06/06/2009, at 6:31 AM, Eugen Dedu fcomte.fr> wrote:



michel memeteau wrote:

HI
On Sun, May 17, 2009 at 8:33 PM, Eugen Dedu 
wrote:
Which one should she click on? How much further do you think she is

going to get?


I agree with you.  The problem is that we are still in the middle of
transition having started long ago.  www.ekiga.org is more  
beautiful and
only one person can change it (so secure), but nearly all the  
pages are
obsolete, while wiki.ekiga.org has practically all the information  
(and is
community-based).  Someone proposed to change mediawiki in drupal  
(in the
wiki site) and integrate www.ekiga.org web site too.  That would  
finish

the transition and all the problems.
Of course, you are free to comment on the wiki web site too :o)

I just wanted someone to download the latest ekigaWin32 and point  
him  to

ekiga.org .
But the only downlodable think on the website are the sources for  
each 3.2.X

release .


No...  On wiki, choose Download for window, and you have the latest  
"official" binary.


Ekiga is a great software but the website is really important as  
people

won't look furtther to find it .


Right...

there i only one admin access ? Why not share it so at least a  
current

release for each platform is on the website ?
Or link the download to the wiki page 


I propose to use the wiki for all the downloads.  Downloads mean:  
binaries, and sources.


- sources: no problem, it's already done
- binaries: what to do?  We cannot create binaries for each/several  
distributions with each ekiga release.  So someone thought to put at  
Downloads page information about how to install latest ekiga on that  
platform.


--
Eugen
___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] News on debian snapshots

[Craig Southeren]

Eugen Dedu wrote:

Hi,

Information about the following debian snapshot packages:

1. DC and AVC plugins in ptlib are not provided anymore.  debian has 
changed the version of raw1394 (and other libraries), and these two 
ptlib plugins are not compatible with this new version.


2. The non-free codecs h263+, mpeg-4 and h264 need an older ffmpeg 
(http://www.nabble.com/Can't-compile-opal-with-avcodec-td21097280.html) 
than debian and debian-multimedia offer, so they are not provided 
anymore either.  You can use theora instead :o)


Of course, when the compatibility is restored, these packages come back.


The H.263/H.263+ plugin works with the latest FFMpeg (I haven't tried 
ffmpeg 0.5)


   Craig

-------
 Craig Southeren  Post Increment – VoIP Consulting and Software
 cra...@postincrement.com.au   www.postincrement.com.au

 Phone:  +61 243654666  ICQ: #86852844
 Fax:+61 243656905  MSN: craig_southe...@hotmail.com
 Mobile: +61 417231046  Jabber: cra...@jabber.org

 "Science is the poetry of reality." Richard Dawkins

___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] A comparison ALSA-PULSE (long, addendum)

[Craig Southeren]

To all

I have just noticed this thread. I wish someone had posted it on the 
Opal list, where Robert and I might have noticed it earlier :)


We are currently planning to add a new audio and video device plugin 
interface to Opal. This new multimedia device interface will be similar 
to the current codec API (allowing plugins to be written without PTLib) 
and will support additional functionality such as:


- support for devices that offer encoded media (such as pre-encoded video)

- support for devices that offer both audio and video.

One of the first plugins I intend to write is a new Pulse audio plugin, 
because Fedora uses pulseaudio by default, and I am sick of audio not 
working without lots of changes :)


I'd welcome comments from anyone on these plans

   Craig

Derek Smithies wrote:

Hi,

Perhaps it's PTLib underneath it? I really don't know, I'm just throwing
the idea out there!


 It is PTLib which contains the code to read from alsa.

Surely, the ideal is not to go via ALSA, but have ptlib directly talk to 
pulse. Thus, we need to write a ptlib plugin for pulse audio.


We know how ptlib plugins work. There are example plugins for alsa, esd, 
oss, sunaudio. The big question is writing a plugin for pulse.


What is involved in writing code that talks directly to pulse ?
Anyone know example code, or of the pulse api docs?

Please don't refer me to docs which say "just use alsa code". We are 
using alsa code, and that is why we are having this issue.


Derek.



--

-------
 Craig Southeren  Post Increment – VoIP Consulting and Software
 cra...@postincrement.com.au   www.postincrement.com.au

 Phone:  +61 243654666  ICQ: #86852844
 Fax:+61 243656905  MSN: craig_southe...@hotmail.com
 Mobile: +61 417231046  Jabber: cra...@jabber.org

 "Science is the poetry of reality." Richard Dawkins
___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] Roadmap for Ekiga 3.00?

[Craig Southeren]

Damien Sandras wrote:

Le mardi 29 juillet 2008 à 10:10 -0400, Praedor Atrebates a écrit :

On Tuesday 29 July 2008 10:03:55 Damien Sandras wrote:

Le mardi 29 juillet 2008 à 09:51 -0400, Praedor Atrebates a écrit :

On Tuesday 29 July 2008 09:46:04 Damien Sandras wrote:

Le mardi 29 juillet 2008 à 09:43 -0400, Praedor Atrebates a écrit :

On Tuesday 29 July 2008 09:36:37 Rene Bartsch wrote:

Hi,

how's the current state of upcoming version 3.00? About when will a
stable version be available?

Will it have full IAX2 support?

Or how about zrtp support?

No ZRTP support for 3.00.

Hmpf.

What is the issue with this lib?  Why is it so particularly difficult
when a bunch of other similar voip apps already include it?

I'm curious.

Nothing. Do you want to finish the work ?

I wish I could.


Those of us who maintain Opal are working with the creators of ZRTP to 
ensure a trouble-free and complete integration of the ZRTP library.


Once this is done, I am sure Damien (or someone else) will have no 
problems adding the GUI extras needed to make it work in Ekiga.


As always, it is an issue of time, priorites and resources, not of 
desire or ability :)


   Craig

-------
 Craig Southeren  Post Increment – VoIP Consulting and Software
 [EMAIL PROTECTED]   www.postincrement.com.au

 Phone:  +61 243654666  ICQ: #86852844
 Fax:+61 243656905  MSN: [EMAIL PROTECTED]
 Mobile: +61 417231046  Jabber: [EMAIL PROTECTED]

 "Science is the poetry of reality." Richard Dawkins
___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] Fwd: Re: ekiga fails to use sound card, other apps do, config help?

[Craig Southeren]

Steve Ames wrote:

..deleted

>> How could I have access to the pwlib in CVS? I followed what the page 
>> http://www.openh323.org/cvs.html says but get connection refused:
> 
> openh323.org has been a dead-ish site for years. pwlib and openh323 were
> hosted at voxgratia for a while until the developers had a disagreement
> and split the projects into h323plus and opal. pwlib has been renamed
> ptlib in the new order. 
> 
> See: http://www.h323plus.org/ for the latest h323 code
> http://www.opalvoip.org/ for the latest opal and pwlib/ptlib
> 
> Both run their CVS off sourceforge now I believe.

I would like to add some clarification to the above. :)

openh323.org is indeed dead, and has been for many years.

voxgratia.org was the home of both the Opal and OpenH323 projects for 
several years while certain issues were being resolved. During that 
time, the founders of OpenH323 were able to move their focus to OPAL.

We were finally able to move OPAL into it's own project at openvoip.org 
late last year. As part of that move, pwlib was renamed ptlib and the 
OPAL source was migrated from CVS to Subversion.

Some of the people who are passionate about OpenH323 wanted to keep it 
alive, and chose to do so at h323plus.org. As far as I know, there is no 
disagreement - they still uses the ptlib from OPAL.

Everyone is welcome to come join us at opalvoip.org :)

Craig

-------
  Craig Southeren  Post Increment – VoIP Consulting and Software
  [EMAIL PROTECTED]   www.postincrement.com.au

  Phone:  +61 243654666  ICQ: #86852844
  Fax:+61 243656905  MSN: [EMAIL PROTECTED]
  Mobile: +61 417231046  Jabber: [EMAIL PROTECTED]

  "Science is the poetry of reality." Richard Dawkins

___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] Dialpad keys for remote control?

[Craig Southeren]

David Todd wrote:

..deleted

>> Ah, is it H.323 based ?
>>   
> 
>Yes, at least the mode I'm using.

The protocol needed is H.224, which is fully supported by OPAL over H.323.

The next release of OPAL will support H.224 over SIP and H.323

Craig

-------
  Craig Southeren  Post Increment – VoIP Consulting and Software
  [EMAIL PROTECTED]   www.postincrement.com.au

  Phone:  +61 243654666  ICQ: #86852844
  Fax:+61 243656905  MSN: [EMAIL PROTECTED]
  Mobile: +61 417231046  Jabber: [EMAIL PROTECTED]

  "Science is the poetry of reality." Richard Dawkins

___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] Setting RFC2833 in H.323

[Craig Southeren]

Fergus Kernan wrote:
> Hi,
> 
> Is it possible to force EKIGA to use only RFC2833 on H323 connections?
> It seems it will advertise it's capability as any of the H245 methods
> but will not use RFC2833 when selected in the H323 settings. I am trying
> to simulate a Nextone which will only use RFC2833 working in an Asterisk
> gateway using OH323 setup for RFC2833 --  it seems that Ekiga will
> always select the H245 methods for UserInputCapability on the H225
> channel rather than reading it's own capability setting (RFC2833) and is
> not sending the DTMF as NetworkTelphonyEvents in the RTP path. As of
> H323 version 4 RTP NTE (RFC2833) is an acceptable method for sending
> DTMF. Thanks for in advance for any guidance 

OPAL has support for RFC2833 in both H.323 and SIP. I'm not sure if 
Ekiga has the ability to enable this.

Craig

-------
  Craig Southeren  Post Increment – VoIP Consulting and Software
  [EMAIL PROTECTED]   www.postincrement.com.au

  Phone:  +61 243654666  ICQ: #86852844
  Fax:+61 243656905  MSN: [EMAIL PROTECTED]
  Mobile: +61 417231046  Jabber: [EMAIL PROTECTED]

  "Science is the poetry of reality." Richard Dawkins
___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] Slideshow broadcasting

[Craig Southeren]

Jason Dixon wrote:
> [ Resending to the list... ]
> 
> We're looking to improve on our broadcasts for the MetaBUG (http:// 
> metabug.org), as well as possible future Linux/BSD conferences.  One  
> of our members mentioned Ekiga, but I wasn't able to determine if it  
> met all of our feature needs.  Here are the features we're looking for:
> 
> - FOSS
> - Runs on *BSD
> - Audio/Video streaming to QTSS
> - Video capture of presenter's screen (slides)
> 
> We've been using QuickTime Broadcaster on OS X to stream A/V capture  
> from my DV camera.  To be blunt, this method sucks (the capture part,  
> not the streaming part).  Ideally we want to take the slides directly  
> off the presenter's laptop and stream it with audio from an external  
> mic.  I've found a commercial offering (http://www.varasoftware.com/ 
> products/wirecast/) that does this, but the price hurts and it only  
> runs on Windows/Mac.

We're working on an OPAL based solution for this problem.

Hannes Friedreich has implemented the ability have multiple video 
streams with a single call, which is necessary for sending both video 
and application capture. This code will be integrated into the CVS head 
after the next stable release (in the next few weeks).

I am working on an MCU which will allow this data to be shared amongst 
multiple callers.

It's all just a matter of time :)

Craig

---
  Craig Southeren  Post Increment – VoIP Consulting and Software
  [EMAIL PROTECTED]   www.postincrement.com.au

  Phone:  +61 243654666  ICQ: #86852844
  Fax:+61 243656905  MSN: [EMAIL PROTECTED]
  Mobile: +61 417231046  Jabber: [EMAIL PROTECTED]

  "Science is the poetry of reality." Richard Dawkins
___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] G729 codec

[Craig Southeren]

Michael wrote:
> 
> Damien and Craig:
> 
> Can I donate X amount so that Ekiga can be certified to work
> 'optimally' with G729 via Asterisks on Xubuntu?
> 
> Currently I see that there are several comments of the
> community members trying to get it to work. For example, Jure Petrovic code is
> posted, but we cannot use it if it is not optimal. We need to be sure it is
> supported so that as new versions of Asterisks, Ekiga and Xubuntu will 
> function
> in the future. In addition a simplified installation method would be a big 
> plus.
> 
> Conclusion, how much would we need to donate so that there
> is a version issued by the Ekiga community? It would support G729 via 
> Asterisks
> on Xubuntu assuming proper licenses are purchased.

Are you saying that you want to use the Asterisk G.729 license with 
Ekiga? This is not possible, for legal reasons.

It is definitely possible to implement G.729 as a plugin codec for OPAL 
that will work with Asterisk. This will be available once the IPP codec 
package is releases.

Craig


-------
  Craig Southeren  Post Increment -- VoIP Consulting and Software
  [EMAIL PROTECTED]   www.postincrement.com.au

  Phone:  +61 243654666  ICQ: #86852844
  Fax:+61 243656905  MSN: [EMAIL PROTECTED]
  Mobile: +61 417231046  Jabber: [EMAIL PROTECTED]

  "Science is the poetry of reality." Richard Dawkins
___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] G729 codec

[Craig Southeren]

Jure Petrovic wrote:
> 
> The problem with my version is, that I cannot set the number of audio
> frames that are wrapped in the RTP packet. My code always sends 1 audio
> frame (= 10 msec), eventhough my setting says two or three. 
> 
> I couldn't fix it yet, because I don't know some things about OPAL and I
> haven't had the time to check the OPAL code.
> 
> Silently, I was hoping that Craig would check it, to see if codec info
> structure is correctly set up :)
> 
> Besides appearing a little bit asymmetrical, I haven't encountered any
> other troubles ;)

Correct handling of the SIP ptime argument is one of the specific 
features that we need to add to OPAL for the next release.

Craig

-------
  Craig Southeren  Post Increment – VoIP Consulting and Software
  [EMAIL PROTECTED]   www.postincrement.com.au

  Phone:  +61 243654666  ICQ: #86852844
  Fax:+61 243656905  MSN: [EMAIL PROTECTED]
  Mobile: +61 417231046  Jabber: [EMAIL PROTECTED]

  "Science is the poetry of reality." Richard Dawkins
___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] State of ZRTP integration?

[Craig Southeren]

Damien Sandras wrote:
> Le dimanche 10 juin 2007 à 14:58 +0200, Rene Bartsch a écrit :

> Hi,
> > how is the current state of ZRTP integration into Ekiga?
> I think it is stalled...--  

No, it is not stalled.

I have spent a lot of time with Phil Zimmermann over the past few months 
to ensure that the ZRTP toolkit is available as an Open Source project 
for OPAL and Ekiga users. This is now done, and Phil's SDK is now 
available under an Open Source license that will allow it to be used by 
Ekiga.

The ZRTP toolkit has been integrated into the OPAL RTP stack and compile 
system. I've been using SRTP (which is the underlying protocol for ZRTP) 
with OPAL for many months and it works great.

The next step is to provide an API within OPAL that applications can use 
to manage ZRTP sessions. I exchanged emails yesterday with one of the 
ZRTP developers and they will be working on this.

Craig

-------
  Craig Southeren  Post Increment – VoIP Consulting and Software
  [EMAIL PROTECTED]   www.postincrement.com.au

  Phone:  +61 243654666  ICQ: #86852844
  Fax:+61 243656905  MSN: [EMAIL PROTECTED]
  Mobile: +61 417231046  Jabber: [EMAIL PROTECTED]

  "It takes a man to suffer ignorance and smile.
   Be yourself, no matter what they say."   Sting
___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] video regression in SVN?

[Craig Southeren]

Damien Sandras wrote:
> Le dimanche 20 mai 2007 à 22:23 +0200, Palo S. a écrit :
>> There is no video, just a completely green image from my webcam in SVN 
>> snapshot from 20-05-2007. The webcam is Labtec webcam Pro with gspca driver, 
>> working great under stable versions of Ekiga (2.0.9 and before) as well as 
>> under other V4L software. 
> 
> Possibly.
> 
> Recent changes were done in the video code in the SVN, and since then my
> camera does not work anymore in small size either.
> 
> I do not understand what could cause the problem. Perhaps Craig can
> tell. 
> 
> Craig, a few people have problems since the video code has been
> reorganized in the SVN, any pointer ?
> 

We'll need to get Robert involved, as he did the reorganisation.

I've cc'ed him on this message

Craig

---
  Craig Southeren  Post Increment – VoIP Consulting and Software
  [EMAIL PROTECTED]   www.postincrement.com.au

  Phone:  +61 243654666  ICQ: #86852844
  Fax:+61 243656905  MSN: [EMAIL PROTECTED]
  Mobile: +61 417231046  Jabber: [EMAIL PROTECTED]

  "It takes a man to suffer ignorance and smile.
   Be yourself, no matter what they say."   Sting

___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] feature wish: recording the conversation

[Craig Southeren]

Ma Begaj wrote:
> Hi,
> 
> I just had a few conversations with Ekiga and there is on option which
> I really needed today: recording a conversation.
> 
> The person I called told me a lot of numbers and data, and it would
> have really nice if there would be a small record button in the main
> GUI.

I'm working on this function in OPAL. I'm sure Damien will make it 
available in Ekiga when I am done.

Craig

---
  Craig Southeren  Post Increment – VoIP Consulting and Software
  [EMAIL PROTECTED]   www.postincrement.com.au

  Phone:  +61 243654666  ICQ: #86852844
  Fax:+61 243656905  MSN: [EMAIL PROTECTED]
  Mobile: +61 417231046  Jabber: [EMAIL PROTECTED]

  "It takes a man to suffer ignorance and smile.
   Be yourself, no matter what they say."   Sting

___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] G729 codec

[Craig Southeren]

Jure Petrovic wrote:

..deleted

> Nevertheless, there is one thing...I do not know how to set
> number of frames per RTP packet and my codec always sends 1 frame 
> per packet (10 milliseconds), whereas asterisk always sends 2
> frames/packet (20 millisces). Audio works great, it's just not optimal
> for bandwidth usage...

The codec advertises the recommended number of frames per packet in the 
plugin tables. OPAL will then negotiate the correct number of frames 
with the remote end, and then use that number to ensure the correct 
amount of PCM data gets sent to the codec.

The encoder function should consume the maximum amount of PCM data and 
generate output frames appropriately.

> I have asked Damien and Craig couple of times how to set number of
> packets in Ekiga, but I just don't get an answer. Maybe they don't 
> like messing with "unclean" code in ekiga. However, my this is plugin
> anyway and doesn't have to be included with other software...

I guess I missed the emails :)

   Craig


-------
  Craig Southeren  Post Increment – VoIP Consulting and Software
  [EMAIL PROTECTED]   www.postincrement.com.au

  Phone:  +61 243654666  ICQ: #86852844
  Fax:+61 243656905  MSN: [EMAIL PROTECTED]
  Mobile: +61 417231046  Jabber: [EMAIL PROTECTED]

  "It takes a man to suffer ignorance and smile.
   Be yourself, no matter what they say."   Sting

___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

[Ekiga-list] OPAL/OpenH323 mailing list is being moved

[Craig Southeren]

To all,

Many of you may have noticed that the OPAL/OpenH323 mailing list has 
been very quiet lately. The list is being moved over to SourceForge, but 
  the SF has been very slow in processing the request to add the old 
subscribers.

Until this happens, please feel free to subscribe to the lists as 
described at:

  http://sourceforge.net/mail/?group_id=80674

   Craig

---
  Craig Southeren  Post Increment – VoIP Consulting and Software
  [EMAIL PROTECTED]   www.postincrement.com.au

  Phone:  +61 243654666  ICQ: #86852844
  Fax:+61 243656905  MSN: [EMAIL PROTECTED]
  Mobile: +61 417231046  Jabber: [EMAIL PROTECTED]

  "It takes a man to suffer ignorance and smile.
   Be yourself, no matter what they say."   Sting

___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] Feature request: ZRTP support

[Craig Southeren]

On Mon, 26 Feb 2007 18:50:26 +0100 (CET)
"Rene Bartsch" <[EMAIL PROTECTED]> wrote:

> 
> Hi,
> 
> could you please add ZRTP support to Ekiga?

I'm working on ZRTP integration into OPAL. I'm hoping to have it
finished in the next few weeks.

Please be patient :)
 
> There is a SDK at http://zfoneproject.com/prod_sdk.html.
> But I don't know which license will be available for OSS projects.

I'm talking with Phil Zimmermann (the creator of ZRTP) and the license
issues will be resolved by the time the integration is complete

   Craig

-------
 Craig Southeren  Post Increment – VoIP Consulting and Software
 [EMAIL PROTECTED]   www.postincrement.com.au

 Phone:  +61 243654666  ICQ: #86852844
 Fax:+61 243656905  MSN: [EMAIL PROTECTED]
 Mobile: +61 417231046  Jabber: [EMAIL PROTECTED]

 "It takes a man to suffer ignorance and smile.
  Be yourself, no matter what they say."   Sting


___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] CVS version compiles ok, but problems connecting

[Craig Southeren]

On Tue, 20 Feb 2007 12:17:07 -0800
George Boyd <[EMAIL PROTECTED]> wrote:

> 
> > the command is thread apply all bt (sorry).
> > 
>  I should have known that :)
> 
> Here's the output:

...deleted

This backtrace showed me exactly where I had made my mistake :(

I've checked in a fix for the problem into the OPAL CVS

My apologies to all for the time wasted

   Craig

-------
 Craig Southeren  Post Increment – VoIP Consulting and Software
 [EMAIL PROTECTED]   www.postincrement.com.au

 Phone:  +61 243654666  ICQ: #86852844
 Fax:+61 243656905  MSN: [EMAIL PROTECTED]
 Mobile: +61 417231046  Jabber: [EMAIL PROTECTED]

 "It takes a man to suffer ignorance and smile.
  Be yourself, no matter what they say."   Sting


___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] Let's spread Ekiga : volunteers ?

[Craig Southeren]

On Tue, 20 Feb 2007 20:23:58 +0100
Damien Sandras <[EMAIL PROTECTED]> wrote:

> Le mardi 20 février 2007 à 18:39 +0100, Jure Petrovic a écrit :
> > On Tue, 2007-02-20 at 11:14 +0100, Damien Sandras wrote:
> > > If it tells you you do not have 2.3.2, then you do not have 2.3.2
> > > installed where it is looking for... 
> > 
> > Ok, that happens if you have 2 opal(s) installed.
> > Compiled ok, but now it crashes on connection established
> > with the following error:
> > 
> > 2007/02/20 18:36:37.052   1:57.200  SIP Handle...er:969c848 SIP
> > Could not find SDP media description for Video
> > 2007/02/20 18:36:37.052   1:57.200  SIP Handle...er:969c848 SIP
> > Could not find SDP media description for Image
> > 
> > Xlib: unexpected async reply (sequence 0x11518)!
> > 
> > 
> > No help if I disable that "Enable video" checkbox.
> 
> Given that George is also encountering a crash, I would think Craig
> recently broke something.
> 
> Can you do the same operation than George (see other e-mails sent today)
> to see if it is the same crash ?

The only changes I made were to prevent error conditions causing
crashes, and should not actually change existing functionality.

I'll check SIP with video today using simpleopal and let you know how it
goes.

The two log mesages above indicate that the SDP does not contain any
video or image (fax) entries. Without seeing the SDP I can't tell if
this is true.

   Craig

---
 Craig Southeren  Post Increment – VoIP Consulting and Software
 [EMAIL PROTECTED]   www.postincrement.com.au

 Phone:  +61 243654666  ICQ: #86852844
 Fax:+61 243656905  MSN: [EMAIL PROTECTED]
 Mobile: +61 417231046  Jabber: [EMAIL PROTECTED]

 "It takes a man to suffer ignorance and smile.
  Be yourself, no matter what they say."   Sting


___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] crash with 2.0.3

[Craig Southeren]

On Wed, 10 Jan 2007 01:15:39 +0100
Patriick <[EMAIL PROTECTED]> wrote:

> On 1/9/07, Damien Sandras <[EMAIL PROTECTED]> wrote:
> > Could you try with CVS?
> 
> I tried. I am stuck at the follwoing when compiling opal:
> 
> make[3]: Entering directory `/home/patrick/w/opal/plugins/LID/CAPI'
> gcc -I../../../include -fPIC   -c CAPI.cxx -o obj/CAPI.o
> CAPI.cxx:172: error: 'Int32' has not been declared
> CAPI.cxx: In constructor 'Context::Context()':
> CAPI.cxx:234: error: 'Success' is not a member of 'CAPI'
> CAPI.cxx: In member function 'PluginLID_Errors
> Context::GetDeviceName(unsigned int, char*, unsigned int)':
> CAPI.cxx:255: error: 'Success' is not a member of 'CAPI'
> CAPI.cxx: In member function 'PluginLID_Errors Context::Open(const char*)':
> CAPI.cxx:281: error: 'Success' is not a member of 'CAPI'
> make[3]: *** [obj/CAPI.o] Error 1
> make[3]: Leaving directory `/home/patrick/w/opal/plugins/LID/CAPI'
> make[2]: *** [opt] Error 2
> make[2]: Leaving directory `/home/patrick/w/opal/plugins'
> make[1]: *** [opt] Error 2
> make[1]: Leaving directory `/home/patrick/w/opal'
> make: *** [optshared] Error 2

Just remove the CAPI directory and recompile. You don't need the CAPI
plugin

   Craig

---
 Craig Southeren  Post Increment – VoIP Consulting and Software
 [EMAIL PROTECTED]   www.postincrement.com.au

 Phone:  +61 243654666  ICQ: #86852844
 Fax:+61 243656905  MSN: [EMAIL PROTECTED]
 Mobile: +61 417231046  Jabber: [EMAIL PROTECTED]

 "It takes a man to suffer ignorance and smile.
  Be yourself, no matter what they say."   Sting


___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] How can I record an Ekiga conversation ?

[Craig Southeren]

On Tue, 19 Dec 2006 10:23:16 +0100
Damien Sandras <[EMAIL PROTECTED]> wrote:

..deleted

> > So, anyone could give me any hint or recipe to me telling how I could
> > record Ekiga conversations ? I'm currently using an Ubuntu system.
> > 
> 
> I think using Asterisk together with Ekiga is the best way to allow
> this.

That's a complicated solution to a rather simple problem.

Adding call recording to OPAL should be quite simple. Let's see what
Santa brings Ekiga for Christmas :)

   Craig

-------
 Craig Southeren  Post Increment – VoIP Consulting and Software
 [EMAIL PROTECTED]   www.postincrement.com.au

 Phone:  +61 243654666  ICQ: #86852844
 Fax:+61 243656905  MSN: [EMAIL PROTECTED]
 Mobile: +61 417231046  Jabber: [EMAIL PROTECTED]

 "It takes a man to suffer ignorance and smile.
  Be yourself, no matter what they say."   Sting

___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] gatekeeper automatic discovery

[Craig Southeren]

On Fri, 15 Dec 2006 11:00:39 +0100
Julien Puydt <[EMAIL PROTECTED]> wrote:

> teamlog a écrit :> Ok, you answered my main question. > Is there a timetable 
> for the "Automatic Discovery" to be reimplemented ? Or> is this so much 
> useless that the is much chance for it not to be> reimplemented at anytime? 
> We have discovery of LAN contacts via avahi.
> Not sure if that's what you want.

H.323 has specific support for discovering gatekeepers using UDP
broadcast.

OpenH323 supports this mode, and it's relatively easy to implement
except for the fact that Linux and Windows do UDP broadcast completely
differently.

   Craig

---
 Craig Southeren  Post Increment – VoIP Consulting and Software
 [EMAIL PROTECTED]   www.postincrement.com.au

 Phone:  +61 243654666  ICQ: #86852844
 Fax:+61 243656905  MSN: [EMAIL PROTECTED]
 Mobile: +61 417231046  Jabber: [EMAIL PROTECTED]

 "It takes a man to suffer ignorance and smile.
  Be yourself, no matter what they say."   Sting

___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] gatekeeper automatic discovery

[Craig Southeren]

On Fri, 15 Dec 2006 01:27:36 -0800 (PST)
teamlog <[EMAIL PROTECTED]> wrote:

> 
> Ok, you answered my main question. Is there a timetable for the "Automatic 
> Discovery" to be reimplemented ? Oris this so much useless that the is much 
> chance for it not to bereimplemented at anytime? Anyway, all my 
> congratulations for the really great job you are doing.
> RegardsPs: I'm not allowed due to the architecture to register on the 
> samegatekeeper each time. No VPN as well. But I'll try to investigate and 
> letyou know...

I'll add it to the ToDo list for OPAL :)

   Craig

-------
 Craig Southeren  Post Increment – VoIP Consulting and Software
 [EMAIL PROTECTED]   www.postincrement.com.au

 Phone:  +61 243654666  ICQ: #86852844
 Fax:+61 243656905  MSN: [EMAIL PROTECTED]
 Mobile: +61 417231046  Jabber: [EMAIL PROTECTED]

 "It takes a man to suffer ignorance and smile.
  Be yourself, no matter what they say."   Sting

___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] ekiga call flow

[Craig Southeren]

On Wed, 6 Dec 2006 11:33:44 +0530
Ramachandran M <[EMAIL PROTECTED]> wrote:

..deleted

> Here we are sending SIP_PDU::Information_Ringing to the "PartyB",why it is
> so?
> 
> But actual flow i studied in SIP TUTORIAL is
> partyA has to send the invite,
> the partyB has to send the 180::Ringing,200::OK
> then PartyA has to send the ACK
> 
> Can you clarify me?

The call flow in OPAL is correct. 

Party A sends the INVITE, then party B sends a 180 Ringing, then party B
sends a 200 OK, then party A sends an ACK.

You'll need to look at the code more carefully.

Also, OPAL specific questions should be directed to the mailing list at
[EMAIL PROTECTED] rather than the Ekiga list.

   Craig

-------
 Craig Southeren  Post Increment – VoIP Consulting and Software
 [EMAIL PROTECTED]   www.postincrement.com.au

 Phone:  +61 243654666  ICQ: #86852844
 Fax:+61 243656905  MSN: [EMAIL PROTECTED]
 Mobile: +61 417231046  Jabber: [EMAIL PROTECTED]

 "It takes a man to suffer ignorance and smile.
  Be yourself, no matter what they say."   Sting

___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?]

[Craig Southeren]

On Mon, 27 Nov 2006 23:17:57 +0100
Damien Sandras <[EMAIL PROTECTED]> 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
 [EMAIL PROTECTED]   www.postincrement.com.au

 Phone:  +61 243654666  ICQ: #86852844
 Fax:+61 243656905  MSN: [EMAIL PROTECTED]
 Mobile: +61 417231046  Jabber: [EMAIL PROTECTED]

 "It takes a man to suffer ignorance and smile.
  Be yourself, no matter what they say."   Sting


___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] [OpenH323]Re: Receiving SIP RTP before media description [was ekiga answers with delay ...?]

[Craig Southeren]

On Mon, 27 Nov 2006 09:27:12 +0100
Damien Sandras <[EMAIL PROTECTED]> 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
 [EMAIL PROTECTED]   www.postincrement.com.au

 Phone:  +61 243654666  ICQ: #86852844
 Fax:+61 243656905  MSN: [EMAIL PROTECTED]
 Mobile: +61 417231046  Jabber: [EMAIL PROTECTED]

 "It takes a man to suffer ignorance and smile.
  Be yourself, no matter what they say."   Sting


___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?]

[Craig Southeren]

On Mon, 27 Nov 2006 11:02:14 +0100
Damien Sandras <[EMAIL PROTECTED]> 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   HousekeeperSIP 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
 [EMAIL PROTECTED]   www.postincrement.com.au

 Phone:  +61 243654666  ICQ: #86852844
 Fax:+61 243656905  MSN: [EMAIL PROTECTED]
 Mobile: +61 417231046  Jabber: [EMAIL PROTECTED]

 "It takes a man to suffer ignorance and smile.
  Be yourself, no matter what they say."   Sting

___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?]

[Craig Southeren]

On Mon, 27 Nov 2006 10:42:01 +0100
Damien Sandras <[EMAIL PROTECTED]> 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
 [EMAIL PROTECTED]   www.postincrement.com.au

 Phone:  +61 243654666  ICQ: #86852844
 Fax:+61 243656905  MSN: [EMAIL PROTECTED]
 Mobile: +61 417231046  Jabber: [EMAIL PROTECTED]

 "It takes a man to suffer ignorance and smile.
  Be yourself, no matter what they say."   Sting

___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?]

[Craig Southeren]

On Mon, 27 Nov 2006 10:26:58 +0100
Damien Sandras <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] 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[EMAIL PROTECTED]
> 2006/11/27 10:24:11.261   0:15.013  SIP Handle...er:843fa00 Call
> OnEstablished
> Call[1]-EP[EMAIL PROTECTED]
> 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
 [EMAIL PROTECTED]   www.postincrement.com.au

 Phone:  +61 243654666  ICQ: #86852844
 Fax:+61 243656905  MSN: [EMAIL PROTECTED]
 Mobile: +61 417231046  Jabber: [EMAIL PROTECTED]

 "It takes a man to suffer ignorance and smile.
  Be yourself, no matter what they say."   Sting

___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?]

[Craig Southeren]

On Mon, 27 Nov 2006 00:01:28 +0100
"Bent Bagger" <[EMAIL PROTECTED]> 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
 [EMAIL PROTECTED]   www.postincrement.com.au

 Phone:  +61 243654666  ICQ: #86852844
 Fax:+61 243656905  MSN: [EMAIL PROTECTED]
 Mobile: +61 417231046  Jabber: [EMAIL PROTECTED]

 "It takes a man to suffer ignorance and smile.
  Be yourself, no matter what they say."   Sting


___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?]

[Craig Southeren]

On Sun, 26 Nov 2006 17:49:42 +0100
"Bent Bagger" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]

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
 [EMAIL PROTECTED]   www.postincrement.com.au

 Phone:  +61 243654666  ICQ: #86852844
 Fax:+61 243656905  MSN: [EMAIL PROTECTED]
 Mobile: +61 417231046  Jabber: [EMAIL PROTECTED]

 "It takes a man to suffer ignorance and smile.
  Be yourself, no matter what they say."   Sting


___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] [OpenH323] Receiving SIP RTP before media description [was ekiga answers with delay ...?]

[Craig Southeren]

On Mon, 27 Nov 2006 00:21:46 +0800
"Joegen E. Baclor" <[EMAIL PROTECTED]> 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
 [EMAIL PROTECTED]   www.postincrement.com.au

 Phone:  +61 243654666  ICQ: #86852844
 Fax:+61 243656905  MSN: [EMAIL 

Re: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?]

[Craig Southeren]

On Sun, 26 Nov 2006 12:14:29 +0100
Julien Puydt <[EMAIL PROTECTED]> 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
 [EMAIL PROTECTED]   www.postincrement.com.au

 Phone:  +61 243654666  ICQ: #86852844
 Fax:+61 243656905  MSN: [EMAIL PROTECTED]
 Mobile: +61 417231046  Jabber: [EMAIL PROTECTED]

 "It takes a man to suffer ignorance and smile.
  Be yourself, no matter what they say."   Sting

___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] [OpenH323]Re: Receiving SIP RTP before media description [was ekiga answers with delay ...?]

[Craig Southeren]

On Sun, 26 Nov 2006 12:12:02 +0100
Damien Sandras <[EMAIL PROTECTED]> 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
 [EMAIL PROTECTED]   www.postincrement.com.au

 Phone:  +61 243654666  ICQ: #86852844
 Fax:+61 243656905  MSN: [EMAIL PROTECTED]
 Mobile: +61 417231046  Jabber: [EMAIL PROTECTED]

 "It takes a man to suffer ignorance and smile.
  Be yourself, no matter what they say."   Sting

___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

[Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?]

[Craig Southeren]

On Sat, 25 Nov 2006 02:45:17 +0100
Daniel Huhardeaux <[EMAIL PROTECTED]> 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
 [EMAIL PROTECTED]   www.postincrement.com.au

 Phone:  +61 243654666  ICQ: #86852844
 Fax:+61 243656905  MSN: [EMAIL PROTECTED]
 Mobile: +61 417231046  Jabber: [EMAIL PROTECTED]

 "It takes a man to suffer ignorance and smile.
  Be yourself, no matter what they say."   Sting

___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] ekiga answers with delay ¿... ?

[Craig Southeren]

On Thu, 23 Nov 2006 12:40:51 +0100
Daniel Huhardeaux <[EMAIL PROTECTED]> 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
 [EMAIL PROTECTED]   www.postincrement.com.au

 Phone:  +61 243654666  ICQ: #86852844
 Fax:+61 243656905  MSN: [EMAIL PROTECTED]
 Mobile: +61 417231046  Jabber: [EMAIL PROTECTED]

 "It takes a man to suffer ignorance and smile.
  Be yourself, no matter what they say."   Sting


___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] Ekiga 2.0.3 interface binding

[Craig Southeren]

On Tue, 3 Oct 2006 13:17:15 +0200
Konrad Karl <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> Ekiga does not recognize new network interfaces, e.g.
> TUN adapters from OpenVPN so I have to shutdown and
> restart whenever I want to make a call thru the VPN.
> (did not check with 2.0.2 because I now have a working
> 2.0.3 on current Fedora Rawhide)
> 
> Should not there be also an option to bind to
> all network interfaces? 

..deleted

It's not that simple.

Implementation of SIP requires that you know the address of each
specific network interface being used. Binding to INADDR_ANY doesn't
work.

So, Ekiga (actually, the underlying library called OPAL which I am
involved with) needs to know when network interfaces come up or go down.
On Linux this would be done via the same mechanism used by the hotplug
daemon, which is the netlink interface.

We have plans to look at this problem once the current codec plugins are
finalised and released.

   Craig

-------
 Craig Southeren  Post Increment – VoIP Consulting and Software
 [EMAIL PROTECTED]   www.postincrement.com.au

 Phone:  +61 243654666  ICQ: #86852844
 Fax:+61 243656905  MSN: [EMAIL PROTECTED]
 Mobile: +61 417231046  Jabber: [EMAIL PROTECTED]

 "It takes a man to suffer ignorance and smile.
  Be yourself, no matter what they say."   Sting


___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] Ekiga X86_64 compiling error

[Craig Southeren]

On Wed, 20 Sep 2006 21:39:04 +0200 (CEST)
[EMAIL PROTECTED] wrote:

> Hi,
> I tried to compile the cvs version (I checked it out via cvs) and got the
> following error. The funny thing is I do exakt the same thing on my i386
> system and it went ok. On the x86_64 it failed. I have no idea why. I used
> exact the same recipie to do it.
> 
> Any help
> 
> Franz
> 
> 
> accounts.o: In function `gm_account_new()':
> gui/accounts.cpp:967: undefined reference to
> `PGloballyUniqueID::PGloballyUniqueID()'
> gui/accounts.cpp:967: undefined reference to
> `PGloballyUniqueID::AsString() const'
> /usr//lib/libopal.so: undefined reference to
> `PGloballyUniqueID::PGloballyUniqueID(PASN_OctetString const&)'
> /usr//lib/libopal.so: undefined reference to
> `PGloballyUniqueID::PGloballyUniqueID(PString const&)'
> /usr//lib/libopal.so: undefined reference to `vtable for PGloballyUniqueID'
> /usr//lib/libopal.so: undefined reference to `PGloballyUniqueID::IsNULL()
> const'
> /usr//lib/libopal.so: undefined reference to
> `PGloballyUniqueID::PGloballyUniqueID(char const*)'
> collect2: ld returned 1 exit status

This is due to change I made yesterday in OPAL and PWLib. However, I
forgot to update Linux Makefile.

This change has now been applied to the CVS. 

Please accept my apologies for the confusion

   Craig


---
 Craig Southeren  Post Increment – VoIP Consulting and Software
 [EMAIL PROTECTED]   www.postincrement.com.au

 Phone:  +61 243654666  ICQ: #86852844
 Fax:+61 243656905  MSN: [EMAIL PROTECTED]
 Mobile: +61 417231046  Jabber: [EMAIL PROTECTED]

 "It takes a man to suffer ignorance and smile.
  Be yourself, no matter what they say."   Sting


___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] call recording / ekiga too tightly on ALSA?

[Craig Southeren]

On Tue, 12 Sep 2006 15:01:57 +0200
Viktor <[EMAIL PROTECTED]> wrote:

> Hello,
> 
> I read the "call recording" thread three days ago with great interest,
> as I'm crawling the net how to do this for some hours now. I see various
> possibilities, however no one has worked for me. Attention, this is a
> longer posting ;-)
> 
> (1) vsound (using Ekiga with OSS)

..deleted

> (2) Direct recording from the ALSA system

..deleted

> (3) Sniffing the VoIP packets

..deleted

> (4) JACK

..deleted

There is another way (and to me, much simpler way) to record Ekiga calls,
which is to use the OPAL library (upon which Ekiga is based).

See the H323Connection::OnStartLogicalChannel function in OPAL to see
how to insert a filter that can capture the raw audio stream

   Craig

-------
 Craig Southeren  Post Increment – VoIP Consulting and Software
 [EMAIL PROTECTED]   www.postincrement.com.au

 Phone:  +61 243654666  ICQ: #86852844
 Fax:+61 243656905  MSN: [EMAIL PROTECTED]
 Mobile: +61 417231046  

 "It takes a man to suffer ignorance and smile.
  Be yourself, no matter what they say."   Sting

___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Re: [Ekiga-list] snapshots.gnomemeeting.net does not exist?

[Craig Southeren]

On Mon, 14 Aug 2006 18:32:42 +0200
Jan Kasprzak <[EMAIL PROTECTED]> wrote:

..deleted

>   Hmm, I have used the tarball from snapshots.seconix.com/cvs -
> how can I get another branch from the CVS? Both cvs.sourceforge.net
> and anoncvs.sourceforge.net return "no route to host":
> 
> $ cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot/openh323 login
> Logging in to :pserver:[EMAIL PROTECTED]:2401/cvsroot/openh323
> CVS password:
> cvs [login aborted]: connect to anoncvs.sourceforge.net(66.35.250.209):2401 
> failed: No route to host

The correct command is:

cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/openh323 login

   Craig

-------
 Craig Southeren  Post Increment – VoIP Consulting and Software
 [EMAIL PROTECTED]   www.postincrement.com.au

 Phone:  +61 243654666  ICQ: #86852844
 Fax:+61 243656905  MSN: [EMAIL PROTECTED]
 Mobile: +61 417231046  Jabber: [EMAIL PROTECTED]

 "It takes a man to suffer ignorance and smile.
  Be yourself, no matter what they say."   Sting

___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list