[asterisk-users] changing the size of voice packets

[Dan Austin]

John Todd wrote:
> There was discussion recently (on -dev? on -users?
> on IRC?) about how there are some shortcomings on RTP
> packetization/transcoding.  It appears, though I have
> not confirmed this, that trying to move a 20ms G.711
> stream from a client, though Asterisk, to a remote
> gateway using 40ms G.711 will NOT work correctly.  The
> 20ms packet size is passed through without aggregating
> to 40ms, or vice versa - no change in packetization
> (though I don't know which side takes precedence.)
> Going the opposite directon for dis-aggregation
> (which is what you want to do) I assume would fail
> in similar ways.  I don't recall if changing the codec
> made any difference on the packetization between two
> bridged channels.

In the past (trunk pre-1.4 and 1.4) both handled
aggregation properly, with one important caveat:
        1. The media actually flows through Asterisk
                (no RTP re-invites)

If the media is re-invited, it is up to the clients/peers
To honor the packetization the remote end requested.

If the media is not reinvited and is 100% compatible,
codec and packetization, it will go through the
packet-to-packet bridge.  At one point the P2P bridge
did not know about packetization differences and would
just relay the RTP packets.  I believe that was fixed
a long time ago.


> For what it's worth, 10ms is the maximum rate for most
> codecs.  This creates twice as many packets as 20ms,
> three times as many as 30ms, etc. - hopefully your
> network hardware has sufficient power or your call
> volumes are reasonably low so as not to produce an
> overwhelming number of Packets Per Second (PPS).
> Decreasing sampling interval also gets you closer to
> reaching your NIC's threshhold of PPS, which often
> is not huge.

> I seem to recall asking the person who reported that to
> open a bug in Mantis, but I can't find it, though I didn't
> look exhaustively.  If you can verify this and/or it's
> relevant to you, please open a ticket so that it at least
> will be reviewed.  I'd open it myself, but I'm a bit
> resource constrained at the moment in an airport lobby.