RTP Payload Format for the Secure Communication Interoperability Protocol (SCIP) Codec
Extracted elements (27)
SCIP does not require SRTP for payload protection because SCIP itself provides end-to-end encryption. SCIP also provides reliable transport at the application layer, making RTCP retransmission capability negotiation unnecessary.
SCIP is treated as opaque because it includes built-in mechanisms for protocol version negotiation and capability exchange. Middleboxes attempting to parse SCIP payloads serve no useful purpose and risk causing protocol ossification (as described in RFC 9170) as SCIP evolves.
Since SCIP payloads are integrity protected, any modification of the SCIP payload is detected as an integrity violation by SCIP endpoints, leading to retransmission and eventually communication failure—providing a strong incentive for network devices to relay payloads transparently.
The document takes the same approach as Clearmode (RFC 4040): rather than defining specific RTP payload content, packet size, or packet intervals, it enables endpoints to signal SCIP support and provides a transparent channel for SCIP communication. Codec-specific negotiation happens within SCIP control messages after RTP session establishment.
Additional augmented RTP mechanisms (FEC per RFC 5109, RTP/RTCP multiplexing per RFC 5761, symmetric RTP per RFC 4961, BUNDLE per RFC 9143) that do not modify the SCIP payload are OPTIONAL and discretionary for SCIP device vendors to implement.
SCIP is designed to be network agnostic and can operate over any digital link, including non-IP modem-based PSTN and ISDN. The scip media subtypes are specifically for SCIP operation over RTP.
Some network devices may not recognize SCIP and may remove the SCIP codecs from the SDP media payload declaration before forwarding to the next node; SCIP endpoint devices cannot operate if the SCIP media subtype is removed from the SDP declaration.
A clock rate of 8000 Hz SHALL be used for 'audio/scip'. A clock rate of 90000 Hz SHALL be used for 'video/scip'.
Applications that use RTP over UDP SHOULD implement their own congestion control above the UDP layer and MAY also implement a transport circuit breaker.
SCIP RTP traffic MUST NOT be filtered by network devices based upon what currently is observed or documented, as SCIP will continue to evolve. Network devices MUST NOT modify SCIP RTP packets.
The mapping of the payload format media subtype and its parameters SHALL be implemented according to Section 3 of RFC 4855. The SCIP device SHALL list the SCIP payload type number in order of preference in the 'm' media line per the SDP Offer/Answer model.
The Marker bit SHALL be set to zero for discontinuous traffic. The Marker bit for continuous traffic is based on the underlying media subtype specification.
The SCIP RTP header fields SHALL conform to RFC 3550. The Timestamp field MUST increment based on the sampling clock for discontinuous transmission as described in RFC 3550, Section 5.1.
There SHALL be no transcoding of the audio or video stream as it traverses the network, as stated in the encoding considerations for both 'audio/scip' and 'video/scip' media subtypes.
Transcoding, lossy compression, or other data modifications MUST NOT be performed by the network on the SCIP RTP payload. The 'audio/scip' and 'video/scip' data streams MUST be a transparent relay treated as 'clear-channel data'.
Use of the packet loss feedback mechanisms in AVPF and SAVPF are OPTIONAL because SCIP itself manages retransmissions of some errored or lost packets. Payload-specific feedback messages are OPTIONAL when transporting video data.
SCIP does not have its own upper layer syntax (no NAL units). Instead it encrypts the output of the audio and video codecs it uses (e.g., G.729D, H.264) after those have been formatted per their relevant RTP payload specification.
SCIP endpoints MAY employ inter-media RTP synchronization mechanisms (as described in RFC 8088, Section 3.3.4) to synchronize 'audio/scip' and 'video/scip' streams.
SCIP traffic may be continuous or discontinuous; both types are highly probable within a single SCIP session. Payload size and interval vary considerably depending on the state of the SCIP protocol within the device.
The SCIP application layer ensures all traffic sent to the RTP layer does not exceed MTU size. The receiving SCIP RTP layer handles packet identification, ordering, and reassembly; error detection and retransmission are handled at the SCIP application layer when required.
The SCIP RTP payload format consists of a standard RTP Header followed by a variable-length SCIP Payload. The payload is opaque encrypted content; its internal format is defined by SCIP-210 and is not parseable by the network.
The 'audio/scip' and 'video/scip' media subtypes were previously registered in the IANA 'Media Types' registry. This document updates those registrations to reference RFC 9607.
Applications SHOULD use one or more appropriate strong security mechanisms as per RFC 7201. Since SCIP provides end-to-end encryption, SRTP is not required for payload protection, but is OPTIONAL for header/RTCP protection.
SCIP only encrypts the contents transported in the RTP payload; it does not protect the RTP header or RTCP packets. Applications requiring additional RTP header and/or RTCP security might consider SRTP, though these mechanisms are OPTIONAL in this document.
The IETF was unable to conduct a security review of SCIP-210, which is not publicly available. Implementers must be aware that the IETF cannot verify any of the security claims contained in this document.
This RTP payload format does not exhibit significant non-uniformity in receiver-side computational complexity, does not pose a denial-of-service threat due to pathological data, and does not contain active content.
The SCIP RTP payload format is a standard RTP header (as defined in RFC 3550) followed by the SCIP Payload field of variable length. No additional framing, NAL units, or payload headers are defined between the RTP header and SCIP payload.