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 business decision. A well established data network might have an easier time of integrating telephony applications into the existing network.

REDCOM's TRANSip technology converges existing TDM components with IP technologies to gain the maximum benefits of each. TRANSip supports various signaling protocols (including SS7, C7, PRI, BRI, MF, R2, GR-303 and V5.2). Different trunk interfaces including T1, E1, E&M and ring-downs are supported by TRANSip to make convergence practical. TRANSip also supports T.38 for fax communications and V.150.1 for modem communications. This is critical for customers who still rely on these communications methods.

Bandwidth

The introduction of VoIP in the data network creates the capability of using a single network to transport both data and voice. Nevertheless, this brings additional load on the existing data network. Bandwidth usage needs to be monitored closely to make sure that the network does not exceed its limit.

REDCOM TRANSip supports various codecs to allow the network operator to choose the desired compression. These codecs include: G.711A&mu, G.723.1H&L, G.726, and G.729A&B. TRANSip also allows the sizing of its voice packets in the increments of 5 ms (5 to 30 ms) to allow the network operators to configure the network based on their needs.

Quality of Service (QoS)

Without support for QoS in the general IP infrastructure, VoIP packets can be delayed or lost to such an extent that communication is not acceptable. There may be temporary overloads due to concurrent massive downloads of pictures or movies which causes VoIP packets to be severely delayed by the routers. This happens because routers without QoS features, do not distinguish VoIP packets from any other in the network. There are a number of different QoS methodologies in use today including DiffServ and IntServ.

VoIP packets representing voice, although occupying a relatively small amount of bandwidth, must be transported with minimal delay and minimal loss. By contrast, other packets, such as those carrying email, can be delayed or even lost (they will be automatically retransmitted if lost).

TRANSip supports the widely popular DiffServ, which tags packets at layer 3 in the protocol stack to indicate that they are to receive expe-dited 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 net-work 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 Concerns

Firewalls, whose main purpose is to restrict access within a network, 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.

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 address for private networks. These addresses are never assigned within the public Internet.

Network Address Translation (NAT) was introduced to assign internal IPs to the end terminals and allow the usage of external IPs 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 corporate LAN.

As you might expect, NAT also has to be aware of protocols which embed IP addresses and socket numbers in their messages. Like fire-walls, NAT servers can wreak havoc on SIP VoIP calls by not translating essential parts of SIP headers containing IP addresses and sockets. Both firewalls and NAT are not known as "SIP friendly", and can present challenges when deploying VoIP.

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.