Deploy And Deliver:
Media Servers And Softswitch-Enabled
Services In The New Network
BY DON STANWYCK
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?
IT�S ALL IN THE NETWORK
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?
WHAT DOES THE NETWORK LOOK LIKE?
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:
- Each user calls in on a pre-published number.
- The dialed number is translated into an IP address and named the
endpoint of the application server, and the call is routed there.
- The application server connects to the media server, instructing it
to play a greeting and collect the conference number.
- The media server returns and conference number, and the application
server instructs the media server to play a prompt to collect the
authorization number.
- 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.
SIP or MGCP?
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.
SUMMARY
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 ]
|