Nortel Networks NN10029-111 User Manual

NN10029-111

Succession Multimedia Communications Portfolio

MCP SIP Application Module

Basics

Standard MCP 1.1 FP1 (02.02) April 2003

Nortel Networks Confidential

Overview

How this chapter is organized

The SIP Application Module Overview contains the following subsections:

• “Overview” on page 4 — Functional desc ription — Network configuration — Interfaces —Protocols

• “Hardware” on page 11

• “Services and features” on page 11 — “Routing and Translation services” on page 12 — “Interworking services” on page 16 — “Service package enforcement” on page 17

— “Authentication services” on page 17 — “Network/Address Hiding service” on page 19 — “911 Notification support” on page 21 — “Instant Messaging” on page 22 — “Presence” on p age 22 — “Voicemail server intero perability and MWI” on page 22 — “Registration—static and dynamic” on page 24 — “Network address book” on page 25 — “Overload contro l ” on page 25 — “Reliability and fault tolerance” on page 26

• “OAM&P strategy” on page 28

4 Overview

Overview

Nortel Networks Confidential

The SIP Application Module is a service execution engine that provides the following functionality:

• core signaling functionality enabling communication among SIP clients

• SIP proxy server

• Back-to-Back User Agent

• SIP Registration

• CPL interpretation

• Location server

• optional Presence subscripti on and notification (For more information on the Presence feature, see the MCP SIP Presence Basics document.)

The SIP Applicatio n Module handles SIP sessions an d applications and provides the core services that enable communication between SIP clients. The SIP Application Module is housed on the SIP Application Server.

Functional description

The SIP Application Module includes the following components:

• Back-to-Back User Agent (BBUA)/Proxy Server Although the BBUA and Proxy Server are basically two differen t

logical entities within the same physical server, they both act as clients and servers. The SIP Application Module decides on a call-by-call basis wh ether to process the req uest as a pure Proxy or BBUA.

The Proxy Server processes SIP requests and responses, re writes headers, modifies requ est- U RIs (U niver sal Resource Indicator), performs locati on look-up, and forwards reques ts to SIP clients or other servers in the network.

The SIP Application Module provides a fully session-stated proxy; in other words, the SIP Application Module main tains a call state for the entire session.

The BBUA extends the proxy function to perform advanced functions such as

— originating new calls — tearing down existing calls — modifying messages

Nortel Networks Confidential

— changing IP addresses in the contact header so that the SIP

— modifying the Sessi o n De scription Protocol (SDP) using va l ue s

— providing advanced screening capabilities The architecture of a BBUA service consists of two user agent

clients linked back-to-back through a proprietary interface. The BBUA is guaranteed to be on the signaling path of all future

requests and responses because it is an endpoint relative to the SIP network component s. Th i s is i m po rtant for services such as billi ng , which need to be aware of all events that take place on a session. The BBUA in the netwo rk also provi des a barrie r for cli ents th at are not fully SIP compliant and entry and exit points for traffic travelling to and from the public network, including agents behind an enterprise firewall. See Figure 1, “Back-to-Back User Agent service.”

Figure 1 Back-to-Back User Agent servic e

Overview 5

Application Module remains on the signaling path

supplied by the RTP Media Portal to control media endpoints

userA

User Agent Client

userB

Internal Protocol

Routing in a S IP network is based on the same hop- by-hop principle as routing e-ma il within the Internet. Th e next hop for a S IP request is determined by a pr oxy using th e domai n or the host p art of a SIP URL (user@domain). The terminating proxy determines whether the domain sent in the SIP URL is one of the domains managed by the SIP proxy. Otherwise, the SIP request is forwarded to another Proxy based on the location lookup performed by the SIPApplication Module. The SIPApplication Module supports routing using t able l ookup i n the SIP dat abase o r using th e Domain Name Server (DNS) to find a route.

6 Overview

Nortel Networks Confidential

• Redirect Server The SIP Application Module decides whether to proxy or redirect the

call separately for each individual request. This decisio n is made based on subscriber service logic. If the decision is to redirect the request, a 302 Resp onse message is returned with a list of alternate locations.

• Registration Server The Registration Server performs registration on messages it

receives from clients. The Registration Server stores information in the database.

• Location Server The Location Server performs location lookup services using

domain and user information stored in the database. The SIP Application Module integrates the above logical servers,

which are all defined in SIP Draft RFC 2543 (see note for specific reference), in to a single server wi th the enhanced se rvices provided by the Back-to-Back User Agent.

Note: J. Rosenberg et al, SIP: Session Initiati on Protocol, Internet Draft draft-ietf-sip-rfc2543-bis09.txt, IETF, Feb 27, 2002.

Network configuration

The SIPApplication Module is configured with two network cards to allow for a network configuration that has a private side and a public side. Figure 2, “Example of network configuration,” shows the SIPApplication Module and RTP Media Portal with public ports and ports that are internal to the priv ate network. This network co nfiguration provides security by placing all the components in a private network and exposing only the public signaling and ports to the public network.

Nortel Networks Confidential

Figure 2 Example of ne twork configuration

SIP Application

BigMart.com

Module

BiggerMart.com

SIP Audio Servers

Overview 7

Management Module

PSTN Gateways

Accounting Modules

8 Overview

Interfaces

The SIP Application Module interfaces with numerous other components. See Figure 3, “Network interfaces.”

Figure 3 Network interfaces

Nortel Networks Confidential

Private network

PSTN or PBX

Access client

Public network

Access client

Legend

Signaling Media stream

Nortel Networks Confidential

Protocols

The SIPApplication Module uses various protocols to support SIP clients, including the Management Module, RTP Media Portal, Database Module, and the PSTN Gateways. The protocols use an IP backbone to connect the components. These interfaces are shown in Figure 3, “Network interfaces.”

Figure 4 Protocols

Overview 9

OMI

PCP

SIP

SQL

SIP

Access client

DTP

Private network

SIP

Public network

SIP

MGCP+

SIP

Access client

SIP

PSTN or PBX

Legend

Signaling Media stream

10 Overview

Nortel Networks Confidential

Table 1, “SIPApplication Module protocols,” gives details about these interfaces.

Table 1 SIP Application Module protocols

Protocol Functional component

SQL Structured Query Language

Interface to the Database Module

SIP Session Initiation Protocol

Interface to the

•SIPclients

• SIP Audio Server

• IP Client Manager (IPCM)

• SIP PRI Gateway

• Web Client Manager

OMI Open Management Interface

Interface to t he SIP Management Module

MGCP+ Media Gateway Control Protocol

Interface to the RTP Media Portal

PCP Perfect Channel Protocol for logs and a larms going to

the Management Server DTP Data Tran sport Protocol Note: The external interfac es use an IP network to int erconnect the

components listed in this table.

Nortel Networks Confidential

Hardware

Refer to Table 2, “Minimum hardware requirements,” for the l ist of required hardware.

Table 2 Minimum hardware requirements

Sun Netra t 1400(DC) /1405 (AC) Description

4-440 Mhz Ultra Sparc II CPUs 4 GB RAM 2-36 GB Ultra SCSI disk drives 1-32X Internal CDROM drive (bootable) 24 GB 4 mm internal tape drive 1 Quad Fast Ethernet PCI card 1 PCI UltraSCSI card

Overview 11

Services and features

The SIP Application Module performs the following services:

• Routing and Translations Services — Call Transfer — Local termination — Foreign termination —Redirect — Telephony Routing — SIP Aliases — Multiple Route Termination/SIP Forking feature — Call Processing Language (CPL)

• Interworking services — Discriminator service

AC (t 1405)/DC (t 1400) power supplies

— Bearer Path Control — Privacy Control service

12 Overview

Routing and Translation services

Nortel Networks Confidential

• Service package enforcement

• Authentication services

• Converged PC service

• Network/Address Hiding

• 911 Notification support

• Instant Messaging

• Presence

• Voicemail server interope rability and MWI (message waiting indication) notification

• Registration

• Network address book

• Overload control

• Reliability and fault tolerance

Foreign termination

If an incoming req uest specifies a do main that is not ser ved by (in other words, is not local to) the SIP Application Module, the SIP Application Module tries to route that request to the appropriate server for that domain.

The first step in this process is to query the DNS SRV, if one is configured in the system, in ord er to obtain the IP address of the server associated with the foreign domain.

Note: A DNS SRV extends the basic functionality provided by a traditional domain name server (DNS). It allows a protocol field to be the query fo r a particular domain and uses that protocol field to provide the correct IP addr ess of the server for the specifie d protocol. For example, clients may query the server with a domain name of nortelnetworks.com and protocol field of sip. The DNS SRV would then respond with the IP address of the SIP server for that domain (which may dif fer from, fo r example, t he H.323 serve r). This all ows a domain to have different servers for different protocols.

If this query fails to find the IP address or if a DNS SRV is not configured, the SI P Appl icatio n Mod ule atte mpt s to lo ok up t he for eig n domain in the database to see if an IP address has been provisioned for this foreign domain (see the SIP Provisioning Client User Guide for

Nortel Networks Confidential

details). If this step also fails, the SIP Application Module attempts a general DNS A-record lookup to route the request.

Note: The DNS A-recor d is the traditiona l response given by a DNS. It translates a domain name into an IP address.

If any of these steps succeed, the SIP Application Module routes the request. If all these methods fa il, the SIP Application Module reject s the request.

Call Transfer service

The SIP Application Module handles the transfer on behalf of clients that do not support the call transfer service.

The SIP Applicatio n Module supports unattended Call T ransfer throug h the Refer mechanism. Unattended Transfer (or Blind Transfer) refers to cases where the transferor redirect s the transferee to the tr ansfer target without first con fer ri ng wi th th e tr a nsfe r target. The transfer or receives a Notify message, however, indicating whether the transfer was successful. If it was, the transferor releases the original call. If it was not, the transferor is reconnected to the transferee.

Overview 13

Local termination

The SIPApplicat ion Module fir st determines w hether the incom ing SIP request terminates to a client in a domain managed by the SIPApplication Module. The SIP Application Mod ule performs local routing lookup through the Location Server, which is part of its internal software.

Telephony routing

When the SIP Application Module receives an incoming call, it looks up the callee in the database. If the callee is not in the database but the domain is served and the user portion of t he URL is a T elep hony routing number, the Telephony routing number is sent through the Telephony routing software within the Location Server.

The Te leph ony r outin g s oftware must perfor m digi t tra nslat ion to fin d a gateway to terminate a call to. These t ables are located in the Database Module. You can provision them through the Provisioning Client. For more information, refer to the SIP Provisioning Client User Guide and the MCP Database Module Basics document.

The Telephony routing service allows the SIP Application Module to

• provide unique dial plans for each subdomain

• provide routes to gateways or to other domains

14 Overview

Nortel Networks Confidential

These routes include routes for private digit dial plans, routes to gateways, and telephony-style routing between SIP domains. Multiple lists can reuse the same routes in a route list.

• assign class of service (COS) COS is basically used to block particular types of calls, such as

international dialing or long-distance dialing. For example, telephones in an office lobby can be restricted to local and emergency calls only in a domain.

Figure 5, “Relationship between Telephony routin g st ag es,” shows th e relationship betwee n the tele phony ro uting sta ges provi ded by the S IP Application M odule. If the C OS val ue of the subscri ber and subdom ain route do not match, then the SIP Ap plication Module checks the pa rent for routes with the same or higher COS value.

Figure 5 Relationship between Telephony routing stages

No subscriber

Foreign domain routing Do database lookup

Failed

*If the DNS A record fails, a 404 Error response is sent back to the originator.

DNS A record*

Route lists The T elephony routing service is an enhancement to the Location Server on the SIP Application Module. This enhanced Location Server function has the ability to translate PSTN numbers into

Nortel Networks Confidential

URL addresses specifying an appropriate gateway . It supports the use of digit translation and digit manipulation.

A route list is assigned a single COS. The route list provides the following additional options that can restrict incoming sessions from using the domain’s telephony resources:

• allow/block all incoming sessions from other domains

• allow/block all incoming sessions from other subdomains

• redirect session to the orig inator’s domain. This option can be used to redirect an incom ing reque st from ano ther domai n that is r outing to a restricted route list.

Route lists consist of

• private telepho ny routes, which a re used for privat e telephony-styl e digit dial plans

• gateway routes, which provide access to the gateways

• SIP telephon y routes, which point to oth er SIP Application Mo dules, and SIP domains and subdomains for interdomain routing using telephony-style dial plans

Overview 15

SIP Aliases

Alias URLs can be used to refer to a SIP client in the network. For example, a user “sip: u serA@domainX. com” can also be ref erred to by an alias of “sip:41037@domainX.com”.

If an incoming request specifies the “sip:41037@domainX.com” alias in a Request-URI, the alias takes precede nce over gateway ro uting translations, and r ou ting information pert aini ng to use rA i s r etri eve d. I f an alias of “sip:410 37@domain X.com” is not confi gured, then g ateway routing translations are performed to find out if a terminating gateway exists.

Multiple Route Termination

If a single SIP user is registered at more than one device (PSTN or SIP), forking is used to terminate a session simultaneously or sequentially to multiple devices.

The SIP Application Module interfaces with the SIP database to determine the use r routing preference, the r outes available, and ro uting options for a particular user. The user defines these options through the SIP Personal Agent. For additional information on the SIP Personal Agent, refer to the on-product help and SIP Personal Agent Getting

Started Guide.

16 Overview

Call Processing Language

Nortel Networks Confidential

With simultaneous ringi n g, the call terminates to multiple routes at the same time. The first terminating route to answer is accepted and the rest of the routes are released.

With sequent ial ringi ng, the call tries to terminate to on ly one of several routes at a time. Route advancement occurs whenever an error response is received, a provisionable No Answer timer expires, or a redirect response is received.

The SIPApplication Module supports the use of the Call Processing Language (CPL), based on the IETF CPL draft, draft-ietf-iptel-cpl.txt. SIP clients can ch ange the behavior of a session using a CPL script that contains general directives for routing a request.

For example, subscribers can include CPL scripts in the body of registration requests that contain instructions for location lookups and call screening, a pr ocess that is actually done th rough the Call Manager in the Personal Age nt. Third-p arty client s can also up load script s using the Registration mechanism. The Registration function of the SIPApplication Module stores the request. When the SIPApplication Module is queried for routing information for a subscriber who has valid data stored in the database, the software returns the script along with the routing information. The SIPApplication Module applies the CPL script to the returned routes and can eliminate or alter the routes based on the CPL script.

CPL scripts do not support the following:

• Remove location

• Mail option

• Log option

Interworking services

Discriminator service

The SIPApplication Module screens requests bound for devices that are not fully SIP compli ant, for example, the Communication Server for Enterprise (CS E) 2000. These comp onents canno t process all types o f signaling and certain media change requests. Therefore, the SIPApplication Module either performs the requested operation or rejects the request and responds with an error response.

The Discriminator service works with various gateways and SIP clients using provisioning facilities implemented by the SIP Application Module. As gateways or SIP clients with limited SIP capability are added to the network, this service can be configured to support these

Nortel Networks Confidential

devices. Information for each component is stored in .xml format to provide flexibility when describing the capabilities o f the component.

Bearer Path Control

The SIPApplication Module uses the RTP Media Portal to control media streams originating from and terminating to non-compliant SIP devices if they d o not support media negotiations. The ex ception to this occurs when the o rigin at ing a nd ter minat in g p art ie s are both th e sam e device type. If both gateways are CSE 2000s, for example, the SIP Application Module does not use the RTP Media Portal.

Privacy Control service

The SIP Application Module supports Privacy Control based on draft-ietf-sip-privacy. This draft defines a mechanism that allows clients to supply a network server with their private user information while at the same time instructing the server no t to pass that information outside the boundaries of the truste d network. The information is passed in a Remote-Party-ID header with the privacy indica tor set to “full.” The SIP Application Module removes this header any time it forwards the message out over a public network interface.

Overview 17

Service package enforcement

A service package is made up of a user’s enabled network services, such as audio conferencing, and subscriber profile. The service provider defines the available service packages for the domain. The domain provisioner can then assign a specific service package to a subscriber.

Authentication services

The SIP Application Module performs user authenticat i on when the server receives an incoming SIP request. The SIP Applicatio n Mo dule supports the challenge-based Digest method for SIP Client-to-Proxy authentication. In Digest authentication, the SIP Application Module challenges a client when a SIP request is received. The SIP Client re-sends a SIP requ est with a valid password an d user name att ached. The request types to be authenticated are configurable.

Note: Only US ASCII is supported for user names.

The software performs authentication using the password of the subscriber originating the call. Only subscribers from a local domain actually have a password stored in the database to authenticate against. If a subscriber from a foreign domain (refer to t he no te below for definitions of these types of domains) places a call and authentication is required for a known foreign domain, the

18 Overview

Converged PC service

Nortel Networks Confidential

authentication fails since the database does not have the subscriber's information. As a result, the call is blocked.

Administrators can configure whether they want a call from an unknown foreign domain authenticated or not. System administrators can also specify foreign proxie s in the Nodal Auth fiel d of the Authenticati on t ab. In this way, no requests originating from those proxies are failed because of authentication.

Note: The following definitions apply:

• Local Domain: Local domains are provisioned for and serviced by a particular SIP Application Module. Su bscribers for a particular system belong to local domains. Local domains are provisioned through the Provisioning Client.

• Foreign Domai n: A foreign domain is a domain that is eithe r provisioned as foreign for this SIP Application Module or not provisioned at all for this specific system. It b asically represents a domain that is not served.

The Converged PC service allows end users to use their PCs for the multimedia portion of their communications while using their existing telephony system for voice. The service uses the simring feature on an existing telephony system to send mirrore d calls to the SIP Application Module through the SIP PRI Gateway . This allows the SIP Application Module to presen t a ca ll wi ndow o n the end user 's PC w hen t he use r's desktop phone rings.

If both parties in a call are Converged users, they will each get a call window from which they can initiate multimedia sessions such as Instant Messaging and collaborative applications between each other.

Some benefits of providing multimedia services using the Converged service are:

• End users can keep using their existing telephone and its capabilities.

• There is no need to replace an existi ng telephony switch to add multimedia capabilities.

Nortel Networks Confidential

The Converged service adds the following cap abilities to the end user's telephony service:

• the ability to manually redirect incoming calls to another party from the PC

• the ability to set up automated enhanced routing and screening of incoming calls based on time of day or based on the calling party's identity

• a call log of all incoming calls

• the ability to send instant messages to the party on the other end of a call

• the ability to start collaborative applications such as shared whiteboard, file transfer, and clipboard transfer with the party on the other end of the call

• the ability to receive a picture ID of the party on the other end of the call

Network/Address Hiding service

The SIP Application Module uses SIP and the Session Description Protocol (SDP) to coordinate the establishment of multimedia sessions for signaling and media, respectively. These protocols embed IP information in their messaging. While Networ k Address Translation (NAT) devices change port and address informati on in the IP packet header , most are not currently SIP or SDP aware. IP addresses in these messages are theref ore sent out unchange d through the NA T. If the SIP Application Mo du le were to for w ar d the se messa ge s on uncha nged, sensitive IP inform ation w ould be gi ven to untr usted clien ts. In or der to remedy this, the SIP Application Module sanitizes the messages before forwarding them.

Overview 19

For IP information in the SIP headers, the SIP Application Module either removes the header (for example, Via headers) or replaces the IP address with the address of the SIP Application Server (for example, Contact head er). A media portal is necessary in order to re place the IP information in the SDP headers. The SIP Application Module queries the Media Port al (u si ng M GC P+) for a new IP and port combi n ati o n to replace the IP and port put th ere by th e client . This ef fe ctively an chors the media stream at the Media Portal.

Clients therefore see the SIP Application Module as their signaling endpoint and th e Media Port al as their R TP media en dpoint. They have no knowledge, and therefore no IP information, about the other client they are in a session with.

20 Overview

Nortel Networks Confidential

The RTP Media Portal handles Network Hiding for the media stream. For information on the R TP Media P ortal, re fer to the MCP RTP Media Portal Basics document.

Note: The SIPApplication Module cannot map SDP information without an RTP Media Portal. It only performs address mapping for SIP header fields. Therefor e, SDP p asses thr ough unto uched. If the server must map SDP address information, then you need an RTP Media Portal.

The SIPApplication Module is configured to use an RTP Media Portal to originate and terminate media streams (RTP/RTCP). The SIPApplicati on Mod ul e uses exte nd ed Me di a Gatew ay Co ntr o l Protocol (MGCP+) to allocate and release resources on the RTP Media Portal for each session as needed.

Enterprise Clients

The SIPApplication software uses the RTP Media Portal to hide sensitive IP address information about SIP clients behind a firewall in an Enterprise netw ork. The exception to th is occurs when the orig inator and terminator of the request are both part of the same network. This status is de ter min ed b y ch ecki ng th e do mains in the From head er a nd Request-URI of the SIP Invites. If both SIP clients belong to the same Enterprise netw or k, th e S IP Ap pl i cation Module does not u se th e RTP Media Portal. Adm inistrators can overri de this behavior by provision ing the AlwaysUseMediaPortal domain parameter in the Provisioning Client (for more information about this parameter, see the SIP Provisioning Client User Guide). See Figure 6, “RTP Media Portal interworking with Enterprise or foreign clients.”

Nortel Networks Confidential

Overview 21

Figure 6 RTP Media Portal interworking with Enterprise or foreign clients

Public Domain

SIP Client

SIP

RTP/RTCP

911 Notification support

The SIP Application Module supports Instant Message notifications to a specified On-Sit e Notification (OSN) location whenever a user makes a call to an emergency number such as 911. The software provides this service using the same mechanis m that allows us ers to push web pages and/or email links back to the originator of a call. In order to do this, administrators set up (at the Personal Agent) an emergency subscriber for each OSN location and a private telephony route to map the emergency number to this subs criber. Since telephony routes are only unique w ithin a sub doma in, you canno t have mo re t han one OSN location for each subdomain.

Enterprise Domain

SIP Client

SIP

MGCP+

RTP/RTCP

RTP/RTCP Media Portal

For each new emergency subscriber that the administrator creates, there must be both

• an emergency numbe r to route to the Public Safety An swering Point (PSAP)

• a SIP subscriber assigned t o the OSN loca tion that is to rece ive the notification.

Each OSN location must have a specific subscriber assig ned, such as sip:guarddeskA@nortelnetworks.com.

22 Overview

Instant Messaging

Presence

Nortel Networks Confidential

For more information a nd the procedure for setting up In stant Message notifications to emergency numbers, see the SIP Provisioning Client

User Guide.

Instant Messages are routed in parallel only to a subscriber' s dynamically registe r ed r ou tes ( see “Reg i str ati on —static and dynamic” on page 24). This is in contrast to session initiation requests, whi ch are subject to CPL routing logic. Upon receipt of an instant message, a client may respond back to the address supplied in the Contact header. This ensures that the response is sent back to the same client device that originally sent the message .

When a user initially reg isters, by default th eir presence st atus is set to “on-line” in the SIP re gistration message . Users subscribe to watch the status of other use rs, and to coordinate the status of their own devices. This information is maintained in an in-memory table on the SIP Application Mo dule (Presen ce software). The informatio n that is stor ed in this table includes:

• the user to be watched

• the party reque sting the subscription

• the correlation informatio n identifying that particular subscription request

• contact information regarding where to send the notifications that are generate d as a result of the subscription being active

When a user chan ges their presence (for example, to Busy), a registration message is automatically sent to the SIP Application Module.

The SIP Application Module then checks its in-memory table to see what their previous prese nce state was. If the update causes a m aterial change in their presence state, the SIP Application Module looks up which users need to be notified of the change (also in memory). This is done by sending a Notify message to each user at every contact contained in the table. For more information, refer to the MCP SIP Presence Basics document.

Voicemail server interoperability and MWI

In order to accomplish voicemail server interoperability and MWI (message waiting indication) notification, the SIP Application Module

Nortel Networks Confidential

transmits the following information over a data link to a voicemail server:

• the called number (terminating party's telephone number)

• the calling numb er

• the type of call forwarding (for example, due to a busy line, an unanswered call)

This feature also provides an interface to pure IP solutions that use a SIP-enabled voicemail server. In this case, SIP messages provide the context data for each call needed by the voicemail server to record a voicemail message. Thus, a SIP-enabled voicemail server accepts Invites for calls routed to voicemail and sen ds Notify messages for MWI information. The softwar e uses Real -T im e Transport Protoc ol (R TP) to carry the voice media.

There are two co nfigurations throu gh which the SIP Ap plication Module supports voicemai l:

• A pure IP, third-party, SIP-enabled voicemail server that uses RTP to establish the voice path from the subscriber to the voicemail server while SIP provides the setup and MWI information.

Overview 23

• A legacy voicemail server that uses a SIP/PSTN gateway to establish the voice path from the subscriber to the PSTN-based voicemail server. The Simplified Message Desk Interface (SMDI) protocol provides the setup information. The platform uses any voicemail server that suppor ts the SMDI protocol. There are two supported physical connections: a line-based gateway and a PRI/T1-based gateway.

Using either of the above configurations, there are three primary scenarios that this feature co nsiders:

• MESSAGE DEPOSIT: An incoming call for a subscriber gets rout ed to voicemail because the called subscriber is unavailable, busy, or has all calls forwarded to voi cem ai l.

• MESSAGE NOTIFICATION: The voicemail server sends an MWI status update to the SIP Application Module for a particular subscriber. The SIP Application Module then sends a message to the client(s) to update its MWI display.

Note: Clients do not store the MWI state. Only the Presence Module stores the state. When a client registers with the proxy

24 Overview

Nortel Networks Confidential

and has messages waiting, the system sends a Notify to the client.

• MESSAGE RETRIEVAL: A subscriber calls the voicemail server for message retrieval. The subscriber is then connected to the voicemail server and accesses the mailbox to retrieve messages.

When you provision the voicemail server, specify which SIP Application Module is the host (see the Configuration chapter in this docume nt for details). Only the SIP Application Module that is hosting a particular voicemail server attempts to establish an SMDI connection with that voicemail server.

Note: SMDI is used in certain voicemail configurations to allow the voicemail server to send Message Waiting Indication information to the SIP Application Module. Also when connected to a lines-based voicemail server, the SIP Application Module sends an SMDI message to the voicemail server when a call is being routed to voicemail for messag e deposit. The SMDI information includes which mailbox the message should be deposited in. Also, the voicemail server periodically sends an SMDI heartbeat message to the SIP Application Mo dule. The SIP Application Mod ule must respond to this message to let the voicemail se rver know that the SMDI link is still up.

Registration—static and dynamic

Registration can take two forms:

•Static Users or administrators can perform st atic registra tions. With st atic

registration, the user can obtain a presence when not logged into the network. The user can obt ain a presen ce and an accoun t in one of the following ways:

— Using the SIP Provisioning Client, the administrator can add a

user account and assign a static route.

— When users have accounts, they can add contact information,

such as PSTN numbers or cell phone numbers, to their routing information.

•Dynamic Once a user logs in, re-registration is automatic with the SIP

Multimedia PC Client, the SIP Multimedia Web Client, and the IPCM. The IPCM takes car e of this re-reg istr ation aut omati cal ly for the i2004. Dynamic registration is automated and behind the scenes.

Nortel Networks Confidential

Network address book

Client Address Book information is stored in the network so that it can be accessed from all clients. The information is downloaded in bulk whenever a client comes on line (either through a Simple Object Access Protocol [SOAP] int erface or direct database access depend ing on the client).

In order to receive updates to the Address Book after the initial download, the c lient subscribe s to the Address Book event package and updates it as needed. Whenever an update is made through the Personal Agent or one of the clients, a Notify message is sent to the client indicating which entries have changed. The client can then incrementall y update their view of the info rmation (aga in either thro ugh a SOAP interface or direct database access depending on the client).

A List of Buddie s is incorporate d as part of the Address Book. Each subscriber must create th eir own personal Address Book an d designate their own Buddies. For each of these specified entries, the client automatically subscribes to their pre sence eve nt packa ge. Thi s allows them to monitor and update the network presence of each Buddy (for example, online or offline).

Overview 25

Overload control

Overload Control monitors the Incoming Protocol Message Queue Length. If this queue l ength crosses a configurable threshold value, the system performs Session Blocking, allowing no new incoming request s to process. The system does, however, continue to process requests for an established session. For rejected requests, the system sends a “503 Service Unavailable” response with a Retry-After header, which specifies the amount of time a client should wait before retrying the request.

Note that multiple thresholds may be crossed simultaneously. If this occurs, the appropriat e actions are invoked and are not cleared until al l aspects of the system have crossed below the assigned threshold value.

26 Overview

Reliability and fault tolerance

Nortel Networks Confidential

The SIP Application Module provides reliability and fault tolerance through multiple SIP Application Mo dules deployed in an N+M active-standby configuration.

Note: The supported active/standby configurations include:

• a 1+1 configuration (one active plus one standby server), which is the most basic reliable configuration

• an N+M configuration of up to four servers (the sum of N plus M should not exceed 4)

— a 2+1 (2 active and one standby) — 2+2 configuration — 3+1 configuration

To accomplish this, all the servers in a reliability group are configured with the same set of NSDs. This gives the standby server the information it needs in case an active server fails. Each server in the group transmits messages indicating its current state. Other servers respond with their curren t states, including th e NSD activated on the m.

An initializing server configures itself with one of any inactive NSDs. If all NSDs are active, the initializing server becomes the standby. This prevents confl i cts where more than on e server is activating simultaneously.

Before activating, the server determines whether it is isolated from critical network resources defined through provisioning. If any of the resources cannot be reached, the server cannot activa te and raises an alarm. The alarm clears when the resources become available.

When there are two or more active servers, the g roup is called a cluster . You can configure b oth the N+M strate gy and the cluster at the Transport Management tab in step 22 in the Configuration chapter.

When one of the active SIP Application Modules fails, the passive Module takes over the IP address. The passive Module has now become active and assumes the responsibilities of the failed Module. When this occurs, any sessions already in the active state remain up. This means that ca lls that ha ve already bee n establ ished contin ue and the parties maintain voice path. Any future requests during that session, however , fai l (for examp le, Hold, Retr ieve, and W eb Pu shes) since th e session information is no longer available. Any sessions that were not in the active state bef ore the failove r ar e lost. The ori ginating clien ts o f

Nortel Networks Confidential

these sessions either receive no indication or continue to hear an alerting tone for an indefinite period of time.

Manual failover

There are two recommended procedures for manually initiating the fail-over of an active instance to a Standby node: the initiation of discrete LOCK and UNLOCK actions, or the initiation of a restart.

Lock/Unlock If you want to force a fail-over in order to perform maintenance on the "failed" se rver, then request a LOCK from th e Management Console. The LOCK forc es the component into a disabled operational state, where it remains until you request an UNLOCK from the Management Console. You can perform any maintenance on the "failed" server while it is LOCKed. Once maintenance is complete, the server can be UNLOCKed from the Management Console, which causes an automatic restart and brings the server back into service.

Overview 27

28 Overview

Nortel Networks Confidential

Restart If you want to simply force an immediate manual fail-over, then you can request a Restart from the Management Console.

WARNING

The N+M reliability strategy provides a highly available service environment. The fail-over mechanisms enable an instance of the S IP Application Module to survive failure condition(s) by migrating to a standby server where it can resume the processing of new sessions.

In such a highly available service environment the failed instance loses all knowledge of sessions started before the fail-over event. Therefore, the stability of these pre-existing sessions cannot b e guaranteed. For examp l e:

Sessions involving SIP clients will survive until the clients encounter a "no response" or "unknown call" response to a request on their active se ssion. At that point the clients will release the session and its associated media resources.

For more information, see the Configuration chapter in this document.

OAM&P strategy

The Management Module manages the OAM&P functions for the SIP Application Module. For additional information, refer to the MCP

Management Modu le Basics and the MCP System Management Console Basics documents.

Sessions involving the MCP SIP PRI Gateway will survive until there is no response to the SIP PRI Gateway-generated SIP "ping" to the SIP Application Module(s) handling the active sessions on the gateway. If there is no response to the SIP "ping" then the gateway will tear down the associated call and recovers its resources.

Also, sessions involving the MCP RTP Media Portal will not survive a manual fail-over because intentionally LOCKing the SIP Application Module initiates the automatic recovery of all resources (including RTP Media Portal resources) associated with in-progress sessions.

Nortel Networks Confidential

Upgrades

For information on upgrading from one full relea se to another, refer to the Installation and Commissioning document you receive wi th the upgrade.

Updating the SIP Application Module software

Administrators can update the software version of the SIP Application Module using the System Management Console. The update can be either an up- or down-version of the software.

Updating the software affects the operation of the component’s hosted services during the procedure. This process automatically fills the service property fields of the updated component with the configured values from the previous version.

The update introduces new functionality across many components without affecting network stability. If a server update fails, you have a choice to roll back or not. For more information on the update procedure, refer to the MCP System Manageme nt Co nso le Basi cs document.

at the System Management Console

1 A load can be either up-versioned or down-versioned. In either

case, updating a load from one version to another results in stopping and deleting the previously added version, adding the new version and auto-launching the new version. Therefore, there is no need to manually LOCK and UNLOCK the service. The steps involved in an update are described below.

From the System Management Console, under the

Components folder , sele ct the name configured at deployment, AppSvr in the example shown in Figure 1.

30 Upgrades

Nortel Networks Confidential

Figure 1 Updating the Application Module from the menu tree

You can also launch the update from the pull-down Configuration menu, as shown.

+ 84 hidden pages