ITEXPO begins in:   New Coverage :  Asterisk  |  Fax Software  |  SIP Phones  |  Small Cells

Feature Article
February 2002

Deploy And Deliver:
Media Servers And Softswitch-Enabled Services In The New Network


Back in the early-to-mid-1980s, there was a lot of debate in the world of telephony over a proposed new architecture. This new architecture proposed smart endpoints as new building blocks -- endpoints that could control the network to create their own features. Companies that made terminals were excited by this idea. Early adopters were hyped up, and both trade journals and consumer electronics magazines wrote about the Integrated Services Digital Network (ISDN) as though it were the greatest thing to ever happen in communications.

Somewhere along the way, that train derailed.

I remember speaking with many network executives about the promise offered by ISDN at the time. Each of them made similar comments, �You�ll never put that in my network. If the consumer can create the services, then I can�t bill for them, and the real money in networks is the services. Minutes are a commodity business.�

Today, we face a similar question: How will the networks make money? If SIP endpoints that take removable media become the norm -- if I can buy the next great service at the local electronics store and just plug it into my phone -- what�s in it for the networks?

The need for network services will never go away. No matter how smart the endpoints, no matter what capabilities some will have, the basis for the services the consumer will buy will be the network capabilities. There are simply too many features that are better handled by the network.

There are also many unresolved issues with the smart endpoint model. How can I upgrade all the endpoints of my network? Will Microsoft�s version of the feature work with AOL�s version? Will the version sold in France work with the version sold in China, or will language and addressing differences cause incompatibilities? If the two ends are using different, incompatible codecs (a-law/�-law, G.723/G.729), where will transcoding occur?

Issues that affect the ability to move services to the edges include security, privacy, and the FCC�s CALEA requirements. While there are solutions proposed for meeting these requirements, not all vendors have embraced them.

For some kinds of terminating service features that only affect one subscriber, some of these questions won�t apply. For others, they are very important. Bandwidth is not unlimited, mixing and transcoding services are not free, or even all that easy. So how will all of this be done?

In the network model generally used throughout the International Softswitch Consortium (ISC) and other standards bodies, there are three components involved in services and applications: the feature server, the application server, and the media server.

The Feature Server
The feature server, often built into a call agent/softswitch, is the functional component that provides call-related features. Capabilities such as call forwarding, call waiting, and last call return, if implemented in the network, are implemented in the feature server. The feature server works closely with the call agent, and may call upon the media server to provide these services. These features do not require the subscriber to explicitly request them but tend to be triggered within the call handling logic.

Take the last call return feature. While there are at least two common variants on this feature in the PSTN today, the one we are describing is when the user picks up the phone, dials *69, and hears, �The number that last called you was 303-555-1212. Press 1 to return this call.�

This is a feature server feature. When the call agent sees the dial string *69, it triggers an invocation of the feature server function. The feature server examines its database, finds the user and the caller identification of the last call, then asks the media server to play the announcement and collect a digit. When the media server returns a �1�, the feature server instructs the call agent to establish a call between the user and the party that last called that user.

The Application Server
The application server provides call-termination or subscriber-independent applications. These include such capabilities as local number portability, free-call routing resolution, conference bridge services, and unified messaging. The PSTN versions of these applications are frequently known as 800 numbers in North America. The subscriber has to explicitly place a call to the application server.

Application server applications are of two general types, those that are signaling only, and those that involve media manipulation. The former are often related to routing resolution -- local number portability, free-call routing, and other services where the dialed number must be translated to a routable address. An example involving media manipulation would be conference bridge applications, something with which most business people are very familiar. The call steps include:

  1. Each user calls in on a pre-published number.
  2. The dialed number is translated into an IP address and named the endpoint of the application server, and the call is routed there.
  3. The application server connects to the media server, instructing it to play a greeting and collect the conference number.
  4. The media server returns and conference number, and the application server instructs the media server to play a prompt to collect the authorization number.
  5. If the digits collected are correct, the application server tells the media server to move this call to a particular conference bridge.

The Media Server
According to the ISC Application Group�s framework document, the media server provides building blocks for the feature server and application server to use.

Typical building blocks include announcements, interactive voice response (IVR), conferencing (or bridging), play and record, speech recognition, text-to-speech, and facsimile. These building blocks are generic and can be applied, unchanged, to a large variety of services.

A media server�s building blocks are used by application service logic in an application server or softswitch to provide services requiring interaction with the media or bearer path. When an application requires media processing, it instructs the media server and far-end devices to set up connections to each other and then invokes one or more building blocks on the connection(s). When the need for media processing is finished, the application can withdraw the media server from the connection(s).

There is agreement that the media server should not maintain any call state or feature/application logic in the network. It serves instead as a service device, used as needed by network elements that do have the feature or application logic within them.

Today there are several standards and proposals for standardization regarding the question of media server interfaces. For some, control protocols such as MGCP or H.248 work best, and others want to see peer-to-peer protocols such as SIP adapted for this purpose. Let�s explore these alternatives.

MGCP (IETF RFC 2705*, PacketCable NCS) and H.248/Megaco (ITU, IETF RFC 3015) are functionally equivalent protocols that have been proposed by different bodies, containing similar packages of control protocols that are designed for media server control**. This control is a tightly coupled control interface. The application server maintains tight management of the media server. The application server orders the media server to generate a signal on a particular RTP stream, and tells it to collect digits and report back to the application server. The media server never determines which announcement to play, nor does it determine what action a particular digit collection event should cause. This means that the application or feature logic must handle the details of the intended service.

SIP has also been proposed for this interface. SIP currently cannot request that signals be generated or that events be reported. However, SIP is a useful transport protocol for carrying other application control logic such as VoiceXML scripts, especially since the entire service or application can be contained in a single script. Still, there are issues to be resolved for interactive services including reporting which are still being debated. It appears that event reports will require either significant extensions to SIP or the use of �HTTP GET/POST� operations -- an entirely different protocol. Since SIP provides a loose coupling between the application server and the media server, the necessary involvement by the application server is significantly decreased.

Packages for MGCP and Megaco that support the delivery of scripts to the media server have been included in recent offerings, and this allows these control protocols to function within loosely coupled architectures. With their existing event reporting capabilities, no extensions are needed to support the transport of VoiceXML scripts, Java applets, or other service logic units, and the reporting of their results back to the application or feature server.

Because of issues not related to the intelligence of the terminal, including access bandwidth, security and the coordination of upgrades, network services will be central to the next generation network. The three functional components of the network architecture that provide services and features to subscribers have been defined, and the interfaces between them are well understood. Some network operators and some feature/application providers prefer a tight coupling to the media devices, while others prefer a looser coupling. Ultimately both will exist and only the service providers will determine which exists in their particular network.

* The evolution of RFC 2705, draft-andreasen-mgcp-rfc2705bis-01, has taken substantial input from the ISC Device Control Work Group and from the PacketCable NCS Committee. The definition of the packages for MGCP general operation, draft-foster-mgcp-basic-packages-01, is also substantially a work product of the ISC Device Control Work Group.

** See RFC 2897, which has evolved into the PacketCable Audio Server Control Specification, pkt-sp-asp-I02-010620, and Annex M.1 of H.248, which was derived from the PacketCable work.

Don Stanwyck is the vice president for technologies and standards of IP Unity, an emerging technology leader offering a carrier-grade services platform for enhanced voice and telephony applications over any telecommunications network. The company�s media servers, applications servers, prepackaged enhanced services, and application development partners allow carriers to offer new services for both next-generation and legacy networks. IP Unity is on the Web at www.ipunity.com.

[ Return To The February 2002 Table Of Contents ]

Today @ TMC
Upcoming Events
ITEXPO West 2012
October 2- 5, 2012
The Austin Convention Center
Austin, Texas
The World's Premier Managed Services and Cloud Computing Event
Click for Dates and Locations
Mobility Tech Conference & Expo
October 3- 5, 2012
The Austin Convention Center
Austin, Texas
Cloud Communications Summit
October 3- 5, 2012
The Austin Convention Center
Austin, Texas