Setting the goals for Ekiga 3.4

[Damien Sandras]

Hi everyone,


In the last few months, Ekiga has been evolving in various directions
following the own will of each of its developers.

It is right that, on the contrary of other major Open Source projects,
we are all coding in our spare time. The envy is great to do that the
way we like it.

However, if we want the project to survive and to evolve in a *stable*
way, I think it is important to define goals between releases.

Here are the goals I would like the project to reach for next release.
I'm talking about user-visible changes, not about internal changes.
Actually, things should be designed in Ekiga to improve the user
experience, not the developer experience.

1) Having the possibility to add to the roster people with more than one
phone number (from the address book).
2) When a contact has been added from the address book, renaming it in
the address book will trigger renaming in the roster. Changing contact
information (cellphone number) will have the same effect.
3) A stable Pulse plugin, which will be the default. We will take the
advantage of all Pulse features (stream tagging so that music is
automatically stopped when receving or giving a phone call, and so on)
4) Having the ability to handle several calls simultaneously, with
attended transfer support. (I need this at the office to take calls with
Ekiga).

We should also work on related aspects :
1) Ekiga.org website
2) Ekiga.net website
3) Ekiga.net service

Comments ?
--
 _     Damien Sandras
(o-      
//\    Ekiga Softphone : http://www.ekiga.org/
v_/_   Be IP           : http://www.beip.be/
       FOSDEM          : http://www.fosdem.org/
       SIP Phone       : sip:dsandras@...
                       


_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Yannick-GNU/Linux]

Damien Sandras a écrit :

> Hi everyone,
>
>
> In the last few months, Ekiga has been evolving in various directions
> following the own will of each of its developers.
>
> It is right that, on the contrary of other major Open Source projects,
> we are all coding in our spare time. The envy is great to do that the
> way we like it.
>
> However, if we want the project to survive and to evolve in a *stable*
> way, I think it is important to define goals between releases.
>
> Here are the goals I would like the project to reach for next release.
> I'm talking about user-visible changes, not about internal changes.
> Actually, things should be designed in Ekiga to improve the user
> experience, not the developer experience.
>
> 1) Having the possibility to add to the roster people with more than one
> phone number (from the address book).
> 2) When a contact has been added from the address book, renaming it in
> the address book will trigger renaming in the roster. Changing contact
> information (cellphone number) will have the same effect.
> 3) A stable Pulse plugin, which will be the default. We will take the
> advantage of all Pulse features (stream tagging so that music is
> automatically stopped when receving or giving a phone call, and so on)
> 4) Having the ability to handle several calls simultaneously, with
> attended transfer support. (I need this at the office to take calls with
> Ekiga).
>
> We should also work on related aspects :
> 1) Ekiga.org website
> 2) Ekiga.net website
> 3) Ekiga.net service

I aply for those last 3 entries. I still have a few work to do about
packaging, then I'll jump on that seriously.

>
> Comments ?

I think it is a good idea to add TCP support; atm the lack of TCP
signaling for SIP broke some setups (calls fail), and as a packager I do
not package extra codecs (non free) because of this bug. This means
those non free codecs are undertested (e.g. it seems latest x264 lib do
not compile with Ekiga anymore), and we lose some interoperability with
other software/hardware out of the box.

I also think we should add some automatic workarounds. e.g. for
freephonie.net which only works if video is disabled. Those issues hurt
our reputation (even if the culprit is on the registrar side for not
supporting well enough the standard). We have discussed that with Eugen,
and he has some ideas to not clutter much our code... /me launching the
hot patato to Eugen ;)

Best regards,
Yannick
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Damien Sandras]

Le dimanche 27 septembre 2009 à 12:38 +0200, yannick a écrit :

> I think it is a good idea to add TCP support; atm the lack of TCP
> signaling for SIP broke some setups (calls fail), and as a packager I do
> not package extra codecs (non free) because of this bug. This means
> those non free codecs are undertested (e.g. it seems latest x264 lib do
> not compile with Ekiga anymore), and we lose some interoperability with
> other software/hardware out of the box.

Agreed. However, that's more an OPAL feature and it requires serious
work on Ekiga.net to add support for TCP and NAT traversal. I'm not sure
of the result of having 10000 active TCP connections to Ekiga.net
either.

> I also think we should add some automatic workarounds. e.g. for
> freephonie.net which only works if video is disabled. Those issues hurt
> our reputation (even if the culprit is on the registrar side for not
> supporting well enough the standard). We have discussed that with Eugen,
> and he has some ideas to not clutter much our code... /me launching the
> hot patato to Eugen ;)

I hate workarounds :-)
Imagine we disable video for freephonie and they fix their stuff: we
will ship broken stuff.

But that's something we need to think about. Is that possible to contact
them and ask them why we are rejected when offering video?


--
 _     Damien Sandras
(o-      
//\    Ekiga Softphone : http://www.ekiga.org/
v_/_   Be IP           : http://www.beip.be/
       FOSDEM          : http://www.fosdem.org/
       SIP Phone       : sip:dsandras@...
                       

_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Yannick-GNU/Linux]

Damien Sandras a écrit :

> Le dimanche 27 septembre 2009 à 12:38 +0200, yannick a écrit :
>
>> I think it is a good idea to add TCP support; atm the lack of TCP
>> signaling for SIP broke some setups (calls fail), and as a packager I do
>> not package extra codecs (non free) because of this bug. This means
>> those non free codecs are undertested (e.g. it seems latest x264 lib do
>> not compile with Ekiga anymore), and we lose some interoperability with
>> other software/hardware out of the box.
>
> Agreed. However, that's more an OPAL feature and it requires serious
> work on Ekiga.net to add support for TCP and NAT traversal. I'm not sure
> of the result of having 10000 active TCP connections to Ekiga.net
> either.

hm... we are back to my secret project to take over the world... Thus I
have a fix, but it will be released in 5 years :P

>
>> I also think we should add some automatic workarounds. e.g. for
>> freephonie.net which only works if video is disabled. Those issues hurt
>> our reputation (even if the culprit is on the registrar side for not
>> supporting well enough the standard). We have discussed that with Eugen,
>> and he has some ideas to not clutter much our code... /me launching the
>> hot patato to Eugen ;)
>
> I hate workarounds :-)
> Imagine we disable video for freephonie and they fix their stuff: we
> will ship broken stuff.
>
> But that's something we need to think about. Is that possible to contact
> them and ask them why we are rejected when offering video?
>
>

Indeed, I need to ask them... thanks for the reminder. Still, I'm quite
sure we will need some workarounds. Plugins maybe?
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Damien Sandras]

Le dimanche 27 septembre 2009 à 14:33 +0200, yannick a écrit :

> Damien Sandras a écrit :
> > Le dimanche 27 septembre 2009 à 12:38 +0200, yannick a écrit :
> >
> >> I think it is a good idea to add TCP support; atm the lack of TCP
> >> signaling for SIP broke some setups (calls fail), and as a packager I do
> >> not package extra codecs (non free) because of this bug. This means
> >> those non free codecs are undertested (e.g. it seems latest x264 lib do
> >> not compile with Ekiga anymore), and we lose some interoperability with
> >> other software/hardware out of the box.
> >
> > Agreed. However, that's more an OPAL feature and it requires serious
> > work on Ekiga.net to add support for TCP and NAT traversal. I'm not sure
> > of the result of having 10000 active TCP connections to Ekiga.net
> > either.
>
> hm... we are back to my secret project to take over the world... Thus I
> have a fix, but it will be released in 5 years :P
>
> >
> >> I also think we should add some automatic workarounds. e.g. for
> >> freephonie.net which only works if video is disabled. Those issues hurt
> >> our reputation (even if the culprit is on the registrar side for not
> >> supporting well enough the standard). We have discussed that with Eugen,
> >> and he has some ideas to not clutter much our code... /me launching the
> >> hot patato to Eugen ;)
> >
> > I hate workarounds :-)
> > Imagine we disable video for freephonie and they fix their stuff: we
> > will ship broken stuff.
> >
> > But that's something we need to think about. Is that possible to contact
> > them and ask them why we are rejected when offering video?
> >
> >
>
> Indeed, I need to ask them... thanks for the reminder. Still, I'm quite
> sure we will need some workarounds. Plugins maybe?

We'll see. The correct fix is for them to answer with a 200OK indicating
they do not support video. But let's wait for their answer. iirc last
time they clearly indicated why they were doing things that way (related
to the multiple ports problem).

--
 _     Damien Sandras
(o-      
//\    Ekiga Softphone : http://www.ekiga.org/
v_/_   Be IP           : http://www.beip.be/
       FOSDEM          : http://www.fosdem.org/
       SIP Phone       : sip:dsandras@...
                       

_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Peter Robinson]

On Sun, Sep 27, 2009 at 11:50 AM, Damien Sandras <dsandras@...> wrote:

> Le dimanche 27 septembre 2009 à 12:38 +0200, yannick a écrit :
>
>> I think it is a good idea to add TCP support; atm the lack of TCP
>> signaling for SIP broke some setups (calls fail), and as a packager I do
>> not package extra codecs (non free) because of this bug. This means
>> those non free codecs are undertested (e.g. it seems latest x264 lib do
>> not compile with Ekiga anymore), and we lose some interoperability with
>> other software/hardware out of the box.
>
> Agreed. However, that's more an OPAL feature and it requires serious
> work on Ekiga.net to add support for TCP and NAT traversal. I'm not sure
> of the result of having 10000 active TCP connections to Ekiga.net
> either.

Can we support it on ekiga and just not use it on ekiga.net so that
those people that wish to use it have the advantage of it?

Peter
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Damien Sandras]

Le dimanche 27 septembre 2009 à 19:30 +0100, Peter Robinson a écrit :

> On Sun, Sep 27, 2009 at 11:50 AM, Damien Sandras <dsandras@...> wrote:
> > Le dimanche 27 septembre 2009 à 12:38 +0200, yannick a écrit :
> >
> >> I think it is a good idea to add TCP support; atm the lack of TCP
> >> signaling for SIP broke some setups (calls fail), and as a packager I do
> >> not package extra codecs (non free) because of this bug. This means
> >> those non free codecs are undertested (e.g. it seems latest x264 lib do
> >> not compile with Ekiga anymore), and we lose some interoperability with
> >> other software/hardware out of the box.
> >
> > Agreed. However, that's more an OPAL feature and it requires serious
> > work on Ekiga.net to add support for TCP and NAT traversal. I'm not sure
> > of the result of having 10000 active TCP connections to Ekiga.net
> > either.
>
> Can we support it on ekiga and just not use it on ekiga.net so that
> those people that wish to use it have the advantage of it?
>

I don't know many providers/software/services supporting TCP...

--
 _     Damien Sandras
(o-      
//\    Ekiga Softphone : http://www.ekiga.org/
v_/_   Be IP           : http://www.beip.be/
       FOSDEM          : http://www.fosdem.org/
       SIP Phone       : sip:dsandras@...
                       

_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Michael Cronenworth]

On 09/27/2009 05:19 AM, Damien Sandras wrote:
> Comments ?
>    

How about performance profiling? Ekiga may not be responsible, but on a
good video phone call I will see at least one core at 100% CPU usage on
a brand new Core 2 Duo system. Would it be good to profile the OPAL
and/or ptlib as well as Ekiga to get CPU usage down? Skype, even though
it's pretty much junk, uses less CPU.

This CPU power draw reduces battery life on laptops, causes higher heat
output, etc.
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Damien Sandras]

Le dimanche 27 septembre 2009 à 18:23 -0500, Michael Cronenworth a
écrit :

> On 09/27/2009 05:19 AM, Damien Sandras wrote:
> > Comments ?
> >    
>
> How about performance profiling? Ekiga may not be responsible, but on a
> good video phone call I will see at least one core at 100% CPU usage on
> a brand new Core 2 Duo system. Would it be good to profile the OPAL
> and/or ptlib as well as Ekiga to get CPU usage down? Skype, even though
> it's pretty much junk, uses less CPU.
>
> This CPU power draw reduces battery life on laptops, causes higher heat
> output, etc.

You are right.

--
 _     Damien Sandras
(o-      
//\    Ekiga Softphone : http://www.ekiga.org/
v_/_   Be IP           : http://www.beip.be/
       FOSDEM          : http://www.fosdem.org/
       SIP Phone       : sip:dsandras@...
                       

_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Thierry Simonnet]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hi,

I use both environments and I think working a little bit more on Win32 version to have linux and Win32 version at the same level will be a good thing.

Best regards



Damien Sandras wrote:

Hi everyone,


In the last few months, Ekiga has been evolving in various directions
following the own will of each of its developers.

It is right that, on the contrary of other major Open Source projects,
we are all coding in our spare time. The envy is great to do that the
way we like it.

However, if we want the project to survive and to evolve in a *stable*
way, I think it is important to define goals between releases.

Here are the goals I would like the project to reach for next release.
I'm talking about user-visible changes, not about internal changes.
Actually, things should be designed in Ekiga to improve the user
experience, not the developer experience.

1) Having the possibility to add to the roster people with more than one
phone number (from the address book).
2) When a contact has been added from the address book, renaming it in
the address book will trigger renaming in the roster. Changing contact
information (cellphone number) will have the same effect.
3) A stable Pulse plugin, which will be the default. We will take the
advantage of all Pulse features (stream tagging so that music is
automatically stopped when receving or giving a phone call, and so on)
4) Having the ability to handle several calls simultaneously, with
attended transfer support. (I need this at the office to take calls with
Ekiga).

We should also work on related aspects :
1) Ekiga.org website
2) Ekiga.net website
3) Ekiga.net service

Comments ?
  

_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Yannick-GNU/Linux]

Thierry Simonnet a écrit :
> Hi,
>
> I use both environments and I think working a little bit more on Win32 version
> to have linux and Win32 version at the same level will be a good thing.
>

Hi,

Could you be more specific? What need the win32 version?

> Best regards
>
>
>
> Damien Sandras wrote:
>> Hi everyone,
>>
>>
>> In the last few months, Ekiga has been evolving in various directions
>> following the own will of each of its developers.
>>
>> It is right that, on the contrary of other major Open Source projects,
>> we are all coding in our spare time. The envy is great to do that the
>> way we like it.
>>
>> However, if we want the project to survive and to evolve in a *stable*
>> way, I think it is important to define goals between releases.
>>
>> Here are the goals I would like the project to reach for next release.
>> I'm talking about user-visible changes, not about internal changes.
>> Actually, things should be designed in Ekiga to improve the user
>> experience, not the developer experience.
>>
>> 1) Having the possibility to add to the roster people with more than one
>> phone number (from the address book).
>> 2) When a contact has been added from the address book, renaming it in
>> the address book will trigger renaming in the roster. Changing contact
>> information (cellphone number) will have the same effect.
>> 3) A stable Pulse plugin, which will be the default. We will take the
>> advantage of all Pulse features (stream tagging so that music is
>> automatically stopped when receving or giving a phone call, and so on)
>> 4) Having the ability to handle several calls simultaneously, with
>> attended transfer support. (I need this at the office to take calls with
>> Ekiga).
>>
>> We should also work on related aspects :
>> 1) Ekiga.org website
>> 2) Ekiga.net website
>> 3) Ekiga.net service
>>
>> Comments ?
>>  
>
>
> --
>
> Thierry Simonnet
>
> ESIEE-Paris
>
> Par respect pour l’environnement, n’imprimez ce mail que si nécessaire
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ekiga-devel-list mailing list
> Ekiga-devel-list@...
> http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Julien PUYDT]

Damien Sandras a écrit :
> 1) Having the possibility to add to the roster people with more than one
> phone number (from the address book).

The addressbook part of ekiga already handles this -- that was precisely
the reason why I refused to put a "get_uri" method in the base
Ekiga::Contact class! When pushing into the local roster though, you
choose only one...

> 2) When a contact has been added from the address book, renaming it in
> the address book will trigger renaming in the roster. Changing contact
> information (cellphone number) will have the same effect.

I'm working on both (1) and (2) while working on the fusion of the
contact and presentity stacks. I have already made some progress on this by:
1) making both Ekiga::Contact and Ekiga::Presentity converge (factorized
most of their code into Ekiga::LiveObject and dumping unused methods) ;
2) writing code outside of ekiga to test new ideas.

I think the ideas I have handle most of what you have in mind except for
one problem : renaming groups. I'm still trying to figure that out.

> 3) A stable Pulse plugin, which will be the default. We will take the
> advantage of all Pulse features (stream tagging so that music is
> automatically stopped when receving or giving a phone call, and so on)

That is something that fixing my gstreamer code would give for free...
I'm stuck.

Snark


_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Thierry Simonnet]

yannick wrote:

> Thierry Simonnet a écrit :
>  
>> Hi,
>>
>> I use both environments and I think working a little bit more on Win32 version
>> to have linux and Win32 version at the same level will be a good thing.
>>
>>    
>
> Hi,
>
> Could you be more specific? What need the win32 version?
>  

libboost integration
ptlib 2.7 not compiling
sound trouble using vista
nsisinstaller including libboost

And for development processus, testing both versions together. It is
quite easy to generate a working ekiga for Linux. For windows is is not
so easy.

>  
>> Best regards
>>
>>
>>
>> Damien Sandras wrote:
>>    
>>> Hi everyone,
>>>
>>>
>>> In the last few months, Ekiga has been evolving in various directions
>>> following the own will of each of its developers.
>>>
>>> It is right that, on the contrary of other major Open Source projects,
>>> we are all coding in our spare time. The envy is great to do that the
>>> way we like it.
>>>
>>> However, if we want the project to survive and to evolve in a *stable*
>>> way, I think it is important to define goals between releases.
>>>
>>> Here are the goals I would like the project to reach for next release.
>>> I'm talking about user-visible changes, not about internal changes.
>>> Actually, things should be designed in Ekiga to improve the user
>>> experience, not the developer experience.
>>>
>>> 1) Having the possibility to add to the roster people with more than one
>>> phone number (from the address book).
>>> 2) When a contact has been added from the address book, renaming it in
>>> the address book will trigger renaming in the roster. Changing contact
>>> information (cellphone number) will have the same effect.
>>> 3) A stable Pulse plugin, which will be the default. We will take the
>>> advantage of all Pulse features (stream tagging so that music is
>>> automatically stopped when receving or giving a phone call, and so on)
>>> 4) Having the ability to handle several calls simultaneously, with
>>> attended transfer support. (I need this at the office to take calls with
>>> Ekiga).
>>>
>>> We should also work on related aspects :
>>> 1) Ekiga.org website
>>> 2) Ekiga.net website
>>> 3) Ekiga.net service
>>>
>>> Comments ?
>>>  
>>>      
>> --
>>
>> Thierry Simonnet
>>
>> ESIEE-Paris
>>
>> Par respect pour l’environnement, n’imprimez ce mail que si nécessaire
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Ekiga-devel-list mailing list
>> Ekiga-devel-list@...
>> http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
>>    
>
>  

--

Thierry Simonnet

ESIEE-Paris

Par respect pour l’environnement, n’imprimez ce mail que si nécessaire


_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Eugen Dedu]

Damien Sandras wrote:

> Le dimanche 27 septembre 2009 à 12:38 +0200, yannick a écrit :
>
>> I think it is a good idea to add TCP support; atm the lack of TCP
>> signaling for SIP broke some setups (calls fail), and as a packager I do
>> not package extra codecs (non free) because of this bug. This means
>> those non free codecs are undertested (e.g. it seems latest x264 lib do
>> not compile with Ekiga anymore), and we lose some interoperability with
>> other software/hardware out of the box.
>
> Agreed. However, that's more an OPAL feature and it requires serious
> work on Ekiga.net to add support for TCP and NAT traversal. I'm not sure
> of the result of having 10000 active TCP connections to Ekiga.net
> either.

TCP support is the bug number 1 in my opinion, so very important.

TCP will be used only when the packet has more than about 1400 bytes, so
only a few clients use TCP at any given moment.

Moreover, I feel confident that linux can work with many TCP connections
simultaneously :o)

Finally, note that TCP support exists already in opal, it needs testing
(Craig dixit, see attachments).

> I'm talking about user-visible changes, not about internal changes.

> I also think we should add some automatic workarounds. e.g. for
>> freephonie.net which only works if video is disabled. Those issues hurt

freephonie is one of the user-visible changes: before, it worked, now,
it does not work.  We should solve this problem somehow...

--
Eugen

Damien Sandras wrote:

..deleted

>>
>> Do we need a workaround for this before a proper fix? (TCP support)
>
> TCP support.

Opal has the basic support for TCP, and has had for some time. To try it
out, make sure you have a TCP listener on the same port as UDP listener
(in fact, this is a requirement of the SIP RFC)

We've done basic testing and it seems to work, but I am sure there are
situations where it fails

What is needed is more testing

    Craig

--

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

  Phone:  [phone]      ICQ: #86852844
  Fax:    [phone]      MSN: craig_southeren@...
  Mobile: [phone]      Jabber: craigs@...

  "Science is the poetry of reality." Richard Dawkins

_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Eugen Dedu wrote:

..deleted

>> We've done basic testing and it seems to work, but I am sure there are
>
> This is very great news!
>
>> situations where it fails
>>
>> What is needed is more testing
>
> How can we test?  How to create a TCP listener...?

The same way a UDP listener is created, but use the string

    tcp$ipaddr:port

instead of

    udp$ipaddr:port

   Craig


--

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

  Phone:  [phone]      ICQ: #86852844
  Fax:    [phone]      MSN: craig_southeren@...
  Mobile: [phone]      Jabber: craigs@...

  "Science is the poetry of reality." Richard Dawkins

_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list


_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Yannick-GNU/Linux]

Eugen Dedu a écrit :

> Damien Sandras wrote:
>> Le dimanche 27 septembre 2009 à 12:38 +0200, yannick a écrit :
>>
>>> I think it is a good idea to add TCP support; atm the lack of TCP
>>> signaling for SIP broke some setups (calls fail), and as a packager I do
>>> not package extra codecs (non free) because of this bug. This means
>>> those non free codecs are undertested (e.g. it seems latest x264 lib do
>>> not compile with Ekiga anymore), and we lose some interoperability with
>>> other software/hardware out of the box.
>> Agreed. However, that's more an OPAL feature and it requires serious
>> work on Ekiga.net to add support for TCP and NAT traversal. I'm not sure
>> of the result of having 10000 active TCP connections to Ekiga.net
>> either.
>
> TCP support is the bug number 1 in my opinion, so very important.
>
> TCP will be used only when the packet has more than about 1400 bytes, so
> only a few clients use TCP at any given moment.
>

s/1400/1300 that's how the standard define it. Should not change much
your argument ;)

> Moreover, I feel confident that linux can work with many TCP connections
> simultaneously :o)
>
> Finally, note that TCP support exists already in opal, it needs testing
> (Craig dixit, see attachments).
>

_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Eugen Dedu]

Michael Cronenworth wrote:

> On 09/27/2009 05:19 AM, Damien Sandras wrote:
>> Comments ?
>>    
>
> How about performance profiling? Ekiga may not be responsible, but on a
> good video phone call I will see at least one core at 100% CPU usage on
> a brand new Core 2 Duo system. Would it be good to profile the OPAL
> and/or ptlib as well as Ekiga to get CPU usage down? Skype, even though
> it's pretty much junk, uses less CPU.
>
> This CPU power draw reduces battery life on laptops, causes higher heat
> output, etc.

This is a good point too, there is already
https://bugzilla.gnome.org/show_bug.cgi?id=581019, we just need someone
to do it :o)

--
Eugen
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Yannick-GNU/Linux]

Eugen Dedu a écrit :

> Michael Cronenworth wrote:
>> On 09/27/2009 05:19 AM, Damien Sandras wrote:
>>> Comments ?
>>>    
>> How about performance profiling? Ekiga may not be responsible, but on a
>> good video phone call I will see at least one core at 100% CPU usage on
>> a brand new Core 2 Duo system. Would it be good to profile the OPAL
>> and/or ptlib as well as Ekiga to get CPU usage down? Skype, even though
>> it's pretty much junk, uses less CPU.
>>
>> This CPU power draw reduces battery life on laptops, causes higher heat
>> output, etc.
>
> This is a good point too, there is already
> https://bugzilla.gnome.org/show_bug.cgi?id=581019, we just need someone
> to do it :o)
>

and this one:
https://bugzilla.gnome.org/show_bug.cgi?id=591627
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Peter Robinson]

On Wed, Sep 30, 2009 at 9:51 AM, yannick <sevmek@...> wrote:

> Eugen Dedu a écrit :
>> Michael Cronenworth wrote:
>>> On 09/27/2009 05:19 AM, Damien Sandras wrote:
>>>> Comments ?
>>>>
>>> How about performance profiling? Ekiga may not be responsible, but on a
>>> good video phone call I will see at least one core at 100% CPU usage on
>>> a brand new Core 2 Duo system. Would it be good to profile the OPAL
>>> and/or ptlib as well as Ekiga to get CPU usage down? Skype, even though
>>> it's pretty much junk, uses less CPU.
>>>
>>> This CPU power draw reduces battery life on laptops, causes higher heat
>>> output, etc.
>>
>> This is a good point too, there is already
>> https://bugzilla.gnome.org/show_bug.cgi?id=581019, we just need someone
>> to do it :o)
>>
> and this one:
> https://bugzilla.gnome.org/show_bug.cgi?id=591627

I have a similarly related bug on the Fedora bugzilla about the amount
of bandwidth that ekiga uses when idle.

https://bugzilla.redhat.com/show_bug.cgi?id=490605

I've not had a chance to actually look at it any further and I don't
know enough about the SIP spec to know how often it needs to
communicate with the server to notify its still alive.

Peter
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Detlef Lechner-2]

Michael Cronenworth wrote:

> How about performance profiling? Ekiga may not be responsible, but on a
> good video phone call I will see at least one core at 100% CPU usage on
> a brand new Core 2 Duo system. Would it be good to profile the OPAL
> and/or ptlib as well as Ekiga to get CPU usage down?

I consider this to be important, too.
See Launchpad bug #395594 'Ekiga occupies > 82% of a Centrino computer's
CPU time'

Regards,

Detlef Lechner
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Michael Rickmann]

Detlef Lechner schrieb:

> Michael Cronenworth wrote:
>
>> How about performance profiling? Ekiga may not be responsible, but on a
>> good video phone call I will see at least one core at 100% CPU usage on
>> a brand new Core 2 Duo system. Would it be good to profile the OPAL
>> and/or ptlib as well as Ekiga to get CPU usage down?
>
> I consider this to be important, too.
> See Launchpad bug #395594 'Ekiga occupies > 82% of a Centrino computer's
> CPU time'
>
> Regards,
>
> Detlef Lechner

As to performance of Ekiga 3.2.6, I did a test calling from WindowsXP
(single core Athlon 2 GHz) Ubuntu Jaunty (Core2Duo, 1.8 GHz). I had
theora video at 640x480 and 128 kBit. The Linux Box was running with
both cores at about 1.2 GHz 55% used, the WinXP Ekiga used about 55% at
full speed of the old Athlon. Without call and local video only, both
cores of the Linux box were running at 800 MHz using 22% each, the
Athlon's usage under XP was about 6%. When switching cameras and doing
local video only. The Athlon went up to 42% while the Core2Duo dropped
to 7% usage of each core at 800 MHz. The good Cam was an old Phillips
PVC740K ToUcam Pro, the bad one a Logitech Quickcam Pro for Notebooks,
3rd generation, i.e. still with not fully mature firmware.
I think that we have to question the systems which show bad performance
of Ekiga in more detail.
Michael
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list