MIME Type Registration for RTP Payload Format for H.224
Extracted elements (14)
The H224 media type is defined so that signaling gateways between H.323 and SDP-based systems can support far-end camera control end-to-end without any protocol translation in the middle, since RTP packets in H.323 annex Q already carry H.224 frames.
Terminals sending simple far-end camera control commands should use the application/H224 MIME type. Receivers that cannot support the protocol will reject the channel.
The application/H224 media type is only defined for transfer via RTP; transport within other framing protocols is not defined. This constraint is stated in the media type registration.
The default clock rate in the SDP 'a=rtpmap' line MUST be 4800.
The encoding name in the SDP 'a=rtpmap' line MUST be 'h224' (the MIME subtype).
The media name in the SDP 'm=' line for application/H224 MUST be 'application', the transport SHALL be any applicable RTP profile, and the payload type is dynamic.
Usage of data origin authentication and data integrity protection of at least the H.323 annex Q packet is RECOMMENDED; SRTP is given as the example mechanism.
In the SDP Offer/Answer model, FECC communication is uni-directional for camera control but H.224 is bi-directional and can be used to negotiate capabilities (e.g., number of cameras). The offerer uses 'sendonly' if its camera cannot be remotely controlled and capability negotiation is not needed; otherwise 'sendrecv' is offered.
The far-end camera control protocol (FECC) is based on ITU-T H.281 frames carried in ITU-T H.224 packets over an RTP/UDP channel. H.323 annex Q specifies how to build RTP packets from H.224 packets; the FECC protocol is identified by the client ID field within the H.224 packet.
The recommended maximum bandwidth for the H.224 FECC protocol is 6.4 kbit/sec, as stated in Section 5.
RFC 4573 registers the MIME media type application/H224 for the RTP payload format carrying H.224 far-end camera control frames. The registration follows RFC 4288 and RFC 3555 procedures.
A denial-of-service threat exists because injected pathological datagrams can cause the receiver to move the camera to attacker-chosen positions. Data origin authentication and integrity protection (e.g., via SRTP) are RECOMMENDED to mitigate this.
H.224 payload packets are subject to the security considerations of RFC 3550 (RTP). Confidentiality is achieved by encryption; SRTP (RFC 3711) MAY be used to provide both encryption and integrity protection of the RTP flow.
Offer/Answer directionality for FECC: (1) Offerer sends 'sendonly' → answerer replies 'recvonly' if FECC is supported, else rejects. (2) Offerer sends 'sendrecv' → answerer replies 'sendrecv' if its camera is controllable or capability negotiation is intended; 'sendonly' if its camera is not remotely controllable; or rejects if FECC is unsupported.