Interworking Fundamentals

Transcription

1 NN

2 Document status: Standard Document version: 0104 Document date: 16 February 2010 All Rights Reserved Sourced in Canada The information in this document is subject to change without notice The statements, configurations, technical data, and recommendations in this document are believed to be accurate and reliable, but are presented without express or implied warranty Users must take full responsibility for their applications of any products specified in this document The information in this document is proprietary to Nortel Networks Nortel, Nortel (Logo), and the Globemark are trademarks of Nortel Networks All other trademarks are the property of their respective owners

3 3 Revision history February 2010 Standard 0104 This document is up-issued to update the section Configuring LDAP March 2007 Standard 0103 This document is up-issued to support Multimedia Communication Server 5100 Release 40 This document addresses CRs Q and Q January 2007 Standard 0101 This document is issued to support Multimedia Communication Server 5100 Release 40 This document contains information previously contained in the following legacy document, now retired: Interworking Basics (NN ) January 2006 Standard 40 This document is up-issued for MCS 5100 Release 35 Some referenced document numbers changed November 2005 Standard 30 This document is up-issued for MCS 5100 Release 35 November 2005 Standard 20 This document is up-issued for MCS 5100 Release 35 October 2005 Standard 10 This document is up-issued for MCS 5100 Release 35 NN Standard Release February 2010

4 4 Revision history NN Standard Release February 2010

5 5 Contents New in this release 9 Features 9 ipdialog interoperability 9 Private/public name and number display 9 Interoperability 9 Other changes 10 How to get help 11 Finding the latest updates on the Nortel web site 11 Getting help from the Nortel web site 11 Getting help over the phone from a Nortel Solutions Center 11 Getting help from a specialist by using an Express Routing Code 12 Getting help through a Nortel distributor or reseller 12 Overview 13 Introduction 13 PRI-enabled switches 14 Interworking with Enterprise Business Networks systems 14 SIP-based communication servers 16 SIP trunking 16 CS 1000 and MCS 5100 dialing and numbering plan configuration 17 Dialing and numbering plan issues for the mixed network 18 SIP-T-based communication servers 30 Functional description 30 Supported services 31 Supported media 34 Quality of service 34 Equal Access workaround 34 Converged Desktop interworking (traditional and IP Phones) 38 Converged Desktop configurations 38 Nortel switching systems supported 38 SIP-based Converged Desktop 39 Interfaces supported 41 Key assumptions and limitations 41 SIP-based CDS Multimedia Client startup 43 NN Standard Release February 2010

6 6 Contents Preferred Audio Device (PAD) selection 44 Converged Alias to user mapping 45 Interface Node to SIP signaling gateway 45 SimRing Converged Desktop service (SimRing CDS) 48 Third-party gateways 51 Vegastream 51 Mediatrix FXO and FXS gateways 52 Voice mail servers 53 Legacy CAS-based voice mail servers 54 Third-party voice mail servers 57 SIP-based voice mail servers 57 Trunk-based voice mail servers 58 Line-based voice mail servers 59 Voice mail server interoperability and Message Waiting Indicator 60 Third-party clients 62 Lightweight Directory Access Protocol 62 Enhanced Upgrades 65 PRI-enabled switches 65 SIP-T-based communication servers 65 Converged Desktop phones (traditional and IP Phones) 65 Third-party gateways 66 Third-party voice mail servers 66 Configuration management 67 Guidelines for configuring SIP-based Converged Desktop 67 Provisioning data gathering 71 Provisioning guidelines 74 Configuring IN to SIP Signaling gateway 89 Configuring a CD user at the switch 89 Configuring the switch routing 90 Configuring the MCS 5100 for SCP connectivity 90 Configuring voice mail servers 90 Configuring LDAP 91 LDAP Server configuration 93 LDAP Schema configuration 94 User defaults 99 LDAP Synchronizing Scheduler 100 LDAP Query Test Tool 102 Add and configure the Media Gateway 104 NN Standard Release February 2010

7 Contents 7 Fault management 115 Accounting management 117 Performance management 119 Security and administration 121 Terminology 123 Figures Figure 1 MCS 5100 and CS 1000 network view 31 Figure 2 Equal Access signaling diagram (PRI) 36 Figure 3 Equal Access signaling diagram (SIP-T) 37 Figure 4 SIP-based CDS user network diagram 40 Figure 5 Signaling and media path 40 Figure 6 Numbers assigned in MCS and switching system 42 Figure 7 SIP-based CDS Multimedia Client main display 44 Figure 8 MCS architecture with SCP 46 Figure 9 Single domain to multiple domain mapping 48 Figure 10 SimRing Converged Desktop services network 49 Figure 11 Vega-100 gateway 52 Figure 12 Mediatrix FXS and FXO gateways 53 Figure 13 CAS-based voice mail server 54 Figure 14 MCS 5100 to CallPilot 107 interworking 56 Figure 15 CAS Gateway URI and Channel Mapping 56 Figure 16 CallPilot Service DN Mapping 56 Figure 17 SIP-based voice mail server 58 Figure 18 Trunk-based voice mail server 59 Figure 19 Line-based voice mail server 60 Figure 20 Company ABC DIT 62 Figure 21 Carrier configuration 68 Figure 22 General data gathering 74 Figure 23 MCS configurations with USP 75 Figure 24 Normal configuration 76 Figure configuration 77 Figure configuration 77 Figure Redirect 78 Figure 28 Top level domain menu 79 Figure 29 Sample CD user 81 Figure 30 Converged Desktop properties 82 Figure 31 Service DN menu 85 Figure 32 LDAP synchronization screen 92 Figure 33 LDAP server configuration screen 94 Figure 34 Company ABC DIT 95 Figure 35 Company ABC Refined DIT 96 Figure 36 LDAP schema configuration DN and attribute mapping 97 Figure 37 User defaults 99 Figure 38 LDAP Synchronizing Scheduler for weekly schedule 101 NN Standard Release February 2010

8 8 Contents Figure 39 LDAP Query Test Tool 103 Tables Table 1 SIP gateway solutions for interworking with MCS Table 2 Phone-context strings for public numbers (example) 26 Table 3 Phone-context strings for unknown numbers (example) 27 Table 4 Phone-context strings for private numbers (example) 27 Table 5 Search results of location database 29 Table 6 Converged Desktop services supported Nortel Switching Systems 39 Table 7 Services for Converged Desktop users 69 Table 8 Services 70 Table 9 Terms 71 Table 10 Provisioning information 72 Table 11 Services available to Converged Desktop subscribers 79 Table 12 Converged Desktop properties 84 Table 13 Mandatory LDAP attributes 96 Table 14 Optional LDAP Attributes 97 Table 15 Synchronizing frequency 102 Procedures Procedure 1 Creating a CD user 82 Procedure 2 Adding Converged Desktop service data 86 Procedure 3 Adding an LDAP server 93 Procedure 4 Adding an LDAP schema configuration 97 Procedure 5 Adding user defaults 99 Procedure 6 Adding an LDAP Synchronizing schedule 101 Procedure 7 Performing an LDAP Query Test 103 Procedure 8 Adding and configuring the Media Gateway 104 Procedure 9 Provisioning the Media Gateway node and domain 108 Procedure 10 Provisioning the Media Gateway Logical Entity 110 Procedure 11 Provisioning Media Gateway Routing Class of Service 111 Procedure 12 Adding telephony routes for the Media Gateway 112 NN Standard Release February 2010

9 9 New in this release The following sections describe what is new in (NN ) for Multimedia Communications Server (MCS) 5100 Release 40 Features The following features affect this book: "ipdialog interoperability" (page 9) "Private/public name and number display" (page 9) "Interoperability" (page 9) For more information, see MCS 5100 New in this Release (NN ) ipdialog interoperability This feature provides the Distinctive Ringing function for the Manitone ipdialog SIP telephone The function extends the MCS features to support the new telephone Private/public name and number display This feature introduces private and public name and number display to the MCS Calls that are made to or from the MCS are identified as private or public, based on the originating domain If a call is private, then the name and number is not displayed on the telephone If the call is public, the name and number (if available) are displayed on the telephone The public or private designation is used within the customer s MCS as well as in the outside telephone network Interoperability The interoperability between MCS 5100 Release 40 and Business Communication Manager (BCM) Release 40 includes SIP trunking only The following are supported: UDP transport BCM 40 as static, trusted generic endpoint NN Standard Release February 2010

10 10 New in this release Other changes This document was renumbered from NN to NN This document was changed to adhere to the Nortel Customer Documentation Standard The Audiocodes Mediant 2000 gateway has been renamed to Media Gateway 3200 NN Standard Release February 2010

11 11 How to get help This chapter explains how to get help for Nortel products and services Finding the latest updates on the Nortel web site The content of this documentation was current at the time the product was released To check for updates to the latest documentation for Multimedia Communication System (MCS) 5100, go to wwwnortelcom and navigate to the Technical Documentation page for MCS 5100 Getting help from the Nortel web site The best way to get technical support for Nortel products is from the Nortel Technical Support web site: wwwnortelcom/support This site provides access to software, documentation, bulletins, and tools to address issues with Nortel products From this site, you can: download software, documentation, and product bulletins search the Technical Support web site and the Nortel Knowledge Base for answers to technical issues arrange for automatic notification of new software and documentation for Nortel equipment open and manage technical support cases Getting help over the phone from a Nortel Solutions Center If you do not find the information you require on the Nortel Technical Support Web site, and you have a Nortel support contract, you can also get help over the telephone from a Nortel Solutions Center In North America, call NORTEL ( ) Outside North America, go to the following web site to obtain the telephone number for your region: wwwnortelcom/callus NN Standard Release February 2010

12 12 How to get help Getting help from a specialist by using an Express Routing Code To access some Nortel Technical Solutions Centers, you can use an Express Routing Code (ERC) to quickly route your call to a specialist in your Nortel product or service To locate the ERC for your product or service, go to: wwwnortelcom/erc Getting help through a Nortel distributor or reseller If you purchased a service contract for your Nortel product from a distributor or authorized reseller, contact the technical support staff for that distributor or reseller NN Standard Release February 2010

13 13 Overview Introduction This chapter provides a high-level overview of the interworking between the Multimedia Communication Server (MCS) 5100 solution and the following systems: "PRI-enabled switches" (page 14) "SIP-based communication servers" (page 16) "Converged Desktop interworking (traditional and IP Phones)" (page 38) "Third-party gateways" (page 51) "Voice mail servers" (page 53) "Third-party clients" (page 62) The MCS infrastructure is a set of elements required to support the suite of services with access clients, gateways, and media servers Nortel offers a formalized process to achieve interoperability with third-party vendors through Nortel Developer Program (DP) The DP offers a vendor an infrastructure of legal agreements, processes, and marketing tools for engaging third parties with complementary solutions to perform compatibility testing and establishing a commercial relationship with Nortel As part of the developer program, the MCS can interwork with the following third-party products: SIP-to-PRI Gateway using AudioCodes Mediant 2000 Primary Rate Interface (PRI) gateway provides an alternative to the Nortel Session Initiation Protocol (SIP) Primary Rate Interface (PRI) Gateway SIP-to-PRI Gateway using VegaStream 100 provides an alternative to the Nortel SIP PRI Gateway SIP-to-T1 CAS Gateway using AudioCodes Mediant 2000 CAS gateway provides an alternative to the Nortel SIP PRI Gateway 4-port SIP-to-FXS Gateway using Mediatrix 1104 provides connection for analog handsets and fax machines into the MCS Solution NN Standard Release February 2010

14 14 Overview 4-port SIP-to-FXO Gateway using Mediatrix 1204 provides connection into the Public Switched Telephone Network (PSTN) or Enterprise Time Division Multiplex (TDM) network SMDI Voice Mail MCS provides interoperability with voice mail systems that support Station Message Desk Indicator (SMDI) (GR-283-CORE) SIP Voice Mail MCS provides interoperability with voice mail systems that support SIP interworking PRI-enabled switches The MCS uses the MCS Trunking Gateway to perform interworking with PRI-enabled switches (switches with PRI interfaces) The MCS Trunking Gateway is based on the AudioCodes Mediant 2000 PRI Gateway platform The gateway converts between packet-based and circuit-based voice stream SIP endpoints with PSTN devices The gateway provides interworking with all SIP clients, existing PRI gateways, voice mail systems, and TDM switches support for PRI call handling support for all SIP multimedia services, including audio conferencing, music on hold, Converged Desktop services Interworking with Enterprise Business Networks systems The primary network services objective for MCS 5100 is to interwork in a peer-to-peer relationship with existing Enterprise Business Networks (EBN) systems including Meridian 1 (M1) family of Private Branch Exchanges (PBX) Business Communications Manager (BCM) Nortel Communication Server 1000 (CS 1000) Nortel Communication Server 2100 (CS 2100) Nortel Communication Server 2000 (CS 2000) The following requirements relate to interworking using the PRI (DMS100) interface This alternative supports private dialing plan interworking with the Meridian 1 and CS 1000 (both Customer Dialing Plan [CDP] and Universal Dialing Plan [UDP]), as well as a limited number of supplementary service features MCS 5100 supports the following peer networking scenarios through the SIP-to-PRI gateway (for example, through the Digital Multiplex System [DMS] 100): Private dialing (both CDP and UDP) NN Standard Release February 2010

15 PRI-enabled switches 15 Between MCS 5100 and Meridian 1 systems with limited supplementary services feature support Between MCS 5100 and CS 1000 systems with limited supplementary services feature support PSTN access from MCS 5100: across the PRI gateway through the Meridian 1 system to the PSTN across the PRI gateway through the CS 1000 system to the PSTN using a PRI gateway to the PSTN using an FXO gateway to the PSTN With CDP, users to dial fewer digits when calling other users in the same building or on the same campus (for example, dialing instead of ) UDP offers the same convenience for calling remote locations by making it possible for network users to dial a three digit number (instead of the remote site area code) and traditional number prefix (for example, dialing instead of ) The following table lists SIP gateway solutions for interworking with MCS 5100 Table 1 SIP gateway solutions for interworking with MCS 5100 Application Gateway Vendor Protocols Capacity Private networking to Meridian 1, CS 1000, BCM, CS 2100 Private networking to Meridian 1, CS 1000, BCM, CS 2100 Mediant 2000 AudioCodes SIP-to-PRI (DMS100) Vega 100 VegaStream SIP-to-PRI (DMS100) Private networking to CS 1000 UAS Nortel SIP-to-PRI (DMS100) Converged Desktop with Meridian 1, CS 1000, CS 2100 PSTN access (local, national, international) PSTN access (local national, international) Vega 100 VegaStream SIP-to-PRI (DMS100) Vega 100 VegaStream SIP-to-PRI (DMS100) 1-16 PRI links 1-2 PRI links 4-48 DS1s Mediatrix 1204 Mediatrix SIP-to-FXO 4 port 1-2 PRI links 1-2 PRI links NN Standard Release February 2010

16 16 Overview Application Gateway Vendor Protocols Capacity PSTN access (local, national, international) MCS 5100 to analog stations and fax machines UAS Nortel SIP-to-PRI (NI-1/2, 4/5 ESS, DMS100) 4-48 DS1s Mediatrix 1104 Mediatrix SIP-to-FXS 4 port MCS 5100 to CallPilot Mediant 2000 AudioCodes SIP-to-T1 CAS 1-8 DS1s SIP-based communication servers This section describes interworking with SIP-based communication servers SIP trunking With SIP trunking, MCS interworks with the CS 1000 using SIP without requiring a gateway to convert between SIP and PRI SIP trunking provides SIP interworking between the MCS and CS 1000; MCS and CS 1000 development streams are aligned SIP trunking supports all SIP functionality included in CS 1000 Translations and routing SIP trunking supports private dial plans (UDP and CDP) for SIP trunking interfaces, including third party gateway interoperability for public access It also support per call number qualification capabilities for SIP trunking interfaces SIP trunking supports interworking of dial plans and services, and the transit of called party number, calling party name and number, Type of Number (TON) and Numbering Plan Identifier (NPI), and presentation or screening indicators between the application server and gateway (CS 1000) endpoints for the following call scenarios: SIP to SIP SIP to PRI SIP trunking supports call routing based on E164, Private Number, and alias ID Services SIP trunking supports the MCS services between the Session Manager and the gateway (CS 1000) endpoints NN Standard Release February 2010

17 SIP-based communication servers 17 SIP trunking supports calls originating from and terminating to any of the following client devices between the Session Manager and CS 1000 endpoints: All supported clients on the MCS All supported terminals on the CS 1000 Converged Desktop terminals on CS 1000 SIP trunking supports the Notify Message Waiting Indicator (MWI) for the message in following the scenarios: CallPilot is hosted on the CS 1000 The CS 1000 maps NMS services to SIP and sends the MWI to MCS CallPilot cannot be hosted on the MCS to support users on the CS 1000 The MCS deliver the MWI message to CS 1000 SIP trunking supports G711, G729a, and G729ab voice codecs, and codec negotiation between endpoints are supported G723 is not supported SIP trunking supports Dual-Tone Multi-Frequency (DTMF) transport using the SIP INFO message CS 1000 and MCS 5100 dialing and numbering plan configuration The CS 1000 and MCS 5100 systems interwork directly using SIP over UDP transport only Both systems are deployed in a single mixed customer network The three types of users in this mixed CS 1000 and MCS 5100 customer network are: CS 1000 user CS 1000 user has an account created on the CS 1000 system The only client available to the CS 1000 user is a client under CS 1000 control This user does not have an account on the MCS 5100 system and the user cannot use the clients under MCS 5100 control MCS 5100 user MCS 5100 user has an account created on the MCS 5100 system The only client available to the MCS 5100 user is a client under MCS 5100 control This user does not have an account on the CS 1000 system The user cannot use the clients under CS 1000 control Converged user A Converged Desktop user has two accounts (a CS 1000 account and an MCS 5100 account) The Converged Desktop user also has two available clients which include a client under CS 1000 control (for example, an IP Phone 2004) and a client under MCS 5100 control (this is the Multimedia PC Client) Note: In this document, Multimedia Client is used to represent the Multimedia PC Client, Multimedia Web Client, Multimedia Office Client and Multimedia PC Client for IBM Lotus Notes NN Standard Release February 2010

18 18 Overview A Converged Desktop user always uses the CS 1000 client as an endpoint for audio streams (in this configuration, the Multimedia Client cannot terminate or originate audio streams) A call itself is initiated on the CS 1000 client or on the Multimedia Client The Multimedia Client uses the click-to-call mechanism to engage Converged Desktop When the user is not in a converged state, the user effectively becomes an MCS 5100 user Dialing and numbering plan issues for the mixed network In a mixed CS 1000 or MCS 5100 network, you must pay special attention to addressing If a CS 1000 user originates a call and the call must terminate at an MCS 5100 user, then the destination address given to the MCS 5100 system must make sense to the MCS translation engine The same requirement applies to the call in the opposite direction; a destination address that the MCS 5100 passes to the CS 1000 system must make sense to the CS 1000 translation engine Digit-based addresses and alphanumeric addresses The CS 1000 translation engine supports only digit-based addresses An example is 5573 The MCS 5100 translation engine supports both digit-based and alphanumeric addresses Examples are and asmith Rule #1 All users in a mixed CS 1000 and MCS 5100 network must be accessible through a digit-based address (on the CS 1000 system as well as on the MCS 5100 system) Dialing plan issues The term dialing plan is used in a very broad sense in this context It includes all the arrangements that determine an exact digit sequence that the user must dial to access a destination To access a destination, a user must know an appropriate access code (for the type of destination being called) and the unique address of the destination (within a certain address space) In most cases, the following may be required: no access code, for private or CDP numbers access code for private or UDP numbers (for example, 6) access code for public or local numbers (for example, 9) access code for public or national numbers (for example, 61) access code for public or international numbers (for example, 6011) NN Standard Release February 2010

19 SIP-based communication servers 19 Certain numbers used to access a service (for example, 911 and 411) are special cases Depending on which system is providing the special number service (CS 1000, MCS 5100, or PSTN), then the special number is accessed as follows: without dialing an access code (for example, with an emergency service the user dials 911) with an access code (for example, with the PSTN directory service, the user can be required to dial 9411) Rule #2 In a mixed CS 1000 and MCS 5100 network, both systems must have the dialing plan configured in the same manner For example, at a certain location, a user must be able to make a call to a UDP number by dialing the same digit string on a CS 1000 client as on an MCS 5100 client Rule 2 is important for a Converged Desktop (CD) user Although a CD user can enter a destination number on the Multimedia Client, the call itself is originated under the CS 1000 control DNs as MCS aliases versus DNs as MCS user names The following section discusses how to assign a digit-based address (that is, directory number [DN]) to an MCS 5100 user Several options are available to associate a DN with an MCS user: provision the user name in the form of a DN provision the user s alias in the form of a DN provision the user s CD alias in the form of a DN provision the user s public and private charge ID in the form of a DN The existing MCS practice is to provision a user with an alias in the form of a DN This works for non-converged MCS 5100 users but presents problems to CD users when they initiate calls from the converged Multimedia PC Client in the click-to-call mode, specifically from the following locations: Call Logs Inbox window Friends Online window Directory window In the above cases, if the DN represents an MCS 5100 user, the call is initiated and connects to the destination identified by the MCS user name In the case of a CD user, the call is actually handled by the CS 1000 Call Server, which routes based on DN addresses only To ensure that the CS 1000 Call Server receives a DN-based address, the MCS 5100 replaces the user name with the user s private charge ID NN Standard Release February 2010

20 20 Overview Rule #3 In a mixed CS 1000 and MCS 5100 network with Converged Desktop users, MCS 5100 private charge IDs must be in the form of a UDP number Directory number qualification When you use digit-based addressing, you must include the directory number qualification Existing telephony systems support multiple address spaces The address spaces include the following: Public address space that is subdivided into the following categories: Local numbers National numbers International numbers Private address space that is subdivided into the following categories: Level 0 regional numbers (in CS 1000 terminology, these are known as Coordinated Dialing Plan [CDP] numbers) Level 1 regional numbers (in CS 1000 terminology, these are known as UDP numbers) ATTENTION On the CS 1000, each customer can have their own Customer Dialing Plan Other types of dialing plans, for instance a Coordinated Dialing Plan, can be part of each Customer Dialing Plan Both the Customer Dialing Plan and the Coordinated Dialing Plan use the same acronym (CDP) To be useful, a DN must be scoped within an appropriate address space One way of achieving this is by qualifying DNs Both the CS 1000 and MCS 5100 systems implement a phone-context parameter of the user info field of the telephony-based SIP Universal Resource Identifier (URI) as a means to fully qualify a DN A SIP URI with the user=phone-context parameter is known as a telephony-based SIP URI A SIP URI without the user=phone-context parameter is known as a non-telephony-based SIP URI or a regular SIP URI The format of a regular SIP URI is sip:[username]@[domainame] The format of a telephony-based SIP URI is sip:[directorynumber];phone-context=[phonecontext]@[domainam e];user=phone sip:+[directorynumber]@[domainname];user=phone NN Standard Release February 2010

21 SIP-based communication servers 21 Rule #4 In a mixed CS 1000 and MCS 5100 network, all DNs that pass between the two systems must be in the form of a telephony-based SIP URI If Rule 4 is not followed, a CDP DN might be incorrectly interpreted as a UDP number, or a public or local number might be incorrectly interpreted as an UDP number Converged Desktop implications The biggest impact of the adopted addressing scheme on the Converged Desktop feature in a mixed CS 1000 and MCS 5100 network is click-to-call With Click-to-Call, Converged Desktop users initiate a call using their converged Multimedia PC Client user interface but use their CS 1000 client to conduct the voice conversation The converged Multimedia PC Client provides several methods for a user to initiate Click-to-Call You initiate Click-to-Call: from the Directory window from the Friends Online window from the Call Logs window from the Make a Call window These four user interfaces retrieve an address The retrieved address has several origins The address is an MCS 5100 user name (as defined by an MCS 5100 administrator) The address was delivered by an incoming call over a route The address was entered directly by the user (personal directory) The address was entered by an MCS 5100 administrator or retrieved from a directory (global directory) It is very difficult for the CS 1000 system to route calls based on the retrieved address alone The address must be either: explicitly qualified (in terms of phone-context) by the MCS 5100 system implicitly qualified using a proper prefix by the MCS 5100 system Mixed network example The following is an example of a dialing plan setup for a mixed CS 1000 and MCS 5100 network Sample network The sample network has the following characteristics The network includes several sites NN Standard Release February 2010

22 22 Overview Each site has a mixture of CS 1000 users, MCS 5100 users, and Converged Desktop users Dialing within a site is done using CDP numbers (no access code, four digit numbers) Dialing among the sites is done by dialing 6 + seven digit UDP number Local PSTN hop-off is done by dialing 9 + local number National dialing is done by dialing national number International dialing is done by dialing international number CS 1000 user configuration The CS 1000 user configuration involves configuring both the general user and the Converged Desktop user For more detailed information on the CS 1000, see IP Peer Networking: Installation and Configuration ( for CS 1000 Release 45; NN for CS 1000 Release 50) Note: CS 1000 must use UDP transport for interworking with MCS 5100 General user configuration The general user configuration applies to both stand-alone and Converged Desktop users The general user configuration involves the following: Configure the user s extension as a four digit number For example, extension = 5573 Configure the three digit Home Location Code (HLOC) for user groups (that is, customers) For example, HLOC = 343 The HLOC and user s extension create the user s UDP number The number is unique within an Enterprise: HLOC + extension For example, UDP Number = Configure the Private Network Identifier (PNI) for user groups (that is, customers) For example, PNI = PNI, HLOC, and the user s extension create the Global user ID that is globally unique: PNI + HLOC + Extension For example, Global ID: Converged Desktop user configuration The Converged Desktop user configuration involves the following: Configure the user s class of service (CLS) to include Converged Desktop Multimedia Only (CDMO) or Converged Desktop Multimedia and Voice (CDMV) Configure the Converged Desktop Service (CDS) parameters NN Standard Release February 2010

23 SIP-based communication servers 23 CS 1000 SIP services use the user s global ID within CD-related signaling (for example: invite and notify) CS 1000 translation configuration The translation configuration involves the following: Configure the CDP routing Distant Steering Codes (DSC) and Local Steering Codes (LSC) based on the 4-digit CDP numbers Configure the UDP routing (AC1, AC2, HLOCs, and LOCs) (based on dialing 6 + the seven-digit UDP number) Configure the PSTN routing (AC1, AC2, NXX, NPA, SPN, and so on) according to the previously listed access codes Configure the CS 1000 SIP Gateways at each site with appropriate phone-context strings: UDP phone-context For example, phone-context="companyabccom" CDP phone-context For example, phone-context="site1companyabccom" Public or Local phone-context For example, phone-context="+1613" Public or National phone-context For example, phone-context="+1" MCS 5100 user configuration The MCS 5100 user configuration involves the general user, stand-alone use, and the Converged Desktop user configurations General user configuration The general user configuration applies to both stand-alone and Converged Desktop users The general user configuration involves the following: Configure the user name as an alphanumeric address For example, Username = asmith Configure the user private charge ID as the UDP number For example, Private Charge ID = Stand-alone user configuration The stand-alone user configuration involves the following: Do not include the CDS in the service package Configure the user s alias as the Global ID: PNI + UDP number For example, Alias = NN Standard Release February 2010

24 24 Overview Converged Desktop user configuration The Converged Desktop user configuration involves the following: Include the CDS in the service package Do not define the user s regular alias Configure the user s CD alias as the Global ID: PNI + UDP number For example: CD Alias = Configure the user s Preferred Audio Device (PAD) as: 6 + UDP number For example: PAD = MCS 5100 translation configuration The MCS 5100 translation includes pretranslation, private telephony routes, and gateway telephony routes configuration Pretranslation configuration Configure pretranslations to support CS 1000-to-MCS 5100 calls to do the following: If the UDP phone-context is received, then insert 6 For example, if phone-context="companyabccom", then insert 6 If the CDP phone-context is received, then insert 6 + HLOC For example, if phone-context="site1companyabccom", then insert 6343 If the Public/Local phone-context is received, then insert 9 For example, if phone-context="+1613", then insert 9 If the Public/National phone-context is received, then insert 61 For example, if phone-context="+1", then insert 61 If the Public/International number is received, then insert 6011 For example, DN starts with "+", then insert 6011 Private telephony routes Configure private telephony routes to support CS 1000-to-MCS 5100 calls as well as MCS 5100-to-MCS 5100 calls as follows: Local termination using UDP dialing (to/from digits 6 + HLOC + LSC, length 8, remove 1, prefix PNI) For example: to/from digits 63435, length 8, remove 1, prefix Local termination for CDP dialing (to/from digits LSC, length 4, remove 0, prefix PNI + HLOC) For example: to/from digits 5, length 4, remove 0, prefix NN Standard Release February 2010

25 SIP-based communication servers 25 Gateway telephony routes Configure gateway telephony routes to support MCS 5100-to-CS 1000 calls as follows: Outgoing routes using UDP dialing (to/from digits 6 + LOC, length 8, remove 1, use UDP phone-context) For example: to/from digits 6444, length 8, remove 1,phonecontext="companyabccom", private Outgoing routes using CDP dialing (to/from digits DSC, length 4, remove 0, use CDP phone-context) For example: to/from digits 2, length 4, remove 0,phonecontext="site1companyabccom", private Results This configuration allows the following calls using DN addressing: CS 1000 user to CS 1000 user calls MCS 5100 user to MCS 5100 user calls CS 1000 user to MCS 5100 user calls CS 1000 user to Converged Desktop user calls MCS 5100 user to Converged Desktop user calls Most of the click-to-call scenarios Phone-context parameter configuration of a telephony-based SIP URI The SIP Phone-context parameter qualifies a DN beyond the usual Numbering Plan Identifier (NPI) and Type of Number (TON) In addition to the NPI/TON, the phone-context parameter includes unique identification of the scope for which the number is valid If a CDP number is dialed within the Site1 CDP domain of the COMPANY ABC network and the call must be routed at the network level (by a network router like CS 1000 Redirect Server or MCS 5100 Proxy Server), then the number must be qualified with a phone-context parameter that incorporates the following: NPI = Private TON = CDP Enterprise ID = companyabccom CDP Domain ID = Site1 These elements must be combined such that the resulting string is globally unique NN Standard Release February 2010

26 26 Overview Global uniqueness of phone-context strings is a prerequisite to serve a domain (for example, CDP-domain or an area code) by several systems (such as CS 1000 and MCS 5100) If the Site1 CDP domain is divided between a CS 1000 and an MCS 5100 system, both systems must define and recognize then a globally unique phone-context for Site1 CDP domain Note: The CS 1000 Redirect Server only routes calls to the CS 1000 users and the MCS 5100 only routes calls to MCS 5100 users Phone-context strings for public numbers Table 2 "Phone-context strings for public numbers (example)" (page 26) provides an example for creating phone-context strings for public numbers Table 2 Phone-context strings for public numbers (example) NPI/TON NPI=Public, TON=International NPI=Public, TON=National NPI=Public, TON=Local (See Note) NPI=Public, TON=Special NPI=Public, Scope Global National For exampl e, mynation Area within nation For exampl e, myarea, mynation Area within nation For exampl e, myarea, mynation Area within nation Hierarchical domain-based schema international e164 myrootdomain mynation national e164 myrootdomain myarea mynation local e164 myrootdomain myarea mynation special e164 myrootdomain Global prefixbased schema Not applicable DN starts with + +1 (+"country code") (+"countrycode"-"a rea code") Not supported CS 1000 Redirect Server implementation Not applicable DN starts with + +1 (+"country code") (+"country code"-"area code") Not supported myarea Not supported Not supported Note: Support for NPI=Public/TON=Local numbers is introduced by CS 1000 Release 40 NN Standard Release February 2010

27 SIP-based communication servers 27 NPI/TON Scope Hierarchical domain-based schema Global prefixbased schema CS 1000 Redirect Server implementation TON=Unknown For exampl e, myarea, mynation mynation unknown e164 myrootdomain Note: Support for NPI=Public/TON=Local numbers is introduced by CS 1000 Release 40 Phone-context strings for unknown numbers Table 3 "Phone-context strings for unknown numbers (example)" (page 27) provides an example for creating phone-context strings for unknown numbers Table 3 Phone-context strings for unknown numbers (example) NPI/TON Scope Hierarchical domain-based schema Global prefix-based schema CS 1000 Redirect Server implementation NPI=Unknown TON=Unknown Location For example, mylocation mylocation unknown wnunknown myrootdomain Not supported Not supported Phone-context strings for private numbers Table 4 "Phone-context strings for private numbers (example)" (page 27) provides an example for creating phone-context strings for unknown numbers Table 4 Phone-context strings for private numbers (example) NPI/TON NPI=Private, TON=Level 1 Regional (UDP) Scope Enterprise For example, myenterprise Hierarchical domain-based schema level1 private myenterprise Global prefix -based schema (the number of the enterprise) CS 1000 Redirect Server implementatio n myl1domain Note: CS 1000 SIP Gateway support for NPI=Public/TON=Unknown numbers is introduced by CS 1000 Release 40 CS 1000 SIP Redirect Server does not support NPI=Public/TON=Unknown numbers NN Standard Release February 2010

28 28 Overview NPI/TON NPI=Private, TON=Level 0 Regional (CDP) NPI=Private, TON=Special NPI=Private, TON=Unknown (see Notes) Scope Location within Enterprise For example, mylocation, myenterprise Location within Enterprise For example, mylocation, myenterprise Location within Enterprise For example, mylocation, myenterprise Hierarchical domain-based schema mylocation level0 private myenterprise mylocation special private myenterprise mylocation unknown private myenterprise Global prefix -based schema (the listed number of the location) (the listed number of the location extended with 1) (the listed number of the location extended with 2) CS 1000 Redirect Server implementatio n myl0domain myl1domain myspeciallabel myl0domain myl1domain myunknownlabe l myl0domain myl1domain Note: CS 1000 SIP Gateway support for NPI=Public/TON=Unknown numbers is introduced by CS 1000 Release 40 CS 1000 SIP Redirect Server does not support NPI=Public/TON=Unknown numbers CS 1000 redirect server operation In a mixed CS 1000 and MCS 5100 network, the following is expected: The CS 1000 SIP Redirect Server routes calls to SIP endpoints (gateways and SIP lines) under CS 1000 control The MCS 5100 routes calls to SIP endpoints (gateways and SIP clients) under MCS 5100 control Note: In the context of SIP, the use of the phrase endpoint under XXX control indicates that entity XXX is the only entity that knows the contact information for the endpoint Provisioning is impacted in the following manner: The CS 1000 SIP Redirect Server represents all CS 1000 endpoints in the MCS 5100 provisioning The MCS 5100 Session Manager represents all MCS 5100 endpoints in the CS 1000 provisioning NN Standard Release February 2010

29 SIP-based communication servers 29 This network configuration requires the CS 1000 SIP Redirect Server and MCS 5100 to interwork seamlessly This section describes the basics of the redirect server logic For more detailed information about the CS 1000, see IP Peer Networking: Installation and Configuration ( for CS 1000 Release 45; NN for CS 1000 Release 50) Note: CS 1000 must use UDP transport for interworking with MCS 5100 The following items describe the operational logic of the CS 1000 SIP Redirect Server: When an invite is received, the Public Address is extracted from the request URI For example: invite SIP/20 When the SIP Redirect Server searches the location database, it tries to find all the endpoints that meet the following requirements: The endpoint belongs to the specified domain The endpoint has associated routing entries (with both of the following): exact phone-context as the one received longest DN-prefix that prefixes the received DN Table 5 "Search results of location database" (page 29) shows the possible outcomes of the location database search Table 5 Search results of location database If The resolution fails (that is, no endpoints are found), the SIP Redirect Server redirects to a collaborating server The collaborating server Sends the 302 response (Moved Temporarily) Build the Contact Address of the 302 response to include the collaborating server Internet Protocol (IP) address For example: <sip:dn;phone-context=pc@domain:5060; maddr= ;transport=tcp; user=phone> NN Standard Release February 2010

30 30 Overview If A single endpoint is found If multiple endpoints are found The collaborating server Sends the 302 response (Moved Temporarily) Build the Contact Address of the 302 response to include the endpoint IP address This can be IP address of the MCS 5100 Session Manager For example: <sip:dn;phone-context=pc@domain:5060; maddr= ;transport=tcp; user=phone> Send the 300 response (Multiple Choices) Include multiple Contact-headers in the 300 response Individual Contact-header URIs are built Contact-headers are ordered according to route costs SIP-T-based communication servers Even though the CS 1000 is a Voice over IP (VoIP) switch, it does not fully support the Session Initiation Protocol (SIP) The following description provides information about how the MCS 5100 interworks with the CS 1000 The MCS 5100 does not support VoIP over Asynchronous Transfer Mode (ATM) or pure ATM, since the MCS 5100 network nodes are IP-based and not ATM based Functional description The interworking between an MCS 5100 and CS 1000 uses Session Initiation Protocol for Telephones (SIP-T) over User Datagram Protocol (UDP) to transport ISDN User Part (ISUP), the call control part of the Signaling System 7 (SS7) protocol SIP-T is an extension of the Session Initiation Protocol (SIP) that allows SIP to facilitate the interconnection of the PSTN with packet networks SIP-T encapsulates the ISDN User Part (ISUP) messages in the SIP messages and translates ISUP information into the SIP header for routing purposes The MCS 5100 Session Manager supports receiving of encapsulated ISUP messaging (using SIP-T) and sends it back out For more information about the capabilities of the Session Manager, see Session Manager Fundamentals (NN ) NN Standard Release February 2010

31 SIP-T-based communication servers 31 Figure 1 "MCS 5100 and CS 1000 network view" (page 31) provides a network view of the MCS 5100 and CS 1000 interconnection The MCS 5100 configuration enables direct connection between the MCS 5100 and CS 1000 with no intervening SIP proxies The CS 1000 and its associated media gateways are typically placed in the private managed network Figure 1 MCS 5100 and CS 1000 network view Supported services This section provides information about services that can interwork between the two platforms VPN dialing A Virtual Private Network (VPN) dial plan enables an enterprise to have one common dial plan across different geographic locations without incurring long-distance expenses The MCS 5100 system uses domains to manage its call routing, while the CS 1000 system uses customer groups NN Standard Release February 2010

32 32 Overview A profile is used to facilitate call routing between the two systems The header named x-nortel-profile identifies the CS 1000 profile Because the CS 1000 does not support domains, the profile is used to map a customer group on the CS 1000 to a domain on the MCS 5100 platform When a new domain is created, a new profile is added in the MCS 5100 system ATTENTION Verify that table TELEPROF on the CS 1000 matches what is configured in table PRODOMAIN on the MCS 5100 platform If they do not match, interworking between the MCS 5100 and CS 1000 will not function correctly Call forward Both the MCS 5100 and the CS 1000 support call forwarding No extra interworking considerations are necessary because call forwarding does not interact across the MCS 5100 and CS 1000 domains, except to deliver a call between the two domains Call transfer Transferred calls are handled by the transferring and terminating servers as though the transferring server is originating a new call Ad Hoc audio conference calls There is no change in the conference application between the two platforms When an Ad hoc audio conference call is made, the client application that starts the conference controls where the conference bridge is allocated For example, if the conference call is made from a client application on the MCS 5100 side, the conference bridge is allocated on the MCS 5100 Media negotiation The MCS 5100 provides media negotiation for the CS 1000 because the CS 1000 gateway controller is not capable of providing this function in the current release The MCS 5100 requires a list of all commonly supported codecs across the CS 1000 media gateways provisioned in the appropriate discriminator file The MCS 5100 needs this list because the MCS 5100 does not determine which gateway the CS 1000 will use The MCS 5100 also allows for the provisioning of packet times that the CS 1000 will use If you provision specific packet times, the Session Description Protocol (SDP) packet time no longer passes transparently through the MCS 5100 This means that the packet time negotiation that normally occurs at the client level is now handled at the server level, and this can lead to voice connection issues NN Standard Release February 2010

33 SIP-T-based communication servers 33 The SDP that the CS 1000 media gateways send is only guaranteed to contain the v=, c=, m=, and a= SDP headers in the SDP message The gateways can receive reception of other SDP parameters, so no screening is needed on the SDP that the MCS 5100 sends to the CS 1000 The only exception is the screening of the m= lines to include only the audio codecs supported by the gateways For the SDP that is received from the CS 1000, the MCS 5100 fills in the missing mandatory parameters as specified in RFC 2327 Recursive search The MCS 5100 Back-to-Back User Agent (BBUA) handles SIP 302 responses to an invite sent out because of a received invite from the CS 1000 The BBUA sends invites for each contact in the SIP 302 response The SIP 302 response is not passed back to the CS 1000 The invites for each contact can be sent parallel or sequentially depending on the mode in which the BBUA processed the initial invite, which then resulted in the SIP 302 response Hold SIP implements a Hold as a re-invite with the connection information in the SDP configured to 0000 In this release, all the CS 1000 media gateways cannot handle hold The MCS 5100 shields the CS 1000 from receiving hold re-invite requests The MCS 5100, when equipped with a Border Control Point, can manage the connections without affecting the connection to the CS 1000 Retrieve Retrieve is also implemented in SIP through a re-invite To retrieve a party on hold, the new invite contains valid SDP The new SDP is used to restore the media connection between the two clients Long call audit timers To prevent hung calls between the two platforms, the platforms implement a long call audit timer between the two platforms Both platforms use the info ping capability described in the SIP info message RFC 2976 This involves sending an info message with no message body Upon receipt of this message, a client sends a response code 200 OK if the call exists The platform sending the message assumes that the call no longer exists and frees all resources associated with the call if it receives the following responses: 404 Not Found 408 Request Timeout 410 Gone 480 Temporarily Unavailable NN Standard Release February 2010

34 34 Overview 481 Transaction Does Not Exist If the platform sending the info receives a response code other than the ones listed, it treats the response as a valid audit response, and disconnects the call The CS 1000 sends a 200 OK response for an empty info message and a 481 response code if the call leg does not exist Supported media The following are the media supported by the interworking of MCS 5100 and the CS 1000: G 711 PCMU G 711 PCMA G 729 G3 fax Modem This list represents a full list of the media capabilities the MCS 5100 uses while interworking with the CS 1000 The actual list of supported media types depends on the capabilities of the gateways that the CS 1000 supports Note: G3 fax and Modem media calls are used only for CS 1000 gateway calls because there are no MCS 5100 endpoints that support either of these two media types Quality of service MCS 5100 implements its Quality of Service (QoS) through the Differentiated Service (DiffServ) feature The parameters of MCS 5100 QoS include the following: QoS DiffServ code for signaling specifies signaling quality for SIP clients QoS DiffServ code for audio specifies audio quality for SIP clients QoS DiffServ code for video specifies video quality for SIP clients QoS 8021p for service priority specifies service priority for SIP clients Equal Access workaround Equal Access is a group of features that allow a carrier operator to offer subscribers a choice of carriers every time they place a toll call Any telephony subscriber has the right to choose their provider for local, toll, and long-distance telephone calls Because these providers can be NN Standard Release February 2010

35 SIP-T-based communication servers 35 different companies, the Carrier Identification Codes (CIC) for their Primary inter-lata (Local Access and Transport Area) carrier (PIC) Call routing depends on the Carrier Access Code to specify the CIC and PIC These CAC codes take the form of the familiar 101-XXXX prefixes that are commonplace in the long distance provider market They allow subscribers to elect on a per call basis what provider will be given the opportunity to service (and therefore charge for) the currently dialed number Additionally, these codes are used internally within the telephony network for trunk selection in various toll call scenarios Subscribers do not dial a CAC code every time they place a long distance call if they have already informed their local telephone provider that they wish to have company XYZ as their default long distance provider In this case, the digits dialed can be automatically prefixed with the company XYZ CIC code and routed accordingly, as if the subscriber had dialed them as part of the dialed digits To perform an Equal Access call, the subscriber perform the following steps Identify the digits dialed as being an equal access call type Add the CAC for routing to dialed digits if CAC is not dialed Determine the correct trunking facility to carry the call Complete the call to the correct trunking facility The MCS 5100 currently cannot efficiently determine the Equal Access traffic type, or prefix digits through the existing translations engine and provisioning interface Because of this, a Communication Server 2000-Compact Superclass Softswitch (CS 2000) performs this function The interface between the CS 1000 and MCS 5100 can either be PRI or SIP-T (DPT) The breakdown of responsibilities between MCS 5100 and CS 1000 are MCS 5100 Identify from the digits dialed whether the call is a possible equal access call type CS 1000 Determine the equal access call type and add the correct PIC prefix to the dialed digits for the subscriber s primary inter-lata carrier CS 1000 Determine the correct trunking facility to the carrier identified by revised dialed digits CS 1000 Complete the call to the correct trunking facility The layout of this division of responsibilities is given in Figure 2 "Equal Access signaling diagram (PRI)" (page 36) and Figure 3 "Equal Access signaling diagram (SIP-T)" (page 37) NN Standard Release February 2010

36 36 Overview Figure 2 Equal Access signaling diagram (PRI) NN Standard Release February 2010

37 SIP-T-based communication servers 37 Figure 3 Equal Access signaling diagram (SIP-T) This document provides an overview of the provisioning required to configure the correct translations to enable support for Equal Access dialing The high level approach is The MCS 5100 translations determine that a toll call is being placed, and route the call to the CS 1000 On the CS 1000, if the call is deemed to be a toll call missing the CAC digits, it is routed over a loop-around ISUP intertoll (IT) trunk with the LATA Equal Access System (LEAS) default carrier configured for the MCS 5100 subscriber Otherwise it is simply routed out of the CS 1000 as a normal non-toll call If the CAC digits are present, then the call can be configured to go straight to the correct carrier trunk group for the CAC digits dialed Upon re-entering the CS 1000 over the loop-around trunk, the call hits LEAS translations This translates and routes the call to the Interexchange Carrier (IXC) of choice using existing LEAS functionality The IXC of choice for a particular user is configured in table DNPIC (inter-lata) or DNLPIC (intra-lata) NN Standard Release February 2010

38 38 Overview Converged Desktop interworking (traditional and IP Phones) The Converged Desktop service enables users to use a desktop telephone for voice calls and use a PC for the multimedia portion of communication The Converged Desktop user s desktop telephone is referred to as a Converged Phone Converged Desktop configurations There are various versions of the Converged Desktop service Those versions are SimRing Converged Desktop service (type 1) in which the Communication Server 1000 (CS) 1000 is configured for Simultaneous Ring (SimRing) and the MCS 5100 user is provisioned to use the Multimedia Client with Desktop Service supported over Primary Rate Interface (PRI) (DMS 100 switch) SimRing Converged Desktop service (type 2) in which the CS 1000 is configured for SimRing and the MCS 5100 user is provisioned as a standard user with Multimedia Client that is not using Converged Desktop service (regular Multimedia Client) This configuration is supported over PRI (DMS 100 switch) Personal Agent The Personal Agent-driven Converged Desktop service is used between MCS 5100 and systems that do not support SimRing, such as the Business Communications Manager (BCM) and third-party systems In this configuration, the inbound call is first directed to the MCS 5100, and the Personal Agent redirects the call to the user s telephone on the existing switching system This type of user uses the Personal Agent as the only way to access Converged Desktop services Session Initiation Protocol (SIP)-based Converged Desktop service between MCS 5100 and the CS 1000 This version is a MCS 40 offering The SIP-based Converged Desktop user can use the regular TDM telephone in addition to a PC running a Multimedia Client with the Converged Desktop service However, a Converged Desktop user cannot use a Multimedia Client for voice while in the converged mode The SIP-based Converged Desktop user can use the Multimedia Client, IP Phone 2002, IP Phone 2004, or IP Phone 2007 for VoIP calls For more detailed information about features available with each Converged Desktop Service (CDS) configuration, see MCS Feature Description Guide (NN ) Nortel switching systems supported The following table provides the switching systems that are supports Converged Desktop Services (CDS) and lists the minimum software version NN Standard Release February 2010

39 Converged Desktop interworking (traditional and IP Phones) 39 Table 6 Converged Desktop services supported Nortel Switching Systems Platform solution option SIP-based Converged Desktop SimRing Converged Desktop (type 1 and type 2) using PRI SimRing Converged Desktop (type 1 and type 2) MCS release MCS Release 30 and later Enterprise CS 1000 (Release 40 and later) (CS 1000 and CS 1000M) MCS 30 (type 2 only) Meridian 1, CS 1000M, CS 1000, SL100: Release 30 MCS 30 (type 2 only) Meridian 1, CS 1000M, and CS 1000 SIP-based Converged Desktop With SIP-based Converged Desktop service (SIP-based CDS), end users use their PCs for the multimedia portion of their communication, while using their existing telephony system for voice SIP-based CDS leaves voice traffic on the existing switching network while providing multimedia using the MCS A converged user stay in control of the calls, but still provide the voice services from their existing telephone When on a call with another MCS user (converged or non-converged), a converged user can use the SIP-based CDS Multimedia Client to add video to the call, to start collaboration sessions or to send Instant Messages with the party on the other end Outside the context of a call, the user can take advantage of Personal Agent enhanced routing as well as collaboration and instant messaging The SIP-based CDS user can gain a degree of mobility by either using an IP Phone 2002, IP Phone 2004, IP Phone 2007 or Web client to receive calls (with audio) at locations away from their desk (such as at meetings or at home) or by configuring their Preferred Audio Device to PC to use their Multimedia Client away from their desk A SIP-based CDS converged user s desktop consists of a regular TDM telephone, and a PC running the SIP-based CDS Multimedia Client as shown in NN Standard Release February 2010

40 40 Overview Figure 4 SIP-based CDS user network diagram The user s existing switching system connects to an MCS using SIP The SIP-based CDS service does not rely on the SimRing feature to blend calls; it relies on the call being sent to the MCS before ringing a converged user s telephone Converged calls always send signaling, and sometimes send media, to the MCS SIP-based CDS service configuration is shown in Figure 5 "Signaling and media path" (page 40) Figure 5 Signaling and media path NN Standard Release February 2010

41 Converged Desktop interworking (traditional and IP Phones) 41 To use the SIP-based CDS, the system administrator must provision changes to the existing switching system to permit insertion of an MCS into the call topology Interfaces supported The supported interfaces between the MCS and the existing switching system are SIP and PRI The following PRI variants are supported: Nortel DMS-100 Bellcore National 2 The PRI variants must support the PRI redirect parameter Key assumptions and limitations The following are some key assumptions and limitations for SIP-based CDS: The MCS system administrator enables converged user calls by provisioning the user as either a SimRing CDS user or a SIP-based CDS user (but not both) This assumption is needed so that the Multimedia Client and the Session Manager function differently for a SimRing CDS client (as opposed to a SIP-based CDS client) The existing Multimedia Client is the base of the Converged Desktop Multimedia Client The MCS system operator provisions a user as a SIP-based CDS User A converged desktop user, while in converged mode, can use any Multimedia Client for voice They can, however, use other SIP endpoints (such as the Multimedia Web Client, IP Phone 2002, IP Phone 2004 or IP Phone 2007 controlled by the IP Client Manager) for VoIP calls In addition, users can change their Preferred Audio Device (PAD) at the Converged Multimedia Client to be PC, to enable their Converged Multimedia Client to be used for voice A unique ALIAS must be configured for each SIP-based CDS user so that the ALIAS is the same as the Calling Line ID sent from the TDM switch to the MCS over the trunking interface (PRI, SIP, SIP-T) This is needed so that the terminating Converged Multimedia Client can contact the originator using the MCS The originator s Calling Line ID is also used to bring the SIP-based CDS Multimedia Client into a session when a converged user makes a call from a Converged Phone See Figure 6 "Numbers assigned in MCS and switching system" (page 42) NN Standard Release February 2010

42 42 Overview Figure 6 Numbers assigned in MCS and switching system If users can access their Personal Agent to configure enhanced routing, then their voice mail should be hosted the MCS This will cause all calls to be sent to the MCS for handling CD users can have voice mail provisioned off the CS 1000 where their PAD is hosted, but not both the switch and MCS simultaneously MWI is only provided to the PAD for a SIP-based CDS user on the MCS A Converged Phone is associated with a single Multimedia Client in this release A CD user cannot be registered in converged-mode in more than one converged PC If this happens, the other Multimedia Clients are logged off When PRI is used for transporting calls to the MCS, two PRI trunks are used for each call This affects normal PRI traffic usage and should be taken into consideration when engineering PRI resources North American PRI is supported, not European Telecommunications Standards Institute (ETSI) Only Automatic Number Identification (ANI) 01 for North America is supported Call duration for call logs are provided for Enterprise SIP-based CDS users NN Standard Release February 2010

43 Converged Desktop interworking (traditional and IP Phones) 43 Both CS 1000 and USP are considered to be trusted nodes; therefore, all message are accepted from these nodes For presence to work properly at the converged Multimedia Client, the CD user must be registered with their Multimedia Client SIP-based CDS Multimedia Client startup Clients are asked to register when a SIP-based CDS user logs in to the MCS after starting up a Multimedia Client Upon successful registration, the client retrieves the user s service package, which contains list of services (or capabilities) assigned to a user and the parameters associated with those services The client-side logic is activated in the Multimedia Client if the service package contains the following three things: SIP-based CDS service PAD parameter is configured as Converged Phone (not PC) Converged Phone Number contains a phone number When the SIP-based CDS logic is activated in the client, it transforms into a Converged Multimedia Client and takes on the appearance similar to Figure 7 "SIP-based CDS Multimedia Client main display" (page 44) NN Standard Release February 2010

44 44 Overview Figure 7 SIP-based CDS Multimedia Client main display At this point, calls that terminate to this user s Converged Phone provide call control and multimedia functions at the SIP-based CDS Multimedia Client, and provide voice at the Converged Phone Preferred Audio Device (PAD) selection The user selects the device type for their audio calls by configuring the Converged Desktop Mode, using the checkbox in the Multimedia Client User Preferences The user chooses between the following configurations: Converged Phone When this is selected, calls to the converged user ring the user s converged Phone and a non-answerable Multimedia Client call window on the user s PC The call window is available until the NN Standard Release February 2010

45 Converged Desktop interworking (traditional and IP Phones) 45 call is terminated The user cannot change which phone is converged because the administrator configures the telephone Multimedia PC When this is selected, the SIP-based CDS logic is deactivated in the converged user s Multimedia Client, transforming the Converged Client into a normal Multimedia Client Calls to the user ring the Multimedia Client (if registered) and the Converged Phone If the call is answered at the Multimedia Client, the telephone stops ringing A call window appears at the Multimedia Client (if registered), which behaves like a normal non-converged Multimedia Client When the call is answered, the voice is routed to the client and not the Converged Phone When the user changes modes, any active clients session windows close The audio call to the Converged Phone is unaffected, but all associated multimedia sessions are canceled The user receives a window, warning of the mode change Converged Alias to user mapping When a call is routed to the MCS for converging, the Converged User s called number (or user Converged Desktop Alias) is used in the SIP messages that are sent The switch that routes the call uses a single domain even if multiple domains are supported on the MCS As a result, the MCS must identify the subscriber and the subscriber s domain by strictly by the subscriber s DN A public DN-based alias field, called the Converged Desktop Alias, enables one or more special public aliases to be assigned to a user These aliases must be dialable numbers that contain the digits 0 to 9 only These aliases behave similarly to a normal alias The difference between these aliases and normal aliases is that provisioning rules for this field ensure that the public aliases assigned to users are unique across all domains instead of within a domain like a normal alias Interface Node to SIP signaling gateway Carrier Personal Agent offers the current MCS Personal Agent functionality across all AIN01 switches, including Nortel products and our competitors (for example, Lucent, Alcatel) products This functionality is also not limited to wireline products The Interface Node (IN) to SIP signal Gateway provides an interface between the PSTN and the MCS network components The Signaling Gateway uses the Advanced Intelligent Network (AIN) signaling from a Class 5 Switch and maps it to SIP protocol The Nortel Universal Signaling Point (USP), also known as the Signaling Control Point (SCP), is used as the IN to SIP signaling Gateway Each telephone number provisioned on the Class 5 Switch that has AIN triggers provisioned against it has a corresponding provisioning on the MCS The AIN triggers send information to the MCS NN Standard Release February 2010

46 46 Overview Figure 8 MCS architecture with SCP indicating when the party made or released a call, which the MCS can use to log the calls and update originating party s presence Similarly, if a Class 5 Switch receives a call for a party with AIN triggers provisioned, the IN to SIP Gateway sends information to the MCS when a call was received so that the MCS system can apply its routing logic to forward the call, log the calling party, and update the terminating party s presence information All endpoints provisioned with the Personal Agent against a switched provisioned party have a set of IN triggers associated with call terminations After the trigger fires, a message is sent to a special purpose Signaling Control Point (SCP) This SCP acts as a gateway from IN to SIP The SCP converts the IN message into the appropriate SIP message and send it to the Instant Message (IM) The IM responds appropriately as suggested in the following call flows From the switch perspective, the SCP and MCS look like one endpoint and is best described as theinter-network Services Signaling Gateway (ISSG) Triggers required for PA Carrier IN The Personal Agent (PA) requires termination triggers at the user s switch to initiate the call towards the user s MCS-based PA A Termination Attempt Trigger (TAT) is armed against a user s DN The TAT arming is done NN Standard Release February 2010

47 Converged Desktop interworking (traditional and IP Phones) 47 according to normal switch procedure The TAT trigger is based on AIN 01 protocol The AIN 01 TAT is assigned against a user s DN to invoke the ISSG routing service Triggers Required for Converged Desktop The Converged Desktop solution requires TAT triggers for both originating and terminating call attempts This requirement is also based on AIN 01 protocol The following AIN triggers are used for notification to the MCS AIN 01 origination triggers Off-hook delay used for call logs and presence-on-the-phone states Termination Notification call logs and presence connected state AIN 01 termination triggers Termination Attempt Trigger used for call logs and presence-on-the-phone state Termination Notification call logs and presence connected state Single to multiple domain support Configure a CD or PA user to any one of multiple domains served by the MCS 5100 system The SCP only sees a CD or PA user as belonging to a single domain The Session Manager provides the intelligence to determine which domain the CD or PA user belongs to, and includes this information if needed in any responses it returns to the SCP The MCS 5100 ensures the call is routed to the proper DN or SIP endpoint The following figure shows a single domain to multiple domain mapping NN Standard Release February 2010

48 48 Overview Figure 9 Single domain to multiple domain mapping SimRing Converged Desktop service (SimRing CDS) A user s Converged Desktop consists of a regular TDM telephone or IP Phone, and a Multimedia Client"SimRing Converged Desktop service (SimRing CDS)" (page 48) shows how the SimRing CDS user interconnects with the MCS network to provide an enhanced communication experience, while the TDM or IP telephone works exactly as it does today NN Standard Release February 2010

49 Converged Desktop interworking (traditional and IP Phones) 49 Figure 10 SimRing Converged Desktop services network SimRing Converged Desktop services features SimRing CDS enhances the end user s communication experience in a variety of ways: Advanced Call Handling The user can use the MCS Personal Agent web pages to control the user s availability When this ability is provided to SimRing CDS users, features not easily accessible on existing TDM switching systems become viable For example, a user can activate MCS-based simultaneous ringing (using the Personal Agent web pages) so that when the user s desktop telephone is called, the user s cell phone also rings After one leg of the call is answered, the other leg stops ringing Inbound call log The user can see who called and when the call occurred Video calling line identification The user who can see who is calling The video is retrieved from the network-based address book accessible on the Converged Multimedia Client File transfer If both the originator and terminator support the MCS file transfer collaboration application, then files can be transferred back and NN Standard Release February 2010

50 50 Overview forth between the two users The Multimedia Client (both Converged and non-converged) is the only endpoint that supports this functionality Whiteboard sharing If both the originator and terminator support the MCS whiteboard collaboration application, then two users can set up a whiteboard session The Multimedia Client (both Converged and non-converged) is the only endpoint that supports this functionality Clipboard transfer If both the originator and terminator support the MCS clipboard transfer collaboration application, then the two users can transfer the Windows System Clipboard between them One user copies items such as PowerPoint slides or sections of Excel spreadsheets to the clipboard, and then sends them to the other party The other party then pastes the items The Multimedia Client (both Converged and non-converged) is the only endpoint that supports this functionality Web Co-browsing If both the originator and terminator have this functionality, then one user can automatically drive the other s web browser The Multimedia Client (both Converged and non-converged) is the only endpoint that supports this functionality The Web Client supports the reception of web pages, but cannot send web pages to a Converged Multimedia Client Instant Messaging (IM) The Converged Multimedia Client can send and receive messages from any client that supports the Nortel IM format All MCS clients support sending and receiving of instant messages to and from each other Presence state indications With the Converged Multimedia Client, the user can select a presence state in the MCS network With the Converged Multimedia Client, users can also see the presence states for the Friends defined in the user s network-based address book SimRing CDS configuration requirements PRI is used as the interface between the existing TDM switching system and the MCS The MCS supports the following PRI protocol variants: AT&T 4ESS(AT4) AT&T 5ESS (E10) AT&T TR Bellcore National 2 ETSI ETS Nortel DMS-100 (DMS) NIS A211-1 NN Standard Release February 2010

51 Third-party gateways 51 For SimRing CDS, successful interworking between the MCS and the TDM switch requires that the TDM switch activate the SimRing feature and assign a SimRing number to each user A user in the TDM switch that acquires this SimRing number can be a CDS user The SimRing feature must send SimRing calls to a routable and unique number for each CDS user The MCS system operator must provision a user as a CDS user A CDS user cannot use the Multimedia PC Client for voice The CDS user s TDM telephone or IP Phone is used for voice In addition, the CDS user can use other SIP endpoints, such as other Multimedia Clients, an IP Phone 2002, IP Phone 2004, or IP Phone 2007 controlled by the IP Client Manager (IPCM), for VoIP calls An MCS alias is configured for each user so that the alias is the same as the Calling Line ID (CLID) sent from the TDM switch to the MCS over PRI When a non-cds MCS user calls a CDS user, the call is sent through the gateway to the CDS user s TDM telephone or IP Phone and the non-cds user s public or private charge ID is used to identify them to the TDM switch as the calling party This charge ID is sent to the Converged Multimedia PC Client, on the SimRing leg of the call, and is used by the Converged Multimedia PC Client to contact the calling party s MCS 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 on the existing switching system of the CDS user before the call is routed to the MCS For example, the originator s existing switching system routes calls using the existing systems, as opposed to sending the call to the MCS All calls from the SIP PRI gateway are triggered by the SimRing feature on the existing switching system Third-party gateways The MCS can use SIP signaling over UDP transport only between the MCS network and a third-party SIP-enabled gateway The third-party gateway provides the necessary signaling interworking between the MCS network and the other network to which the gateway is connected For example, a line-based voice mail server requires that a Line Gateway be placed between the MCS network and the voice mail server This Line Gateway processes SIP messages to and from the MCS network and creates the corresponding line signaling to and from the line network Vegastream The Vegastream Vega-100 gateway is a SIP-to-PRI gateway that can support 23/30 B-channels (1 T1/E1) or 46/60 B-channels (2 T1/E1s) The MCS system interacts with the Vega-100 gateway using SIP MCS NN Standard Release February 2010

52 52 Overview interworking with the Vega-100 gateway covers the compatibility and interoperability of devices that are used on the IP network Figure 11 "Vega-100 gateway" (page 52) shows a network view of the MCS interconnection with the Vega-100 gateway Figure 11 Vega-100 gateway Mediatrix FXO and FXS gateways The Mediatrix 1204 (APAIII-4FXO) is a telecommunication device that provides an analog interface to a PBX or Central Office The Mediatrix 1104 (4 port FXS) is a telecommunication device that provides an analog interface to RJ11-based telephones or faxes Figure 12 "Mediatrix FXS and FXO gateways" (page 53) shows a network view of the MCS interconnection with the Mediatrix FXS and FXO gateways NN Standard Release February 2010

53 Voice mail servers 53 Figure 12 Mediatrix FXS and FXO gateways MCS interworking with the Mediatrix gateway covers the compatibility and interoperability of devices that are used on the IP network In addition the following features are intended for interoperability: Basic Calls Hold and retrieve Call Forward-Unconditional Call Forward-No Answer Call Forward-Busy Call Transfer (REFER Method) Call Waiting Caller ID Mid-call CODEC change (initiated by the remote party) The Mediatrix FXO Gateway is installed in an office space or in wiring closets, wherever existing wiring is terminated The Mediatrix 1204 is also supported to provide a small-scale PSTN interface for enterprise branch offices Voice mail servers The following sections describe how the MCS interworks with legacy voice mail systems through a combination of Channel Associated Signaling (CAS) and Station Message Desk Indicator (SMDI) NN Standard Release February 2010

54 54 Overview Legacy CAS-based voice mail servers The elements involved in the interoperability with the voice mail systems include the SIP CAS gateway, an itouch terminal server, the Session Manager, MCS clients, and the third-party voice mail system A unique trunk group is allocated from the SIP CAS gateway to the voice mail system An IP address for the terminal server is assigned The terminal server is connected to the voice mail system with a serial cable The terminal server bridges the signaling between the Voice Mail system using the SMDI link and the Session Manager The Session Manager server is provisioned for the terminal server The terminal server has a private IP address The Session Manager and the voice mail system preferably collocate at the same site In the database, end users are provisioned with their mailbox IDs The mailbox ID is the user s 10-digit DN alias, which is a routable number A universal Call Processing Language (CPL) script allows routing to the voice mail system Upon a message deposit through the RS232 link, the terminal server passes the SMDI information over the IP network back to the Session Manager The Session Manager then sends the clients the notification, which turns on the message waiting indicator (MWI) light Figure 13 "CAS-based voice mail server" (page 54) shows a network view of the MCS interconnection with a CAS-based third-party voice mail server Figure 13 CAS-based voice mail server NN Standard Release February 2010

55 Voice mail servers 55 CallPilot MCS integration is based on the MSL/DMS-100 version of CallPilot that supports a T1/CAS interface for the bearer channel, as well as an industry-standard SMDI interface for signaling The following feature differences exist between the Meridian 1 and CS 1000/DMS-100 versions of CallPilot: Password suppression on the telephone display Messaging commands on display telephones with soft keys Service Quality Summary and Details reports Minimum and maximum channel limits for media services Slower agent/channel transfers (2-3 seconds) on MSL/DMS100 CLID for ESN calls preceded by 001 in the message envelope Names (CPND) not provided in the desktop message envelope CallPilot IPE in-skin servers not supported In addition, CallPilot for Meridian SL-100/DMS-100 is only supported on rack-mounted servers; the CallPilot Tower is not supported In-Reach terminal server The In-Reach itouch terminal server provides remote access to the MCS system and also serves as the data interface to CallPilot for SMDI information One available port on the Terminal Server must map a Transmission Control Protocol (TCP) or Telnet port to the RS-232C serial connection for the CallPilot system SMDI interface AudioCodes T1/CAS-SIP Gateway The AudioCodes Mediant 2000 T1/CAS Gateway provides the bearer path for the speech connection between the MCS and CallPilot This gateway is available in single-span, dual-span and four-span configurations CallPilot and MCS communicate using in-band signaling for mailbox or auto-attendant navigation on the T1/CAS gateway CAUTION DNS is not supported in the Audiocodes Gateway when connected to the MCS The DNS server address must be configured as 0000 MCS to CallPilot 107 interworking Using Figure 14 "MCS 5100 to CallPilot 107 interworking" (page 56) as a basis for discussion, the following explanation highlights the call flow between MCS and CallPilot NN Standard Release February 2010

56 56 Overview Figure 14 MCS 5100 to CallPilot 107 interworking The tables shown in Figure 15 "CAS Gateway URI and Channel Mapping" (page 56) and Figure 16 "CallPilot Service DN Mapping" (page 56) depict how an enterprise might map information to the CAS gateway and CallPilot so that CallPilot can communicate with the next-generation IP environment of MCS Figure 15 CAS Gateway URI and Channel Mapping Figure 16 CallPilot Service DN Mapping Suppose that John Smith is a user on the CallPilot server His user ID is johnsmith@enterprisecom, and his voice mail number is 3100 The following is the sequence of events for a call that is forwarded to the CallPilot system: 1 Based on call rules, MCS forwards an incoming call to CallPilot using the format <voice mail number>@<domain> ( 3100@enterprisecom) NN Standard Release February 2010

57 Third-party voice mail servers 57 2 The T1 CAS gateway maps the SIP URI (3100@enterprisecom) to a channel group, seizes the channel, and returns the trunk and channel information to MCS (180 Ringing with Trunk/Channel: 2/1) 3 MCS sends a call history message (channel information, original number dialed) to the terminal server and forwards trunk information to CallPilot using the AudioCodes T1/CAS server 4 The terminal server passes an SMDI message to MCS and to CallPilot ([forwarding DN: 3100], [messagedesk: 2] trunk, [positionnum: 1] channel) 5 CallPilot uses the call history message and service groups to initiate service for the call Third-party voice mail servers There are three major types of third-party voice mail servers The following sections describe how the MCS can interwork with the following types of third-party voice mail servers: SIP-based voice mail servers Trunk-based voice mail servers Line-based voice mail servers SIP-based voice mail servers SIP-based voice mail servers are SIP-enabled and interwork directly with the MCS network SIP is used to configure connections between the client and the voice mail server The Border Control Point carries the media packets between the client and the voice mail server Figure 17 "SIP-based voice mail server" (page 58) shows how the MCS interconnects with a SIP-aware third-party voice mail server NN Standard Release February 2010

58 58 Overview Figure 17 SIP-based voice mail server For more information on how the Session Manager uses Media Gateway Control Protocol Plus (MGCP+), see Border Control Point Fundamentals (NN ) For more information about how the IP Client Manager uses Unified Network IP Stimulus (UNIStim) to control the IP Phone 2002, IP Phone 2004, or IP Phone 2007, see IP Client Manager Fundamentals (NN ) Trunk-based voice mail servers Trunk-based voice mail servers cannot communicate directly with the MCS network A SIP PRI Gateway is required for the MCS to interwork with a trunk-based voice mail server The SIP PRI Gateway also provides a media path from the IP network to the voice mail server on the PSTN A terminal server, using SMDI, sends data about the storage and retrieval of voice mail from the trunk-based voice mail server to the MCS network The MCS network does not send data back to the voice mail server over the SMDI link Figure 18 "Trunk-based voice mail server" (page 59) shows a network view of the MCS interconnection with a trunk-based third-party voice mail server NN Standard Release February 2010

59 Third-party voice mail servers 59 Figure 18 Trunk-based voice mail server Line-based voice mail servers Line-based voice mail servers cannot directly communicate with the MCS network A Line Gateway, also known as an analog station gateway, is required for the MCS to interwork with a line-based voice mail server Similar to interworking with trunk-based voice mail servers, an SMDI terminal server exchanges data between the MCS and the legacy voice mail server However, the SMDI links are used to both send and receive data about the storage and retrieval of voice mail from the line-based voice mail server to the MCS network Figure 19 "Line-based voice mail server" (page 60) shows a network view of the MCS interconnection with a line-based third-party voice mail server NN Standard Release February 2010

60 60 Overview Figure 19 Line-based voice mail server Voice mail server interoperability and Message Waiting Indicator To accomplish voice mail server interoperability and MWI notification, the Session Manager transmits the following information over a data link to a voice mail server: called number (terminating party s telephone number) calling number type of call forwarding (for example, due to a busy line or an unanswered call) Note: This functionality applies to lines only and the type of information changes accordingly This session manager interface uses pure IP solutions that use a SIP-enabled voice mail server In this case, SIP messages provide the context data for each call needed by the voice mail server to record a NN Standard Release February 2010

61 Third-party voice mail servers 61 voice mail message Thus, a SIP-enabled voice mail server accepts invite messages for calls routed to voice mail and sends notify messages for MWI information The software uses Real-Time Transport Protocol (RTP) to carry the voice media The Session Manager supports voice mail through two configurations: A pure IP, third-party, SIP-enabled voice mail server that uses RTP to establish the voice path from the user to the voice mail server while SIP provides the configuration and MWI information A legacy voice mail server that uses a SIP or PSTN gateway to establish the voice path from the user to the PSTN-based voice mail server The SMDI protocol provides the setup information The platform uses any voice mail server that supports the SMDI protocol The supported physical connections for MCS is the PRI-based connection In either of the preceding configurations, this feature considers three primary scenarios: MESSAGE DEPOSIT An incoming call for a user gets routed to voice mail because the called user is unavailable, busy, or has all calls forwarded to voice mail MESSAGE NOTIFICATION The voice mail server sends an MWI status update to the Session Manager for a particular user The Session Manager sends a message to the client to update the MWI display Note: Clients do not store the MWI state Only the Presence Module stores the state When a client registers with the proxy and has messages waiting, the system sends a notify message to the client MESSAGE RETRIEVAL A user calls the voice mail server for message retrieval The user is connected to the voice mail server and accesses the mailbox to retrieve messages When you provision the voice mail server, specify which Session Manager is the host For configuration details, see Session Manager (NN ) Only the Session Manager that is hosting a particular voice mail server attempts to establish an SMDI connection with that voice mail server This applies to lines and trunks only Note: SMDI is used in certain voice mail configurations to allow the voice mail server to send Message Waiting Indication information to the Session Manager When connected to a lines-based voice mail server, the Session Manager sends an SMDI message to the voice mail server when a call is being routed to voice mail for message deposit The SMDI information includes the mailbox into which the message is to be deposited The voice mail server periodically sends an SMDI heartbeat message to the Session Manager The Session Manager NN Standard Release February 2010

62 62 Overview must respond to this message to let the voice mail server know that the SMDI link is still active Third-party clients The Manitone ipdialog terminal was tested successfully with all of the MCS clients (PC, Web, PA, 200x, NN IAD) The ipdialog terminal negotiates to any p-time (10, 20, 30, 60, 120) for calls terminating to the ipdialog terminal The ipdialog terminal requires that the endpoint it connects to supports a packet time of 20 milliseconds (ms) The ipdialog terminal does not support auto-negotiation of the packet time when initiating a call It does not negotiate to any packet time other than 20 ms This will result in either no voice path or a garbled voice path between the two end terminals Lightweight Directory Access Protocol Lightweight Directory Access Protocol (LDAP) is a client-server access protocol that runs on top of TCP/IP It defines a communications protocol, such as transport and format of messages, that a client uses to access data in a directory Use LDAP, a simplified version of the Directory Access Protocol (DAP), to gain access to X500 directories (an ISO standard) LDAP is the usual method for accessing directory information The LDAP structure is based on a simple information tree metaphor called a directory information tree (DIT) An example of a DIT is shown in Figure 20 "Company ABC DIT" (page 62) Figure 20 Company ABC DIT A tree can contain multiple leaves and each leaf is an entry The top-level entry is the root entry and each entry contains a distinguished name along with any number of attributes/value pairs The DN must be unique for a given entry and is similar to a file system path in that it defines the DIT for that entry However, unlike file system paths that are read left to right, NN Standard Release February 2010

63 Enhanced distinguished names are read right to left For example, a distinguished names for a person with a USER ID of joeb in company ABC might look like this: dn: uid=joeb, ou=internal,ou=people,o=abc The left-most portion of the distinguished names is known as a relative distinguished name (RDN) and is made up of an attribute and value pair that must be unique for each entry In the proceeding example, that would be uid=joeb The items uid, ou, and o are known as attributes Attributes define how data is represented in a DIT Figure 20 "Company ABC DIT" (page 62) illustrates of how many different types of information can be stored in an LDAP database This is the reason LDAP databases are prevalent in many organizations to store data In Figure 20 "Company ABC DIT" (page 62), the following attributes exist: o (organization) The organization attribute represents the name of an organization, and in Figure 20 "Company ABC DIT" (page 62) represents company ABC ou (organizational unit) The organizational unit attribute represents the name of an organizational unit, and in Figure 20 "Company ABC DIT" (page 62) the LDAP directory for company ABC contains entries for People and Devices The People tree is further differentiated by additional organizational units for External and Internal employees, while the Devices tree is further differentiated by an additional organizational unit of PCs (perhaps the administrator anticipates adding more devices in the future) uid (userid) The userid attribute represents an employee s user ID in Figure 20 "Company ABC DIT" (page 62) MCS provides a means for propagating additions and modifications from a customer s LDAP directory to the MCS system, including: Creating new users on the MCS system after new records are added to an LDAP version 3 directory Modifying information for existing users defined on an MCS system after these changes are made to an LDAP version 3 directory Providing the ability for the administrator to automatically schedule synchronization of the MCS system with the LDAP version 3 directory Enhanced 911 Enhanced emergency services, known as Enhanced 911 (E911), differ from basic emergency services in two main ways First, the emergency call is routed to the local public safety answering point (PSAP) serving the caller area based on the calling phone location, and the PSAP has access to the calling party address The PSAP also has access to a callback number (referred to as the Automatic Number Identification [ANI]), which the PSAP NN Standard Release February 2010

64 64 Overview can use to call back the emergency caller The PSAP can use this callback number if they need additional information after ending the emergency call, or to reestablish the emergency call if it is cut off for some reason The ability to locate the 911 caller within the enterprise facility must be provided, although this requirement varies in different jurisdictions On-site notification (OSN) functionality can be used to address the requirement in some jurisdictions to be able to locate the 911 caller within the facility OSN functionality indicates to a security guard, administrator or other front-door personnel that someone within the building made an emergency call This person can then direct police, ambulance or other emergency workers to the proper location within the building for faster response The OSN instant message address must be monitored 24 hours a day, seven days a week for OSN to be effective in speeding emergency response times Each PSAP has access to an Automatic Location Identification (ALI) database, which contains information on physical address and callback number This database is updated as soon as possible for new entries, while existing records are typically updated once every 24 hours The National Emergency Number Association (NENA) specifies the format for ALI database records ALI database entries should be approved by the Master Street Address Guide (MSAG) To meet the fundamental requirements for E911 calling functions, the system must have information about the geography being served This geography is imparted through the introduction of the concept of location into the system The Location Infrastructure can be used for location-based information The Location Infrastructure enables the provisioning of a virtual topology that describes the geography of the system, and hence the proximity and distribution of system components The Location Infrastructure provides a means of provisioning a Location Hierarchy on a domain basis This enables the definition of a virtual geographic representation of the area serviced by an associated domain The component locations that constitute this hierarchy can be used by any service that can benefit from a knowledge of geography, proximity, or distribution Locations associated with local PSAPs are referred to as Emergency Response Locations (ERL) An ERL represents a physical address, a building floor (for multistory buildings), floor partition (for floors greater than square feet) and room number (optional) For more information, see Enhanced 911 Fundamentals (NN ) NN Standard Release February 2010

65 65 Upgrades This chapter provides information about upgrade procedures dealing with MCS 5100 interworking with the following systems: "PRI-enabled switches" (page 65) "SIP-T-based communication servers" (page 65) "Converged Desktop phones (traditional and IP Phones)" (page 65) "Third-party gateways" (page 66) "Third-party voice mail servers" (page 66) PRI-enabled switches MCS 5100 interworking with PRI-enabled switches does not involve additional software deployment to the PRI-enabled switches SIP-T-based communication servers MCS 5100 interworking with the Communication Server 1000 does not involve additional software deployment The functionality exists in the Session Manager For more information about upgrades, see Session Manager Fundamentals (NN ), MCS Upgrades Release 3x to Release 40 (NN ) and MCS Upgrades Maintenance Releases (NN ) ATTENTION Because the MCS 5100 and CS 1000 can be upgraded at different times, the two products are backward compatible by one release Converged Desktop phones (traditional and IP Phones) MCS 5100 interworking with traditional telephones (Converged Desktop) does not involve additional software deployment to the existing switching system However, the SimRing feature on the TDM switch must be activated to route calls to CDS users NN Standard Release February 2010

66 66 Upgrades You cannot upgrade the MCS 5100 network and clients at the same time As new client functionality is introduced in the network through MCS 5100 network node upgrades, the existing clients must continue to interwork with the network Therefore, the MCS 5100 network nodes must be backward compatible with older clients and MCS 5100 nodes In addition, clients (both Converged and non-converged) must be backward compatible with all previously released clients, as different versions of the clients can coexist in a given MCS 5100 network Compatibility is maintained by version identifiers included in an MCS 5100 user s service package information When new CDS functionality becomes available in the MCS 5100 network, older Converged Multimedia PC Clients can continue to exist and operate in the upgraded MCS 5100 network; however, they will not be able to access the new Converged Multimedia PC Client services Note: In general, MCS 5100 network is upgraded before the Multimedia PC Client is upgraded Third-party gateways MCS 5100 interworking with SIP-enabled third-party gateways does not involve additional software deployment to the third-party gateways The Session Manager uses SIP to communicate with a third-party gateway that also uses SIP Each third-party gateway software release must be validated and certified against the current MCS release The Session Manager and third-party gateways can be upgraded independently from one another For more information about upgrades to the Session Manager, see Session Manager Fundamentals (NN ), MCS Upgrades Release 3x to Release 40 (NN ) and MCS Upgrades Maintenance Releases (NN ) Third-party voice mail servers MCS 5100 interworking with third-party voice mail servers does not involve additional software deployment to the third-party voice mail servers The Session Manager uses SIP to successfully communicate with third-party voice mail servers For non-sip-aware voice mail servers, use a gateway between the MCS 5100 network and the legacy voice mail server, in which case the Session Manager still relies on SIP to successfully communicate with that gateway For example, the Trunking Gateway connects the MCS 5100 network to a PRI trunk-based voice mail server For information about the upgrade procedures of a specific third-party vendor s voice mail server, see the documentation provided by the third-party vendor NN Standard Release February 2010

67 67 Configuration management This chapter provides information about the tasks required to configure the MCS 5100 to allow interworking with other systems, using "Guidelines for configuring SIP-based Converged Desktop" (page 67) "Configuring IN to SIP Signaling gateway" (page 89) "Configuring voice mail servers" (page 90) "Configuring LDAP" (page 91) "Add and configure the Media Gateway" (page 104) Unless stated otherwise, all tasks are described from the MCS Provisioning Client perspective For more information about provisioning tasks required to configure the MCS, see Provisioning Client User Guide (NN ) Guidelines for configuring SIP-based Converged Desktop This section provides basic guidelines on provisioning the MCS for Session Initiation Protocol (SIP)-based Converged Desktop (CD) usage and requirements on the Switch to interface with the MCS The guidelines do not provide details on how to provision the Automatic Number Identification (ANI) and Switch Rather, the guidelines provide details on what to provision on these components For detailed information about the Universal Signalling Platform (USP), refer to the USP 813 Release Notes The basic configuration in which you deploy the Converged Desktop should have following system components: 1 MCS system Converged Desktop Service (CDS) runs from here, and other IP clients are provisioned The MCS clients work with the Class 5 telephone sets to provide multimedia services The audio interface into the MCS with the Class 5 telephone sets is either using a Public Switched Telephone Network (PSTN) gateway or the Class 5 switch providing an IP link Communication Server (CS) 1000 version 40 or higher is supported NN Standard Release February 2010

68 68 Configuration management 2 Class 5 switch The telephone for a CD user is connected here, and the audio part of a CD user is provided The Class 5 switch provides an Advanced Intelligent Network (AIN) signaling interface with a SIP-enabled Signaling Control Point (SCP) and provides the audio path to the MCS using IP trunk or an interface with the MCS using a PSTN gateway You provision the AIN triggers at the Class 5 switch against the telephone numbers that require CD service with the MCS 3 AIN network AIN is the signaling interface between the MCS and the Class 5 switch Use the USP as an SCP The USP provides the mapping between the AIN and SIP interface that is used to drive various CD services The USP supports only AIN 01 for CD service in this release For detailed information about the USP, see the USP 813 Release Notes A basic interface overview of the MCS with CD service appears in Figure 21 "Carrier configuration" (page 68) The figure shows that generally the audio path is established between the phones using the Class 5 switch The multimedia services, such as video and collaboration, are established in the MCS IP environment This is not always the case, as described in the following sections of the document, based on the various services invoked by the CD feature Figure 21 Carrier configuration The list of services available to a CDp user in the environment previously described is in Table 7 "Services for Converged Desktop users" (page 69) NN Standard Release February 2010

69 Guidelines for configuring SIP-based Converged Desktop 69 Table 7 Services for Converged Desktop users Service Inbound/Outbound Client and Network call logs Picture Calling Line ID File transfer, white board sharing, point to point application sharing, clip board transfer and Web Co-browsing Instant Message (IM) and Presence Auto Presence Point to Point Video Click to Call Single Converged Telephone (Not changeable) Advanced Screening and routing Unconverged mode Description Ability to log incoming and outgoing calls at the Client and the Web server Client logs are only available when the client is logged with the MCS Send and receive picture ID saved through the Personal Agent These are noncall associated services that are launched from within a call window or independently IM is a noncall associated service, but is also used from the call dialog window The presence service provides the subscriber with the ability to configure presence state manually Provides automatic presence of a subscriber based on the call state Point to point Video capability is permitted after an audio leg is configured Only On Demand video is supported for Converged Desktop users regardless of Multimedia Client initiating video immediately Ability to click in a call log, address book, or Outlook plug-in and place a call The administrator allows and provisions a single Converged Telephone Ability to screen calls based on the calling number and time of day, ability to route calls sequentially or simultaneously based on the calling number and time of day Ability for the user to unconverge the Multimedia Client from the telephone to receive or make calls using the IP environment NN Standard Release February 2010

70 70 Configuration management Service Access to IP clients Description Ability for the CD user to login and use other MCS IP clients A CD user making a call using Click to call does not have access to branding announcements (specific audio marketing messages for companies and product names) because CS 1000 call transfer does not support the Branding service A branding announcement initiates before a call routes to the called number When a CD user makes a call using Click to call, the CS 1000 transfer performs behind the scenes In this case, a call between the CS 1000 and the web is already established Consequently, when you use the existing CS 1000 leg for a series of holds and retrieves to transfer the call from the CD user to the called number, the Branding service is not initiated Some of the previously described services require the same provisioning as a regular MCS user that does not have Converged Desktop service in the MCS service package The following table lists the services that are used in conjunction with the Converged Desktop Table 8 Services Service Inbound/Outbound Client and Network Call logs Auto Presence Point to Point Video Click to Call Single Converged Telephone (Not changeable) Advanced Screening and routing Unconverged mode Description The network logs do not provide call duration in certain call scenarios Provides automatic presence of a subscriber based on the call state Video is started during the ringing state of the call during certain call scenarios Requires that PSTN translations are correctly configured to make calls, for example, from the converged Client, or call logs How to reach the Converged telephone without having translations loops How simplex and complex calls work Need to understand the differences in how calls work when a subscriber is unconverged This document and the MCS provisioning system use the following terms NN Standard Release February 2010

71 Guidelines for configuring SIP-based Converged Desktop 71 Table 9 Terms Term Converged Client Converged Phone Converged Mode Un-Converged Mode Converged DN Converged Alias Simplex Call Complex Call Service DN Description Multimedia Client where a subscriber with Converged Desktop is logged on and uses the Multimedia client for multimedia services Telephone that a Converged Desktop subscriber uses for audio services A subscriber s Multimedia client is converged with the telephone, audio and multimedia services are split across the telephone and PC A subscriber s Multimedia Client is used for full multimedia services including audio services In this mode, the telephone can still ring and answering the telephone cancels the call to the Multimedia client Similarly, answering the Multimedia Client cancels the call to the Converged Phone Telephone number assigned at the MCS for outbound calls to the Converged Phone from the MCS system This is normally the same as the Converged DN but is for incoming requests or calls to the MCS to reach a Converged Desktop user The Converged Alias has to be unique across the entire MCS system Use this term when a terminating call only requires a single dip into the MCS A Simplex call normally results when the subscriber has no Advanced Screening rules and routes defined Use this term when the terminating call requires multiple dips into the MCS to reach the terminator This normally occurs when Advanced routing is enabled and the MCS must handle the redirection on media Use a Service DN only for the Carrier Converged Desktop server Provisioning data gathering Before provisioning the MCS system for Converged Desktop usage, the following table provides a list of items to collect and determine before provisioning can begin on the MCS NN Standard Release February 2010

72 72 Configuration management Table 10 Provisioning information Provisioning item Description Decision needed MCS User ID User domains User subdomain Outgoing Local dialing patterns Outgoing Public dialing patterns A set of subscribers A user ID in the form of Greg@mydomaincom is needed to provision all subscriber specific data A domain provides a grouping of subscriber-to-telephone MCS services A subscriber within a domain calls other subscribers within the same domain using the MCS user ID without the inclusion of the domain part A domain can be divided into multiple subdomains to divide the dialing plans into user groups (for example, richmydomaincom) For example, if two groups of subscribers require use of the same five-digit translations, but both groups being to the same higher domain (for example, mydomain) Dialing plan that a subscriber can dial to reach other clients within MCS and other subscribers that are part of the same enterprise, but not MCS subscribers For example, MCS and the PBX users can belong to the same CDP group using a four- or five-digit dialing plan to reach other Determining this dial plan is important because of Click to call capability available to the CD user Dialing plan to reach subscribers not part of the CDP group from the MCS (for example, during Click to Call and when Unconverged) These can include what prefixes are used to dial long distance numbers and international calls Whether to use alpha characters for user IDs or DN Will the MCS system support a single domain or multiple domains Are multiple subdomains needed, or will a single domain work Determine what digits the user can dial out to reach other users and what dialed digits are accepted into the MCS to find the subscriber Determine if all subscribers are assigned these restrictions using Class Of Service (COS) parameter on the MCS Determine how many COS you must create NN Standard Release February 2010

73 Guidelines for configuring SIP-based Converged Desktop 73 Provisioning item Description Decision needed DN assigned to Converged Telephone Incoming Local dialing patterns Incoming Public dialing patterns N+M Session Manager Carrier Gateway IPs Configuring IN to SIP Signaling gateway Directory Number (DN) assigned to the converged telephone allows various screen to display and redirects services at the MCS All DNs must be unique Incoming calls from other MCS clients and other subscriber that are part of the same enterprise group, but not MCS subscribers (for example, four- to five-digit dialing Similar to the local dialing, but when long distance or international calls are received If multiple Session Managers are involved for redundancy and capacity requirements, then a decision is need on how subscribers are populated across the Session Managers The IP addresses of the Carrier Gateway that sends the Invites to MCS on behalf of CD users must be provisioned on the MCS as known gateways This is primarily used to process originating screen pop-up windows for CD users If not provisioned as a known gateway IP address, then there will be no originating screen pop-up windows Examples are the gateway the Service DN Invite is from, VRDN and similar equipment None just need to get the list to provision the Converged aliases Determine if abbreviated dialing is used and what digits are received to provision the MCS to look up the CD user Determine what digits are received at the MCS for incoming calls from other PSTN users How many Session Managers? How are CD subscribes populated across the Session Managers because of capacity, redundancy, and firewall requirements? None Just need the list of IP addresses of the Carrier Gateways interfacing with the MCS for CD users Figure 22 "General data gathering" (page 74) shows what data is generally required and from at what component NN Standard Release February 2010

74 74 Configuration management Figure 22 General data gathering Provisioning guidelines This section discusses "Network configuration" (page 74) "IP Network configuration" (page 78) Network configuration This section describes two network configurations for Converged Desktop service In the first configuration, the MCS has a 1+1 Session Manager (Proxy) where call requests from the USP go to a single Session Manager (Proxy) and the other is a spare server The second scenario shows 2+1 Session Manager configuration in which two servers provide Converged Desktop service and one acts as the sparefigure 23 "MCS configurations with USP" (page 75) shows two possible configurations of the USP with the MCS system NN Standard Release February 2010

75 Guidelines for configuring SIP-based Converged Desktop 75 Figure 23 MCS configurations with USP Other configurations are possible using the N+M model, which is an extension of the 2+1 configuration shown in the figure The USP can support multiple IP addresses to point to different Proxy addresses The PRI Gateway can only point to a single MCS proxy You must consider this when you are engineering the system, as subscribers can exist on different proxies to which the PRI or USP are sending requests and introducing more messaging in the system The USP uses IP paths to connect to the MCS system from the IP link cards An overview of USP routing appears in the following section For more information about the USP, see the USP 813 Release Notes USP routing A USP has two main interfaces one connects to the TDM switching network to provide the AIN interface, and the other connects to the MCS system over IP network The AIN side uses Signaling System 7 (SS7) links connected to the SS7 link cards to send AIN triggers and responses The AIN messages are converted into SIP messages and are sent over to the MCS using the IP link cards NN Standard Release February 2010

76 76 Configuration management In a normal configuration, you can configure two SS7 Link and two IP Link cards to provide hardware and signaling path redundancy for the Converged Desktop service Figure 24 Normal configuration The USP uses the term Application Server (AS) to associate a number of IP paths Each Application Server can be associated to an MCS Session Manager Each Application Server contains a list of paths, and a path is a floating IP address of the MCS Session Manager USP paths and application servers: Each USP application server can have multiple paths from the IP link card (up to 32) The USP performs AIN Global Title Translations (GTT) functions on the SS7 link for an incoming AIN request, and routes the request to a particular Application Server USP does this creating a dummy SS7 point code (a real SS7 point code that is never used for a route) for the AS in the Answer Signal Delay (ASD) routing screen A remote SCCP subsystem and route is created for the AS dummy point code GTT results are then created for the AS remote subsystem for the number ranges used for the CD service Point Code/Subsystem routing is also supported if GTT is performed before the message reaches the USP The AS selected is based on lowest cost in-service destination for load balance the IP link cards The SS7 link uses a round robin algorithm between all in-service paths in the selected Application Server Figure 25 "1+1 configuration" (page 77) shows the provisioning of an Application Server and IP Paths from the USP NN Standard Release February 2010

77 Guidelines for configuring SIP-based Converged Desktop 77 Figure configuration In the 1+1 configuration, One AS is defined on the USP to correspond with one MCS Session Manager A second Session Manage acts a standby spare One path is defined for each link card from the USP to the MCS proxy floating (logical) IP address Traffic is balanced between the link cards Figure 26 "2+1 configuration" (page 77) shows a 2+1 configuration using two MCS proxies Each proxy has a different floating IP address One proxy acts as a standby spare Figure configuration In the 2+1 configuration, Two ASs are defined on the USP for the two floating IP addresses One path is defined for each link card per AS from the USP to the MCS proxy floating IP addresses NN Standard Release February 2010

78 78 Configuration management Traffic is balanced between the link cards for each Application server, giving IP link card redundancy and traffic distribution across cards In the 2+1 or N+M configuration it is possible that the terminating subscriber exists on a different proxy, so a redirect response from the MCS (301 SIP message) is sent back to the USP to connect to a different proxy Figure 27 "2+1 Redirect" (page 78) shows this scenario Figure Redirect In the 2+1 Redirect configuration, The incoming request from the Switch routes to the AS1 Path-1 to terminate to Proxy-1 Proxy-1 determines that the user is homed on Proxy-2 and responds with a 301 message with Proxy-2 IP address IP Link 1 routes the request to Proxy-2 using AS2 Path-2 IP Network configuration You must provision the IP address of the IP Link Cards as the Trusted Node on all the MCS proxies As a Trusted Node, the MCS does not authenticate USP requests, which is different from the way MCS Clients are handled When MCS Clients want to make call, the system prompts the user for a password USP requests do not require passwords MCS subscriber provisioning New subscribers are created with CD service and existing MCS users can be assigned the CD services This section describes creating a new CD user and CD service package requirements For these examples, it is assumed that subscribers for the Converged Desktop service belong to the mcs5100com domain Provision a domain as any other domain used for MCS subscribers as shown in Figure 28 "Top level domain menu" (page 79) NN Standard Release February 2010

79 Guidelines for configuring SIP-based Converged Desktop 79 Figure 28 Top level domain menu Before you can add CD subscribers to the domain, you must create and assign a service package to the domain The system administrator must create a list of services that can be assigned to a particular domain Make sure the Converged Desktop is one of the services selected Remember that these services are not really assigned, but are a list of services that the domain administrator can use to create service packages to assign to subscribers The assumption in this guideline is that all services are assigned to the mcs5100com domain Selecting services The list of services that a Converged Desktop subscriber can use are listed in the following table Table 11 Services available to Converged Desktop subscribers MCS service Ad Hoc Audio Conferencing Interaction with Converged Desktop service Not applicable Subscribers cannot invoke MCS Conferencing, but they can include the CD call into an MCS conference call when they are converged NN Standard Release February 2010

80 80 Configuration management MCS service Advance Address book Advanced Screening Assistant Console Assistant Support Call Park Calling Line ID Restriction Converged Desktop Device Acces s Restrictions IM Chatroom Meet Me Audio Conf erencing Music On Hold Network Call Logs Presence QoS Unified Communicati on Interaction with Converged Desktop service Applicable The Converged client uses this to save other subscribers calling information Subscribers can use the address book to originate calls Applicable This provides the advanced routing and screening capabilities from the MCS Personal Agent Assigning this service to the subscriber gives the subscriber complex call capabilities Not applicable CD users do not use this Not applicable not used by CD users Not applicable CD users cannot park or retrieve calls while converged, but the call from a CD user can be parked Partially applicable This service is applied when using the Click to Call in the Converged Mode or using another MCS client to originate calls from the MCS system If Calling line restriction is required from a regular telephone, then this service must be provisioned on the TDM switch providing the service to the phone Applicable Configured to the IP Phone 200, IP Phone 2004 and IP Phone 2007 for CD service Partially applicable CD users do not use this unless the CD user is going to use an IP Phone 2002, IP Phone 2004 or IP Phone 2007 This service restricts services to the IP Phone 200x based on the user s service package Applicable can be assigned to a CD user to access conferencing bridge and MCS chat room Applicable can be assigned to a CD user to access the conferencing bridge Only applicable in the complex call scenarios where the call traverses the MCS system Applicable logs all calls either in the simplex and complex call scenarios Applicable presence of a CD user is based on the CD Client registration If the CD Client is not registered, CD user presence is not updated Not applicable not applicable unless the CD user is Unconverged or logged on to another MCS client Not supported in MCS 5100 NN Standard Release February 2010

81 Guidelines for configuring SIP-based Converged Desktop 81 MCS service Video Voice Mail Interaction with Converged Desktop service Applicable permits the CD user to perform point to point video with another MCS subscriber Applicable TDM based voice mail, if assigned to the CD user, makes all terminating calls Complex When this service is assigned to the subscribe, it gives the subscriber complex call capabilities Nortel recommends that the MCS system administrator define a Service Package with the selected services specifically for the Converged Desktop users in a domain Creating Converged Desktop users The steps to provision new MCS subscribers for the Converged Desktop service are similar to provisioning a subscriber for non-converged services A Converged Desktop menu requires input for the service to function and this menu also provisions existing MCS subscribers that want to use the Converged Desktop service In this example, the MCS domain and service package already exist The system administrator creates or modifies existing users for the CD service, as shown in Figure 29 "Sample CD user" (page 81) Figure 29 Sample CD user NN Standard Release February 2010

82 82 Configuration management After you add a user to the MCS system, click on the Converged Desktop properties to provision the subscriber s telephone DN and the incoming DN that the system uses to find this subscriber in the MCS system as shown in Figure 30 "Converged Desktop properties" (page 82) Figure 30 Converged Desktop properties Procedure 1 Creating a CD user Step Action At the provisioning client 1 Open the User Details for an existing user 2 Click Converged Desktop properties 3 Enter an alias in the Converged Desktop Alias dialog box NN Standard Release February 2010

83 Guidelines for configuring SIP-based Converged Desktop 83 Use this alias in both originating and terminating call scenarios The Converged Desktop alias must be unique across the MCS system regardless of what domain is assigned to the CD user Since this number must be unique across the MCS system, define this alias with the following components: the user s extension as a four digit number For example: extension = 3224 the three digit HLOC codes for user groups (that is, customers) For example: HLOC = 351 The HLOC and user s extension create the user s UDP number The number is unique within an enterprise: HLOC + Extension For example: UDP Number = the Private Network Identifier (PNI) for user groups (that is, customers) For example: PNI = PNI, HLOC, and the user s extension create the Global user ID that is globally unique: PNI + HLOC + Extension For example: Global ID: Enter a DN in the Private Preferred Audio Device dialog box This DN is the PSTN routable digit string that routes the call to the user s preferred audio device For example, enter a user s desktop phone number For conditions applying to this field, see Table 12 "Converged Desktop properties" (page 84) 5 Select Carrier Converged User from the Converged Desktop User Type menu 6 Select the Click to Dial Enabled check box 7 Click Save You can assign additional aliases to the CD subscriber if you cannot find the CD subscriber using telephony translations, as long the alias is not the same as the Converged Desktop Alias You can use these additional aliases for private dial plans (CDP), for example, to reach other users using four- or five-digit dial plans End The following table describes Converged Desktop properties NN Standard Release February 2010

84 84 Configuration management Table 12 Converged Desktop properties Converged Desktop properties Converged Desktop Alias Private and Public Preferred Audio Devices Description This alias is used to find the subscriber when requests are received from the USP or PSTN/SIP Gateway in the complex call scenarios This alias is used in both originating and terminating call scenarios This alias is also used to populate the Original Called Number field when a call is sent to the CD subscriber s telephone to avoid a loop back into the MCS from the USP The system administrator must make sure that when the IN trigger terminates to the USP in any call attempts from the MCS, the called number and original called number (this alias) match Otherwise, the call will loop back into the MCS The Converged Desktop Alias must be unique across the complex MCS system regardless of what domain is assigned to the CD user Because this number must be unique across the MCS system, Nortel recommends that this alias be a 10-digit number unique to the subscriber Private and Public Preferred Audio Devices are normally provisioned with the same DN The DN provisioned is the PSTN routable digit string used to route the call to the user s PAD However, if these routable digits are different for Private and Public PAD, then specific rules apply on the selection of the Private or Public PAD Private PAD number is selected when: the originator and terminator are in the same root domain An originator can be another Multimedia Client or a Converged Desktop 2 user the originator and terminator are in different domains, but the public name or number for the originator is not provisioned the Public PAD number is not provisioned Public PAD number is selected when: the originator and terminator are in different domains, and the originator has a public name or number provisioned the incoming subscriber is not known at the MCS the Private PAD number is not provisioned NN Standard Release February 2010

85 Guidelines for configuring SIP-based Converged Desktop 85 Converged Desktop properties Converged Desktop User Type Click to Dial Enabled Description The user must be a Carrier Converged User Enables the AIN Make Call on the CS 1000 to initiate a call When a CD user selects this check box, the user can originate calls by using Click to Call with their Converged Desktop client Remember that the Click to Dial Enabled feature is only available if the adjacent CS 1000 supports AIN and the CD Preferred Audio Device resides on the CS 1000 You can assign additional Aliases to the CD subscriber if you cannot find the CD subscriber using telephony translations, as long the alias is not the same as the Converged Desktop Alias You can use these additional aliases for private dial plans (CDP) For example, you can use these aliases to reach other users using four- or five-digit dial plans Provisioning Service DN You must provision the service DN for each domain in the MCS to route a call back to the MCS for complex call treatment Figure 31 "Service DN menu" (page 85) shows an example of provisioning the Service DN for a domain Figure 31 Service DN menu NN Standard Release February 2010

86 86 Configuration management The Service DN is provisioned for each domain and must be unique across the MCS system The Service DN must be a 10-digit number because of the AIN 01 interface The AIN 01 limits the Forward Call Response telephone number to 10-digit numbers only Procedure 2 Adding Converged Desktop service data Step Action At the provisioning client 1 Click Domains > <domain> > Converged Desktop > Assign Converged Desktop Data 2 Enter a routable DN in the Service DN dialog box 3 Select National from the Number Qualifier menu 4 Click Save End Telephony translations Telephony translations uses the terminating subscriber or a Gateway route to route the call to another system Telephony translations are not used to find the originator of the call; the Converged Desktop Alias or Alias finds the originating subscriber To begin adding translations, a Converged Desktop subscriber must provision a Converged Desktop Preferred Device Number and a Converged Desktop Alias In a simple provisioning example, the following two users subscribe to the CD service with the following Aliases and PAD DNs: Subscriber 1: Greg with Alias = and PAD DN Subscriber 2: Dave with Alias = and PAD DN Simplex call Simplex call uses the Alias or Converged Desktop Alias to find the subscriber The terminator is found using an Alias, Converged Desktop Alias, or private telephony translations that normalize to an alias For example, if Greg calls Dave and the TDM switch delivers as the calling number and as the called number The global aliases used in this example find both the originator and terminator of the call Complex call Complex call uses three DNs to determine the originator, terminator and route to the MCS through the Gateway NN Standard Release February 2010

87 Guidelines for configuring SIP-based Converged Desktop 87 For example, Greg calls Dave, and Dave has provisioned advanced screening rules to ring his desktop telephone and his mobile phone When the USP queries the MCS as in the simplex call, the MCS asks the TDM switch to forward the call to the MCS Gateway using the Service DN The first query for this call uses the same translations as the Simplex Call to determine if the terminator is in complex mode The MCS forwards the following information to the TDM switch: calling number original called number called number (service DN) On the TDM switch, translations pass all three numbers to the MCS using the Gateway When the call arrives, the MCS Gateway maps the 10-digit Service DN to the MCS Converged Desktop service The Gateway domain must be provisioned to map the service DN and calling/called numbers to the user s domain The MCS cannot translate the Service DN to a service The MCS can translate only the DN for a subscriber When the MCS determines that the call is to a service DN, the Converged Desktop service takes the original called number ( in this case) and routes the call to the terminator again MCS Private telephony invokes translations to find the terminator Click to Call Click to Call refers to calls that originate from the MCS to ring the calling party s telephone before placing a call to the terminator Telephony translations at the MCS used to call the originator s phone and then the terminator For example, Greg wants to call Dave and uses the Click to Call feature The MCS Gateway translates the action into calling Greg using the number and then calling Dave Restrictions and limitations for telephony translations The following are restrictions and limitations: 1 Call forward and number of pop-up windows a CD telephone that forwards a call to another phone is displayed in a pop-up window The window remains open until the forwarded call is released The switch Call Forward service runs after the AIN 01 Termination Attempt trigger is invoked The Termination Attempt trigger creates a pop-up in a window with the MCS A possible solution is to remove the Call Forward feature from the telephone and invoke it from the MCS Personal Agent NN Standard Release February 2010

88 88 Configuration management 2 Interactions with Call Transfer whenever a call comes in through a Gateway into MCS, the originating Converged Desktop client displays a window if the Gateway sends the Converged Desktop Alias or the correct user@domain provisioned for that user An example of this is a call transfer When the MCS transfers CD users, the original pop-up windows for the newly-established calls close after the transfer of CD call is complete New windows to represent the transferred leg are based on successfully identifying the originating user as an MCS CD subscriber This scenario is more evident in configurations in which multiple domains are involved in the call and the Gateway is provisioned to point only to a single MCS and domain Nortel recommends configuring translations so that the Converged Desktop Alias is always provided to the Session Manager for the originating Converged Desktop users and this is subsequently used when the call is transferred by the Gateway to another user 3 Call forward interactions with DMS variant PRI trunk the Converged Desktop uses the PRI redirection numbers on the Gateway trunk to determine the terminator of the call in the Complex call scenario The DMS Variant PRI trunk limits the number of redirection DN available to only the Original Called DN and does not include the Redirecting Number in the PRI message Due to this limitation, if a telephone is forwarded to user B s telephone, the call forward is not completed User B s telephone is marked as the Redirecting Number, but is number not available on the DMS variant PRI trunk If this configuration is required, then use NI2 variant PRI trunk because it supports both the Original Called Number and the Redirecting Number 4 A CD user cannot park a call, but a CD user can be parked 5 Depending on how call routes are configured in the Personal Agent, the Click to Call feature can have certain limitations For example, a Converged Desktop user configures the Personal Agent to route an incoming call to SIMRing and, if the call is unanswered, to respond with an initial Instant Message (IM) window In this scenario, if two Converged Desktop users are on the same Session Manager, the call route works as expected That is, one CD user calls the other CD user using Click to Call, and the originating caller receives an initial IM window after the call goes unanswered However, the call behavior changes when two CD users are not on the same Session Manager When the CD user on another Session Manager calls a CD user using Click to Call, the originating caller receives an IM in a second IM window 6 Although video can be enabled in their service package, Converged Desktop users cannot start video if they chair a Meet Me Audio Conferencing call using a Converged phone or a Multimedia Client NN Standard Release February 2010

89 Configuring IN to SIP Signaling gateway 89 Configuring IN to SIP Signaling gateway There are two areas of configuration for the Personal Agent (PA) Carrier service: Network routing and user The following tasks are required for enabling a CD user: Configure Termination Attempt Trigger (TAT) trigger against user s DN on user s home switch User defines route or routes in PA The following items are required for Network activation: Switch TAT trigger activation Point AIN connection towards AIN-SIP enabled SCP MCS 5100 Provision SCP IP address Configuring a CD user at the switch A CD user must have an existing DN provisioned on the switch A TAT is provisioned against the CD user s DN The procedure to do this differs from switch to switch For more information, see the switch documentation The switch must be configured with, and connected to, an SS7 network that contains the SCP that meets the AIN to SIP specification as described in the AIN to SIP document Assigning TAT trigger to a user DN on a DMS switch The following is an example of how a TAT is assigned to a user s DN on the DMS Table TRIGITM defines the TAT, including any digit, call type, or escape criteria for the trigger, the action to be taken (trigger or escape), and the SCP the query goes to TDP TINAME TRIGGER TRIGDATA CRITERIA STATE ACTION SLHR OPTIONS TAT2 TERMATT $ ULK EVENT R01 SS7 AINBLUES $ The preceding TAT is then assigned to a user s DN through ServerID >ado $ OPTION: >ain AINGRP: >tiid TIASGN: >20 TINAME: >tat2 TRIGACT: >on OPTION: >$ NN Standard Release February 2010

90 90 Configuration management COMMAND AS ENTERED: ADO NOW AM ( AIN TIID 20 TAT2 ON ) $ ENTER Y TO CONFIRM,N TO REJECT OR E TO EDIT Configuring the switch routing The TAT service must terminate to an SCP that is provisioned with AIN to SIP in addition to connectivity to the serving MCS 5100 For more information on connecting the SCP to both the switch and MCS 5100, see the SCP feature documentation and the switch documentation Configuring the MCS 5100 for SCP connectivity The TATs are sent from the terminator switch to the configured SCP The SCP processes the AIN message and sends a SIP message to the Application Server The SCP configuration requires the following conditions: SCP is a gateway To the Application Server, the SCP is just a gateway It sends and receives SIP messages through TCP/UDP connectivity SCP is a trusted node The SCP is considered a trusted node; therefore, all Invite messages or other SIP requests coming from the SCP are not challenged The SCP is not configured to provide authentication credentials for each CD user Because the SCP has a minimum of two IP links to the Application Server, each SCP link must be added to the trusted nodes list on the Application Server For more information on adding a Gateway as a trusted node, see the Application Server configuration documentation SCP connectivity private Because the SCP is considered a trusted node, configure the SCP to be on the private network side of the Application Server Configuring voice mail servers The administrator uses the Provisioning Client to provision third-party voice mail server information to set up and route calls to voice mail associate users to a voice mail server set up a voice mail server to receive message waiting indication (MWI) notifications You can configure the MCS 5100 to interwork with the following types of voice mail servers: SIP-based An IP-based voice mail server that uses the SIP protocol This server type does not need a PSTN gateway Only UDP transport for SIP protocol is supported by the MCS5100 NN Standard Release February 2010

91 Configuring LDAP 91 trunk-based A legacy Public Switched Telephone Network (PSTN) based voice mail server that uses a Primary Rate Interface (PRI) or Channel Associated Signalling (CAS) gateway The Session Manager uses SMDI to send call setup information using a Call Detail Message to get MWI information from the voice mail server line-based A voice mail server with multiple lines A 10-digit telephone number that goes into the voice mail server identifies each line When people leave messages, the individual lines operate in a round robin manner to connect to the voice mail server to allow someone to leave a message The Session Manager sends an SMDI message to the voice mail server to help establish the connection to the Session Manager that uses SMDI to obtain Message Waiting Indication (MWI) information from the voice mail server For detailed descriptions of the provisioning tasks required for the MCS 5100 to interwork with each type of voice mail server, see Provisioning Client User Guide (NN ) Configuring LDAP LDAP provides the administrator with the option to use an existing LDAP server on their network and augment the MCS 5100 database with subscriber data immediately or at a conveniently scheduled time You provision LDAP on a domain basis through LDAP synchronizing (LDAP Syncing) in Provisioning > Domains > DomainName, as shown in Figure 32 "LDAP synchronization screen" (page 92) NN Standard Release February 2010

92 92 Configuration management Figure 32 LDAP synchronization screen When the administrator expands the LDAP Syncing, five links appear: Server Configuration Used to configure the primary and secondary LDAP servers Schema Configuration Used to configure the schema that the MCS 5100 uses to create users when synchronizing with an LDAP version 3 server User Defaults Used to configure the defaults that the MCS 5100 uses to create new users The defaults include User Password, Service Package, Class of Service, Status Reason, Time Zone, and Locale The default values depend on what is already provisioned for the domain Synchronizing Scheduler Used to automatically schedule the synchronizing of the MCS 5100 user database with an LDAP version 3 server The administrator can also schedule an immediate synchronizing operation Query Test Tool Used to verify that the MCS 5100 is correctly configured to talk to an LDAP version 3 server by permitting the initiation of a query NN Standard Release February 2010

93 Configuring LDAP 93 LDAP Server configuration Use the LDAP Server Configuration screen to configure the MCS 5100 system to communicate with an LDAP server Use this screen to configure: IP address and port of primary and secondary LDAP server Selection of the LDAP server logical name from the list Userid and password of the LDAP server, if necessary, for querying the server Connect to LDAP server with a secure socket through SSL or through a normal TCP socket The SSL field is for future use If you select this field, scheduled or immediate synchronizing fails You must import the certificate to the voice mail through the key tool executable that is available as part of the Sun JRE Procedure 3 Adding an LDAP server Step Action At the Provisioning Client 1 Click Provisioning > Domains > <domain name> > LDAP Syncing > Server Configuration NN Standard Release February 2010

94 94 Configuration management Figure 33 LDAP server configuration screen 2 Select Primary or Secondary from the Server Selection menu 3 Select an address from the Server Address menu 4 Select, if required, the Require Server Login check box 5 Enter a name in the User Name dialog box 6 Enter a password in the Password dialog box 7 Select, if required, the Use Secure Connection check box 8 Click Save End LDAP Schema configuration Use the LDAP Schema Configuration sheet to configure the schema that the MCS 5100 system is to use from the LDAP server NN Standard Release February 2010

95 Configuring LDAP 95 Distinguished Name information LDAP Protocol uses a Distinguished Name (DN) to distinguish one entry in an LDAP database from another For example, an entry whose userid is joeb: dn: uid=joeb, ou=internal, ou=people,o=abc The uid field is part of the Relative Distinguished Name (RDN) for this particular entry Every user in the domain must have a different uid field and uid should match requirements for MCS username (NN ) page 104 For more information, see Figure 36 "LDAP schema configuration DN and attribute mapping" (page 97) When you configure a domain on the MCS 5100, you create the first portion of the DN, o=domainname Notice that the LDAP Distinguished Name o=domain name is present by default The domain name that is configured on the MCS 5100 must match the organization (o) field, on the LDAP server However, MCS 5100 administrators have the ability to refine their searches by including other attributes, such as organizational unit (ou) For instance, in Figure 34 "Company ABC DIT" (page 95), ou=people and ou=external can be included in the dn to further refine the entries in the LDAP database that will be used to create MCS 5100 users This limits synchronizing to the dotted lined portion of the LDAP database as pictured in Figure 36 "LDAP schema configuration DN and attribute mapping" (page 97) The LDAP Distinguished Name field would now contain the following additional parameters, separated by spaces: o=domainname ou=people ou=internal Figure 34 Company ABC DIT NN Standard Release February 2010

96 96 Configuration management Figure 35 Company ABC Refined DIT If no additional parameters are given for the DN, all entries under the o=abc are used to create new MCS 5100 users LDAP server attribute mapping It is possible that an administrator has configured one or more of these items to another field within the database, so the ability to use a different attribute to populate the MCS 5100 system is possible Use the Schema Query tool to verify what attributes are available on the LDAP server If necessary, you can modify the default attributes to match If the LDAP server does not support the retrieval of its schema, the LDAP server administrator should acquire it The standard attributes are the default and are depicted in Figure 36 "LDAP schema configuration DN and attribute mapping" (page 97) The following table contains the mandatory attributes in the LDAP database that are used to create an MCS 5100 user Table 13 Mandatory LDAP attributes Attribute User Name First Name Last Name Default value uid givenname sn The following table contains the optional attributes that can be mapped to MCS 5100 users if present in LDAP database NN Standard Release February 2010

97 Configuring LDAP 97 Table 14 Optional LDAP Attributes Attribute Business Phone Home Phone Cell Phone Pager Fax Jpeg Photo Preferred Language Default value mail telephonenumber homephone mobile pager facsimiletelephonenumber JpegPhoto preferredlanguage Figure 36 LDAP schema configuration DN and attribute mapping Procedure 4 Adding an LDAP schema configuration Step Action At the Provisioning Client NN Standard Release February 2010

98 98 Configuration management 1 Click Provisioning > Domains > <domain name> > LDAP Syncing > Schema Configuration 2 Enter the distinguish name in the LDAP Distinguished Name dialog box 3 Enter a user name in the User Name dialog box 4 Enter the user s first name in the First Name dialog box 5 Enter the user s family name in the Last Name dialog box 6 Enter the user s address in the dialog box 7 Enter the user s work telephone number in the Business Phone dialog box 8 Enter the user s home telephone number in the Home Phone dialog box 9 Enter the user s cell phone number in the Cell Phone dialog box 10 Enter the user s pager number in the Pager dialog box 11 Enter the user s fax number in the Fax dialog box 12 Enter the user s portrait file name in the Jpeg Photo dialog box 13 Enter the user s LDAP schema name in the MCS 5100 User dialog box 14 Click Save End When you select attributes, you change how each user s Personal Agent behaves because now the user cannot modify these fields This is necessary because otherwise users can modify their jpeg photos through the Personal Agent and then, during the next synchronizing operation, the Jpeg Photo would be overwritten with whatever Jpeg photo was present in the LDAP database If the LDAP server does not contain any data for any of the proceeding non-mandatory attributes, or if the administrator decides that users should be able to modify a certain fields through the Personal Agent, the administrator can leave any of the non-mandatory fields blank During an LDAP synchronizing operation, the blank attributes are not synchronized and the user can modify those particular fields through the Personal Agent NN Standard Release February 2010

99 Configuring LDAP 99 User defaults Figure 37 "User defaults" (page 99) shows the User Defaults window, which an administrator uses to configure the default User Password, Service Package, Class of Service, Status Reason, Time Zone and Locale for any new MCS 5100 users that are created Figure 37 User defaults Procedure 5 Adding user defaults Step Action At the Provisioning Client 1 Click Provisioning > Domains > <domain name> > LDAP Syncing > User Defaults 2 Enter a generic password in the Default User Password dialog box 3 Select a service package from the Default Service Package menu 4 Select a Class of service value from the Default Class of Service menu 5 Select a status from the Default Status Reason menu NN Standard Release February 2010

100 100 Configuration management 6 Select the time zone from the Time Zone menu 7 Select a language from the Locale menu 8 Click Save End LDAP Synchronizing Scheduler Use the LDAP Synchronizing Scheduler to configure when automatic synchronizing of an LDAP database with the MCS 5100 occurs The administrator can schedule queries on a monthly, weekly, daily, or immediate basis Figure 38 "LDAP Synchronizing Scheduler for weekly schedule" (page 101) depicts a schedule for every Sunday at 2:15 am The current status is displayed when the LDAP Synchronizing Scheduler sheet is first accessed indicating what the current schedule (if any) is and whether it is enabled The administrator also can turn on or off the synchronizing operation for a given domain The time used to schedule a synchronizing operation is based on the internal server clock of the Provisioning Manager server If the server time is incorrect, the synchronizing operation will run at the incorrect time As a benchmark, synchronizing an LDAP database with 2000 users takes approximately 5 minutes Nortel recommends that the LDAP synchronizing operation be scheduled during off-peak hours to preserve MCS 5100 system resources If the administrator attempts to perform an immediate synchronizing operation, a warning message indicates that the synchronizing operation can impact system performance The administrator must acknowledge the warn before the synchronizing operation begins Similarly, if the administrator is scheduling a LDAP synchronizing operation for some future time, a warning message indicates that the synchronizing operation can impact system performance and that Nortel recommends that the synchronizing operation be scheduled during off-peak hours If a synchronizing operation fails, system logs indicate the failure reason: LDAP Server Connection Failure During the LDAP synchronizing operation, the Primary and Secondary servers were unreachable Maximum MCS 5100 User Limit Reached During the LDAP synchronizing operation, the MCS 5100 reached the maximum number of provisioned users In either case, the administrator can either schedule an immediate synchronizing operation or wait until the next scheduled synchronizing operation, as shown in Figure 38 "LDAP Synchronizing Scheduler for weekly schedule" (page 101) NN Standard Release February 2010

101 Configuring LDAP 101 Figure 38 LDAP Synchronizing Scheduler for weekly schedule Procedure 6 Adding an LDAP Synchronizing schedule Step Action At the Provisioning Client 1 Click Provisioning > Domains > <domain name> > LDAP Syncing > Schema Configuration 2 Select the Enable Scheduler check box to activate the LDAP synchronizing schedule 3 Select the time of day you wish to synchronize with the Time menus 4 Select a synchronizing frequency: NN Standard Release February 2010

102 102 Configuration management Table 15 Synchronizing frequency If you want to synchronize weekly you want to synchronize monthly Do Click the Weekly option button and the corresponding check box for the day of the week for thesynchronizing operation Click the Monthly option button and select the day of the month from the menu 5 Click Save Synchronizing Time End LDAP Query Test Tool The administrator uses the LDAP Query Test Tool, shown in Figure 39 "LDAP Query Test Tool" (page 103), to verify connectivity to an configured LDAP database by providing an interface from which to query the LDAP database for a user If a query is successful and returns a user, the administrator can manually add or update the user (if already present) in the MCS 5100 with the data retrieved from the LDAP database To perform the query, the administrator must enter a unique attribute and value of a user in the LDAP database and press the Query LDAP Database button If successful, at this point the administrator can add or update the user A message appears if the addition or update was successful In the event of a failure, an error message advises that the administrator must verify the LDAP Server Configuration and LDAP Schema Configuration To use this tool, the LDAP Server Configuration sheet must already be configured NN Standard Release February 2010

103 Configuring LDAP 103 Figure 39 LDAP Query Test Tool Procedure 7 Performing an LDAP Query Test Step Action At the Provisioning Client 1 Click Provisioning > Domains > <domain name> > LDAP Syncing > Query Test Tool 2 Enter the name of an attribute in the Enter LDAP Attribute to Search On dialog box 3 Enter a value for the attribute in the Attribute Search String dialog box 4 Click Query LDAP Database End NN Standard Release February 2010