Advanced VoIP Applications New application deployments for VoIP networks can use a variety of network protocols and architectures. The use of MGCP and SIP are possible solutions and this paper discusses the design and tradeoffs of each approach. Draft 1.0 February 25, 2001 Glen Gerhard White Paper 1
Advanced Intelligent Network applications Today s Advanced Intelligent Network (AIN) provides many useful features common to callers today. These features include Caller ID, Voice Mail, Call Waiting, Pre-and-post paid calling cards, 911, Call Blocking, and Auto Call-back to name a few. These features represent years of development and investment by vendors and service providers, and are delivered via a proven circuit switched infrastructure. The network architecture is shown in general format below: SS7 Signaling Network Class-5 End Office Class-4 Tandem Residential, business or Centrex subscriber GR-1129 TCAP Se rvice Control Point Voice Mail Server Intelligent Peripheral A subscriber in this network is provided primary dial tone and feature set by the Class-5 End Office switch. This system provides the basic call control features such as Dial Tone, Call Waiting, forwarding to Voice Mail, and billing. It passes calls to the Class-4 Tandem switch as needed based on the dial plan in the region. For messaging, a local mail server is usually employed for the subscriber base in the region. The calls requiring other advanced features such as 911, Local Number Portability, or 800 service are forwarded to a TCAP Service Control Point (SCP) for servicing when the proper Trigger Detection Points are met. A connection is established from the subscriber to an Intelligent Peripheral when media output and input analysis is required. Once the information is processed, with the help of a backend DataBase, the call can then be rerouted and the subscriber connected to the proper destination with the proper billing. Although this system is proven and widely deployed it is inefficient in terms of port and equipment utilization. A connection must be established between the End Office Switch and the Tandem switch as well as a connection from the Tandem to the SCP, or the Tandem to the IP. Numerous devices and paths could be required for any given call. It also mandates that the Intelligent Peripherals, Voice Mail Server, and some SCP have telephony interfaces as well as database access. This creates an expensive system which has potential capacity constraints. White Paper 2
VoIP Advanced Applications The migration to VoIP networks is being driven by a number of factors; the key concept is that of advanced services. These services will be able to provide all the existing AIN features and add new ones based on IP services. A key aspect of the new VoIP infrastructure is that there is no need to build circuit switched connections between the devices, which reduces the cost of providing the services, and simplifies deployment. All systems, except the media gateway itself, require only IP interfaces. The IP interfaces of these devices can provide the telephony signaling as well as the media interfaces. This provides for simpler distributed signaling and processing capability, reduces the cost of components, and speeds up application development and deployment. The new IP based applications can be delivered in a variety of methods depending upon their complexity. For simple applications the Media Gateway Controller (MGC) can provide the application intelligence in a very distributed fashion. The MGC provides call control to the user via the Media Gateway with a client/server protocol called MGCP. The MGC controls all routing and call control to the devices within its MGCP domain. This functions very similarly to a Class-5 End Office switch and provides the same features one would expect on a standard POTS line. However it also has the ability to play tone and announcements to a caller, as well as gather digits from the caller. This provides capabilities similar to an SCP or Announcement Server for simple applications. These features are provided by the capabilities defined in MGCP and H.248. An example application and call flow is shown below. In this application a caller incorrectly dials a number and receives a message such as: Your call cannot be completed as dialed. EXAMPLE 1. MEDIA GATEWAY PROVIDED PROMPTS Class-4 or 5 MGC Softswitch Residential, business, or Centrex subscriber MGCP Media Gateway White Paper 3
Media Gateway Media Gateway Controller RQNT (R: hd) 200 OK NTFY (O: hd) The user picks up telephone and the MG notifies the MGC of the event. The MGC asks for the dialed digits. The caller dials an incorrect number for directory assistance (1-619-555-121). 200 OK NTFY (D:1619555121) RQNT (S:"unable_comp_call") NTFY (O:hu) DLCX () The MGC could return a fast busy signal but chooses to play an announcment. The announcement file is called "unable_comp_call" and is stored on the MG. While the file is being played the caller hangs up. The MGC returns the port to an idle state. The file can be any URL name but must be identified explicitly in the RQNT message from the MGC The above scenario is fairly simple and saves bandwidth on the network. Since the announcement is stored on the MG there is no bandwidth required except the MGCP signaling shown. This is effective for small networks with minimal prompting requirements. However due to the need for coordination of the file systems of the MGs and the messaging of the MGCs it can create administrative overhead. When networks grow to a certain size it becomes much easier to administer a separate Media or Announcement Server. This centralizes the configuration/maintenance for the audio files and allows all gateways in the domain to use the same source files. The calls are connected as though the Media Server was simply another endpoint, but in this case the endpoint is instructed to play a file using the same messages used in the above example. A network topology using a Media Server is shown below. White Paper 4
EXAMPLE 2. MGCP ANNOUNCEMENT SERVER Class-4 or 5 MGC Softswitch MGCP Media Gateways Residential, business, or Centrex subscriber Announcement Server The approach shown above permits many MGs to share the file information stored in the Announcement Server, so their local files are not used. In general this will be made available to all MGs within the direct control of the MGC. This is called the MGC s domain, and it controls all ports and all calls within its domain. Nonetheless this approach does require the MGC to be aware of the Announcement Server and know at what point to refer the caller to which prompt. This logic is fairly simple in the case of a misdialed number but is more difficult when the application requires more complexity and interaction with the caller. In the case of an Interactive Voice Response (IVR) server providing calling card service the logic for the interaction is much greater and is not feasibly controlled by an MGCP endpoint. In this case the Announcement Server has the ability to play announcements and retrieve DTMF tones, but due to the nature of MGCP, cannot easily control a call. This would be analogous to a POTs subscriber attempting to transfer a call on a Class-5 End Office switch, while maintaining control of the call. In the case of a Calling Card application the MGC can intercept the callers DTMF input, but the logic must be tightly coupled with the prompts of the Announcement Server. In practice the coordination of this is beyond the capability of most MGCs and the function is moved onto a more specialized platform. This is usually done with a SIP Application Server. White Paper 5
Scaling Networks and Adding Intelligence As the VoIP networks grow they require a centralized control system for the specialized applications that become incorporated into the network. SIP provides for a lightweight and flexible protocol and architecture for this type of application server. In the case of a SIP Application Server the MGC passes the call to the appropriate server which handles the call logic required for the call. In the case of misdialed call for instance the MGC can route the call to the server with a specific URI on the server and tells the server to play the appropriate message. All routing is handled similarly by the MGC, reducing the logic and processing requirements. Since the MGC can load level between a number of SIP Servers it is very beneficial to minimize the loading on the MGC and maximize the loading on the SIP Servers. This provides a more scalable End Office environment with a single MGC routing calls to many redundant SIP Servers. In addition the Application Server is available to take calls from any MGCP Domain in the network and can provide a centralized point for database access when used in advanced applications such as IVRs. The database activity can also be run in a distributed fashion depending upon the back end database selected. An example of the misdialed call is shown below. EXAMPLE 3. SIP APPLICATION SERVER Class-4 or 5 MGC Softswitch SIP Application Server Residential, business, or Centrex subscriber MGCP Media Gateways White Paper 6
Media Gateway Media Gateway Controller SIP App Server RQNT (R: hd) NTFY (O: hd) NTFY (D:1619555121) CRCX (M:Receiveonly) The user picks up telephone and the MG notifies the MGC of the event. The MGC asks for the dialed digits. The caller dials an incorrect number for directory assistance (1-619-555-121). INVITE:To:bad_dog@sip.ptt.com OK: MDCX (IP:216.188.94.55) RTP Media Announcement: bad_dog NTFY (O:hu) DLCX () BYE: The MGC could return a fast busy signal but chooses to play an announcment. The announcement file is called "bad_dog" and is stored on the SIP Server. While the file is being played the caller hangs up. The MGC returns the port to an idle state. The file can be any URL as in http:// scripts.example.net/bad_dog/ ptt.com [note- ack messages left out for clarity] The application here is very simple, however in more advanced applications the requirement for full call control becomes more critical. In some applications the call must be returned to the Application Server due to lack of pre-paid funds and the caller given the chance to recharge their calling card. This requires a well-written script application to intelligently handle the unpredictable range of responses, as well as database read/write capability. It requires the IVR to have complete call control for re-establishing calls in progress, and providing prompts based on database information. It is important to note that the RTP media stream can be originated or terminated by the Application Server. A unified messaging server for instance can receive RTP media traffic from a gateway and perform many different operations on this media. The media can be stored as speech, and it can be retrieved as speech as in normal voice mail. It could also be converted to an email message or the Application Server could even perform speech recognition on the inbound media. Designs have been put in place for an entire speech driven web application; SIP will be used to access these very intelligent voice assistants and voice browsers. The call flow for such a call is shown below but it utilizes the same fundamental and simple equipment listed in the above application. Whatever control logic is used, such as XML or CPL, the only thing that is changed is the complexity of the call flow and the application. In this way a single SIP Application Server (or Server Farm) can manage to perform many application within a network, and have those application easily and simply changed-out or upgraded. White Paper 7
Media Gateway Media Gateway Controller SIP App Server RQNT (R: hd) NTFY (O: hd) NTFY (D:18009668372) CRCX (M:Receiveonly) The user picks up telephone and the MG notifies the MGC of the event. The MGC asks for the dialed digits. The caller dials a pre-paid calling card 800 number. They are connected to the PTTs SIP platform. INVITE:To:call_card@sip.ptt.com OK: MDCX (IP:216.188.94.55) RTP Media Announcement: calling card greeting DTMF Input from user via RFC2833 REFER: To: 18586252400 MDCX (IP:216.188.94.58) The MGC routes the call to the PTTs SIP platform and directs it to the calling card application. It could include such information as ANI if available. The user inputs their card number and the SIP server performs a database querie to authorize the call. Once validated the caller is prompted for the destination phone number. That number is passed back to the MG for normal least cost routing RTP Media Stream between parties REINVITE: prompt@sip.ptt.com MDCX (IP:216.188.94.55) RTP Media Announcement: one minute warning! REINVITE: 216.188.94.58 The account of the user runs out of money and the application reinvites the caller back for a "one minute warning" prompt. After the prompt the caller is reconnected to the call MDCX (IP:216.188.94.58) RTP Media Stream between parties NTFY (O:hu) DLCX () At the end of the conversation the caller hangs up, and the application is advised of the termination of the call. BYE: White Paper 8
Nuera Solutions Nuera provides many parts of the new telecomm infrastructure. The GX-8 and GX-21 Media Gateways and the SSC Media Gateway Controllers are essential products for Nuera. However the new phone system must be much more flexible than the old, and that necessitates a standards based interoperability focus for all equipment vendors. Nuera helps lead the way in this way too, contributing and participating in many of the VoIP standards bodies. The solution sets outlined in this paper are just the starting point from which bright new teams and companies will grow new applications. Nuera has demonstrated interoperability with several different application server vendors. These include Iperia for unified messaging; Dynamicsoft and Longboard for advanced SIP routing. Nuera recommends Telephony Experts, Apex, and isoftel for calling card and billing applications, and Hearme for SIP Multiparty Conferencing Units. The list of solutions will continue to grow rapidly in the near future. Visit these and other partners at http://www.nuera.com/insta/. SIP Application Server Farm Announcements Messaging Center Calling Card Voice Browser Residential, business, Or Centrex subscriber Class-5 Softswitch MGCP Media Gateways Class-4 Softswitch White Paper 9