IP Technology Suite
TRANSip is REDCOM’s IP telephony technology suite, available on the HDX and SLICE® product family. TRANSip provides an easily configurable, fully integrated VoIP solution which seamlessly integrates next-generation VoIP (SIP) networks with legacy PSTN / TDM networks, allowing you to leverage your existing network. TRANSip supports IP to IP, IP to TDM, and TDM to TDM connections.
Product Features by Platform
|HDX||SLICE® 2100™||SLICE® 2100™ Micro||SLICE® IP||SLICE® IP Micro|
|VoIP Call Control|
|IP Subscriber Database|
|T.38 and V.150.1|
|Media Gateway Controller||
|Maximum Registered IP Subscribers||3,000 per shelf||2,000 per unit||2,000 per unit||3,000 per unit||3,000 per unit|
|Scalable/Stackable||Up to 32 shelves||Up to 3 units||—||Up to 3 units||—|
TRANSip Functions and IMS
IP Multimedia Subsystem (IMS) is a standards-based architecture which delivers IP-based media (voice, video, etc.) using the Session Initiation Protocol (SIP). Examples of key IMS functions provided by TRANSip include:
Home Subscriber Server (HSS)
Profile information (name, extension, feature settings, etc.) for IP and Access subscribers on a TRANSip-enabled system is embedded in the system database. TRANSip also supports authorization and authentication of IP users.
Call Session Control Function (CSCF)
TRANSip’s powerful call controller can support thousands of concurrent calls. TRANSip CSCF functions include:
- Subscriber Authentication
- Trunk Authentication
- TLS encryption
- QoS Marking
- Call Detail Record (CDR) generation
- Call Routing
Media Gateway Control Function (MGCF)
TRANSip provides fully integrated control of the Media Gateway (MGF) and seamlessly merges next-generation VoIP (SIP) networks with legacy PSTN / TDM networks, all in one device.
Media Gateway Function (MGF)
Both the HDX and SLICE 2100 (when equipped with TRANSip) operate as a powerful VoIP gateway. On the VoIP side, many codecs are supported including G.711 A-law, G.711 μ-law, G.723.1H&L, G.726 (16, 24, 32, 40 kb/s), G.729 A&B, iLBC, as well as T.38 for Fax over IP and V.150.1 for Modem over IP. On the TDM and analog side, a wide variety of interfaces are available, including E1, T1, E&M, Ground Start and Loop Start trunks, Magneto, and Radio interfaces with support for many industry standard protocols including ISDN PRI, IDSN BRI, SS7, C7, SS5, DTMF, MF, R2, GR-303 and V5.2.
Breakout Gateway Control Function (BGCF)
TRANSip performs call routing based on telephone number. Outbound calls can be routed via VoIP to another network / system, or via TDM (using MGCF functionality).
Multimedia Resource Function (MRF)
TRANSip offers extensive conferencing capabilities; from simple three-way-calling to extreme multi-technology conferencing with hundreds of conferees. TRANSip offers customizable PSTN tones. In addition, TRANSip supports both pre-recorded announcement tokens, and custom recorded announcements.
TRANSip Enhanced Services
SIP / AS-SIP
TRANSip supports the industry standard Session Initiation Protocol (SIP) and the Assured Services Session Initiation Protocol (AS-SIP).
Lawful Intercept (HDX and SLICE 2100 only)
TRANSip’s integrated design provides lawful intercept, third party monitoring, recording, and tracing for both IP subscribers (US J-STD-025-B) and legacy subscribers (CALEA compliant).
Number and Feature Portability
TRANSip’s unified design creates an easy transition to the IP world, allowing subscribers to retain or transfer their numbers and features.
TRANSip collects and processes IP and legacy call detail records to support accurate account and billing management.
TRANSip incorporates flexible IP and PSTN trunking schemes (including alternate routing and emergency rerouting) that maximize network efficiency and ensures successful call completion.
TDM and IP Telephony Comparison
In a TDM (circuit-switched) call setting, there is an assigned connection between the two endpoints of the call. The entire bandwidth assigned to the call is maintained for the exclusive use of the call for the duration of that call.
In the IP world, packet switching is used and there is no dedicated bandwidth between the two endpoints. Data is sent on a voice-packet by voice-packet basis. Between the individual voice packets, the IP network bandwidth is continually reassigned for the purpose of carrying all IP network traffic including voice.
In the TDM world, all or most of the “intelligence” resides at the network level and switching equipment does more than just switching. All of the end terminals need the support of this central unit.
In IP Telephony, a (SIP-based VoIP) telephone instrument, unlike its TDM counterpart, can perform simple call functions including call setup with another VoIP telephone without the help of any external controller. The two VoIP phones simply exchange messaging to coordinate their own call through the IP network. However, their capabilities in this respect are limited. Commonly, the VoIP telephone relies on a remote (SIP) Call Controller to orchestrate call setup and feature management. In addition to gaining access to richer and more standardized feature capabilities, this shifts the burden of understanding the initial phone setup requirements from the VoIP instrument user to a system level manager.
Ports and Timeslots in TRANSip
Each active VoIP call leg (channel) occupies a port. On the HDX and SLICE 2100, TDM and analog interfaces (i.e. line boards, trunk boards, service boards) occupy a port. The number of occupied ports is directly related to the number of circuits that would be used. For example, a line board with 8 circuits occupies 8 ports from the available pool of ports in TRANSip.
In addition to the ports, each interface that is connected to TRANSip may occupy a timeslot. Timeslots are required for making connections with the TDM services and line circuits, trunk circuits or even customized announcements. There may be situations where certain timeslots can be shared across certain circuits. For example, 16 line circuits may share 10 timeslots meaning that only 10 line circuits have service at any given time.
Please note that the term ‘port’ used in relation to REDCOM system resources and TRANSip is unrelated to the term ‘port’ used in IP net-working (for example, Telnet uses TCP port 23, SIP uses UDP port 5060).
TRANSip consists of:
- TRANSip software located in the controller board
- IP trunking capability
- Subscriber Registrar
Optional blocks of 100 IP registrants can be purchased (up to 3000 subscribers per shelf)
- TRANSip Media Services Circuit (MSC) board for the HDX
Equivalent functionality is embedded in SLICE 2100 and SLICE IP
- TRANSip Media Gateway Functionality and optional T.38 / V.150.1 engines for fax and modem relay
- Call Progress Tones
Common resources in the HDX and SLICE 2100 consist of:
- IP Registrants
There are 1000 ports in the HDX and SLICE 2100. There are 512 timeslots in each HDX shelf and SLICE 2100 unit. The amount of timeslots per HDX shelf in a system with more than 8 shelves will change based on the total number of shelves.
There are up to 3000 IP registrants in each HDX shelf or SLICE IP and up to 2000 in a SLICE 2100 unit. These registrants do not use any ports unless they are active, meaning in a call state. These IP registrants only use timeslots if they need to access the voice related services such as access to TDM or custom announcements offered by HDX or SLICE 2100.
The timeslots and ports that are used for IP calls are located in the MSC board. One MSC board can have up to 128 timeslots. Additional boards should be added to the system if more timeslots (i.e. IP to TDM conversions) are needed.
Below are two examples to further clarify the shared resources in the HDX and SLICE 2100.
IP to IP Call
In this example, an IP phone calls another IP phone using HDX as the call controller. These phones are registered in the HDX, thus they occupy 2 of the possible 1000 entries in this HDX shelf. They do not occupy any port until they call each other. The moment they call each other, each of them occupies a port on the MSC board. However, since there is no IP to TDM conversion, no timeslots are used.
Total resources used in this example:
- Ports = 2 (on the MSC Board during the call)
- Timeslots = 0 (no TDM connection)
- IP Registrants = 2 (each IP phone is registered to the HDX)
IP to TDM Call
In this example, an IP phone calls an analog phone using TRANSip HDX as the call controller and media gateway. The IP phone is registered to TRANSip and occupies 1 of the possible 1000 entries in the HDX shelf. The moment the IP phone calls the analog phone or vice versa, a timeslot is used in the MSC board for media gateway functionality.
The total resources used in this example:
- Ports = 2 (1 port on the MSC board and 1 port for the analog line)
- Timeslots = 2 (1 timeslot on the MSC board and 1 timeslot on the analog line)
- IP Registrant = 1 (only 1 IP phone is registered to the HDX)
The resource planning might be complicated due to the number of variants. At REDCOM, we will be more than happy to help with resource planning if our customers have any questions or concerns.
IP User Registration
TDM circuit-switched phones and other TDM equipment are physically connected to the HDX or SLICE 2100. This gives some physical assurance that the device is authorized.
An IP telephone is not connected physically to a TRANSip-equipped system. Rather, it uses the data network to send a SIP message to the system to be “registered”. Because IP phones are not physically connected to the TRANSip’s SIP Call Controller, it must ensure the IP phone is, indeed, an authorized device, and not one that is masquerading for the purpose of unauthorized use of TRANSip’s services. This is accomplished by programming the phone with the IPv4 or IPv6 address of the TRANSip equipped system, specifying a SIP username, and assigning an optional pre-arranged password. The SIP username and password are exchanged and validated as part of the registration process. Registration typically occurs when the phone is powered up, and then is repeated at scheduled intervals.
Once an IP phone is successfully registered, TRANSip’s SIP Call Controller may dispatch calls to it and accept requests for service from it. When the IP phone is “idle”, as long as the registration has not expired, TRANSip remains aware of the phone, but it does not occupy any ports or timeslots on the system.
In recent years, the number of users on the Internet has increased at a dramatic rate with more and more applications deployed in the data world and no end in sight. The intent of one of these applications was to carry voice over a data network; this eventually took the name of Voice over Internet Protocol (VoIP). The initial VoIP deployments had two functions: to convert voice from/to data packets and establish a protocol to get the phones in contact with each other, similar to the switching concept in the TDM world.
As IP deployment continued its explosive growth, VoIP became increasingly attractive, and the need for standards became obvious. Without standards there was no hope of interoperability and user features were limited to the basic Plain-Old-Telephone-Service (POTS). Also, administration of larger networks and security would become a nightmare.
One of the first efforts at standardization resulted in the H.323 standard. H.323 is really an umbrella specification encompassing many additional specifications. The “H.xxx” signifies that this specification comes from ITU-T (formally CCITT). H.323 may be efficient in terms of memory and CPU usage, but it is difficult for programmers to work with, and difficult to expand and develop. REDCOM, and the VoIP industry in general, have embraced SIP as the best protocol for converged communication going forward based in ease of use, human readability and SIP’s ability to expand.
Session Initiation Protocol (SIP), in contrast to H.323, represents a complete break with the tradition of TDM telephony protocols as it comes from the data world. SIP is not a specific protocol for telephony. Rather, SIP is a generalized protocol for allowing what are called “user agent” clients and servers to associate, and when communication is desired, allow them to exchange capabilities, make media choices and establish communication sessions between them. SIP can mediate a session involving a one-way transmission of a full-length movie, a multi-party video conference, a telephone call, or an Instant Message transmission. SIP provides a set of methods and a suggested way to use them to create (in the case of VoIP) call flows for most of the commonly used features we are familiar with in the TDM world.
There are almost daily improvements being made in the SIP implementations as more and more vendors, including REDCOM, follow SIP standards. This increases interoperability between different vendor equipment.
As the convergence of TDM and IP networks continue, end users do not necessarily want to abandon their traditional telephony features and needlessly throw away invested dollars.
TRANSip’s integrated architecture allows the migration of many rich traditional TDM features to standard SIP phones, but certain specific features require support from the phone manufacturer (i.e. support for hook-flash). The following is a partial list of traditional TDM features that are supported by TRANSip.
Selected Features Available to SIP phones
Lineside Features: Users of SIP phones desire the same lineside features that have been available on traditional TDM and analog telephones. At the same time, VoIP offers new functionality that can deliver new features which are not available on traditional telephone systems. The Internet Engineering Task Force (IETF) has proposed SIPPING standards as an industry-standard way to offer lineside features to SIP phones. TRANSip embraces SIPPING functionality for lineside features (such as call transfer, call hold, and 3-way calling).
Line Groups: SIP phones, along with analog and digital phones, can be put in a line group to benefit from group call pick-up, broadcast ringing, speed dial, and many other features.
Station Number Playback: SIP phone users dial a code and receive an announcement that relays the number of the phone they are dialing from.
Caller ID and Name: Caller ID and name features available to the analog and digital phones are available to the SIP phones along with the ability to choose not sending Caller ID and name, as well as blocking calls based on Caller ID.
Announcements: Common announcements can be sent to analog, digital and even SIP phones. This ensures common announcements for all of the users.
Call Detail Records: Traditional call detail records (CDR) that were logged for billing or quality assurance reasons are also available for SIP phones. TRANSip provides records including callED number, callING number, call time, call duration and other detailed information for SIP phones as well as analog and ISDN phones.
Compatible SIP Phones
In the traditional TDM world, the phone or the end station was easily compatible with the existing phone lines. The backward compatibility is so strong that an operational phone from the early 20th Century can be connected to the existing telephone network.
As the intelligence shifted to the end terminals in the IP world, the phones started to deploy new capabilities. However there are still interoperability issues as the phone vendors may deploy proprietary signaling protocols. In order to ease the concern of its customers, REDCOM periodically tests various phones in the industry.
In the traditional TDM world, subscriber access was relatively straightforward. Phones would be wired to a switch at a central location. Compatibility between traditional switching platforms and traditional analog telephones was generally strong, thanks to the maturity of the technology.
As traditional telephony systems grew in size, it was realized that offering many lines at a central location could become very expensive. This often involved a significant investment in cable plant and switching hardware. A new technology was developed to aggregate lineside connectivity at a location closer to subscribers, to reduce investment in cabling to subscribers. This new technology (Digital Loop Carrier / DLC or Remote) would handle lineside functionality but would still rely upon a central switching platform for call control. Cabling between the DLC / Remote (T1/E1) was significantly reduced compared to individual cable pairs for each subscriber, and could be copper or fiber. GR-303 and V5.2 are examples of industry-standard protocols used to aggregate subscribers on a DLC / Remote, and are both supported by REDCOM.
Over time, consumer demand for high-speed internet service grew significantly. A new technology, Digital Subscriber Line (DSL) was developed to allow high-speed data service over existing telephone lines. This was often provided by a DSL Access Multiplier (DSLAM) located with the central switching platform. As demand for DSL grew, DLC / Remote manufacturers began to integrate DSL functionality into their products, thus eliminating the need for a separate DSLAM. These products are known as Multi-Service Access Node/Platform (MSAN / MSAP) or Broadband Loop Carrier (BLC).
Most manufacturers of MSAN / MSAPs, BLCs, DLCs and Remotes now offer support for VoIP connectivity between the Central switching platform and the Remote. VoIP introduces both benefits and challenges when it comes to access technology. VoIP enabled remotes require only an IP path from the central switching location. Efficiencies can be gained by consolidating both voice and data on to one link, however there are many factors that must be considered in advance, such as: switch support for VoIP remotes, bandwidth, QoS and latency.
REDCOM brings experience in both IP networking and telephony to help build the proper solution to meet your needs. REDCOM is routinely testing new access equipment including IP Phones, Analog Telephone Adapters (ATAs), and Remotes for compatibility with TRANSip.
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.
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 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 communications and V.150.1 for modem communications. This is critical for customers who still rely on these communications methods.
For installations that do not require any TDM or analog connectivity, REDCOM offers the SLICE IP and the SLICE IP Micro. These platforms delivers robust lineside and trunking functionality with the same administrative interface and TRANSip engine as the HDX and SLICE 2100. The SLICE IP family offers the reliability that REDCOM has built their reputation on, but is designed without any TDM or analog interfaces. This makes the SLICE IP family a cost-effective solution for applications without legacy equipment.
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 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) 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 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 address 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 corporate LAN.
SBCs, discussed above, are frequently used as a solution to difficulties found with NAT. SBCs 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.
REDCOM’s High Density Exchange (HDX) is a powerful telecommunications system designed for a wide variety of switching applications ranging from analog to digital to IP communications. The HDX shares a common approach and a common hardware set with other REDCOM switching products. This hardware set is called the Modular Switching Unit, or MSU.
One or more MSUs comprise a complete system. Though all MSUs operate together as a single system, each is capable of operating independently. Thus, the loss of a single (or even multiple) MSU elements does not constitute a total failure of the system. All remaining MSUs will continue to operate and communicate normally. This distributed architecture is one of the “secrets” behind REDCOM’s reliable telecom systems.
In order to equip your existing HDX system with TRANSip capability, two actions need to be performed (assuming the HDX has V3.0 software or higher):
- Enable TRANSip
- Add the MSC board(s) to the system
Additional features like T.38 and V.150.1 may be enabled based on the customer needs. Once the desired features are turned on, your HDX system is powered by TRANSip.
The MSU architecture of REDCOM’s HDX allows the addition of more MSC boards or even shelves based on application requirements. Depending on selected configuration and traffic, each MSC board can take up to 128 timeslots that will be used for VoIP conversions as well as MoIP, FoIP, customized tones for SIP phones and other features. More MSC boards can be added to the system if more capacity is required.
Controller and MSC Board
TRANSip HDX’s Controller board acts as a call controller and a media gateway controller. All of the call translator database information is stored in the Controller board and the call processing is handled with this board as well. The Controller board communicates directly with the MSC board to allow TDM to IP conversions.
The MSC board provides IP to TDM conversions (media gateway functionality) as well as helping the controller to keep track of the IP call records. This fully integrated relationship between the controller and the MSC board allows enhanced features like:
- Lawful Intercept (CALEA in the U.S.)
- Number and feature portability
- Billing Records
- Flexible routing
- Customized Tones for SIP phones
REDCOM’s Single Platform Solution
REDCOM’s HDX with TRANSip is a true all-in-one converged communications platform. While other solutions rely on multiple boxes, REDCOM’s HDX with TRANSip is able to offer all the same capabilities in a much smaller footprint. With the HDX, there are no expensive server boxes, no separate gateway boxes, and no separate VoIP software to load and configure.
SLICE 2100 is a converged VoIP solution that functions as both a softswitch and gateway, delivering up to 2,000 IP registered subscribers per unit. SLICE 2100 is a natural addition to the SLICE product line that has the capability of handling analog, digital and IP interfaces to provide a unified communications solution.
SLICE 2100 is a compact communications platform that supports many traditional signaling protocols including C7, SS7, DTMF, MFC/R2, MF/R1, FGC, FGD, ISDN PRI/BRI, and EURO ISDN. SLICE 2100 is TRANSip-equipped and can be used as a call manager and media gateway as needed. SLICE 2100’s V4.0 software offers virtually unlimited SIP trunking and enhanced Centrex features (IP and TDM).
The basic SLICE 2100 has two T1/E1 digital spans, two RS-232 ports, two 10/100 Base-T Ethernet ports, two PCMCIA slots for updates and database backup and one hot-swappable cooling module. It also has two rear-accessible positions for your choice of interface modules.
SLICE 2100 architecture allows the stacking of up to three SLICE 2100 units by using the RJ-45 connectors that are located on the front of the units without using any extra resources. When stacked, up to three SLICE 2100s can operate as a single integrated system, tripling your maximum IP subscribers to 6,000 and the maximum number of digital trunks to 18 E1/T1s.
The MSC board is embedded within the unit. To enable TRANSip in SLICE 2100, simply activate the necessary TRANSip feature (password is required) that enables the fully integrated call manager and media gateway. Additional features like T.38 and V.150.1 may be turned on separately based on the customer needs.
Embedded Controller and MSC Board
SLICE 2100 with TRANSip acts as a call manager and a media gateway controller. Call translator database information is stored in the controller and call processing is handled with this unit as well. The controller communicates directly with the embedded MSC board, allowing TDM to IP conversions as well as successful signaling.
The MSC board handles IP to TDM conversions as well as helping the controller to keep track of the IP call records. This fully integrated relationship between the controller and the MSC board allows enhanced features like:
- Lawful Intercept
- Number and Feature Portability
- Billing Records
- Flexible Routing
- Customized Tones for SIP Phones
Interchangeable Plug-in Modules for SLICE 2100
SLICE 2100 features two rear-accessible positions for your choice of interface modules. These modules allow service providers to configure each SLICE 2100 to meet their specific needs. The modules include the following:
Subscriber Module: features 12 loop lines and 2 ISDN BRI-S lines
Analog Trunk Module: Features 10 loop or magneto lines, 2 ISDN BRI-S lines, 2 E&M/SF trunks, and 2 GSRD/LSRD trunks
Multi-E1/T1 Module: Adds 4 E1/T1 spans to the SLICE 2100, for a total of 6 E1/T1 trunks per unit.
Media Gateway Module: The SLICE 2100 already features a built-in Media Gateway with up to 128 timeslots, but adding this module to one of the SLICE 2100’s rear bays enables an additional 128 timeslots, which allows more simultaneous TDM-IP calls and enables extra bandwidth for gateway applications. The IP registrants only use timeslots if they need to access the voice-related services like access to announcements or an analog phone.
Radio Interface Module: Provides an interface to two-way radios allowing the radio user to access most of the SLICE 2100’s features normally accessible to a standard station user. This module allows any phone in the REDCOM system to dial out to a radio net, or allows a remote radio to dial directly into the system and ring a phone, make an outside call, or call another remote radio system.
SLICE IP is a pure IP softswitch powered by TRANSip. In its slim 1U platform, SLICE IP integrates key IP Multimedia Subsystem (IMS) elements, delivering call management functionality and directory services for IP subscribers. A single SLICE IP supports up to 3,000 registered IP subscribers.
The SLICE IP is scalable and flexible for future growth. Up to three SLICE IP systems can be stacked to operate as a single system when greater capacity is required, allowing you to triple your IP trunking and IP subscriber base to 9,000 per node. The SLICE IP can also be stacked with REDCOM’s SLICE 2100 system when access to E1/T1 trunks or legacy protocols is needed.
At the heart of the SLICE IP is a full-featured SIP Call Controller. The SLICE IP supports all the features needed on a pure IP network, such as IP Centrex, bandwidth management, conferencing and SIP trunking. And if a media gateway or legacy interfaces are also required, simply stack a SLICE IP with a SLICE 2100.
SIP Trunking with SLICE IP
SIP trunking using REDCOM’s TRANSip® technology suite with a REDCOM SLICE IP Carrier Class 4/5 softswitch is a powerful way to build your business. SIP trunking is a secure, cost-effective way for service providers to leverage their IP network to provide voice service. To get started with SIP trunking, all that is required is a SLICE IP softswitch (which includes a built-in SIP Call Manager) and an IP network, and you will be on your way to implementing robust SIP trunking capabilities. With proper network assessment planning and implementation, SIP trunks can deliver high quality and reliable service with substantial cost savings.
SLICE IP Micro
The SLICE IP Micro redefines transportable IP communications. By integrating key IP Multimedia Subsystem (IMS) elements and call management functionality into the size of a hardcover book, the SLICE IP Micro puts all the power of a REDCOM SLICE IP into your hands. Powered by REDCOM’s TRANSip® IP technology suite, SLICE IP Micro supports up to 3,000 VoIP subscribers, dual-stack IPv4/IPv6, and configurable conferencing.
Whether you need to deploy this SIP call controller to a mining site, oil rig, remote encampments, or tent cities, the SLICE IP Micro travels easily. The SLICE IP Micro is ideal for essential portable applications such as emergency response, police, fire, and rapid deployment applications. When packaged in its ruggedized carrying case, the SLICE IP Micro is small enough to easily fit in the overhead compartments of commercial aircraft. SLICE IP Micro is the fully featured SIP call controller you can take with you.
Often, it is desirable to have switching assets in different geographic locations. This may be due to geographically dispersed office facilities, the size of the facilities, security concerns, or even something as simple as cable length. Generally, this is accomplished via trunking between two distinct switches. Traditional signaling protocols such as MF, ISDN and even SS7 have limited capabilities for conveying information between the switches that are intended to share information about operations and maintenance, billing record collection and host remote applications.
Using REDCOM’s ClusterNet™ technology, multiple locations equipped with compatible REDCOM equipment behave as a single, integrated system. This approach allows you to increase the manageability and survivability of the entire system.
Components of ClusterNet
ClusterNet technology needs two separate paths to function properly:
- Data Path (Inter-Cluster Link)
- Voice Path (Cross Office Highway)
The data path carries information about the status of the switches including the subscriber status, trunk status, maintenance notes and any other information that can be expected from a single system. The voice path carries the voice between two clusters to make both systems work as a single unit.
ClusterNet in TRANSip
Traditionally, the data channel has been supplied over DS0 channels if the switches were geographically separated, and supplied over Ethernet if the switches were co-located. In both cases, the voice channel was provisioned over T1 or E1 trunks.
TRANSip technology allows the use of the IP layer for ClusterNet connectivity. All of the messages (including data and voice paths) can be carried over the IP network, forming a ClusterNet system. The use of the IP layer saves bandwidth because dedicated DS0 channels are no longer required and the information is sent when it is generated.
The chart below outlines the possible ClusterNet operations between REDCOM products.
|HDX||SLICE||SLICE 2100||SLICE IP|
|HDX||TDM & IP||TDM||TDM & IP||IP|
|SLICE 2100||TDM & IP||TDM||TDM & IP||IP|
What should I do before deploying ClusterNet?
REDCOM’s ClusterNet allows a single point of administration and operations for separate switching systems. In order to benefit from ClusterNet, one should be aware of the following:
- All equipment must have the same software version
- The Cluster feature must be enabled
- There should be enough resources for voice path (either TDM trunks or MSC board)
- The transmission delay between clusters needs to be considered
The REDCOM Customer Service Group is ready to help you with technical questions. They can be reached from 8am to 5pm EST at 1-585-924-6500 and by e-mail at firstname.lastname@example.org
What are RFCs?
Specifications in the IP World are called RFCs. Technically, this stands for “Requests for Comment”. RFCs go through a formal process of review, leading up to publication as a standard by the Internet Engineering Task Force (IETF). Interestingly, there are no “revisions” to RFCs. If a new RFC supercedes an old one, it is simply given an new RFC number.
There is no “requirement” that all equipment conform to all RFCs. Designers, manufacturers, and publishers of IP equipment and software pick and choose the RFCs they believe are relevant to their product and their customers.
The elements forming TRANSip conform to relevant RFCs. Some of these RFCs are supported by all HDX and SLICE 2100 units running V3.1 software or higher. Other RFCs are only supported if the HDX or SLICE 2100 is equipped with TRANSip.
Other organizations which publish specifications or standards which are used by the HDX, SLICE 2100, SLICE IP, SLICE IP Micro and TRANSip include the International Telecommunications Union (ITU), European Telecommunications Standards Institute (ETSI) and the American National Standards Institute (ANSI).
HDX, SLICE 2100 & SLICE IP
The following standards are supported by the HDX and SLICE 2100 running V3.1 or higher software (whether or not they are equipped with TRANSip), as well as SLICE IP running V4.0
or higher software:
|IPv6 is described by many separate RFCs.
(RFC 2460- general, RFC4291- addressing)
|DNS (RFC1034, RFC1035)||Domain Name System|
|DHCP (RFC1533, RFC1534, RFC2131, RFC2132)||Dynamic Host Control Prot|
|NTP (RFC1305)||Network Time Protocol|
The following RFCs and codecs are supported by all HDX, SLICE 2100, SLICE IP and SLICE IP Micro models that are equipped with TRANSip:
RTP-REAL TIME TRANSPORT PROTOCOL-AUDIO STREAMING
|RFC3550||Main RTP Spec|
|RFC3551||Additional RTP spec|
LIST OF SUPPORTED CODECS
|ITU-T G.711 A & Mu plus appendix I and appendix II||Pulse Code Modulation (PCM) of Voice Frequencies|
|ITU-T G.723.1 H&L||RFC 3951, Internet Low Bit Rate Codec (iLBC)|
|ITU-T G.726||16, 24, 32, 40 kbps Adaptive Differential Pulse Code Modulation (ADPCM)|
|ITU-T G.729 A & B||Coding of Speech at 8 kbps using Conjugate-Structure Algebraic-Code-Excited Linear Prediction (CS-ACELP)|
|IETF RFC4040||RTP Payload Format for 64 kbps Transparent Call|
SIP CALL MANAGEMENT
|IETF Draft – SIPPING 19||Session Initiation Protocol Service Examples, draft-ietf-sipping-service-examples-15|
|RFC2327||SDP: Session Description Protocol|
|RFC2543||Session Initiation Protocol (SIP)|
|RFC2833||RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals. Because VoIP encoding methods are optimized specifically for voice, they do not transport DTMF digits or telephony call progress tones. Therefore, these tones must be detected and/or regenerated at both ends of the connection.|
|RFC2976||SIP INFO Method|
|RFC3261||Session Initiation Protocol (SIP)|
|RFC3265||SIP Specific Event Notification|
|RFC3326||Reason Header Field for SIP|
|RFC3420||Internet Media Type message/sipfrag|
|RFC3428||SIP Extension for Instant Messaging|
|RFC3515||SIP Refer Method|
|RFC3581||An extension to the SIP for Symmetric Response Routing|
|RFC3891||SIP “Replaces” Header|
|RFC3892||SIP Referred-By Mechanism|
|RFC4028||Session Timers in SIP|
|RFC4235||An INVITE-Initiated Dialog Event Package for SIP|
The following ITU specs are supported as an option in HDX and SLICE 2100 equipped with TRANSip and when the option is purchased:
|ITU T.38||Fax over IP (FoIP)
Because VoIP encoding methods are optimized specifically for voice, they do not transport modem tones designed to transport faxes.
For a traditional fax to communicate with a fax connected to the data port of a VoIP phone, or a fax designed specifically to behave as a VoIP phone, it is necessary for a Media Services Circuit with a TRANSip FoIP engine to convert between the two protocols.
|ITU V.150.1||Modem over IP (MoIP)
Because VoIP encoding methods are optimized specifically for voice, they do not transport modem tones.
It might seem strange that there is even a requirement for VoIP to transport modem tones, considering that the use of VoIP presumes the availability of a direct IP connection which can transport data. However, existing modems need to be supported as they will be functional for the foreseeable feature.
REDCOM has provided custom telecommunications solutions since 1978 to a variety of customers. As our customers migrate to an IP environment, REDCOM’s telecom experts can help simplify your transition to VoIP with network assessment services.
The traditional TDM network is circuit switched and factors like Grade of Service and Erlang tables are used to estimate the resources that would be allocated for communications. Signaling protocols, trunk interfaces and line cards are needed to determine the equipment for successful deployment of the network and toll quality expected by the customers.
In packet switched networks such as the Local Area Networks (LANs) or Wide Area Networks (WANs), the design of the network is different. Since there are no dedicated channels, unlike the circuit switch network, the resources need to be estimated considering peak data traffic. Regular network elements such as mail servers, web servers, firewalls or NATs need to be considered.
As the convergence continues, the data networks will keep carrying real-time packets that are extremely sensitive to delay. If a voice packet gets to its destination one second late, it is basically discarded due to delay. The network needs to be able to prioritize traffic based on QoS tags that are generated by phones or media gateways.
REDCOM has provided custom telecommunications solutions since 1978 to a variety of customers. As our customers migrate to an IP environment, REDCOM can help by providing network assessment services to make your VoIP deployment as easy as possible.
How to Request a Quotation
All of REDCOM’s offerings are customizable based on customer needs. In order to provide an accurate quotation, we would like to learn as much as possible about your network. One of the most efficient ways of portraying the network is to provide a network diagram along with signaling protocols, subscriber numbers (analog, digital and IP), trunk interfaces (E1, T1, E&M, G/LSRD) and as much information as possible.
After gathering this information, REDCOM might ask further questions or provide you a quotation that is specifically prepared for your project.
To request a quote, please contact REDCOM.
Frequently Asked Questions (FAQs)
Where did the intelligence go?
In the traditional TDM world, the intelligence in any given network was located in the core of the network rather than the edges. Network elements were all intelligent units that would perform various jobs including digit translations, providing billing information and special services. The end terminals had a very simple task and required no or little intelligence.
In the IP world, the intelligence has shifted to the end terminals where applications reside. The main purpose of the network is basically to route traffic.
As the shift towards an all IP based architecture continues, REDCOM TRANSip converges both of these worlds and provides a greater total benefit than the simple sum of the two worlds.
How many timeslots are there per shelf?
In the SLICE 2100, there are 512 timeslots available. An HDX system can have up to 4,096 non-blocking timeslots with up to 512 per shelf.
How many timeslots can be assigned to the MSC Board?
The MSC board that is embedded within the SLICE 2100 takes 128 timeslots. The MSC board in the HDX can take up to 128 timeslots.
Usage of timeslots is critical for applications that require a TDM connection or special services (like announcements) from the HDX or SLICE 2100.
Contact REDCOM for assistance with system resources related questions including timeslot calculations. Call 1-585-924-7550 or e-mail email@example.com.
Does the dial tone really mean dial tone?
In the traditional TDM world, a dial tone is provided by the Central Office to the end station to indicate that the end station is able to make a phone call. The dial tone is a confirmation of the availability of the network.
In the IP world, a dial tone can be provided by an IP phone that is simply powered up and not connected to the network. The dial tone does not necessarily mean that the network is ready. This can give a false impression to the user.
Ready to deploy VoIP in your network?
The task of deploying VoIP in your existing TDM/IP or just IP network may not be as easy a task as it sounds. There are various factors that need to be considered ranging from the support for the existing network elements to the firewalls to the Quality of Service requirements. There is no one-size-fits-all approach for this deployment.
For more than 30 years, REDCOM has provided customized solutions based on our customers’ specific needs. Before deploying VoIP, we recommend you consult with the communications experts at REDCOM. Call 1-585-924-7550 or firstname.lastname@example.org.
TRANSip is available in multiple platforms?
REDCOM’s TRANSip technology is deployed in different packages to meet our customer needs.
The HDX with TRANSip is a fully customizable switching system where users can benefit from a variety of boards that are deployed for signaling, trunking, lines and announcements. HDX also provides redundancy in the controller board for increased reliability. HDX is the preferred choice for mid to larger size applications.
SLICE 2100 with TRANSip is a pre-configured 1 U high communication system that allows stacking up to 3 units. SLICE 2100 is an ideal size for small size business and tandem applications.
SLICE IP is a 1U high pure IP solution. REDCOM also offers the SLICE 2100 Micro and the SLICE IP Micro.
For more than 35 years, REDCOM has provided custom solutions based on customers’ needs. Before deploying VoIP, we recommend talking to the communications experts at REDCOM. Call us at 1-585-924-7550 or e-mail email@example.com.
Obtaining a Quote for TRANSip solutions?
In order to provide the best possible solutions for our customers, REDCOM systems are configured to meet your specific requirements. To address your needs properly, we need information about your application, including the number of trunks, lines, signaling types, etc.
As much information as you can share with us will assist our telecommunications experts to configure a solution that will meet your specific needs.
Feel free to contact us at 1-585-924-7550 or e-mail firstname.lastname@example.org.
I need a REDCOM. Can you please send me a quote?
REDCOM has been in the telecommunications industry for nearly 30 years and provided customizable solutions for our customers. The high quality of our products raised the expectations in the industry.
We often receive requests that specify REDCOM as part of the communications solution due to our capability of delivering products on time that meets the demands. Although we appreciate your request for REDCOM, we will need further details to provide you a solution.
In order to provide the best possible solution for our customers, all of REDCOM systems are custom configured. To address your needs properly, we need detailed information about your application which may include number of trunks, lines, signaling types and as much information as possible.
We appreciate your interest in REDCOM products and will continue to deliver the needed solutions.
What should I do before deploying ClusterNet™ Technology?
REDCOM’s ClusterNet allows a single point of administration and operations for separate switching systems. In order to benefit from ClusterNet, one should be aware of the following:
- All of the equipment needs to have the same software version.
- The Cluster feature must be turned on
- There should be enough resources for voice paths (either TDM trunks or MSC board)
- The transmission delay between clusters needs to be considered
The REDCOM Customer Service Group is ready to help you with technical questions. They can be reached from 8am to 5pm EST at 1-585-924-7550 and by e-mail at email@example.com.
What are RFCs?
Specifications in the IP World are called RFCs. Technically, this stands for “Requests for Comment”. RFCs go through a formal process of review, leading up to publication as a standard by the Internet Engineering Task Force (IETF). Interestingly, there are no “revisions” to RFCs. If a new RFC supercedes an old one, it is simply given a new RFC number.
There is no “requirement” that all equipment conform to all RFCs. Designers, manufacturers, and publishers of IP equipment and software pick and choose the RFCs they believe are relevant to their product and their customers. If they pick correctly, their equipment and/or software becomes compatible with other equipment in their market, and they succeed in the marketplace.
The elements forming TRANSip conform to relevant RFCs. Some of these RFCs are supported by all HDX and SLICE 2100 running V3 or higher software. Other RFCs are only supported if the HDX or SLICE 2100 is equipped with TRANSip.
Other organizations which publish specifications or standards which are used by the HDX, SLICE 2100, and TRANSip include the International Telecommunications Union (ITU), European Telecommunications Standards Institute (ETSI) and the American National Standards Institute (ANSI)
TRANSip® for HDX/SLICE® utilizes the industry-standard Session Initiation Protocol (SIP) as defined by the Internet Engineering Task Force (IETF) in RFC 3261. As such, TRANSip is compatible with any endpoint that also complies with RFC 3261. Users of these devices can be confident that the device will successfully register to the HDX/SLICE and process phone calls.
Due to the sheer volume of different devices available, it is simply not feasible to validate each and every feature on every model and version from every manufacturer that provides SIP-compatible endpoints. REDCOM does, however, have a close working relationship with specific manufacturers and performs extensive validation testing with those devices.
The following vendors and models undergo continual testing with the latest versions and are recommended for use the TRANSip on the HDX/SLICE platforms.
- 4101 – A single line phone available in both business and military versions.
- 4104 – A four line phone available in both business and military versions.
- 7810 – A ten line phone available in both business and military versions.
- 7810 TSG-6 – A ten line phone designed for secure and SCIF applications.
- SoundPoint Series IP Phones