Bug with iLBC mode negotiation (thanks Michael Smith for reporting)

[bennylp]

Michael Smith wrote:

Hi,

Asterisk uses a fixed iLBC packetization of 30 ms. pjsua defaults to 20 ms.
I can get the two to communicate if I tell pjsua to use 30 ms.

If I don't, pjsua encodes at 30 ms and decodes at 20 ms, even though
Asterisk thinks both directions are using 30 ms. This makes for some
interesting sounds. :)

According to the standard, if one side requests 30 ms, the other is
supposed to use it because it's the lowest bandwidth setting. (It's
pretty bizarre - even if the initiator offers mode=30, and the responder
replies with mode=20, they are both supposed to use mode=30.)

I found some notes about this at
​http://www.pjsip.org/trac/wiki/audio-check-codec-nego and
​http://www.pjsip.org/trac/ticket/40 but what the standard says is
different:

It is important to emphasize the bi-directional character of the
"mode" parameter - both sides of a bi-directional session MUST use
the same "mode" value.

The offer contains the preferred mode of the offerer. The answerer
may agree to that mode by including the same mode in the answer, or
may include a different mode. The resulting mode used by both
parties SHALL be the lower of the bandwidth modes in the offer and
answer.

That is, an offer of "mode=20" receiving an answer of "mode=30" will
result in "mode=30" being used by both participants. Similarly, an
offer of "mode=30" and an answer of "mode=20" will result in
"mode=30" being used by both participants.

• ​http://www.ietf.org/rfc/rfc3952.txt