fundamentals - media resource function

Fundamentals - Media Resource Function

Avaya MS 7.0NN44471-105, 02.01

3 Dec 2010

© 2010 Avaya Inc.

All Rights Reserved.

Notice

While reasonable efforts have been made to ensure that theinformation in this document is complete and accurate at the time ofprinting, Avaya assumes no liability for any errors. Avaya reserves theright to make changes and corrections to the information in thisdocument without the obligation to notify any person or organization ofsuch changes.

Documentation disclaimer

“Documentation” means information published by Avaya in varyingmediums which may include product information, operating instructionsand performance specifications that Avaya generally makes availableto users of its products. Documentation does not include marketingmaterials. Avaya shall not be responsible for any modifications,additions, or deletions to the original published version ofdocumentation unless such modifications, additions, or deletions wereperformed by Avaya. End User agrees to indemnify and hold harmlessAvaya, Avaya's agents, servants and employees against all claims,lawsuits, demands and judgments arising out of, or in connection with,subsequent modifications, additions or deletions to this documentation,to the extent made by End User.

Link disclaimer

Avaya is not responsible for the contents or reliability of any linked Websites referenced within this site or documentation provided by Avaya.Avaya is not responsible for the accuracy of any information, statementor content provided on these sites and does not necessarily endorsethe products, services, or information described or offered within them.Avaya does not guarantee that these links will work all the time and hasno control over the availability of the linked pages.

Warranty

Avaya provides a limited warranty on its Hardware and Software(“Product(s)”). Refer to your sales agreement to establish the terms ofthe limited warranty. In addition, Avaya’s standard warranty language,as well as information regarding support for this Product while underwarranty is available to Avaya customers and other parties through theAvaya Support Web site: http://support.avaya.com. Please note that ifyou acquired the Product(s) from an authorized Avaya reseller outsideof the United States and Canada, the warranty is provided to you bysaid Avaya reseller and not by Avaya.

Licenses

THE SOFTWARE LICENSE TERMS AVAILABLE ON THE AVAYAWEBSITE, HTTP://SUPPORT.AVAYA.COM/LICENSEINFO/ AREAPPLICABLE TO ANYONE WHO DOWNLOADS, USES AND/ORINSTALLS AVAYA SOFTWARE, PURCHASED FROM AVAYA INC.,ANY AVAYA AFFILIATE, OR AN AUTHORIZED AVAYA RESELLER(AS APPLICABLE) UNDER A COMMERCIAL AGREEMENT WITHAVAYA OR AN AUTHORIZED AVAYA RESELLER. UNLESSOTHERWISE AGREED TO BY AVAYA IN WRITING, AVAYA DOESNOT EXTEND THIS LICENSE IF THE SOFTWARE WAS OBTAINEDFROM ANYONE OTHER THAN AVAYA, AN AVAYA AFFILIATE OR ANAVAYA AUTHORIZED RESELLER; AVAYA RESERVES THE RIGHTTO TAKE LEGAL ACTION AGAINST YOU AND ANYONE ELSEUSING OR SELLING THE SOFTWARE WITHOUT A LICENSE. BYINSTALLING, DOWNLOADING OR USING THE SOFTWARE, ORAUTHORIZING OTHERS TO DO SO, YOU, ON BEHALF OFYOURSELF AND THE ENTITY FOR WHOM YOU ARE INSTALLING,DOWNLOADING OR USING THE SOFTWARE (HEREINAFTERREFERRED TO INTERCHANGEABLY AS “YOU” AND “END USER”),AGREE TO THESE TERMS AND CONDITIONS AND CREATE ABINDING CONTRACT BETWEEN YOU AND AVAYA INC. OR THEAPPLICABLE AVAYA AFFILIATE (“AVAYA”).

Copyright

Except where expressly stated otherwise, no use should be made ofmaterials on this site, the Documentation, Software, or Hardwareprovided by Avaya. All content on this site, the documentation and theProduct provided by Avaya including the selection, arrangement anddesign of the content is owned either by Avaya or its licensors and isprotected by copyright and other intellectual property laws including thesui generis rights relating to the protection of databases. You may notmodify, copy, reproduce, republish, upload, post, transmit or distributein any way any content, in whole or in part, including any code andsoftware unless expressly authorized by Avaya. Unauthorizedreproduction, transmission, dissemination, storage, and or use withoutthe express written consent of Avaya can be a criminal, as well as acivil offense under the applicable law.

Third-party components

Certain software programs or portions thereof included in the Productmay contain software distributed under third party agreements (“ThirdParty Components”), which may contain terms that expand or limitrights to use certain portions of the Product (“Third Party Terms”).Information regarding distributed Linux OS source code (for thoseProducts that have distributed the Linux OS source code), andidentifying the copyright holders of the Third Party Components and theThird Party Terms that apply to them is available on the Avaya SupportWeb site: http://support.avaya.com/Copyright.

Trademarks

The trademarks, logos and service marks (“Marks”) displayed in thissite, the Documentation and Product(s) provided by Avaya are theregistered or unregistered Marks of Avaya, its affiliates, or other thirdparties. Users are not permitted to use such Marks without prior writtenconsent from Avaya or such third party which may own the Mark.Nothing contained in this site, the Documentation and Product(s)should be construed as granting, by implication, estoppel, or otherwise,any license or right in and to the Marks without the express writtenpermission of Avaya or the applicable third party.

Avaya is a registered trademark of Avaya Inc.

All non-Avaya trademarks are the property of their respective owners,and “Linux” is a registered trademark of Linus Torvalds.

Downloading Documentation

For the most current versions of Documentation, see the AvayaSupport Web site: http://support.avaya.com.

Contact Avaya Support

Avaya provides a telephone number for you to use to report problemsor to ask questions about your Product. The support telephone numberis 1-800-242-2121 in the United States. For additional supporttelephone numbers, see the Avaya Web site: http://support.avaya.com.

2 Fundamentals - Media Resource Function 3 Dec 2010

http://support.avaya.com

http://www.avaya.com/support/LicenseInfo

http://support.avaya.com/Copyright



Contents

Chapter 1: New in this release.................................................................................................5Features............................................................................................................................................................5Other changes...................................................................................................................................................5

Chapter 2: Introduction.............................................................................................................7

Chapter 3: Overview..................................................................................................................9Supported MRF functionality...........................................................................................................................10Billing/Charging...............................................................................................................................................11Avaya MS Protocol Support............................................................................................................................11Charging service.............................................................................................................................................12Avaya MS Application Integration...................................................................................................................13Deployment.....................................................................................................................................................13Hosted model..................................................................................................................................................13Delegated model.............................................................................................................................................13Charging Models.............................................................................................................................................14Post-Paid Off-Line...........................................................................................................................................14Pre-call scenario.............................................................................................................................................15Post-call scenario............................................................................................................................................17Sending ACR(Event) independent of call context...........................................................................................17Description of the messages...........................................................................................................................17Example..........................................................................................................................................................19Charging mechanisms....................................................................................................................................20Diameter WSDL..............................................................................................................................................20Media control...................................................................................................................................................63URI support.....................................................................................................................................................63Announcements..............................................................................................................................................63Dialog..............................................................................................................................................................64Conference......................................................................................................................................................64

Chapter 4: High-level architecture.........................................................................................65Components and relationship to each other...................................................................................................65User Agent phones.........................................................................................................................................66CSCF..............................................................................................................................................................66P-CSCF...........................................................................................................................................................66I-CSCF............................................................................................................................................................67S-CSCF...........................................................................................................................................................67Billing Servers.................................................................................................................................................67Connections between components.................................................................................................................67Diameter for Billing Servers interaction...........................................................................................................68SIP for CSCF interaction.................................................................................................................................68Sr interface for Application Server interaction.................................................................................................68

Chapter 5: IMS control............................................................................................................69Mr interface.....................................................................................................................................................70Sr interface......................................................................................................................................................70

Chapter 6: Media control........................................................................................................71Announcement service....................................................................................................................................71

Fundamentals - Media Resource Function 3 Dec 2010 3

Dialog service..................................................................................................................................................72Conference Service.........................................................................................................................................72Supported parameters for each service..........................................................................................................74List of errors and handling...............................................................................................................................75Media provisioning..........................................................................................................................................77Configuring media provisioning.......................................................................................................................78Maximum announcement for each Request...................................................................................................79Using mmf namespace...................................................................................................................................80

Chapter 7: Charging control...................................................................................................83Charging operation..........................................................................................................................................83Charging Trigger Function...............................................................................................................................88Charging Event Retransmission......................................................................................................................89

Chapter 8: MRF commissioning.............................................................................................91MRF configuration procedures........................................................................................................................91Configuring SIP routing and domains.............................................................................................................92Configuring diameter.......................................................................................................................................93Configuring MRF OM collection......................................................................................................................94Configuring MRF log collection.......................................................................................................................94Configuring Advanced Engineering Parameters.............................................................................................94

Chapter 9: Operational Measurements reference................................................................97Counters..........................................................................................................................................................97Gauges............................................................................................................................................................98

Chapter 10: Logs reference..................................................................................................101Event Logs....................................................................................................................................................101Trace logs......................................................................................................................................................102Diameter Stack logs......................................................................................................................................102

Chapter 11: Alarms reference...............................................................................................105

Chapter 12: Glossary............................................................................................................107


Chapter 1: New in this release

The following sections detail what's new in Avaya Media Server Fundamentals — Media ResourceFunction, NN44471-105 for Avaya Media Server Release 7.0.

• Features on page 5

• Other changes on page 5

FeaturesThis document is new for Avaya Media Server Release 7.0.

Other changesThere are no other changes to this document.


New in this release


Chapter 2: Introduction

This document provides fundamental information about Media Resource Function (MRF) in the IPMultimedia Subsystem (IMS) core network for the Media Applications Server (Avaya MS).

• Overview on page 9

• High-level architecture on page 65

• IMS control on page 69

• Media control on page 71

• Charging control on page 83

• MRF commissioning on page 91

• Operational Measurements reference on page 97

• Logs reference on page 101

• Alarms reference on page 105

• Glossary on page 107


Introduction


Chapter 3: Overview

Media Resource Function (MRF) in the IP Multimedia Subsystem (IMS) core network refers to a generictrusted node you can use to provide multimodal resource functions. These resource requirements are asfundamental as playing tones and prompts; collecting dtmf digits to more complex service requirementsdealing with speech recognition and synthesis, conferencing, instant messaging, on-demand mediastreaming, and Web portals.

This document describes the use of platform facilities as MRF in IMS. A typical MRF service developmentenvironment mainly consists of the following:

• Program development environment using VoiceXML (VXML).

• Configuration management and audio provisioning using Element Manager (EM) tool.

• Debugging, deployment, and tuning support using various logs, alarms, events, and operationalmeasurements.

In an IMS scenario, additional platform capabilities are provided by Diameter-based charging support,RFC4240-based media control, and Media provisioning. By default, a built-in RFC4240-based service isinvoked and the charging information is automatically forwarded to the servers.

In production, charging a multimedia session is a mandatory requirement for all calls in IMS. The followingprotocols are implemented on Avaya MS:

• Diameter: RFC3588 and other related specification defining transports

• Rf Charging interface: 3GPP, TS32.298, and TS32.299

A series of 3GPP specifications exist for different charging scenarios. In this release, Avaya MS supportsoff-line charging interface Rf, identified by the following scenarios:

• time-measured messages: ACR(Start), ACR(Interim) and ACR(Stop)

• asynchronous messages: ACR(Event)

The time measured messages are identified by the elapsed time between a session set up and tear down.Typically an end-to-end session establishment is identified by ACR(Start) message while the session teardown is identified by ACR(Stop) message. During the session, the ACR(Interim) message is used at anegotiated interval. The time measured messages are automatically sent on behalf of the applicationsconfigured to do so, which also includes ACR(Event) for failure handling during call set up scenarios.

One time charging requirements are associated with one time end user events such as downloading aparticular file or streaming a premium event. These type of events are asynchronous in nature. Theseevents are categorized as asynchronous events and identified as one time charging during a session.There can be multiple one time events. Each event is charged using one ACR(Event) message. In theAvaya MS environment, a VXML application can use a web service operation for this purpose in parallel toan ongoing time measured charging.

RFC4240 protocol support is partly provided by a packaged application based on Avaya FSM scriptingengine. Call Session Control Function (CSCF) or Application Server (AS) IMS identities can signal Avaya


MS as a MRF to use media resources. You can develop supplementary services on application serversthat can command a MRF using RFC4240 controls using S-CSCF for basic services like announcement,dialog, and simple conferencing.

The Avaya MS EM tool is used to provision audio requirements either interactively or in the batch mode.The RFC4240 packaged application leverages the existing content store infrastructure to locate and usethe media. This implementation is compatible with media management policies in the MCS family ofproducts.

Navigation

• Supported MRF functionality on page 10

• Deployment on page 13

• Charging Models on page 14

• Charging mechanisms on page 20

• Media control on page 63

Supported MRF functionalityMRF brings the flexibility of leveraging all the capabilities of Avaya MS into IMS by supporting athe following fundamentals of IMS goals–Guaranteed QoS, Integrated Multimedia Services,and Common Charging. IMS is realized by layered architecture (media, control, and serviceplanes) that identifies the standard components participating in these layers. The functionalityof Avaya MS MRF can be logically distributed into various planes depending on the functionalityhosted on it. In general, MRF serves in the control plane with its controller (MRFC) functionsthat include the signaling interfaces with CSCF, AS, and Billing Domain while the mediaprocessor (MRFP) component is responsible for interfacing end-to-end multimediaconnectivity in the media plane. Avaya MS implements generic functions of a stand-alonemedia server that are available as packaged applications built-in with the platform or as anopen, standard VXML programming environment where specific services can be developedand deployed.

In IMS terminology, MRF implements the Charging Trigger Function (CTF). The purpose ofCTF is to send various charging messages to the Charging Data Function (CDF),synonymously used as billing servers or peer hosts.

Overview


Billing/Charging• Avaya MS Protocol Support on page 11

• Charging service on page 12

• Avaya MS Application Integration on page 13

Avaya MS Protocol SupportIn the following diagram, Avaya MS is connected to multiple CDFs on different realms(domains). A peer host from the Avaya MS is associated with exactly one route. Thus, multipleroutes are associated with one domain.

Figure 1: CDF routing

The key idea of a charging is to forward charging messages to a particular peer host within acluster in a destination realm as described in the preceding diagram. To MRF, a cluster of peer

Billing/Charging


hosts (CDFs) are associated with a realm, as it routes the messages to one server using aroute. MRF supports any number of routes. The destination realm is extracted from the To:header in the Invite message. The charging message is forwarded to a peer host that isavailable in the cluster at that instant. Identification of a peer host depends on the followingfactors:

• IP address of the CDF as configured using EM

• content of the P-Charging-Functions header in the Invite message

• failover/failback scenario at the point of time

Routing to a CDF is based on the assumption that every CDF in a route is a potential alternativeserver by default. This means, all the servers within a realm are capable of receiving messageson behalf of the other in case of failures of a particular server or a number of servers. As long asthere is one server up within the cluster, the messages are routed to that server. This routingscenario is the default. However, the choice of servers for routing is dependent on the IPaddress. The server with lowest IP address provisioned is tried first; next the following IPaddress and repeat until the list is exhausted. The default routing behavior is guaranteed atevery restart of DiamC component.

The content of the P-Charging-Function-Addresses SIP header overrides the default routingbehavior. The routing order follows the same order as available in that header. If the numberof servers in this header is less than the statically configured routes, then in case of failure,other routes are tried as described in the previous paragraph.

For example: if Avaya MS is configured with four servers (A, B, C, D; where A has the lowest IPaddress and D being the highest), the routing takes place as follows:

By default, the route is taken as A, then B if A is not available, then C if A and B are not available,then D if A, B and C are not available.

With P-Charging-Function-Addresses, if it contains B, A then the route will be taken as B thenA. If B and A are not available, then Avaya MS will route the message starting from C then D. Ifthe header contains B, C, then the routing starts from B then C. In case both B and C are notavailable, then the routing is A then D. If the Avaya MS receives a CDF address in the P-Charging-Function-Addresses and there is no static route, then it will be stored as a stalerecord if the archiving is enabled. If a peer connection goes down, a periodic reconnectionattempt is made at a default interval of 30 seconds (Tc timer, RFC3588).

Charging serviceIn IMS, charging of a service provided by the MRF is implemented using diameter applicationsas mandated by 3GPP specifications. In general a chargeable session has two aspects–time measured and asynchronous. Also, a session that uses the MRF chargeable resource isdivided into prepaid and postpaid categories. The current release of Avaya MS supports thepostpaid category. This means the charges will be made to the user after resource usage. In

Overview


IMS terms, it is realized by the support of a charging application that supports Rf interface.MRF supports this interface.

Avaya MS Application IntegrationThe IMS charging facilities are available to all applications by default. Avaya MS tracks thesession setup and tear down on behalf of any application (VXML or Developer environments). Ifyou enabled and licensed the diameter stack, then the charging information is automaticallysent to the CDF for each session. Additional messages are sent from an application using Webservice through the soap server infrastructure. In each case, the diameter stack sends theinterim messages to the CDF as negotiated with the servers.

DeploymentYou can deploy the MRF using two types of deployment models: hosted and delegated.

Navigation

• Hosted model on page 13

• Delegated model on page 13

Hosted modelThe hosted model of MRF deployment is a one box solution. There are no application serversand everything gets routed directly to MRF. This means the service application hosted on MRFis well-known and takes the full responsibility of charging scenarios independent of applicationservers.

Delegated modelThe delegated model of MRF deployment is an application server driven environment. In thiscase, the application server takes over the media controlling functions. Typically the applicationserver takes the back to back user agent role to drive the MRF using proper signalling androuting.

Avaya MS Application Integration


Charging ModelsThere are two categories of charging models, prepaid and postpaid. Avaya MS supportspostpaid in this release.

Post-Paid Off-LinePost-paid time measured charging is realized by three messages ACR(Start), ACR(Interim)and ACR(Stop) messages. At the start of a session an ACR(Start) message is sent to the billingserver (Charging Data Function–CDF). As long as the session continues, ACR(Interim)messages are sent at a negotiated interval with the CDF. At the end of the session, anACR(Stop) is sent. MRF sends all these messages automatically on behalf of any applicationconfigured to do so. Any one time charging event support is provided by the ACR(Event)message. The application sends this message to the CDF using a web service operation. Anexample of one time charging event is a file download during a session, the operator decides tocharge for this operation. Another example is the streaming of premium content on demandduring a session.

ACR(Event) message can be sent in different call scenarios. In pre-call scenario, it is sentbefore the ACR(Start) begins. A post-call scenario is where the message is sent after the callhas ended or the ACR(Stop) is received. For more information, please seeChargingoperation on page 83 for further explanation.

The basis of offline charging is to generate the following messages during the session. Themeasuring of time begins at media connectivity identified by the Ack message at successfulcall set up. From the charging server perspective, an accounting begins at the receipt ofACR(Start). As the call continues, Avaya MS sends a number of ACR(Interim) messages andany number of ACR(Event) messages. In the scenario illustrated in the following figure, thecaller (UA) disconnects and the call is ended, which in turn is identified by the ACR(Stop)message at the charging server.

Overview


Figure 2: Normal call scenario

Internally within Avaya MS, a call context is associated with the session (call) the applicationis handling. The creation and destruction of the call context is not typically synchronized withthe SIP session. From an application perspective, a call context is created with the session,however, if the session is destroyed due to any reason, the application must complete itshousekeeping and destroy the call context after that. Diameter messaging with the chargingserver has no relevance with call context, but the application developer must consider the callcontext while dealing with the diameter stack because the call context of an application issynchronized with internal states of diameter component to handle the pre- and post-callscenarios.

Diameter messages (AVPs) are created from the Invite headers. For every diametermessage, the content of Invite message must be forwarded to the diameter stack. Toreduce internal messaging traffic within Avaya MS, a unique global session identifier (gslid), a32-bit number, is assigned to a call context. This number is a well-known number associatedwith a call that every participating component in Avaya MS is aware of. For example, to createthe ACR(Start) message, the gslid and the Invite message is sent once to the diameter stack.Messages related to the same call context (including pre- or post-call scenarios), are handledby passing the gslid to the stack.

Pre-call scenarioA pre-call scenario is identified where the ACR(Event) is sent to the server before Ackmessage is received or the media connection is not established. There are two ways to handlethese messages as explained in the following figure.

Pre-call scenario


Figure 3: Pre-call scenario (real time)

In this scenario, a one time event has occurred before the media is established. If you mustsend the ACR(Event) message immediately, then the Invite content must be passed to thediameter stack along with the gslid. The ACR(Event) messages are sent by the application asWeb services operation. This introduces two different modes of ACR(Event) executionschemes.

1. If you must send the ACR(Event) immediately, then the application has to providethe Invite content.

2. The stack buffers the gslid for a certain time on the assumption that ACR(Start) withInvite message comes later to correlate and retrieve the Invite content. Thisintroduces a variation of the message flows as explained in the following figure:

Figure 4: Pre-call scenario (gslid from Invite)

The ACR(Event) is sent after the media establishment and then the ACR(Start) issent as the call context is available at the SIP session establishment.

Overview


Post-call scenarioThe post-call scenario is identified by the location where the call context exists in the applicationwhen the SIP session is destroyed.

Figure 5: Post-call scenario

As the call context is still stored after the session is destroyed both within the application and thestack, ACR(Event) is sent after the call is over. The stack holds the call context controlled bythe application that sends the ACR(Event) in the scenario.

Sending ACR(Event) independent of call contextYou can send the ACR(Event) without the correlation using the Web service. In this case, thestack immediately sends the messages to the charging servers without buffering any gslid.The processing associated with this type of handling is inherently slow and this is notrecommended for normal use.

Description of the messagesThe diameter web service uses the existing SoapServer infrastructure. The operation isidentified by the following table.

Post-call scenario


Table 1: Sending ACR(Event)

SENDING ACR(EVENT)Parameter Optional Description

acrType M Type of the message:GSLID_ONLY orWITH_INVITE

gslid M The gslid in the form:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

sipData C Invite message content

customData O Any string that chargingserver is interested in

acrType

ACR(Event) is an aynchronous message that can be sent by the application at any point oftime. If the application wants to correlate this message with an an ongoing session, the typeis set to GSLID_ONLY. This ensures the IMS related session parameters are shared betweenACR(Start) and ACR(Event) messages.

If the ACR(Event) is sent with WITH_INVITE, then the stack expects the sipData must be filledin correct format. In this case, the stack does not correlate the IMS related session parameterswith any other message with the ongoing session. The application must send the correctcontent of the Invite message in the sipData parameter.

gslid

You must complete this parameter with the gslid generated for the session. For a vxmlapplication, running on Avaya MS, this value is represented by the session variable (associatedwith the call context) “session.com.avaya.ivr.call.id”.

sipData

This parameter is used with the acrType WITH_INVITE. For a vxml application, this value iscreated from two session variables "session.connection.protocol.sip.headers" and"session.connection.protocol.sip.requesturi.toString()". The application must generate andinclude the Invite message in the format described as following.

Important:You must escape the characters ", <, and > as ", <, and > and you must delimit the headers by|. Additional parameters are added starting with mmc_. This procedure is done to ensurecompatibility with Release 1.0. You can remove these in future versions.

Example

to: "[email protected]"<sip:[email protected]>|from:"DisplayName"<sip:[email protected]>;tag=6162b064|call-id:

Overview


NDM1ZjZmYWVlNDhiZTFjYWJlMzNhMTM2NmIzYjU4MWQ.|cseq: 1 INVITE|content-length:428|content-type: application/sdp|via: SIP/2.0/UDP127.0.0.1:35768;received=47.184.231.187;rport=35768;branch=z9hG4bK-d8754z-f349b3346142992b-1---d8754z-|max-forwards: 70|contact:<sip:[email protected]:35768>|allow:INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,NOTIFY,MESSAGE,SUBSCRIBE,INFO|user-agent: X-Lite release 1100l stamp 47546|!mmc_req_uri: sip:[email protected]|mmc_from:"DisplayName"<sip:[email protected]>;tag=6162b064|mmc_to:"[email protected]"<sip:[email protected]>|mmc_user_agent:X-Literelease 1100l stamp 47546|mmc_srv:diamcws|mmc_dom:avaya.com|mmc_secured:false

customData

You can use this optional parameter if additional information that has significance to a peerlevel application cannot be passed by any AVPs defined by a diameter specification. However,the AVP identifier must be approved by the peer user. At present a temporary identifier 12345 isused for this AVP. The final version of this identifier is provided as a patch, if required.

ExampleThe following is a SOAP message example.

Request:<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"xmlns:v1="http://www.nortel.com/xmlprotocol/wsdl/aaa/diameter/v1_0/"><soapenv:Header/><soapenv:Body><v1:SendACREvent><acrType>GSLID_ONLY</acrType><gslid>12345678-1234-1234-1234-123456781234</</gslid><sipData></sipData><customData></customData></v1:SendACREvent></soapenv:Body></soapenv:Envelope>

This example shows a gslid based ACR(Event) message creation. The type of the messageis GSLID_ONLY and the gslid is 12345678-1234-1234-1234-123456781234. This ACR(Event)is treated by the stack as one of the scenarios.

Result:<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP- ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema- instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ns1="urn:masservice" xmlns:ns2="http://www.nortel.com/xmlprotocol/wsdl/mas/oam/v1_0/" xmlns:ns3="http://www.nortel.com/xmlprotocol/wsdl/content_store/v1_0/" xmlns:ns4="http://www.nortel.com/xmlprotocol/wsdl/session_control/applications/

Example


invoke/v1_0/" xmlns:ns5="urn:maswsutilityapi" xmlns:ns6="http://www.nortel.com/xmlprotocol/wsdl/aaa/diameter/v1_0/"><SOAP-ENV:Header/><SOAP-ENV:Body><ns6:SendACREventResponse><ReturnCode></ReturnCode></ns6:SendACREventResponse></SOAP-ENV:Body></SOAP-ENV:Envelope>

A single ReturnCode is defined to identify the status of the request operation. A ReturnCode0 identifies the success of passing the ACR(Event) message to diameter stack. This stacktreats this message identically with the other messages and guarantees the delivery to thebilling servers.

Charging mechanismsThe Diameter Component (DiamC) supports both session-based (ACR[Start], ACR[Interim],ACR[Stop]) and event-based (ACR[Event]) charging using the Rf interface. Whether you mustuse session-based or event-based charging depends on the application logic. As an example,playing a video clip to an end user can be considered as a one time event during a multimediacall. In that case, along with session-based diameter messaging, event-based messaging canbe mixed within the same diameter session. DiamC treats the event-based informationseparately and perform the appropriate messaging with the CDF as indicated by the applicationto report a chargeable event to DiamC.

Diameter WSDL

<?xml version="1.0

Overview


" encoding="UTF-8"?><definitions name="MASDiamCAPI"targetNamesp

Diameter WSDL


ace="http://www.nortel.com/xmlprotocol/wsdl/aaa/diameter/v1_0/"

Overview


xmlns:tns="http://www.nortel.com/xmlprotocol/wsdl/aaa/diameter/

Diameter WSDL


v1_0/"xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/

Overview


"xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"xmln

Diameter WSDL


s:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns:xsd="htt

Overview


p://www.w3.org/2001/XMLSchema"xmlns:ns6="http://www.nortel.com/

Diameter WSDL


xmlprotocol/wsdl/aaa/diameter/v1_0/"xmlns:SOAP="http://schemas.

Overview


xmlsoap.org/wsdl/soap/"xmlns:MIME="http://schemas.xmlsoap.org/w

Diameter WSDL


sdl/mime/"xmlns:DIME="http://schemas.xmlsoap.org/ws/2002/04/dim

Overview


e/wsdl/"xmlns:WSDL="http://schemas.xmlsoap.org/wsdl/"xmlns="htt

Diameter WSDL


p://schemas.xmlsoap.org/wsdl/">

<types>

<schematargetNamespace

Overview


="http://www.nortel.com/xmlprotocol/wsdl/aaa/diameter/v1_0/"xml

Diameter WSDL


ns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"xmlns:SO

Overview


AP-ENC="http://schemas.xmlsoap.org/soap/encoding/"xmlns:xsi="ht

Diameter WSDL


tp://www.w3.org/2001/XMLSchema-instance"xmlns:xsd="http://www.w

Overview


3.org/2001/XMLSchema"xmlns:ns6="http://www.nortel.com/xmlprotoc

Diameter WSDL


ol/wsdl/aaa/diameter/v1_0/"xmlns="http://www.w3.org/2001/XMLSch

Overview


ema"elementFormDefault="unqualified"attributeFormDefault="unqua

Diameter WSDL


lified">

<import namespace="http://schemas.xmlsoap.org/soap/en

Overview


coding/"/>

<element name="Sen

Diameter WSDL

dACREvent">

<complexType>

<sequence>

<element name="acrType" type="xsd:string" minOccurs="0" maxOccurs="1" nillable="true"/><element name="gslid" type="xsd:string" minOccurs="0" maxOccurs="1" nillable="true"/><element name="sipData" type="xsd:string" minOccurs="0" maxOccurs="1" nillable="true"/><element name="customData" type="xsd:string" minOccurs="0" maxOccurs="1" nillable="true"/>

</sequence>

Overview


</complexType>

</element><

Diameter WSDL

element name="SendACREventResponse">

<complexType>

<sequence>

Overview


<element name="ReturnCode" type="xsd:int" minOccurs="1" maxOccurs="1"/>

</sequence>

</complexType>

</element>

</schema>

</type

Diameter WSDL


s>

<message name="SendACREvent">

<part name="parameters" eleme

Overview


nt="ns6:SendACREvent"/>

</message>

<message name="SendACREvent

Diameter WSDL


Response">

<part name="parameters" element="ns6:SendACREventRe

Overview


sponse"/>

</message>

<portType name="MASDiamCAPISendType">

<o

Diameter WSDL


peration name="SendACREvent">

<documentation>Service definitio

Overview


n of function ns6__SendACREvent</documentation><input message="

Diameter WSDL


tns:SendACREvent"/><output message="tns:SendACREventResponse"/>

Overview


</operation>

</portType>

<binding name="MASDiamCAPISendBindin

Diameter WSDL


g" type="tns:MASDiamCAPISendType">

<SOAP:binding style="docume

Overview


nt" transport="http://schemas.xmlsoap.org/soap/http"/><operatio

Diameter WSDL


n name="SendACREvent">

<SOAP:operation soapAction=""/><input>

Overview


<SOAP:body parts="parameters" use="literal"/>

</input><output>

Diameter WSDL


<SOAP:body parts="parameters" use="literal"/>

</output>

</op

Overview


eration>

</binding>

<service name="MASDiamCSendAPI">

<documen

Diameter WSDL


tation>MAS DiamC SOAP API</documentation><port name="MASDiamCSe

Overview


ndAPI" binding="tns:MASDiamCAPISendBinding">

<SOAP:address loc

Diameter WSDL


ation="http://localhost:80/soap"/>

</port>

</service>

</defin

Overview


itions>

Media controlMRF media control is handled by the RFC4240 protocol.

URI supportAvaya MS uses the basic RFC 4240 SIP-based media networks to provide media services.Such services include playing announcements, initiating a media mixing session (conference),and prompting and collecting information type of user interactions. The services supported bythe Avaya MS are as follows:

• annc service: For announcement service, implemented by the RFC4240 packagedapplication.

• dialog service: For prompt/collect and user application invoking service. Built-in withthe platform. Using this service, external VXML application can also be invoked.

• conf service: For user initiated conference service by the RFC4240 packagedapplication.

Avaya MS is preconfigured to map any RFC4240 URI (begins with annc/dialog/conf) that isrouted to the packaged application or the control is transferred to an external VXML application.

Navigation

• Announcements on page 63

• Dialog on page 64

• Conference on page 64

AnnouncementsAnnouncements are audio prompts played to the user. Announcements are identified by theSIP URI of service invocation.

Media control


DialogPrompt and collect is where the server prompts the user for information, as in anannouncement, and then collects the user’s response. This can be a one-step interaction, forexample by playing an announcement, "Please enter your choice", followed by collecting astring of digits.

The dialog URI implementation is based on the draft-burke-vxml specification. It invokes anexternal VXML application to perform the user interactions. The VXML application is not a partof the packaged application.

ConferenceAvaya MS identifies conference service through their SIP request URIs. To create a mixingsession, one initiates the conf service with the conf-id that represents the session. If the conf-id does not already exist on the Avaya MS and the requested resources are available, theAvaya MS creates a new mixing session. If there is an existing conference (conf-id) for thesession, then the Avaya MS interprets it as a request to join the existing session.

Overview


Chapter 4: High-level architecture

The following figure abstracts the IP Multimedia Subsystem (IMS) architecture.

Figure 6: IMS architecture

Media Resource Function (MRF) is a core node in an IMS trusted network. It is signaled by S-CSCF forsession and media management. SIP application servers (AS) can host services and signal MRF for mediaresources. Session management is implemented using SIP protocol as defined in the TS24.229specification. Media management is invoked by providing specific SIP URIs as defined in the RFC4240specification. Charging is provided by the diameter application that implements charging interfaces asdefined in the TS32.299 and other related specifications.

• Components and relationship to each other on page 65

• Connections between components on page 67

Components and relationship to each otherThe following sections describe the components in MRF and their relationship to each other.


Navigation

• User Agent phones on page 66

• CSCF on page 66

• Billing Servers on page 67

User Agent phonesUser Agent (UA) phones are calling devices–different types of SIP phones.

CSCFCall Session Control Function (CSCF) is essentially a SIP server in IMS that handles SIPsignaling. Depending on the functionality, they are identified in three different types.

• Proxy -CSCF (P-CSCF)

• Interrogating -CSCF (I-CSCF)

• Serving-CSCF (S-CSCF)

Navigation

• P-CSCF on page 66

• I-CSCF on page 67

• S-CSCF on page 67

P-CSCFP-SCSF works as an inbound and outbound proxy server in the IMS that is responsible forsignaling between the IMS terminal, and to or from the IMS network. It also authenticates theuser, verifies the SIP request messages, does message compression for narrow bandnetworks, and implements network policies.

High-level architecture


I-CSCFI-CSCF is a SIP proxy that is responsible for forwarding SIP messages from the remote serversto the domain (administrative domain) to which it belongs to. It also interfaces with the HSS toobtain subscriber details.

S-CSCFS-CSCF is the central SIP server node that performs the session control. All SIP messagesfrom the IMS terminals are eventually handled by this node to determine if application serverinteractions needed before forwarding to final destination. It also does the user authenticationand the number translation.

Typically the MRF is connected to S-CSCF. From the perspective of MRF functionality, S-CSCF is similar to the standard SIP proxy that is used to create, maintain, and tear down aSIP session. S-CSCF receives media control messages (RFC4240-based) from theapplication server using the Mr interface.

Billing ServersBilling servers, also known as Charging Data Function (CDF), are the nodes of a billing domainthat interact with the MRF for charging.

Connections between componentsThe following figure demonstrates how the MRF communicates with different servers andnodes.

I-CSCF


Figure 7: MRF components

Navigation

• Diameter for Billing Servers interaction on page 68

• SIP for CSCF interaction on page 68

• Sr interface for Application Server interaction on page 68

Diameter for Billing Servers interactionDiameter protocol is used to communicate with the CDFs in order to provide accountingservices.

SIP for CSCF interactionSIP is used to communicate with the CSCF servers for the MRF to act as a node on the IMScore network.

Sr interface for Application Server interactionSr interface is used by MRF to communicate with Application Servers to provide multimediato the user.

High-level architecture


Chapter 5: IMS control

Media Resource Function (MRF) functionality brings the flexibility of leveraging all the capabilities of theAvaya Media Server into the IP Multimedia Subsystem (IMS) by supporting a few fundamentals of IMSgoals: Guaranteed QoS, Integrated Multimedia Services, and Common Charging. IMS is realized bylayered architecture (media, control, and service planes) that identifies the standard componentsparticipating in these layers. For more information, see the figure below. Avaya MS MRF is logicallydistributed into various planes depending on the functionality hosted on it. In general MRF serves in thecontrol plane with its controller (MRFC) functions that include the signaling interfaces with CSCF, AS, andBilling Domain while the media processor (MRFP) component is responsible for interfacing end-to-endmultimedia connections in the media plane.

Figure 8: Avaya MS as a node in IMS core network

This figure identifies the interface requirements of the MRF (MRFC+MRFP) in the IMS.

• Mr interface: 3GPP SIP protocol requirements for CSCF interaction

• Rf, Ro interface: Diameter based charging protocol requirements to Billing Domain

• Sr, Cr interface: Direct Media Control protocol requirements by SIP Application Server

• RTP: End to end media connectivity protocol requirements

Mr (SIP), Sr (HTTP) and RTP are built-in to Avaya MS.


Mr interfaceIn IMS, the MRF can interact with other elements using standard protocols. The basicrequirement of MRF is to interact with the S-CSCF over Mr interface. You can use the Mr forsession and media control. S-CSCF can choose to use the AS to execute additional servicelogic depending on the setting of initial filter criterion. In that case it forwards the call to the ASthat can work in one of the several modes. The most common mode of the AS working withthe MRF is a back to back user agent (B2BUA) that also performs the 3PCC (third party callcontrol). The RFC4240-based URI, working as a B2BUA, is generated for simple services likeplaying announcements, collecting digits as offered by the packaged application on the MRF.For relatively complex services, the control on call flow is performed by 3PCC logic on the ASwhile delegating script based media control to the MRF. For example, in an adhoc conferencingscenario, the AS can decide to terminate the call so that the Avaya MS application delegatesmedia control activities (play the welcome message, accept the dtmf for authentication, andbring the new party into the conference) while the AS controls the conference, as determined byits 3PCC logic, to add a new participant in that conference.

Sr interfaceIn the IMS, the MRF can interact with the AS to execute a VXML application. The executionof a VXML application is done utilizing the Sr interface to communicate with the AS to downloada script to continue the execution to control the media behavior and user interactions thereafter(IVR functionalities in this release). In the dialog, there are some trigger points that sendmessages to the Diameter Component for the generation of charging events.

IMS control


Chapter 6: Media control

The Avaya Media Server uses the basic RFC4240 SIP-based media networks to provide media services.Such services include playing announcements, initiating a media mixing session (conference), andprompting and collecting information with a user. The Avaya MS supports the following services:

• annc service: for announcement service, implemented by the RFC4240 packaged application

• dialog service: for prompt and collect, user application invoking service, and is built-in with theplatform

• conf service: for user initiated conference service, implemented by the RFC4240 packagedapplication

A service name can have an associated set of parameters. These parameters follow the convention setout for SIP URI parameters. That is, a semicolon separated list of keyword=value pairs.

Avaya MS, upon receiving an "INVITE", reads the service indicator. Avaya MS either honors the request orreturns a failure response code depending on the service indicator.

• Announcement service on page 71

• Dialog service on page 72

• Conference Service on page 72

• Supported parameters for each service on page 74

• List of errors and handling on page 75

Announcement serviceAnnouncements is media played to the user after the call setup is complete. First, therequesting device issues an "INVITE" to the Avaya MS requesting the announcement service.The Avaya MS negotiates the SDP and responds with a 200 OK . After receiving the ACKfrom the requesting device, the Avaya MS plays the requested object and issues a BYE tothe requesting device.

The user portion of the address, annc , specifies the announcement service on the AvayaMS. The play= parameter is mandatory.

Example

[email protected];play=http://crichton/softivr/LongAnnc.wavThe following figure demonstrates a RFC4240-based announcement.


Figure 9: RFC4240-based announcement

The URL scheme for play parameter includes any of the following:

• HTTP

• file (referencing a local object)

Dialog servicePrompt and collect is a procedure where the server prompts the user for some information,as in an announcement, and then collects the user’s response. This can be a one-stepinteraction, for example by playing an announcement, "Please enter your pass code", followedby collecting a string of digits.

This service is also known as a voice dialog. It establishes an oral dialog with the user. Theservice indicator is dialog . The dialog service takes a parameter, voicexml= , indicatingthe URI of the VoiceXML script to execute.

Example

sip:[email protected];voicexml= http://crichton/softivr/dtmf1test.vxmlVoiceXML scripts may continue with the dialog and engage the user for further interactions bycollecting the dtmf digits and taking actions based on the entered digits. The Avaya MS alsosupports the SIP INFO method to collect dtmf digits.

Conference ServiceThe Avaya MS identifies the conference service using the SIP request URIs. To create a mixingsession, you can initiate conf with conf-id, which represents the session. If the conf-id doesnot already exist on the Avaya MS and the requested resources are available, the Avaya MS

Media control


creates a new mixing session. If there is an existing conference (conf-id) for the session, thenthe Avaya MS interprets it as a request to join the existing session.

sip:conf=uniqueIdentifier@<mediaserver>The unique identifier (conf-id) is a value that is compliant with the SIP URI specification.

Example

[email protected] or [email protected];conf-id=123The following figure demonstrates the RFC4240-based conferencing.

Figure 10: RFC4240-based conferencing

You can remove legs by issuing a BYE command in the corresponding dialog. The mixingsession, and thus the conference-specific request URI, remains active so long as there is atleast one SIP dialog associated with the given request URI.

Conference Service


Avaya enhancement

Avaya added an optional parameter to control the bridge destruction in MRF.

[email protected]; lastdialoghold=<true | false>By default, the value of this parameter is “true". This means the bridge will not be destroyeduntil the last part leaves. When the value is “false”, then the bridge is destroyed if either of thelast two parties leave. The parameter is added to keep the compatibility with other Avayaproducts’ interoperability requirements.

Supported parameters for each serviceThe following descriptions are the parameters of each service.

Announcement Service

The following are the parameters for the announcement service.

repeat Specifies how many times Avaya MS should repeat the announcement or sequencenamed by the play= parameter. The value "forever" means the repeat is effectivelyunbounded. In this case, the Avaya MS implements some local value to “forever” to ensureerrant clients do not create a denial of service attack. [email protected];play=http://crichton/softivr/LongAnnc.wav;reapeat=5The file LongAnnc.wav is played 5 times continuously.

delay The delay parameter specifies a delay interval between the announcementrepetitions. The delay is measured in milliseconds. [email protected];play=http://crichton/softivr/LongAnnc.wav;repeat=5;delay=2000 With delay of 2 second, LongAnnc.wav isplayed five times.

duration The duration parameter specifies the maximum duration of the announcement.The Avaya MS discontinues the announcement and ends the call if the maximum duration isreached. The duration is measured in milliseconds. [email protected];play=http://crichton/softivr/LongAnnc.wav;duration=3000locale The locale parameter specifies the language and optionally the country variant ofthe announcement sequence named in the play= parameter. The implementations providethe best possible match between the requested locale and the available languages in the eventthe Avaya MS cannot honor the locale request precisely. [email protected];play=http://crichton/softivr/LongAnnc.wav;locale=en_US

Dialog Service:

Media control


The following is the parameter for the dialog service.

vxml-keyword These parameters get passed to the VoiceXML interpreter session with theassigned vxml-keyword vxml-value pairs. All vxml-keywords require values.

List of errors and handlingThe following are errors and handling for MRF on the Avaya MS.

Service Error

If the Avaya MS cannot perform the requested service or does not recognize the serviceindicator, it responds with the response code "488 NOT ACCEPTABLE HERE".

Announcement Errors

• If the Avaya MS cannot find the referenced URI, it responds with the 404 response codeand sends the reason phrase "Announcement content not found".

• If the Avaya MS receives an INVITE for the announcement service without a play=parameter, it respond with the response code 400 and sends the reason phrase"Mandatory play parameter missing".

• If there is an error retrieving the announcement, the Avaya MS responds with a 400response code and sends the reason phrase "Announcement content could not beretrieved". In addition, the Avaya MS includes a warning header with the appropriateexplanatory text explaining what failed.

Dialog Errors

If there is a vxml-keyword without a corresponding vxml-value, the Avaya MS rejects therequest with a 400 BAD REQUEST response code. In addition, the Avaya MS states "MissingVXML Value" in the reason phrase.

Conference Errors

If the Request-URI has conf as the user part but does not have a conf-id parameter, theAvaya MS responds with a 404 NOT FOUND.

If there is an SDP parse error while adding a party in conference, it generates 400 BADREQUEST error.

Error Scenarios

List of errors and handling


A ReturnCode -1 identifies the failure of sending the message to the stack. The following isa list that describes the failure scenarios:

• If the diameter stack is disabled - soapserver log: Info: Diameter Stack disabled, nomessage sent.

• One of the fields entered null in the request - soapserver log: Error: One of the fields inthe request is NULL.

• Any problem with gslid - soapserver log: Error: GSLID decode failed. or Error: InvalidGSLID received.

• acrType WITH_INVITE and there is no SIP data sent - soapserver log: Error: EmptysipData.

• Any type other than GSLID_ONLY or WITH_INVITE - soapserver log: Error: Invalid <typeyou entered>.

• Any problem while sending data to DiamC for GSLID_ONLY - soapserver log: Error: Whilesending ACR_WS_EVENT_GSLID_ONLY to DiamC.

• Any problem while sending data to DiamC for WITH_INVITE - soapserver log: Error: Whilesending ACR_WS_EVENT to DiamC.

• Any problem while parsing sip data for acrType WITH_INVITE - soapserver log: Error:While parsing sipData.

• If the authentication is enabled, but there is challenge failure (This is generic tosoapserver) - Error: HTTP digest authentication failed.

The following is a list of debugging messages for other error scenarios, mainly used by Avayasupport personnel.

• DiamCTransport: Error: Calling populateEventContainer() – returned <code>

• DiamCTransport: Error: conn = <id> connection error

• DiamCTransport: Error: unable to retrieve event type from MSLink message

• DiamCTransport: Error: unable to retrieve gslid from MSLink message

• DiamCTransport: Error: unable to map gslid <gslid#> received from DiamC

• DiamCTransport: Error: unable to retrieve header from MSLink message

• DiamCTransport: Error: Invalid event type received: <type of event>

• DiamCTransport: Error: map insert error for gslid: <gslid#>

• DiamCTransport: Error: waitEvent failed

• DiamCTransport: Error: map erase error for gslid: <gslid#>

• DiamCTransport: Error: send error = <error type>

Media control


Media provisioningThis section describes the use of Element Manager to provision media that can be directlyused by a RFC4240 packaged application. Media files (digitized audio) are stored in ahierarchical manner as illustrated in the following figure.

Figure 11: Media provisioning namespace hierarchy

From a services perspective, the namespace is the name of the service. The Avaya MS is hostto multiple services. Avaya recommends that each service has a separate namespace. Forthe RFC4240-based application, the name of the default namespace is RFC4240. ContentID is a reference to a media (prompt name, announcement ID) that can be associated withphysical media stored and managed by Content Store. Content Group is associated with thelogical grouping of media content. You can put this into a subgroup for further classification.

For example, if RFC4240 service for avaya.com contains a number of prompts, then eachprompt is associated with one content id under the content group avaya.com inside the

Media provisioning


RFC4240 namespace. If avaya.com hosts multiple categories of applications, then it is putinto a subgroup under avaya.com .

The Avaya MS searches the media files in Content Store; the files that are uploaded throughthe Element Manager (EM). If the response from the Content Store is successful then the sameURL is used to play the announcement or else the media file is searched in the default folder(RFC4240).

Configuring media provisioningFor the MRF to supply media files upon demand, you must configure media provisioning.

Prerequisites

• Avaya MS must be configured and fully operational. For more information, see AvayaMedia Server Commissioning, NN44471-301.

• MRF must be configured. For more information, see MRF commissioning on page 91.• User must be logged into Element Manager (EM).

1. In the Network panel, under Tools, click Media Management.The default namespace mmf is provided by the Avaya MS and it contains built-inprompts.

2. To add a new namespace, click Add.

3. Type a Content namespace name, and then click Save.

4. Select the new namespace, and then click Browse.

5. Select the newly created namespace, and then click Add Content Group.

6. Type the new content group name, and then click Save.

7. Select the newly created content group, and then click Add Media.

8. Click Browse, locate the media file you want to add, and then click Upload.Avaya MS provides an option to change the name of the media file. If you do notprovide a new name then the default file name is used as Content Id.

9. To add a sub-content group to a content group, select the content group, and thenclick Add Content Group.

10. Type a name for the sub-content group, and then click Save.To add media files in the sub-content group, use the same method as adding mediafiles in a content group.

11. To invoke a media file, use the following syntax:[email protected];play = [<content-group>]/[<content-id>];[ns=<namespace>]

Media control


Where content-group and content-id follow the same structure from the EM tool, ifthe namespace and content-group is missing then default values are taken(<namespace> = RFC4240 and <content-group> = default).

12. To invoke a media file located in a sub-content group, use the following syntax:[email protected];play = [<content-group>]/[<content-sub-group>]/[<content-id>];[ns=<namespace>]

Maximum announcement for each RequestThe maximum announcement played for each request is nine. The prompts in request URIcan be concatenated by a positive (+) sign. For example, one-thousand + fifty-eight + dollarsis heard as “one thousand fifty eight dollars” if the built-in prompts (as shown in italics) are usedfrom the mmf namespace and the default content group.

EM does not perform any transcoding of media files. Only the following file formats aresupported:

• Mono

• 8KHz

• Law, Mu-Law, PCM, or G729

There is no verification on wave files formats in EM. The user needs to supply proper audioformats when provisioning with the EM Media Management tool.

Example

1. play = MyPrompt

em-provisioned-namespace-name = RFC4240 em-provisioned-content-group-name = default em-provisioned-prompt-name =MyPromptPlays MyPrompt announcement

2. play = MyPrompt_1+MyPrompt_2+MyPrompt_3

em-provisioned-namespace-name = RFC4240 em-provisioned-content-group-name = default em-provisioned-prompt-name =MyPrompt_1 em-provisioned-prompt-name = MyPrompt_2 em-provisioned-prompt-name = MyPrompt_3Plays a sequence of prompts (MyPrompt_1,MyPrompt_2 and MyPrompt_3).

3. play = avaya.com/MyPrompt

Maximum announcement for each Request


em-provisioned-namespace-name = RFC4240 em-provisioned-content-group-name = default em-provisioned-content-group-name = avaya.com em-provisioned-prompt-name = MyPromptPlays MyPrompt from RFC4240 namesapce with "avaya.com" as content group

4. play=avaya.com/prompt1+avaya.com/prompt2

em-provisioned-namespace-name = RFC4240 em-provisioned-content-group-name = default em-provisioned-content-group-name = avaya.com em-provisioned-prompt-name = prompt1 em-provisioned-prompt-name = prompt2Plays a sequence of prompts(prompt1 and prompt2) from content group “avaya.com” inRFC4240 namespace and avaya.com as content-group-name

5. play = default/MyPrompt

em-provisioned-namespace-name = RFC4240 em-provisioned-content-group-name = default em-provisioned-prompt-name =MyPromptPlays MyPrompt from default content group in RFC4240 application namespace.

6. play = avaya.com/AppGroup_1/MyPrompt

em-provisioned-namespace-name = RFC4240 em-provisioned-content-group-name = default em-provisioned-content-group-name = avaya.com/AppGroup_1 em-provisioned-prompt-name =MyPromptPlay from RFC4240 namesapce with avaya.com as content group and AppGroup_1 as sub-content group

7. play = avaya.com/MyPrompt;ns=NewNamespace

em-provisioned-namespace-name = RFC4240 em-provisioned-content-group-name = avaya.com em-provisioned-prompt-name =MyPrompt em-provisioned-namespace-name = NewNamespace em-provisioned-content-group-name = avaya.com em-provisioned-prompt-name = MyPromptPlays MyPrompt from content group avaya.com and namespace as NewNamespace

Using mmf namespaceAvaya MS is supplied with a mmf namespace for built-in prompts used by the system. Thehierarchy is mmf, system, default. It takes the advantage of using built-in prompts for the

Media control


announcement service. The mmf namespace is reserved. The following is an example of usingthe system prompts.

[email protected];play=system/default/twenty-five-dollars+system/default/and-eight-cents;ns=mmf

The mmf namespace contains a large number of basic audio files like alphabets (A-Z),numbers, price (dollars, cents), and date (month, week). These can be useful to play differenttypes of announcement.

Important:Using prompts from different namespaces can not be mixed. However, mixed usage ofprompts under same namespace, from multiple content groups or subgroups are allowed.

Using mmf namespace


Media control


Chapter 7: Charging control

Two of the most common charging models are postpaid and prepaid. Offline charging is related to theconcept of “bill after the call is over” while online charging is related to the concept of “authorize first beforemaking call and control the call as authorized”. The unification of a charging model is one of the mainendeavors of the IP Multimedia Subsystem (IMS). Offline charging uses the Rf interface to send the CallDetail Record (CDR) to the servers known as Charging Data Functions (CDFs) in the billing domain whilethe online charging uses the Ro interface to do the same to the servers (OCS). Charging mechanism isdivided into two categories–session-based and event-based in the context of using the offline (Rf) andthe online (Ro) messaging interfaces. Event-based charging is associated with a single end-user-to-network transaction. In session-based charging, multiple charging events are generated that areconsolidated for each session by the billing domain. This document addresses the functions of Rf interfacefor session- and event-based charging.

The following table shows the components that are responsible to implement various IMS interfaces.

Table 2: Avaya MS components handling IMS related protocols

Name and meaning of interface Avaya MS component orEnvironment

Remarks

Mr, 3GPP SIP session controland MRF media control

SIPMC–SIP interface TS24.229 Mr specific messages,RFC3455, RFC3325 P-headersand RFC4240 mandatoryparameters

Sr, HTTP protocol in client role VXML application controlled TS24.880

Rf, Offline charging in client role DiamC - Diameter interface TS32.260, TS32.299

Charging operationThe charging operation is the process of generation and transmission of accountinginformation between the Avaya MS Charging Trigger Function (CTF) and the billing server orCDF. From the accounting information, the CDF constructs and formats the Charging DataRequests (CDRs) for the MRF. The DiamC process collects, computes, and generatescharging related attributes from the Avaya MS. It works in a request and response model asdefined by TS32.260 sec 6.1. The Diameter Component as a CTF supports stateless (event-based) and stateful (session-based) charging mechanisms. In case of a transmission failure,the entire message is routed to a database transparently and scheduled for retransmissionlater. The transmission failures do not effect the services rendered in real-time. The following


types of accounting information are sent from the MRF for offline charging to support session-and event-based charging scenarios.

• START session

• INTERIM session

• STOP session

• EVENT session

The reporting of accounting information is achieved by sending the diameter ACR (AccountingRequests) messages. In the duration of the call, different types of ACR messages are sent.These include the following:

• ACR(Start) to identify the beginning of a session (in the Avaya MS it is identified as thegslid parameter)

• ACR(Interim) is triggered at interval mutually agreed upon interval between the CDF andthe CTF

• ACR(Stop) to identify the end of a session

• ACR(Event) sends account data unrelated to a session or unsuccessful sessionestablishment attempt

Every diameter message is grouped as Request and Acknowledgement pairs. For every ACR,there is an ACA response message. The following list is the supported Diameter messagesfor Rf implementation:

• ACR/ACA (Accounting)

• CER/CEA (Capability Exchange)

• DPR/DPA (Disconnect Peer)

• DWR/DWA (Device Watchdog)

Of all these messages, only ACR/ACA is based on a diameter user session (session relatedto the Rf interface). The rest of the messages are related to peer (Avaya MS and CDF) thatcan be loosely treated as maintenance messages. The following table from TS32.260describes the mapping between SIP and Diameter messages:

Table 3: Accounting request messages triggered by SIP methods for the MRFC

Diametermessage

Triggering SIP method

ACR [Start] SIP 200 OK acknowledging an SIP INVITE for initiating a multimedia adhoc conferencing session

ACR [Interim] SIP ACK acknowledging a SIP INVITE to connect an UE to theconferencing session

Expiration of AVP (Acct-Interim-Interval)

ACR [Stop] SIP BYE message

Charging control


Diametermessage

Triggering SIP method

ACR [Event] SIP Final/Redirection Response 3xx

SIP Final Response with error codes 4xx, 5xx or 6xx indicatingtermination of an ongoing session

SIP CANCEL, indicating abortion of a SIP session setup

The Diameter Component supports the 3GPP Rf interface application for communication withCDF. There are two categories of parameters in general. The first category is the AccountingData, which is transmitted as diameter payload using ACR message. The other category dealswith the peer-to-peer operations, for example, exchange of watchdog messages, andcapability exchanges. There are different categories of parameters in Accounting Data–M:mandatory, Oc: operator conditional, and Om: operator mandatory. If a mandatory parameter ismissing, the appropriate error is reported and no messaging is possible due to that error. If aparameter (Om or Oc type) is available, it is included in the ACR message. This means, there isno separate configuration available to control the presence or absence of that parameter inthe message.

Table 4: ACR messages

AVP Category Origin CommentsSession-Id M SIP GLSID

Origin-Host M Configuration NODE table

Origin-Realm M Configuration COMPONENT_ CFGtable

Destination-Realm M SIP/Configuration Domain name in theSIP "From" header

Accounting-Record- Type M Diameter ComponentCode

Enumeration on Start/Stop/Interim/Eventfrom SIPMC/SCmessage

Accounting-Record-Number

M Diameter ComponentCode

Monotonicallyincreasing number perstartup

Accounting- Application-Id

Om Diameter ComponentCode (Hardcoded)

Constant (3)

Acct-Interim-Interval Oc Diameter ComponentCode

Optional field in ACAfrom CDF

Origin-State-Id Oc Configuration andDiameter ComponentCode

Configurationdetermines inclusion

Charging operation


AVP Category Origin CommentsEvent-Timestamp Oc Diameter Component

CodeTime of receipt ofSIPMC/SC triggers(200 OK, ACK, BYE,3xx, 4xx, 5xx)

Service-Information Om(grouped)

– –

IMS-Information Om(grouped)

– –

Event-Type Oc(grouped)

– –

SIP-Method Oc SIP SIP Method name

Event Oc SIP SIP 'Event' header

Expires Oc SIP SIP 'Expires' header

Node-Functionality Om Diameter ComponentCode (Hardcoded)

Constant (3)

User-Session-ID Oc SIP SIP 'Call-Id' header

Calling-Party- Address Oc SIP SIP 'From' header

Called-Party- Address Oc SIP SIP 'Request-URI'

Called-Asserted- Identity Oc SIP SIP 'P-Asserted-Identity' header in the2xx responsecorresponding to a SIPrequest either initiatinga dialog or a standalonetransaction

Requested-Party-Address

Oc SIP SIP 'Request-URI'

Associated-URI Oc SIP SIP 'P-Associated- URI'header in the 200 OKresponse to aREGISTER request

Time-Stamps Oc(grouped)

– –

SIP-Request- Timestamp Oc SIP Time of the SIPRequest

SIP-Response-Timestamp

Oc SIP Time of the response tothe SIP Request

Application-Server-Information

Oc(grouped)

– –

Charging control


AVP Category Origin CommentsApplication-Server Oc SIP SIP URLs of the

Application Serversaddressed during thesession

Application-Provide-Called-Party-Address

Oc SIP Called party address ifit is determined by anapplication server

Inter-Operator- Identifier Oc(grouped)

– –

Originating-IOI Oc SIP SIP 'P-Charging-Vector' header

Terminating-IOI Oc SIP SIP 'P-Charging-Vector' header

IMS-Charging- Identifier Oc SIP SIP 'P-Charging-Vector' header

SDP-Session-Description

Oc SIP Holds the content of an"attribute" line (i=, b=,c=, k=, a=, ...) related toa session

SDP-Media- Component Oc(grouped)

– –

SDP-Media-Name Oc SIP Holds the content of a"m=" line in the SDPdata

SDP-Media- Description Oc SIP Holds the content of an"attribute line" (i=, c=,b=, k=, a=, ...) related toa media component.The attributes arespecifying the mediadescribed in the SDP-Media-Name AVP

Media-Initiator- Flag Oc SIP Indicates which partyrequested the sessionmodification. Thedefault value is '0',indicating the calledparty initiated themodification. Choiceare: Called Party/Calling Party/Unknown

Service-Id Oc SIP Identifies the servicethe MRFC is hosting.

Charging operation


AVP Category Origin CommentsFor conferences, theconference ID can beused as the value of thisparameter

Service-Specific- Data Oc SIP Holds service specificdata if and as providedby an AS.

Cause-Code Oc SIP The cause code valuefrom the IMS node. SIPerror code or platformspecific code.

DiamC supports multiple CDFs and multiple destination realms that you must configure. Theaddresses of different CDFs are available as P-Charging-Function-Addresses. DiamC keepsconnectivity to all the CDFs and routes the message to the desired CDF from this list.

DiamC does not generate CDRs itself, however, it collects and forwards the charginginformation, over the Rf interface, to the CDF to enable the CDF to generate CDRs. The list ofattributes are identified in the table above.

DiamC collects the IMS Charging Identifier (ICID) information from the P-Charging-Vector SIPheader, and received by the IMS MRF over the Mr interface. With ICID you can correlatesession and transaction related charging data generated in the different IMS elements. TheICID information is present in the IMS-Charging-Identifier AVP of the IMS-Information groupedAVP of the Service-Information grouped AVP in the ACR message. In DiamC, ICID is mappedto gslid for end to end correlation.

Charging Trigger FunctionCharging Trigger Function (CTF) consists of two major functions–accounting metrics collectionand accounting data forwarding. For session-based charging, the trigger points for sendingaccounting data to CDF are defined in TS32.260 Table 5.2.1.2. These are 200 OK, ACK, BYE,3xx, 4xx and 5xx. Also negotiable (with CDF) interim triggers (from timers) are considered. Forevent-based charging, the API is provided for one-time events. The Diameter Componentcollects accounting data for calls, service events, or sessions; for identifying the user and user’sconsumption of resources in real-time. Finally, it assembles charging data and transfers thedata using ACR message as an application (Rf application) payload and forwards the chargingevents towards the CDF using the Rf interface.

Charging control


Charging Event RetransmissionRetransmission occurs when DiamC loses connectivity with the CDF it is communicating with.As defined in RFC3588, failover takes place to the alternate server. Any duplicate message issent to the alternate CDF with T-Flag set (a particular bit in diameter header indicatingretransmission). Once the original CDF comes back, new messages are sent to the originalserver (failback).

Depending on the Accounting-Realtime-Required AVP returned by ACA, the actions taken arebased on the following parameters:

• DELIVER_AND_GRANT–Deliver diameter messages as long as there is a connection toprimary or backup CDFs.

• GRANT_AND_STORE–Diameter messages are delivered to CDF (either from the SC inreal time or from the archive table as a roll forward).

• GRANT_AND_LOSE–CDF always accepts diameter messages independent of the clientcapabilities on delivery of messages or storing.

In the DiamC implementation, delivery failure is handled by using a combination ofreconnection (failover and failback) and roll-forward mechanisms. In the diameter messagearchive database, any message that can not be routed to a CDF is marked as a failure. Atreconnection, all the failed messages for that CDF are retransmitted. In case of delivery failure,the messaging is routed to a database if there is no alternate CDFs available. DiamCcontinuously tries to connect to the failed CDF until successful. If the original CDF comes back,the message is routed back to it if there is no P-Charging-Function-Addresses defined or theP-Charging-Function-Addresses contains the server name as the reconnected CDF.

The following routing scenarios are addressed.

• Routing order is the CDF having lowest IP address to the higher IP addresses dependingon the availability.

• Routing order can be changed by list of CDFs in P-Charging-Function-Addresses (in thatorder).

DiamC is able to archive charging information (ACRs) in a database for up to seven days if itis not able to transmit or retransmit the information to the CDF. When charging information isolder than seven days (configurable) it is discarded and the appropriate event logs aregenerated.

Charging Event Retransmission


Charging control


Chapter 8: MRF commissioning

This section describes how to configure the Media Resource Function (MRF) on the Avaya Media Server.The MRF is used to deliver multimedia on an IP Multimedia Subsystem (IMS) network.

Prerequisites to MRF commissioning

Avaya MS must be setup and operational. For more information about Avaya MS setup andconfiguration, seeAvaya Media Server Commissioning, NN44471-301.

MRF configuration proceduresThe following task flow shows you the sequence of procedures you perform to configure theMRF on the Avaya MS.


Figure 12: MRF configuration procedures

ResultMRF configuration navigation

• Configuring SIP routing and domains on page 92

• Configuring diameter on page 93

• Configuring MRF OM collection on page 94

• Configuring MRF log collection on page 94

• Configuring Advanced Engineering Parameters on page 94

Configuring SIP routing and domainsYou must configure SIP routing and domains to enable communication between the Avaya MSand the Call Session Control Function (CSCF) servers on the IMS network.

MRF commissioning


Prerequisites

• User must be logged on to Element Manager (EM).• CSCF servers must be operational and visible on the network.

1. Configure the SIP domain settings for the CSCF servers in the IMS network. Formore information, see Avaya Media Server Commissioning, NN44471-301.

2. Configure the SIP user accounts from the IMS network. For more information, seeAvaya Media Server Commissioning, NN44471-301.

3. Configure each CSCF server as SIP trusted nodes. For more information, seeAvaya Media Server Commissioning, NN44471-301.

4. Configure the SIP routes for the CSCF servers. For more information, see AvayaMedia Server Commissioning, NN44471-301.

5. For more information about SIP configuration, see .Avaya Media ServerCommissioning, NN44471-301.

Configuring diameterYou must configure Diameter on Avaya MS to communicate with the Charging Data Functions(CDFs).

Prerequisites

• User must be logged on to EM.• CSCF servers must be operational and visible on the network.• SIP routing and domains configuration must be done.• Diameter component must be licensed.

1. In the navigation pane, click System Configuration, Signaling, Diameter.

2. Click General Settings.

3. To enable the Diameter Stack, select the Diameter Stack Enabled check box.

4. In the navigation pane, click Realms.

5. To add a Realm, click Add.

6. Type the domain name, and then click Save.

7. In the navigation pane, click Servers.

8. To add a CDF, click Add under Peer Hosts.

Configuring diameter


9. Type the IP address or the host name of the CDF you want to add, and then clickSave.

10. Click Add under Diameter Route.

11. On the Realm Name menu, choose the Realm name desired. Do the same for "Hostor IP" to add the CDF desired to the route.

12. Select TCP from the Transport list, and then type 3868 for the Port (Port 3868 isthe default listening port).

13. Click Save.Repeat this procedure for every Realm and CDF to be configured.For more information about Diameter configuration, see Avaya Media ServerCommissioning, NN44471-301.

Configuring MRF OM collectionConfigure the OM collection on the Avaya MS. For more information about configuring OMcollection, see Avaya Media Server Commissioning, NN44471-301.

Configuring MRF log collectionConfigure log collection on the Avaya MS. For information about configuring log collection, seeAvaya Media Server Commissioning, NN44471-301.

Configuring Advanced Engineering ParametersThe following section describes advanced settings procedures that you use whilecommissioning MRF.

Prerequisites

• User must be logged on to EM.• CSCF servers must be operational and visible on the network.• SIP routing and domains configuration must be done.• Diameter component must be licensed.

MRF commissioning


Caution:Avaya recommends that you start with the default values. You can change these parametersfor further tuning, considering the availability of system resources. Contact Avaya TechnicalSupport before making changes to the following settings.

1. In the navigation pane, click System Configuration, Signaling, EngineeringParameters.

2. To change the size of the diameter message that the stack supports, type a differentvalue for Maximum message size setting.

3. To change the number of messages that the stack can handle at a point in time,type a different value for Maximum message number setting.

4. To change the number of CDF connections allowed, type a different value forMaximum connections setting.

5. To change the minimum time the accounting data will be stored in the databasebefore reusing the space, type a different value for Archive interval.Avaya recommends making a backup of the archive, if required.

6. To change the number of messages queued for delivery to the stack, type a differentvalue for Maximum Rf(Offline) accounting queue depth setting.

Important:Usually this setting is the same number as the maximum message number.

7. Click Save.

Configuring Advanced Engineering Parameters


MRF commissioning


Chapter 9: Operational Measurementsreference

The following sections contain information about the Operational Measurements used by MRF.

• Counters on page 97• Gauges on page 98

CountersThe following table describes the counters used by MRF.

Legend

• ACR–Accounting-Request• ACA–Accounting-Answer• CER–Capability-Exchange-Request• CEA–Capability-Exchange-Answer• DPR–Disconnect-Peer-Request• DPA–Disconnect-Peer-Answer

Table 5: DiamC counters

No. Name Scenario1 OMDiamCACAFailA ACA is received with non-2001 Result-Code AVP.

2 OMDiamCACARcvdA ACA is received.

3 OMDiamCACRSentA ACR is sent.

4 OMDiamCAnsErrS E-bit in the Command Code of the receivedDiameter message is set.

5 OMDiamCAnsSentS An answer is sent by the stack for an incomingDiameter message.

6 OMDiamCCEARcvdS CEA is received.

7 OMDiamCCERFailS An invalid reponse is received for a sent CER,either because of time-out or a non-CEA responseor a CEA with non-2001 result code.


No. Name Scenario8 OMDiamCCERSentS CER is sent.

9 OMDiamCDPARcvdS DPA is received.

10 OMDiamCDPRSentS DPR is sent.

11 OMDiamCMsgFailA A failure return code is received when the APIfunction to send ACR is invoked.

12 OMDiamCMsgRcvdA A Diameter message is received by theapplication. In the current release the onlyDiameter message received (processed) by theapplication is ACA. (CER-CEA, DWR-DWA andDPR-DPA messages are processed at theDiameter stack and not at the application.)

13 OMDiamCMsgSentA A Diameter message is sent by the application. Inthe current release the only Diameter messagesent (encoded) by the application is ACR. (CER-CEA, DWR-DWA and DPR-DPA messages areencoded at the Diameter stack and not at theapplication.)

14 OMDiamCPeerDiscS A Diameter peer is disconnected.

15 MDiamCReqCreateSendS R-bit in the command code of the sent Diametermessage is set.

16 OMDiamCReqRcvdS A Diameter message is received.

17 OMDiamCReqSentS A Diameter message is sent.

18 OMDiamCSessExpS A Diameter accounting session has become Idle.

GaugesThe following table describes the gauges used by MRF.

Table 6: DiamC gauges

No. Name Scenario1 OMDiamCActivePeer Incremented when a peer moves to I_OPEN /

R_OPEN state. Decremented when a peer isdisconnected.

2 OMDiamCActiveRfSess Incremented when a new Rf session is created.Decremented when a Rf session goes Idle.

3 OMDiamCActiveSess Incremented when a new session is created.Decremented when a session goes Idle.

Operational Measurements reference


No. Name Scenario4 OMDiamCBytesMaxRcvdA The maximum size of the MSLINK message

received by DiamC.

5 OMDiamCRcvdReqRateA Set to the number of MSLINK messages receivedby the application per second.

6 OMDiamCReqPendingA Incremented when a new request for DiameterStack processing. Decremented when a requestis dequeued by the Diameter Stack forprocessing.

7 OMDiamCSessOpenMaxS Set to the maximum number of sessions that everexisted since last DiamC startup, measured whena new session is created.

8 OMDiamCSessTimeAvgA Set to the average time spent in a session,measured when a session goes Idle.

9 OMDiamCSessOpenAvgS The average number of open sessions, over aperiod of time since the last DiamC startup,measured when a new session is created.

Gauges


Operational Measurements reference


Chapter 10: Logs reference

The following sections contain information about the different log types used by MRF.

Event LogsEvent logs are generated in three categories – Informational, Warning, and Error.

The following event logs are available at the DiamC component.

Table 7: Event logs

Id Name Category Description11200 Component

InitializedInformational The DiamC component has been configured,

and is up and running.

11201 Peer Created Informational A new peer has been created in the staticpeer table.

11202 Peer Connected Informational A connection to a peer has been established,and capabilities have been exchanged.

11203 Peer Error Error An error has been received on the peer.

11204 Peer Disconnected Informational A connection to a peer has been severed.

11205 Peer Removed Informational A peer has been removed from the staticpeer table.

11206 Session Created Informational A Diameter session (Rf) has been created.

11208 Rf Session Error Error An error has been received on an existing Rfsession.

11209 Rf Session Buffered Warning An ACR send failed, hence, the ACR hasbeen scheduled for retransmission later.

11210 Rf Session Deleted Informational An ACR resend was successful, hence theACR has been scheduled for purge.

11211 Session Removed Informational An existing session has been removed.


Trace logsDiamC component trace logging occurs at the common/log directory, in the filediamcDebug.txt . Both non-session- and session-based logging are available. Session-based logging occurs when chargeable events are received from the Session Controller.Session-based logging is logged against the GSLID of the respective chargeable events.

The trace file size, trace file depth, and trace file roll over period are dictated by the trace loggingmechanism of the Avaya MS platform.

Diameter Stack logsExtensive diagnostic logs are available from the Radvision stack. The levels of diagnosticlogging can be controlled from the OAM GUI, at startup and runtime.

The DiamC component ckey ENABLE_STACK_LOG in theemplatcore.component_cfg table is used to enable or disable Radvision Diameter stacklogging. If enabled, stack logging occurs at any combination of these eight log levels.

• LOG_LEVEL_DEBUGDiameter stack activity in detail.

• LOG_LEVEL_ENTERAPI function was called.

• LOG_LEVEL_ERRORNon-fatal error has occurred (protocol error, faulty application behavior) – these errorsare identified and handled by the stack.

• LOG_LEVEL_EXCEPFatal error has occurred that prevents the Diameter stack from continuing to operate.

• LOG_LEVEL_INFODiameter stack activity.

• LOG_LEVEL_LEAVEAPI function call was completed.

• LOG_LEVEL_SYNCActivity of mutexes and locks.

• LOG_LEVEL_WARNINGWarning about a possible problem (unorthodox behavior, minor failure).

Logs reference


The Diameter stack logging is integrated with the trace logging available from Avaya MS,hence, Diameter stack logging can be session-based, or non-session-based. The trace loggingcategory is Informational.

The Diameter stack logging will be available at the common/log directory, in the filediamcDebug.txt . The trace file size, trace file depth, and roll over of the trace files isdictated by the trace logging feature of the Avaya MS platform.

Diameter Stack logs


Logs reference


Chapter 11: Alarms reference

The following section contains information regarding the alarms that are identified on MRF.

List of identified alarms:

• Internal Component Shutdown (DiamC)• Diameter Offline• Session Controller Offline• Database Offline• Peer Route Offline

There is no impact of peer route or database connection loss on the system as long as they are notsimultaneous. If both the connections are lost, the diameter component will close the connection with theSession Controller, indicating the severity of losing charging information.

An alarm is cleared when the respective cause is removed.

The following alarms are available at the DiamC component.

Table 8: DiamC Alarms

Id Name Severity Type Description11100 Internal Component

Shutdown (DiamC)CRITICAL GENERIC The Avaya MS platform has been

shutdown.

11101 Diameter Offline CRITICAL GENERIC The Diameter capability isunavailable.

11102 Session ControllerOffline

CRITICAL GENERIC The connection with the SessionController is unavailable.

11104 Peer Route Offline MAJOR GENERIC There is no peer route available.

11105 Soap Server Offline MAJOR GENERIC The connection with Soap Server isunavailable.

11106 DiamC archive repairin progress

MAJOR GENERIC Diameter archive table is notconsistent, repairing.

The following describes the alarms in details.

• Internal Component Shutdown (DiamC): This is generated during Avaya MS shutdown to indicatethat the DiamC component is not operational. This alarm is cleared once the DiamC component isup and running with default/configured parameters.

• Diameter Offline: This alarm is generated before the diameter stack is up and it is cleared when thestack is up.


• Session Controller Offline: This alarms is generated when the communication between the DiamCand SC is lost or yet to be established. It is cleared when SC establishes the connection.

• Peer Route Offline: In the first release, DiamC connects to the peer hosts (CDFs) using staticconfiguration. This means all the CDFs are connected at start up. If any of these charging servers isnot reachable, this alarm is raised. DiamC continues with reconnect retries. This alarm is clearedwhen it reconnects to the CDFs. As long as the database connection is up, the presentimplementation guarantees no loss of data.

• Soap Server Offline: DiamC waits for soap server connection to make MSLink active. This alarm isgenerated if the soap server connection is lost at any point of time. If this alarm is active, web servicesmessages can not be sent to DiamC. SoapServer connects to DiamC at start up or reconnects toDiamC if at any point this connection is lost.

• DiamC archive repair in progress: The archive table holds all diameter messages to CDF if the archiveis on. This table is also used to retransmit messages in case a CDF is not reachable. Potentially thistable can be very large, depending on the system load and purge interval. At every startup, DiamCchecks the consistency of this table. If it discovers any corruption, it tries to repair the table. As therepairing process can take a long time depending on the size of the table and the level of corruption,this alarm is set. After the table is repaired, this alarm goes away. If automated recovery is notpossible, this alarm remains set. In that case, manual repair of the table is required. If required, bydisabling the archive feature, normal traffic can be continued.

Alarms reference


Chapter 12: Glossary

The following are terms used throughout this document and their definitions.

Table 9: Glossary

Terms DefinitionsAccounting The process of apportioning charges between the Home Environment, Serving

Network and User.

Application An application is a service enabler deployed by service providers,manufacturers or users. Individual applications will often be enablers for a widerange of services.

Applications/Clients These are services, which are designed using service capability features.

Billing A function whereby CDRs generated by the charging function are transformedinto bills requiring payment.

Call A logical association between several users (this could be connection orientedor connection less).

Charging DataRecord (CDR)

A formatted collection of information about a chargeable event (e.g. time of callsetup, duration of the call, amount of data transferred) for use in billing andaccounting. For each party to be charged for parts of or all charges of achargeable event a separate CDR shall be generated, for example, more thanone CDR may be generated for a single chargeable event, because of its longduration, or because more than one charged party is to be charged.

Charging A function whereby information related to a chargeable event is formatted andtransferred in order to make it possible to determine usage for which thecharged party may be billed.

Domain The highest-level group of physical entities. Reference points are definedbetween domains.

Element Manager(EM)

Provides a package of end-user functions for management of a set of closelyrelated types of network elements. These functions can be divided into two maincategories.

File A named and hierarchically-classified data set on the UICC.

File identifier (FID) The 2-byte name of a file or a directory on the UICC.

Framework A framework defines a set of Application Programming Interface (API) classesfor developing applications and for providing system services to thoseapplications.


Terms DefinitionsInteractive service A service which provides the means for bi-directional exchange of information

between users. Interactive services are divided into three classes of services:conversational services, messaging services and retrieval services.

Interface The common boundary between two associated systems.

Multimedia service Services that handle several types of media such as audio and video in asynchronised way from the user's point of view. A multimedia service mayinvolve multiple parties, multiple connections, and the addition or deletion ofresources and users within a single communication session.

Name A name is an alpha numeric label used for identification of end users and may beportable

Off-line charging A charging process where charging information does not affect, in real time, theservice rendered.

Postpay billing Billing arrangement between customer and operator/service provider where thecustomer periodically receives a bill for service usage in the past period.

Protocol A formal set of procedures that are adopted to ensure communication betweentwo or more functions within the within the same layer of a hierarchy of functions.

Service A component of the portfolio of choices offered by service providers to a user,a functionality offered to a user.

Service control The ability of the user, home environment or serving environment to determinewhat a particular service does, for a specific invocation of that service, withinthe limitations of that service.

Service delay The time elapsed from the invocation of the service request, to thecorresponding service request indication at the Service Receiver, indicating thearrival of application data.

Signalling The exchange of information specifically concerned with the establishment andcontrol of connections, and with management, in a telecommunicationsnetwork.

User An entity, not part of the 3GPP System , which uses 3GPP System services.Example: a person using a 3GPP System mobile station as a portabletelephone.

Glossary


fundamentals - media resource function

Documents