3.2.5 release

[Eugen Dedu]

Hi,

So we are preparing a new stable release.  What are the blocking bugs?

- picture in picture does not work sometimes
- -d 4 warnings about too many consecutive I-frames, still investigating
if it is harmful or not
- initially greyed image, seems only cosmetic, still investigating

Are there others?

--
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 :

> Hi,
>
> So we are preparing a new stable release.  What are the blocking bugs?
>
> - picture in picture does not work sometimes
> - -d 4 warnings about too many consecutive I-frames, still investigating
> if it is harmful or not
> - initially greyed image, seems only cosmetic, still investigating
>
> Are there others?
>

The PDU>1500 issue?

Here is a report from a Ubnutu user (I know, I should not trust blindly
a user, but i wont be able to test before tomorrow...):
"No I hadn't installed any non-free codecs (not knowingly anyway).

I wanted to confirm this so I booted from clean live USB memory stick
image (Jaunty).
Selected ekiga for installation.
Synaptic informs that the following are required: libgsm1, libopal3.6.1,
libpt2.6.1, libpt2.6.1-plugins-alsa, libpt2.6.1-plugins-v4l2. (All of
these come from the Main repository).

Once above are installed: Ekiga has the same problem as described above
(PDU exceed 1500) and same solution as you describe above also works.

Out-of-the-box Audio codecs: G722, Speex(16kHz), PCMA, PCMU, G726-16,
G726-24, G726-32, G726-40, gsm, ms-gsm, Speex(8kHz).

Out-of-the-box Video codecs: h261, theora.

So, in answer to your question, only using default packages from Ubuntu
is sufficient for PDU to exceed 1500."

Do we need a workaround for this before a proper fix? (TCP support)
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Damien Sandras]

Le lundi 06 juillet 2009 à 16:12 +0200, yannick a écrit :

> Eugen Dedu a écrit :
> > Hi,
> >
> > So we are preparing a new stable release.  What are the blocking bugs?
> >
> > - picture in picture does not work sometimes
> > - -d 4 warnings about too many consecutive I-frames, still investigating
> > if it is harmful or not
> > - initially greyed image, seems only cosmetic, still investigating
> >
> > Are there others?
> >
>
> The PDU>1500 issue?
>
> Here is a report from a Ubnutu user (I know, I should not trust blindly
> a user, but i wont be able to test before tomorrow...):
> "No I hadn't installed any non-free codecs (not knowingly anyway).
>
> I wanted to confirm this so I booted from clean live USB memory stick
> image (Jaunty).
> Selected ekiga for installation.
> Synaptic informs that the following are required: libgsm1, libopal3.6.1,
> libpt2.6.1, libpt2.6.1-plugins-alsa, libpt2.6.1-plugins-v4l2. (All of
> these come from the Main repository).
>
> Once above are installed: Ekiga has the same problem as described above
> (PDU exceed 1500) and same solution as you describe above also works.
>
> Out-of-the-box Audio codecs: G722, Speex(16kHz), PCMA, PCMU, G726-16,
> G726-24, G726-32, G726-40, gsm, ms-gsm, Speex(8kHz).
>
> Out-of-the-box Video codecs: h261, theora.
>
> So, in answer to your question, only using default packages from Ubuntu
> is sufficient for PDU to exceed 1500."
>
> Do we need a workaround for this before a proper fix? (TCP support)

TCP support.
--
 _     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

[Craig Southeren]

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]

yannick wrote:

> Eugen Dedu a écrit :
>> Hi,
>>
>> So we are preparing a new stable release.  What are the blocking bugs?
>>
>> - picture in picture does not work sometimes
>> - -d 4 warnings about too many consecutive I-frames, still investigating
>> if it is harmful or not
>> - initially greyed image, seems only cosmetic, still investigating
>>
>> Are there others?
>>
>
> The PDU>1500 issue?
>
> Here is a report from a Ubnutu user (I know, I should not trust blindly
> a user, but i wont be able to test before tomorrow...):
> "No I hadn't installed any non-free codecs (not knowingly anyway).
>
> I wanted to confirm this so I booted from clean live USB memory stick
> image (Jaunty).
> Selected ekiga for installation.
> Synaptic informs that the following are required: libgsm1, libopal3.6.1,
> libpt2.6.1, libpt2.6.1-plugins-alsa, libpt2.6.1-plugins-v4l2. (All of
> these come from the Main repository).
>
> Once above are installed: Ekiga has the same problem as described above
> (PDU exceed 1500) and same solution as you describe above also works.
>
> Out-of-the-box Audio codecs: G722, Speex(16kHz), PCMA, PCMU, G726-16,
> G726-24, G726-32, G726-40, gsm, ms-gsm, Speex(8kHz).
>
> Out-of-the-box Video codecs: h261, theora.
>
> So, in answer to your question, only using default packages from Ubuntu
> is sufficient for PDU to exceed 1500."
>
> Do we need a workaround for this before a proper fix? (TCP support)

TCP support is the bug no 1 (in my opinion), but it is not for 3.2.5.

Once 3.2.5 is released, we will see the next release goals.

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

[Eugen Dedu]

Craig Southeren wrote:

> 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

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...?

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

[Craig Southeren]

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

[Eugen Dedu]

yannick wrote:

> Eugen Dedu a écrit :
>> Hi,
>>
>> So we are preparing a new stable release.  What are the blocking bugs?
>>
>> - picture in picture does not work sometimes
>> - -d 4 warnings about too many consecutive I-frames, still investigating
>> if it is harmful or not
>> - initially greyed image, seems only cosmetic, still investigating
>>
>> Are there others?
>>
>
> The PDU>1500 issue?
>
> Here is a report from a Ubnutu user (I know, I should not trust blindly
> a user, but i wont be able to test before tomorrow...):
> "No I hadn't installed any non-free codecs (not knowingly anyway).
>
> I wanted to confirm this so I booted from clean live USB memory stick
> image (Jaunty).
> Selected ekiga for installation.
> Synaptic informs that the following are required: libgsm1, libopal3.6.1,
> libpt2.6.1, libpt2.6.1-plugins-alsa, libpt2.6.1-plugins-v4l2. (All of
> these come from the Main repository).
>
> Once above are installed: Ekiga has the same problem as described above
> (PDU exceed 1500) and same solution as you describe above also works.
>
> Out-of-the-box Audio codecs: G722, Speex(16kHz), PCMA, PCMU, G726-16,
> G726-24, G726-32, G726-40, gsm, ms-gsm, Speex(8kHz).
>
> Out-of-the-box Video codecs: h261, theora.
>
> So, in answer to your question, only using default packages from Ubuntu
> is sufficient for PDU to exceed 1500."
>
> Do we need a workaround for this before a proper fix? (TCP support)

A workaround would be to switch off some codecs by default (for initial
installation), for ex. G726-24, G726-32, G726-40, gsm, ms-gsm,
Speex(8kHz).  What do you think?

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

[Damien Sandras]

Le lundi 06 juillet 2009 à 18:53 +0200, Eugen Dedu a écrit :

> yannick wrote:
> > Eugen Dedu a écrit :
> >> Hi,
> >>
> >> So we are preparing a new stable release.  What are the blocking bugs?
> >>
> >> - picture in picture does not work sometimes
> >> - -d 4 warnings about too many consecutive I-frames, still investigating
> >> if it is harmful or not
> >> - initially greyed image, seems only cosmetic, still investigating
> >>
> >> Are there others?
> >>
> >
> > The PDU>1500 issue?
> >
> > Here is a report from a Ubnutu user (I know, I should not trust blindly
> > a user, but i wont be able to test before tomorrow...):
> > "No I hadn't installed any non-free codecs (not knowingly anyway).
> >
> > I wanted to confirm this so I booted from clean live USB memory stick
> > image (Jaunty).
> > Selected ekiga for installation.
> > Synaptic informs that the following are required: libgsm1, libopal3.6.1,
> > libpt2.6.1, libpt2.6.1-plugins-alsa, libpt2.6.1-plugins-v4l2. (All of
> > these come from the Main repository).
> >
> > Once above are installed: Ekiga has the same problem as described above
> > (PDU exceed 1500) and same solution as you describe above also works.
> >
> > Out-of-the-box Audio codecs: G722, Speex(16kHz), PCMA, PCMU, G726-16,
> > G726-24, G726-32, G726-40, gsm, ms-gsm, Speex(8kHz).
> >
> > Out-of-the-box Video codecs: h261, theora.
> >
> > So, in answer to your question, only using default packages from Ubuntu
> > is sufficient for PDU to exceed 1500."
> >
> > Do we need a workaround for this before a proper fix? (TCP support)
>
> A workaround would be to switch off some codecs by default (for initial
> installation), for ex. G726-24, G726-32, G726-40, gsm, ms-gsm,
> Speex(8kHz).  What do you think?
>

Isn't that already the case ?

I need to check.
--
 _     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]

>> >> So we are preparing a new stable release.  What are the blocking bugs?
>> >>
>> >> - picture in picture does not work sometimes
>> >> - -d 4 warnings about too many consecutive I-frames, still investigating
>> >> if it is harmful or not
>> >> - initially greyed image, seems only cosmetic, still investigating
>> >>
>> >> Are there others?
>> >>
>> >
>> > The PDU>1500 issue?
>> >
>> > Here is a report from a Ubnutu user (I know, I should not trust blindly
>> > a user, but i wont be able to test before tomorrow...):
>> > "No I hadn't installed any non-free codecs (not knowingly anyway).
>> >
>> > I wanted to confirm this so I booted from clean live USB memory stick
>> > image (Jaunty).
>> > Selected ekiga for installation.
>> > Synaptic informs that the following are required: libgsm1, libopal3.6.1,
>> > libpt2.6.1, libpt2.6.1-plugins-alsa, libpt2.6.1-plugins-v4l2. (All of
>> > these come from the Main repository).
>> >
>> > Once above are installed: Ekiga has the same problem as described above
>> > (PDU exceed 1500) and same solution as you describe above also works.
>> >
>> > Out-of-the-box Audio codecs: G722, Speex(16kHz), PCMA, PCMU, G726-16,
>> > G726-24, G726-32, G726-40, gsm, ms-gsm, Speex(8kHz).
>> >
>> > Out-of-the-box Video codecs: h261, theora.
>> >
>> > So, in answer to your question, only using default packages from Ubuntu
>> > is sufficient for PDU to exceed 1500."
>> >
>> > Do we need a workaround for this before a proper fix? (TCP support)
>>
>> A workaround would be to switch off some codecs by default (for initial
>> installation), for ex. G726-24, G726-32, G726-40, gsm, ms-gsm,
>> Speex(8kHz).  What do you think?
>>
>
> Isn't that already the case ?
>
> I need to check.

The default in Fedora certainly doesn't enable them by default and we
don't do anything with that sort of config so I assume its the
default.

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

[Damien Sandras]

Le lundi 06 juillet 2009 à 20:20 +0100, Peter Robinson a écrit :

> >> >> So we are preparing a new stable release.  What are the blocking bugs?
> >> >>
> >> >> - picture in picture does not work sometimes
> >> >> - -d 4 warnings about too many consecutive I-frames, still investigating
> >> >> if it is harmful or not
> >> >> - initially greyed image, seems only cosmetic, still investigating
> >> >>
> >> >> Are there others?
> >> >>
> >> >
> >> > The PDU>1500 issue?
> >> >
> >> > Here is a report from a Ubnutu user (I know, I should not trust blindly
> >> > a user, but i wont be able to test before tomorrow...):
> >> > "No I hadn't installed any non-free codecs (not knowingly anyway).
> >> >
> >> > I wanted to confirm this so I booted from clean live USB memory stick
> >> > image (Jaunty).
> >> > Selected ekiga for installation.
> >> > Synaptic informs that the following are required: libgsm1, libopal3.6.1,
> >> > libpt2.6.1, libpt2.6.1-plugins-alsa, libpt2.6.1-plugins-v4l2. (All of
> >> > these come from the Main repository).
> >> >
> >> > Once above are installed: Ekiga has the same problem as described above
> >> > (PDU exceed 1500) and same solution as you describe above also works.
> >> >
> >> > Out-of-the-box Audio codecs: G722, Speex(16kHz), PCMA, PCMU, G726-16,
> >> > G726-24, G726-32, G726-40, gsm, ms-gsm, Speex(8kHz).
> >> >
> >> > Out-of-the-box Video codecs: h261, theora.
> >> >
> >> > So, in answer to your question, only using default packages from Ubuntu
> >> > is sufficient for PDU to exceed 1500."
> >> >
> >> > Do we need a workaround for this before a proper fix? (TCP support)
> >>
> >> A workaround would be to switch off some codecs by default (for initial
> >> installation), for ex. G726-24, G726-32, G726-40, gsm, ms-gsm,
> >> Speex(8kHz).  What do you think?
> >>
> >
> > Isn't that already the case ?
> >
> > I need to check.
>
> The default in Fedora certainly doesn't enable them by default and we
> don't do anything with that sort of config so I assume its the
> default.
>

That's what I thought. By default, only a few codecs are enabled.
--
 _     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

[Eugen Dedu]

Damien Sandras wrote:

> Le lundi 06 juillet 2009 à 20:20 +0100, Peter Robinson a écrit :
>>>>>> So we are preparing a new stable release.  What are the blocking bugs?
>>>>>>
>>>>>> - picture in picture does not work sometimes
>>>>>> - -d 4 warnings about too many consecutive I-frames, still investigating
>>>>>> if it is harmful or not
>>>>>> - initially greyed image, seems only cosmetic, still investigating
>>>>>>
>>>>>> Are there others?
>>>>>>
>>>>> The PDU>1500 issue?
>>>>>
>>>>> Here is a report from a Ubnutu user (I know, I should not trust blindly
>>>>> a user, but i wont be able to test before tomorrow...):
>>>>> "No I hadn't installed any non-free codecs (not knowingly anyway).
>>>>>
>>>>> I wanted to confirm this so I booted from clean live USB memory stick
>>>>> image (Jaunty).
>>>>> Selected ekiga for installation.
>>>>> Synaptic informs that the following are required: libgsm1, libopal3.6.1,
>>>>> libpt2.6.1, libpt2.6.1-plugins-alsa, libpt2.6.1-plugins-v4l2. (All of
>>>>> these come from the Main repository).
>>>>>
>>>>> Once above are installed: Ekiga has the same problem as described above
>>>>> (PDU exceed 1500) and same solution as you describe above also works.
>>>>>
>>>>> Out-of-the-box Audio codecs: G722, Speex(16kHz), PCMA, PCMU, G726-16,
>>>>> G726-24, G726-32, G726-40, gsm, ms-gsm, Speex(8kHz).
>>>>>
>>>>> Out-of-the-box Video codecs: h261, theora.
>>>>>
>>>>> So, in answer to your question, only using default packages from Ubuntu
>>>>> is sufficient for PDU to exceed 1500."
>>>>>
>>>>> Do we need a workaround for this before a proper fix? (TCP support)
>>>> A workaround would be to switch off some codecs by default (for initial
>>>> installation), for ex. G726-24, G726-32, G726-40, gsm, ms-gsm,
>>>> Speex(8kHz).  What do you think?
>>>>
>>> Isn't that already the case ?
>>>
>>> I need to check.
>> The default in Fedora certainly doesn't enable them by default and we
>> don't do anything with that sort of config so I assume its the
>> default.
>>
>
> That's what I thought. By default, only a few codecs are enabled.

The bug is strange, since
https://launchpadlibrarian.net/24407094/ekiga_3.2.0-0ubuntu1.diff.gz 
does not show any change related to enabled codecs in ekiga...

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

[Damien Sandras]

Le mercredi 08 juillet 2009 à 09:04 +0200, Eugen Dedu a écrit :

> Damien Sandras wrote:
> > Le lundi 06 juillet 2009 à 20:20 +0100, Peter Robinson a écrit :
> >>>>>> So we are preparing a new stable release.  What are the blocking bugs?
> >>>>>>
> >>>>>> - picture in picture does not work sometimes
> >>>>>> - -d 4 warnings about too many consecutive I-frames, still investigating
> >>>>>> if it is harmful or not
> >>>>>> - initially greyed image, seems only cosmetic, still investigating
> >>>>>>
> >>>>>> Are there others?
> >>>>>>
> >>>>> The PDU>1500 issue?
> >>>>>
> >>>>> Here is a report from a Ubnutu user (I know, I should not trust blindly
> >>>>> a user, but i wont be able to test before tomorrow...):
> >>>>> "No I hadn't installed any non-free codecs (not knowingly anyway).
> >>>>>
> >>>>> I wanted to confirm this so I booted from clean live USB memory stick
> >>>>> image (Jaunty).
> >>>>> Selected ekiga for installation.
> >>>>> Synaptic informs that the following are required: libgsm1, libopal3.6.1,
> >>>>> libpt2.6.1, libpt2.6.1-plugins-alsa, libpt2.6.1-plugins-v4l2. (All of
> >>>>> these come from the Main repository).
> >>>>>
> >>>>> Once above are installed: Ekiga has the same problem as described above
> >>>>> (PDU exceed 1500) and same solution as you describe above also works.
> >>>>>
> >>>>> Out-of-the-box Audio codecs: G722, Speex(16kHz), PCMA, PCMU, G726-16,
> >>>>> G726-24, G726-32, G726-40, gsm, ms-gsm, Speex(8kHz).
> >>>>>
> >>>>> Out-of-the-box Video codecs: h261, theora.
> >>>>>
> >>>>> So, in answer to your question, only using default packages from Ubuntu
> >>>>> is sufficient for PDU to exceed 1500."
> >>>>>
> >>>>> Do we need a workaround for this before a proper fix? (TCP support)
> >>>> A workaround would be to switch off some codecs by default (for initial
> >>>> installation), for ex. G726-24, G726-32, G726-40, gsm, ms-gsm,
> >>>> Speex(8kHz).  What do you think?
> >>>>
> >>> Isn't that already the case ?
> >>>
> >>> I need to check.
> >> The default in Fedora certainly doesn't enable them by default and we
> >> don't do anything with that sort of config so I assume its the
> >> default.
> >>
> >
> > That's what I thought. By default, only a few codecs are enabled.
>
> The bug is strange, since
> https://launchpadlibrarian.net/24407094/ekiga_3.2.0-0ubuntu1.diff.gz 
> does not show any change related to enabled codecs in ekiga...
>

I guess people enable everything.
--
 _     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 mercredi 08 juillet 2009 à 09:04 +0200, Eugen Dedu a écrit :
>> Damien Sandras wrote:
>>> Le lundi 06 juillet 2009 à 20:20 +0100, Peter Robinson a écrit :
>>>>>>>> So we are preparing a new stable release.  What are the blocking bugs?
>>>>>>>>
>>>>>>>> - picture in picture does not work sometimes
>>>>>>>> - -d 4 warnings about too many consecutive I-frames, still investigating
>>>>>>>> if it is harmful or not
>>>>>>>> - initially greyed image, seems only cosmetic, still investigating
>>>>>>>>
>>>>>>>> Are there others?
>>>>>>>>
>>>>>>> The PDU>1500 issue?
>>>>>>>
>>>>>>> Here is a report from a Ubnutu user (I know, I should not trust blindly
>>>>>>> a user, but i wont be able to test before tomorrow...):
>>>>>>> "No I hadn't installed any non-free codecs (not knowingly anyway).
>>>>>>>
>>>>>>> I wanted to confirm this so I booted from clean live USB memory stick
>>>>>>> image (Jaunty).
>>>>>>> Selected ekiga for installation.
>>>>>>> Synaptic informs that the following are required: libgsm1, libopal3.6.1,
>>>>>>> libpt2.6.1, libpt2.6.1-plugins-alsa, libpt2.6.1-plugins-v4l2. (All of
>>>>>>> these come from the Main repository).
>>>>>>>
>>>>>>> Once above are installed: Ekiga has the same problem as described above
>>>>>>> (PDU exceed 1500) and same solution as you describe above also works.
>>>>>>>
>>>>>>> Out-of-the-box Audio codecs: G722, Speex(16kHz), PCMA, PCMU, G726-16,
>>>>>>> G726-24, G726-32, G726-40, gsm, ms-gsm, Speex(8kHz).
>>>>>>>
>>>>>>> Out-of-the-box Video codecs: h261, theora.
>>>>>>>
>>>>>>> So, in answer to your question, only using default packages from Ubuntu
>>>>>>> is sufficient for PDU to exceed 1500."
>>>>>>>
>>>>>>> Do we need a workaround for this before a proper fix? (TCP support)
>>>>>> A workaround would be to switch off some codecs by default (for initial
>>>>>> installation), for ex. G726-24, G726-32, G726-40, gsm, ms-gsm,
>>>>>> Speex(8kHz).  What do you think?
>>>>>>
>>>>> Isn't that already the case ?
>>>>>
>>>>> I need to check.
>>>> The default in Fedora certainly doesn't enable them by default and we
>>>> don't do anything with that sort of config so I assume its the
>>>> default.
>>>>
>>> That's what I thought. By default, only a few codecs are enabled.
>> The bug is strange, since
>> https://launchpadlibrarian.net/24407094/ekiga_3.2.0-0ubuntu1.diff.gz 
>> does not show any change related to enabled codecs in ekiga...
>>
>
> I guess people enable everything.

I have done some limited search on the MTU topic and it seems the MTU
can vary along the patch. Beside large bandwidth can greatly benefit for
a larger MTU than 1500 and some people are pushing to have larger MTU in
this case. (I have a report with this case at hand here:
https://bugs.launchpad.net/ubuntu/+source/ekiga/+bug/380091 )I do not
know how the choice if 1500 is made inside OPAL; if it is hardcoded it
is probably a source of frame dropping in some case (and it happen
probably in silence). Around 1400 seems more safe but it seems to not
cover all cases.

AFAIK a proper fix for this situation is to use a discovery mechanism
for the MTU: fortunately this exist in RFC:
http://tools.ietf.org/html/rfc4821
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Damien Sandras]

Le vendredi 10 juillet 2009 à 10:49 +0200, yannick a écrit :

> >>> That's what I thought. By default, only a few codecs are enabled.
> >> The bug is strange, since
> >> https://launchpadlibrarian.net/24407094/ekiga_3.2.0-0ubuntu1.diff.gz 
> >> does not show any change related to enabled codecs in ekiga...
> >>
> >
> > I guess people enable everything.
>
> I have done some limited search on the MTU topic and it seems the MTU
> can vary along the patch. Beside large bandwidth can greatly benefit for
> a larger MTU than 1500 and some people are pushing to have larger MTU in
> this case. (I have a report with this case at hand here:
> https://bugs.launchpad.net/ubuntu/+source/ekiga/+bug/380091 )I do not
> know how the choice if 1500 is made inside OPAL; if it is hardcoded it
> is probably a source of frame dropping in some case (and it happen
> probably in silence). Around 1400 seems more safe but it seems to not
> cover all cases.
>
> AFAIK a proper fix for this situation is to use a discovery mechanism
> for the MTU: fortunately this exist in RFC:
> http://tools.ietf.org/html/rfc4821

OPAL does not touch the MTU.

The MTU setting on a machine is an OS thing, not a user program thing.
--
 _     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 vendredi 10 juillet 2009 à 10:49 +0200, yannick a écrit :
>>>>> That's what I thought. By default, only a few codecs are enabled.
>>>> The bug is strange, since
>>>> https://launchpadlibrarian.net/24407094/ekiga_3.2.0-0ubuntu1.diff.gz 
>>>> does not show any change related to enabled codecs in ekiga...
>>>>
>>> I guess people enable everything.
>> I have done some limited search on the MTU topic and it seems the MTU
>> can vary along the patch. Beside large bandwidth can greatly benefit for
>> a larger MTU than 1500 and some people are pushing to have larger MTU in
>> this case. (I have a report with this case at hand here:
>> https://bugs.launchpad.net/ubuntu/+source/ekiga/+bug/380091 )I do not
>> know how the choice if 1500 is made inside OPAL; if it is hardcoded it
>> is probably a source of frame dropping in some case (and it happen
>> probably in silence). Around 1400 seems more safe but it seems to not
>> cover all cases.
>>
>> AFAIK a proper fix for this situation is to use a discovery mechanism
>> for the MTU: fortunately this exist in RFC:
>> http://tools.ietf.org/html/rfc4821
>
> OPAL does not touch the MTU.
>
> The MTU setting on a machine is an OS thing, not a user program thing.

(ARGH I only answered to Damien, reposting to the list, sorry Damien for
the noise...)

It does not matter, even if your host has a 1500 MTU, the next hop in
the path can have a 1400 MTU (I agree this should be a rare case), thus
if you only take your host in account you'll be screwed.

e.g. the AOL ISP use a 1450 MTU:
"MTU (Maximum Transfer Unit) defines the largest data packet size you
can transmit in one go across a network. Any messages larger than the
MTU are divided into smaller packets before being sent. The industry
standard follows the principle that in order to transmit the largest
amount in one go, an MTU should be set to a high value, such as 1500.

However, the AOL Broadband network runs at an MTU of 1450. Many modem
routers have inbuilt auto-configurations where the hardware identifies
that the AOL Broadband traffic has an MTU of 1450 and dynamically
adjusts. If the modem router hardware does not have this facility, the
MTU setting can manually be changed on the computer."
Source:
http://help.aol.co.uk/what-is-an-mtu-setting-and/article/20060802093009990042
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Damien Sandras]

Le vendredi 10 juillet 2009 à 11:17 +0200, yannick a écrit :

> Damien Sandras a écrit :
> > Le vendredi 10 juillet 2009 à 10:49 +0200, yannick a écrit :
> >>>>> That's what I thought. By default, only a few codecs are enabled.
> >>>> The bug is strange, since
> >>>> https://launchpadlibrarian.net/24407094/ekiga_3.2.0-0ubuntu1.diff.gz 
> >>>> does not show any change related to enabled codecs in ekiga...
> >>>>
> >>> I guess people enable everything.
> >> I have done some limited search on the MTU topic and it seems the MTU
> >> can vary along the patch. Beside large bandwidth can greatly benefit for
> >> a larger MTU than 1500 and some people are pushing to have larger MTU in
> >> this case. (I have a report with this case at hand here:
> >> https://bugs.launchpad.net/ubuntu/+source/ekiga/+bug/380091 )I do not
> >> know how the choice if 1500 is made inside OPAL; if it is hardcoded it
> >> is probably a source of frame dropping in some case (and it happen
> >> probably in silence). Around 1400 seems more safe but it seems to not
> >> cover all cases.
> >>
> >> AFAIK a proper fix for this situation is to use a discovery mechanism
> >> for the MTU: fortunately this exist in RFC:
> >> http://tools.ietf.org/html/rfc4821
> >
> > OPAL does not touch the MTU.
> >
> > The MTU setting on a machine is an OS thing, not a user program thing.
>
> (ARGH I only answered to Damien, reposting to the list, sorry Damien for
> the noise...)
>
> It does not matter, even if your host has a 1500 MTU, the next hop in
> the path can have a 1400 MTU (I agree this should be a rare case), thus
> if you only take your host in account you'll be screwed.

Anyway, the only clean solution is to use 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

[Yannick-GNU/Linux]

Damien Sandras a écrit :

> Le vendredi 10 juillet 2009 à 11:17 +0200, yannick a écrit :
>> Damien Sandras a écrit :
>>> Le vendredi 10 juillet 2009 à 10:49 +0200, yannick a écrit :
>>>>>>> That's what I thought. By default, only a few codecs are enabled.
>>>>>> The bug is strange, since
>>>>>> https://launchpadlibrarian.net/24407094/ekiga_3.2.0-0ubuntu1.diff.gz 
>>>>>> does not show any change related to enabled codecs in ekiga...
>>>>>>
>>>>> I guess people enable everything.
>>>> I have done some limited search on the MTU topic and it seems the MTU
>>>> can vary along the patch. Beside large bandwidth can greatly benefit for
>>>> a larger MTU than 1500 and some people are pushing to have larger MTU in
>>>> this case. (I have a report with this case at hand here:
>>>> https://bugs.launchpad.net/ubuntu/+source/ekiga/+bug/380091 )I do not
>>>> know how the choice if 1500 is made inside OPAL; if it is hardcoded it
>>>> is probably a source of frame dropping in some case (and it happen
>>>> probably in silence). Around 1400 seems more safe but it seems to not
>>>> cover all cases.
>>>>
>>>> AFAIK a proper fix for this situation is to use a discovery mechanism
>>>> for the MTU: fortunately this exist in RFC:
>>>> http://tools.ietf.org/html/rfc4821
>>> OPAL does not touch the MTU.
>>>
>>> The MTU setting on a machine is an OS thing, not a user program thing.
>> (ARGH I only answered to Damien, reposting to the list, sorry Damien for
>> the noise...)
>>
>> It does not matter, even if your host has a 1500 MTU, the next hop in
>> the path can have a 1400 MTU (I agree this should be a rare case), thus
>> if you only take your host in account you'll be screwed.
>
> Anyway, the only clean solution is to use TCP.

By default? If we use UDP by default, then we need either the MTU
discover mechanism in the RFC, either to use a safer MTU value (1400
seems a reasonable choice), because AFAIK UDP has no mechanism for
fragmented packet and frames will be dropped silently if we are in the
bad range (close to 1500). Or maybe use the fact frame are dropped to
switch to TCP? Is there a way to know if frames has been dropped?
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Damien Sandras]

Le vendredi 10 juillet 2009 à 11:30 +0200, yannick a écrit :

> Damien Sandras a écrit :
> > Le vendredi 10 juillet 2009 à 11:17 +0200, yannick a écrit :
> >> Damien Sandras a écrit :
> >>> Le vendredi 10 juillet 2009 à 10:49 +0200, yannick a écrit :
> >>>>>>> That's what I thought. By default, only a few codecs are enabled.
> >>>>>> The bug is strange, since
> >>>>>> https://launchpadlibrarian.net/24407094/ekiga_3.2.0-0ubuntu1.diff.gz 
> >>>>>> does not show any change related to enabled codecs in ekiga...
> >>>>>>
> >>>>> I guess people enable everything.
> >>>> I have done some limited search on the MTU topic and it seems the MTU
> >>>> can vary along the patch. Beside large bandwidth can greatly benefit for
> >>>> a larger MTU than 1500 and some people are pushing to have larger MTU in
> >>>> this case. (I have a report with this case at hand here:
> >>>> https://bugs.launchpad.net/ubuntu/+source/ekiga/+bug/380091 )I do not
> >>>> know how the choice if 1500 is made inside OPAL; if it is hardcoded it
> >>>> is probably a source of frame dropping in some case (and it happen
> >>>> probably in silence). Around 1400 seems more safe but it seems to not
> >>>> cover all cases.
> >>>>
> >>>> AFAIK a proper fix for this situation is to use a discovery mechanism
> >>>> for the MTU: fortunately this exist in RFC:
> >>>> http://tools.ietf.org/html/rfc4821
> >>> OPAL does not touch the MTU.
> >>>
> >>> The MTU setting on a machine is an OS thing, not a user program thing.
> >> (ARGH I only answered to Damien, reposting to the list, sorry Damien for
> >> the noise...)
> >>
> >> It does not matter, even if your host has a 1500 MTU, the next hop in
> >> the path can have a 1400 MTU (I agree this should be a rare case), thus
> >> if you only take your host in account you'll be screwed.
> >
> > Anyway, the only clean solution is to use TCP.
>
> By default? If we use UDP by default, then we need either the MTU
> discover mechanism in the RFC, either to use a safer MTU value (1400
> seems a reasonable choice), because AFAIK UDP has no mechanism for
> fragmented packet and frames will be dropped silently if we are in the
> bad range (close to 1500). Or maybe use the fact frame are dropped to
> switch to TCP? Is there a way to know if frames has been dropped?

No because it is UDP => no feedback.
And the value indicating when to switch from udp to tcp is in the SIP
RFC. I think guessing the MTU is overly complex.

On the mid term, ekiga should fully switch to TCP, but I need to review
both teh RFC and the opal code to check routing is done correctly in
that case.
--
 _     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

[Eugen Dedu]

yannick wrote:

> Damien Sandras a écrit :
>> Le vendredi 10 juillet 2009 à 11:17 +0200, yannick a écrit :
>>> Damien Sandras a écrit :
>>>> Le vendredi 10 juillet 2009 à 10:49 +0200, yannick a écrit :
>>>>>>>> That's what I thought. By default, only a few codecs are enabled.
>>>>>>> The bug is strange, since
>>>>>>> https://launchpadlibrarian.net/24407094/ekiga_3.2.0-0ubuntu1.diff.gz 
>>>>>>> does not show any change related to enabled codecs in ekiga...
>>>>>>>
>>>>>> I guess people enable everything.
>>>>> I have done some limited search on the MTU topic and it seems the MTU
>>>>> can vary along the patch. Beside large bandwidth can greatly benefit for
>>>>> a larger MTU than 1500 and some people are pushing to have larger MTU in
>>>>> this case. (I have a report with this case at hand here:
>>>>> https://bugs.launchpad.net/ubuntu/+source/ekiga/+bug/380091 )I do not
>>>>> know how the choice if 1500 is made inside OPAL; if it is hardcoded it
>>>>> is probably a source of frame dropping in some case (and it happen
>>>>> probably in silence). Around 1400 seems more safe but it seems to not
>>>>> cover all cases.
>>>>>
>>>>> AFAIK a proper fix for this situation is to use a discovery mechanism
>>>>> for the MTU: fortunately this exist in RFC:
>>>>> http://tools.ietf.org/html/rfc4821
>>>> OPAL does not touch the MTU.
>>>>
>>>> The MTU setting on a machine is an OS thing, not a user program thing.
>>> (ARGH I only answered to Damien, reposting to the list, sorry Damien for
>>> the noise...)
>>>
>>> It does not matter, even if your host has a 1500 MTU, the next hop in
>>> the path can have a 1400 MTU (I agree this should be a rare case), thus
>>> if you only take your host in account you'll be screwed.
>> Anyway, the only clean solution is to use TCP.
>
> By default? If we use UDP by default, then we need either the MTU
> discover mechanism in the RFC, either to use a safer MTU value (1400
> seems a reasonable choice), because AFAIK UDP has no mechanism for
> fragmented packet and frames will be dropped silently if we are in the
> bad range (close to 1500). Or maybe use the fact frame are dropped to
> switch to TCP? Is there a way to know if frames has been dropped?

As I wrote on TCP bug, IPv4 does fragmentation (IPv6 does not).  No need
to worry about MTU other than the local one.  I can send my courses if
you wish :o)

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