IOCOM Whitepaper: Connecting to Third Party Organizations

Transcription

1 IOCOM Whitepaper: Connecting to Third Party Organizations September 2008 IOCOM

2 Table of Contents 1. Executive Summary 2. Goals 3. Scenarios for Enterprise Connectivity over IOCOM a. Connecting over IOCOM-based nodes from within the Company Firewall b. Connecting from IOCOM-based nodes over a VPN c. Connecting to Third Parties using an External UCS Federated to Internal UCS d. Internal Enterprise UCS Federated to Semi-Public WebConnect Serverf e. Internal Enterprise UCS Federated to Public IOCOM Hosted Services f. Hosted Subscription Services 4. Integrating Third-Party Systems to IOCOM Networks a. Legacy IP Videoconferencing, VoIP, and ISDN Videoconferencing

3 Executive Summary The IOCOM Grid (IG) multimedia collaboration platform is a scalable, adaptable, software solution enabling geographically distant users to easily and reliably meet face to face in rich collaborative environments. The IG software solution is an IP network based client and server application. The IG Unified Collaboration Server (UCS) runs on commodity hardware running the Linux operating system. The IG grid architecture can be readily scaled across commodity hardware to increase capacity while functioning as a single centralized system. The IG UCS can also be federated with additional IG UCS systems to expand the network within or outside of internal firewalls. The IOCOM WebConnect Server, or WCS, enables users to connect either through our existing client software or from a web browser using standard network connections. The WCS can federate with existing UCS systems, vastly expanding the number of users who will have easy access to successful IOCOM Visual Communication solutions. The purpose of this document is to discuss the capabilities as they pertain to existing network configurations in Enterprise environments, paying particular attention to security concerns and interoperation with third-party communication tools. Goals IOCOM s primary goals include: - Allowing everyone within internal networks to easily communicate via the IOCOM platform. - Allowing seamless, secure communication with approved users outside of internal networks via the IOCOM platform. Scenarios for Enterprise Connectivity using the IOCOM Software The following scenarios describe the process and architecture of connecting to individuals, corporations, or organizations using entirely IOCOM-based technology. These scenarios provide for the best video and audio experience, and the greatest amount of control, flexibility and security, while requiring the least amount of administration overhead. The first two scenarios focus primarily on connections for employees who have access to the internal company network or VPN. Scenarios for connecting to third parties, such as outside consultants or contractors who may not have access to the company network are illustrated in Scenarios 3, 4, and 5. Using IO- COM web clients and subscription-based services allows for connections to virtually any individual or company, while guaranteeing security and reliability. For a discussion of connections to non-iocom systems such as legacy videoconference hardware, see section four below. Scenario 1: Connecting over IOCOM-based nodes from within the Company Firewall Under this scenario, all endpoints are located within the company firewall. This allows for the greatest security, as absolutely no data must leave the company network, however it obviously presents difficulties in meeting with third parties, as it requires an internal network connection. This scenario is illustrated here as the preferred scenario for company employees who have access to the internal company network. - Providing for interoperation with third-party communication tools and protocols as necessary. In meeting each of these goals, the primary focus is on maintaining security while allowing for the greatest possible distribution of users joining via IOCOM and/or by connecting via other phone and VTC endpoints. To that end, certain cases in the following scenarios present special limitations of technology and security. These are noted as appropriate and are being worked on by our development team as priority dictates. Under this architecture, each endpoint connects directly to an IOCOM UCS sitting on the internal net-

4 work, and therefore accessible to each endpoint without introducing security concerns. In the case of large corporations, multiple IOCOM UCS systems can be housed internally and then federated to each other, allowing all endpoints to contact any other endpoints. This method localizes regional traffic and minimizes more expensive WAN traffic, regardless of which specific UCS the endpoint is connected to on the network. As above, each endpoint has a permanent client license obtained from IOCOM, and users authenticate to the UCS's access list. Alternately, authentication can be tied to a centralized corporate LDAP or Active Directory server for administrative convenience. Each endpoint has a permanent client license obtained from IOCOM, and users authenticate to the UCS's access list. Alternately, authentication can be tied to a centralized corporate LDAP or Active Directory server for administrative convenience. In addition to authentication control, this scenario also offers the Enterprise complete control over the meeting experience for all users. Using the UCS's limits manager allows administrators to restrict bandwidth, specify the video and audio codecs to be used, and allow or disallow the separate IGTools functionality (e.g. Recorder, IGFile, etc.) on a permeeting per-ucs, or corporate-wide basis. Scenario 2: Connecting from IOCOM-based nodes over a VPN Under this scenario, all endpoints either reside on the Enterprise's internal network, or they connect to the internal network over a VPN set up by the company. This scenario allows for a very high degree of security at low administrative cost. This is the preferred architecture for connecting to employees or contractors at remote locations when VPN connections are feasible. Each endpoint tunnels via VPN to connect to an IO- COM UCS sitting on the internal network. The UCS remains completely inaccessible to any machines not connected to the VPN or the local network. As above, multiple internal IOCOM UCS systems can be federated to each other, allowing all endpoints to contact any other endpoint, even in the case of an endpoint connected over the VPN. Because this scenario uses the company VPN, all data remains entirely within the corporate network. This allows the Enterprise to maintain its VPN and internal network according to its standard practices. In addition to authentication control, this scenario also offers the Enterprise complete control over the meeting experience for all users. Using the UCS's limits manager allows administrators to restrict bandwidth, specify the video and audio codecs to be used, and allow or disallow the separate IGTools functionality (e.g. Recorder, IGFile, etc.) on a per-room, per-ucs, or corporate-wide basis. Scenario 3: Connecting to Third Parties using an External UCS Federated to Internal UCS Endpoints and users within the corporate firewall connect to the company's internal UCS, as described in the above scenarios. External users, however, connect to a separate UCS housed outside the corporate firewall. This external UCS is federated to the Internal UCS, and proxies all external IOCOM connections through the external UCS entry point. Internal IOCOM endpoints can securely create and join meeting with external endpoints. However, external do not have direct access to the internal UCS and all traffic is routed over the federated connections. The corporate firewall can monitor the RTSP setup negotiation and dynamically open and close UDP ports during the session between the internal and external UCS. All IOCOM endpoints use client licenses purchased from IOCOM. These licenses can be purchased either by the sponsoring Enterprise or by the individual third party partners and vendors. Although client licenses

5 are transferable, this approach may present scalability limitations when applied to users who will only connect for one or two meetings per year. client licenses among them. The web-based client does not contain all of the features of the standard licensed client, but is able to run on most systems and allows for very low-setup or no-setup participation. Web browsers with an installed Flash component would provide richer video, audio and collaboration tools than plain standalone web browsers. Scenario 5: Internal Enterprise UCS Federated to Public IOCOM Hosted Services The user accounts and access lists on the external UCS can be managed either by IOCOM or by the sponsoring Enterprise. This approach utilizes a new server technology currently under development at IOCOM. Internal users would be able to join meetings with any current subscriber to the IOCOM hosted service. Trial software would be available at no charge for initial users. Scenario 4: Internal Enterprise UCS Federated to Semi-Public WebConnect Server This approach utilizes a new server technology currently under development at IOCOM. This new server product allows connections to fully licensed standard clients, but also to any authorized user with a standard web browser. The web clients are not licensed and the WebConnect Server will be configurable to allow a specified number of concurrent web connections as well as a specified number of licensed connections. The access list to the WebConnect Server is managed by either the Enterprise or IOCOM. The new server product can be federated to a specific Enterprise UCS or group of UCS s, as in the above scenario, and would not be part of a wider public IOCOM cloud. The Enterprise could limit federation access to a specific list of UCS s. This scenario allows for the flexibility to connect to third parties as necessary without needing to transfer The access lists to the WebConnect Servers are managed by IOCOM. Enterprise UCS or group of UCS systems, would be federated to the wider public IOCOM cloud. All traffic would be routed through the public Web- Connect servers to through the Internal Enterprise UCS and onto the internal client endpoints. This scenario allows for the flexibility to connect to third parties as necessary without needing to transfer client licenses among them. The web-based client does not contain all of the features of the standard licensed client, but is able to run on most systems and allows for very low -setup or no-setup participation. Web browsers with an installed Flash component would provide richer video, audio and collaboration tools than plain stand-alone web browsers Scenario 6: Hosted Subscription Services This is a fully hosted service. IOCOM hosts the servers and licenses are renewed via subscription payment. Various subscription plans provide different features, such as multiple video sends, Hi-Def codecs and higher encryption levels. No internal UCS is necessary as all clients

6 directly connect to the external IOCOM hosted UCS. The corporate firewall can monitor the RTSP setup negotiation and dynamically open and close UDP ports during the session. The public UCS may host multiple companies on the same server or cluster of servers. This approach allows both the Enterprise and third party partners and vendors to subscribe to the service as needed. Integrating Third-Party Systems to IOCOM Networks Legacy IP Videoconferencing, VoIP, and ISDN Videoconferencing The UCS can initiate and receive H.323/SIP calls as well as connect to PSTN and ISDN endpoints. H.323 and SIP endpoints directly establish a call with the UCS and do not directly connect to the IOCOM clients. The UCS does not directly establish connections with PSTN and ISDN endpoints and instead uses a gateway. PSTN traffic is routed through any standards based VoIP gateway to convert the signaling and audio traffic to IP (using either H.323 or SIP as the signaling protocol). ISDN endpoints also require a gateway to translate the signaling and media streams to SIP/H.323 and IP. The ISDN gateway, normally a MCU which supports ISDN and IP, completes the videoconferencing call between the UCS and the ISDN videoconferencing end point. An external UCS federated to an internal UCS can be used to allow third party access without needing to open potentially vulnerable h.323/sip access through the corporate firewall. Third party users join an external IOCOM UCS by entering the IP address of the UCS and entering the meeting code that was assigned by the internal enterprise user. The federated UCS system then joins the internal enterprise client and the external third party device over the secure federated link. Enterprise users wishing to dial out to external third party legacy videoconferencing devices must be directly connected (not through federation) to the external UCS. The dialer that is used to connect the IG client to the legacy device is on the UCS that the user is registered to. Attempts to dial an external device from an internal UCS would most likely fail unless firewall traversal for legacy protocols is available. Once the external UCS is connected to a legacy device, all other IG participants can join the meeting from their local federated UCS as they would any meeting. Only one IG participant is required to join the external UCS to establish the connection. Gatekeepers manage call setup, resources and bandwidth for h.323 and SIP voice and video networks. The UCS can register with a gatekeeper to work within enterprise call control processes. Once registered, the UCS will pass all dialing and call type information to the gatekeeper for processing. The gatekeeper allocates the proper resources; bandwidth, gateways, endpoints; required for the call completion and instructs the UCS how to terminate the call. For networks with multiple gatekeepers that handle different types of traffic, they must route through a single gatekeeper that will direct the UCS traffic to the appropriate network termination point. Conclusion IOCOM delivers a flexible visual communication solution that gives enterprises complete independence ofdevice, network, and location. IOCOM ensures that everyone in the company is able to securely connect both inside and outside of the corporate environment. As shown, our flexible network scenarios adapt any situation, eliminating all walled gardens. And by providing client side software solutions that scale from webbrowsers to laptops to full-featured conference centers, IOCOM solutions integrate easily into any environment and workflow.