Standard Information Communications Technology January2013 Version 1.4 Corporate and Information Services
Document details Document Title Contact details File name Version 1.4 Document Control Information Communication Technology (ICT) Policy and Strategy Division, Corporate and Information Services (DCIS) Northern Territory Government (NTG). Date issued January 2013 Approved by NTG CIO Forum: 27 October 2011 Change History Version Date Author Change details 1.0 July 2010 K. Kannoorpatti New Standard Document 1.1 October 2011 K. McCarthy Change format 1.2 October 2011 K. McCarthy Endorsed by NTG CIO Forum 1.3 February 2012 K. McCarthy Internet Version 1.4 January 2013 K. McCarthy Change government names Corporate and Information Services
Table of Contents 1 Executive Summary...4 1.1 Aim of standards...4 1.2 Applicability...4 1.3 Scope...4 1.4 Other applicable documents...4 1.5 Acronyms used in this document...5 2 Devices...6 2.1 General requirements (Conference room based)...6 2.1.1 Video Network (conference room based, HD telepresence, telemedicine)...6 2.1.2 MCU registration...6 2.1.3 IAM (EPass2) details...7 2.1.4 Redundancy...7 2.2 Management software...7 2.2.1 EPass2 or IAM (Identity and Access Management)...7 2.2.2 Reporting...8 2.2.3 Conference set up...8 2.2.4 Technology requirements...8 2.2.5 Encryption...8 2.3 network (desktop based)...8 2.3.1 User authorisation...9 2.4 General Requirements...9 2.4.1 General set up...9 2.4.2 Conferencing...10 2.4.2.1 Conferencing from the internet... 10 2.4.2.2 Sharing during conference... 10 2.4.2.3 Recording the conference proceedings... 10 2.4.2.4 Logging and auditing... 10 2.5 Operating system and firmware...11 2.6 Auditing...11 3 Conferences and Meetings to and from the Internet...12 3.1 ISDN connections...13 4 Interconnectivity of video networks...14 4.1 Interconnectivity Architecture...14 5 Federation with non-ntg organisations...16 6 E-learning Packages...18 7 Green ICT requirements...19 Corporate and Information Services
1 Executive Summary devices are deployed extensively across the NT Government ICT environment. These improve communications by providing conference facilities on demand, improves productivity, and reduces costs, travel and greenhouse gas emissions. Users from anywhere in the world can interact with the users in NTG in a secure and controlled manner. The standards will reduce the number of systems with proprietary protocols and standards. The document provides functional requirements and standards to which the videoconferencing equipment should adhere for interoperability, interfacing with NTG ICT infrastructure, scalability and, above all, useability. All of the videoconferencing should be defined to the Identity and Access Management system (EPass2). All dedicated videoconferencing equipment should have a static IP and a service account to be eligible to be present on the network. All videoconferencing devices and systems be able to work with standardised protocols to achieve maximum interoperability. 1.1 Aim of standards The document describes functional requirements for videoconferencing devices used in NTG. Where possible, standards will be specified for the requirements. The requirements provide standards for interoperability, security and integration in to the NTG ICT environment. User features that will form part of a business requirement are not part of this document. The features need to be negotiated with the supplier at the time of procurement by Agencies. 1.2 Applicability The standards in the document apply to all NTG Agencies. Any deviation from the standards requires the approval of NTG Enterprise Architecture and Security Unit. The deviation if found valid will be given approval and an update to the standard will be issued. It is understood that the standards for videoconferencing is in development stages in the NTG environment. This document could be considered to be interim standards until all the aspects of the videoconferencing set up variations are settled. 1.3 Scope The standards apply to all videoconferencing devices namely, devices that are set up: in conference rooms, to deliver high definition video (eg., Cisco Telepresence) and to deliver telemedicine services; and as desktop facilities. This does not cover any internet based conferencing services such as Skype, Yahoo Messenger, etc. 1.4 Other applicable documents NTG Green ICT policy Access Standards Corporate and Information Services 4
Audit policy 1.5 Acronyms used in this document The following acronyms are used in this document: AD HD OS OCS VOIP MCU SIP UC PSTN Active Directory High Definition Operating System Office Communicator Service Voice over Internet Protocol Multipoint control unit Session Initiation Protocol Unified Communications Public Switch Telephone Network Corporate and Information Services 5
2 Devices 2.1 General requirements (Conference room based) These are fixed devices in conference rooms. Conference equipment in the room is then connected to an MCU or equivalent system that controls how conferences are organised by participants. The MCU sets up a conference at the required time and date with a PIN number. The participants dial in to the MCU with the PIN. A variation to this could be that an event is set up by the MCU and a web link sent to all participants. The participants then click on the link and a conference is set up. Another variation is that the IP Address of a videoconferencing device is used to connect to the MCU. The MCU will be set up to accept connections only from authorised IP addresses. The system should be capable of supporting standard protocols such as SIP, and other standard telecommunications protocols (#3.5) for maximum interoperability. Fig.1 General arrangement of a videoconferencing network 2.1.1 Video Network (conference room based, HD telepresence, telemedicine) All videoconferencing devices should be controlled by an MCU or an equivalent system to initiate any service. devices should be registered to the MCU with an IP address and a service account allocated to the device. All videoconferencing devices should connect to the MCU using a UserID and password (Service Account). Each device should have a service account with which it connects to the AD and then authenticates to the MCU through a single sign-on process.. All videoconference devices should have a static IP address. The MCU will only accept connections from devices which are registered to it. 2.1.2 MCU registration All videoconference devices should have the following details registered to the MCU: Device name; Corporate and Information Services 6
Service account userid; and Static IP address. 2.1.3 IAM (EPass2) details All videoconference devices and MCU should have the following defined to the IAM: Service account userid; Device Name; Purpose; Static IP address; Location of the device; Device Owner (Typically an Agency representative); Phone number of Owner; and Service provider. The name of the device should conform to server naming standards used by the service providers for machines in the AD. Using the above the AD should create an account and password for each device. 2.1.4 Redundancy The MCU design should consider redundant devices to be able to provide a continuous service in the event of the failure of the main MCU. 2.2 Management software The MCUs should be capable of being managed centrally by each of the service providers that manage a videoconferencing network. The management application software access should be secured by UserID and password. Any changes to the application software should be done by privileged accounts set up for the purpose. All accesses to MCU configuration and changes should be secured by such privileged accounts. 2.2.1 EPass2 or IAM (Identity and Access Management) All MCU privilege accounts should be defined to the IAM. This should contain the following details: Account userid; name of the MCU; agency details; location; IP address; and service provider contacts. Corporate and Information Services 7
The name of the MCU should conform to server naming standards used by the service providers for machines in the AD. This information should be kept updated regularly and this is the responsibility of the relevant service provider The accounts should be synchronised with all details with the AD so it can log on to a defined MCU. 2.2.2 Reporting The management software should be capable reporting the following. Status of the machine; Be able to reset MCUs; Provide statistics on usage such as: Number of calls made; Number of conferences made; Details of the users using conference; and Files shared ( if relevant and applicable). 2.2.3 Conference set up The videoconferencing application on the MCU should include a Directory of all videoconferencing endpoints with all their details including IP addresses. All the videoconferencing endpoints should be included as a resource in Microsoft exchange Directory. The MCU should have the ability host several conferences at the same time. 2.2.4 Technology requirements The devices and MCU should be capable of supporting and operating with all or relevant sub-sections of industry videoconferencing standards such as: SIP protocols; H 323; H 264; H 262; and MPEG 4 or equivalent. 2.2.5 Encryption Some agencies may require encrypted sessions when sensitive information is involved. An option to encrypt conferencing sessions should be available. 2.3 network (desktop based) There are a number of products that provide videoconferencing at the desktop level. Some popular products used in NTG are Microsoft OCS, Polycom and REACT. These products generally use low bandwidth and a webcam with audio. The products may also include a softphone for making PSTN telephone calls. The products may be able to provide presence information. In general, calls between users will be made using the product. The products should be capable of conferences involving several users. The users may be able to share the desktop or another application and text each other. The applications are likely to provide converged communications experience by integrating Office applications, such as Outlook, Word, Excel, etc with the ability to schedule and conduct online meetings and instant messaging. Users are likely to be Corporate and Information Services 8
able to make and receive phone and video calls from other colleagues using their desktop computers as well as make and receive telephone calls via the public telephone network using the conferencing applications. The users should be able to set up conference calls with others on the internet. The videoconferencing set up will need client application interfaces with the services on the desktop and the servers that enable connections to other users. 2.3.1 User authorisation User accounts should be authorised by an appropriate delegate from each agency to use desktop conferencing services. Further the authorisation should specify if a user is authorised to use the facilities from the internet. The following information should be captured in the IAM: Name of user; UserID; Agency; Phone number(s), including mobile; Authorised for just softphone (Yes/No); Authorised for conferencing software (Yes/No); Authorised for videoconferencing (Yes/No); Authorised for conferencing from the internet (Yes/No); and Authorised for conferencing with federated organisations (Yes/No). 2.4 General Requirements 2.4.1 General set up set up may have one or more of the following functions depending on the application and set up. Only the basic features are mentioned here: Phone Service (Desk Phone & Soft Phone); Conference Calls (video & audio); Presence Awareness; External Conferencing; Desktop \ Application Sharing; Webcam Compatible; Voice Mail; and Mobility (connect from any location) using smartphones. As a minimum, the devices should be capable of making video conference calls. In some products some of the above features may not be available. Corporate and Information Services 9
2.4.2 Conferencing The set up should be capable of making conference calls using audio and/or video. This should be possible both within the NTG network and from and to the internet. In general, conferences should be possible to be set up as ad hoc or a planned conference. When a planned conference is set up, the calendar on invitees should be updateable should the user chooses to accept the invite. When the conference is set up a URL link should be created by the software and a unique ID provided to the invitees. Additionally, invitees should be able to join the conference by dialling a phone number provided. Joining the conference should be possible either using conference client application or using a webpage. Access to conferencing features through the desktop based client should be available from the NTG network, via VPN and the internet. 2.4.2.1 Conferencing from the internet The conferencing setup mentioned should be possible for anyone from the internet joining the conference. The conference should be possible only by invitation by a host from within the NTG network. The connection from the internet is received by a reverse proxy at the gateway to ensure that the URL and unique ID supplied by the invitee matches that supplied by the inviter. If there is a match, the invitee is allowed to join the conference. 2.4.2.2 Sharing during conference The conferencing should be capable of capable of sharing a portion of the desktop or a specific application during the conference. This should be initiated by some one that wishes to share their desktop or application. The invitee sharing the workspace should then able to stop sharing at any time. The application should be capable of providing full control of the desktop or application to one or more participants. 2.4.2.3 Recording the conference proceedings It is anticipated that the conference proceedings will be recorded by the participants especially in a training situation. In all cases where recording is done the users who recording should let the others know that the session is being recorded. 2.4.2.4 Logging and auditing All calls made through the video application client should be logged. If files are transferred, such events should also be logged. In general the details logged should be: Name and UserID of the user; SIP sign in name; Asset number; Time and date of call; Duration of call; Names and UserID of receivers; Corporate and Information Services 10
SIP sign in name of receivers; and Mode of conference (Client based, URL, telephone, or a combination). It is the responsibility of the service provider to set up logging and provide an appropriate visualiser so that the report can be read and copied in to popular office products. Auditing should be done as per the NTG Auditing policy. 2.5 Operating system and firmware All devices operating systems (OS) should be compatible with the OS of the NTG fleet. At present, the NTG server SOE (standard operating environment) is based on Microsoft Windows operating systems. The devices should be capable of interoperating with the Windows based servers. However, there are a few servers and workstations that are not based on Windows OS. Interoperating client devices and other server devices not based on Windows OS is the responsibility of the system owners. The OS and firmware should be updated regularly to ensure that they do not create any security issues. 2.6 Auditing All accesses and changes made to the configuration of management software should be logged. The logs should be able to be read using Excel or other popular office applications. Corporate and Information Services 11
3 Conferences and Meetings to and from the Internet All connections made from and to the internet should be done in a secure manner without exposing the NTG network to the internet. Any such accesses should be controlled by a video border reverse proxy. The reverse proxy will allow only authorised connections from the internet. This is shown in the figure below. The authorised connections are allowed only through: Meeting or Conference ID; Entry code; a SIP location; and in rare instances IP address. These entries are to be generated by a video application server. The video application server will need to authenticate each connection from the internet based on the above. Fig.2 Connectivity from the internet through a Video Border Reverse Proxy The reverse proxy should ensure that it accepts connections from internet only based on valid parameters allowed for a videoconferencing system, i.e., application hardened. The reverse proxy should be set up such that it will not allow connections from the Corporate and Information Services 12
internet beyond what a videoconferencing application server will allow. Normally the connection from the internet will be allowed until the MCU (video application server) and not beyond. The MCU will host the conference and the proceedings are relayed to all the participants. Some videoconferencing systems may require the internet user to have some specific software installed on their machine. For example, Microsoft Live meeting software is required for some conference invites. Reverse proxy should be capable of SSL encryption at a minimum of 128 bits. 3.1 ISDN connections In some cases the videoconferencing connections would be through an ISDN connection. For this, an MCU which accepts such connections only from an ISDN should be placed at the DMZ in front of the Video Border proxy. The MCU will not accept connections from anything other than an IDSN line. Connections from this MCU will be accepted by the reverse proxy. Such conferences should be prearranged. Such connections from the internet need a meeting or conference ID and a conference location that was prearranged. This will avoid any spamming from the internet without valid parameters. The appropriate MCU that is hosting the conference should have the valid entries for the conference. Corporate and Information Services 13
4 Interconnectivity of video networks It is anticipated that the different videoconferencing systems produced by different vendors will be able to share some basic features with each other. For example, a videoconferencing system produced by Polycom for Desktop purposes is expected to interconnect with Microsoft UC system user at least for Video/audio conferencing. A system that enables this interconnectivity will be called the interconnectivity gateway (IG). The IG will work mainly based on standard protocols described in 3.5. The interconnectivity can be enabled only from within the NTG ICT network. Users from the internet while in a meeting will not be able to enable interconnectivity. There may be requirements to translate non-standard protocols but this is not recommended. It is up to the system owner of non-standard protocol to arrange for conversion to standard protocols and carry out the testing. This should be considered when procurement planning is contemplated. Fig.3 Interconnectivity architecture for connecting various networks within the NTG ICT network 4.1 Interconnectivity Architecture The MCUs or equivalent systems from different videoconferencing networks within NTG should connect to the IG for enabling interconnectivity. The IG should be capable of converting protocols from one network in to a protocol that can be received and translated by another network of a different system. Although the systems are required to be based on standards, it is expected that the IG will enable interconnectivity if there are minor changes to standards. The interconnectivity architecture is shown in Fig.3. In order to enable interconnectivity, the presence information of users from various videoconferencing networks should be made available on IG. This will also display if the user is on the same system or a different system. Corporate and Information Services 14
The IG interfaces with the AD and be able to download all contact information from the AD. The IG should display all information from the AD along with the presence information. In general, the IG should not be used for connecting to and from the internet for any meeting or conference purposes. Corporate and Information Services 15
5 Federation with non-ntg organisations It is possible to allow some non-ntg organisations to be able to see presence information of NTG staff and be able to initiate video/audio conferencing without any of the additional steps mentioned above. They will be deemed to be part of the NTG. This will be based on a trust established between organisations and NTG. The videoconferencing system should be able to identify federated staff of another organisation and show their presence information by different colour or other means. Organisations that are to be federated with NTG should be carefully selected to ensure that they will not misuse NTG information such as email address and phone numbers of NTG staff. In general, a vendor organisation will not be permitted to be federated with NTG. A request highlighting why an organisation should be federated with NTG should be made to the NTG ICT Infrastructure, Architecture and Security Unit. Federation should be normally in the instance where there is considerable interaction between the non-ntg organisation and an NTG agency. An agreement between both the parties should be executed to exclude any staff behaving in an inappropriate manner while using the conferencing system. The granting of access to NT Government information and ICT facilities should be formalised by a contract, or memorandum of understanding, containing, or referring to, all of the NT Government s security and Access policy requirements. A videoconferencing system should be capable of blocking a non-ntg user if they are found to be behaving in an inappropriate manner. Once blocked the non-ntg user will not be able to lift the block unless an explanation in writing is provided to a senior NTG business manager. This should be covered in the agreement between the federated organisations. NTG staff member to be able to federate should request a business manager to approve federation in Epass. Staff that are permitted to federate are still covered by the NTG End User ICT Services Policy and, additionally, the agreement between NTG and the federated organisation. Some staff even if allowed federation may wish to keep their presence information unknown to federated organisation or they may choose to have their presence known to some selected staff in the federated organisations. The system should be able to control the following: File sharing; Desktop sharing. Conferencing; and Texting, The service provider of each videoconferencing network should log the following details for a federated session: Name of the NTG User(s); Name of non-ntg users; Time of contact; Corporate and Information Services 16
Duration of contact; Files shared; and Desktop sharing (Yes/No). For federation to occur the federating organisation s edge server should authenticate to the NTG s edge server and vice versa. In the case of NTG, the edge server is the video border proxy. The edge servers should have third party trusted certificates which should be verified during the authentication process. The edge server s IP address should also be verified at the time of authentication. Corporate and Information Services 17
6 E-learning Packages There are a number of packages within NTG ICT network that are used for training. Some of the training packages in wide use are: Moodle; GoTo Meeting; and Adobe Connect. Corporate and Information Services 18
7 Green ICT requirements All the relevant requirements of the NTG Green ICT policy should be adhered to when the devices are purchased. All devices should be Energy star compatible. All suppliers of equipment should be a signatory to the National Packaging Covenant. (http://www.packagingcovenant.org.au). The devices should be recyclable as per local legislation or regulations Corporate and Information Services 19