DISA Interoperability Requirements - Voice.xlsx
XLSX spreadsheet 1 MB Posted
- Solicitation number
- 612673989-001
- Issued by
-
Defense Information Systems Agency
About this file
This file is a technical interoperability requirements spreadsheet for DISA Voice systems, detailing specific compliance standards and testing procedures for Session Controllers (SCs) implemented through combined Session Border Controllers (SBCs) and Policy Switch Routers (PSX).
The document specifies 21 distinct voice interoperability requirements organized by functional category, each with assigned severity levels, rule identifiers, and detailed check and fix procedures. Key requirements include: SIPconnect 2.0 certification compliance; support for recording capabilities via Feature-Caps headers; NTPv4 synchronization within 1 millisecond; E.164 and DNS-based routing with longest-prefix matching; RFC 5626 outbound registration support; STIR/SHAKEN implementation per RFC 8225; SBC B2BUA normalization of SIP signaling; Binary Floor Control Protocol (BFCP) traversal; V.150.1 modem relay SDP attribute transparency; DTMF interworking per RFC 2833, RFC 4733, and Telcordia GR 506; G.711 codec support at 20ms sampling rates with echo cancellation per ITU-T G.168; Vacant Code Announcement (VCA) signaling; proper SDP media directionality handling without c=0.0.0.0 notation; SCIP payload support for secure voice; ANAT SDP semantics preservation; session persistence during media inactivity; REFER-based and INVITE/re-INVITE transfer support; P-header selective removal; RFC 4028 Session Timer enforcement with mid-dialog UPDATE requests; and ICE/STUN/TURN support with symmetric NAT fallback. Each requirement includes specific test procedures to verify compliance and remediation steps for failures, ensuring interoperability across Department of Defense unified capabilities voice systems.
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 - Video.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
| Category | Group ID | Rule ID | STIG ID | SRG ID | Severity | Classification | Rule Title | Discussion | Notes | Check Text | Fix Text | Note | References |
| Note: Within this solution, 'Session Controller (SC)' refers to the logical role fulfilled by the combined operation of both the Session Border Controllers (SBC) and the Policy Switch Router (PSX) | |||||||||||||
| Voice | Signaling | 0000100 | High | Unknown | The SC (as may be implemented by a SBC and Policy Switch Router) must be SIPconnect 2.0 compliant with certification via the SIP Forums "SIPconnect Certification Testing Program". The SC must use SIPconnect compliant signaling mechanisms for session interoperability unless otherwise specified by appropriate STIGs, policy, or the requirements herein. | The SIP Connect 2.0 profile provides an open standard and suitable core signaling architecture necessary for progressive interoperability. All necessary signaling mechanisms required to facilitate routine Voice Over IP calls are defined and the requirements herein serve to extend functionality of SIP Connect to support Military Unique Features. | Within this solution, 'Session Controller (SC)' is a logical role fulfilled by the combined operation of Session Border Controllers (SBC) and PSX Policy Server | 1. Obtain the certification Test Plan V. 1.1.0: https://www.sipforum.org/download/sipconnect-certification-test-plan-v1-0-pdf/?wpdmdl=2751 |
2. SIP testing tool is available at: https://www.iol.unh.edu/testing/ip/sip/sipconnect/tool
3. Test compliance
| 4. Record pass/fail. | SIPconnect, SIP Forum | |||||||
| Voice | Recording | 0000110 | Medium | Unknown | The SC must support the interoperability of EI's signaling of recording capabilities and maintain recording states and session information. | Failure to preserve or translate recording capabilities can cause interoperability issues with secure systems leveraging call recording across SC interfaces. While commercial networks use the Feature-Caps framework, defense environments may require distinct session state tracking. The SC must then normalize these to prevent downstream recording servers or EI from losing track of mandatory recording states | 1. Send an INVITE with Feature-Caps header containing the features option tag per RFC 6809. |
2. Ensure the header is preserved in both directions.
3. Ensure policy‑based rejection occurs only when recording support is required and is unavailable.
4. Record pass/fail. 1. Configure the SIP recording‑related header.
2. Configure policy‑based rejections to only occur when recording support is requested and unavailable.
| 3. Re-test. | RFC 7866, RFC 6809 | |||||||
| Voice | NTPv4 | 0000120 | Medium | Unknown | The SC must synchronize its system clock within 1 millisecond of an authoritative reference source utilizing NTPv4. Devices must treat NTP adjustments exceeding this threshold as untrusted and no longer used until manually reviewed and the source validated by an operator. | This ensures the accuracy of timestamps used for compliance measures. Once adopted by relevant STIG authors, this requirement may be deprecated. | 1. Query the SC using an authorized auditing tool |
2. Verify the SC actively rejects unauthenticated NTP synchronization attempts.
3. Ensure no more than 1 millisecond of system time drift is observed from the source.
| 4. Record pass/fail. | 1. Verify the SC is configured to utilize NTPv4 with approved NTPv4 sources. | |||||||
| 2. Re-test. | RFC 1305, RFC 5905, RFC 8915, | |||||||
| Voice | E.164 | 0000130 | High | Unknown | The SC must be able to look up both numeric E.164 prefixes and DNS routes at the same time and select the longest‑prefix match. | The DoW uses both traditional telephone numbers E.164 and DNS based service names. If the SC can only use one table, calls could fail. | 1. Check the routing configuration from the PSX |
2. Verify that two separate tables exist, one for numeric prefixes and one for DNS names.
3. Send a SIP INVITE that contains an E.164 address that also matches a DNS entry.
4. Confirm that the longest prefix rule was applied.
5. Repeat with a call that only matches a DNS rule.
6. Record pass/fail. 1. In the PSX’s routing, create any missing tables.
2. Populate the E.164 table with the official DoW prefix list.
3. Populate the DNS table with the approved DoW SIP‑URI patterns.
4. Configure the longest prefix match rule.
5. Re-test.
| Voice | Outbound | 0000140 | The SC must implement support for RFC 5626 such that remote devices requiring it can maintain reliable registrations. | RFC 5626 aligns to support STIR/SHAKEN. In addition, devices encountering call‑setup failures could re‑REGISTER continuously. | 1. Register a device using the “flow‑token” parameter. 2. Shut down the device’s connection and restart it; verify the SBC accepts the re‑registration using the stored flow‑token without a full re‑Authenticate. 3. Record pass/fail. | 1. Enable SIP Outbound on the SBC, set “flow‑token‑expiry” per policy. 2. Re‑test registrations. | RFC 5626 |
| Voice | STIR/SHAKEN | 0000150 | The SC must support STIR/SHAKEN per RFC 8225 | SIPconnect does not cover STIR/SHAKEN. The SC policy routing must periodically fetch the latest STI signing certificate, validate the certificate chain (CRL or OCSP), and reject PASSporT tokens signed with a certificate older than the configured rollover window | 1. Place a call and capture the outbound SIP INVITE from the SBC. |
2. Verify an Identity header is present per policy.
3. Record pass/fail. 1. Configure PSX REST endpoint to STI.
2. Enable SBC “STIR/SHAKEN failure policy” (Reject, Continue, Strip).
| 3. Re‑test. | STIR/SHAKEN RFC 8225 | |||
| Voice | SBC | 0000160 | The SBC component functioning as a Back-to-Back User Agent (B2BUA) must normalize all SIP signaling required to support the interworking of any required external vendor components. | |
| The SBC must be the endpoint for incoming SIP sessions, first answering as a SIP user agent on behalf of the callee, and then sending a new SIP INVITE as the caller to the end-instrument on the line-side. |
The SBC must normalize SIP signaling to support any required external vendor components that require SIP headers, SDP attributes, and codec rules to function.
The SBC must further stop any incoming media stream, apply any required policies and then launch a fresh media stream toward the destination. The routing decision (either a 302 Redirect or a URI) must be supplied by the component serving as the PSX Policy Server. 1. Capture SIP at the SBC.
2. Send a test INVITE with a standard headers and any non-standard required header.
3. Capture the outbound INVITE and confirm the standard headers and any required headers are removed or present per policy.
4. During the call, capture RTP and confirm the stream stops at the SBC and a new RTP stream is sent out with the agreed codecs.
5. Look at the SBC or PSX log and confirm the routing.
Record pass/fail. 1. Configure the SBC component to function as a B2BUA.
2. Configure any required SIP normalization mechanisms such as munging or adjusting endpoint profile configurations.
3. Configure routing and connection information if PSX role is served by a separate component.
4. Re-test.
Voice Binary Floor Control Protocol (BFCP) 0000170 The SC must support Binary Floor Control Protocol (BCFP) The SC, combined SBC and PSX, must support the traversal of BFCP traffic contained in the SIP signaling through NAT and in the same dialog. 1. Make a test call leveraging BFCP
2. Capture the network traffic
3. Confirm BFCP packets are present and unchanged
4. Record pass/fail. 1. Enable BFCP.
2. Configure network settings.
3. Configure NAT for signaling.
4. Enable BFCP within the SIP call.
| 5. Re-test. | RFC 4582 | |||||||
| Voice | V.150.1 Modem Relay | 0000180 | High | Unknown | The SC must forward and must not drop or modify V.150.1 SDP attributes. | This requirement preserves interoperability with Modem-over-IP architectures where commercial SC may change or remove V.150.1 SDP attributes, breaking interoperability. The SC must treat V.150.1 SDP attributes as transparent and forward them unchanged. (e.g., "versn" and "jmdelay") | 1. Initiate a test call using a modem-over-ip endpoint profile. |
2. Inspect the outbound SDP offer/answer exchange to ensure expected attributes are unmodified.
3. Record pass/fail. 1. Configure the SC profile to ignore V.150.1 SDP attributes.
2. Modify any SDP munge rules to ensure strict attribute transparency for V.150.1 signaling
| 3. Re-test | AS-SIP 2013 11.2.1; ITU-T Recommendation V.150.1 | |||||||
| Voice | Dual Tone Multi Frequency (DTMF) | 0000190 | High | Unknown | The SC must support DTMF interworking per RFC 2833, RFC 4733, SIP INFO, and tone code handling compliant with Telcordia GR 506 CORE. | Improper DTMF processing affects interactive services, call control functions, and signaling interoperability. This elevates the SIP Connect 2.0 tone code handling for compliance with Telcordia GR 506 CORE which supports EI interoperability. | 1. Establish a test call to another end instrument or IVR. |
2. Verify that the SC processes DTMF tones in-band.
3. Verify that the SC processes out-of-band
4. Verify that telephone events are present and the SC recognizes tone codes per Telcordia GR 506 CORE.
5. Record pass/fail 1. Update relevant components of the SC.
2. Ensure the SC is properly configured.
3. Ensure signaling includes the required telephone‑event payload handling.
| 4. Re-test | Telcordia GR 506 CORE 4.2.5; RFC 2833, RFC 4733 | |||||||
| Voice | Media G.711 | 0000200 | High | Unknown | The SC must support G.711 at a sampling rate of 20ms. | The default sample rate for G.711 in the SIP Connect 2.0 profile 'should' be 20ms. This elevates the requirement to a 'must' as non-default sampling rates may break compatibility with legacy EI’s and legacy components expecting a sampling rate of 20ms. | 1. Establish a test call. |
2. Capture a G.711 RTP stream and verify each packet carries 20 ms of audio (160 samples for μ-law or A-law).
| 3. Record pass/fail | 1. Configure the G.711 media packetization interval to 20 ms for all compliant call paths. | |||||||
| 2. Re-test. | SIPconnect; AS-SIP 2013 | |||||||
| Voice | Echo Cancellation and Voice Supported Codecs | 0000210 | High | Unknown | The SC must support the following codecs with echo cancellation where echo can be produced and per ITU‑T G.168. Baseline G.711 U/A, G.729 | Incomplete codec support or failure to cancel echo can cause degraded media and communication quality. SIP Connect 2.0 leans heavily on Offer/Answer and to ensure interoperability, echo cancellation for voice codecs must be supported by the SC. | 1. Establish a call offering one or more codecs in an INVITE. |
2. Using a packet capture tool, verify inclusion in the 200 OK
3. Verify RTP echo return loss of at least 20 dB per ITU‑T G.168
4. Record pass/fail. 1. Configure the SC to enable all required codecs.
2. Configure packetization intervals.
3. Configure echo‑cancellation parameters to meet ITU‑T G.168
4. Re-test Voice Vacant Code Announcement 0000220 High Unknown The SC must support signaling of VCA for playback at the EI and may serve as the media server. Failing to support or play VCA may interrupt or break protected hotline calling functionality. Returning a different error code or omitting the VCA can additionally confuse callers, hide network‑reachability issues, and violate service‑announcement policies. 1. Dial an undefined DSN from an end instrument.
2. Verify the SC returns 404 Not Found, plays the VCA audio (if configured), and then sends BYE.
3. Record pass/fail. 1. Configure VCA for undefined DSN numbers
2. Map the appropriate announcement resource.
3. Configure sending of BYE.
| 4. Re-test | AS-SIP 2013 4.1.5 | |||||||
| Voice | Media directionality | 0000230 | High | Unknown | When placing a call on hold with or without Music on Hold (MoH), the SC must not set c=0.0.0.0 when setting the media directionality attribute to a=inactive or a=sendonly and must use the EI or media server SIP URI formatted per RFC 4566. | Improper media state signaling can cause interoperability issues, media loss or noncompliant hold behavior and/or early termination of calls. SIP Connect 2.0 compliance supports the option of setting c=0.0.0.0 for legacy support. This ambiguity may may cause interoperability issues with legacy devices downstream. This requirement is intended to remove the option and improve interoperability. | 1. Place a call on hold |
2. Verify SDP contains a reachable media‑server address, proper directionality, and no c=0.0.0.0 line.
3. Record pass/fail 1. Configure MoH 2.Configure a designated media server and RFC 4566 compliant SDP hold semantics.
| 3. Re-test | AS-SIP 2013 4.1.9, RFC 4566 | |||||||
| Voice | SCIP Payload | 0000240 | High | Unknown | The SC must support SCIP‑214, 215, 216 as applicable for V.150.1 modem relay as per RFC 9607 | Failure for SCIP payloads to passthrough the SDP Offer/Answer prevents secure high‑assurance voice interoperability. Since SCIP leverages its own encapsulation, it is only necessary to negotiate the use of SCIP within the SDP Offer/Answer per RFC 9607 | 1. Send an INVITE with a=rtpmap:97 scip/8000 |
2. Verify the SC returns a 200 OK
3. Verify media is protected with SRTP. 1. Add SCIP to allowed codec processing
2. Configure secure media negotiation when SCIP is selected.
| 3. Re-test | AS-SIP 2013 11.2.1, RFC 9607 | |||||||
| Voice | ANAT SDP Semantics | 0000250 | High | Unknown | The SC must preserve ANAT semantics per RFC 4566 and use the same UDP port for related streams. | Improper ANAT handling can disrupt dual‑stack media negotiation and related stream coordination. This requirement is to support backwards compatibility with legacy AS‑SIP systems. | 1. Initiate a dual‑stack INVITE |
2. Verify address‑type attributes are present for each related media line and that the port number remains identical across them where required.
3. Record pass/fail 1. Configure transparent ANAT SDP handling.
2. Configure stream-related port behavior.
| 3. Re-test | AS-SIP 2013 5.2.5; RFC 4566 | ||||||
| Voice | Session Termination | 0000260 | Unknown | The SC must not terminate an established SIP session due to media inactivity unless an authorized termination trigger occurs. | An established session must remain up indefinitely during media silence unless terminated by one of four authoritative events: an expired RFC 4028 Session Timer, an inbound BYE message, an overriding signaling request (such as a higher-priority preemption), or the mid-call revocation of a participant’s PKI certificate. Improper session termination can drop valid calls, reducing operational reliability. | 1. Establish a valid call and completely mute or stop the media stream on both End Instruments (EIs). |
2. Keep the signaling path alive.
3. Verify that the SC does not drop the call.
4. Record pass/fail 1. Configure SIP session timers
2. Configure dialog state handling
3. Configure certificate validation
4. Configure media renegotiation so that sessions persist unless terminated by an authorized trigger.
| 5. Re-test | AS-SIP 2013 4.2.8; RFC 4028 | ||||||
| Voice | Transfers | 0000270 | Unknown | Both REFER‑based and INVITE/re‑INVITE‑based transfers must be supported; the SC shall preserve the original Call‑ID and add a Referred‑By header on the outbound INVITE | Inconsistent domain treatment behavior can cause routing errors and failures. The SC must accept and process REFER and Refer-To URIs. SIP Connect 2.0 allows REFER or INVITE/re-INVITE. This requirement elevates the profile to support REFER and INVITE/re-INVITE to preserve interoperability. | 1. Initiate a call transfer from an EI using a sip re-INVITE method. |
2. Trace the signaling and ensure the SC processes the target address contained in the header.
3. Repeat using the REFER method.
4. Verify the Referred-By header is present at the INVITE generated by the SC.
5. Record pass/fail. 1. Configure the SC to use re-INVITE when supported.
2. Configure the SC to use SIP REFER when re-INVITE is not supported per RFC 5589.
| 3. Re-test. | AS-SIP 2013; RFC 5589 | ||||||
| Voice | SIP P‑Headers | 0000280 | Unknown | The SC must support the selective removal of P‑headers when forwarding SIP messages over a public interface. | The SC as implemented, must preserve the P-header group internally. External SIP communications may be required to selectively strip certain headers to comply with DoW policy while leaving others to facilitate interworking with required external vendor components. | 1. Send a test SIP INVITE to an internal end instrument containing standard test P-headers. |
2. Capture the outbound SIP message on internal interfaces egress and verify that every header is present and unmodified.
3. Record pass/fail. 1. Configure the SC to preserve all P-headers.
2. If applicable, configure the public facing SBC interface to strip P-headers to comply with relevant STIG authority.
| 3. Re-test. | AS-SIP 2013 | ||||||
| Voice | SIP Timers | 0000290 | Unknown | The SC must support RFC 4028 Session Timers. The SC must support configurable Session-Expires, Min-SE, and execute mid-dialog UPDATE requests at one-half of the negotiated Session-Expires interval. | SIPconnect treats session timers as optional. This requirement elevates RFC 4028 to a must. The SC must properly process the timer option tag and enforce sections 7.1, 7.2, 7.3, 7.4, and 10 of RFC 4028. Enforcing the generation of a session refresh using the UPDATE method (per Section 10) at the half-interval point ensures network state is reliably preserved. | 1. Establish a test call session |
2. Confirm via a network packet analyzer that the SC refreshes the session
3. Confirm the SC transmits a mid-dialog UPDATE request without an SDP offer at exactly half of the negotiated Session-Expires duration.
| 4. Record the pass/fail. | 1. Configure the SC's global signaling profiles to enforce RFC 4028 behavior. | |||||
| 2. Re-test. | AS-SIP 2013; RFC 4028; RFC 3311 | |||||
| Voice | ICE/STUN/TURN | 0000300 | The SC must support ICE/STUN/TURN. If ICE fails, the SBC must fall back to symmetric‑NAT handling. | SIPconnect does not require ICE‑based media traversal. The SC as implemented must support ICE (RFC 8445) with fallback to symmetric‑NAT handling. | 1. Place a call from a behind NAT end instrument “a=candidate”. |
2. Verify the SBC component returns ICE candidates and that the media is established successfully.
3. Record pass/fail. 1. Enable ICE on the SBC component
2. Configure STUN/TURN
3. Re‑test. RFC 8445, RFC 4582
Diagrams image1.png
File details come from the government source that posted it. Updated .