Re: [GnomeMeeting-devel-list] Speex

["Olaf Conradi" <oohlaf gmail com>]

Hello,

On 12/03/06, Damien Sandras <dsandras seconix com> wrote:
> Hi!
>
> Le vendredi 10 mars 2006 à 23:29 +0100, Olaf Conradi a écrit :
> > Hello,
> >
> > I am testing Ekiga with the latest Debian snapshot (march 8th) to see
> > how it works with my Speex plugin for Yate.
> >
> > I noticed Ekiga was the first softphone I came across which sets the
> > SDP payload type to "SPEEX" and not "speex". Digging into the RFCs of
> > AVT payloads [1] it does say:
> >
> > "Note that the payload format (encoding) names defined in the RTP
> > Profile are commonly shown in upper case.  Media subtype names are
> > commonly shown in lower case.  These names are case-insensitive in
> > both places."
> >
>
> Yes it is case-insensitive.

Yes, I'll propose a change in Yate to handle this.


> > But the latest speex RFC [2] says:
> >
> > "When conveying information by SDP [4], the encoding name MUST be set
> > to "speex"."
>
> I will change it to lower case, but still, it is case-insensitive.

Thanks.
First of all, congratulations for getting Ekiga to a release today.
New website is looking fine.
I do have a comment on the mode handling though.

> > I did some testing between my codec and Ekiga and noticed Ekiga advertises this:
> >
> > m=audio 5018 RTP/AVP 101 110
> > a=rtpmap:101 telephone-event/8000
> > a=fmtp:101 0-15
> > a=rtpmap:110 SPEEX/8000
> >
> > If I respond with:
> >
> > m=audio 17002 RTP/AVP 110 101
> > a=rtpmap:110 speex/8000
> > a=fmtp:110 mode=5
> > a=fmtp:110 ebw=narrow
> > a=rtpmap:101 telephone-event/8000
> >
> > Then Ekiga does not pickup that the other side wants to use mode 5
> > (speex-nb-15k), not mode 3 (speex-nb-8k). The connection succeeds and
> > all Ekiga hears is garbage as speex decodes in the wrong mode.
> >
> > Why does Ekiga not request mode 3 if it does not cope with other modes
> > or accept other modes? The Speex RFC [2] does state mode 3 is default,
> > but both parties still have to agree.
>
> Ekiga doesn't support specifying modes for codecs. The SPEEX draft (it
> is not an RFC yet) is severely limited in that regard. The iLBC RFC
> tells for example that : the default mode has to be used except if both
> parties agree to use another mode. In this case, if you respond to my
> offer, you shouldn't try to use another mode than the one Ekiga
> requested (which is the default mode). So from my point of view, your
> answer is not correct...

Hmm, ok. I read the Speex RFC draft as: if the the offerer does not
specify a mode, assume it supports all modes. Ofcourse this is not
explicitly stated. Indeed, it does not accurately specify what to do.

After reading the iLBC RFC [1], I notice it assumes if unspecified
default mode is iLBC mode 30. But if offerer and answerer differ in
mode, the *lower bandwidth* one is preferred. So offer 30 (or not
specified) and answer mode 20 will result in mode 30 being used, which
happens to be the default.

Applying the "prefer lowest bandwidth mode" between offerer and
answerer to Speex will make my example from above (offerer requests -
unspecified - mode 3, answerer responds with 5) invalid and the lower
mode 3 shall be used.

But Speex supports 6 modes. So if I responded with mode 2, then mode 2
should be used.

Cheers,
Olaf

[1] http://www.ietf.org/rfc/rfc3952.txt