DISA Interoperability Requirements - Video.xlsx
XLSX spreadsheet 351 KB Posted
- Solicitation number
- 612673989-001
- Issued by
-
Defense Information Systems Agency
About this file
This is a technical requirements specification document (DISA Interoperability Requirements - Video.xlsx) that establishes mandatory interoperability standards for video communications systems within the Department of Defense Unified Capabilities framework. The document comprises 22 detailed technical rules organized across multiple categories including Total Conversation, General Interoperability, Codecs, Media Control, Flow Control, and WebRTC specifications.
Core requirements mandate that Session Controllers (SCs), End Instruments (EIs), and Session Border Controllers (SBCs) comply with ITU-T F.703 Total Conversation standards to support simultaneous audio, video, and real-time text within single sessions. Systems must support video upgrade capabilities during active audio sessions using SIP re-INVITE procedures while maintaining session continuity, and preserve negotiated SDP media attributes across domain boundaries except where explicitly modified by policy. Mandatory baseline codecs include G.711 and H.264 Baseline Profile. Additional technical mandates address media-control preservation (including FECC), Binary Floor Control Protocol (BFCP) support per RFC 8855-8856, RTP/AVPF feedback mechanisms with legacy SIP INFO fallback support, and comprehensive WebRTC interoperability requirements including ICE candidate gathering (RFC 8445), DTLS-SRTP encryption (RFC 5764), STUN/TURN support, Opus audio codec preference with G.711 fallback, H.264 Constrained Baseline and VP8 video codec support, T.140 real-time text via SCTP data channels, RTCP muxing, and session recording capabilities. Severity levels range from High to Low, with most video interoperability requirements classified as High priority, reflecting their critical importance to DoD unified communications systems integration.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| DISA SD-WAN Interoperability Requirements Comprehensive.xlsx | XLSX spreadsheet | |
| DISA Interoperability Requirements - Chat.xlsx | XLSX spreadsheet | |
| DISA Interoperability Requirements - Voice.xlsx | XLSX spreadsheet | |
| UCR RFI_August 2026.pdf | ||
| UCR_RFI_Response_Template_28_JUL_2026.xlsx | XLSX spreadsheet |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Sheet1
| Group ID | Rule ID | STIG ID | SRG ID | Severity | Classification | Rule Title | Discussion | Notes | Check Text | Fix Text | Note | References |
| Video - Total Conversation | 0000010 | High | SCs, EIs, and conferencing systems MUST comply with ITU-T F.703 Total Conversation with specific support for simultaneous audio, video, and real-time text (RFC 4103) within a single session. | F.703 establishes the core multimedia service framework, such as session support for multimedia communications (audio, video, real-time text). Protocol, codec, conferencing, media control, and interoperability service concepts are implemented and supported leveraging the signaling mechanisms available via the SIPconnect 2.0 profile in combination with minimally extended capabilities required to support DoW external vendor components through applicable IETF RFCs. This approach outlines a robust core interoperability framework for unified communications. | 1. Establish multimedia SIP session. |
2. Verify audio, video, and RTT are negotiated.
3. Confirm all media streams are active simultaneously.
4. Verify SIP signaling supports all negotiated media.
5. Record pass/fail results. 1. Verify SDP includes audio, video, and RTT m-lines.
2. Ensure SIP endpoints support RFC 4103.
3. Add support for any missing codec or negotiation failures.
| 4. Re-test session. | ITU F.703 "Total Conversation", SIPconnect 2.0 (informative), RFC 4103 | |||||
| Video - General - Interoperability | 0000020 | High | EI, SC, and SBC MUST support the negotiation and establishment of video media during an active audio session using re-INVITE while preserving session continuity. | This requirement ensures SIP systems can upgrade an active audio session to include video using standard SIP offer/answer procedures. Session continuity improves interoperability between vendors and prevents call teardown during media upgrades. | 1. Establish an audio only VoIP session between Vendor A and Vendor B End Instrument (EI)s. |
2. Verify audio is established.
3. Initiate video upgrade request from Vendor A.
4. Capture SIP signaling of the upgrade.
5. Verify the session remains established.
6. Verify SIP session modifiers are compliant with SIP Connect (e.g., re-INVITE or UPDATE with SDP Offer/Answer).
7. Verify bidirectional video is established between both EI's.
8. Verify audio remains active throughout the escalation process.
9. Record pass/fail results. 1. Review SIP traces for failed or rejected session modification messages.
2. Confirm SC and SBC leveraged SIPconnect compliant re-INVITE behavior.
3. Verify SDP Offer/Answer negotiation was not impacted.
4. Verify video codec interoperability between EI's.
5. Verify policies do not block adding video streams during active sessions.
| 6. Correct any configurations and repeat re-test compliance. | ITU-T F.703, SIPconnect 2.0, RFC 3261, RFC 3264 | |||||
| Video - General Interoperability | 0000030 | Medium | SCs and SBCs MUST preserve negotiated SDP media capabilities and session attributes impacting interoperability, except where explicitly modified by policy or subsequent SIP negotiation. | This requirement preserves negotiated session attributes and media stream descriptions in SIP signaling from one domain to another as policy and security permits. Modification or removal of negotiated SDP attributes can cause codec mismatch, one-way media, or session failure across domains. | 1. Place a VoIP call from End Instrument A in Domain A to End Instrument B in Domain B. |
2. Capture SIP signaling at the originating End Instrument, ingress SBC, egress SBC, and terminating End Instrument.
3. Establish the session and compare SDP session attributes transmitted by End Instrument A with those received by End Instrument B.
4. Verify media attributes, codec information, media directions, RTP parameters, and session identifiers remain unchanged except where explicitly required by policy.
5. Verify audio and video communication functions as negotiated.
6. Record any modifications introduced by SCs or SBCs.
7. Record pass/fail results. 1. Review SIP traces to identify where negotiated SDP attributes were modified or removed.
2. Identify any policies removing required session attributes.
3. Confirm cross-domain interoperability profiles are consistently configured.
4. Correct any configuration or policy that alters negotiated media streams or attributes and repeat check procedure.
| SIPconnect 2.0, RFC 3264 (Offer/Answer), RFC 8866 (SDP) | |||||
| Video - Codecs | 0000040 | High | SCs and EIs MUST support G.711 and H.264 Baseline. | This requirement ensures baseline codec interoperability across SIP systems. | 1. Verify codec offer in SDP. |
2. Establish SIP or WebRTC session.
3. Confirm successful negotiation of mandatory codecs.
4. Verify audio/video interoperability.
5. Record pass/fail results. 1. Add any missing codecs.
2. Correct any SDP fmtp attributes and semantics
3. Ensure codec is supported
| 4. Re-test compliance | SIPconnect 2.0, RFC 6184, ITU-T G.711, RFC 7587 | |||||
| Video Media Control Preservation (e.g., FECC) | 0000050 | Medium | SCs MUST preserve media-control and conferencing-related SDP attributes (including FECC) end-to-end as pass-through signaling, even if the SC does not process or interpret these attributes. | SDP media-control signals such as FECC must not be dropped or modified to preserve functionality. | 1. Establish video session with FECC enabled. |
2. Capture SDP across network elements.
3. Verify FECC attributes remain unchanged.
4. Verify control functionality where supported.
5. Record pass/fail results. 1. Remove SBC/SC rewriting of media-control attributes.
2. Enable SDP transparency rules.
| 3. Re-test compliance. | SIPconnect 2.0, RFC 8866 | |||||
| Video - Binary Floor Control Protocol (BCFP) | 0000060 | Medium | Where floor control is required, the SC MUST support BFCP per RFC 8855 and SDP formatting specified in RFC 8856. | This requirement is intended to preserve interoperability with systems still leveraging BFCP. | 1. Initiate conference session. |
2. Verify BFCP negotiation.
3. Confirm floor control operation.
4. Record pass/fail results. 1. Verify BFCP is enabled on the SC.
2. Correct any configuration preventing BCFP operation.
| 3. Re-test compliance. | RFC 8855, RFC 8856 | |||||
| Video Flow Control RTP/AVPF | 0000070 | High | SCs and EIs MUST support RTP/AVPF feedback mechanisms (RFC 4585 and RFC 5104) and MUST support video recovery for legacy EI using SIP INFO-based 'Picture Fast Update' per RFC 5168. This legacy fallback MUST NOT replace RTP-based feedback mechanisms where available or be used in new deployments. | This requirement establishes RTCP as the preferred mechanisms for communicating and adapting media stream QoS. Legacy systems leveraging SIP INFO may still be supported exclusively for backward compatibility. | 1. Establish a video session through the SC. |
2. Induce packet loss conditions requiring generation of a new keyframe.
3. Confirm FIR/PLI/NACK response.
4. Verify SIP INFO support for legacy devices.
5. Record pass/fail results. 1. Verify RTP/AVPF feedback mechanisms are enabled on the SC and EI.
2. Verify PLI, FIR, and NACK is supported.
3. Verify SIP INFO for Picture Fast Update for legacy devices.
4. Correct any configurations preventing video recovery.
| 5. Re-test compliance. | RFC 4585, RFC 5104 | |||||
| Video - WebRTC | 0000080 | High | Where SIP-to-WebRTC interoperability is required, SCs or gateways MUST interwork SIP (RFC 3261/3264) with WebRTC media systems using SIPconnect procedures and WebRTC-compatible ICE (RFC 8445) and DTLS-SRTP (RFC 5764). Audio, video, and real-time text capabilities MUST be preserved through SDP negotiation and codec mapping between domains. | If a SC is required to serve as a WebRTC to SIP gateway, the requirements set out in Annex W seek to address the minimum set of requirements the SC must support to facilitate WebRTC-based EI's. | 1. Establish SIP-to-WebRTC call. |
2. Verify ICE negotiation.
3. Verify DTLS-SRTP establishment.
4. Verify audio/video/RTT interoperability.
5. Confirm successful media exchange.
6. Record pass/fail results. 1. Correct SDP/ICE configuration.
2. Fix codec mismatches.
3. Ensure DTLS-SRTP enforcement.
| 4. Re-test compliance. | SIPconnect 2.0, RFC 3261, RFC 3264, RFC 8445, RFC 5764, RFC 4103 | |||||
| WebRTC - SIPconnect Signaling | 0000090 | High | If the SC MUST serve as a WebRTC to SIP signaling gateway, then the SC MUST use SIP in compliance with the SIPconnect 2.0 interoperability profile. | Specifies use of the SIPconnect sip stack for signaling communications. | 1. Establish SIP-to-WebRTC call. |
2. Capture the SIP signaling.
3. Verify compliance with SIPconnect SIP profile semantics.
4. Log any failures.
5. Record pass/fail results.
1. Implement a SIPconnect compliant SIP stack.
2. Confirm installation.
| 3. Re-test compliance. | SIPconnect 2.0 | |||||
| WebRTC - SIP‑over‑Web Secure Socket (WSS) | 0000100 | High | If the SC MUST support WebRTC, the SC MUST accept SIP messages over a Secured WebSocket per RFC 7118. | This requirement improves security posture by mandating the use of WSS. | 1. Establish SIP-to-WebRTC call. |
2. Verify call is established.
3. Verify WSS is used via packet capture INVITE
4. Record pass/fail results. 1. Correct any WSS misconfiguration.
2. Ensure network connectivity configuration
3. Confirm connectivity to STUN/TURN/ICE
| 4. Re-test compliance. | RFC 7118, SIPconnect 2.0 | |||||
| WebRTC - T.140 Real-Time Text | 0000110 | Medium | If the SC MUST support WebRTC, the SC MUST support T.140 Real-Time Text using SCTP/Data Channel per RFC 8865 | This requirement facilitates T.140 compliant Real-Time Text compatible with WebRTC to maintain conceptual alignment with principles of Total Conversation in ITU-T F.703. | 1. Establish SIP-to-WebRTC call. |
2. Verify call is established.
3. Verify SCTP data channel is established.
4. Send T.140 RTT.
5. Record pass/fail results. 1. Correct any SCTP or data channel configuration issues.
2. Ensure the data channel is established successfully
3. Confirm text transmission and T.140 compliance.
| 4. Re-test compliance. | RFC 8865 | |||||
| WebRTC - ICEv2 | 0000120 | High | If the SC MUST support WebRTC, the SC MUST support ICE candidate gathering, connectivity checks, and ICE restart per RFC 8445 | This requirement facilitates NAT traversal and is required for WebRTC support. | 1. Establish SIP-to-WebRTC call. |
2. Verify call is established.
3. Verify SDP includes ICE candidates.
4. Verify ICE resolution in WebRTC internals.
| 5. Record pass/fail results. | 1. Correct any ICE connectivity and server configuration issues. | |||||
| 2. Re-test compliance. | RFC 8445 | |||||
| WebRTC - STUN/TURN | 0000130 | High | If the SC MUST service a WebRTC endpoint, the SC MUST support STUN/TURN per RFC 8489 and RFC 8656 | This requirement facilitates NAT traversal and is required for WebRTC support. | 1. Establish SIP-to-WebRTC call. |
2. Verify call is established.
3. Verify SDP includes ICE candidates and reflexive address.
4. Verify in WebRTC that ICE candidates match.
| 5. Record pass/fail results. | 1. Correct any STUN/TURN network connectivity issues | |||||
| 2. Re-test compliance. | RFC 8489, RFC 8656 | |||||
| WebRTC - DTLS‑SRTP | 0000140 | Medium | If the SC MUST support WebRTC, the SC MUST protect media using DTLS-SRTP per RFC 5764. | This requirement is a core WebRTC requirement. | 1. Establish SIP-to-WebRTC call. |
2. Verify call is established.
3. Verify SDP includes DTLS-SRTP setup semantics.
4. Verify encrypted media
5. Record pass/fail results. 1. Correct any misconfigurations
2. Correct any certificate issues
| 3. Re-test compliance. | RFC 5764, RFC 7983 | ||||
| WebRTC - DTLS Management | 0000150 | High | If the SC MUST support WebRTC, the SC MUST follow STIG approved certificate requirements. | 1. Establish SIP-to-WebRTC call. |
2. Verify per STIG instructions
| 5. Record pass/fail results. | 1. Follow STIG remediation. | |||||
| 2. Re-test compliance | RFC 5764 | |||||
| WebRTC - RTCP feedback | 0000160 | High | If the SC MUST support WebRTC, the SC MUST support FIR, PLI, NACK and Transport-Wide Congestion Control (TWCC). | This requirement is a core WebRTC requirement. | 1. Establish SIP-to-WebRTC call. |
2. Verify RTCP feedback negotiation in SDP.
3. Induce packet loss conditions requiring generation of a new keyframe.
4. Confirm FIR/PLI/NACK response.
5. Verify SIP INFO support for legacy devices.
| 6. Record pass/fail results. | RFC 5104, RFC 4585, | ||||||
| WebRTC - RTCP-MUX | 0000170 | High | If the SC MUST support WebRTC, the SC MUST support RTCP muxing and include the SDP attribute a=rtcp-mux indicating transmission and receiving of RTCP on the same port as RTP. | This requirement is a core WebRTC requirement. | 1. Establish SIP-to-WebRTC call. |
2. Verify a=rtcp-mux in SDP.
3. Confirm RTCP sender report and receiver reports.
4. Confirm call stays connected greater than 30s.
| 5. Record pass/fail results. | 1. Configure the endpoint for multiplexing | |||||
| 2. Re-test compliance | RFC 8035 | |||||
| WebRTC - TRICKLE ICE | 0000180 | Medium | If the SC MUST support WebRTC, the SC MUST support BUNDLE as per RFC 8840 when negotiated but MUST NOT require it. | This requirement is a core WebRTC requirement. | 1. Establish SIP-to-WebRTC call with BUNDLE enabled. |
2. Verify the SDP contains BUNDLE group attribute.
3. Confirm call stays connected greater than 30s.
4. Record pass/fail results. 1. Configure the endpoint to support BUNDLE
2. Correct any configuration that rejects non-BUNDLE.
| 2. Re-test compliance | RFC 8840 | |||||
| WebRTC - Audio codec | 0000190 | High | If the SC MUST support WebRTC, the SC MUST support and offer Opus (RFC 7587) as the preferred audio codec for WebRTC. G.711 MUST be supported as fallback for SIP interoperability. | This requirement is a core WebRTC requirement. | 1. Establish SIP-to-WebRTC call. |
2. Verify the SDP audio codec contains Opus as the preferred audio codec.
3. Confirm call connects greater than 30s with audio.
4. Record pass/fail results. 1. Add codec support to the SC.
2. Verify Opus is preferred for WebRTC endpoints.
3. Verify G.711 is enabled.
| 4. Re-test compliance. | RFC 7587 | |||||
| WebRTC - Video codecs | 0000200 | High | If the SC MUST support WebRTC, the SC MUST support H.264 Constrained Baseline Profile per RFC 6184 and VP8 per RFC 7741. | This requirement is a core WebRTC requirement. | 1. Establish SIP-to-WebRTC call. |
2. Verify the SDP video codec contains H264 Constrained Baseline Profile and VP8.
3. Confirm call connects with H264 and with VP8 endpoints.
4. Confirm call video stays connected greater than 30s.
5. Record pass/fail results. 1. Add codec support to the SC.
2. Verify H264 and VP8 are available for WebRTC endpoints.
| 4. Re-test compliance. | RFC 6184, RFC 7741 | |||||
| WebRTC - Media switch via re‑INVITE | 0000210 | Medium | If the SC MUST support WebRTC, the SC MUST support SIP re-INVITE to add, remove, or renegotiate media streams. | This requirement aligns with use of re-INVITE to modify existing sessions media streams elsewhere in the specification. | 1. Establish SIP-to-WebRTC call with audio only. |
2. Initiate an re-INVITE to add video.
3. Confirm video is added without terminating the session.
4. Initiate a re-INVITE that removes video
5. Confirm the call is audio only.
6. Initiate a re-INVITE that changes media parameters.
7. Confirm the session now uses the new parameters.
8. Record pass/fail results. 1. Review SIP trace for failed re-INVITEs
2. Verify policies and configuration do not block SIP re-INVITE and SDP Offer/Answer
3. Correct any configuration issues.
| 4.Re-test compliance. | SIPconnect 2.0, RFC 3261, RFC 3264, RFC 8445 | |||||
| Recording | 0000220 | Low | Recording SIP/WebRTC video/audio/text. | This requirements allows for session recording from SIP/WebRTC to a SRC (Recording Client). | 1. Establish SIP-to-WebRTC call. |
2. Verify SRS is capturable for call.
3. Begin capture on SRS. 1. Ensure video/audio/text was collected after recording stops or call ends. RFC 7866
Diagrams image1.png image2.png image3.png
File details come from the government source that posted it. Updated .