Nortel Networks NN10033-111 User Manual

Succession Multimedia Communications Portfolio

MCP Interworking

Basics

Standard MCP 1.1 FP1 (02.02) April 2003

NN10033-111

Nortel Networks Confidential

Overview

How is this chapter organized

This chapter provides a high-level overview of the interworking between the Multimedia Communications Platform (MCP) and the following systems:

• Primary Rate Interface (PRI)-enabled switches

• SIP-T-based switches

• third-party g ateways

• traditional phones

• third-party vo icemail servers

Interworking with PRI-enabled switches

The MCP uses the SI P PRI Gateway to perf orm interworking with PRI-enabled switches (switches with PRI interfaces).

For more detailed information about the SIP PRI Gateway, please refer to the MCP SIP PRI Gateway Basics document.

Functional description

The SIP PRI Gateway is a signaling and media gateway that interconnects a SIP-based Voice over IP (VoIP) domain and a system that uses ISDN Primary Rate Interface (PRI/Q.931).

A PRI-enabled system can be a switch that works on the Public-Switched Telephone Network (PSTN) or Private Branch Exchange (PBX). The Nortel Networks DMS-100 and the Nortel Networks Meridian SL-100 are examples of PRI-enabled switches.

The SIP PRI Gateway’s primary functio n is to convert the packet-based voice streams of the V oI P system to circuit-based vo ice streams of the PRI-enabled system.

4 Overview

Supported services

Nortel Networks Confidential

The SIP PRI Gateway supports the following call types:

• SIP to PRI

• PRI to SIP

• PRI to PRI The SIP PRI Gateway supports the following call features:

• Basic call: The ability to make a call.

• Hold/Retrieve: The ability to hold and retrieve calls.

• Call transfers: The ability to forward the call to a third party after the call is established. Call transfer is limited to SIP clients. Callers from the PRI-enabled switches cannot perform this function.

• Call redirect: The ability to forward a call before it is answered.

• Codec negotiation: The ability to negotiate between different VoIP codecs during call setup, mid-call, call transfer, and call retrieve. The SIP PRI Gateway supports the following codecs:

— G.711 mu-law (PCMU) — G.711 a-law (PCMA) — G.723.1 — G.729a

• Call rejection: The ability to reject a call on nodal authentication request.

• Calling party name and number: The MCP supports the delivery/reception of calling party name and number information to/from PRI-enabled switches. Incoming callin g party informa tion privacy indication is honored by the MCP . For MCP call originations, privacy indication is not used.

• Dual-Tone Multi Frequency (DTMF) outpulsing: The ability to outpulse to PRI-enabled sw itches. However , DTMF detection is not provided. Military DTMF digits A-D are current l y not supported.

• ISDN trunk group selection: The selection is based on information provided in a request Universal Resource Identifier (URI).

• Ringback: The SIP PRI Gateway provides ringback towards the circuit-switched side of the network.

• PRI variant support: The SIP PRI Gateway supports different PRI variants. For a list of the PRI variants that the SIP PRI Gateway supports, please refer to the MCP SIP PRI Gateway Basics document.

Nortel Networks Confidential

• SIP/PRI mapping support, including: — Protocol parameter mappin g — error codes — PRI cause values with SIP responses — presentation a nd screening indicators

• PRACK: the provisional response acknowledge message that ensures that the ringing signal does not get lost.

• T ype of Server (ToS): The ToS bit can be configured to indicate the priority of the voice packet over data packet to ensure quality of service.

• Long-call service: The ability to detect abandoned calls.

More detailed information about the functional capabilities of the SIP PRI Gateway is available in the MCP SIP PRI Gateway Basics document.

Interworking with CS 2000

Even though Nort el Ne tw orks C om m unication Server 2000 (CS 2000) is a V oIP switch, it d oes not fully suppor t the Session Initiati on Protoco l (SIP). The following de scri p ti on provides information on how the MCP interworks with the CS 2000.

Overview 5

The MCP does not support VoIP over Asynchronous Transfer Mode (ATM) or pure ATM, as the MCP network nodes are IP-based and not ATM based.

Functional description

The interworking betw een an MCP and CS 2000 uses Session Initiat ion Protocol for Telephones (SIP-T) over User Datagram Protocol (U DP) to transport ISDN User Part (ISUP), the call control part of the Signaling System 7 (SS7) protocol.

SIP-T is an e xtension of the Se ssion Initiation P rotocol (SIP) that allows SIP to be used to facilitate the interconnection of the Public Switched Telephone Network (PSTN) with p acket networ ks. SIP-T e ncapsu lates the ISDN User Part (ISUP) messages in the SIP messages and translates ISUP information into the SIP header for routing purposes.

Although the MCP SIP Application Module supports receiving of encapsulated ISUP messaging (usi ng SIP-T), it does not send encapsulated ISUP back out. For more information about the capabilities of the SIP Application Module, please refer to the SIP Application Mo du le Basi cs document.

6 Overview

Nortel Networks Confidential

Figure 1 shows a network view of the MCP/CS 2000 interconnection. The MCP configuration enables direct connection between the MCP and CS 2000 with no intervening SIP proxies. The CS 2000 and its associated media gateways are placed in the private managed network.

Figure 1 MCP/CS 2000 Network view

network 1

Supported services

This section provides inform ation on services that can interwork between the two platforms .

PSTN

SIP-T

MCP

SIP-T

SIP

SIP-T

PSTN

network 2

SIPSIP

MCP

network 2

VPN Dialing

A Virtual Pr ivate Network (VPN) d ial plan enables an enterprise to have one common dial plan across different geographic locations without incurring long-distance expenses.

The MCP system uses domains to man age its call routing, while the CS 2000 system uses customer groups.

A profile is used to facilitate call routing between the two systems. The header named “x -nor tel- pro file” is used to ident ify the CS 20 00 pro file. The profile is used to ma p the domain to a PSTN custome r group in the PRODOMAIN table in the Database Module.

Nortel Networks Confidential

The profile is added when a new do main is created in the MCP system.

Note: The profile name in the TEL EPROF table on the CS 2000 side must match the profile name in the PRODOMAIN table on the MCP side. Otherwise, interworking between the MCP and CS 2000 will not work.

Call Forward

Both the MCP and the CS 2000 support call forwarding. No extra interworking consider ati ons are necessa ry as call forw ardi ng does not interact across the MCP and CS 200 0 domains, except to deliver a call between the two domains.

Call Transfer

Call transfer works between the two platforms. The calls are transferred because from each platfor ms view the other is ju st ini tiatin g a new call.

Ad Hoc Conference calls

There is no change in the conference application between the two platforms. Whe n an ad hoc conference call is made, the client application that starts the conference controls where the conference bridge is allocated. For exa m ple, i f the conference call is made from a client application on the MCP side, the conference bridge will be allocated on the MCP.

Overview 7

Media Negotiation

The MCP provides media negotiation for the CS 2000 since the CS 2000 gateway contr ol ler i s not capable of providing this function in the current release.

The MCP requires a list of all commonly supported codecs across the CS 2000 media gateways to be provisioned in the cs2k.xml file. The list is required because the MCP does not determine which gateway the CS 2000 will use.

Although the MCP also allo ws f or the pr ovision ing o f p acket ti mes th at the CS 2000 will use, this is not recommended. By provisioning specific packet times, the SDP packet time will no longer pass transparently through the MCP. This means that the packet time negotiation that would normally occur at the client level is now being handled at the server level, and this could lead to voice connection issues.

The SDP sent by the CS 2000 media gateways is only guaranteed to contain the v=, c= , m=, and a= SDP heade rs in the SDP message. The gateways can accept reception of other SDP parameters, so no screening needs to be done on the SDP that the MCP sends to the CS

2000. The only exception is the screening of the m= lines to only

8 Overview

Nortel Networks Confidential

include the audio codecs supported by the gateways. For the SDP that is received from the CS 2000, the MCP fills in the missing mandatory parameters as specified in RFC 2327. Details on the restrictions on SDP are specifie d in the SN03 IP Gateway InterOP Requirements document.

Recursive Search

The MCP Back-to-Back User Agent (BBUA) handles SIP 302 responses to an INVITE sent out because of a received INVITE from the CS 2000. The BB UA sends INVITEs for each contact in the S IP 302 response. The SIP 302 response will not be passed back to the CS

2000. The INVITES fo r each contact can be sent parallel or sequ entially

depending on the mode in which the BBUA processed the initial INVITE, which then resulted in the SIP 302 response.

Hold

SIP implement s a Hold as a re-INVITE with the connectio n information in the SDP set to 0.0.0.0. In this release, Hold cannot be handled by all the CS 2000 media gateways. The MCP shields the CS 2000 from seeing Hold re-INVITE requests. The MCP, when equipped with an RTP Media Port al, ca n ma nage the RTP connections witho ut af fe cting the connection to the CS 2000.

Retrieve

Retrieve is also implemented in SIP through a re-invite. To retrieve a party on hold the new invite contains va li d SDP. The new SDP is use d to restore the media connection between the two clients.

Long Call Audit Timers

In order to prevent hung calls between the two platforms, a long call audit timer is implemented between the two platforms. Both platforms use the INFO ping capability described in the SIP INFO message RFC2976. This involves sending an INFO message with no message body. Upon receipt of this message, a client should send a 200 OK if the call exists. If the response to the INFO is any of the following response codes, then the platf orm sending the message assumes that the call no longer exists and frees all resources associated with the call:

• 404 Not Found

• 408 Request T im eo ut

• 410 Gone

• 480 Temporarily Unavailable

• 481 Transaction Does Not Exist

Nortel Networks Confidential

If the platform sending the INFO receives a response code other than the ones listed above, it tre at s the re sponse a s a valid au dit resp onse, and does not bring the call down.

The CS 2000 sends a 2 00 OK for a n em pty IN FO message and a 481 response code if the call leg does not exist.

Supported media

The following are the media su pported b y the inter working o f MCP and the CS 2000:

• G. 711 PCMU

• G. 711 PCMA

•G. 729

•G. 723

•G3 Fax

• Modem

Note 1: This list represents a full list of the media capabilities the MCP can use while inte rworkin g wit h the CS 2 000. The actual list of supported media types depends on the capabilities of the gateways that the CS 2000 is using.

Overview 9

Note 2: G3 Fax and Modem media calls are used only for CS 2000 gateway calls as there are no MCP endpoints that support either of these two media types.

QoS

MCP implements its Quality of Service through the DiffServ (Differenti ate d Ser vi c e) feature. The parameters of MCP QoS includ e the following:

• QoS DiffServ code for s i gnaling: specifies signaling quality for SIP clients.

• QoS DiffServ code for au dio: specifies audio quality for SIP clients.

• QoS DiffServ code for video: specifies video quality for SIP clients.

• QoS 802.1p for service priority: specifies service priority for SIP clients.

Interworking with third-party gateways

The MCP can use SIP signaling between the MCP networ k and a third-party SIP-enabled gateway. The third-party gateway provides the necessary signalling interworking between the MCP network and the other network to whic h the gateway is conn ected. For example, a

10 Overview

line-based voicemail server requires that a Line Gateway be placed between the MCP network and the voicemail server. This Line Gateway would process SIP message s to/from the MC P network and create the corresponding line signalling to/from the line network. “Interworking with third-party voicemail servers” on page 13, provides more information about how the MCP interworks with non-SIP aware voicemail servers.

Interworking with traditional phones

The MCP provides Con verged Desktop Servi ces (CDS) to facilit ate the interworking with traditional phones of the TDM network. This allows users to have a p ersonal computer (PC) provide the m ultimedia porti on of their communication session while having the traditional telephony system provide the voice portion of their communication session.

Functional description

A user’s Converged Desktop consists of a regular TDM telephone, and a SIP Multimedia PC Client (PC Client) software provisioned as a Converged PC Client. Figure 2 shows how the Converged PC Client interconnects wit h the ne twor k. Th e C o nve rged PC C l ient pr ovide s a n enhanced communication experience to the user, while the TDM telephone works exactly as it does today.

Nortel Networks Confidential

Figure 2 Converged Desktop Services Network Diagram

MCP network

PRI

Existing

switching system

Various line protocols

SIP

Converged Desktop

Converged

PC Client

Traditional

phone

Nortel Networks Confidential

Converged Desktop Services

CDS enhances the end user’s communication experience in a variety of ways:

• Advanced Call Handling: The user can use the MCP Personal Agent web pages to control the user’s availability. By providing this ability to CDS users, features not easily accessible on existing TDM switching systems now become viable. For example, a user can activate MCP-based f orking (using the Personal Agent we b pag es) so that when the user’s desktop telephone is called, the users cell phone rings as well. Once one leg of the forked call is answered, the other leg stops ri ng in g.

• Inbound call log: Allows the user to see who has cal l ed and when the call occurred.

• Video calling line identification: Allows the user to see who is callin g. The picture is retrieved from the network-based address book accessible on the Converged PC Client.

• Redirection of incoming calls at the Converged PC Client: Upon the arrival of an incoming call, the user may click on the “Redirect” button, and send the incoming call to another address. Once the user answers the call (using the TDM phone), the redirect function is no longer available.

Overview 11

• File transfer: If both the originator and terminator support the MCP file transfer collabora ti on ap pl ic ation , t hen files can be transferred back and forth between the two users. The PC Client (both Converged and non- C on ver ge d) is th e only endpoint that supports this functionality.

• Whiteboard sharing : If both the originator and te rminator support the MCP whiteboard collaboration application, then a whiteboard session can be set up between the two user s. The PC Cli ent (bot h Converged and non- C on ver ge d) is th e only endpoint that supports this functionality.

• Clipboard transfer: If both the originator and terminator support the MCP clipboard transfe r collaboration applicati on, then the Windows System Clipboard may be transferred between the two users. The clipboard transfer application allows a user to “Copy (CTRL-C)” items such as PowerPoint slides or sections of Excel sp readsheet s to the clipboard, and then sends them to the other party. The other party then “Pastes (CTRL-V)” the items. The PC Client (both Converged and non- C on ver ge d) is th e only endpoint that supports this functionality.

• Web Co-bro wsing: If both the or iginator an d termina tor are capa ble of this functionality, then one user can automatically drive the other’s web browser. The PC Client (both Converged and

12 Overview

Configuration Requirements

Nortel Networks Confidential

non-Converged) i s the only endpoi nt that support s this functionality. The Web Client supports the reception of web pages, but cannot send web pages to a Converged PC Client.

• Instant Messaging (IM): The Converged PC Client can send and receive messages from any client that support s the Nortel Ne tworks IM format. All MCP clients support sending a nd receiving of inst ant messages with each other.

• Presence state indications: The Con verged PC Client allows the user to select a presence state in the MCP ne twork. The Converged PC Client also allows the user to see the presence state s for the Buddies defined in the user’s network-based address book.

PRI is used as the interface between the existing TDM switching system and the MCP. The MCP supports the following PRI protocol variants:

• AT&T 4ESS(AT4)

• AT&T 5ESS (E10)

• AT&T TR 41459

• Bellcore National 2

•ETSI

•ECMA-143

• ETS 300 102-1

• Northern Telecom DMS-100 (DMS)

• NIS A211-1

•QSig

For more detai led information a bout the which PRI varian ts the SIP PRI Gateway supports, please refer to the MCP SIP PRI Gateway Basics document.

Successful interworking between the MCP and the TDM switch requires that the TDM switch acti vate the Simultaneous Ring (SimRing) feature and assign each user a SimRing number. A user in the TDM switch that has acquired this SimRing n umber can be a C DS user . Th e SimRing featur e must send “SimRing” calls to a routable and unique number for each CDS user.

The MCP system operator must provision a user a s a CDS user . A CDS user cannot use the SIP Multimedia PC Client for voice. The CDS user’s TDM phone is u sed for voice. In addition, the CDS user m ay use

Nortel Networks Confidential

other SIP endpoints (such as the SIP Multimedia Web Client or an i2004 controll ed by the IP Client Ma nager (IPCM) for voice over IP calls.

An MCP alias must be set up for each user so that the alia s is the same as the Calling Line ID sent from the TDM switch to the MCP over PRI. When a non-CDS MCP user calls a CDS user, the call is sent out the gateway to the CDS user’s TDM phone and the non-CDS user’s public/private charge ID is used to identify them to the TDM switch as the calling party. This charge ID is sent to the Converged PC Client, on the SimRing leg of the call, an d is used by the Con verged PC Cli ent to contact the calling party’s MCP client. Therefore, the non-CDS user’s charge ID must be included as an alias in the non-CDS user’s provisioning. A non-CDS user’s charge ID cannot be shared amongst users within a domain because the charge ID must be included as an alias and a user's aliases must be unique within a domain.

Calls to a CDS user must terminate to the existing switching system of the CDS user before the call is routed to the MCP. For example, the originator’s existing switching system must route calls using the existing systems, as opposed to sending the call to the MCP. This is required since all calls from the SIP PRI gateway are implied to have been triggered by the SimRing feature on the existing switching system.

Overview 13

Interworking with third-party voicemail servers

There are three major types of third-party v oicemail servers. The following sections describe how the MCP can interwork with the following types of third-party voicemail servers:

• SIP-based voicemail servers

• Trunk-based voicemail servers

• Line-based voicemail servers

SIP-based voicemail servers

SIP-based voicemail servers are SIP-enabled and can interwork directly with the MCP network. SIP is used to set up connections between the client and the voicemail server. The RTP Media Portal is used to carry the media packets between t he client and the voicemail server.

Figure 3 shows how the MCP interconnects with a SIP-aware third-party voicemail server.

+ 29 hidden pages