Existing TDM Components Bandwidth Quality of Service Firewall & Security Concerns
Network Address Translation

Existing TDM Components

The importance of the existing network elements varies based upon their usability and the investment that has been made to acquire these services. In a TDM oriented network, a sudden jump to IP technology may prove to be a risky decision. A well established data network might have an easier time of integrating telephony applications into the existing network.

Alternately, there are cases where it may be cost effective to build your network exclusively with IP at the core, such as adding a new site or building a new network from the ground up.

With TRANSip, REDCOM can offer a solution for either of these two needs.

The HDX•C and SLICE 2100 converge existing TDM components with IP technologies to gain the maximum benefits of each. These platforms support various signaling protocols (including SS7, C7, ISDN PRI, ISDN BRI, MF, R2, GR-303 and V5.2). Different trunk interfaces including T1, E1, E&M and ring-downs are supported to make convergence practical. These platforms also support T.38 for fax over IP communications and V.150.1 for modem over IP communications. This is critical for secure calling and for users who still rely on these communications methods.

For installations that do not require any TDM or analog connectivity, REDCOM offers the SLICE IP platform. The SLICE IP platform delivers robust lineside and trunking functionality with the same administrative interface and TRANSip engine as the HDX•C and SLICE 2100. The SLICE IP offers the reliability that REDCOM has built their reputation on, but is designed without any TDM or analog interfaces. This makes the SLICE IP a cost-effective solution for applications without legacy equipment. 

Bandwidth

The introduction of VoIP in the data network creates the capability of using a single network to transport both data and voice. This brings additional load on an existing data network. Bandwidth usage needs to be monitored closely to make sure that users do not experience excessive network congestion.

Whether you are adding VoIP to an existing network, or building a new network, VoIP bandwidth requirements must be carefully considered. TRANSip offers multiple codec options (such as G.711A&mu, G.723.1H&L, G.726, and G.729A&B, iLBC) to help compress traffic (lower bandwidth) where required. TRANSip offers many other bandwidth-saving features such as:

• Codecs can be configured on a per-trunk basis
• Codecs can be defined on a per-user basis
• A trunk destination can be configured with multiple codecs, dynamically selected based on call volume
• Voice Activity Detection with Silence Suppression and Comfort Noise Generation
• Adjustable Packetization Rates per user and trunk

Quality of Service (QoS)

Data networks frequently experience conditions such as delay, jitter (variance in delay) and packet loss. These conditions are caused by network congestion (inadequate bandwidth), may be due to the type of circuit used, such as satellite circuits (high delay), or could be caused by instability in a given circuit.

Typical data network traffic such as web or email traffic is very tolerant of these conditions, and frequently these conditions are transparent to an end user. Such is not the case with VoIP. Voice traffic on an IP network (VoIP traffic) is very sensitive to delay, jitter and packet loss on a data network, and even moderate amounts of these conditions will make VoIP performance unacceptable for an end user.

Quality of Service (QoS) offers a potential solution to this problem. QoS defines a way to ensure that specific types of traffic receive specific treatment on the data network. There are a number of different QoS methodologies in use today including DiffServ and IntServ.

TRANSip supports the widely popular DiffServ, which tags packets at layer 3 in the protocol stack to indicate that they are to receive expedited handling.  Although private networks may support QoS methods, the public Internet, with a few local exceptions, does not.  Note that the QoS tagging is done at the end points (i.e. VoIP phones and TRANSip), but the IP infrastructure is what uses the information.  If the network does not support QoS, this tagging is ignored and QoS may not be provided. The advantage of DiffServ is its ability to allow the call to be processed even without QoS treatment.

Firewall and Security Concerns

Firewalls, whose main purpose is to protect a network from potential threats, can be set up to look for connect attempts to well-known ports and deny those attempts that are not legitimate. Using what is known as “deep packet inspection”, a firewall can look up and down the protocol stack to see if a received packet is “well-behaved”. Firewalls are also used to deny access to any sockets not explicitly opened as a result of legitimate activity. For example, if a Telnet session is allowed by a firewall, then the firewall will note and “remember” the cloned socket that the session is using, and the firewall will only allow packets to be passed on that socket until the session is closed or a timeout occurs.

A firewall must be aware of all the protocols it monitors so that it will know what is going on, and keep open only the minimum number of specific sockets required. Some new protocols (like SIP) have IP addresses and port (socket) numbers buried deep within their messages, and if a firewall is not “SIP aware”, it will fail to recognize these and either block valid SIP messages, or require the administrator to waive checking for SIP traffic.

A Session Border Controller (SBC) or Edge Boundary Controller (EBC) is a third-party product designed specifically to allow large volumes of VoIP (and other media) traffic to traverse network boundaries reliably, while protecting the network from potential threats. SBCs and EBCs are frequently used in addition to a Firewall to provide network security on VoIP-enabled networks.

TRANSip offers an additional layer of security for VoIP traffic with the ability to encrypt calls. Secure Real-Time Transport Protocol (SRTP) is available to encrypt the audio stream of VoIP calls, and Transport Layer Security (TLS) is available to encrypt the SIP call signaling to deter spoofing and other threats.

Network Address Translation (NAT)

As the number of available IPv4 addresses started to deplete, a temporary alternative solution was proposed to slow the usage of publicly addressable IP addresses. IANA (Internet Assigned Numbers Authority) has reserved a special set of IP addresses for private networks.  These addresses are never assigned within the public Internet.

Network Address Translation (NAT) was introduced to assign internal IP addresses to the end terminals and allow the usage of external IP addresses when the internal terminals access the outside world. The NAT process changes both the IP address and the port number that are located in the IP headers. However, this causes problems for SIP clients/servers because like firewalls, NAT servers have to recognize IP addresses and socket numbers buried deep in the protocols.  Failure to do this correctly and completely will result in a network which is incompatible with SIP VoIP.  NAT is required in most networks, especially ones which access the public Internet from within a private LAN. 

SBCs and EBCs, discussed above, are frequently used as a solution to difficulties found with NAT. SBCs and EBCs are SIP-aware and will successfully perform NAT for SIP traffic.

As shown above, deploying VoIP requires in-depth knowledge of TDM and IP networking. REDCOM’s telecommunications experts are well-versed in TDM and IP networking subjects, and can assist you with network design and offer guidance in providing the right services for your users.