APPENDICES. Aethra X5

Appendices

Network Requirements IP\H.323

The network requirements for point-point connections between videoconferencing terminals are as follows.

The complete network path connecting two H.323 terminals must have a constant available bandwidth for the whole duration of the connection. The effective bandwidth used on LAN/WAN

Full-Duplex network connections is equal to the sum of the Audio Rate and Video Rate, plus approximately 20% for TCP/IP overhead.

In the case of Half-Duplex LAN/WAN networks, the aforementioned bandwidth is doubled. For example, if it is necessary to guarantee a 384K connection for the video and a 64K for the audio, the bandwidth allocated must be at least (384+64) *1.2 ≈ 540K for each Half-Duplex connection. In case of dial-up WAN links, it should be underlined that their efficiency in terms of “useful” bandwidth is approximately half the total available bandwidth.

It is always preferable to use mechanisms such as QoS for WANs because they take into account the total bandwidth required for a videoconference, rather than relying exclusively on overdimensioning the network. This is necessary for the handling of increasing numbers of simultaneous connections or a network that is already loaded.

The network needs to be set up so that latency and jitter are as low as possible. Extended times for latency and variable jitter can create serious problems, especially in video quality.

It is always preferable for H.323 terminals to be connected to switched type LAN connections to avoid the traffic generated by terminals being superposed on the normal traffic present on the network.

It is preferable to avoid using NAT-type protocols on router interfaces that route H.323 packets, since NAT protocols often do not allow the correct routing of connections.

If NAT, firewall or access list implementations are to be used, they must be H.323 compatible.

Network Requirements for Multivideoconferences H.323 (MCU)

The same requirements indicated above apply to multipoint connections between more H.323 videoconference terminals.

In this case, more H.323 streams converge in the network, increasing the local network-load. The consequence is that the bandwidth allocated must be the sum of the bandwidths required for each of the individual connections, calculated according to the description given in the previous section.

The network requirements previously described are also valid for connections between H.323 and

H.320 terminals via gateways. In this case, more than one H.323 stream converges on the gateway increasing local network traffic. As such, the necessary bandwidth, at the point where the

H.323/H.320 gateway is to be installed, must be the sum of the bandwidths required for each individual connection, calculated as shown in the previous section.

77

NAT – FIREWALL Interoperability

Introduction

There are many strategic advantages for companies that succeed in making all traffic converge from voice applications, video and data to one IP network infrastructure.

Unfortunately, the drive to concentrate all IP communications onto one single network has reduced.

The connection between a company’s corporate network and the Internet world is accomplished with firewalls and devices using NAT (Network Address Translation), which block voice and video calls via IP. Firewalls block IP traffic for video and voice by preventing any unsolicited communication from the outside. Devices implementing NAT block IP traffic because all equipment on the internal network uses private IP addresses, and can therefore not be contacted from outside the local domain.

There are several solutions to the problem of getting IP communications past NAT and firewalls: bypassing the firewall or NAT device, upgrading the network infrastructure with an Application

Level Gateway (ALG), and going out through the firewall or NAT using semi-tunnelling connections. Going around the firewall or NAT device is not the best solution for most companies.

Removing the firewall or placing videoconferencing equipment on an unshielded section of the network could seriously compromise the network’s security.

Using these devices is very expensive and besides this an access policy for Firewalls and NATs would be needed. These devices should be located along the communication path at every point where a NAT and Firewall are present.

A second solution is the improvement of the network by the introduction of an ALG, but this is intrusive and potentially expensive. ALGs are software packages specifically designed for firewalls from various producers that examine every packet attempting to pass through the firewall in order to determine whether it concerns a known protocol like H.323 or SIP. If the packet contains a known protocol, the Firewall allows it through. However, like Proxies and MCUs that go around firewalls, ALGs also need an access policy for firewalls and every firewall or NAT device needs up-to-date ALG software. Because new protocols are continually being developed, ALG software must be updated frequently.

IP Voice and Video Crossing NAT and Firewall

The use of existing network infrastructures for the transmission of voice, video and data promises interesting strategic advantages for companies of all sizes. Commonly known as “rich media communications” or “Internet Protocol (IP) communications” these technologies for converging networks offer new opportunities to communicate, coordinate and collaborate with customers, suppliers, commercial partners and others all over the world.

Unfortunately, the protocols used for IP communications conflict with most of the security mechanisms for networks (such as Firewalls and NAT), resulting in protracted or late implementation times for IP video and voice applications.

Firewalls and NATs – How they work

In an IP network, every device is assigned a unique IP address. All computers, telephones, and videoconference terminals have at their disposal approximately 65,000 ports for the purpose of establishing communication channels to transmit data to other devices on the network.

Messages between IP network devices are composed of packets that contain the following information: the IP address of the terminal that has generated the message, the port number from which the message has been sent, the IP address of the destination terminal, the port number at the destination, and the data being sent.

78

Firewalls

Companies that allow connection to the Internet by their employees typically install a firewall in order to prevent external access of or tampering with internal data.

The firewall examines the destination IP address and port number of every packet received from outside. Usually, firewalls are configured in such a way that if a computer from inside the firewall requests data from a computer outside the firewall, the response packets will be allowed through from the external computer, but only if they are sent to the IP address and port of the internal computer that generated the request.

If the Firewall receives a packet destined for a computer that is located internally and determines that the destination computer has not initiated any communication, the firewall discards the incoming packet.

Firewalls are nearly always configured to block all incoming traffic that has not been explicitly requested. Internal web servers are the exception: they must be accessible from the outside. To allow this, the network administrator configures the Firewall to let through packets destined for port

80 of the IP address of the web server. This operation allows external users to send requests to connect to the company’s web server in order to access data on that server.

NAT (Network Address Translation)

Network Address Translation is an Internet standard that allows a LAN (Local Area Network) to use a set of IP addresses for internal traffic and another address (or set of addresses) to connect to services on an external network (the internet, for example). Devices that implement NAT are located at boundaries between the LAN and the external network, and their purpose is to provide translation of IP addresses for all packets that are destined for the external network. Many organisations use NAT as a security mechanism because it masks the internal IP addresses – if hackers do not know the IP address of a machine, they cannot attack it and cause disruptions. NAT also allows a company to use more IP addresses than they might otherwise be allocated. Since these addresses are only used internally, there is no problem with IP address conflicts with other organisations.

Problems with Video and Voice Communications on NAT/Firewall Protected Networks

The IP based voice and video protocols like H.323 require that terminals be capable of establishing audio-video communication channels using IP addresses and data ports. In this situation, a problem arises: terminals must “listen” for incoming calls to establish IP connections, but the firewall is generally configured in such a way as not to allow packets past that are not expressly requested.

Even if the network administrator left a port open for the terminal to receive notification of a call

(port 1720, designated as a “well-known TCP port”) the video and voice communication protocols for IP necessitate the opening of other ports in order to receive control messages and open audio and video channels.

The identities of these additional ports are determined dynamically, not in advance, meaning that the network administrator would have to open all the firewall ports to allow video and voice communication, thus virtually disabling the firewall. Network administrators are unlikely to do this

(and wisely so), since it effectively eliminates network security policies.

NAT also creates an obstacle for voice and video communications over IP. NAT allows an organisation to assign private IP addresses to machines on the local network, but routers that control the flow of data towards the internet can handle only packets with routable addresses or public IP addresses.

A terminal located behind the NAT device on the LAN can initiate communication with any other terminal in the same LAN because the IP addresses within the LAN are routable, meaning that it is possible to have subnets in a company managed by an internal router. This allows the establishment of audio-video communications on different branches of the subnet.

79

Because they have private addresses, and are therefore not accessible from outside the NAT, terminals on the LAN cannot be reached by externally originating calls. Even if they initiate calls to external terminals, a problem still arises. When the call is initiated, the IP address of the calling terminal is contained in the payload of the packet sent. The destination terminal receives call setup packets, examines them and starts to transmit audio and video towards the terminal from which the call was received, and from which the IP address was obtained by examining the contents of the received packets.

If this IP address is private, the router for Internet access discards the audio and video packets sent from the terminal external to NAT towards the internal terminal because the packets sent were nonroutable. The connection between two terminals appears to be successful but in reality the NATinternal terminal never receives the audio or video from the external terminal.

Solution for the NAT/Firewall Problem

The only equipment that does not create any of the problems described above is a NAT/firewall

H.323-compatible device. Such a firewall does not block the TCP 1720 port and allows access to the other, dynamically-determined H.323 ports.

Videoconferencing systems usually have private IP addresses that are not accessible from external routers. To allow calls to function properly, the network administrator can define static NAT (a permanent association between a private IP address and a public IP address reserved for H.323 videoconferences) for every terminal that must be accessible from an external connection.

The NAT device substitutes the static IP address in the payload and header setup packet sent from the internal terminal to the external terminal. The destination terminal uses that address for addressing the reply packets, which are routed through the NAT device to the internal terminal.

Firewall ALG

Application Level Gateways (ALGs) are firewalls programmed to recognize specific IP protocols like H.323.

Instead of looking only at the information contained in packet headers to determine whether to transmit or block packets, ALGs analyse in detail the data contained in the payload packet. The

H.323 protocol inserts important control information such as audio and video port identification in the payload packets. The terminal expects to receive audio and video connections from the remote calling terminal on these ports. By analysing which port the terminal expects to use, the ALG dynamically opens only those ports, leaving the others closed to preserve network security. An example of a firewall ALG follows.

The Aethra Application Level Gateway is present in the Aethra Stargate xDSL Router and allows any videoconferencing terminal, independent of its manufacturer, resolve the NAT/firewall problem. The Stargate router is capable of checking every incoming and outgoing H.323 call and dynamically opening only the ports being used for the H.323 videoconference.

The Stargate router also supports NAT functionality and is therefore capable of substituting the public NAT address for the private IP address automatically inserted in the H.323 payload packets by the internal terminal. When the Aethra ALG functionality is used with an Aethra videoconferencing system, the “Aethra NAT” function of the videoconferencing system must be disabled because the network equipment is H.323 compatible.

80

Wireless Cards

The minimal cards wireless requirement to use the system in wireless nets is standard Wi-Fi

PCMCIA IEEE 802.11b.

Some models of cards wireless supported:

• BENQ AWL100

• CISCO/AIRONET AIRPCM 350

• All AGERE/ORINOCO compatible cards.

For other information relative to the compatibility Wi-Fi 802.11b, 802.11g, 802.11a please contact

Help Desk Aethra Telecomunicazioni SpA.

Mail: [email protected]

81

Technical specifics

Supported Standards

• ITU-T H.320:ISDN, leased networks

• ITU-T H.323: IP networks

• IETF-SIP (RFC3261): IP networks

• PPPoE

• Video: H.261, H.263++, H.264, H.239, H.241

• Audio: G.711, G.728, G.722,

G.722.1, MPEG4 AAC-LD

• Data: T.120

• LDAP: H.350

• MCU compatibility H.243, H.231

Transmission

• Bit rate:

56 kbps ÷ 768 kbps over ISDN BRI

56 kbps ÷ 2 Mbps over ISDN PRI**

64 kbps ÷ 4 Mbps over IP (H323/SIP) rates

56 kbps ÷ 2 Mbps over V.35/Leased

**in North America ISDN pri/t1 at

1544 kbps (ansi t1 recommendations)

• Simultaneous video motion coding and PC presentations from the XGA input

Video

• Frame rate:

15 fps @ 56 kbps -128 kbps

30 fps @ 168 kbps - 4 Mbps

• Video resolution:

4CIF 704 x 576 pixels

FCIF 352 x 288 pixels

QCIF 176 x 144 pixels

4CIF 704 x 576 pixels for still images (H.261 Annex D)

Up to 1024 x 768 pixels over XGA in H.263

•

Remote camera control:

H.281 (H.320 - H.323)

Audio

Audio Band Bit rate

G.711 300 ÷ 3400 Hz 56 kbps

G.728 50 ÷ 3400 Hz 16 kbps

G.722 50 ÷ 7000 Hz 48/56 kbps

G.722.1 50 ÷ 7000 Hz 24/32 kbps

AAC-LD 50 ÷ 14000 Hz 48/56/64 kbps

• Echo cancellation: Full-duplex

• Adaptive post filtering

• Automatic Gain Control (AGC)

• Automatic Noise Suppression

Audio Tracking

• Tracking: Enhanced Voice Tracking

• Coverage: max. 6 m, recommended 3 m

• Location: ±60° horizontal, ±25° vertical

Digital Microphone Pod

•Range: 360°

•Response: 50 ÷ 14000 Hz

• Microphones: 3

• Mute button

• Up to 2 pods in a daisy-chain configuration

Built-in Camera

• Resolution: 752 x 582 pixels

• Presets: 122 presets

• H. angle of view: 6.6 to 65 degrees

• Zoom: 40x (10x optical + 4x digital)

Supported Monitor

• Format: PAL or NTSC or VGA

• Single, dual monitor, VGA

• PiTP function

• 16:9 support

• Dual Monitor Emulation

Network Interfaces

• B

ASIC VERSION

:

ISDN

3 BRI with integrated channel aggregator: 3 RJ-45

Ethernet

2-Port 10/100BASE-T full-duplex with integrated switch Ethernet: 2 RJ-45

• O

PTIONAL

User Interface

• Multilingual on-screen graphic user interface

• User selectable languages:

Italian, English, French, Spanish, German,

Portuguese, Norwegian, Swedish,

Russian, Czechoslovakian, Hungarian,

Chinese, Japanese, Korean

• Infrared remote control for full function control

• Contextual help

• Diagnostics and management functions

• Call progress monitoring

• Supports AMX™ or Crestron™

• Customizable Graphic User Interface

Multipoint Function

• Integrated MCU H.320, H.323 and SIP mixed

ISDN

3 BRI with integrated channel aggregator: 3 RJ-45 or 1 E1/T1 PRI with integrated channel aggregator: 1 RJ-45 or Leased networks

X.21/V.35/RS366/RS449: 44 pin Hi/Den or G.703: 1 RJ-45 mode

8 participants @ 256 kbps

6 participants @ 384 kbps

5 participants @ 512 kbps

4 participants @ 768 kbps

3 participants @ 1 Mbps

• Compatible with analog and mobile networks

• Video coding: H.261, H.263++

Audio/Video Interfaces

• Video inputs:

Main camera: Integrated Y/C,

• Audio inputs:

Connection

Aux. mic. accessible

Level Connector

2xPod mic. 360° Dig.

Mic

RJ-11 6/6

Stereo jack 3.5 mm

• Audio coding: G.711, G.722, G.722.1, G.728

• Chair control: H.243

• Dial-In/Dial-Out capabilities

• Continuous Presence

VCR Composite (RCA)

Doc. Cam. 1 S-video (Mini-DIN)

Doc. Cam. 2 S-video (Mini-DIN)

Doc. Cam. 3 Composite (RCA)

XGA In

• Video outputs:

DB 15 Hi/Den

• Encryption

• H.239 Dual-video from any site

Encryption

• AES encryption standard H.233, H.234, H.235

Monitor 1 Composite (RCA)

(Mini-DIN)

Web Management

All the configuration, call, diagnostics and management functions are accessible using the following web browsers:

Monitor 2 S-video (Mini-DIN)

with

VCR

XGA Out

Composite (RCA)

DB 15 Hi/Den

Microsoft® Internet Explorer™,

Netscape Navigator™

Remote Diagnostics and Management

Local Web Browser SNMP

Self test Yes Yes

Diagnostics Yes Yes

Configuration Yes

Call Yes

Yes

Yes

Yes

Yes

Yes

Yes Audio In

VCR

Line RCA

Line 2 RCA (L/R)

• Audio outputs

Connection Level Connector

Monitor 1

VCR

Line 2 RCA (L/R)

Line 2 RCA (L/R)

Auxiliary Interfaces

• Data RS232 Mini-DIN 8-pin

Error tracking Yes Yes

Integrated Presentation

• Supported applications:

Microsoft® PowerPoint®

• Multimedia support: T.120

Power Supply

• 100-240 Vac 50-60 Hz 1.5 A Max

Dimensions

• Diagnostics RS232 Mini-DIN 8-pin

• VISCA RS232

DB9

Mini-DIN 8-pin

• VEGA X5

Width: 54 cm (21.25”)

Height: 22.5 cm (8,85”)

• PC card supports Canon or Sony, aux PTZ camera

1 PCMCIA, type II for Wi-Fi card

Depth: 23 cm (9.05”)

82