Summary

  • RFC 9607 registers audio/scip and video/scip, maps them into SDP, and requires networks to relay the variable encrypted payload without transcoding, filtering by observed structure, or modification.
  • SDP negotiates the use of SCIP, not the codecs and security state inside it; RTP delivery, endpoint reassembly, integrity acceptance, SCIP negotiation, peer identity and intelligible media are different receipts.
  • The RFC expressly says the IETF did not conduct a security review of SCIP and did not verify the security claims in the document.

The middlebox did exactly the right thing

A call crossed an IP network whose session border controllers had been updated to recognize audio/scip. The SDP offer bound dynamic payload type 96 to scip/8000. No device stripped the line. No transcoder opened the payload. Packet capture showed an RTP stream arriving at the destination with the negotiated number, plausible sequence movement and ciphertext that the network could not interpret.

That is a meaningful operational success. Before RFC 9607, a device that treated an unfamiliar pseudo-codec as invalid could remove it from the media declaration and prevent SCIP endpoints from operating. Registration gives manufacturers and administrators a common name for permitting a transparent channel.

But the capture is not a secure-call certificate. It does not reveal whether all SCIP fragments were reassembled, whether a retransmission closed the loss, which inner codec the endpoints selected, whether the intended peer was authenticated, whether the required cryptographic properties held, or whether the receiver decoded a single useful sentence. The network proved restraint. The endpoints still had work to do.

A media subtype is permission to carry, not authority to inspect

SCIP runs at the application layer and uses RTP as a basic transport. RFC 9607 deliberately asks the network to know less, not more. audio/scip and video/scip identify an opaque class of traffic whose packet size and interval can change with protocol state and underlying media. The network must not transcode it, apply lossy compression, modify it, or filter it according to today's apparent bit pattern.

This is an anti-ossification rule with an economic consequence. A middlebox vendor may be tempted to turn present observations into a classifier, optimization or compliance feature. The feature then becomes a hidden compatibility veto: a later SCIP version changes its shape, the box calls the unfamiliar traffic defective, and two conforming endpoints fail because an intermediary believed its model was authoritative.

The narrow shared contract is more durable. Recognize the declared subtype. Preserve the SDP mapping. Carry the RTP packets. Leave the encrypted application protocol to the endpoints. Running code retains room to evolve because the forwarding path does not demand that every future SCIP message resemble yesterday's capture.

SDP opens the corridor; SCIP decides what travels inside

RFC 9607 assigns an 8000 Hz clock to audio/scip and a 90000 Hz clock to video/scip. The SDP m= line names audio or video; a=rtpmap binds a dynamic payload number to scip and the clock rate. In offer/answer, the device lists its preferred payload types in order.

Those lines answer bounded questions. Did the parties express willingness to use the SCIP pseudo-codec? Which number identifies it in this session? Which RTP clock applies? They do not negotiate the encapsulated audio or video codec. SCIP performs its own later capability exchange and protocol-version negotiation inside the opaque channel.

The distinction prevents a familiar monitoring error. A successful SIP/SDP transaction is sometimes promoted into a green “secure media established” state. Here it proves only that signaling preserved a candidate media mapping. The next receipts belong to RTP arrival, reassembly, SCIP control exchange, cryptographic acceptance, decoder output and the application. Each can fail while the SDP remains immaculate.

MTU compliance ends where reassembly begins

The SCIP application layer is responsible for handing RTP traffic that does not exceed the MTU. At the receiver, the SCIP RTP layer identifies packets, orders them and reassembles the message. When required, the SCIP application layer detects errors and manages retransmission.

This creates at least four different facts. An emitted packet fitted the path's assumed limit. An RTP packet arrived with a sequence position. A complete SCIP unit was reassembled. The application accepted the unit after its integrity rules and any recovery. One counter cannot stand in for all four.

A dashboard that counts only received RTP packets can therefore overstate usable delivery. Duplication, reordering, loss at a fragment boundary or a retransmission that arrives after the application deadline may leave packet counts healthy and the reconstructed message absent. Conversely, an integrity failure followed by successful recovery should not be recorded as permanent session failure. Evidence has to preserve the transition, not just the last color shown by the transport panel.

Integrity rejection is evidence of a veto, not of success

RFC 9607 says SCIP payloads are integrity protected: modification is detected at the endpoint, causing retransmission and eventually communication failure. That is valuable local veto power. The network cannot silently “improve” encrypted media by changing it.

The veto does not certify the rest of the session. Seeing an integrity alert proves that one protected object failed acceptance under one endpoint's state. It does not attribute the cause to an attacker rather than corruption, misbinding or implementation error. It does not show whether the retransmission arrived. Silence from the integrity counter does not prove complete reception, correct peer identity or decoded meaning.

Operators should therefore record the protected unit identifier, endpoint, direction, RTP sequence range, verification result, recovery request, replacement arrival and application disposition. “Integrity enabled” is configuration. “Integrity failure observed” is an event. “Recovered and rendered before deadline” is an outcome. These are not synonyms.

Encrypted payload leaves other surfaces outside the envelope

SCIP encrypts the contents transported in the RTP payload. RFC 9607 also states that this does not protect the RTP header or RTCP packets. An application that needs additional header or control-plane protection may use SRTP, but the payload-format document treats that choice as optional.

The word “secure” in the protocol name must not erase that scope boundary. A protected payload can coexist with exposed timing, sequence, synchronization-source and control information. An RTP/SAVP or SAVPF profile introduces another protection layer, with its own keys, replay handling, overhead and failure modes. RFC 5124's protected feedback machinery is not automatically present merely because the inner SCIP media is encrypted.

This also separates two forms of authority. RTP and its profiles decide how the transport envelope is interpreted and, when selected, protected. SCIP decides how its application messages negotiate capability, establish a secure session and protect inner content. Neither layer's success allows an observer to invent the other layer's receipt.

Publication did not turn a claim into an IETF security verdict

RFC 9607 contains an unusually direct caveat: the IETF did not conduct a security review of SCIP and therefore did not verify the claims in the document. The standards-track output defines the RTP payload format and media registrations. It does not certify the complete SCIP protocol.

This is not a reason to dismiss the RFC. It is a reason to use it accurately. The document can authoritatively specify the shared transport seam while disclosing that the inner security system remains outside the review represented by publication. Such honesty makes procurement and assurance more precise: conformance to RFC 9607 can be tested through SDP and RTP behavior; claims about peer authentication, key management, confidentiality or resistance to attack need their own evidence.

Treating the RFC number as a security seal would reverse the architecture. A minimal interoperability contract would become a centralized judgment about a protocol the IETF explicitly says it did not review. Leadership should instead demand the specific receipt relevant to each risk.

Sources