IP Ports and Protocols used by H.323 Devices

IP Ports and Protocols used by H.323 Devices Overview: The purpose of this paper is to explain in greater detail the IP Ports and Protocols used by H.323 devices during Video Conferences. This is essential information if there are endpoints that are protected by a Firewall. It lists the Port and the Protocol used for various H.323 functions along with the H.323 devices that may use this Port. This paper also mentions using Virtual Private Networks (VPN), H.235 Encryption, H.460 Firewall/NAT Traversal and SIP Registrars. It is assumed that the reader has a general knowledge of video conferencing systems and the standards involved. However, the following technical papers are available to provide more information on these topics: How do I choose a Video Conferencing system? Video Conferencing Standards and Terminology. H.323 Terminals, Gatekeepers, Gateways & MCUs. H.221 Framing used in ISDN Conferences. Cost Efficient ISDN Conferencing, including Multipoint Access. H.323 Dial Plan and Service Codes used by Gatekeepers etc. Firewall and Proxy Server: A firewall is a set of security mechanisms that an organisation implements to prevent unsecured access from the outside world to its internal network. An organisation with its own internal network (intranet) whose users also requires access to the Internet, usually installs a firewall to prevent unauthorised Internet users from accessing its internal network. Firewalls usually work by blocking access of certain network protocols to specific ports. The firewall can also control what Internet resources the organisations users may access. The firewall is generally installed at a specific location in much a manner that no incoming requests can by-pass it and gain access to the internal network. A Proxy Server acts as an intermediary server that makes network requests on behalf of internal users, so that organisations can ensure security, control and caching services. Proxy Servers are now equipping themselves with security features such as Network Address Translation (NAT). The NAT or Proxy Server works on the concept that there is an outside world (Internet) and an inside world (intranet) and it separates and protects the intranet from the Internet. Firewalls now usually include a NAT capability. Certainly, most ADSL Routers have a built-in Firewall and NAT functionality that can be setup to work with H.323 video conferencing systems. Network Address Translation (NAT): NAT helps protect the intranet from exposure to unwanted traffic by providing one single external address to remote users. NAT uses a system of local and external addresses to hide an intranet user from other networks. NAT translates the local intranet user s address to an external address, which is then used to identify the local user to remote users. Therefore, remote users use this external address to call the local user, without knowing its actual local address. The latest releases of most vendors software including Polycom, LIfeSize and ClearOne all support NAT and allow you to specify the external IP address of the selected endpoint. IP Ports and Protocols used by H.323 & SIP Devices Port Type Description H.323 Client H.323 Gatekeeper H.323 MCU 80 Static TCP HTTP Web Interface x x SIP Client SIP Registrar

389 Static TCP LDAP x x 443 Static TCP HTTPS & Port Tunnelling x x 1718 Static UDP Gatekeeper Discovery x x 1719 Static UDP Gatekeeper RAS x x 1720 Static TCP H.323 Call Setup x x x 2253-2263 TCP Sony endpoints x 2326-2485 UDP Cisco/Tandberg endpoints x x 3230-3235 TCP Polycom endpoints x 3230-3280 UDP Polycom endpoints x x 5001 TCP & UDP Polycom PPCIP client x 5004-6004 TCP & UDP ClearOne endpoints x x 5060 TCP & UDP SIP endpoints x x 5061 TCP SIP TLS x x 5555-5574 TCP Cisco/Tandberg endpoints x 6000-6006 TCP & UDP Librestream endpoints x 8080 Static TCP HTTP Server Push (optional) 9400-9406 TCP & UDP AudiSoft endpoints x x 9800-9806 TCP AudiSoft Server/Gateway x 9810-9822 UDP AudiSoft Server/Gateway x 15100 Static TCP NetPoint Q.931 Call x (MXM) 15101 Static TCP NetPoint Default x (MXM) 15102 Static UDP NetPoint Default x (MXM) 22136 Static TCP MXM endpoint administration x x (MXM) 26505 Static TCP MXM remote admin login x (MXM) 49152-49239 UDP Sony endpoints x x 58024-58120 UDP InGate SIP media x x 60000-64999 TCP & UDP LifeSize endpoints x x 1024-65535 Dynamic TCP H.245 (Call Parameters) x x 1024-65535 Dynamic UDP RTP (Video Stream Data) x x 1024-65535 Dynamic UDP RTP (Audio Stream Data) x x 1024-65535 Dynamic UDP RTCP (Control Information) x x x General H.323 and SIP Firewall issues and Protocols: The table above shows that H.323 and SIP require the use of specific static ports as well as a number of dynamic ports within the range 1024-65535. For the H.323 and SIP to cross a firewall, the specific static ports and all ports within the dynamic range must be opened for all traffic. This clearly causes a security issue that could render a firewall ineffective. There are several standards based transport protocols used within H.323 and SIP Conferencing. Generally, each configures the data into packets, with each packet having a 'header' that identifies its contents. The protocol used is usually determined by the need to have reliable or unreliable communications. Transmission

Control Protocol (TCP) is a reliable protocol designed for transmitting alphanumeric data; it can stop and correct itself when data is lost. This protocol is used to guarantee sequenced, error-free transmission, but its very nature can cause delays and reduced throughput. This can be annoying, especially with audio. User Datagram Protocol (UDP) within the IP stack, is by contrast, an unreliable protocol in which data is lost in preference to maintaining the flow. Real-Time Protocol (RTP) was developed to handle streaming audio and video and uses IP Multicast. RTP is a derivative of UDP in which a time-stamp and sequence number is added to the packet header. This extra information allows the receiving client to re-order out of sequence packets, discard duplicates and synchronise audio and video after an initial buffering period. Real-Time Control Protocol (RTCP) is used to control RTP. Reliable transport is required for control signals and data because they must be received in the proper order and cannot be lost. Consequently, TCP is used with the H.245 control channel and call control. Unreliable UDP is used for RAS and H.225 call signalling as well as audio and video streams were time sensitive issues become a priority. However, H.323 and SIP are not the same and should not be confused. They might share similar codecs such as H.264 video and G.722.1C audio; be supported on the same video conferencing endpoints and use the same IP ports for media, but they are fundamentally different protocols that use different network and calling procedures (H.323 uses TCP on port 1720 whereas SIP uses UDP or TCP on port 5060 or TCP for TLS on port 5061) that require different Firewall Traversal solutions. H.323 endpoints use H.460 Firewall/NAT Traversal whilst SIP endpoints use a SIP Registrar to cross firewalls (see below for more details). H.323 and Intelligent Firewalls: Q.931 is the call signalling protocol used in setting-up and terminating a call. H.323 uses TCP on port 1720 for Q.931 and negotiates which dynamic port range to use between the endpoints for H.225 call signalling (UDP), H.245 call control parameters (TCP), data, audio and video (UDP). Clearly, to open all ports within the dynamic range would cause security issues, so the firewall must be able to allow H.323 related traffic through on an intelligent basis. Some special H.323 intelligent firewall can do this by snooping on the control channel to determine which dynamic ports are being used and then only allowing these ports to pass traffic when the control channel is busy. However, most firewalls that state they support H.323 just open port 1720 and you have to make additional rules to open the endpoints specific TCP and UDP port ranges. The latest releases of Polycom, LIfeSize and ClearOne endpoint software all allow you to specify the dynamic port ranges to be used by TCP and UDP. This allows you to reduce the number of ports that need to be open, and hence the security risk. Furthermore, these latest versions support 'Port Pinholing', so that inbound data can be returned using the same port as the initiating outbound call. They also support H.460 Firewall/NAT Traversal (see below). Using NAT to Enhance Security: When H.323 terminals communicate directly with each other, they must have direct access to each other s IP address. But this exposes key network information to a potential attacker. By locating the endpoints behind a firewall only the public addresses are exposed, keeping the majority of address information hidden. However, conferencing successfully through a firewall depends upon how well the firewall is capable of dealing with the complexities of the H.323 protocol. If the firewall cannot provide dynamic access control based on looking at the control channel status, then NAT inside the firewall can be used to map an endpoints internal non-routable IP address a public IP address and hence provide access control. When you specify that an endpoint should use NAT, it embeds the outside world IP address of the firewall into its IP header. This is how the far end system knows the outside world IP address to return the call. The endpoint cannot use its internal IP address as this is non-routable and you want it hidden. On receiving

inbound traffic, the firewall uses NAT to forward to the traffic to the endpoint. But using NAT can cause issues if you also want to connect over a VPN (see below). NAT by itself with H.323 endpoints has a major limitation. By definition, every H.323 endpoint uses port 1720 TCP to initiate a call; but you can only NAT one internal address to one public address, so to use NAT by itself, you would need a public IP address for every H.323 endpoint; which is clearly impractical if you want to deploy several video conferencing devices. This is where an H.323 Gatekeeper can be used. Since only the Gatekeeper, via RAS on port 1719 and Call Setup on port 1720 are the only systems that interact with H.323 device outside the firewall, access rules in the firewall can be set to pass traffic destined for the Gatekeeper or endpoint. But using an H.323 Gatekeeper by itself does not provide a complete, secure solution. Ideally you need an H.460 Firewall/NAT Traversal solution that incorporates an H.323 Gatekeeper. (see below) Using VPN or H.235 Encryption: Creating a Virtual Private Network (VPN) by definition provides you with your own private network, so as long as you stay within this network, you do not need any firewalls. However, this is not always possible and you may have a necessity to conference with others outside your own VPN. This can cause a problem as using NAT is typically incompatible with routers setup for a VPN. To call an H.323 endpoint over a VPN, you call its IP address, which is usually on a different internal network segment. With NAT enabled, the H.323 endpoint has the external IP address of the firewall in its IP header. When you make a call over the VPN, this external address is still in the IP header, so the far end system on the VPN will try to return the call to the external address via the outside world and not over the VPN. The call will fail, typically with no audio and video. It will work to endpoints on the same internal network segment, but not to endpoints on different segments. Disabling NAT on the endpoint will allow calls over the VPN, but then you cannot call outside world endpoints! The solution is to use an H.460 Firewall/NAT Traversal device (see below). When configuring the VPN, be wary of using a long key and hence applying too much encryption as this can cause an unacceptable delay in the transmission between sites and impact the overall efficiency of the video conference. Similarly, enabling H.235 compliant AES Encryption that is supported by most endpoints can have an impact on the overall efficiency of the conference, especially if low bandwidths are used. H.460 Firewall/NAT Traversal: As mentioned above, when H.323 endpoints are set to use NAT, the outside world IP address of the firewall is embedded in their IP header. This is done so that the far end system knows where to return the call. This is part of complying with the H.323 protocol. However, this typically causes a problem if have several H.323 endpoints or when you then want to call another H.323 endpoint over a VPN. The solution is to implement H.460 Firewall/NAT Traversal or Session Border Controller (SBC). These typically consist of a two boxes; one outside the firewall in the public domain and the other behind the firewall on the internal network, which also incorporates an H.323 Gatekeeper function. The ClearOne Collaborate NetPoint outside the firewall works in-conjunction with ClearOne's Collaborate VCB behind the firewall to provide a two box H.460 Firewall/NAT Traversal solution with Collaborate VCB including Collaborate Central as its embedded H.323 Gatekeeper.

SIP Registrar: Similarly, Polycom's RealPresence Access Director (RPAD) outside the firewall works in-conjunction with their Distributed Media Application (DMA) behind the firewall to provide an H.460 Firewall/NAT Traversal solution with DMA also providing the H.323 Gatekeeper function. The Polycom DMA can also act as a Gateway and transcode H.323 <> SIP calls. Most vendors have now implemented H.460 support into their latest endpoint software revisions. H.323 endpoints behind the firewall then do not use NAT; they simply register their H.323 ID with the Gatekeeper using their current internally allocated IP address. H.323 endpoints behind the firewall can then call each other using their unique H.323 ID, alias or E.164 number and it does not matter if they are on a VPN or not. External (public) H.323 endpoints would initiate a conference to an endpoint behind the firewall by calling the public IP address of the firewall solution along with the specific endpoints H.323 ID, alias or E.164 number. Alternatively, some H.323 endpoints such as the Sony PCS-XG80 have two network interfaces, one that supports NAT for connecting to the outside world and the other that doesn't for connecting internally. SIP endpoints generally register using a secure login (User Name & Password) with a SIP Registrar. This provides them with a unique URI that is then used to call the SIP endpoint. For example, a Polycom HDX6000 might be allocated a URI of hdx6000@sip.polycom.net which could then be called by other SIP endpoints to initiate a conference. The InGate SIParator models are SIP Registrars that provide a secure SIP firewall traversal solution. They have several network interfaces and would typically reside outside the firewall or in the firewall's DMZ. The public network interface would be allocated a public IP address and any internal network interfaces would be allocated a non-routable IP address. Each User ID also defines which network interface it will use at login, hence securely separating URI and devices on either side of the firewall. Only SIP traffic is routed through

the InGate SIParator and blocked by the firewall. Alternatively, you may use a hosted SIP Registrar from a service provider. The Polycom Distributed Media Application (DMA) can also act as a SIP Registrar and when used inconjunction with a Polycom RealPresence Access Director (RPAD), can provide a SIP Firewall Traversal solution. SIP traffic is normally routed through the SIP Registrar, so it is this Registrar that determines which media ports will be used along with which port and protocol is used for call signalling, setup and registration; 5060 UDP, 5060 TCP or if using TLS (Transport Layer Security), 5061 TCP.