Packetizer

Abide by Framing in Audio Caps (Q54)


The information in this article applies to: H.323, H.225.0, H.245, G.711, G.723.1

Be careful about 6.2.1/H.225.0: "Transmitters may send any whole number of audio frames in each packet, up to the maximum stated by the receiver." Some vendors have been ignoring the maximum number of audio frames per packet that are indicated in the remote endpoint's receive capabilities and simply attempt to open an audio channel with whatever their, sometimes hard-coded, transmit capability is. This happens mostly with G.711, but we have also seen it with G.723.1.

The receiver is required to accept packets up to the maximum size it publishes in its receive capabilities, and a transmitter shall not send any more than what the receiver says it can accept. If a transmitter for some reason requests that an audio channel be established with a packet size larger than what the receiver can handle, the receiver would be prudent in rejecting the request. This would, of course, result in no audio and disappointed users, but that is better than risking unpredictable behavior in the receiver, such as locking up the entire endpoint.

An implementation that cannot adjust its transmit packet size to the capability of the receiver is not compliant. One workaround for the incoming direction is for a G.711 receiver to increase its receive caps to at least a maximum of 60 frames per packet in order to be interoperable with all of the non-compliant endpoints we have encountered (20, 30, 40, and 60 G.711 fixed frames per packet). A workaround for the outgoing direction is to open the channel with and encode the exact number of frames per packet that the remote EP indicates as its maximum receive capability if this is less than or equal to 60; if more than 60, use whatever you prefer up to what the remote EP indicates it can support. The idea is that if the remote indicates that its maximum number of frames per packet is something less than or equal to 60, there is a good chance that it is non-compliant and this is in reality the exact number of frames per packet that it requires, not the maximum. If greater than 60, this is probably the true maximum. This workaround is safe because it is compliant behavior and interoperable with compliant endpoints.