[asterisk-dev] Codec Framing/Packetization limits

[Dan Austin]

> I posted a small document to Mantis yesterday to explain the
> usage and capabilities of the new RTP packetization options.

> It was quickly pointed out that the max values for many of the
> codec are lower than (what's the right word, reasonable? possible?
> viable?).  In any case here is a table of the current values.
> These values were picked based on what authoritative documentation
> that could be found, including RFCs and a number of Cisco whitepapers.
> While these values might be lower than any theoretical maximum, I
think
> they are safe/practical values.

Name            Min             Max             Default	Increment
g723            30              300             30              30
gsm             20              60              20              20
ulaw            10              30              20              10
alaw            10              30              20              10
g726            10              50              20              10
ADPCM           10              30              20              10
SLIN            10              70              20              10
lpc10           20              20              20              20
g729            10              230             20              10
speex           10              60              20              10
ilbc            30              30              30              30
g726_aal2       10              50              20              10

> Any comments or suggestions about any of the values would be
> appreciated, but I am most interested in what the Max values should be

> for each codec.

A comment on bugid 7989 shows that there maybe some confusion about
the current implimentation.  The max packetization values listed in
the table above ARE hardcoded.  This was done to apply sanity checks
when setting up the framing.  The values may be low, but are enforced,
so the code should be updated if a given codec can sanely support a 
larger packetization value.

The bug I opened to introduce the documentation is already closed, so
I cannot update it to include this clarification.

And the addition of chan_h323 to the list of supported channels is 
excellent news.

Dan