RFC 3952 (RTP format for iLBC) is somewhat vague on what the default
packetization period used is (20 or 30ms). There are sentences that
imply
it's 30ms, but it is not stated. Also, it's never stated what mode is
selected if the offer says mode=20 and the answer doesn't specify a
mode
(or vice versa).
From the RFC (somewhat unclearly worded):
If 20 ms frame size mode is used, remote iLBC encoder SHALL receive
"mode" parameter in the SDP "a=fmtp" attribute by copying them
directly from the MIME media type string as a semicolon separated
with parameter=value, where parameter is "mode", and values can be 0
and 20 (where 0 is reserved and 20 stands for preferred 20 ms frame
size). An example of the media representation in SDP for describing
iLBC when 20 ms frame size mode is used might be:
m=audio 49120 RTP/AVP 97
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20
This implies that the default is 30ms but doesn't state it. (The rest
of the RFC is agnostic either way.)
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.
What if there is no mode in the response?