October 2000

Pulling Together -- Interoperability Through Open Standards

BY GREG GALITZINE

We've taken a quick pulse of the industry and asked several vendors to comment on the importance of interoperability. Respondents include an Internet telephony service provider (ITSP), a next-gen Integrated Communications Provider (ICP), and one of the so-called "arms merchants" -- a company tasked with supplying products and solutions to the industry.

We've also taken a moment to ask the industry's leading players to describe a standard that falls within their particular area of expertise. Below you'll find descriptions and definitions of several of the more prevalent standards operating in the Internet telephony industry: SIP, H.323, MGCP, and MPLS. One thread you'll find throughout this whole section is the need for the industry to work together toward a rather elusive goal: Only by pulling together can we ever achieve the holy grail of interoperability.

[ Return To The October 2000 Table Of Contents ]

Jonathan Rosenberg, Chief Scientist, dynamicsoft, Inc.

As next-generation networks move from the design stage to deployment, a key challenge for service providers and network operators is how to ensure interoperability between different communication protocols. The Session Initiation Protocol (SIP) is an Internet standard specified by the Internet Engineering Task Force that is used to used to initiate, manage, and terminate interactive sessions between one or more users on the Internet. SIP has gained tremendous momentum among service providers because it can deliver enhanced services over next-generation networks.

However, one of SIP's most attractive features is that its simple, open design supports interworking with ISUP and H.323 -- key protocols from both the SS7 and IP environments. SIP's ability to work with these widely deployed standards will not only speed the integration of the PSTN with IP networks, but gives service providers with H.323 networks a clear migration path to offer new services that can go well beyond VoIP.

SIP And ISUP
Let's look first at how SIP works with ISUP, the protocol used in SS7 networks to set up and manage basic call connections. One common network scenario is IP trunking, also known as phone-to-phone, in which PSTN calls hop onto the Internet over a gateway and then hop back off to the PSTN. While SIP is used to route calls over the Internet, the question becomes how to preserve feature transparency. It is generally believed that the primary way to achieve feature transparency is to ensure that all the information in the incoming ISUP is carried through the SIP network to the gateway on the far end.

This can be accomplished with SIP-T (SIP for telephony), a simple extension of SIP that preserves needed ISUP information as the call is carried through the Internet. This is done by actually carrying the ISUP message, byte for byte, in the body of the SIP messages. Since SIP supports transfer of any type of content, ranging from JPEG pictures to HTML Web pages, it can easily carry ISUP messages. What's more, SIP-T is backwards compatible so that it will operate with all existing SIP phones. If a phone gets a message with ISUP, but doesn't understand ISUP, those bodies are simply ignored. SIP-T is currently a work item of the SIP working group in the IETF.

SIP And H.323
How well does SIP interwork with H.323? Since H.323 is an ITU standard, while SIP springs from the IETF, these two protocols are often portrayed as rivals. As usual, the real picture is more complicated than that, and network operators stand to benefit from closer interworking between SIP and H.323.

Architecturally, these two protocols are very different, and the way they handle many functions (such as multiparty conferencing) share few similarities and are difficult to interwork. However, many softswitches already support SIP to H.323 translations, and interworking between SIP and H.323 has been demonstrated for some time now. There is currently work going on within the IETF to develop guidelines for such interworking. It's already been shown that basic functions like call setup and teardown will work between these two protocols, but even more complex functions are being investigated.

One of the key advantages of SIP/H.323 interworking is that a service provider with deployed H.323 networks will be able to begin to gradually realize some of the benefits of SIP services. SIP is rapidly emerging as the clear choice for delivering applications; soon we'll begin to see the advent of application servers that will likely support SIP and not H.323. The International Softswitch Consortium's applications working group has defined a typical VoIP application server based on SIP.
Service providers with H.323 networks can simply begin to use SIP/H.323 conversion boxes, or gateways, that will let them leverage their existing investments in H.323 gear. They'll be able to deploy SIP application servers that can work in H.323 networks via conversion boxes. They won't have access to the powerful new features and services SIP defines, but SIP itself is powerful enough to "know" what features a H.323 client is able to execute. SIP-based applications can include negotiation capabilities that can "step down" in function when talking to an H.323 endpoint device.

The advantages to this approach are compelling: H.323 operators will gain access to new applications. And as soon as they deploy a full SIP gateway or SIP-enabled devices in their network, they will immediately have access to the complete rich set of SIP services. So there's a logical migration path here. The incentive for H.323 operators is to gain access to these more powerful applications, but still be able to support older H.323 endpoints. This approach lets network operators move up to a SIP-based infrastructure as part of a planned network upgrade cycle -- protecting their existing investments while gaining access to the better scalability, openness, and rich features SIP can deliver. 

[ Return To The Top Of The Page ]
[ Return To The October 2000 Table Of Contents ]

Orit Levin, Product Manager, RADVision, Inc.

Scope
H.323 is an ITU standard designed to accomplish a primary system goal: moving real-time bi-directional multimedia (audio, video, data, fax) across packet-based networks while maintaining connectivity to PSTN, including SS7 circuit-switched networks and H.320 systems. Version 1 of H.323 was released by the ITU in May 1996, and was designed mainly to support small-to-medium videoconference systems. As the VoIP community began to adopt H.323, versions 2 and 3 of the H.323 recommendation added many features associated with pure VoIP systems, more services, and a support for large distributed networks. Version 4 of H.323, to be ratified in November 2000, reflects over four years of deployment experience. In addition, H.323 Annexes provide specifications for designing H.323 systems for specific environments or applications.

Building Blocks
H.323 both defines a system and also provides the protocols necessary to achieve the defined system. The signaling protocols are defined by H.225.0 and include RAS and Q.931. RAS, or Registration, Administration, and Status, handles user management; Q.931, an adaptation and optimization for packet networks of the original ISDN Q.931, handles call signaling; H.323 also uses the H.245 protocol, which provides media control by opening the media channels and negotiating the capabilities for each endpoint. H.245 can also change the characteristics of the channel, allowing for asymmetrical rate and codec adaptation between endpoints, features necessary for multimedia interactive communications. H.323 also uses the IETF RTP/RTCP protocol to move the real-time streams themselves across the network.

The building blocks of H.323 are Gatekeepers, Terminals, Gateways and Multipoint Control Units (MCUs). These last three entities are collectively referred to as endpoints, which generate and/or terminate call signaling and information streams.

• Terminals are "smart" endpoints that, in addition to call signaling, can negotiate capabilities and media control.
• Gatekeepers are H.323 Servers that provide Location and Control services, for various H.323 endpoints within their Zones. Among services, traditionally provided by a Gatekeeper, are address resolution, bandwidth management and resolving the Gateway's location problem. The Gatekeeper is considered to be a control point, through which the desired policies and back-end services are introduced to the H.323 system. The Gatekeeper is also a typical place for extracting of H.323 information, such as billing information and diagnostics.
• Gateways provide for real-time, two-way communication between H.323 endpoints and other endpoints of any kind, such as users connected to a PSTN network.
• MCUs provide the capability for three or more endpoints to participate in a multipoint conference. Two terminals in a point-to-point conference may also be connected by an MCU if the call is anticipated to later develop into a multipoint conference. H.323 has a concept of breaking the MCU into two distinct pieces -- the multipoint processor (MP) for processing of multipoint media streams and the multipoint control (MC) for control of one or many MPs. This MC/MP split allows use of complementary protocols such as MCGP and H.248 (MEGACO) to physically distribute the logical MCU components.

Annexes Soup
"Annex C" defines procedures for running H.323 over ATM.

The H.450 series defines how PSTN-like Supplementary services can be built for H.323 systems.

H.323 has been optimized for VoIP support through "Annex E" (creating a standard for running H.323 over UDP) and "Annex F" (providing guidelines for Simple Endpoint Type (SET), allowing for media types other than voice to be stripped away). "Annex J" defines security procedures for SET. Additionally, Stimulus Signaling (defined by "Annex L") allows a user to establish a simple H.323 call and then communicate with a server via H.248 (MEGACO) procedures in order to receive or invoke services implemented by the server.

"Annex G" defines procedures for simple text conversation both for "classic" H.323 and SET devices.

"Annex M" defines a framework for conveying legacy protocols over the H.323 backbone. Annexes M.1, M.2, and M.3 address QSIG, ISUP, and DSS1 signaling protocols correspondingly.

H.323 also continues to make strides in mobility and use of the Internet's improving infrastructure. The original RAS Registration concept allows for User and Service Mobility built within and around H.323 (H.323 Annexes "H" and "I", and "H.246 Annex E").

"Annex K" introduces a concept of HTTP-based "service control plane" within a "call control plane" of H.323.

As H.323 prepares for full inclusion as a service being provided over Internet, work on H.323 procedures over Internet is being performed in the context of "Annex O" (Internet Protocols and Technologies complementary to H.323).

Early 2001 should bring ratification of "Annex N" (QoS in H.323) and "Annex R" (Robustness). Based on deployment experience, several important annexes are set for near-term second version ratification. Among them are H.235 v2 (Security for H.323), "Annex D" v2 (FAX over H.323), "Annex E" v2 (H.323 over UDP) and "H.225.0 Annex G" v2 (Inter-Domain Communication).

Final Word
With four years of deployment experience and maturity behind it, the H.323 protocol is stable and the most deployed solution. H.323 is being used for a variety of multimedia applications such as Call Center (voice and video), VoIP trunking applications, remote education and other vertical business applications. H.323, as the most mature specification, is the standard of choice for applications that require multi-vendor components. H.323, together with protocols and toolsets such as MCGP, SIP, and H.248, provides a robust framework for enhanced multimedia solutions. 

[ Return To The Top Of The Page ]
[ Return To The October 2000 Table Of Contents ]

Jeff Lawrence, President & CEO, Trillium Digital Systems, Inc.

Gateways reside at the boundaries between and within the telephony, Internet, broadband, and wireless network infrastructures. Trunking media gateways operate at the boundary between the Internet and the PSTN, and perform the conditioning of circuit- and packet-based media streams. Other types of media gateways perform similar functions at the boundary between businesses, residences, access points, and the network.

Gateways may be decomposed into the Media Gateway Controller (MGC), Signalling Gateway (SG) and Media Gateway (MG). The SG acts as the relay for signalling information between the Internet and PSTN. The "intelligent" Media Gateway Controller maintains the overall call state and controls the "dumb" Media Gateway by sending commands via the Media Gateway Control Protocol (MGCP), a fairly simple protocol consisting of a small set of messages and procedures. The MG executes the commands given by the MGC to control and condition the circuit and packet media streams. Currently, the intelligence controlling the Internet (in the form of name servers, gatekeepers, and media gateway controllers) and the PSTN (in the form of service control platforms and location registers) is distributed throughout the network. In the future, the access and core network intelligence will reside in softswitches and backend application servers. These softswitches will incorporate MGC functionality and control the network elements using a variety of protocols including MGCP.

MGCP and its related protocols have undergone a swift market driven evolution. Unfortunately, as a result of differing market needs the IETF, CableLabs, and the ITU have fragmented the MGCP standard into four variations: MGCP, NCS/MGCP, MEGACO, and H.248. There are a number of differences between these variations and there can even be different implementations within the individual variations. This has created confusion in the market and raised a number of interoperability and interworking issues for communications equipment manufacturers and their customers, the network operators and service providers. MGCP is driven by the IETF and supports voice connections, while NCS/MGCP is driven by the CableLabs PacketCable initiative and is designed to support multimedia connections and operate efficiently in the cable infrastructure's multipoint environment.

MEGACO and H.248, on the other hand, are essentially two names for the same thing. Though these started as separate initiatives, the IETF MEGACO Working Group and ITU Study Group 16 have agreed to align their activities and publish a single document for MEGACO/H.248, which promises a much richer set of capabilities, with a corresponding increase in protocol complexity. The transaction model has changed from endpoints and connections to contexts and terminations, which in turn will provide a greater deal of transaction flexibility. MEGACO/H.248 uses text or binary messages and can support multiple actions and commands per transaction. Importantly, MEGACO/H.248 also supports improved failover procedures to provide high availability in case of equipment or network failure. In addition, MEGACO/H.248 provides easier-to-use and extensible packages to support the events, signals, and statistics necessary to control and manage the MGs. Unfortunately, these capabilities come at the expense of a command and response structure that is different from that of MGCP and NCS/MGCP.

Due to these differences, MGCP is not completely compatible with NCS/MGCP and neither of these is compatible with MEGACO/H.248. Although MGCP and NCS/MGCP have dominant market share at this point in time, new equipment and devices are being developed to support MEGACO/H.248. The incompatibilities among MGCP's different variations will require the development of gateways to translate between the installed bases of the different variations. In addition to the differences in the variations, there are differences in the individual implementations, which means each softswitch will need to support the specific command and response sets of the MGs under its control.

In the short term, interoperability problems can be alleviated if a single vendor supplies the MGC and MGs. This, however, is not a long-term solution. From a risk management and competitive perspective, network operators and service providers will find it essential to move towards multi-vendor solutions that will provide the flexibility to choose the best feature, performance, and cost solutions to meet their particular needs. However, true multi-vendor solutions will not be possible until more extensive and industry-wide interoperability testing is performed. The multiple standards and the limited number of interoperability tests performed to date (most of which have been sponsored by CableLabs, the University of New Hampshire, and the International Softswitch Consortium), highlight how far the industry still must go to ensure the long-term success of MGCP and the decomposed network architecture. 

[ Return To The Top Of The Page ]
[ Return To The October 2000 Table Of Contents ]

Mark Veil, Product Manager, Integral Access

The demand for converged IP-based services and applications has created a host of new market opportunities for today's Integrated Communications Provider (ICP). With each new market having its own unique set of demands, the ICP must be capable of creating, delivering, and billing for graded service offerings specifically tailored for these requirements.

As a result, today's providers need tools to effectively and efficiently engineer and manage their networks for class and quality of service (CoS/QoS). Fortunately, new IP-based technologies for supporting enhanced broadband voice and data services over a single access network can provide competitive carriers the opportunity to aggressively attack new markets with broad and richly differentiated service offerings. Multi-Protocol Label Switching (MPLS), in combination with effective traffic management facilities, provides the best approach for managing QoS/CoS in today's access networks and allows ICPs to deliver differentiated IP-based services.

Engineering And Managing Network Traffic For QoS
QoS, which we will define as the collective measure of service levels delivered to the customer premise and characterized by performance criteria such as availability, response time, throughput, error rates, and packet loss, enables certain traffic types to be given priority treatment in the network. This capability is required to support specific latency requirements of individual applications, or to meet customer-contracted Service Level Agreement (SLA) obligations. To support QoS requirements, network facilities must provide traffic management services such as admission control, traffic classification, traffic marking, and traffic conditioning. Once appropriately classified and groomed, traffic must be aggregated and efficiently mapped onto the existing network topology for the purposes of controlling network behavior and optimizing network utilization and traffic performance. This is the domain of traffic engineering and MPLS.

MPLS represents the best alternative for enabling traffic engineering and QoS in the heterogeneous world of network communications. Although originally intended as a means to enhance routing performance, continued improvements in that area have shifted the application focus of MPLS to its inherent capabilities for delivering efficient and scalable traffic engineering and QoS in IP-based networks. MPLS operates at Layer Two-and-a-half (L2.5) and is protocol-agnostic to the layers above and below it. Its architecture is based on the multi-layer switch concept -- which cleanly separates the forwarding and control functions --with the former being the domain of MPLS.

The power of MPLS stems from its ability to associate and allocate any type of user traffic with a particular Forwarding Equivalency Class (FEC). Each FEC represents an aggregation of traffic that will be treated in the same manner as it traverses the network. Typically these traffic classifications are based on the contents of the packet header, such as the L2 and L3 source/destination address. In practice, however, classifications may be derived from (and applied to) a virtually unlimited range, combination, and granularity of packet attributes -- including physical ingress port/interface, application protocol type or Ipv4 type of service (ToS), and Ipv6 CoS markings.

These FECs are then mapped to label switched paths (LSPs) that have been engineered to support specific traffic QoS requirements -- guaranteed bandwidth or low latency for instance. LSPs behave in a similar fashion to the more familiar ATM virtual circuit and frame relay data link connection identifier (DLCI), but do so with much greater efficiencies.

Upon ingress to a particular MPLS domain, all packets are assigned a label that serves to represent its FEC/LSP binding as well as a short-hand reference to the contents of the IP packet header. In sharp contrast to today's "longest-match" routing paradigm, MPLS-equipped routers are able to perform ultra-fast forwarding of IP packets via "exact match" label swapping. Moreover, MPLS overcomes the inherent limitations of traditional destination-based routing by supporting both explicit and constraint-based approaches for establishing LSPs. This capability allows network administrators to bypass potential points of congestion and direct traffic away from the default path selected by today's Interior Gateway Protocol (IGP)-based networks and deliver precise control of network traffic and behavior.

Enabling Enhanced Services With MPLS
For the resource-constrained local access loop, MPLS is best matched with the IETF's Integrated Services (IntServ) architecture to provide explicit QoS controls at the LSP level for delivering enhanced IP-based services. The MPLS-IntServ combination delivers connection-oriented behavior to connectionless access networks. Each LSP is apportioned and allocated access bandwidth in accordance with its traffic contract parameters to ensure the given application receives its appropriate level of QoS. For instance, individual LSPs can be created to support the unique requirements of services such as Voice over IP (VoIP), VoMPLS, or premium data applications such as e-commerce or VPNs. In the core network, where explicit end-to-end resource reservations are not practical and additional packet processing overhead is not advantageous, pairing MPLS with another IETF initiative, differentiated services (DiffServ) provide the required levels of QoS management.

MPLS offers a practical QoS solution for ICPs that want to deliver differentiated, IP-based services. MPLS enables all services -- packet-based voice services, tiered data offerings, and secure VPNs -- to dynamically share the same link, delivering optimum resource utilization for resource-constrained access networks. Moreover, service providers can provision, account, and bill for differentiated services -- and turn previously "flat" minutes into "fat" revenue-generating minutes. Finally, MPLS promises to reduce the complexities and costs associated with operating multiple access networks and provides protection for existing technology investments, while allowing carriers to follow a clear migration path to a converged, IP-dominated world. 

[ Return To The Top Of The Page ]
[ Return To The October 2000 Table Of Contents ]

We asked several industry-leading vendors for their views on the Internet telephony industry. Their responses appear below.

 Jim Yu, Director of New Technologies, ITXC Corp.
A.) Interoperability is essential to the growth of the Internet telephony industry. Without it, service providers have two choices: Either they are forced to operate multiple networks -- a network for each type of equipment -- or they are forced to operate their network relying on a single vendor. Operating multiple networks is difficult to manage and not cost effective to build out. Relying on a single vendor locks the service provider into a single upgrade and migration path, and can not take advantage of additional features or cost competition offered by other vendors.

B.) The hurdle that the industry faces today is the lack of a single interoperability reference to implement against. One organization that is actively addressing this issue is the IMTC's iNOW! Activity Group. iNOW!, which stands for "interoperability NOW!," is a broad-based, industry initiative to quickly provide short term, revenue-based IP telephony interoperability. A set of profiles were developed to guide the implementation of VoIP equipment to ensure that equipment built to the iNOW! specification will be able to exchange voice and fax traffic seamlessly across vendor platforms.

C.) Interoperability in the VoIP space will enable service providers to rapidly expand their footprints with customers that have already bought equipment from multiple vendors. Service providers will also easily expand their footprint by connecting their multiple vendor networks to other multiple vendor networks.

Al Bender, Vice President, Applications Portfolio, Nortel Networks
A.) The promise of Internet telephony is an open and programmable environment. Open means standards-based and interoperable. With interoperability, service providers will be able to mix best-in-class products from different vendors to differentiate service. Interoperability is less important at the gateway level. In general, gateways are dumb and are becoming commodities. The key value of interoperability is at the applications level. Next-generation multimedia services will be delivered in Internet telephony architecture from SIP-based service platforms that need to interoperate with the softswitch and the smart clients.

B.) The major hurdle is the completion of relevant standards: H.248 with support for both lines and trunks, IPS7 for SS7, SIP-T for softswitch-to-softswitch signaling, and native SIP for next-generation services.

C.) The major benefits of interoperability are lower cost, faster deployment, and differentiated services.

Mike Kallet, Executive Vice President, Products & Technology, ICG Communications
A.) Critical. Only with interoperability can Quality of Service (QoS) exist across different networks. This hasn't happened yet. The hardware vendors -- the Ciscos, Lucents, and Nortels of the industry -- must design and implement according to agreed upon standards. Hardware vendors must test with each other and listen to companies (like ICG) so they know what does and does not work. Providers like ICG must pressure vendors to create and adhere to standards. With the industry calling for standards, hardware vendors will be pushed to take that first and important step toward interoperability.

B.) If a supplier can sell their goods with proprietary technology, it has no incentive to design a product replaceable by products from other companies. Even once standards are set, companies will extend those standards, differentiating themselves and losing interoperability. The thin line companies must walk is to adhere to industry standards while differentiating themselves to consumers.

Another issue is complexity of networks. Multiple standards must unite so a diversity of services can run on the network. We must offer QoS across different technologies.

Finally, we are reinventing settlement issues -- reciprocal compensation, tariffs, etc. The industry must determine billing and revenue issues in light of regulatory mandates.

C.) For providers, the benefit is simply industry growth and additional telephony purchases by customers. For customers, the benefit is simplicity. The customer won't worry about QoS or the networks on which traffic travels. Unless interoperability is achieved, IP telephony will not thrive; there is too much information for the consumer to keep track

[ Return To The Top Of The Page ]
[ Return To The October 2000 Table Of Contents ]