Technology and Research
Intel® Technology Journal Home
Volume 10, Issue 01
Converged Communications
Table of Contents
Technical Reviewers
About This Journal
Intel Published Articles
Read Past Journals
Subscribe
E-Mail this Journal to a Colleague
Main Visual Description
Intel Technology Journal - Featuring Intel's Recent Research and Development
Converged Communications
Volume 10    Issue 01    Published February 15, 2006
ISSN 1535-864X    DOI: 10.1535/itj.1001.06

  Section 5 of 15  
Using Intel® Technologies to Build Next-Generation Media Servers
PACKET-SWITCHED NETWORK

Unlike circuit switching, which relies on dedicated point-to-point connections to transmit contiguous streams of media, a packet-switched network breaks up the media stream into small message packets. Each packet contains address information specifying the desired destination for the packet. Because packets are addressed, no pre-established communication path or reserved "circuit" is required for a packet network. In contrast to a circuit-switched network, bandwidth in a packet network is used as needed to send packets. A quiescent channel need not produce load on the network.

As packets traverse the packet-switched network, they do not necessarily follow the same path to the destination. Network traffic conditions or outages can result in packets being dynamically routed through different paths. As a result, packets may take different amounts of time to reach the destination, they may arrive in a different order from the one in which they were sent, or they may be lost altogether. It is the responsibility of the destination device to deal with packet order, latency, jitter, and loss. Once they are reassembled, the destination device can render the media in real time. Packet loss, network latencies, and packet ordering represent some of the biggest challenges to providing reliable, high-quality, real-time communications over a packet network.

Several protocols have been designed for packet-based networks, the most popular being the ubiquitous Internet Protocol (IP). IP, which specifies the addressing scheme and packet format, was originally designed for data communications between dissimilar computers. It is a connectionless protocol and not inherently reliable. Numerous additional protocols have been designed to run on top of IP specifically to address the needs of real-time voice and video communications.



Figure 3: IP network with PSTN gateway
click image for larger view
 

Two predominant standards have emerged in the IP signaling domain: H.323 [3] and SIP [4]. H.323 is an International Telecommunications Union (ITU) standard for the transmission of voice, video, and data over an IP network. An umbrella specification that consists of a suite of protocols and standards, H.323 defines a complete framework for multimedia communications. It specifies detailed protocols, messages, and state machines. H.323 has its roots in the traditional telephone network and attempts to address a wide range of problems including basic call states, supplementary services such as call forwarding and call waiting, Quality of Service (QoS), mobility (users moving from one address to another), and security.

SIP is a protocol defined by the Internet Engineering Task Force (IETF) that has begun to supplant H.323 in popularity. Unlike H.323, which attempts to address specific functionality such as basic and supplementary multimedia services, SIP defines a protocol that supports a generic session model upon which systems can be built. The SIP specification (IETF RFC 3261) defines a small set of messages that addresses location services, session creation and termination, and session parameter passing. It is designed to support a wide range of multimedia applications.

Although SIP and H.323 seem to have approached the problem of multimedia communications from different angles, they both define a number of architectural elements that enable location services, authentication, mobility, and interoperability with the circuit-switched PSTN. At a high level, SIP and H.323 are similar in terms of functional decomposition. In addition, both SIP and H.323 use RTP/RTCP [5] (IETF RFC 3550) as the media streaming protocol over IP.

For interoperability with the PSTN, SIP and H.323 define an architectural element called a gateway. The gateway is divided into two functional components. The signaling gateway (SG) component converts between PSTN control signals and the appropriate SIP/H.323 messages. The media gateway component (MG) converts between circuit and packet media. A MG controller is the entity that controls the MG (see Figure 3).

In architecture diagrams, the MG, SG, MG controller, application server, and media server are often shown as individual devices. Depending on the system requirements, these devices may be implemented on separate nodes or be physically combined within a single server.

3GPP and IMS

The Third Generation Partnership Project (3GPP) developed the IP Multimedia Subsystem (IMS) [6]. IMS is an example of a next-generation communications network architecture. It enables service providers to deploy new IP-based, multimedia communication services over both the fixed wireline and mobile telecommunications networks.

With IMS, services can be provided over any IP network (GPRS, WLAN, etc.). The IMS infrastructure is IP based, using standard SIP/IP between the core network elements. Originally designed for the mobile network, IMS can provide IP-based services to external circuit-switched networks as well as external IP networks.

The IMS architecture defines functional entities falling into the six main categories listed in Table 1. The IMS entities collectively address interoperation with other networks (e.g., circuit-switched and radio access networks), security, roaming, policy control, billing, and service deployment.

Figure 4 shows a simplified view of the IMS architectural elements that cover session management and call routing, security and policy management, network interoperability, security, and services.



Figure 4: Simplified IMS architecture
click image for larger view
 

Table 1: IMS functional categories
 
Session and routing Call Session Control Functions (CSCF)
Databases Home Subscriber Server (HSS), Subscription Locator Function (SLF)
Interoperation Breakout Gateway Control Function (BGCF), Media Gateway Control Function (MGCF), IMS Media Gateway (IMS-MGW), Signaling Gateway Function (SGF)
Services Application Server (AS), Multimedia Resource Function Control (MRFC), Multimedia Resource Function Processor (MRFP)
Support Policy Decision Function (PDF), Security Gateway (SEG), Topology Hiding Inter-network Gateway (THIG)
Charging Charging Collection Function (CCF)

The IMS elements most relevant to this paper are the Multimedia Resource Function Controller (MRFC), Multimedia Resource Function Processor (MRFP), and the Applications Server (AS). The MRFC is the element responsible for taking SIP requests from the AS and translating them to messages that control the media processing resources residing in the MRFP. The MRFP is where the actual media processing resources reside.

While the IMS specifications separate the AS, the MRFC, and the MRFP, implementations can combine one or more of these elements into a single node, as noted earlier. In fact, it is widely expected that the MRFC and MRFP elements will typically be deployed as a single unit.

In Figure 5 we show a combined AS, MRFC, and MRFP and collapse the other IMS elements. This diagram shows many of the same functional elements as shown in Figure 3: an IP-based Media Server interoperating with the circuit-switched network via a media and signaling gateway combination. In fact, many of the same Intel components may be used to build both systems.



Figure 5: Media server view of the IMS architecture
click image for larger view
 


  Section 5 of 15  

In This Article
Abstract
Introduction
Taxonomy of a Media Service Network
Circuit-Switched Network
Packet-Switched Network
Application Programming Interfaces
Intel NetStructure® Host Media Processing Software
Intel Architecture for Signal Processing Applications
Intel Development Environment
Where We Go From Here
Conclusion
Performance Testing
Acknowledgments
References
Authors' Biographies
Download a PDF of this article.   
Email This Page
Back to Top