defense information systems agency -...

Joint Interoperability Test Command (JTE) 7 Nov 13 MEMORANDUM FOR DISTRIBUTION SUBJECT: Joint Interoperability Certification of the TEO Technologies 78XX, 4104, and 4101

with Software Release xx.04.13 References: (a) Department of Defense Instruction 8100.04, "DoD Unified Capabilities (UC)," 9 December 2010 (b) DoD CIO, Memorandum, "Interim Guidance for Interoperability of Information Technology (IT) and National Security Systems (NSS)," 27 March 2012 (c) through (f), see Enclosure 1 1. Certification Authority. References (a) and (b) establish the Joint Interoperability Test Command (JITC) as the Joint Interoperability Certification Authority for the Unified Capabilities (UC) products. 2. Conditions of Certification. The TEO Technologies 78XX, 4104, and 4101 with Software Release xx.04.13; hereinafter referred to as the System Under Test (SUT), meets the critical requirements of the Unified Capabilities Requirements (UCR), Reference (c), and is certified for joint use as a voice only, non-secure Assured Services Session Initiation Protocol (AS-SIP) End Instrument (EI) (AEI) with the conditions described in Table 1. The SUT was tested and is certified for use specifically with REDCOM HDX and REDCOM SLICE 2100 Local Session Controllers (LSCs). The SUT was also tested and is certified for use with the NEC Univerge 3C LSC, which is undergoing final certification for placement on the UC Approved Products List (APL). This certification expires upon changes that affect interoperability, but no later than three years from the date of this memorandum.

Table 1. Conditions

Condition Operational Impact Remarks

UCR Waivers None.

Conditions of Fielding None.

Open Test Discrepancies The SUT does not support DHCPv6. Minor

LEGEND DHCPv6 Dynamic Host Control Protocol version 6 SUT System Under Test

UCR Unified Capabilities Requirements

DEFENSE INFORMATION SYSTEMS AGENCY P. O. BOX 549

FORT MEADE, MARYLAND 20755-0549

IN REPLY REFER TO:

JITC Memo, JTE, Joint Interoperability Certification of the TEO Technologies 78XX, 4104, and 4101 with Software Release xx.04.13

2

3. Interoperability Status. Table 2 provides the SUT interface interoperability status and Table 3 provides the Capability Requirements (CR) and Functional Requirements (FR) status. Table 4 provides a UC APL product summary.

Table 2. End Instrument Interface Status

Interface Threshold CR/FR Requirements Status Remarks

Voice EIs

10Base-X (R) 1, 4, 5, 6, 7, 8, 9, 10, and 11 Met The SUT met the CRs and FRs for the IEEE 802.3i interface.

100Base-X (R) 1, 4, 5, 6, 7, 8, 9, 10, and 11 Met The SUT met the CRs and FRs for the IEEE 802.3u interface.

1000Base-X (C) 1, 4, 5, 6, 7, 8, 9, 10, and 11 Not Tested The SUT does not support this conditional interface.

10GBase-X (C) 1, 4, 5, 6, 7, 8, 9, 10, and 11 Not Tested The SUT does not support this conditional interface.

ISDN BRI (C) 2 Not Tested The SUT does not support this conditional interface.

2-Wire Analog (C) 2 Not Tested The SUT does not support this conditional interface.


Video EIs 10Base-X (R) 3, 4, 5, 6, 7, 8, 9, 10, and 11 Not Tested Not applicable. The SUT is a voice only AEI.

100Base-X (R) 3, 4, 5, 6, 7, 8, 9, 10, and 11 Not Tested Not applicable. The SUT is a voice only AEI. 1000Base-X (C) 3, 4, 5, 6, 7, 8, 9, 10, and 11 Not Tested Not applicable. The SUT is a voice only AEI. 10GBase-X (C) 3, 4, 5, 6, 7, 8, 9, 10, and 11 Not Tested Not applicable. The SUT is a voice only AEI. ISDN BRI (C) 3, 4, 5, 6, 7, 8, 9, 10, and 11 Not Tested Not applicable. The SUT is a voice only AEI.

Serial (C) 3, 4, 5, 6, 7, 8, 9, 10, and 11 Not Tested Not applicable. The SUT is a voice only AEI. LEGEND: 802.3u 100BASE-TX, 100BASE-T4, 100BASE-FX Fast Ethernet at

100 Mbps 802.3z 1000BASE-X Gbps Ethernet over Fiber-Optic at 1 Gbps AEI AS-SIP End Instrument AS-SIP Assured Services Session Initiation Protocol BRI Basic Rate Interface C Conditional CR Capability Requirement

EI End Instrument FR Functional Requirement Gbps Gigabits per second IEEE Institute of Electrical and Electronics Engineers ISDN Integrated Services Digital Network Mbps Megabits per second R Required SUT System Under Test

Table 3. EI Capability Requirements and Functional Requirements Status

CR/FR

ID UCR Requirement (High-Level)

(See note 1.) UCR 2013 Reference EI Applicability Status

1 IP Voice End Instruments 2.9.1 AEI (R) PEI (R) Met (See note 2.)

2 Analog and ISDN BRI Telephone Support 2.9.2 EI (R) Not Tested (See note 3.)

3 Video End Instrument 2.9.3 AEI (R) PEI (R)

Not Tested (See note 3.)

4 Authentication to SC 2.9.4 AEI (R) PEI (R) Met

5 End Instrument to ASLAN Interface 2.9.5 AEI (R) PEI (R) Met

6 Operational Framework for AEIs and Video EIs 2.9.6 AEI (R)

AS-SIP Voice EI (R) AS-SIP Secure Voice EI (R)

AS-SIP Video EI (R)

Met

7 Multiple Call Appearance Requirements for AS-SIP EIs 2.9.7 AS-SIP Voice EI (R) AS-SIP Secure Voice EI (R) Met


3

CR/FR ID

UCR Requirement (High-Level)

(See note 1.) UCR 2013 Reference EI Applicability Status

8 PEIs, AEIs, TAs, and IADs Using the V.150.1 Protocol 2.9.8 AEI (R)

Secure AEI (R) PEI (R)

Not Tested (See note 4.)

9 ROUTINE-Only EIs 2.9.10 ROEI (R) non-RO EI (R) Not Tested

10 Internet Protocol version 6 Section 5 All IP EI (R) Partially Met (See note 5.)

11 Information Assurance Section 4 All EI Met (See note 2.) NOTES: 1. The annotation of ‘required’ refers to a high-level requirement category. The applicability of each sub-requirement is provided in Enclosure 3. 2. Security requirements in UCR 2013, Errata 1, Section 4 are met by the vendor’s LoC. In addition, security testing is accomplished by DISA-led Information Assurance test teams and the results published in a separate report, Reference (e). 3. The SUT is a voice only AEI. Therefore, the video, secure voice, and ROEI requirements do not apply. 4. Non-secure AEI phone do not use V.150.1. V.150.1 is used exclusively with TAs, IADs and secure AEI phones. DISA stated the intent to change the requirement to remove applicability from AEI and PEI. 5. The SUT does not support DHCPv6. DISA accepted the vendor’s POA&M and adjudicated this as minor. LEGEND: AEI AS-SIP End Instrument AS-SIP Assured Services Session Initiation Protocol ASLAN Assured Services Local Area Network BRI Basic Rate Interface CR Capability Requirement DHCP Dynamic Host Control Protocol version 6 DISA Defense Information Systems Agency EI End Instrument FR Functional Requirement IAD Integrated Access Device ID Identification

IP Internet Protocol ISDN Integrated Services Defense Network LoC Letters of Compliance PEI Proprietary End Instrument POA&M Plan of Action and Milestones ROEI ROUTINE only End Instrument SC Session Controller SUT System Under Test TA Terminal Adapter UCR Unified Capabilities Requirements

Table 4. UC APL Product Summary

Product Identification

Product Name TEO

Software Release xx.04.13 UC Product Type(s) Assured Services Session Initiation Protocol (AS-SIP) End Instrument (AEI) Product Description The SUT is a voice only, non-secure AEI.

Product Components (See note 1.) Component Name Version Remarks

AEI 7810 05.04.13 This model is certified with or

without the optional 8030x 30-button expander.

AEI 7810-TSG 05.04.13 AEI 7810-PoE-TSGA 05.04.13 AEI 7810-PoE-TSGB 05.04.13

AEI 4101 07.04.13 Tested with the NEC Univerge only, included with the REDCOM systems by similarity with REDCOM DTR 3.

AEI 4104 06.04.13 Tested with the NEC Univerge only, included with the REDCOM systems by similarity with DTR 3.

NOTES: 1. The detailed component and subcomponent list is provided in Enclosure 3. 2. Components bolded and underlined were tested by JITC. The other components in the family series were not tested but are also certified for joint use. JITC certifies those additional components because they utilize the same software and similar hardware and JITC analysis determined them to be functionally identical for interoperability certification purposes. LEGEND: DTR Desktop Review JITC Joint Interoperability Test Command UC Unified Capabilities


4

4. Test Details. This finding is based on interoperability testing, review of the vendor’s Letters of Compliance (LoC), DISA adjudication of open test discrepancy reports (TDRs), and DISA Certifying Authority (CA) Recommendation for inclusion on the UC APL. Testing was conducted at JITC’s Global Information Grid Network Test Facility at Fort Huachuca, Arizona, from 2 April 2013 to 12 April 2013 with the REDCOM HDX LSC and 22 July 2013 through 13 September 2013 with the NEC Univerge LSC using test procedures derived from Reference (d). Review of the vendor’s LoC was completed on 21 October 2013. DISA adjudication of outstanding TDRs was completed on 1 November 2013. The DISA CA provided a positive Recommendation on 25 October 2013 based on the security testing completed by DISA-led IA test teams and the results published in a separate report, Reference (e). Enclosure 2 documents the test results and describes the tested network and system configurations. Enclosure 3 provides a detailed list of the interface, capability, and functional requirements. 5. Additional Information. JITC distributes interoperability information via the JITC Electronic Report Distribution (ERD) system, which uses Sensitive but Unclassified IP Data (formerly known as NIPRNet) e-mail. Interoperability status information is available via the JITC System Tracking Program (STP). STP is accessible by .mil/.gov users at https://stp.fhu.disa.mil/. Test reports, lessons learned, and related testing documents and references are on the JITC Joint Interoperability Tool (JIT) at https://jit.fhu.disa.mil/. Due to the sensitivity of the information, the Information Assurance Accreditation Package (IAAP) that contains the approved configuration and deployment guide must be requested directly from the Unified Capabilities Certification Office (UCCO), e-mail: disa.meade.ns.list.unified-capabilities-certification-office@mail.mil. All associated information is available on the DISA UCCO website located at http://www.disa.mil/Services/Network-Services/UCCO. 6. Point of Contact (POC). The JITC point of contact is Mr. Cary Hogan, commercial telephone (520) 538-2589, DSN telephone 879-2589, FAX DSN 879-4347; e-mail address [email protected]; mailing address Joint Interoperability Test Command, ATTN: JTE (Mr. Cary Hogan) P.O. Box 12798, Fort Huachuca, AZ 85670-2798. The UCCO tracking number for the SUT is TN1310601. FOR THE COMMANDER: 3 Enclosures a/s

for RICHARD A. MEADOR Chief Battlespace Communications Portfolio

https://stp.fhu.disa.mil/

https://jit.fhu.disa.mil/

mailto:disa.meade.ns.list.unified-capabilities-certification-office@mail.mil

mailto:disa.meade.ns.list.unified-capabilities-certification-office@mail.mil

http://www.disa.mil/Services/Network-Services/UCCO

mailto:[email protected]


5

Distribution (electronic mail): DoD CIO Joint Staff J-6, JCS USD(AT&L) ISG Secretariat, DISA, JTA U.S. Strategic Command, J665 US Navy, OPNAV N2/N6FP12 US Army, DA-OSA, CIO/G-6 ASA(ALT), SAIS-IOQ US Air Force, A3CNN/A6CNN US Marine Corps, MARCORSYSCOM, SIAT, A&CE Division US Coast Guard, CG-64 DISA/TEMC DIA, Office of the Acquisition Executive NSG Interoperability Assessment Team DOT&E, Netcentric Systems and Naval Warfare Medical Health Systems, JMIS IV&V HQUSAISEC, AMSEL-IE-IS UCCO

Enclosure 1

ADDITIONAL REFERENCES

(c) Office of the Department of Defense Chief Information Officer, “Department of Defense Unified Capabilities Requirements 2013, Errata 1,” 1 July 2013 (d) Joint Interoperability Test Command, “Session Controller (SC) Test Procedures for Unified Capabilities Requirements (UCR) 2013,” Draft (e) Joint Interoperability Test Command, “Information Assurance (IA) Findings and Mitigations Summary for Teo Internet Protocol (IP) Telephones 78xx, 4104, 4101, Release xx.04.13 (Tracking Number 1310601),” Draft

Enclosure 2

CERTIFICATION SUMMARY 1. SYSTEM AND REQUIREMENTS IDENTIFICATION. The TEO Technologies 78XX, 4104, and 4101 with Software Release xx.04.13 is hereinafter referred to as the System Under Test (SUT). Table 2-1 depicts the SUT identifying information and requirements source.

Table 2-1. System and Requirements Identification

System Identification Sponsor Defense Information Systems Agency Sponsor Point of Contact Michael Giniger, Post Office Box 549, Fort Meade, Maryland 20755-0549,

[email protected]. Vendor Point of Contact Steve Hill, 11609 49th PI. W. Mukilteo, Washington 98275, [email protected] System Name TEO Technologies 78XX, 4104, and 4101 Increment and/or Version xx.04.13 Product Category Assured Services Session Initiation Protocol (AS-SIP) End Instrument (AEI) System Background Previous certifications None Tracking UCCO ID TN1310601 System Tracking Program ID 4406 Requirements Source Unified Capabilities Requirements Unified Capabilities Requirements 2013 Errata 1 Remarks Test Organization(s) Joint Interoperability Test Command, Fort Huachuca, Arizona LEGEND: ID Identification UCCO Unified Capabilities Connection Office

2. SYSTEM DESCRIPTION. The Unified Capabilities Requirements (UCR) defines an End Instrument (EI) as the device or application through which an end user accesses Unified Capabilities (UC) voice, secure voice, and video communication services. UC Internet Protocol (IP) EIs use either Assured Services Session Initiation Protocol (AS-SIP) or vendor-proprietary protocols for signaling. The UCR defines and AS-SIP AEI as an EI that interfaces with a Session Controller (SC) using AS-SIP. The UCR defines a Proprietary End Instrument (PEI) as an EI that interfaces with a SC using proprietary Voice and Video over IP (VVoIP) signaling. Note that for video International Telecommunication Union (ITU) H.323 and Internet Engineering Task Force (IETF) Session Initiation Protocol (SIP) are considered vendor-proprietary protocols because one EI vendor’s implementation of H.323 or SIP is not guaranteed to interoperate with another vendor’s implementation of H.323 or SIP. EIs can also be supported with analog or Integrated Services Digital Network (ISDN) Basic Rate Interface (BRI) interfaces. The Teo 78xx, 4104, 4101 IP telephones are AEI designed to interoperate with multiple types of SCs. They include full support for precedence calls and provide dual-stack IP version 4 (IPv4)/Internet Protocol version 6 (IPv6) signaling. Connection to the phones is through an Ethernet interface; support for Power over Ethernet (PoE), as well as a local power option, is provided. A 10/100Base-T switched Ethernet personal computer (PC) port is provided that can

2-2

be used to connect a local workstation to the Assured Services Local Area Network (ASLAN) over a shared drop that is provisioned with separate voice and data Virtual Local Area Networks. The PC port can also be disabled through provisioning. The SUT was tested and is certified for use specifically with REDCOM HDX and REDCOM SLICE 2100 Local Session Controllers (LSCs). The SUT was also tested and is certified for use with the NEC Univerge 3C LSC, which is undergoing final certification for placement on the UC Approved Products List (APL). The SUT IP telephones are listed in the subparagraphs below.

Teo 7810 IP Telephone: The Teo 7810 IP phone is a 10-button AS-SIP phone. It can use PoE for power or use a local power source. It also includes a 10/100Base-T switched Ethernet PC port. The optional Teo 8030X 30-button expander module connects to an expansion port on the Teo 7810 and is configured through the 7810. The Teo 7810 is certified with our without the optional 8030X 30-button expander. Teo 4101 IP Telephone: The Teo 4101 is a single-line phone that uses the same core software and SIP stack as the Teo 7810; the menus have been modified to allow for the hardware differences. It has a smaller 2-line display and can only have one directory number assigned. It also includes a 10/100Base-T switched Ethernet PC port, which must be disabled. Teo 4104 IP Telephone: The Teo 4104 is a 16-button phone that uses the same core software and SIP stack as the Teo 7810; the menus have been modified to allow for the hardware differences. It has a smaller display and different button layout than the Teo 7810. It also includes a 10/100Base-T switched Ethernet PC port, which must be disabled. 3. OPERATIONAL ARCHITECTURE. The Unified Capabilities (UC) architecture is a two-level network hierarchy consisting of Defense Information Systems Network (DISN) backbone switches and Service/Agency installation switches. The Department of Defense (DoD) Chief Information Officer (CIO) and Joint Staff policy and subscriber mission requirements determine which type of switch can be used at a particular location. The UC architecture, therefore, consists of several categories of switches. Figure 2-1 depicts the notional operational UC architecture in which the SUT may be used. 4. TEST CONFIGURATION. The test team tested the SUT at JITC, Fort Huachuca, Arizona in a manner and configuration similar to that of a notional operational environment. Testing of the system’s required functions and features was conducted using the test configurations depicted in Figures 2-2. Information Assurance testing used the same configuration. 5. METHODOLOGY. Testing was conducted using EI requirements derived from the Unified Capabilities Requirements (UCR) 2013, Reference (c), and EI test procedures, Reference (d). Any discrepancies noted were written up in Test Discrepancy Reports (TDRs). The vendor submitted Plan of Action and Milestones (POA&M) as required. The remaining open TDRs were adjudicated by DISA as minor. Any new discrepancy noted in the operational environment will be evaluated for impact on the existing certification. These discrepancies will be adjudicated to the satisfaction of DISA via a vendor POA&M, which will address all new critical TDRs within 120 days of identification.

2-3

LEGEND: DCO Defense Connection Online DISA Defense Information Systems Agency DISN Defense Information Systems Network DoD Department of Defense EI End Item IAP Integrated Access Point IM Instant Messaging IP Internet Protocol ISP Internet Service Provider LAN Local Area Network MCEP Multi-Carrier Entry Point

NETOPS Network Operations PKI Public Key Infrastructure PSTN Public Switched Telephone Network QoS Quality of Service SBC Session Border Controller SC Session Controller SS Softswitch UC Unified Capabilities VVoIP Voice and Video over IP XMPP Extensible Messaging and Presence Protocol

Figure 2-1. Notional UC Network Architecture

2-4

Figure 2-2. SUT Test Configuration

6. INTEROPERABILITY REQUIREMENTS, RESULTS, AND ANALYSIS. The interface, Capability Requirements (CR) and Functional Requirements (FR), Information Assurance (IA), and other requirements for the UC End Instrument are established by UCR 2013, sections 2.9, 4, and 5. a. IP Voice End Instruments (1) Basic. The basic IP voice end instrument interoperability requirements in the subparagraphs below were met with testing. Interoperability test scenarios were performed between the various certified LSCs depicted in Figure 2-2. The SUT was tested and is certified for use specifically with REDCOM HDX and REDCOM SLICE 2100 LSCs. The SUT was also tested and is certified for use with the NEC Univerge 3C LSC, which is undergoing final certification for placement on the UC APL.

LEGEND: ASLAN Assured Services Local Area Network AS-SIP Assured Services Session Initiation Protocol HDX High Density Exchange LSC Local Session Controller MFS Multifunction Switch MFSS Multifunction Softswitch

MG Media Gateway SBC Session Border Controller SC Session Controller SUT System Under Test UCM Unified Communications Manager

2-5

(a) DoD Common Access Card (CAC) reader. See UCR 2013, Section 4.2.3.5, Authentication Practices, item 1h(1), for SC and EI requirements on PKI and CAC authentication, and SC and EI requirements on Username and Personal Identification Number (PIN) authentication. Security is tested by DISA-led IA test teams and the results published in a separate report. (b) Display calling number. See UCR 2013, Section 2.2.8, Calling Number Delivery, for SC and EI requirements on the Calling Number Delivery feature. (c) Display precedence level of the session. (d) Use of DSCPs in signaling and media streams. (e) Support for Dynamic Host Configuration Protocol (DHCP). (f) For multiple line appearance, only two-appearance IP voice instruments are specified and they shall function as specified in Section 2.9.7, Multiple Call Appearance Requirements for AS-SIP EIs. (2) Tones and Announcements. Tones and announcements, as required in Section 2.9.1.2.1, UC Ringing Tones, Cadences, and Information Signals, and Section 2.9.1.2.2, Announcements, shall be supported, except for the loss of the C2 announcement. These tones and announcements shall be generated locally by the PEI or AEI on the command of the SC, or shall be generated on the command of the SC by an internal SC Media Server or an external Media Server connected to the ASLAN and passed as a media stream to the PEI or AEI. Regardless of how implemented, the Media Server is part of the SC SUT. This requirement was met with testing. The SUT does not generate the tones and announcements, but audibly generates the tones and announcements as the were provided by the LSC Call Control Agent (CCA). Tone and announcements were generated by the CCA as a result of MLPP interoperability test scenarios performed between the various certified LSCs depicted in Figure 2-2. The SUT was tested and is certified for use specifically with REDCOM HDX and REDCOM SLICE 2100 LSCs. The SUT was also tested and is certified for use with the NEC Univerge 3C LSC, which is undergoing final certification for placement on the UC APL. (3) Audio Codecs, Voice Instruments (a) EIs and MGs shall support the origination and termination of a voice session using the ITU-T Recommendation G.711 codec, including both the μ-law and A-law algorithms. The SUT met this requirement with testing. (b) EIs and MGs shall support the origination and termination of a voice session using the ITU-T Recommendation G.729 or G.729A codec. The SUT met this requirement for G.729A with testing.

2-6

(c) EIs and MGs shall support the origination and termination of a voice session using the ITU-T Recommendation G.723.1 codec. The SUT does not support this optional requirement. (d) EIs and MGs shall support the origination and termination of a voice session using the ITU-T Recommendation G.722.1 codec. The SUT met this requirement with testing. (4) VoIP PEI or AEI Telephone Audio Performance. Voice over IP PEIs or AEIs (i.e., handset, headset, and hands-free types) shall comply with Telecommunications Industry Association (TIA)-810-B, November 3, 2006. This requirement was met through testing. The Sage 960 was used to record Mean Opinion Score (MOS) scores, which all achieved a 4.0 or higher. (5) Voice over IP Sampling Standard. For Fixed-to-Fixed calls, the product shall use 20 ms as the default voice sample length, and as the basis for the voice payload packet size. For other call types, e.g., Fixed-to Deployable calls, the product shall use different voice sample lengths and voice payload packet sizes, as negotiated during call setup via the Session Description Protocol (SDP). The SUT met this requirement with testing. Wireshark was used to capture and verify call data. (6) Softphones. The SUT is certified for AEI voice only, therefore the requirements for softphones in the following subparagraphs do not apply. (a) If a softphone is supported by an SC or SS, the softphone shall be conceptually identical to a traditional IP “hard” telephone and is required to provide voice features and functionality provided by a traditional IP hard telephone, unless explicitly stated here within this paragraph. The softphone application in conjunction with a general-purpose computer, including its mouse (point and click) interaction, shall support, as a minimum, the following requirements: 1. UCR 2013, Section 2.2, Voice Features and Capabilities. 2. UCR 2013, Section 2.9.1.1, Basic. 3. UCR 2013, Section 2.9.1.2, Tones and Announcements. 4. UCR 2013, Section 2.9.1.3, Audio Codecs, Voice Instruments. 5. UCR 2013, Section 2.9.1.4, VoIP PEI or AEI Telephone Audio Performance. 6. UCR 2013, Section 2.9.1.5, Voice over IP Sampling Standard. 7. UCR 2013, Section 2.9.4, Authentication to SC. 8. UCR 2013, Section 2.9.5, End Instrument to ASLAN Interface.

2-7

9. UCR 2013, Section 6, Network Infrastructure End-to-End Performance. The softphone application shall be exempt from the performance (i.e., packet loss, jitter, latency) requirements specified in Section 6, Network Infrastructure End-to-End Performance; e.g., the PEI/AEI 50-ms latency for the G.711 codec. 10. UCR 2013, Section 6.3.2, VVoIP Differentiated Services Code Point. 11. UCR 2013, Section 4, Information Assurance. (b) If an EI is a softphone, then it shall inhibit any screen saver or lock screen capability whenever the softphone application is active (i.e., user is on a call). This is to avoid the situation where the user needs to interact with the softphone application via the mouse or keyboard expeditiously (e.g., respond to a new call) but first needs to re-login. (7) DSCP Packet Marking. The SUT met the requirements in the following subparagraphs with testing. Wireshark was used to capture and verify call data. (a) As part of the session setup process, the SC controls what Differentiated Service Code Point (DSCP) to use in the subsequent session media stream packets. For inter-SC media sessions (across the WAN), and intra-SC media sessions (internal to the enclave), one of the following occurs: 1. The PEI shall be commanded by the SC about which DSCP to insert in the session media stream packets. 2. The PEI shall populate the DSCP marking on its own. 3. The AEI shall populate the DSCP marking on its own. (b) The exact DSCP method used by the implementer shall comply with Section 6, Network Infrastructure End-to-End Performance. The session’s media type (e.g., audio vs. video) and the session’s precedence level (R, P, I, F, or FO) shall be used to determine the media stream DSCP for that session. b. Analog and ISDN BRI Telephone Support. The SUT is certified for AEI voice only, therefore the requirements for analog and ISDN BRI in the following subparagraphs do not apply. (1) Analog instruments, including secure analog EIs, analog facsimile (fax) EIs, and analog modem EIs, shall be supported by the SC either by a Terminal Adapter, RJ-11 Plain Old Telephone Service (POTS) telephone to RJ-45 Ethernet interface (TA), or an Integrated Access Device (IAD), 4 or more ports of RJ-11 POTS telephone to one port of RJ-45 Ethernet interface. (a) The TA shall support G.711 standards. (b) The TA shall support V.150.1 Modem Relay and T.38 Fax Relay standards.

2-8

(c) The IAD shall support G.711 standards. (d) The IAD shall support V.150.1 Modem Relay and T.38 Fax Relay standards. (e) Analog telephones, when combined with a TA or IAD, together shall comply with TIA-810-B, November 3, 2006. (2) Analog instruments, including secure analog EIs, analog facsimile EIs, and analog modem EIs, shall be supported by the existing twisted-pair cable plant connected to line cards that are part of the SC MG. (a) The line card shall support G.711 standards. (b) The line card shall support V.150.1 Modem Relay and T.38 Fax Relay standards. (c) Analog telephones, when connected to a line card, together shall comply with TIA-810-B, November 3, 2006. (d) The SC and SS shall support secure analog EIs on analog TAs, IADs, and MG line cards, where the TAs, IADs, and MG line cards support the ITU-T Recommendation V.150.1 standard for Modem Relay. (e) The SC and SS shall support analog facsimile EIs on analog TAs, IADs, and MG line cards, where the TAs, IADs, and MG line cards support the ITU-T Recommendation T.38 standard for Fax Relay. (f) The SC and SS shall support analog modem EIs on analog TAs, IADs, and MG line cards, where the TAs, IADs, and MG line cards support the ITU-T Recommendation V.150.1 standard for Modem Relay. (3) ISDN BRI Telephone Support (a) ISDN BRI EIs, including secure ISDN BRI EIs, shall be supported by the SC. (b) If an SC supports ISDN BRI EIs, they shall be supported by one of the following: 1. A BRI-capable TA that is connected to an Ethernet port. 2. A BRI-capable IAD that is connected to an Ethernet port. 3. The existing twisted-pair cable plant connected to a BRI-capable line card that is part of the SC MG. (c) If a TA supports standard (nonsecure) ISDN BRI EIs, it shall support the ITU-T Recommendation G.711 standard.

2-9

(d) If an IAD supports standard (nonsecure) ISDN BRI EIs, it shall support the ITU-T Recommendation G.711 standard. (e) If a TA supports secure ISDN BRI EIs, it shall support both the ITU-T Recommendations G.711 and V.150.1 standards. (f) If an IAD supports secure ISDN BRI EIs, it shall support both the ITU-T Recommendations G.711 and V.150.1 standards. (g) If an MG line card supports standard (nonsecure) ISDN BRI EIs, the MG line card shall support the ITU-T Recommendation G.711 standard. (h) If an MG line card supports secure ISDN BRI EIs, it shall support both the ITU-T Recommendations G.711 and V.150.1 standards. (i) The ISDN BRI telephones when combined with a BRI-capable TA, BRI-capable IAD, or BRI-capable MG line card shall comply with TIA-810-B, November 3, 2006. (j) If an SC, TA, IAD, or SC MG support ISDN BRI EIs (both standard and secure), the SC, TA, IAD, or SC MG shall support all the DSN ISDN BRI requirements in the following DSN sections: 1. Section 2.25.1.6, ISDN MLPP BRI. 2. Section 2.25.1.8, MLPP Interactions With Common Optional Features and Services. 3. Section 2.25.1.9, MLPP Interactions With Electronic Key Telephone Systems Features. 4. Section 2.25.2, Signaling. 5. Section 2.25.3, ISDN. c. Video End Instrument. The SUT is a voice only AEI. Therefore, the video end instrument requirements in the following subparagraphs do not apply. (1) Basic. An IP video instrument shall be designed IAW the acquiring activity requirements, but the following capabilities are specifically required or optional as indicated: (a) DoD CAC card reader. (b) Automatic enabling of the video camera is not permitted after video session negotiation or acceptance. The called party must take a positive action to enable the camera.

2-10

(c) Display calling number. (d) Display precedence level of the session. (e) Support for Multilevel Precedence and Preemption (MLPP) feature. (f) Support for DHCP. (2) Display Messages, Tones, and Announcements. Tones and announcements, as appropriate for voice and video over IP, and as required, in Section 2.9.1.2.1, UC Ringing Tones, Cadences, and Information Signals, and Section 2.9.1.2.2, Announcements, shall be supported by the PEI and AEI, except for the loss of the C2 announcement. These tones and announcements shall be generated locally by the PEI and AEI on the command of the SC, or generated on command of the SC by an internal SC Media Server or an external Media Server connected to the ASLAN, and passed as a media stream to the PEI and AEI. Regardless of how implemented, the Media Server is part of the SC SUT. (3) Video Codecs (Including Associated Audio Codecs) (a) The product shall support the origination, maintenance, and termination of a video session using the following codecs: one G.xxx and one H.xxx shall be used to create and sustain a video session. (All video and audio capabilities in the PEI or AEI shall be sent to the terminating PEI or AEI for negotiation about which video and audio codec to use for the session.) (b) Video PEIs and AEIs shall support, at a minimum, G.711 Pulse Code Modulation (PCM), where PCM has a static payload type value of 0 and a clock rate of 8000. The PCM shall support both the μ-law and A-law algorithms. (c) It is recommended that video PEIs and AEIs support other audio codecs in addition to G.711 PCM. Recommended audio codecs include the following: 1. ITU-T Recommendation G.722, where G.722 has a static payload type value of 9 and a clock rate of 8000. 2. ITU-T Recommendation G.722.1, where G.722.1 has the encoding name “G7221”, a clock rate of 16000, and a standard bit rate of 24 Kbps or 32 Kbps. 3. ITU-T Recommendation G.723.1, where G.723.1 has the encoding name “G723”, a clock rate of 8000, and standard bit rates of 5.3 Kbps and 6.3 Kbps. 4. ITU-T Recommendation G.729, where G.729 has the encoding name “G729”, a clock rate of 8000, and a standard bit rate of 8 Kbps. 5. ITU-T Recommendation G.729 Annex A (G.729A), where G.729A also has the encoding name “G729”, a clock rate of 8000, and a standard bit rate of 8 Kbps.

2-11

(d) Video PEI and AEI shall support, at a minimum, the following video codecs: ITU-T Recommendation H.263-2000 and ITU-T Recommendation H.264. (4) H.323 Video Teleconferencing (a) The H.323 VTC system and end points should meet the requirements of Federal Telecommunications Recommendation (FTR) 1080B-2002. (b) The H.323 VTC features and functions used in conjunction with IP network services should meet the requirements of H.323 in accordance with FTR 1080B-2002, and H.323 video EIs should meet the tagging requirements as specified in Section 7, Network Edge Infrastructure. (c) A loss of any conferee on a multipoint H.323 videoconference shall not terminate or degrade the DSN service supporting H.323 VTC connections of any of the other conferees on the videoconference. (d) An audio add-on interface shall be provided on H.323 VTC equipment in accordance with Section 3.7, Customer Premise Equipment. (e) If an H.323VTC system or end point uses an integrated BRI interface to connect to the DSN, then it shall be in conformance with the requirements associated with a TA as described in Section 3.7, Customer Premise Equipment, and Section 2.9.2.1, ISDN BRI Telephone Support. (f) If a VTC system or end point uses a serial interface to another device, such as a cryptographic device or TA, for eventual connection to the DSN, it shall be in conformance with the requirements for that serial interface as described in FTR 1080B-2002. (g) Physical, electrical, and software characteristics of a video teleconferencing unit system or end point that is used in the DSN network shall not degrade, or impair, the serving DSN switch and its associated network operations. As noted in the introduction to Section 2.3.3, ASAC Requirements for the SC and the SS Related to Video Services, the SC and the SS will process only AS-SIP video. H.323 video will be processed by a gatekeeper appliance. d. Authentication to SC. The PEI and AEI shall each be capable of authenticating itself to its associated SC and vice versa IAW Section 4, Information Assurance. The SUT met this requirement with testing and the vendor’s LoC. e. End Instrument to ASLAN Interface. The interface to the ASLAN shall be IAW Ethernet (IEEE 802.3) Local Area Network (LAN) technology. The 10-Mbps and 100-Mbps Fast Ethernet (IEEE 802.3u) shall be supported. The SUT met this requirement with testing and the vendor’s LoC.

2-12

f. Operational Framework for AEIs and Video EIs. The SUT met the voice requirements in the subparagraphs below with testing and the vendor’s LoC. The SUT is a voice only AEI, therefore, the secure voice and video requirements do not apply. (1) Requirements for Supporting AS-SIP EIs (a) The AS-SIP EIs (voice, secure voice, and video) shall follow all of the previous requirements for EIs (voice and video, with secure voice EIs following the previous requirements for voice EIs), except for those requirements that involve vendor-proprietary SC-to-EI signaling. (b) The SCs and AS-SIP EIs (voice, secure voice, and video) shall support mutual authentication using AS-SIP and TLS signaling instead of vendor-proprietary signaling. That is, each AS-SIP EI shall authenticate itself with its serving SC using AS-SIP and TLS signaling, and each SC shall authenticate itself with the AS-SIP EIs that it serves using AS-SIP and TLS signaling. (c) The SC shall allow a single AS-SIP EI to support voice, secure voice, and video capabilities. In this case, the SC shall support that EI using the combined requirements for an AS-SIP voice EI, an AS-SIP secure voice EI, and an AS-SIP video EI, as given below. The SC shall also allow a single AS-SIP EI to support the following subset of capabilities: 1. Voice and Secure Voice. 2. Voice and Video. (d) A single AS-SIP EI shall support voice, secure voice, and video capabilities. In this case, the EI shall support those capabilities IAW the combined requirements for an AS-SIP voice EI, an AS-SIP secure voice EI, and an AS-SIP video EI, as given in Section 2.9.6.2, Requirements for AS-SIP Voice EIs; Section 2.9.6.3, Requirements for AS-SIP Secure Voice EIs; and Section 2.9.6.4, Requirements for AS-SIP Video EIs. (e) A single AS-SIP EI shall support both voice and secure voice capabilities. In this case, the EI shall support those capabilities IAW the combined requirements for an AS-SIP voice EI and an AS-SIP secure voice EI, as given in Section 2.9.6.2, Requirements for AS-SIP Voice EIs, and Section 2.9.6.3, Requirements for AS-SIP Secure Voice EIs. (f) A single AS-SIP EI shall support both Voice and Video capabilities. In this case, the EI shall support those capabilities IAW the combined requirements for an AS-SIP voice EI and an AS-SIP video EI, as given in Section 2.9.6.2, Requirements for AS-SIP Voice EIs, and Section 2.9.6.4, Requirements for AS-SIP Video EIs. (g) An AS-SIP secure voice EI shall also support the capabilities of an AS-SIP Voice EI IAW the AS-SIP voice EI requirements given in Section 2.9.6.2, Requirements for AS-SIP Voice EIs. The AS-SIP secure voice EI shall support these capabilities for “voice communication in the clear” using the Audio media type and the G.7XX codecs.

2-13

(2) Requirements for AS-SIP Voice EIs. The SUT met the requirements in the subparagraphs below with testing with the exceptions noted below. Interoperability test scenarios were performed between the various certified LSCs depicted in Figure 2-2. The SUT was tested and is certified for use specifically with REDCOM HDX and REDCOM SLICE 2100 LSCs. The SUT was also tested and is certified for use with the NEC Univerge 3C LSC, which is undergoing final certification for placement on the UC APL. (a) The SCs shall support AS-SIP voice EIs that use AS-SIP for EI-to-SC signaling. The SCs shall support these AS-SIP voice EIs using the AS-SIP SC-to-AS-SIP-EI interface defined in Section 2.9.7, Multiple Call Appearance Requirements for AS-SIP EIs, and in AS-SIP 2013. (b) The AS-SIP voice EIs shall support AS-SIP for EIto-SC signaling. These AS-SIP voice EIs shall support the AS-SIP SC-to-AS-SIP-EI interface defined in Section 2.9.7, Multiple Call Appearance Requirements for AS-SIP EIs, and in AS-SIP 2013. (c) The SCs and AS-SIP Voice EIs shall support the following supplementary services for voice calls, consistent with Section 2.2, Voice Features and Capabilities, using AS-SIP signaling. Precedence Call Waiting, Call Forwarding, Call Transfer, Call Hold, UC Conferencing, Three-Way Calling, Calling Number Delivery, and Call Pickup. The SUT does not support UC Conferencing or Call Pickup. There is no impact of the SUT not supporting these optional requirements. (d) The SCs and AS-SIP voice EIs shall support a mechanism to limit the total number of voice calls at that EI at any given time. (e) For AS-SIP voice EIs, the voice call limit depends on the number of voice call appearances supported on the EI. The AS-SIP voice EIs are required to support two voice call appearances for one DSN number in this document (per Section 2.9.7, Multiple Call Appearance Requirements for AS-SIP EIs). But one of these call appearances might not be used, because the SC is configured to support only one voice call appearance for one DSN number on this EI. As a result, the voice call limit that the SC maintains for the AS-SIP voice EI depends on whether the SC is configured to support one call appearance or two call appearances for that EI. 1. When the SC is configured to support two call appearances on an AS-SIP voice EI, the SC shall use a voice call limit of “Two” for that EI. 2. When the SC is configured to support one call appearance on an AS-SIP voice EI (even though the EI might support two call appearances), the SC shall use a voice call limit of “One” for that EI. (3) Requirements for AS-SIP Secure Voice EIs. The SUT is a voice only AEI. Therefore, the secure voice end instrument requirements in the following subparagraphs do not apply. (a) The SCs shall support AS-SIP secure voice EIs that use AS-SIP for EI-to-SC signaling. The SCs shall support these AS-SIP secure voice EIs using the AS-SIP SC-to-AS-SIP-

2-14

EI interface defined in Section 2.9.7, Multiple Call Appearance Requirements for AS-SIP EIs, and in AS-SIP 2013. (b) AS-SIP Secure Voice EIs shall support AS-SIP for EI-to-SC signaling. These AS-SIP secure voice EIs shall support the AS-SIP SC-to-AS-SIP-EI interface defined in Section 2.9.7, Multiple Call Appearance Requirements for AS-SIP EIs, and in AS-SIP 2013. (c) The SCs and SSs shall support the following supplementary services for voice calls on AS-SIP secure voice EIs, consistent with Section 2.2, Voice Features and Capabilities, using AS-SIP signaling: Precedence Call Waiting, Call Forwarding, Call Transfer, Call Hold, UC Conferencing, Three-Way Calling, Calling Number Delivery, and Call Pickup. (d) An AS-SIP secure voice EI shall be able to operate as an AS-SIP voice EI for voice calls (calls using Audio media and not SCIP/modem relay media). (e) An AS-SIP secure voice EI shall be able to operate as an AS-SIP voice EI for the portions of calls where Audio media is used (and SCIP/modem relay media is not used). This AS-SIP secure voice EI requirement applies during the time before a call converts from Audio media to SCIP/modem relay media, and during the time after a call converts from SCIP/modem relay media back to Audio media. This requirement also applies to a call that never converts to SCIP/modem relay media, and uses Audio media for the lifetime of the call. (f) An AS-SIP Secure Voice EI shall not allow the end user to activate any supplementary services when a call on that EI is operating in “Secure Voice” mode, and SCIP/modem relay media is being used. When an end user tries to use a supplementary service when a call on the EI is operating in secure voice mode, the EI shall prevent the user from activating the service, and shall return an error indication (i.e., a locally generated tone and a visual display) back to that user. The error indication shall indicate that the end user must return the secure voice call to a “Clear Voice” call before the supplementary service can be used. (g) Whenever the local end user returns the Secure Voice call to a Clear Voice call, or the remote end user returns the secure voice call to a clear voice call, the AS-SIP secure voice EI shall return a “clear voice confirmation” indication (i.e., a locally generated tone and a visual display) to the local end user. This lets the local end user know that the call has returned from secure voice mode to clear voice mode. It also lets them know that they are no longer communicating in secure voice mode, and lets them know that they can activate supplementary services if desired. (h) An AS-SIP secure voice EI shall support supplementary services when all calls on that EI are operating in clear voice mode, and Audio media alone is being used. When an end user tries to use a supplementary service when all calls on the EI are operating in clear voice mode, the EI shall allow the user to activate the service, and shall process the service request accordingly. This requirement shall also apply after the user has returned a secure voice call to a clear voice call (e.g., in response to an error indication from the EI during the secure voice call), and then tries to use a supplementary service on the clear voice call.

2-15

(i) When operating as an AS-SIP voice EI (i.e., all EI calls are in clear voice mode), an AS-SIP secure voice EI shall support the following supplementary services for voice calls, consistent with Section 2.2, Voice Features and Capabilities, using AS-SIP signaling: Precedence Call Waiting, Call Forwarding, Call Transfer, Call Hold, UC Conferencing, Three-Way Calling, Calling Number Delivery, Call Pickup. (j) When an AS-SIP secure voice EI has a secure voice call active, the SC sends that EI a Precedence CW or ROUTINE CW indication, and the EI user attempts to place the secure voice call on hold and answer the waiting call, the EI shall send an error indication (tone and display) to the user as described previously. If the user converts the secure voice call back to a clear voice call, and then tries to place the clear voice call on hold and answer the waiting call, the EI shall accept the user’s request and relay it to the SC. (k) When an AS-SIP secure voice EI has a secure voice call active, and the EI user attempts to activate Call Transfer by placing the secure voice call on hold and setting up another call, the EI shall send an error indication (tone and display) to the user as described previously. If the user converts the secure voice call back to a clear voice call, and then tries to activate Call Transfer by placing the clear voice call on hold and setting up another call, the EI shall accept the user’s request and relay it to the SC. (l) When an AS-SIP secure voice EI has a secure voice call active, and the EI user attempts to activate Call Hold by placing the secure voice call on hold, the EI shall send an error indication (tone and display) to the user as described previously. If the user converts the secure voice call back to a clear voice call, and then tries to activate Call Hold by placing the clear voice call on hold, the EI shall accept the user’s request and relay it to the SC. (m) When an AS-SIP secure voice EI has a secure voice call active, and the EI user attempts to activate TWC by placing the secure voice call on hold and setting up another call, the EI shall send an error indication (tone and display) to the user as described previously. If the user converts the secure voice call back to a clear voice call, and then tries to activate TWC by placing the clear voice call on hold and setting up another call, the EI shall accept the user’s request and relay it to the SC. (n) When an AS-SIP secure voice EI has a secure voice call active, and the SC sends that EI a Precedence CW or Routine CW indication and provides Calling Party ID and Precedence Level information within the CW indication, the AS-SIP Secure Voice EI shall display both the Calling Party ID and Precedence Level information to the called user at the EI, as part of the CW indication that the EI delivers to the called user. (This gives the called users a basis for deciding whether to answer or ignore a “waiting” voice call when they have a secure voice call active on their EI. “Ignore,” as used here, means that the user allows the call to be forwarded by the Call Forward Don’t Answer [CFDA] feature or deflected by the Precedence Call Diversion feature.) (4) Requirements for AS-SIP Video EIs. The SUT is a voice only AEI. Therefore, the video end instrument requirements in the following subparagraphs do not apply.

2-16

(a) SCs shall support AS-SIP Video EIs that use AS-SIP for EI-to-SC signaling. The SCs shall support these AS-SIP Video EIs using the AS-SIP SC-to-AS-SIPEI interface defined in Section 2.9.7, Multiple Call Appearance Requirements for AS-SIP EIs, and in AS-SIP 2013. (b) The AS-SIP Video EIs shall support AS-SIP for EI-to-SC signaling. These AS-SIP Video EIs shall support the AS-SIP SC-to-AS-SIP-EI interface defined in Section 2.9.7, Multiple Call Appearance Requirements for AS-SIP EIs, and in AS-SIP 2013. (c) SCs, SSs, and AS-SIP Video EIs shall support the following supplementary services for video calls, as an extension of the requirement to support these services for voice calls in Section 2.2, Voice Features and Capabilities: Precedence Call Waiting, Call Forwarding, Call Transfer, Call Hold, UC Conferencing, Three-Way Calling, Calling Number Delivery, and Call Pickup. (d) The SC, SS, and the AS-SIP Video EI shall support the transmission of H.281 far-end camera control (FECC) messages when used in conjunction with video systems (e.g., MCUs and VTC bridges) that employ far-end camera control capabilities. The specific requirements for implementing this capability are provided in AS-SIP 2013, Section 10.3.6.1, General H.224 Control Channel for Far-End Camera Control Messages, and in Section 10.3.6, FECC. (e) The SC, SS, and the AS-SIP Video EI shall support (when used in multipoint conferences) the Binary Floor Control Protocol (BFCP) that uses a floor control server to manage the control of media streams that are shared resources (i.e., “floors”) as specified in RFC 4582. The specific requirements for implementing this capability are provided in Section 5.3.4.9.7.5, SDP Attributes for Binary Floor Control Protocol Streams. (f) If SCs, SSs, and AS-SIP Video EIs support the optional supplementary services noted above (within Section 2.9.6.4), they shall support them using AS-SIP signaling. (g) The SCs and AS-SIP Video EIs shall support a mechanism to limit the total number of video calls at that EI at any given time. The SC shall keep track of the total number of video calls at the AS-SIP Video EI at all times. The SC shall compare this total number of calls to the configured video call limit for that EI, and shall block further video call requests to and from the AS-SIP EI once this video call limit is reached. (h) The SC, SS, and the AS-SIP Video EI shall support a mechanism to identify the amount of video call bandwidth, expressed in VSUs, in use at that EI at any given time. A 500-Kbps video call uses one VSU of bandwidth, a 1-Mbps video call uses two VSUs of bandwidth, a 2.5-Mbps video call uses five VSUs of bandwidth, and a 4.0-Mbps video call uses eight VSUs of bandwidth.) (i) The SC, SS, and the AS-SIP Video EI shall support the conversion of a lower-bandwidth video call to a higher-bandwidth video call (and vice-versa), using AS-SIP re-INVITE messages on the SC-to-AS-SIP-EI interface to signal the bandwidth change.

2-17

(j) The SC, SS, and the AS-SIP Video EI shall support the conversion of a video call to a voice call (and vice-versa), using AS-SIP re-INVITE messages on the SC-to-AS-SIP-EI interface to signal the media change. (5) AS-SIP Video EI Features. The SUT is a voice only AEI. Therefore, the video end instrument requirements in the following subparagraphs do not apply. (a) If the AS-SIP Video EI supports FECC based on ITU-T Recommendation H.224 and ITU-T Recommendation H.281, then the EI shall support all the AS-SIP and SDP protocol requirements for FECC in the following: AS-SIP 2013, Section 10.3.6.1, General H.224 Control Channel for Far End Camera Control Messages. (b) If the AS-SIP Video EI supports BFCP based on RFC 4582 and RFC 4583, then the EI shall support all the AS-SIP and SDP protocol requirements for BFCP Streams in the following: AS-SIP 2013, Section 10.3.3.2.1, SDP Requirements for the Binary Control Protocol (Based on RFC 4583). (c) If the AS-SIP Video EI supports Video Channel Flow Control [VCFC] based on RFC 4585, then the EI shall support all the AS-SIP and SDP protocol requirements for VCFC in the following: AS-SIP 2013, Section 10.3.4, Video Channel Flow Control. (d) If the AS-SIP Video EI supports VCFC based on RFC 4585, then the EI shall support the required sections of RFC 4585 specifically required in UCR 2013.

(e) If the AS-SIP Video EI supports Video Channel Fast Update Requests (VCFURs) based on RFC 5104, then the EI shall support all the AS-SIP and SDP protocol requirements for VCFUR in the following: AS-SIP 2013, Section 10.3.5, Video Channel Fast Update Requests. (f) If the AS-SIP Video EI supports VCFUR, Full Intra Request (FIR) payload-specific feedback message shall be used for implementing VCFUR. g. Multiple Call Appearance Requirements for AS-SIP EIs. The multiple call appearance requirements in the subparagraphs below for voice AEI were met with testing. Interoperability test scenarios were performed between the various certified LSCs depicted in Figure 2-2. The SUT was tested and is certified for use specifically with REDCOM HDX and REDCOM SLICE 2100 LSCs. The SUT was also tested and is certified for use with the NEC Univerge 3C LSC, which is undergoing final certification for placement on the UC APL. The SUT is a voice only AEI, therefore, the secure voice and video requirements do not apply. (1) Multiple Call Appearances – Specific Requirements (a) AN AS-SIP EI shall allow multiple call appearances of the same DN (10-digit DSN number) to be assigned to it. AN AS-SIP EI shall allow at least two appearances of the same DN to be assigned to it. This requirement does not apply to AS-SIP Video EIs.

2-18

(b) AN AS-SIP EI shall allow each call appearance of a DN to be used for voice and secure voice calls to and from that DN. This requirement does not apply to AS-SIP Video EIs. Dedication of call appearances on an EI to a particular call type (Voice, Secure Voice, or Video) is not a requirement. (c) AN AS-SIP Video EI shall support at least one DN for video calls, and support at least one video call on that DN at a time. AN AS-SIP Video EI is not required to use a call appearance to support this video call. AN AS-SIP Video EI that is also an AS-SIP Voice EI (and supports voice calls and two voice call appearances) is not required to use either of its voice call appearances to support this video call. (d) AN AS-SIP Voice EI shall be able to support two simultaneous voice calls (media type equals Audio) using two call appearances of the same DN (10-digit DSN number). (d) When operating as an AS-SIP Voice EI (no Secure voice calls active), an AS-SIP Secure Voice EI shall be able to support two simultaneous voice calls (media type equals Audio) using two call appearances of the same DN. (e) When operating as an AS-SIP Secure Voice EI (one Secure voice call active), an AS-SIP Secure Voice EI shall be able to support one Secure voice call (media type equals modem relay) using one of its two call appearances. The EI may also support a voice call (media type equals Audio) on Hold using its other call appearance in this case. (f) AN AS-SIP Video EI shall be able to support at least one video call (media type equals Video). If the AS-SIP EI is also an AS-SIP Voice EI or AS-SIP Secure Voice EI, the EI is not required to use either of its voice call appearances to support the video call. (g) The AS-SIP EI and SC shall allow multiple media types to be requested (as part of SDP capability declaration) in the same EI-to-SC INVITE message. (h) The SC and AS-SIP EI shall allow multiple media types to be requested (as part of SDP capability declaration) in the same SC-to-EI INVITE message. (i) AN AS-SIP EI shall allow only one voice call (voice or secure voice) to be associated with one call appearance at a time. An AS-SIP EI shall not allow multiple calls (e.g., one active call and one held call) to be associated with the same call appearance at the same time. (j) AN AS-SIP EI shall allow multiple voice calls to be associated with itself, as long as each call is associated with one, and only one, call appearance on that AS-SIP EI. AN AS-SIP EI shall allow each call associated with the EI to be in either an “active” state, a “held” state, or a “call in progress” state (a call in the process of being established). (k) AN AS-SIP secure voice EI shall allow only one secure voice call (media equals modem relay) to be associated with the EI at a time, and allow that call to be associated with one

2-19

call appearance on that EI. The AS-SIP EI shall allow this secure voice call to be in only an “active” state, and not in a “held” state, or a “call in progress” state. (l) When a secure voice call is active, the AS-SIP secure voice EI shall also allow an additional voice call (media equals Audio) to be associated with the EI, and allow that call to be associated with the second call appearance on that EI. The AS-SIP EI shall allow this additional voice call to be in only a “held” state or a “call in progress” state (a call in the process of being established), and not in an “active” state. For example, if the CW feature is assigned, the EI shall allow an active Secure voice call on one call appearance and an incoming “in progress” voice call on the other call appearance. (m) AN AS SIP EI shall allow a call on a single call appearance to transition from one media type to another, using an inband media message for a media change (like a V.150.1 modem relay SSE message). AN AS-SIP EI shall support transitions from voice media to secure voice media, and transitions from secure voice media to voice media. (2) Multiple Call Appearances – Interactions With Precedence Calls (a) When an incoming precedence call is offered on a multiple-call-appearance AS-SIP EI, the EI shall do all of the following: 1. Play a precedence ringing tone for that call. 2. Offer the call on the next available call appearance for the indicated DN. 3. Provide a visual precedence level display to the called user. 4. Allow the called user to place any currently active call (on the currently active appearance) on hold and answer the incoming precedence call on the new call appearance. (b) When the called user of an incoming precedence call offered on a multiple-call-appearance AS-SIP EI, does not answer that precedence call, the call shall be forwarded IAW the Call Forwarding Don’t Answer feature, or diverted to a designated UC DN IAW the Precedence Call Diversion feature. (c) If the AS-SIP EI is a secure voice EI and the currently active call is a secure voice call using modem relay media, the EI shall require the called user to convert the currently active call back to a voice call using Audio media before placing it on hold. The AS-SIP EI shall not allow a Secure voice call using modem relay media to be placed on hold. (d) The AS-SIP voice EI shall offer subsequent incoming precedence calls to the end user, up to the total number of call appearances supported by the EI. For each additional incoming precedence call, the AS-SIP EI shall offer the call as described previously, and allow the end user to place the existing active call on hold (if it is a voice call using Audio media) and answer the precedence call as described previously. The ability to place an existing call on hold

2-20

and answer a new precedence call shall be supported until the AS-SIP EI is saturated (i.e., all of its call appearances are in use). (e) When an AS-SIP EI is saturated, and an incoming precedence call is made to that EI, the EI shall determine the lowest precedence call from all of the calls on all of the EI’s call appearances (including those calls that are on hold), and shall preempt that call. (f) If the lowest precedence call is a call on hold, then the AS-SIP EI shall send a preemption tone to the remote party on this held call (the party on hold). (g) The AS-SIP EI shall also send a preemption tone to the local party on this held call by playing this tone on the EI call appearance for this call. (h) After a preset period, the AS-SIP EI shall clear this call on hold and shall play a precedence ringing tone and provide a precedence level display for the call appearance from which the held call has been cleared. As a result, the called user will hear the preemption tone followed by the precedence ringing tone (indicating that the call on hold has been dropped), and see the precedence level of the new call on the AS-SIP EI’s display. (i) The AS-SIP EI shall then give the called user the option of answering the call, or letting it forward to an alternate party (if CFDA is assigned), or letting it divert to an attendant (if Precedence Call Diversion is assigned). (j) If the lowest precedence call is not a call on hold, but instead is the active call at the EI, the AS-SIP EI shall send a preemption tone to both the remote party and the local party on the active call (the local party on the active call appearance). (k) When the local party on the active call appearance goes “on hook,” the AS-SIP EI shall offer the incoming precedence call to that party by playing a precedence ringing tone and providing a precedence level display on the call appearance from which the active call has been cleared. (l) The AS-SIP EI shall then give the called user the option of answering the call, or letting it forward to an alternate party (if CFDA is assigned), or letting it divert to an attendant (if Precedence Call Diversion is assigned). (m) In both of the previous cases (held call preempted and active call preempted), the AS-SIP EI shall not preempt any of the other calls that are on hold (on any other the other call appearances), and shall allow the end user to retrieve any of those calls at any time. h. PEIs, AEIs, TAs, and IADs Using the V.150.1 Protocol. Whenever these types of IP EIs, TAs, or IADs use ITU-T Recommendation V.150.1, the requirements in the following subparagraphs apply. Non-secure AEI phone do not use V.150.1. V.150.1 is used exclusively with TAs, IADs and secure AEI phones. DISA stated the intent to change the requirement to remove applicability from AEI and PEI.

2-21

(1) ITU-T Recommendation V.150.1 provides for three states: audio, voiceband data (VBD), and modem relay. After call setup, inband signaling shall be used to transition from one state to another. In addition, ITU-T Recommendation V.150.1 provides for the transition to FoIP using Fax Relay per ITU-T Recommendation T.38.

(2) When the product uses ITU-T Recommendation V.150.1 inband signaling to transition between audio, Fax over IP (FoIP), modem relay, or VBD states or modes, the product shall continue to use the established session’s protocol (e.g., decimal 17 for User Datagram Protocol [UDP]) and port numbers so that the transition is transparent to the SBC. i. ROUTINE-Only EIs. The SUT is a voice only AEI. Therefore, the ROEI requirements in the following subparagraphs do not apply.

(1) If an SC supports ROUTINE-only voice EIs, it shall also support voice EIs that fully support precedence and preemption.

(2) An SC shall support ROUTINE-only video EIs without providing support for video

EIs that fully support precedence and preemption. (3) ROUTINE-Only (RO) EIs (ROEIs) shall not be able to originate precedence (i.e.,

PRIORITY and above) calls. (4) Precedence calls to ROEIs shall be diverted immediately to an attendant. (5) Sessions involving ROEIs affect ASAC Session Counts in the same way as sessions

involving EIs that fully support precedence and preemption. (6) MLPP/PBAS requirements shall apply to non-ROEIs in sessions involving both RO

and non-ROEIs. (7) Preemption Tone shall be provided to ROEIs on preempted sessions involving both

ROUTINE-only and non-ROEIs. (8) An ROEI shall display the precedence level of the session on which it participates, but

is not required to do so. (9) An ROEI shall support AS-SIP signaling, but will be tested and certified as a PEI, with

the precedence and preemption exceptions noted above in this section. j. Internet Protocol version 6. The EI in conjunction with the Call Connection Agent (CCA) application must be IPv6-capable. Use guidance in UCR 2013 Errata 1, Table 5.2-3 for EI. The EI must also meet the additional IPv6 requirements documented in the UCR 2013, Section 5 paragraphs. The SUT met these requirements with testing and the vendor’s LoC with the following minor exception. The SUT does not support Dynamic Host Protocol version 6 (DHCPv6). DISA accepted the vendor’s POA&M and adjudicated this as minor.

2-22

k. Information Assurance. The EIs must meet the IA requirements in the UCR 2013, Errata 1, Section 4. The SUT met these requirements with the vendor’s LoC. 7. TESTING LIMITATIONS. JITC test teams noted the following testing limitations including the impact they may have on interpretation of the results and conclusions. Any untested requirements are also included in the testing limitations. There were no test limitations. 8. CONCLUSION(S). The SUT meets the critical interoperability requirements for a voice only, non-secure UC AEI in accordance with the UCR. The SUT was tested and is certified for use specifically with REDCOM HDX and REDCOM SLICE 2100 LSCs. The SUT was also tested and is certified for use with the NEC Univerge 3C LSC, which is undergoing final certification for placement on the UC APL. The SUT meets the interoperability requirements for the interfaces listed in Table 3-1.

Enclosure 3

DATA TABLES

Table 3-1. Interface Status

Interface Threshold CR/FR Requirements Status Remarks

Voice EIs

10Base-X (R) 1, 4, 5, 6, 7, 8, 9, 10, and 11 Met The SUT met the CRs and FRs for the IEEE 802.3i interface.

100Base-X (R) 1, 4, 5, 6, 7, 8, 9, 10, and 11 Met The SUT met the CRs and FRs for the IEEE 802.3u interface.

1000Base-X (C) 1, 4, 5, 6, 7, 8, 9, 10, and 11 Not Tested The SUT does not support this conditional interface.

10GBase-X (C) 1, 4, 5, 6, 7, 8, 9, 10, and 11 Not Tested The SUT does not support this conditional interface.

ISDN BRI (C) 2 Not Tested The SUT does not support this conditional interface.



Video EIs 10Base-X (R) 3, 4, 5, 6, 7, 8, 9, 10, and 11 Not Tested Not applicable. The SUT is a voice only AEI.

100Base-X (R) 3, 4, 5, 6, 7, 8, 9, 10, and 11 Not Tested Not applicable. The SUT is a voice only AEI. 1000Base-X (C) 3, 4, 5, 6, 7, 8, 9, 10, and 11 Not Tested Not applicable. The SUT is a voice only AEI. 10GBase-X (C) 3, 4, 5, 6, 7, 8, 9, 10, and 11 Not Tested Not applicable. The SUT is a voice only AEI. ISDN BRI (C) 3, 4, 5, 6, 7, 8, 9, 10, and 11 Not Tested Not applicable. The SUT is a voice only AEI.

Serial (C) 3, 4, 5, 6, 7, 8, 9, 10, and 11 Not Tested Not applicable. The SUT is a voice only AEI. LEGEND: 802.3u 100BASE-TX, 100BASE-T4, 100BASE-FX Fast Ethernet at

100 Mbps 802.3z 1000BASE-X Gbps Ethernet over Fiber-Optic at 1 Gbps AEI AS-SIP End Instrument AS-SIP Assured Services Session Initiation Protocol BRI Basic Rate Interface C Conditional CR Capability Requirement

EI End Instrument FR Functional Requirement Gbps Gigabits per second IEEE Institute of Electrical and Electronics Engineers ISDN Integrated Services Digital Network Mbps Megabits per second R Required SUT System Under Test

3-2

Table 3-2. Capability and Functional Requirements and Status

CR/FR ID

UCR Requirement (High-Level) (See note 1.)

UCR Reference EI Applicability Status

1

IP Voice End Instruments Basic 2.9.1.1 PEI (R) / AEI (R) Met (See note 2.) Tones and Announcements 2.9.1.2 PEI (R) / AEI (R) Met Audio Codecs, Voice Instruments 2.9.1.3 PEI (R) / AEI (R) Met VoIP PEI or AEI Telephone Audio Performance 2.9.1.4 PEI (R) / AEI (R) Met Voice over IP Sampling Standard 2.9.1.5 PEI (R) / AEI (R) Met Softphones 2.9.1.6 PEI (C) / AEI (C) Not Tested (See note 3.) DSCP Packet Marking 2.9.1.7 PEI (R) / AEI (R) Met

2 Analog and ISDN BRI Telephone Support Analog and ISDN BRI Telephone Support 2.9.2 EI (R) Not Tested (See note 3.) ISDN BRI Telephone Support 2.9.2.1 EI (R) Not Tested (See note 3.)

3

Video End Instrument Basic 2.9.3.1 PEI (R) / AEI (R) Not Tested (See note 3.) Display Messages, Tones, and Announcements 2.9.3.2 PEI (R) / AEI (R) Not Tested (See note 3.) Video Codecs (Including Associated Audio Codecs) 2.9.3.3 PEI (R) / AEI (R) Not Tested (See note 3.)

H.323 Video Teleconferencing 2.9.3.4 PEI (R) / AEI (R) Not Tested (See note 3.)

4 Authentication to SC Authentication to SC 2.9.4 PEI (R) / AEI (R) Met

5 End Instrument to ASLAN Interface End Instrument to ASLAN Interface 2.9.5 PEI (R) / AEI (R) Met

6

Operational Framework for AEIs 2.9.6

Requirements for Supporting AS-SIP EIs 2.9.6.1

AEI (R) AS-SIP Voice EI (O)

AS-SIP Secure Voice EI (R) AS-SIP Video EI (O)

Met

Requirements for AS-SIP Voice EIs 2.9.6.2 AS-SIP Voice EI (R) Met Requirements for AS-SIP Secure Voice EIs 2.9.6.3 AS-SIP Secure Voice EI (R) Not Tested (See note 3.) Requirements for AS-SIP Video EIs 2.9.6.4 AS-SIP Video EI (R) Not Tested (See note 3.) AS-SIP Video EI Features 2.9.6.5 AS-SIP Video EI (C) Not Tested (See note 3.)

7

Multiple Call Appearance Requirements for AS-SIP EIs Multiple Call Appearances – Specific Requirements 2.9.7.2 AS-SIP Voice EI (R)

AS-SIP Secure Voice EI (R) Met

Multiple Call Appearances – Interactions With Precedence Calls 2.9.7.3 AS-SIP Voice EI (R)

AS-SIP Secure Voice EI (R)

8

PEIs, AEIs, TAs, and IADs Using the V.150.1 Protocol

PEIs, AEIs, TAs, and IADs Using the V.150.1 Protocol 2.9.8

PEI (R) AEI (R)

Secure AEI (R) Not Tested (See note 4.)

9 ROUTINE-Only EIs

ROUTINE-Only EIs 2.9.10 ROEI non-RO EI Not Tested (See note 3.)

10 Internet Protocol version 6 (IPv6)

IPv6 Section 5 All IP EI (R) Partially Met (See note 5.)

11 Information Assurance (IA) IA Section 4 All EI Met

NOTES: 1. The annotation of ‘required’ refers to a high-level requirement category. The applicability of each sub-requirement is provided in Table 3-5. 2. Security requirements in UCR 2013, Errata 1, Section 4 are met by the vendor’s LoC. In addition, security testing is accomplished by DISA-led Information Assurance test teams and the results published in a separate report, Reference (e). 3. The SUT is a voice only AEI. Therefore, the video, secure voice, and ROEI requirements do not apply. 4. Non-secure AEI phone do not use V.150.1. V.150.1 is used exclusively with TAs, IADs and secure AEI phones. DISA stated the intent to change the requirement to remove applicability from AEI and PEI. 5. The SUT does not support DHCPv6. DISA accepted the vendors POA&M and adjudicated this as minor.

3-3

Table 3-2. Capability and Functional Requirements and Status (continued)

LEGEND: AEI AS-SIP End Instrument AS-SIP Assured Services Session Initiation Protocol ASLAN Assured Services Local Area Network BRI Basic Rate Interface CR Capability Requirement DHCPv6 Dynamic Host Control Protocol version 6 DISA Defense Information Systems Agency EI End Instrument FR Functional Requirement IAD Integrated Access Device

ID Identification IP Internet Protocol ISDN Integrated Services Defense Network PEI Proprietary End Instrument POA&M Plan of Action and Milestones ROEI ROUTINE Only End Instrument SC Session Controller SUT System Under Test TA Terminal Adapter UCR Unified Capabilities Requirements

Table 3-3. SUT Hardware/Software/Firmware Version Identification

Component (See note 1.) Release Sub-component Function

7810 (See note 2.) 05.04.13 Not Applicable AEI 7810-TSG 05.04.13 Not Applicable AEI

7810-PoE-TSGA 05.04.13 Not Applicable AEI 7810-PoE-TSGB 05.04.13 Not Applicable AEI

4101 07.04.13 Not Applicable AEI 4104 06.04.13 Not Applicable AEI

NOTES: 1. Components bolded and underlined were tested by JITC. The other components in the family series were not tested; however, they utilize the same software and similar hardware and JITC analysis determined them to be functionally identical for interoperability certification purposes and they are also certified for joint use. 2. The 7810 is certified with or without the optional 8030x 30-button expander. LEGEND: AEI AS-SIP End Instrument AS-SIP Assured Services Session Initiation Protocol

JITC Joint Interoperability Test Command SUT System Under Test

Table 3-4. Test Infrastructure Hardware/Software/Firmware Version Identification

System Name Software Release Function

Required Ancillary Equipment None.

Test Network Components NEC Univerge 8.5.2.1 LSC

REDCOM High Density Exchange 4.0AR3P9 LSC

REDCOM SLICE 4.0AR3P9 LSC

Acme Packet Net-Net 3820 Session Director 6.3 M2P5 SBC

AS5300 with CS2100 AS5300 3.0 SP3/CS2100 SE09.1 MFSS

Cisco Unified Communications Manager 8.6.1 LSC

Cisco Unified Communications Manager 8.0(2) LSC

Avaya AS5300 2.0 LSC

Avaya AS5300 3.0 SP3 LSC

Avaya Aura S8800 Communication Manager (CM) 6.0.1 (00.1.510.1) Service Pack 19211 LSC LEGEND: LSC Local Session Controller SBC Session Border Controller MFSS Multifunction Softswitch

3-4

Table 3-5. End Instrument Products Capability/Functional Requirements

CR/FR ID Requirement UCR Ref LoC/

Test EI

R/O/C 1 2.9.1 – IP Voice End Instruments

1-1 2.9.1.1 – Basic

1

DoD CAC reader. [See Section 4.2.3.5, Authentication Practices, item 1h(1), for SC and EI requirements on PKI and CAC authentication, and SC and EI requirements on Username and Personal Identification Number (PIN) authentication.]

2.9.1.1 SCM-001930 T PEI (O)

AEI (O)

2 Display calling number. (See Section 2.2.8, Calling Number Delivery, for SC and EI requirements on the Calling Number Delivery feature.)

2.9.1.1 SCM-001940 T PEI (R)

AEI (R)

3 Display precedence level of the session. 2.9.1.1 SCM-001950 T PEI (R)

AEI (R)

4 Use of DSCPs in signaling and media streams. 2.9.1.1 SCM-001960 T PEI (R)

AEI (R)

5 Support for DHCP. 2.9.1.1 SCM-001970 T PEI (R)

AEI (R) 1-2 2.9.1.2 – Tones and Announcements

1

Tones and announcements, as required in Section 2.9.1.2.1, UC Ringing Tones, Cadences, and Information Signals, and Section 2.9.1.2.2, Announcements, shall be supported. These tones and announcements shall be generated locally by the PEI or AEI on the command of the SC, or shall be generated on the command of the SC by an internal SC Media Server or an external Media Server connected to the ASLAN and passed as a media stream to the PEI or AEI. Regardless of how implemented, the Media Server is part of the SC SUT.

2.9.1.2 SCM-001990 T PEI (R)

AEI (R)

2 The UC EIs and signaling appliances shall provide alerting (ringing) for precedence calls (i.e., PRIORITY and above) that is distinct from the alerting for ROUTINE calls.

2.9.1.2.1 SCM-002000 T PEI (R)

AEI (R)

3 The UC EIs and signaling appliances shall implement the ringing tones and cadences shown in Table 2.9-1, UC Ringing Tones and Cadences.

2.9.1.2.1 SCM-002010 T PEI (O)

AEI (O)

4

The AEIs shall be able to provide customized ring tones for incoming precedence calls through the use of pre-recorded audio files (e.g., MP3, AAC [.m4a and .m4r], WAV, WMA, OGG) that are stored in the AEIs. For example, an AEI may store one audio file for use with ringing on incoming PRIORITY calls, another file for use with ringing on incoming IMMEDIATE calls, another file for use with ringing on incoming FLASH calls, and so on. Different audio files can also be associated with different calling numbers when that calling number is used on a Precedence calls (e.g., “This is an IMMEDIATE call from General John Smith.”).

2.9.1.2.1 SCM-002020 T AEI (O)

5 The EIs and signaling appliances shall implement the UC information signals shown in Table 2.9-2, UC Information Signals.

2.9.1.2.1 SCM-002030 T PEI (R)

AEI (R)

6

The announcements in Table 2.9-3, Required Announcements, shall be supported, along with all announcements that are associated with a specific NM trunk group and/or code control implementation. Each announcement shall contain a location identification number to be provided by the Government. The appliance playing the announcement (or serving the EI that is playing the announcement) shall be identified by “Switch Name and Location.” Announcements shall be capable of being recorded and changed by Government O&M personnel. Additional local messages may be added and optionally activated, deactivated, or modified via administrative or operational controls.

2.9.1.2.2 SCM-002040 T PEI (R)

AEI (R)

7

If an announcement in Table 2.9-4, Optional Announcements, is provided, it shall contain a location identification number to be provided the Government. The appliance playing the announcement (or serving the EI that is playing the announcement) shall be identified by “Switch Name and Location.” Announcements shall be capable of being recorded and changed by Government O&M personnel.

2.9.1.2.2 SCM-002045 T PEI (C)

AEI (C)

3-5

Table 3-5. End Instrument Products Capability/Functional Requirements (continued)


Test EI

R/O/C

8

The LOC2 Features announcement applies only to calls placed via an SC MG or an SS MG to a non-MLPP PRI or CAS trunk and shall be provided IAW the following: a. Play only for calls above the ROUTINE precedence level. b. Not required for locally originated calls to non-MLPP PRI or CAS trunks

(e.g., PSTN). c. Appropriate for VoIP calls received from the DISN WAN, or calls received

from a base MLPP tie trunk via an MG that are destined to tandem via an SC MG or SS MG to a non- MLPP PRI or CAS trunk.

d. Play before ringback is provided to the caller. e. Play before cut-through to the non-MLPP trunk. This prevents ringback

from interfering with the announcement. f. The announcement shall be played into the media stream at the MG point of

departure from the DISN to the non-MLPP trunk. g. The LOC2 announcement is not signaled by AS-SIP.

2.9.1.2.3 SCM-002060 T PEI (O)

AEI (O)

1-3 2.9.1.3 – Audio Codecs, Voice Instruments

1 EIs and MGs shall support the origination and termination of a voice session using the ITU-T Recommendation G.711 codec, including both the μ-law and A-law algorithms.

2.9.1.3 SCM-002070 L/T PEI (R)

AEI (R)

2 EIs and MGs shall support the origination and termination of a voice session using the ITU-T Recommendation G.729 or G.729A codec.

2.9.1.3 SCM-002080 L/T PEI (R)

AEI (R)

3 EIs and MGs shall support the origination and termination of a voice session using the ITU-T Recommendation G.723.1 codec.

2.9.1.3 SCM-002090 L/T PEI (O)

AEI (O)

4 EIs and MGs shall support the origination and termination of a voice session using the ITU-T Recommendation G.722.1 codec.

2.9.1.3 SCM-002100 L/T PEI (O)

AEI (O) 1-4 2.9.1.4 – VoIP PEI or AEI Telephone Audio Performance

1 Voice over IP PEIs or AEIs (i.e., handset, headset, and hands-free types) shall comply with Telecommunications Industry Association (TIA)-810-B, November 3, 2006.

2.9.1.4 SCM-002110 L PEI (R)

AEI (R)

1-5 2.9.1.5 – Voice over IP Sampling Standard

1

For Fixed-to-Fixed calls, the product shall use 20 ms as the default voice sample length, and as the basis for the voice payload packet size. For other call types, e.g., Fixed-to-Deployable calls, the product shall use different voice sample lengths and voice payload packet sizes, as negotiated during call setup via the Session Description Protocol (SDP).

2.9.1.5 SCM-002120 T PEI (R)

AEI (R)

1-6 2.9.1.6 – Softphones

1

If a softphone is supported by an SC or SS, the softphone shall be conceptually identical to a traditional IP “hard” telephone and is required to provide voice features and functionality provided by a traditional IP hard telephone, unless explicitly stated here within this paragraph. The softphone application in conjunction with a general-purpose computer, including its mouse (point and click) interaction, shall support, as a minimum, the following requirements: a. Section 2.2, Voice Features and Capabilities. b. Section 2.9.1.1, Basic. c. Section 2.9.1.2, Tones and Announcements. d. Section 2.9.1.3, Audio Codecs, Voice Instruments. e. Section 2.9.1.4, VoIP PEI or AEI Telephone Audio Performance. f. Section 2.9.1.5, Voice over IP Sampling Standard. g. Section 2.9.4, Authentication to SC. h. Section 2.9.5, End Instrument to ASLAN Interface. i. Section 6, Network Infrastructure End-to-End Performance. The softphone

application shall be exempt from the performance (i.e., packet loss, jitter, latency) requirements specified in Section 6, Network Infrastructure End-to-End Performance; e.g., the PEI/AEI 50-ms latency for the G.711 codec.

j. Section 6.3.2, VVoIP Differentiated Services Code Point. k. Section 4, Information Assurance.

2.9.1.6 SCM-002130 T PEI (C)

AEI (C)

2

If an EI is a softphone, then it shall inhibit any screen saver or lock screen capability whenever the softphone application is active (i.e., user is on a call). This is to avoid the situation where the user needs to interact with the softphone application via the mouse or keyboard expeditiously (e.g., respond to a new call) but first needs to re-login.

2.9.1.6 SCM-002140 T PEI (C)

AEI (C)

3-6



Test EI

R/O/C 1-7 2.9.1.7 – DSCP Packet Marking

1

As part of the session setup process, the SC controls what DSCP to use in the subsequent session media stream packets. For inter-SC media sessions (across the WAN), and intra-SC media sessions (internal to the enclave), one of the following occurs: a. The PEI shall be commanded by the SC about which DSCP to insert in the

session media stream packets. b. The PEI shall populate the DSCP marking on its own. c. The AEI shall populate the DSCP marking on its own.

2.9.1.7 SCM-002150 T PEI (R)

AEI (R)

2

The exact DSCP method used by the implementer shall comply with Section 6, Network Infrastructure End-to-End Performance. The session’s media type (e.g., audio vs. video) and the session’s precedence level (R, P, I, F, or FO) shall be used to determine the media stream DSCP for that session

2.9.1.7 SCM-002160 T PEI (R)

AEI (R)

2 2.9.2 – Analog and ISDN BRI Telephone Support

1

Analog instruments, including secure analog EIs, analog facsimile (fax) EIs, and analog modem EIs, shall be supported by the SC either by a Terminal Adapter, RJ-11 POTS telephone to RJ-45 Ethernet interface (TA), or an IAD, 4 or more ports of RJ-11 POTS telephone to one port of RJ-45 Ethernet interface. SCM-002170.e Analog telephones, when combined with a TA or IAD, together shall comply with TIA-810-B, November 3, 2006.

2.9.2 SCM-002170 L EI (R)

2

Analog instruments, including secure analog EIs, analog facsimile EIs, and analog modem EIs, shall be supported by the existing twisted-pair cable plant connected to line cards that are part of the SC MG. SCM-002180.c Analog telephones, when connected to a line card, together shall comply with TIA-810-B, November 3, 2006.

2.9.2 SCM-002180 L EI (R)

2-1 2.9.2.1 – ISDN BRI Telephone Support

1 The ISDN BRI telephones when combined with a BRI-capable TA, BRI-capable IAD, or BRI-capable MG line card shall comply with TIA-810-B, November 3, 2006.

2.9.2 SCM-002270 L/T EI (R)

2

If an SC, TA, IAD, or SC MG support ISDN BRI EIs (both standard and secure), the SC, TA, IAD, or SC MG shall support all the DSN ISDN BRI requirements in the following DSN sections: a. Section 2.25.1.6, ISDN MLPP BRI. b. Section 2.25.1.8, MLPP Interactions With Common Optional Features and

Services. c. Section 2.25.1.9, MLPP Interactions With Electronic Key Telephone

Systems Features. d. Section 2.25.2, Signaling. e. Section 2.25.3, ISDN.

2.9.2 SCM-002280 T EI (C)

3 2.9.3 – Video End Instrument

3-1 2.9.3.1 – Basic. An IP video EI shall be designed IAW the acquiring activity requirements, but the following capabilities are specifically required or optional as indicated:

1 DoD CAC card reader. 2.9.3.1 SCM-002290 L/T PEI (O)

AEI (O) 2

Automatic enabling of the video camera is not permitted after video session negotiation or acceptance. The called party must take a positive action to enable the camera.

2.9.3.1 SCM-002300 T PEI (R)

AEI (R) 3 Display calling number. 2.9.3.1

SCM-002310 T PEI (R) AEI (R)

4 Display precedence level of the session. 2.9.3.1 SCM-002320 T PEI (O)

AEI (O) 5 Support for MLPP feature. 2.9.3.1

SCM-002330 T PEI (O) AEI (O)

6 Support for DHCP. 2.9.3.1 SCM-002340 T PEI (R)

AEI (R) 3-2 2.9.3.2 – Display Messages, Tones, and Announcements

3-7



Test EI

R/O/C

1

Tones and announcements, as appropriate for voice and video over IP, and as required, in Section 2.9.1.2.1, UC Ringing Tones, Cadences, and Information Signals, and Section 2.9.1.2.2, Announcements, shall be supported by the PEI and AEI, except for the loss of the C2 announcement. These tones and announcements shall be generated locally by the PEI and AEI on the command of the SC, or generated on command of the SC by an internal SC Media Server or an external Media Server connected to the ASLAN, and passed as a media stream to the PEI and AEI. Regardless of how implemented, the Media Server is part of the SC SUT.

2.9.3.2 SCM-002350 T PEI (R)

AEI (R)

3-3 2.9.3.3 – Video Codecs (Including Associated Audio Codecs)

1

The product shall support the origination, maintenance, and termination of a video session using the following codecs: one G.xxx and one H.xxx shall be used to create and sustain a video session. (All video and audio capabilities in the PEI or AEI shall be sent to the terminating PEI or AEI for negotiation about which video and audio codec to use for the session.)

2.9.3.3 SCM-002360 T PEI (R)

AEI (R)

2 Video PEIs and AEIs shall support, at a minimum, G.711 PCM, where PCM has a static payload type value of 0 and a clock rate of 8000. The PCM shall support both the μ-law and A-law algorithms.

2.9.3.3 SCM-002370 L/T PEI (R)

AEI (R)

3

It is recommended that video PEIs and AEIs support other audio codecs in addition to G.711 PCM. Recommended audio codecs include the following: a. ITU-T Recommendation G.722, where G.722 has a static payload type

value of 9 and a clock rate of 8000. b. ITU-T Recommendation G.722.1, where G.722.1 has the encoding name

“G7221”, a clock rate of 16000, and a standard bit rate of 24 Kbps or 32 Kbps.

c. ITU-T Recommendation G.723.1, where G.723.1 has the encoding name “G723”, a clock rate of 8000, and standard bit rates of 5.3 Kbps and 6.3 Kbps.

d. ITU-T Recommendation G.729, where G.729 has the encoding name “G729”, a clock rate of 8000, and a standard bit rate of 8 Kbps.

e. ITU-T Recommendation G.729 Annex A (G.729A), where G.729A also has the encoding name “G729”, a clock rate of 8000, and a standard bit rate of 8 Kbps.

2.9.3.3 SCM-002380 L/T PEI (O)

AEI (O)

4

Video PEI and AEI shall support, at a minimum, the following video codecs: a. ITU-T Recommendation H.263-2000. b. ITU-T Recommendation H.264

SCM-002390.a [Optional] ITU-T Recommendation H.264, Scalable Video Coding (SVC). SCM-002390.b [Optional] ITU-T Recommendation H.261.

2.9.3.3 SCM-002390 L/T PEI (R)

AEI (R)

3-4 2.9.3.4 – H.323 Video Teleconferencing 1 The H.323 VTC system and end points should meet the requirements of FTR

1080B-2002. 2.9.3.4

SCM-002400 L All (O)

2

H.323 VTC features and functions used in conjunction with IP network services should meet the requirements of H.323 in accordance with FTR 1080B-2002, and H.323 video EIs should meet the tagging requirements as specified in Section 7, Network Edge Infrastructure.

2.9.3.4 SCM-002410 L All (O)

3 A loss of any conferee on a multipoint H.323 videoconference shall not terminate or degrade the DSN service supporting H.323 VTC connections of any of the other conferees on the videoconference.

2.9.3.4 SCM-002420 T All (R)

4 An audio add-on interface shall be provided on H.323 VTC equipment IAW Section 3.7, Customer Premise Equipment.

2.9.3.4 SCM-002430 N/A All (O)

5

If an H.323VTC system or end-point uses an integrated BRI interface to connect to the DSN, then it shall be in conformance with the requirements associated with a TA as described in Section 3.7, Customer Premise Equipment, and Section 2.9.2.1, ISDN BRI Telephone Support.

2.9.3.4 SCM-002440 N/A All (C)

6

If a VTC system or end-point uses a serial interface to another device, such as a cryptographic device or TA, for eventual connection to the DSN, it shall be in conformance with the requirements for that serial interface as described in FTR 1080B-2002.

2.9.3.4 SCM-002450 N/A All (C)

7

Physical, electrical, and software characteristics of a video teleconferencing unit (VTU) system or end point that is used in the DSN network shall not degrade, or impair, the serving DSN switch and its associated network operations.

2.9.3.4 SCM-002460 N/A All (R)

3-8



Test EI

R/O/C 4 2.9.4 – Authentication to SC 1 The PEI and AEI shall each be capable of authenticating itself to its associated

SC and vice versa IAW Section 4, Information Assurance. 2.9.4

SCM-002470 T PEI (R) AEI (R)

5 2.9.5 – End Instrument to ASLAN Interface

1 The interface to the ASLAN shall be IAW Ethernet (IEEE 802.3) Local Area Network (LAN) technology. The 10-Mbps and 100-Mbps Fast Ethernet (IEEE 802.3u) shall be supported.

2.9.5 SCM-002480 T PEI (R)

AEI (R)

6 2.9.6 – Operational Framework for AEIs 6-1 2.9.6.1 – Requirements for Supporting AS-SIP EIs

1

The AS-SIP EIs (voice, secure voice, and video) shall follow all of the previous requirements for EIs (voice and video, with secure voice EIs following the previous requirements for voice EIs), except for those requirements that involve vendor-proprietary SC-to-EI signaling.

2.9.6.1 SCM-002490 T AEI (R)

2

The SCs and AS-SIP EIs (voice, secure voice, and video) shall support mutual authentication using AS-SIP and TLS signaling instead of vendor-proprietary signaling. That is, each AS-SIP EI shall authenticate itself with its serving SC using AS-SIP and TLS signaling, and each SC shall authenticate itself with the AS-SIP EIs that it serves using AS-SIP and TLS signaling.

2.9.6.1 SCM-002500 T AEI (R)

3

A single AS-SIP EI shall support voice, secure voice, and video capabilities. In this case, the EI shall support those capabilities IAW the combined requirements for an AS-SIP voice EI, an AS-SIP secure voice EI, and an AS-SIP video EI, as given in Section 2.9.6.2, Requirements for AS-SIP Voice EIs; Section 2.9.6.3, Requirements for AS-SIP Secure Voice EIs; and Section 2.9.6.4, Requirements for AS-SIP Video EIs.

2.9.6.1 SCM-002520 T AEI (O)

4

A single AS-SIP EI shall support both voice and secure voice capabilities. In this case, the EI shall support those capabilities IAW the combined requirements for an AS-SIP voice EI and an AS-SIP secure voice EI, as given in Section 2.9.6.2, Requirements for AS-SIP Voice EIs, and Section 2.9.6.3, Requirements for AS-SIP Secure Voice EIs.

2.9.6.1 SCM-002530 T

AS-SIP Voice EI (O)

AS-SIP Secure Voice EI (O)

5

A single AS-SIP EI shall support both Voice and Video capabilities. In this case, the EI shall support those capabilities IAW the combined requirements for an AS-SIP voice EI and an AS-SIP video EI, as given in Section 2.9.6.2, Requirements for AS-SIP Voice EIs, and Section 2.9.6.4, Requirements for AS-SIP Video EIs.

2.9.6.1 SCM-002540 T

AS-SIP Voice EI (O)

AS-SIP Video EI (O)

6

An AS-SIP secure voice EI shall also support the capabilities of an AS-SIP Voice EI IAW the AS-SIP voice EI requirements given in Section 2.9.6.2, Requirements for AS-SIP Voice EIs. The AS-SIP secure voice EI shall support these capabilities for “voice communication in the clear” using the Audio media type and the G.7XX codecs.

2.9.6.1 SCM-002550 T AS-SIP Secure

Voice EI (R)

6-2 2.9.6.2 – Requirements for AS-SIP Voice EIs

1

The AS-SIP voice EIs shall support AS-SIP for EI-to-SC signaling. These AS-SIP voice EIs shall support the AS-SIP SC-to-AS-SIP-EI interface defined in Section 2.9.7, Multiple Call Appearance Requirements for AS-SIP EIs, and in AS-SIP 2013.

2.9.6.2 SCM-002570 T AS-SIP Voice

EI (R)

2

The SCs and AS-SIP Voice EIs shall support the following supplementary services for voice calls, consistent with Section 2.2, Voice Features and Capabilities, using AS-SIP signaling. a. Precedence Call Waiting [Required]. b. Call Forwarding [Required]. c. Call Transfer [Required]. d. Call Hold [Required]. e. UC Conferencing [Optional]. f. Three-Way Calling [Required]. g. Calling Number Delivery [Required].

(1) Calling Name [Optional]. (2) Calling Party Org and Location [Optional].

h. Call Pickup [Optional].


EI (R)

6-3 2.9.6.3 – Requirements for AS-SIP Secure Voice EIs

1

AS-SIP Secure Voice EIs shall support AS-SIP for EI-to-SC signaling. These AS-SIP secure voice EIs shall support the AS-SIP SC-to-AS-SIP-EI interface defined in Section 2.9.7, Multiple Call Appearance Requirements for AS-SIP EIs, and in AS-SIP 2013.


Voice EI (R)

3-9



Test EI

R/O/C 2 An AS-SIP secure voice EI shall be able to operate as an AS-SIP voice EI for

voice calls (calls using Audio media and not SCIP/modem relay media). 2.9.6.3

SCM-002640 N/A AS-SIP Secure Voice EI (R)

3

An AS-SIP secure voice EI shall be able to operate as an AS-SIP voice EI for the portions of calls where Audio media is used (and SCIP/modem relay media is not used). This AS-SIP secure voice EI requirement applies during the time before a call converts from Audio media to SCIP/modem relay media, and during the time after a call converts from SCIP/modem relay media back to Audio media. This requirement also applies to a call that never converts to SCIP/modem relay media, and uses Audio media for the lifetime of the call.

2.9.6.3 SCM-002650 N/A AS-SIP Secure

Voice EI (R)

4

An AS-SIP Secure Voice EI shall not allow the end user to activate any supplementary services when a call on that EI is operating in “Secure Voice” mode, and SCIP/modem relay media is being used. When an end user tries to use a supplementary service when a call on the EI is operating in secure voice mode, the EI shall prevent the user from activating the service, and shall return an error indication (i.e., a locally generated tone and a visual display) back to that user. The error indication shall indicate that the end user must return the secure voice call to a “Clear Voice” call before the supplementary service can be used.


Voice EI (R)

5

Whenever the local end user returns the Secure Voice call to a Clear Voice call, or the remote end user returns the secure voice call to a clear voice call, the AS-SIP secure voice EI shall return a “clear voice confirmation” indication (i.e., a locally generated tone and a visual display) to the local end user. This lets the local end user know that the call has returned from secure voice mode to clear voice mode. It also lets them know that they are no longer communicating in secure voice mode, and lets them know that they can activate supplementary services if desired.


Voice EI (R)

6

An AS-SIP secure voice EI shall support supplementary services when all calls on that EI are operating in clear voice mode, and Audio media alone is being used. When an end user tries to use a supplementary service when all calls on the EI are operating in clear voice mode, the EI shall allow the user to activate the service, and shall process the service request accordingly. This requirement shall also apply after the user has returned a secure voice call to a clear voice call (e.g., in response to an error indication from the EI during the secure voice call), and then tries to use a supplementary service on the clear voice call.


Voice EI (R)

7

When operating as an AS-SIP voice EI (i.e., all EI calls are in clear voice mode), an AS-SIP secure voice EI shall support the following supplementary services for voice calls, consistent with Section 2.2, Voice Features and Capabilities, using AS-SIP signaling: a. Precedence Call Waiting [Required]. b. Call Forwarding [Required]. c. Call Transfer [Required]. d. Call Hold [Required]. e. UC Conferencing [Optional]. f. Three-Way Calling [Required]. g. Calling Number Delivery [Required]. h. Call Pickup [Optional].


Voice EI (R)

8

When an AS-SIP secure voice EI has a secure voice call active, the SC sends that EI a Precedence CW or ROUTINE CW indication, and the EI user attempts to place the secure voice call on hold and answer the waiting call, the EI shall send an error indication (tone and display) to the user as described previously. If the user converts the secure voice call back to a clear voice call, and then tries to place the clear voice call on hold and answer the waiting call, the EI shall accept the user’s request and relay it to the SC.


Voice EI (R)

9

When an AS-SIP secure voice EI has a secure voice call active, and the EI user attempts to activate Call Transfer by placing the secure voice call on hold and setting up another call, the EI shall send an error indication (tone and display) to the user as described previously. If the user converts the secure voice call back to a clear voice call, and then tries to activate Call Transfer by placing the clear voice call on hold and setting up another call, the EI shall accept the user’s request and relay it to the SC.


Voice EI (R)

3-10



Test EI

R/O/C

10

When an AS-SIP secure voice EI has a secure voice call active, and the EI user attempts to activate Call Hold by placing the secure voice call on hold, the EI shall send an error indication (tone and display) to the user as described previously. If the user converts the secure voice call back to a clear voice call, and then tries to activate Call Hold by placing the clear voice call on hold, the EI shall accept the user’s request and relay it to the SC.


Voice EI (R)

11

When an AS-SIP secure voice EI has a secure voice call active, and the EI user attempts to activate TWC by placing the secure voice call on hold and setting up another call, the EI shall send an error indication (tone and display) to the user as described previously. If the user converts the secure voice call back to a clear voice call, and then tries to activate TWC by placing the clear voice call on hold and setting up another call, the EI shall accept the user’s request and relay it to the SC.


Voice EI (R)

12

When an AS-SIP secure voice EI has a secure voice call active, and the SC sends that EI a Precedence CW or Routine CW indication and provides Calling Party ID and Precedence Level information within the CW indication, the AS-SIP Secure Voice EI shall display both the Calling Party ID and Precedence Level information to the called user at the EI, as part of the CW indication that the EI delivers to the called user. (This gives the called users a basis for deciding whether to answer or ignore a “waiting” voice call when they have a secure voice call active on their EI. “Ignore,” as used here, means that the user allows the call to be forwarded by the CFDA feature or deflected by the Precedence Call Diversion feature.)


Voice EI (R)

6-4 2.9.6.4 – Requirements for AS-SIP Video EIs

1

The AS-SIP Video EIs shall support AS-SIP for EI-to-SC signaling. These AS-SIP Video EIs shall support the AS-SIP SC-to-AS-SIP-EI interface defined in Section 2.9.7, Multiple Call Appearance Requirements for AS-SIP EIs, and in AS-SIP 2013.

2.9.6.3 SCM-002760 T AS-SIP Video

EI (R)

2

The SCs and AS-SIP Video EIs shall support the following supplementary services for video calls, as an extension of the requirement to support these services for voice calls in Section 2.2, Voice Features and Capabilities: a. Precedence Call Waiting. b. Call Forwarding. c. Call Transfer. d. Call Hold. e. UC Conferencing. f. Three-Way Calling. g. Calling Number Delivery. h. Call Pickup.


EI (O)

3

The SC, SS, and the AS-SIP Video EI shall support the transmission of H.281 far-end camera control (FECC) messages when used in conjunction with video systems (e.g., MCUs and VTC bridges) that employ far-end camera control capabilities. The specific requirements for implementing this capability are provided in AS-SIP 2013, Section 10.3.6.1, General H.224 Control Channel for Far-End Camera Control Messages, and in Section 10.3.6, FECC.

2.9.6.4 SCM-002780 L/T AS-SIP Video

EI (O)

4

The SC, SS, and the AS-SIP Video EI shall support (when used in multipoint conferences) the Binary Floor Control Protocol (BFCP) that uses a floor control server to manage the control of media streams that are shared resources (i.e., “floors”) as specified in RFC 4582. The specific requirements for implementing this capability are provided in Section 5.3.4.9.7.5, SDP Attributes for Binary Floor Control Protocol Streams.


EI (O)

5 If SCs, SSs, and AS-SIP Video EIs support the optional supplementary services noted above (within Section 2.9.6.4), they shall support them using AS-SIP signaling.

2.9.6.4 SCM-002800 N/A AS-SIP Video

EI (O)

6 The SC and the AS-SIP Video EI shall support a mechanism to identify the amount of video call bandwidth, expressed in VSUs, in use at that EI at any given time.


EI (O)

7

The SC and the AS-SIP Video EI shall support the conversion of a lower-bandwidth video call to a higher-bandwidth video call (and vice-versa), using AS-SIP re-INVITE messages on the SC-to-AS-SIP-EI interface to signal the bandwidth change.


EI (O)

3-11



Test EI

R/O/C

8 The SC and the AS-SIP Video EI shall support the conversion of a video call to a voice call (and vice-versa), using AS-SIP re-INVITE messages on the SC-to-AS-SIP-EI interface to signal the media change.


EI (O)

6-5 2.9.6.5 – AS-SIP Video EI Features

1

If the AS-SIP Video EI supports FECC based on the following: • ITU-T Recommendation H.224. • ITU-T Recommendation H.281.

Then the EI shall support all the AS-SIP and SDP protocol requirements for FECC in the following: • AS-SIP 2013, Section 10.3.6.1, General H.224 Control Channel for Far

End Camera Control Messages.


EI (C)

2

If the AS-SIP Video EI supports BFCP based on the following: • RFC 4582. • RFC 4583.

Then the EI shall support all the AS-SIP and SDP protocol requirements for BFCP in the following: • AS-SIP 2013, Section 10.3.3.2.1, SDP Requirements for the Binary

Control Protocol (Based on RFC 4583).


EI (C)

3

If the AS-SIP Video EI supports VCFC based on the following: • RFC 4585.

Then the EI shall support all the AS-SIP and SDP protocol requirements for VCFC in the following: • AS-SIP 2013, Section 10.3.4, Video Channel Flow Control.


EI (C)

4

If the AS-SIP Video EI supports VCFC based on the following: • RFC 4585.

Then the EI shall support all of the following sections of RFC 4585: • Section 3.1, Compound RTCP Feedback Packets. • Section 3.2, Algorithm Outline. • Section 3.3, Modes of Operation. • Section 3.4, Definitions and Algorithm Over view. • Section 3.5, AVPF RTCP Scheduling Algorithm, and all subsections 3.5.1

– 3.5.4, inclusive. • Section 3.6.1, ACK Mode. • Section 3.6.2, NACK Mode. • Section 4.1, Profile Identification. • Section 4.2, RTCP Feedback Capability Attribute. • Section 4.3, RTCP Bandwidth Modifiers. • Section 5, Interworking and Coexistence of AVP and AVPF Entities. • Section 6, Format of RTCP Feedback Messages. • Section 6.1, Common Packet Format for Feedback Messages. • Section 6.2, Transport Layer Feedback Messages (including 6.2.1 Generic

NACK). • Section 6.3, Payload-Specific Feedback Messages, including:

– Section 6.3.1, Picture Loss Indication (PLI) and its subsections. – Section 6.3.2, Slice Loss Indication (SLI) and its subsections. – Section 6.3.3, Reference Picture Selection Indication (RPSI) and its subsections.

• Section 6.4, Application Layer Feedback Messages.

2.9.6.5 SCM-002880 L AS-SIP Video

EI (C)

5

If the AS-SIP Video EI supports Video Channel Fast Update Requests (VCFURs) based on the following: • RFC 5104.

Then the EI shall support all the AS-SIP and SDP protocol requirements for VCFUR in the following: • AS-SIP 2013, Section 10.3.5, Video Channel Fast Update Requests.


EI (C)

6 If the AS-SIP Video EI supports VCFUR, Full Intra Request (FIR) payload-specific feedback message shall be used for implementing VCFUR.


EI (C)

7 2.9.7 – Multiple Call Appearance Requirements for AS-SIP EIs 7-1 2.9.7.2 – Multiple Call Appearances – Specific Requirements

3-12



Test EI

R/O/C

1

AN AS-SIP EI shall allow multiple call appearances of the same DN (10-digit DSN number) to be assigned to it. AN AS-SIP EI shall allow at least two appearances of the same DN to be assigned to it. This requirement does not apply to AS-SIP Video EIs.

2.9.7.2 SCM-002910 T

AS-SIP Voice EI (R)


2

AN AS-SIP EI shall allow each call appearance of a DN to be used for voice and secure voice calls to and from that DN. This requirement does not apply to AS-SIP Video EIs. Dedication of call appearances on an EI to a particular call type (Voice, Secure Voice, or Video) is not a requirement.

2.9.7.2 SCM-002920 T

AS-SIP Voice EI (R)


3

AN AS-SIP Video EI shall support at least one DN for video calls, and support at least one video call on that DN at a time. AN AS-SIP Video EI is not required to use a call appearance to support this video call. AN AS-SIP Video EI that is also an AS-SIP Voice EI (and supports voice calls and two voice call appearances) is not required to use either of its voice call appearances to support this video call.


EI (R)

4 AN AS-SIP Voice EI shall be able to support two simultaneous voice calls (media type equals Audio) using two call appearances of the same DN (10-digit DSN number).


EI (R)

5 When operating as an AS-SIP Voice EI (no Secure voice calls active), an AS-SIP Secure Voice EI shall be able to support two simultaneous voice calls (media type equals Audio) using two call appearances of the same DN.


Voice EI (R)

6

When operating as an AS-SIP Secure Voice EI (one Secure voice call active), an AS-SIP Secure Voice EI shall be able to support one Secure voice call (media type equals modem relay) using one of its two call appearances. The EI may also support a voice call (media type equals Audio) on Hold using its other call appearance in this case.


Voice EI (R)

7

AN AS-SIP Video EI shall be able to support at least one video call (media type equals Video). If the AS-SIP EI is also an AS-SIP Voice EI or AS-SIP Secure Voice EI, the EI is not required to use either of its voice call appearances to support the video call.


EI (R)

8 The AS-SIP EI and SC shall allow multiple media types to be requested (as part of SDP capability declaration) in the same EI-to-SC INVITE message.

2.9.7.2 SCM-002980 T

AS-SIP Voice EI (R)


9 The SC and AS-SIP EI shall allow multiple media types to be requested (as part of SDP capability declaration) in the same SC-to-EI INVITE message.

2.9.7.2 SCM-002990 T

AS-SIP Voice EI (R)


10

AN AS-SIP EI shall allow only one voice call (voice or secure voice) to be associated with one call appearance at a time. An AS-SIP EI shall not allow multiple calls (e.g., one active call and one held call) to be associated with the same call appearance at the same time.

2.9.7.2 SCM-003000 T

AS-SIP Voice EI (R)


11

AN AS-SIP EI shall allow multiple voice calls to be associated with itself, as long as each call is associated with one, and only one, call appearance on that AS-SIP EI. AN AS-SIP EI shall allow each call associated with the EI to be in either an “active” state, a “held” state, or a “call in progress” state (a call in the process of being established).

2.9.7.2 SCM-003010 T

AS-SIP Voice EI (R)


12

AN AS-SIP secure voice EI shall allow only one secure voice call (media equals modem relay) to be associated with the EI at a time, and allow that call to be associated with one call appearance on that EI. The AS-SIP EI shall allow this secure voice call to be in only an “active” state, and not in a “held” state, or a “call in progress” state.


Voice EI (R)

13

When a secure voice call is active, the AS-SIP secure voice EI shall also allow an additional voice call (media equals Audio) to be associated with the EI, and allow that call to be associated with the second call appearance on that EI. The AS-SIP EI shall allow this additional voice call to be in only a “held” state or a “call in progress” state (a call in the process of being established), and not in an “active” state. For example, if the CW feature is assigned, the EI shall allow an active Secure voice call on one call appearance and an incoming “in progress” voice call on the other call appearance.


Voice EI (R)

14

AN AS-SIP EI shall allow a call on a single call appearance to transition from one media type to another, using an in-band media message for a media change (like a V.150.1 modem relay SSE message). AN AS-SIP EI shall support transitions from voice media to secure voice media, and transitions from secure voice media to voice media.

2.9.7.2 SCM-003040 T

AS-SIP Voice EI (R)


3-13



Test EI

R/O/C 7-2 2.9.7.3 – Multiple Call Appearances – Interactions With Precedence Calls

1

When an incoming precedence call is offered on a multiple-call appearance AS-SIP EI, the EI shall do all of the following: a. Play a precedence ringing tone for that call. b. Offer the call on the next available call appearance for the indicated DN. c. Provide a visual precedence level display to the called user. d. Allow the called user to place any currently active call (on the currently

active appearance) on hold and answer the incoming precedence call on the new call appearance.

2.9.7.3 SCM-003050 T

AS-SIP Voice EI (R)


2

When the called user of an incoming precedence call offered on a multiple-call-appearance AS-SIP EI, does not answer that precedence call, the call shall be forwarded IAW the Call Forwarding Don’t Answer feature, or diverted to a designated UC DN IAW the Precedence Call Diversion feature.

2.9.7.3 SCM-003060 T

AS-SIP Voice EI (R)


3

If the AS-SIP EI is a secure voice EI and the currently active call is a secure voice call using modem relay media, the EI shall require the called user to convert the currently active call back to a voice call using Audio media before placing it on hold. The AS-SIP EI shall not allow a Secure voice call using modem relay media to be placed on hold.


Voice EI (R)

4

The AS-SIP voice EI shall offer subsequent incoming precedence calls to the end user, up to the total number of call appearances supported by the EI. For each additional incoming precedence call, the AS-SIP EI shall offer the call as described previously, and allow the end user to place the existing active call on hold (if it is a voice call using Audio media) and answer the precedence call as described previously. The ability to place an existing call on hold and answer a new precedence call shall be supported until the AS-SIP EI is saturated (i.e., all of its call appearances are in use).

2.9.7.3 SCM-003080 T

AS-SIP Voice EI (R)


5

When an AS-SIP EI is saturated, and an incoming precedence call is made to that EI, the EI shall determine the lowest precedence call from all of the calls on all of the EI’s call appearances (including those calls that are on hold), and shall preempt that call.

2.9.7.3 SCM-003090 T

AS-SIP Voice EI (R)


6 If the lowest precedence call is a call on hold, then the AS-SIP EI shall send a preemption tone to the remote party on this held call (the party on hold).

2.9.7.3 SCM-003100 T

AS-SIP Voice EI (R)


7 The AS-SIP EI shall also send a preemption tone to the local party on this held call by playing this tone on the EI call appearance for this call.

2.9.7.3 SCM-003110 T

AS-SIP Voice EI (R)


8 After a preset period, the AS-SIP EI shall clear this call on hold and shall play a precedence ringing tone and provide a precedence level display for the call appearance from which the held call has been cleared.

2.9.7.3 SCM-003120 T

AS-SIP Voice EI (R)


9 The AS-SIP EI shall then give the called user the option of answering the call, or letting it forward to an alternate party (if CFDA is assigned), or letting it divert to an attendant (if Precedence Call Diversion is assigned).

2.9.7.3 SCM-003130 T

AS-SIP Voice EI (R)


10

If the lowest precedence call is not a call on hold, but instead is the active call at the EI, the AS-SIP EI shall send a preemption tone to both the remote party and the local party on the active call (the local party on the active call appearance).

2.9.7.3 SCM-003140 T

AS-SIP Voice EI (R)


11

When the local party on the active call appearance goes “on hook,” the AS-SIP EI shall offer the incoming precedence call to that party by playing a precedence ringing tone and providing a precedence level display on the call appearance from which the active call has been cleared.

2.9.7.3 SCM-003150 T

AS-SIP Voice EI (R)


12 The AS-SIP EI shall then give the called user the option of answering the call, or letting it forward to an alternate party (if CFDA is assigned), or letting it divert to an attendant (if Precedence Call Diversion is assigned).

2.9.7.3 SCM-003160 T

AS-SIP Voice EI (R)


13

In both of the previous cases (held call preempted and active call preempted), the AS-SIP EI shall not preempt any of the other calls that are on hold (on any other the other call appearances), and shall allow the end user to retrieve any of those calls at any time.

2.9.7.3 SCM-003170 T

AS-SIP Voice EI (R)


8 2.9.8 – PEIs, AEIs, TAs, and IADs Using the V.150.1 Protocol

3-14



Test EI

R/O/C

Whenever these types of IP EIs, TAs, or IADs use ITU-T Recommendation V.150.1, the following shall apply: a. ITU-T Recommendation V.150.1 provides for three states: audio,

voiceband data (VBD), and modem relay. After call setup, inband signaling shall be used to transition from one state to another. In addition, ITU-T Recommendation V.150.1 provides for the transition to FoIP using Fax Relay per ITU-T Recommendation T.38.

b. When the product uses ITU-T Recommendation V.150.1 inband signaling to transition between audio, Fax over IP (FoIP), modem relay, or VBD states or modes, the product shall continue to use the established session’s protocol (e.g., decimal 17 for User Datagram Protocol [UDP]) and port numbers so that the transition is transparent to the SBC.

2.9.8 SCM-003180 T

PEI (R) AEI (R)

Secure AEI (R)

9 2.9.10 – ROUTINE-Only EIs 1 ROUTINE-Only (RO) EIs (ROEIs) shall not be able to originate precedence

(i.e., PRIORITY and above) calls 2.9.10

SCM-003240 T ROEI (R)

2 Sessions involving ROEIs affect ASAC Session Counts in the same way as sessions involving EIs that fully support precedence and preemption.

2.9.10 SCM-003260 T ROEI (R)

3 MLPP/PBAS requirements shall apply to non-ROEIs in sessions involving both RO and non-ROEIs.

2.9.10 SCM-003270 T ROEI (R)

Non-RO EI (R)

4 Preemption Tone shall be provided to ROEIs on preempted sessions involving both ROUTINE-only and non-ROEIs.

2.9.10 SCM-003280 T ROEI (O)

5 An ROEI shall display the precedence level of the session on which it participates.

2.9.10 SCM-003290 T ROEI (O)

10 Section 5 – Internet Protocol version 6 (IPv6)

10-1 The EI in conjunction with the Call Connection Agent (CCA) application must be IPv6-capable. Use guidance in UCR 2013 Errata 1, Table 5.2-3 for EI. These requirements are documented in Table 3-6.

Table 5.2-1 L R

10-2 The additional EI IPv6 requirements from UCR 2013 Errata 1, Section 5 are documented in Table 3-7. Section 5 T R

11 Section 4 – Information Assurance (IA)

11-1 The IA requirements from UCR 2013 Errata 1, Section 4 are documented in Table 3-8. Section 4 T R

3-15


LEGEND: AEI AS-SIP End Instrument AS-SIP Assured Services Session Initiation Protocol ASLAN Assured Services Local Area Network BFCP Binary Floor Control Protocol BRI Basic Rate Interface C Conditional C2 Command and Control CAC Common Access Card CAS Common Access Signaling CR Capability Requirement CW Call Waiting DHCP Dynamic Host Configuration Protocol DN Directory Number DSCP Differentiated Services Code Point DoD Department of Defense DISN Defense Information Systems Network DSN Defense Switched Network EI End Instrument FECC far-end camera control FR Functional Requirement FTR Federal Telecommunications Recommendation IA Information Assurance IAD Integrated Access Device IAW in accordance with ID Identification IEEE Institute of Electrical and Electronics Engineers IP Internet Protocol IPv6 Internet Protocol version 6 ISDN Integrated Services Defense Network ITU-T International Telecommunication Union –

Telecommunication Standardization Sector L Letter of Compliance item LoC Letter of Compliance

LOC2 Loss of Command and Control MG Media Gateway MLPP Multilevel Precedence and Preemption ms millisecond NM Network Management O Optional O&M Operations and Maintenance PBAS Precedence Based Assured Services PCM Pulse Code Modulation PEI Proprietary End Instrument PKI Public Key Infrastructure POTS Plain Old Telephone Service PRI Primary Rate Interface PSTN Public Switched Telephone Network R Required RFC Requests for Comment ROEI ROUTINE only End Instrument SC Session Controller SCIP Secure Communications Interoperability Protocol SDP Session Description Protocol SS Softswitch SUT System Under Test T Testable item TA Terminal Adapter TLS Transport Layer Security TWC three-way calling UC Unified Capabilities UCR Unified Capabilities Requirements VCFC Video Channel Flow Control VoIP Voice over Internet Protocol VTC Video Teleconference VVoIP Voice and Video over Internet Protocol WAN Wide Area Network

3-16

Table 3-6. Mapping of RFCs to UC Profile Categories for Internet Protocol Version 6

ID Requirement UCR Ref (UCR 2013)

EI R/O/C

IP1 RFC RFC TITLE Internet Protocol version 6

IP1-1

1981 Path MTU Discovery for IP Version 6 IP6-000080 R-8 2407 The Internet IP Security Domain of Interpretation for ISAKMP IP6-000830 R-8; C

2408 Internet Security Association and Key Management Protocol (ISAKMP) IP6-000840 R-8; C

2409 The Internet Key Exchange (IKE) IP6-000810 R-8; C

2460 Internet Protocol, Version 6 (IPv6) Specification IP6-000060 IP6-000090 IP6-000110

R-2

2464 Transmission of IPv6 Packets over Ethernet Networks R-3

2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers IP6-001150 R-4

2710 Multicast Listener Discovery (MLD) for IPv6 IP6-000070 R-8

2711 IPv6 Router Alert Option IP6-000670 IP6-000680 R-8

3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) IP6-000180 IP6-000210 R

3484 Default Address Selection for Internet Protocol Version 6 (IPv6) IP6-001130 R-8 3596 DNS Extensions to Support IPv6 IP6-001000 C 3810 Multicast Listener Discovery Version 2 (MLDv2) for IPv6 IP6-000670 R-8 3986 Uniform Resource Identifier (URI): Generic Syntax IP6-000990 R-8; C

4007 IPv6 Scoped Address Architecture IP6-000160 IP6-000170 R

4091 The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework IP6-001050 R

4092 Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP)

IP6-001050 R

4109 Algorithms for Internet Key Exchange Version 1 (IKEv1) IP6-000880 R-8; C

4213 Basic Transition Mechanisms for IPv6 Hosts and Routers IP6-000010 IP6-000040 R-1

4291 IP Version 6 Addressing Architecture IP6-000150 R

4301 Security Architecture for the Internet Protocol

IP6-000690 IP6-000700 IP6-000710 IP6-000720 IP6-000730 IP6-000750 IP6-000760 IP6-000770 IP6-000810 IP6-000830 IP6-000840 IP6-000860 IP6-000880

R-8; C

4302 IP Authentication Header IP6-000850 R-8; C

4303 IP Encapsulating Security Payload (ESP) IP6-000780 IP6-000790 IP6-000800

R-8; C

4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification

IP6-000520 R

4566 SDP: Session Description Protocol IP6-001090 C

4835 Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)

IP6-000870 R-8, C

4861 Neighbor Discovery for IP Version 6 (IPv6) IP6-000280 R

4862 IPv6 Stateless Address Autoconfiguration

IP6-000420 IP6-000450 IP6-000460 IP6-000480

R-8; C

3-17

Table 3-6. Mapping of RFCs to UC Profile Categories for Internet Protocol Version 6


EI R/O/C

4941 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 IP6-000510 C-8

5095 Deprecation of Type 0 Routing Headers in IPv6 IP6-000060 IP6-000090 R

NOTES: 1. C/R-1: Meets only the dual-stack requirements of this RFC. 2. C/R-2: Meets only the IPv6 formatting requirements of this RFC. 3. R-3: Meets only the framing format aspects of RFC. 4. R-4: Requirement covered in Section 6, Network Infrastructure End-to-End Performance. 5. C-5: Condition is that product acts as a router. 6. C-6: Applies only to MGs. 7. C-7: Requirements apply only if the product acts as a CE-R. 8. C/R-8: EI (softphones only). * This column can have (1) softphones only, e.g., R-8, (2) EI, e.g., R-3; or (3) Softphones only and EI, e.g., R-8; C.

Table 3-7. Internet Protocol Version 6 (IPv6) Requirements

CR/FR


LoC/ Test

EI R/O/C

5.2.1 – Product

IP2-1 The product shall support dual IPv4 and IPv6 stacks as described in RFC 4213. 5.2.1 IP6-000010 L EI (R)

IP2-2 Dual-stack end points or Call Connection Agents (CCAs) shall be configured to choose IPv4 over IPv6.

5.2.1 IP6-000020 L EI (R)

IP2-3

All nodes and interfaces that are “IPv6- capable” must be carefully configured and verified that the IPv6 stack is disabled until it is deliberately enabled as part of a deliberate transition strategy. This includes the stateless autoconfiguration of link-local addresses. Nodes with multiple network interfaces may need to be separately configured per interface.

5.2.1 IP6-000030 L EI (R)

IP2-4 The system shall provide the same (or equivalent) functionality in IPv6 as in IPv4 consistent with the requirements in the UCR for its Approved Products List (APL) category.

5.2.1 IP6-000050 L EI (R)

IP2-5 The product shall support the IPv6 format as described in RFC 2460 and updated by RFC 5095.

5.2.1 IP6-000060 L EI (R)

IP2-6 The product shall support the transmission of IPv6 packets over Ethernet networks using the frame format defined in RFC 2464.

5.2.1 IP6-000070 L EI (R)

5.2.1.1 – Maximum Transmission Unit IP2-7 The product shall support Path Maximum Transmission Unit (MTU) Discovery

as described in RFC 1981 5.2.1.1

IP6-000080 L EI (R)

IP2-8 The product shall support a minimum MTU of 1280 bytes as described in RFC 2460 and updated by RFC 5095.

5.2.1.1 IP6-000090 L EI (R)

IP2-9 If Path MTU Discovery is used and a “Packet Too Big” message is received requesting a next-hop MTU that is less than the IPv6 minimum link MTU, then the product shall ignore the request for the smaller MTU and shall include a fragment header in the packet.

5.2.1.1 IP6-000100 L EI (R)

5.2.1.2 – Flow Label IP2-10 The product shall not use the Flow Label field as described in RFC 2460. 5.2.1.2

IP6-000110 L EI (R)

IP2-11 The product shall be capable of setting the Flow Label field to zero when originating a packet.

5.2.1.2 IP6-000120 L EI (R)

IP2-12 The product shall not modify the Flow Label field when forwarding packets. 5.2.1.2 IP6-000130 L EI (R)

IP2-13 The product shall be capable of ignoring the Flow Label field when receiving packets.

5.2.1.2 IP6-000140 L EI (R)

5.2.1.3 – Address IP2-14 The product shall support the IPv6 Addressing Architecture as described in

RFC 4291. 5.2.1.3

IP6-000150 L EI (R)

3-18


CR/FR ID Requirement UCR Ref

(UCR 2013) LoC/ Test

EI R/O/C

IP2-15 The product shall support the IPv6 Scoped Address Architecture as described in RFC 4007.

5.2.1.3 IP6-000160 L EI (R)

IP2-16 If a scoped address (RFC 4007) is used, then the product shall use a scope index value of zero when the default zone is intended

5.2.1.3 IP6-000170 L EI (C)

5.2.1.4 – Dynamic Host Configuration Protocol

IP2-17 If Dynamic Host Configuration Protocol (DHCP) is supported within an IPv6 environment, then it shall be implemented in accordance with the DHCP for IPv6 (DHCPv6) as described in RFC 3315.

5.2.1.4 IP6-000180 L EI (R)

IP2-18 If the product is a DHCPv6 client, then the product shall discard any messages that contain options that are not allowed to appear in the received message type (e.g., an Identity Association option in an Information-Request message).

5.2.1.4 IP6-000200 L EI (C)

IP2-19 The product shall support DHCPv6 as described in RFC 3315 5.2.1.4 IP6-000210 L EI (R)

IP2-20

If the product is a DHCPv6 client and the first retransmission timeout has elapsed since the client sent the Solicit message and the client has received an Advertise message(s), but the Advertise message(s) does not have a preference value of 255, then the client shall continue with a client-initiated message exchange by sending a Request message.

5.2.1.4 IP6-000220 L EI (R)

IP2-21 If the product is a DHCPv6 client and the DHCPv6 solicitation message exchange fails, then it shall restart the reconfiguration process after receiving user input, system restart, attachment to a new link, a system configurable timer, or a user defined external event occurs.

5.2.1.4 IP6-000230 L EI (R)

IP2-22 If the product is a DHCPv6 client and it sends an Information-Request message, then it shall include a Client Identifier option to allow it to be authenticated to the DHCPv6 server.

5.2.1.4 IP6-000240 L EI (R)

IP2-23 If the product is a DHCPv6 client, then it shall perform duplicate address detection upon receipt of an address from the DHCPv6 server before transmitting packets using that address for itself.

5.2.1.4 IP6-000250 L EI (R)

IP2-24 [Alarm] If the product is a DHCPv6 client, then it shall log all reconfigure events.

5.2.1.4 IP6-000260 L EI (R)

IP2-25 [Alarm] If the product supports DHCPv6 and uses authentication, then it shall discard unauthenticated DHCPv6 messages from UC products and log the event.

5.2.1.4 IP6-000270 L EI (C)

5.2.1.5 – Neighbor Discovery IP2-26 The product shall support Neighbor Discovery for IPv6 as described in RFC

4861. 5.2.1.5

IP6-000280 L EI (R)

IP2-27 When a valid “Neighbor Advertisement” message is received by the product and the product neighbor cache does not contain the target’s entry, the advertisement shall be silently discarded.

5.2.1.5 IP6-000310 L EI (R)

IP2-28

When a valid “Neighbor Advertisement” message is received by the product and the product neighbor cache entry is in the INCOMPLETE state when the advertisement is received and the link layer has addresses and no target link-layer option is included, the product shall silently discard the received advertisement.

5.2.1.5 IP6-000320 L EI (R)

IP2-29 When address resolution fails on a neighboring address, the entry shall be deleted from the product’s neighbor cache.

5.2.1.5 IP6-000330 L EI (R)

IP2-30 The product shall support the ability to configure the product to ignore Redirect messages.

5.2.1.5.1 IP6-000340 L EI (R)

IP2-31 The product shall only accept Redirect messages from the same router as is currently being used for that destination.

5.2.1.5.1 IP6-000350 L EI (R)

IP2-32 If “Redirect” messages are allowed, then the product shall update its destination cache in accordance with the validated Redirect message.

5.2.1.5.1 IP6-000360 L EI (C)

IP2-33 If the valid “Redirect” message is allowed and no entry exists in the destination cache, then the product shall create an entry.

5.2.1.5.1 IP6-000370 L EI (C)

IP2-34 If redirects are supported, then the device shall support the ability to disable this functionality.

5.2.1.5.1 IP6-000380 L EI (C)

IP2-35 The product shall prefer routers that are reachable over routers whose reachability is suspect or unknown.

5.2.1.5.2 IP6-000400 L EI (R)

5.2.1.6 – Stateless Address Autoconfiguration and Manual Address Assignment

3-19




EI R/O/C

IP2-36 If the product supports stateless IP address autoconfiguration including those provided for the commercial market, then the product shall support IPv6 Stateless Address Autoconfiguration (SLAAC) for interfaces supporting UC functions in accordance with RFC 4862.

5.2.1.6 IP6-000420 L EI (C)

IP2-37

If the product supports IPv6 SLAAC, then the product shall have a configurable parameter that allows the function to be enabled and disabled. Specifically, the product shall have a configurable parameter that allows the “managed address configuration” flag and the “other stateful configuration” flag to always be set and not perform stateless autoconfiguration.

5.2.1.6 IP6-000430 L EI (C)

IP2-38 If the product supports IPv6 SLAAC, then the product shall have the configurable parameter set not to perform stateless autoconfiguration.

5.2.1.6 IP6-000440 L

EI (C) (Except

Softphone)

IP2-39

While nodes are not required to autoconfigure their addresses using SLAAC, all IPv6 Nodes shall support link-local address configuration and Duplicate Address Detection (DAD) as specified in RFC 4862. In accordance with RFC 4862, DAD shall be implemented and shall be on by default. Exceptions to the use of DAD are noted in the following text.

5.2.1.6 IP6-000450 L EI (R)

IP2-40 A node MUST allow for autoconfigurationrelated variable to be configured by system management for each multicast-capable interface to include DupAddrDetectTransmits where a value of zero indicates that DAD is not performed on tentative addresses as specified in RFC 4862.

5.2.1.6 IP6-000460 L EI (R)

IP2-41 The product shall support manual assignment of IPv6 addresses. 5.2.1.6 IP6-000470 L EI (R)

IP2-42 The product shall support stateful autoconfiguration (i.e., ManagedFlag=TRUE) as described in RFC 4862.

5.2.1.6 IP6-000480 L

EI (R) (Softphone

only)

IP2-43 If the product provides routing functions, then the product shall default to using the “managed address configuration” flag and the “other stateful flag” set to TRUE in their router advertisements when stateful autoconfiguration is implemented.

5.2.1.6 IP6-000490 L EI (R)

IP2-44 If the product supports a subtended appliance behind it, then the product shall ensure that the IP address assignment process of the subtended appliance is transparent to the UC components of the product and does not cause the product to attempt to change its IP address.

5.2.1.6 IP6-000500 L EI (C)

IP2-45

If the product supports SLAAC and security constraints prohibit the use of hardware identifiers as part of interface addresses generated using SLAAC, then Internet Protocol Security (IPSec)-capable products shall support privacy extensions for stateless address autoconfiguration as defined in RFC 4941.

5.2.1.6 IP6-000510 L

EI (C) (Softphone

Only)

5.2.1.7 – Internet Control Message Protocol IP2-46 The product shall support the Internet Control Message Protocol (ICMP) for

IPv6 as described in RFC 4443. 5.2.1.7

IP6-000520 L EI (R)

IP2-47 The product shall support the enabling or disabling of the ability to send an Echo Reply message in response to an Echo Request message sent to an IPv6 multicast or anycast address.

5.2.1.7 IP6-000550 L EI (R)

IP2-48 The product shall validate ICMPv6 messages, using the information contained in the payload, before acting on them.

5.2.1.7 IP6-000560 L EI (R)

5.2.1.8 – Routing Functions

IP2-49

If the product supports routing functions, then the product shall support the Multicast Listener Discovery (MLD) process as described in RFC 2710 and extended in RFC 3810. a. If the product supports MLD process as described in RFC 2710 and

extended in RFC 3810, then the product shall support RFC 2711.

5.2.1.8 IP6-000670 L

EI (R) (Softphone

Only) EI (C)

IP2-50 The product shall support MLD as described in RFC 2710. 5.2.1.8 IP6-000680 L EI (R)

5.2.1.9 – IP Security

3-20




EI R/O/C

IP2-51

If the product uses IPSec, then the product shall be compatible with the Security Architecture for the IPSec described in RFC 4301. a. If RFC 4301 is supported, then the product shall support binding of a SA

with a particular context. b. If RFC 4301 is supported, then the product shall be capable of disabling the

BYPASS IPSec processing choice.

5.2.1.9 IP6-000690 L

EI (R) (Softphone

Only) EI (C)

IP2-52 If RFC 4301 is supported, then the product shall not support the mixing of IPv4 and IPv6 in a SA.

5.2.1.9 IP6-000700 L

EI (R) (Softphone

Only) EI (C)

IP2-53 If RFC 4301 is supported, then the product’s security association database (SAD) cache shall have a method to uniquely identify a SAD entry.

5.2.1.9 IP6-000710 L

EI (R) (Softphone

Only) EI (C)

IP2-54 If RFC 4301 is supported, then the product shall implement IPSec to operate with both integrity and confidentiality.

5.2.1.9 IP6-000720 L

EI (R) (Softphone

Only) EI (C)

IP2-55 If RFC 4301 is supported, then the product shall be capable of enabling and disabling the ability of the product to send an ICMP message informing the sender that an outbound packet was discarded.

5.2.1.9 IP6-000730 L

EI (R) (Softphone

Only) EI (C)

IP2-56 If an ICMP outbound packet message is allowed, then the product shall be capable of rate limiting the transmission of ICMP responses.

5.2.1.9 IP6-000740 L

EI (R) (Softphone

Only) EI (C)

IP2-57 If RFC 4301 is supported, then the system’s Security Policy Database (SPD) shall have a nominal, final entry that discards anything unmatched.

5.2.1.9 IP6-000750 L

EI (R) (Softphone

Only) EI (C)

IP2-58

[Alarm] If RFC 4301 is supported, and the product receives a packet that does not match any SPD cache entries, and the product determines it should be discarded, then the product shall log the event and include the date/time, Security Parameter Index (SPI) if available, IPSec protocol if available, source and destination of the packet, and any other selector values of the packet.

5.2.1.9 IP6-000760 L

EI (R) (Softphone

Only) EI (C)

IP2-59 [Alarm] If RFC 4301 is supported, then the product should include a management control to allow an administrator to enable or disable the ability of the product to send an IKE notification of an INVALID_SELECTORS.

5.2.1.9 IP6-000770 L

EI (R) (Softphone

Only) EI (C)

IP2-60 If RFC 4301 is supported, then the product shall support the ESP Protocol in accordance with RFC 4303.

5.2.1.9 IP6-000780 L

EI (R) (Softphone

Only) EI (C)

IP2-61 If RFC 4303 is supported, then the product shall be capable of enabling anti-replay.

5.2.1.9 IP6-000790 L

EI (R) (Softphone

Only) EI (C)

IP2-62 If RFC 4303 is supported, then the product shall check, as its first check, after a packet has been matched to its SA whether the packet contains a sequence number that does not duplicate the sequence number of any other packet received during the life of the security association.

5.2.1.9 IP6-000800 L

EI (R) (Softphone

Only) EI (C)

IP2-63 If RFC 4301 is supported, then the product shall support IKEv1 as defined in RFC 2409.

5.2.1.9 IP6-000810 L

EI (R) (Softphone

Only) EI (C)

IP2-64

To prevent a Denial of Services (DoS) attack on the initiator of an IKE_SA, the initiator shall accept multiple responses to its first message, treat each as potentially legitimate, respond to it, and then discard all the invalid half-open connections when it receives a valid cryptographically protected response to any one of its requests. Once a cryptographically valid response is received, all subsequent responses shall be ignored whether or not they are cryptographically valid.

5.2.1.9 IP6-000820 L EI (C)

3-21




EI R/O/C

IP2-65 If RFC 4301 is supported, then the product shall support extensions to the Internet IP Security Domain of Interpretation for the Internet Security Association and Key Management Protocol (ISAKMP) as defined in RFC 2407.

5.2.1.9 IP6-000830 L

EI (R) (Softphone

Only) EI (C)

IP2-66 If RFC 4301 is supported, then the product shall support the ISAKMP as defined in RFC 2408.

5.2.1.9 IP6-000840 L

EI (R) (Softphone

Only) EI (C)

IP2-67 If the product supports the IPSec Authentication Header Mode, then the product shall support the IP Authentication Header (AH) as defined in RFC 4302.

5.2.1.9 IP6-000850 L

EI (R) (Softphone

Only) EI (C)

IP2-68 If RFC 4301 is supported, then the product shall support manual keying of IPSec.

5.2.1.9 IP6-000860 L

EI (R) (Softphone

Only) EI (C)

IP2-69 If RFC 4301 is supported, then the product shall support the ESP and AH cryptographic algorithm implementation requirements as defined RFC 4835.

5.2.1.9 IP6-000870 L

EI (R) (Softphone

Only) EI (C)

IP2-70 If RFC 4301 is supported, then the product shall support the IKEv1 security algorithms as defined in RFC 4109.

5.2.1.9 IP6-000880 L

EI (R) (Softphone

Only) EI (C)

5.2.1.10 – Network Management

IP2-71 If the product uses Uniform Resource Identifiers (URIs) in combination with IPv6, then the product shall use the URI syntax described in RFC 3986.

5.2.1.10 IP6-000980 L

EI (R) (Softphone

Only) EI (C)

IP2-72 If the product uses the Domain Name Service (DNS) resolver for IPv6 based queries, then the product shall conform to RFC 3596 for DNS queries.

5.2.1.10 IP6-001000 L EI (C)

5.2.1.12 – IP Version Negotiation

IP2-73

When the product is establishing media streams from dual-stacked appliances for AS-SIP signaled sessions, the product shall use the Alternative Network Address Type (ANAT) semantics for the Session Description Protocol (SDP) in accordance with RFC 4091. Also, the following conditional requirements would apply. a. The product shall prefer any IPv4 address to any bIPv6 address when using

ANAT semantics. b. The product shall place the option tag “SDPANAT” bin a Required header

field when using ANAT semantics in accordance with bRFC 4092. c. The products shall include the IPv4 and IPv6 addresses within the SDP of

the SIP INVITE message when the INVITE contains the SDP.

5.2.1.12 IP6-001050 L EI (R)

5.2.1.13 – Services Session Initiation Protocol IPv6 Unique Requirements

IP2-74

If the product is using AS-SIP, and the <addrtype> is IPv6, and the <connection-address> is a unicast address, then the product shall support generation and processing of unicast IPv6 addresses having the following formats: • x:x:x:x:x:x:x:x (where x is the hexadecimal values of the eight 16-bit pieces

of the address). Example: 1080:0:0:0:8:800:200C:417A. • x:x:x:x:x:x:d.d.d.d (where x is the hexadecimal values of the six high-order

16-bit pieces of the address, and d is the decimal values of the four low-order 8-bit pieces of the address (standard IPv4 representation). For example, 1080:0:0:0:8:800:116.23.135.22.

5.2.1.13 IP6-001060 L EI (C)

IP2-75

If the product is using AS-SIP, then the product shall support the generation and processing of IPv6 unicast addresses using compressed zeros consistent with one of the following formats: • x:x:x:x:x:x:x:x format: 1080:0:0:0:8:800:200C:417A. • x:x:x:x:x:x:d.d.d.d format: 1080:0:0:0:8:800:116.23.135.22. • compressed zeros: 1080::8:800:200C:417A.

5.2.1.13 IP6-001070 L EI (C)

3-22




EI R/O/C

IP2-76

If the product is using AS-SIP, and the <addrtype> is IPv6, and the <connection-address> is a multicast group address (i.e., the two most significant hexadecimal digits are FF), then the product shall support the generation and processing of multicast IPv6 addresses having the same formats as the unicast IPv6 addresses.

5.2.1.13 IP6-001080 L EI (C)

IP2-77 If the product is using AS-SIP, and the <addrtype> is IPv6, then the product shall support the use of RFC 4566 for IPv6 in SDP as described in AS-SIP 2013, Section 4, SIP Requirements for AS-SIP Signaling Appliances and AS-SIP EIs.

5.2.1.13 IP6-001090 L EI (C)

IP2-78 If the product is using AS-SIP, and the <addrtype> is IPv6, and the <connection-address> is an IPv6 multicast group address, then the multicast connection address shall not have a Time To Live (TTL) value appended to the address as IPv6 multicast does not use TTL scoping.

5.2.1.13 IP6-001100 L EI (C)

IP2-79 If the product is using AS-SIP, then the product shall support the processing of IPv6 multicast group addresses having the <number of address> field and may support generating the <number of address> field. This field has the identical format and operation as the IPv4 multicast group addresses.

5.2.1.13 IP6-001110 L EI (C)

IP2-80 The product shall support default address selection for IPv6 as defined in RFC 3484 (except for Section 2.1).

5.2.1.13 IP6-001130 L

EI (R) (Softphone

Only) 5.2.1.14 – Miscellaneous

IP2-81 The products shall support Differentiated Services as described in RFC 2474 for a voice and video stream in accordance with Section 2, Session Control Products, and Section 6, Network Infrastructure End-to-End Performance, plain text DSCP plan.

5.2.1.13 IP6-001150 L EI (R)

3-23

Table 3-8. End Instrument Information Assurance (IA) Requirements


(UCR 2013) LoC/ Test R/O/C

4 4 – Information Assurance 4-1 4.2.3 – User Roles

1 The product shall be capable of supporting at least three types of user roles: a system administrator, a privileged application user, and an application user.

4.2.3 IA-002000 L EI (R)

2 The product shall be capable of setting the default user precedence VVoIP session origination capability as ROUTINE.

4.2.3 IA-003000 L EI (R)

4-2 4.2.4 – Ancillary Equipment

1

Products that use external AAA services provided by the Diameter Base Protocol shall do so IAW RFC 3588. IA-009010 Systems that act as Diameter agents shall be capable of being configured as proxy agents. IA-009020 Systems that act as proxy agents shall maintain session state. IA-009030 All Diameter implementations shall ignore answers received that do not match a known Hop-by-Hop Identifier field. IA-009040 All Diameter implementations shall provide transport of its messages IAW the transport profile described in RFC 3539. IA-009050 Products that use the EAP within Diameter shall do so IAW RFC 4072.

4.2.4 IA-009000 L EI (C)

AEI (C)

2

Products shall support the capability to use the RADIUS IAW RFC 2865 to provide AAA services. NOTE: For products to which the Conditional statement applies, the condition is implementation of RADIUS. IA-010010 Products that use the EAP within RADIUS shall do so IAW RFC 3579. IA-010020 If the products support RADIUS based accounting, then the system shall do so IAW RFC 2866.

4.2.4 IA-010000 L EI (C)

AEI (C)

3 Products that use external AAA services provided by the Terminal Access Controller Access Control System (TACACS+) shall do so IAW the TACACS+ Protocol Specification 1.78 (or later).

4.2.4 IA-011000 L EI (C)

AEI (C)

4

EIs that use external address assignment services provided by the Dynamic Host Configuration Protocol (DHCP) shall do so IAW RFC 2131. NOTE: An external address assignment service is a service that extends beyond the boundary of the system. IA-012010 Products that act as DHCP clients upon receipt of a new IP address shall probe [e.g., with Address Resolution Protocol (ARP)] the network with the newly received address to ensure the address is not already in use. IA-012020 Products that act as DHCP clients upon receipt of a new IP address shall broadcast an ARP reply to announce the client’s new IP address and clear outdated ARP cache entries in hosts on the client’s subnet.

4.2.4 IA-012000 L EI (C)

AEI (C)

5

Products that use external AAA services provided by port based network access control mechanisms shall do so IAW IEEE 802.1X-2010 in combination with Protected Extensible Authentication Protocol (PEAP) and EAP-TLS support, at a minimum, plus any other desired secure EAP types [e.g., EAP-Tunneled TLS (TTLS)]. IA-013010 Products that use external EAP services provided by EAP shall do so IAW RFC 3748 and its RFC extensions.

4.2.4 IA-013000 L EI (C)

AEI (C)

3-24

Table 3-8. EI Information Assurance (IA) Requirements (continued)



4-3 4.2.5 – VVoIP Authentication 1 The product shall be capable of authenticating the SC using TLS (or its equivalent)

(Threshold) with PKI certificates issued from a DoD-approved PKI. 4.2.5

IA-019000 L EI (R)

The product shall be capable of authenticating the SC using TLS with PKI certificates issued from a DoD-approved PKI

4.2.5 IA-020000 AEI (R)

2 The product shall be capable of allowing users to place ROUTINE precedence calls without authenticating.

4.2.5 IA-021000 L EI (R)

3 The product shall be capable of allowing users to place emergency calls without authenticating.

4.2.5 IA-022000 L EI (R)

4

If the product supports authentication for precedence calls, then the product shall support a configuration setting which allows only authenticated users to access the product for services above the ROUTINE precedence level. IA-023010 [conditional] If the product uses SIP or AS-SIP, then the system shall, at a minimum, support the use of SIP digest authentication as specified in RFC 3261 when authenticating users. The product may support the ability to authenticate users via PKI certificates when authenticating user credentials to the SC via the EI using proprietary mechanisms. IA-023020 [Conditional] If the product implements AS-SIP and supports authentication for precedence calls, then the product shall use the procedures and algorithms specified in RFC 3261, Section 22.4, to execute SIP digest authentication for user authentication with a PIN. The User-ID entered by the user shall be used for the value of the “username” field, and the PIN entered by the user shall be used as the value for “secret” in the digest calculation. IA-023030 [Conditional] If the product supports authentication for precedence calls via a PIN, then the device shall support the capability to provide audible and/or visible notification to the user, which, in a human understandable manner, prompts the user to enter his or her assigned User-ID and PIN when a precedence level above ROUTINE is requested. IA-023040 [Required] The user authentication mechanism shall be software enabled or disabled. IA-023050 [Conditional] If the product is a softphone, then the product shall support the capability to provide user authentication by presenting the user credentials extracted from the Common Access Card (CAC) or other DoD PKI Project Management Office (PMO)-approved PKI token to the SC.

4.2.5 IA-023000 L EI (R)

5 The product shall adhere to the requirements in RFC 5922, Section 7.2, “Comparing SIP Identities,” when comparing the domains extracted from X.509v3 certificates with AS-SIP identities contained in signaling messages.

4.2.5 IA-024000 L AEI (R)

4-4 4.2.6 – VVoIP Authorization

6

If DHCP is used, then the product shall be capable of using 802.1X in combination with a secure EAP type (defined within this UCR and the STIGs/SRGs) residing on the authentication server and within the operating system or application software of the EI and AEI to authenticate to the LAN.

4.2.6 IA-037000 L EI (C)

AEI (C)

4-5 4.2.7 – Public Key Infrastructure 1 The product shall be capable of generating asymmetric keys whose length is at least

2048 for Rivest Shamir Adleman (RSA). 4.2.7

IA-040000 L EI (C) AEI (R)

2 The product shall be capable of generating symmetric keys whose length is at least 128 bits.

4.2.7 IA-041000 L EI (R)

AEI (R)

3 The product shall be capable of storing key pairs and their related certificates. 4.2.7 IA-042000 L EI (C)

AEI (R)

4

The product shall operate with DoD-approved trust anchors (e.g., public keys and the associated certificates the relying party deems as reliable and trustworthy, typically root certification authorities [CAs]). IA-043010 [Required: AEI; Conditional: EI] Any system that performs PKI certificate validation operations must implement the basic steps outlined in Section 6.1.3 of the internet X.509 certificate specification Request for Comment (RFC) 5280. IA-043020 [Conditional: AEI, EI] The system must also provide the capability to check certificate revocation status as part of the certificate validation process as defined in RFC 5280.

4.2.7 IA-043000 L EI (C)

AEI (R)

5 The product shall be capable of supporting end entity server and device certificates and populating all certificate fields IAW methods described in the “DoD PKI Functional Interface Specification.”

4.2.7 IA-044000 L EI (C)

AEI (R)

3-25




6

The product shall be capable of using the Lightweight Directory Access Protocol (LDAP) version 3 (LDAPv3), LDAP over TLS (LDAPS), Hypertext Transfer Protocol (HTTP), or HTTP Secure (HTTPS) as appropriate when communicating with DoD-approved PKIs.

4.2.7 IA-045000 L EI (C)

AEI (R)

7 If CRLs are used, then the product shall be capable of using either the date and time specified in the next update field in the CRL or using a configurable parameter to define the period associated with updating the CRLs.

4.2.7 IA-046000 L EI (C)

AEI (C)

8

If CRLs are used, then the product shall be capable of obtaining the CRL from the CRL Distribution Point (CDP) extension of the certificate in question. The product shall be able to process HTTP pointers in the CDP field whereas the ability to process HTTPS and LDAP pointers is considered Objective and is not a hard requirement.

4.2.7 IA-047000 L EI (C)

AEI (C)

9

If OCSP is used, then the product shall support the capability to use both the Delegated Trust Model (DTM), whereby the OCSP responder's signing certificates are signed by DoD approved PKI CAs, and the OCSP Trusted Responder model, where the OCSP responder uses a self-signed certificate to sign OCSP responses, IAW DoD PKI PMO guidance.

4.2.7 IA-048000 L EI (C)

AEI (C)

10

If OCSP is used, then the OCSP responder shall be contacted based on the following information: IA-049010 The OCSP responder preconfigured in the application or toolkit; and IA-049020 The OCSP responder location identified in the OCSP field of the Authority Information Access (AIA) extension of the certificate in question. IA-049030 If both of the above are available, then the product shall be configurable to provide preference for one over the other. IA-049040 The product should (not shall) be configurable to provide preferences or a preconfigured OCSP responder based on the Issuer DN.

4.2.7 IA-049000 L EI (C)

AEI (C)

11 If the EI is PKI enabled, then the EI shall support a mechanism for verifying the status of an SC certificate using a CTL, CRLs, or an online status check (OCSP in the case of the DoD PKI).

4.2.7 IA-050000 L EI (C)

12 The product shall support all of the applicable requirements in the latest DoD Public Key Enabled (PKE) Application Requirements specification published by the DoD PKI PMO.

4.2.7 IA-052000 L EI (C)

AEI (R)

13

Systems that perform any PKI operations (e.g., certificate path processing, certificate validation, digital signature generation, and encryption) must support RSA keys up to 2048 bits with Secure Hash Algorithm (SHA)-1 and SHA-2 digital signatures as dictated by the National Institute of Standards and Technology (NIST) Special Publications (SP) 800-57, SP 800-78, and SP 800- 131A and the DoD Certificate Policy. IA-053010 The product shall support the capability to verify certificates, CRLs, OCSP responses, or any other signed data produced by a DoD approved PKI using RSA in conjunction with the SHA-256 algorithm.

4.2.7 IA-053000 L EI (C)

AEI (R)

14

The product shall be capable of supporting the development of a certificate path and be able to process the path. IA-055010 The path process shall fail when a problem that prohibits the validation of a path occurs.

4.2.7 IA-055000 L EI (C)

AEI (R)

15

The product shall be capable of ensuring that the intended use of the certificate is consistent with the DoD-approved PKI extensions. IA-056010 The product shall be capable of ensuring that the key usage extension in the end entity certificate is set properly. IA-056020 The product shall be capable of ensuring that the digital signature bit is set for authentication uses. IA-056030 The product shall be capable of ensuring that the non-repudiation bit is set for nonrepudiation uses.

4.2.7 IA-056000 L EI (C)

AEI (R)

16

[Alarm] During VVoIP session establishment, if the product uses an online status check to validate a certificate and the product cannot contact the online status check responder (OSCR) (in the case of the DoD PKI, this will be an RFC 2560 OCSP responder) and backup OSCRs, the product will establish the VVoIP session (e.g., shall not terminate the session), but will log the event and send an alarm to the NMS.

4.2.7 IA-057000 L EI (R)

AEI (R)

17

[Alarm] During VVoIP session establishment, if the product uses CRLs to validate a certificate and the product cannot reach the CDP or any backup CDPs, the product will continue the process (e.g. shall not terminate the session), but will log the event and send an alarm to the NMS.

4.2.7 IA-058000 L EI (R)

AEI (R)

3-26




18

Periodically, the system shall examine all of the certificates and trust chains associated with ongoing, long-lived, sessions. The system shall terminate any ongoing sessions based on updated revocation/trust information if it is determined that the corresponding certificates have been revoked, are no longer trusted, or are expired. IA-059010 If the system supports manual loading of a CRL or CTLs configured by an administrator, then the system shall check all ongoing sessions as soon as updates to the internally stored CRL or trust lists occur. IA-059020 If the system supports automated retrieval of a CRL from a CDP, then the system shall immediately check the certificates and trust chains associated with all ongoing sessions against the newly retrieved CRL. IA-059030 If the system supports automated retrieval of a CRL from a CDP, then the system shall support the ability to configure the interval in which the CRL is retrieved periodically. IA-059040 If the system supports queries against an online status check responder (an OCSP responder in the case of the DoD PKI), then the system shall periodically query the responder to determine if the certificates corresponding to any ongoing sessions have been revoked. IA-059050 If the system supports queries against an online status check responder (an OCSP responder in the case of the DoD PKI), by default, for each session, then the device shall query the online status check responder every 24 hours for as long as the session remains active. IA-059060 If the system supports queries against an online status check responder (an OCSP responder in the case of the DoD PKI), then the system shall support the ability to configure the interval at which the system periodically queries the online status check responder.

4.2.7 IA-059000 L EI (C)

AEI (R)

19

[Alarm] The system shall be capable of sending an alert when installed certificates corresponding to trust chains, OCSP responder certificates, or any other certificates installed on the device that cannot be renewed in an automated manner, are nearing expiration. IA-060010 [Alarm] By default, the system shall be capable of sending this alert 60 days before the expiration of the installed credentials, which cannot be renewed automatically. This alert should be repeated periodically on a weekly or biweekly basis by default.

4.2.7 IA-060000 L EI (C)

AEI (R)

20

The product shall support the capability to verify that the identity claimed in an X.509v3 certificate Subject Common Name, used to establish an authenticated and secure channel, correctly maps to the identity claimed in signaling messages transmitted within the same secure channel. IA-061010 [Required: AEI; Conditional: EI] The product shall support the capability to examine the identity claimed by the X.509v3 Subject Common Name field and compare it to the identity claimed within signaling messages regardless of whether the claimed identity contains an FQDN, IPv4 address, or IPv6 address. IA-061020 [Required: AEI, EI] The product shall support the capability to statically map the FQDNs contained in X.509v3 certificate Subject Common Names to IP addresses via a configurable lookup table.

4.2.7 IA-061000 L EI (C)

AEI (R)

4-6 4.2.8 – Integrity

1

The product shall be capable of using TLS for providing integrity of AS-SIP messages. IA-062010 The product shall be capable of using HMAC-SHA1-160 with 160 bit keys.

4.2.8 IA-062000 L EI (C)

AEI (R)

2 If the product uses H.323, then the product shall be capable of using H.235.1 Baseline Security Profile guidance for mutually authenticated shared keys and HMAC-SHA1-96 with 160 bit keys.

4.2.8 IA-063000 L EI (C)

AEI (C)

3

The product shall be capable of providing data integrity of the SRTP bearer (transport) packets. IA-064010 The product shall be capable of using HMACSHA1-32 for the authentication tag with 160 bit key length as the default integrity mechanism for SRTP packets. IA-064020 The product shall be capable of using HMACSHA1-80 for the authentication tag with 160 bit key length as the default integrity mechanism for Secure Real-Time Transport Control Protocol (SRTCP).

4.2.8 IA-064000 EI (R)

AEI (R)

4-7 4.2.9 – Confidentiality

3-27




1

The product shall be capable of providing confidentiality for media streams using SRTP with either the AES_CM_128 encryption algorithm as the default. IA-069010 [Required: SS, SC, MG, EI, AEI] The product shall be capable of distributing the Master Key and the Salt Key in the VVoIP signaling messages IAW RFC 4568. IA-069020 [Required: SS, SC, MG, EI, AEI] The product shall be capable of distributing the Master Key and the Salt Key in concatenated form. IA-069030 [Required: EI, AEI, MG] The product shall use a Master Key of 128 bits to support 128-bit Advanced Encryption Standard (AES) encryption. IA-069040 [Required: EI, AEI, MG] The Master Key and a random Master Salt Key shall be supported for SRTP sessions. IA-069050 [Required: SS, SC, SBC, MG, AEI, EI] When the system assigns the port numbers to a session, the system shall assign the SRTP port ranges within a configurable range between 2048 and 65535 with the default between: 16384 to 32764.

4.2.9 IA-069000 L EI (R)

AEI (R)

2

If H.323, Media Gateway Control Protocol (MGCP), or H.248 (MEGACO) is used, then the product shall be capable of using IPSec to provide confidentiality. IA-070020 If H.323 is used, then the product shall bbe capable of distributing the SRTP Master Key and Salt Key in H.235 using the H235Key as described in H.235.0 and H.235.8.

4.2.9 IA-070000 L EI (C)

AEI (C)

3

If IPSec is used, then the product shall be capable of using IKE for IPSec key distribution: IA-071010 [Required: AEI, EI] The product shall be capable of using IKE version 1. IA-071030 If IPSec is used, then the product shall be capable of using the Quick Mode as the default Phase II Security Association mechanism for the IPSec service. IA-071040 If IPSec is used, then the product shall be capable of using and interpreting certificate requests for Public-Key Cryptography Standard #7 (PKCS#7) wrapped certificates as a request for the whole path of certificates. IA-071050 If IPSec is used, then the product shall be capable of using Main Mode associated with the Diffie-Hellman approach for key generation for the security association negotiation. IA-071060 If IPSec is used, then the product shall be capable of using Diffe-Hellman Groups 1, 2, and 14, at a minimum.

4.2.9 IA-071000 L EI (C)

AEI (C)

9

The product shall be capable of using TLS (dual path method) to provide confidentiality for the AS-SIP as described in RFC 3261. IA-072010 [Required: AEI; Conditional: EI] The underlying protocol for AS-SIP shall be the TCP. IA-072020 [Required: AEI; Conditional: EI] The product shall be capable of using as its default cipher suite TLS_RSA_WITH_AES_128_CBC_SHA. IA-072030 [Required: AEI; Conditional: EI] The product shall be capable of using a default of no compression for AS-SIP messages. IA-072040 [Required: AEI; Conditional: EI] The product shall be capable of exchanging AS-SIP TLS messages in a single exchange or multiple exchanges. IA-072050 [Required: AEI; Conditional: EI] The product shall be capable of distributing the SRTP Master Key and Salt Key in the AS-SIP message using the SDP crypto= field. IA-072060 [Conditional: EI, AEI] If AS-SIP is used, then the product shall transmit only packets that are secured with TLS and use port 5061. IA-072070 [Required: EI, AEI] The product shall reject all received AS-SIP packets associated with port 5061 that are not secured with TLS. IA-072080 [Required: EI, AEI] The product shall only accept and process AS-SIP packets that arrive on port 5061.

4.2.9 IA-072000 L AEI (R)

3-28




10

If the product uses TLS, then the product shall do so in a secure manner as defined by the following subtended requirements: IA-073010 If the product uses TLS, then the system shall be capable of using TLS_RSA_WITH_AES_128_CBC_SHA as its default cipher suite. IA-073020 If the product uses TLS, then the system shall be capable of using a default of no compression. IA-073030 If the product uses TLS, then the system shall be capable of exchanging TLS messages in a single exchange or multiple exchanges. IA-073040 If TLS session resumption is used, then a timer associated with TLS session resumption shall be configurable and the default shall be 1 hour. NOTE: This requirement is not associated with NM-related sessions. IA-073050 If TLS session resumption is used, then the maximum time allowed for a TLS session to resume (session resumption) without repeating the TLS authentication/confidentiality/authorization process (e.g., a full handshake) is 1 hour. IA-073060 [Required: AEI, EI] If the product supports SSL/TLS renegotiation, then the product shall support the capability to disable this feature or the product shall support RFC 5746.

4.2.9 IA-073000 L EI (C)

AEI (C)

11

If the product uses Secure Shell (SSH), then the system shall do so in a secure manner as defined by the following subtended requirements: IA-074010 If the product uses SSH, then the system shall be capable of supporting the RSA 2,048-bit key algorithm and the Diffie-Hellman 2,048 bit key algorithm. IA-074020 If the product uses SSH, then a client shall close the session if it receives a request to initiate an SSH session whose version is less than 2.0. NOTE: Closing the session may be either a default behavior or a configurable option. If this is a configurable option, then the conditions of fielding should clearly specify that this option must be configured. IA-074030 If the product uses SSH, then the SSH sessions shall rekey at a minimum every gigabyte of data received or every 60 minutes, whichever comes sooner. IA-074040 If the product uses SSH, then the SSH sessions shall rekey at a minimum every gigabyte of data transmitted or every 60 minutes, whichever comes sooner. IA-074050 If the product uses SSH, then the SSH sessions shall minimally support the AES 128-CBC algorithm as defined in RFC 4253. IA-074070 If the product uses SSH, then the SSH sessions shall use TCP as the underlying protocol. IA-074100 If the product uses SSH, then the product shall discard SSH packets that exceed the maximum packet size to avoid denial of service (DoS) attacks or buffer overflow attacks. IA-074110 If the product uses SSH, then the SSH packets shall use random bytes if packet padding is required. IA-074120 If the product uses SSH, then the system shall treat all SSH-encrypted packets sent in one direction as a single data stream. For example, the initialization vectors shall be passed from the end of one packet to the beginning of the next packet. IA-074130 If the product uses SSH, then the system shall be capable of setting Diffie-Hellman-Group14-SHA1 as the preferred key exchange mechanism for SSH.

4.2.9 IA-074000 L EI (C)

AEI (C)

12 If the product uses web browsers or web servers, then the product web browsers and web servers shall be capable of supporting TLS 1.0 or higher for confidentiality.

4.2.9 IA-078000 L EI (C)

AEI (C)

13

If the product is the originating party and receives a 181 message indicating that the call is being forwarded, then, upon completion of the session establishment between the originating party and the forwarded-to party, the originating party must initiate a rekeying.

4.2.9 IA-081000 L EI (C)

AEI (C)

14 If the EI or AEI acts as a bridge or a MCU, then it shall establish a unique key for each EI or AEI connection.

4.2.9 IA-082000 L EI (C)

AEI (C)

3-29




LEGEND: AAA Authentication, Authorization, and Accounting AEI AS-SIP End Instrument ARP Address Resolution Protocol AS-SIP Assured Services Session Initiation Protocol C Conditional CR Capability Requirement CRL Certificate Revocation List CTL Certificate Trust List DHCP Dynamic Host Configuration Protocol DoD Department of Defense EAP Extensible Authentication Protocol EI End Instrument FQDN Fully Qualified Domain Name FR Functional Requirement HMAC Hash-Based Message Authentication Code IAW in accordance with ID Identification IEEE Institute of Electrical and Electronics Engineers

IP Internet Protocol IPv4 Internet Protocol version 4 IPv6 Internet Protocol version 6 LoC Letter of Compliance O Optional OCSP Online Certificate Status Protocol PIN Personal Identification Number PKI Public Key Infrastructure R Required RADIUS Remote Authentication Dial In User Service RFC Request for Comment SRTP Secure Real-Time Transport Protocol SSH Secure Shell TACACS+ Terminal Access Controller Access Control System

plus TLS Transport Layer Security UCR Unified Capabilities Requirements VVoIP Voice and Video over Internet Protocol

defense information systems agency -...

Documents