Feature Articles
Customer News
Support Tip
Articles and Publications
Spotlight Events
SUBSCRIBE I UPDATE PROFILE I PAST ISSUES I READER SURVEY I DOWNLOAD PDF I RSS
By Brough Turner, SVP & CTO
This was the title of a panel I participated in at Spring VON 2007. I reported on what NMS Communications has learned so far in migrating our MyCaller™ Ringback application from the Intelligent Network (IN) implementation that’s been deployed by nearly 30 operators today, to an IMS version capable of working with Middle East operators who have “IMS” networks from major European equipment providers.
For the impatient, here are the takeaways.
- It’s very early days for IMS. Today’s “IMS” networks are combinations of SIP infrastructure with 3GPP Release 4 softswitch-controlled voice service.
- IMS is about connection control, only. Only part of your application has to change. For MyCaller, ~90 percent of the software remains the same.
- IMS enables multimedia ringback, i.e. video! So there is significant new functionality, versus today’s audio-only ringback.
- Parallels with Intelligent Network are striking!
- Most application–specific data remains outside of IMS. In particular, operators do not want to add data fields to their Home Subscriber Server (HSS).
- Application–specific MRFs make sense. Operators tend to avoid sharing resources between diverse applications. And, for rich media, application–specific MRFs can be more cost-effective.
- Operators await 3GPP Release 7. At least anecdotally, several operators have suggested that 3GPP Release 7 is the first complete, stable, and consistent version they will fully deploy.
Ringbacks, The Application
Ringbacks are a service where you get to specify what callers hear in place of traditional “ring, ring” sounds, while they wait for you to answer. Why is there a market for such a service? There is a market because subscribers want to prove to their friends that they are cool or, in my case, a classical music die-hard.
Ringback systems must…
-
accept audio (and now video) clips from multiple content sources,
-
manage that content, offer it for sale to subscribers via web, WAP, IVR, and/or SMS dialogs,
-
manage “albums” of content that subscribers have purchased,
-
provide facilities for subscribers to define who hears what content based on caller ID, time and date, and so on,
-
and then finally play the appropriate content as calls are made.
Only the last step involves any IN or IMS complexity.
Most of the ringback application is based on a conventional three–tiered IT architecture, i.e., database core, business logic tier, and presentation tier. Moreover, the majority of operator–specific integration issues have to do with the operator’s IT infrastructure—OSS/BSS, network management, and the like. It’s no wonder that less than ten percent of the MyCaller ringback code base is impacted by IMS.
Migration in Two Stages
NMS decided to migrate in two stages. The first stage is IMS enabling the current MyCaller ringback system. The second stage leverages as much of the evolving IMS infrastructure as possible. We refer to these stages as “IMS-enabled” and “IMS-native.” To see how this works, Figure 1 shows a high-level view of the current (IN-based) system.
Figure 1: MyCaller IN-Based System
IMS-Enabled MyCaller
The first stage of IMS migration is straight forward. Figure 2 illustrates an implementation in an IMS network where the IMS application server is a WebLogic SIP Server from BEA. As you can see, the parallels between IN and IMS are striking.
The provisioning interface to the HSS is slightly different than that of the HLR, but the functions and architecture are identical. IN triggers are replaced by IMS filter criteria. There is work to be done developing call flows and implementing them on the IMS application server, but the functions and complexity match those of call flows on an Intelligent Network SCP.
The MyCaller Intelligent Peripheral becomes the MyCaller MRF. It’s still a media server, only now it’s invoked by SIP instead of ISUP signaling over SS7, and it plays media streams over RTP/UDP/IP rather than over T1/E1 trunks. The specific choice of media is still done by application code on the MyCaller Subscriber Server, which is unchanged.
An added advantage of the IMS-enabled system is that one can mix TDM and IP nodes in larger networks during a staged transition.
Figure 2: IMS-Enabled MyCaller
Issues for IMS-Native MyCaller Ringback
A pure IMS implementation should be able to leverage IMS to minimize costs. Unfortunately today’s realities muddy the picture.
Can we eliminate the MyCaller Subscriber Server by moving its functions to the IMS application server (AS)? Maybe, though not in a standard way. The problem is that there is a good amount of data per each subscriber—multiple audio and video clips with complex assignment rules based on caller ID, time, date, rotation rules, special days (birthdays, holidays), and so on. If this subscriber data could be stored in an extension to the HSS, there would be a standard way for the AS to access the data and execute the rules. However, it appears that operators do not want to tamper with the data fields supplied by their HSS vendors. The preferred solution is to have the AS interrogate the MyCaller Subscriber Server and use the result to compose an appropriate command or VoiceXML page for the MRF. This conforms to the IMS specifications but doesn’t reduce the number of boxes or otherwise simplify the implementation.
Can we at least use the network’s standard MRF? Yes, but there are management, performance, and cost considerations. Operators typically qualify one or two specific vendors’ MRFs, but then deploy separate instances for significant applications—one set of boxes as announcement servers, another set for voicemail, and a third for ringbacks. This minimizes finger pointing and simplifies cost allocations.
Typically, the default MRF is ideal for audio applications, like announcements, voicemail, and music ringbacks, requiring expensive upgrades if conferencing, video, or other rich media are needed. In such cases, application-specific MRFs can be much more cost effective.
Finally, for ringbacks, a critical competitive issue is minimizing added post dial delay—the time from when a caller punches in the last digit or hits “Send”, until they hear the ringback media clip. This requires fast response from the Subscriber Servers and Content Servers, typically achieved by caching and low-latency connections. The highest performance and lowest cost is achieved by integrating the content server and content cache into the MRF.
As a practical matter, IMS applications must work with the operator’s default MRF, but application providers are still likely to sell application-specific MRFs.
“R4” today, R7 eventually
IMS was initially defined in 3GPP Release 5 specifications. I was surprised when I first saw the term “IMS R4” in a confidential presentation deck from a major equipment provider. If IMS began with R5, what could “IMS R4” mean? I have heard this term used by field staff (but not corporate) at two major equipment providers as they referred to recently deployed configurations where a 3GPP Release 4 softswitch handled voice traffic and a SIP infrastructure handled new applications, like push-to-talk or video sharing.
Most operators have deployed some form of SIP infrastructure today. But from discussions with their IMS planners, Release 7 is the first version of IMS that is complete enough to meet long-term needs. Certainly, IMS Release 7 is the first version to fully integrate fixed and mobile networks, though Release 7 specifications won’t be frozen until June 2007. It will take at least two years from stable specifications to initial deployments.
So IMS will be a work-in-progress, supporting equipment sales and professional services, for many years to come.
By Maggie Smith, Director, Product Marketing, Developer Platforms
The typical IMS diagram shows numerous elements labeled with curious acronyms, interconnected by interfaces with even more acronyms. However in practical networks, individual IMS elements are usually combined in more cost-effective and application-relevant groups. For example, an infrastructure vendor may include the Media Resource Function Controller (MRFC) as additional software within the Call Session Control Function (CSCF), while leveraging a Media Resource Function Processor (MRFP) capability within the Media Gateway (MGW).
On the other hand, as noted in the previous article, operators typically use dedicated resources to simplify management of complex applications so, for complex media, application-specific Media Resource Functions (MRFs) may be appropriate and much more cost-effective. Thus a video mail vendor may choose to offer video MRFP and MRFC functions in combination with other application-specific components.
In either case, typical IMS application developers need to only worry about a small subset of all the elements and interfaces in the IMS framework. Whether for IMS infrastructure or IMS applications, NMS’s deep understanding of media processing, signaling, and provisioning has lead to a comprehensive product offering for developers facing the task of deploying media-rich applications in IMS networks.
One approach for a dedicated MRFP uses AdvancedTCA (ATCA) components. This can help reduce the cost of the solution without limiting the flexibility for expansion. Because ATCA blades communicate with each other via packet switching fabrics, additional chassis can be seamlessly integrated with minimal reconfiguration. The service provider deploying the application benefits from the differentiation of the ATCA form factor—with its ability to support full redundancy (N+1) and 99.999% reliability.
NMS offers the application designer the MG 7000A—a complete media processor on an ATCA blade ready for such media rich applications as ringback tones, text-to-speech processing, and enhanced multimedia conferencing. Combining high-speed IP packet handling, four Gigabit Ethernet interfaces, high-density DSP media processing power, and optional T1/E1/J1 interfaces, the MG 7000A is a good choice for media applications developed from the ground up.
For applications that require interactive voice and video response (IVVR), advanced scripting languages such as VoiceXML and CCXML can make a critical difference. NMS offers the Vision VoiceXML Server for the development and deployment of complex interactive speech and video applications within IMS networks. Its support of SIP signaling and RTP media facilitate its use in application-specific IMS media functions, as well as in support of standard IMS interfaces like the Mr-interface between the CSCF and the MRF. In addition, the Vision VoiceXML Server’s ability to connect seamlessly with any IP- or PSTN-based terminal device facilitates deployments in hybrid networks during the often protracted period that a network is transitioning to IMS.
The Vision VoiceXML Server conforms to the latest VoiceXML 2.1 specification and includes pre-configured media processing servers that can manage up to 240 audio ports or up to 120 video and audio ports with TDM and IP connectivity installed—ideal for IVVR applications in an IMS environment. In addition to its SIP call support, it also supports handsets conforming to the 3G-324M specification, opening up the applications to PSTN callers.
Specific IMS applications that lend themselves to the Vision VoiceXML Server include:
- Content sharing and see-what-I-see through video blogging and mobile publishing
- Presence and instant messaging services between IP and mobile devices such as Voice SMS
- Streamed video content such as mobile TV services
NMS continues to leverage decades of experience in media proessing and signal processing, SIP-enabled media devices, and web-based development environments to participate in the IMS era. Today’s IN applications can evolve into supported IMS frameworks with the help of products like the Vision VoiceXML Server and MG 7000A ATCA media processing blade for media-intensive IMS applications.
Customer News
The Intervoice EVIP interactive voice response system allows enterprise customers to enhance customer experiences and reduce the costs associated with calls to and from their organization. A comprehensive voice system, EVIP enables enterprises to build, execute, and manage speech applications across the entire enterprise. With Open Access technology on board, the Intervoice system provides desirable and competitive features such as full multi-lingual capability, natural language recognition, barge-in capabilities, and adaptability to virtually any industry, including government, healthcare, retail, telecommunications, and utilities.
“NMS has a solid reputation for quality media processing boards and software. Its Open Access products offer the flexibility and reliability we expect from OEM products used in Intervoice solutions,” said Mike Polcyn, Chief Technology Officer, Intervoice. “Incorporating Open Access technology into our Intervoice Voice Interaction Platform enables us to offer additional connectivity choices to our customers.”
“Intervoice is a true industry leader, and we are proud to have been chosen as an option for their technology,” said John Orlando, Chief Marketing Officer, NMS. “Our Open Access technology is used by the majority of the world’s leading telecom suppliers and has been on the leading edge of media processing technology for more than 20 years. Intervoice’s selection of Open Access is a testament to the quality and commitment of our communications platforms.”
About Intervoice
Intervoice is a world leader in unified communications, providing scalable, switch-independent software, and professional services that power standards-based voice portals, multi-channel IP contact centers, and next-generation mobile-enhanced services. Since 1983, Intervoice solutions have been used by many of the world’s leading banks, communications companies, healthcare institutions, utilities, and government entities. With more than 5,000 customers in 75 countries, Intervoice helps enterprises and network operators stay competitive by offering their customers best-in-class services. Intervoice’s Media Exchange platform, IP contact center software, IMS-enabled messaging products, and custom-built and packaged applications are available on-premise and, selectively, as managed or hosted services by Intervoice. For more information, visit www.Intervoice.com.
|
Support Tip |
Some signaling protocols, such as ISDN, support "overlap sending mode," i.e., the sending of address information in multiple bursts rather than all at once. The application supplies the first digit or digits when originally placing the call and then repeatedly sends additional segments of the digit string, in order. The application also indicates whether a segment of the digit string is the final segment or if more digits are to follow.
Overlapped sending/receiving of digits in the NMS ISDN stack are supported, either at the channelized layer (NCC mode layer 4), or at the ACU messaging layer (ACU layer 3).
This support tip explains how to implement the overlap sending mode at the ACU messaging layer for both the sending and receiving side.
Enabling Overlap Sending
To enable overlap sending, configure the behavior bits as follows:
The application must set CC_USER_SENDING_COMPLETE (0x0002) behavior bit in the out_calls_behavior field in the ISDN_PROTOCOL_PARMS_Q931CC structure upon starting the ISDN stack.
Setting this behavior bit prevents the stack from automatically adding "sending_complete IE" to the outgoing SETUP message and it is up to the application to either add, or not add, the sending_complete IE to the outgoing SETUP.
An incoming SETUP message that is missing a sending_complete IE indicates to the receiving side that more information will follow after the SETUP.
Enabling Overlap Receiving
The application must set CC_TRANSPARENT_OVERLAP_RCV (0x080) behavior bit in the in_calls_behavior field in the stack parms structure (ISDN_PROTOCOL_PARMS_Q931CC).
Setting this behavior bit instructs the stack to send an ACU_CONN_IN to the application even if not all digits have arrived (i.e., sending_complete IE is not present in the incoming SETUP message).
Using Overlap Sending
After setting the appropriate behavior bits and starting the stack, the application needs to do the following:
-
Application builds an ACU_CONN_RQ and fills in all the information including the called party digits (if any) and it sets Acu_conn_rq_sending_complete to 0 (OFF). This ensures that the stack will NOT generate a sending_complete in the outgoing SETUP message.
-
Application receives an ACU_SETUP_ACK_IN, indicating that the stack has received a SETUP_ACK from the called party.
-
Application starts sending the remaining called party digits in one or more calls to ACU_DIGIT_RQ by using Acu_digit_rq_digit_size and Acu_digit_rq_a_digit macros. Also, the application needs to set Acu_digit_rq_sending_complete to:
0 (OFF) if more digits will follow (in a subsequent calls to ACU_DIGIT_RQ), or
1 (ON) if this is the end of called party digits.... no more digits to follow
-
The stack, upon receiving the ACU_DIGIT_RQ, builds an INFORMATION message with the appropriate IEs (i.e., called party IE and, if set, sending_complete IE).
-
Once all digits are sent and accepted by the remote side, the application would receive ACU_CALL_PROC_IN which indicates that the stack has received a CALL_PROCEEDING message from remote side.
-
After that, the normal call control would continue (i.e. call connected, called rejected, etc.).
Using Overlap Receiving
-
Application receives an ACU_CONN_IN to indicates that a SETUP message has been received. Acu_conn_in_called_nb_size and Acu_conn_in_called_nb macros would indicate the number of called party digits received, as well as the digits string (if any). If Acu_conn_in_sending_complete is:
0 ---> more digits to follow
1 ---> no more digits
-
If more digits are expected (i.e., no sending_complete in the incoming SETUP), the application would receive an ACU_DIGIT_IN (which indicates that the stack has received an INFORMATION message) that contains the size and the digit string (Acu_digit_in_digit_size and Acu_digit_in_a_digit). Acu_digit_in_sending_complete would indicate whether more digit are to follow or if that’s the end of the digit string. If more digits are to come, then the application would expect additional ACU_DIGIT_IN that would carry the remaining digits until it gets an ACU_DIGIT_IN with Acu_digit_in_sending_complete set to 1.
- Once the application receives all the digits, it can proceed with the normal call control procedure (i.e., answer the call, or reject the call, etc.).
For additional support tips, visit the Technical Notes section of the NMS web site. |
Articles and Publications
The white paper, Economics of Five-Nines Systems: CPCI vs. AdvancedTCA, compares high availability solutions developed with standards-based cPCI and ATCA components. It details the capital expenses of creating a solution with five-nines availability, and discusses the operational and opportunity cost of service failures and downtime, which are often overlooked during the cost analysis of providing highly available services.
Read the abstract and get your copy of this white paper here.
Spotlight Events
Connect 2007, hosted by NMS, is a series of global conferences that target key business and technical decision makers who are interested in learning about the vital drivers shaping the communications ecosystem—the business issues, the market drivers, the technology challenges, the compelling applications, and the end user demands. This year, events take place in Boston (USA), Guilin (China) and Madrid (Spain).
Connect Americas Conference
October 2-3 Boston, MA, USA
Connect Asia Conference
October 17-18 Guilin, China
Connect EMEA Conference
November 7-8 Madrid, Spain
Click here to register for our
Connect 2007 events .
Call for Speakers
We are currently recruiting panel members for the first day of the Connect conference. If you are interested in speaking, visit our Call for Speakers page for all the details. Have questions? Please contact Christine Krajewski at Christine_Krajewski @ nmss.com or call +1 508 271 1129. Speaker submissions are accepted until May 31.
About the show
At the fourth Communications Developer Conference (previously named the VoIP Developer Conference), developers, product managers, and manufacturers like NMS will learn how to quickly develop new VoIP applications that are in high demand now. The conference will be covering today’s hottest topics, like ATCA, speech, conferencing, WiFi/wireless applications, host media processing, IMS, and SIP.
NMS Participation
We are a Gold Sponsor this year and are exhibiting in booth number #119. We will be showcasing our media processing and network signaling solutions for creating enhanced voice, data, and video applications and services.
NMS Speaking Details
Brough Turner, Senior Vice President and Chief Technical Officer will be speaking at the following sessions on May 16, 2007:
| Time |
Session |
| 8:30–9:15 am |
Voice SMS—Merging VoIP & Mobile to Create A Compelling Service |
| 4:00–4:45 pm |
SIP Track: Connecting Your SIP-Based Hosted Contact Center to the Rest of the World |
Free Exhibit Hall Passes
If you are interested in learning more about NMS’s enhanced applications and services and would like to attend the show, click here to register for your free pass. This pass includes free admission to all networking receptions, all keynotes, and unlimited exhibit hall access for the entire conference. Offer expires May 17, 2007.
Exhibit Hours
Wednesday, May 16
5:45 pm–8:00 pm
Thursday, May 17
11:30 am–4:00 pm
Meeting Request
If you would like to schedule a meeting with an NMS sales representative, click here to fill out a short form. You may also call Janice Manning at +1 508 271 1355.
On May 22, 2007,
NMS will present the web seminar
Connecting Your SIP-Based Hosted Contact Center to the Rest of the World
VoIP has enabled a new generation of hosted contact centers to consolidate physical resources to provide powerful new features for regional business centers and dispersed employee groups. But a significant challenge arises when addressing PSTN connectivity in many parts of the world. Enterprise VoIP gateways typically lack local approvals and totally lack support for SS7 signaling (desirable in many markets, such as Latin America). High-end gateways for international markets are expensive and appropriate VoIP-PSTN services (beyond simple call termination) are typically lacking. How to proceed?
This presentation will show how media and signaling gateway resources can be configured to address global connectivity for hosted enterprise contact centers, explaining the problem and typical solutions, including SIP to ISUP signaling, and how they are adapted for different global conditions.
Who Should Attend
Application developers, network equipment providers, service providers, and systems architects developing and deploying IP-based enhanced services that require connectivity to legacy PSTN callers.
Register now for this web seminar on
May 22 at 11:00 am Eastern / 8:00 am Pacific. |