h264 packetization mode for FUA

Question

We have got into couple of interop issues where, The video mode that is required by couple of endpoints in market are little different and only understands H.264 packetization modes (FUA type) (i.e) FU -A NAL unit type.(while others do not play the video on receiving a fu-a nal type payload)

Does anyone know what is this FUA type of packetization mode? How is it different from packetization modes 0,1,2 as defined in RFC3984? Is the video encoder/decoder supports it, how can it be appropriately signalled in SIP SDP session wherein the attributes do not get changed even when traversing through SIP B2BUAs?

Answer 1

I'm not sure if I understand your question correctly, but FU-A is not a packetization mode, it just signals that the NAL unit is a Fragmentation Nal Unit i.e. a NAL unit is fragmented over several RTP packets. RFC3984 table 3 shows that NAL FU-A can only be used in the interleaved and non-interleaved packetization modes (modes 1 and 2) i.e. not in single Nal Unit mode (mode 0).

As for encoder/decoder support: if the SDP signals packetization mode 1 or 2, it means that there might be FU-As in the RTP stream. This won't affect the decoder though RFC3894 section 7.1: "If a decapsulated packet is an FU-A, all the fragments of the fragmented NAL unit are concatenated and passed to the decoder."

I don't understand the last part of your question relating to the SIP B2BUAs, the SDP signals packetization modes and based on that the RTP receiver must be able to handle the different NAL unit types that are specified in RFC3984.

Answer 2

FUA is used in packetization modes 1 & 2. packetization-mode defaults to 0 (single-NAL mode); if both sides agree to modes 1 or 2 you will typically see an FU-A when a NAL exceeds the UDP MTU or configured maximum packet size.

The packetization/de-packetization layer should take NALs and generate FU-A's when needed, and on reception take a series of FU-A's and reassemble a NAL to feed to the decoder.

See RFC 3984 and RFC 3984bis (of which I'm an author).

A B2BUA should not accept or offer a packetization-mode it's not ready to process, though it may be simply passing through the offer/answer from the other UA.

Also note that (if compliant with RFC 3984) a UA must support packetization-mode 0, though it's not required to offer it on an INVITE.