This chapter provides a high-level overview of the interworking
between the Multimedia Communications Platform (MCP) and the
following systems:
•Primary Rate Interface (PRI)-enabled switches
•SIP-T-based switches
•third-party g ateways
•traditional phones
•third-party vo icemail servers
Interworking with PRI-enabled switches
The MCP uses the SI P PRI Gateway to perf orm interworking with
PRI-enabled switches (switches with PRI interfaces).
For more detailed information about the SIP PRI Gateway, please refer
to the MCP SIP PRI Gateway Basics document.
3
Functional description
The SIP PRI Gateway is a signaling and media gateway that
interconnects a SIP-based Voice over IP (VoIP) domain and a system
that uses ISDN Primary Rate Interface (PRI/Q.931).
A PRI-enabled system can be a switch that works on the
Public-Switched Telephone Network (PSTN) or Private Branch
Exchange (PBX). The Nortel Networks DMS-100 and the Nortel
Networks Meridian SL-100 are examples of PRI-enabled switches.
The SIP PRI Gateway’s primary functio n is to convert the packet-based
voice streams of the V oI P system to circuit-based vo ice streams of the
PRI-enabled system.
The SIP PRI Gateway supports the following call types:
•SIP to PRI
•PRI to SIP
•PRI to PRI
The SIP PRI Gateway supports the following call features:
•Basic call: The ability to make a call.
•Hold/Retrieve: The ability to hold and retrieve calls.
•Call transfers: The ability to forward the call to a third party after the
call is established. Call transfer is limited to SIP clients. Callers from
the PRI-enabled switches cannot perform this function.
•Call redirect: The ability to forward a call before it is answered.
•Codec negotiation: The ability to negotiate between different VoIP
codecs during call setup, mid-call, call transfer, and call retrieve.
The SIP PRI Gateway supports the following codecs:
•Call rejection: The ability to reject a call on nodal authentication
request.
•Calling party name and number: The MCP supports the
delivery/reception of calling party name and number information
to/from PRI-enabled switches. Incoming callin g party informa tion
privacy indication is honored by the MCP . For MCP call originations,
privacy indication is not used.
•Dual-Tone Multi Frequency (DTMF) outpulsing: The ability to
outpulse to PRI-enabled sw itches. However , DTMF detection is not
provided. Military DTMF digits A-D are current l y not supported.
•ISDN trunk group selection: The selection is based on information
provided in a request Universal Resource Identifier (URI).
•Ringback: The SIP PRI Gateway provides ringback towards the
circuit-switched side of the network.
•PRI variant support: The SIP PRI Gateway supports different PRI
variants. For a list of the PRI variants that the SIP PRI Gateway
supports, please refer to the MCP SIP PRI Gateway Basics
document.
•SIP/PRI mapping support, including:
— Protocol parameter mappin g
— error codes
— PRI cause values with SIP responses
— presentation a nd screening indicators
•PRACK: the provisional response acknowledge message that
ensures that the ringing signal does not get lost.
•T ype of Server (ToS): The ToS bit can be configured to indicate the
priority of the voice packet over data packet to ensure quality of
service.
•Long-call service: The ability to detect abandoned calls.
More detailed information about the functional capabilities of the SIP
PRI Gateway is available in the MCP SIP PRI Gateway Basics
document.
Interworking with CS 2000
Even though Nort el Ne tw orks C om m unication Server 2000 (CS 2000)
is a V oIP switch, it d oes not fully suppor t the Session Initiati on Protoco l
(SIP). The following de scri p ti on provides information on how the MCP
interworks with the CS 2000.
Overview 5
The MCP does not support VoIP over Asynchronous Transfer Mode
(ATM) or pure ATM, as the MCP network nodes are IP-based and not
ATM based.
Functional description
The interworking betw een an MCP and CS 2000 uses Session Initiat ion
Protocol for Telephones (SIP-T) over User Datagram Protocol (U DP) to
transport ISDN User Part (ISUP), the call control part of the Signaling
System 7 (SS7) protocol.
SIP-T is an e xtension of the Se ssion Initiation P rotocol (SIP) that allows
SIP to be used to facilitate the interconnection of the Public Switched
Telephone Network (PSTN) with p acket networ ks. SIP-T e ncapsu lates
the ISDN User Part (ISUP) messages in the SIP messages and
translates ISUP information into the SIP header for routing purposes.
Although the MCP SIP Application Module supports receiving of
encapsulated ISUP messaging (usi ng SIP-T), it does not send
encapsulated ISUP back out. For more information about the
capabilities of the SIP Application Module, please refer to the SIP Application Mo du le Basi cs document.
Figure 1 shows a network view of the MCP/CS 2000 interconnection.
The MCP configuration enables direct connection between the MCP
and CS 2000 with no intervening SIP proxies. The CS 2000 and its
associated media gateways are placed in the private managed
network.
Figure 1 MCP/CS 2000 Network view
network 1
network 1
Supported services
This section provides inform ation on services that can interwork
between the two platforms .
PSTN
SIP-T
MCP
SIP-T
SIP
SIP-T
PSTN
network 2
SIPSIP
MCP
network 2
VPN Dialing
A Virtual Pr ivate Network (VPN) d ial plan enables an enterprise to have
one common dial plan across different geographic locations without
incurring long-distance expenses.
The MCP system uses domains to man age its call routing, while the CS
2000 system uses customer groups.
A profile is used to facilitate call routing between the two systems. The
header named “x -nor tel- pro file” is used to ident ify the CS 20 00 pro file.
The profile is used to ma p the domain to a PSTN custome r group in the
PRODOMAIN table in the Database Module.
The profile is added when a new do main is created in the MCP system.
Note: The profile name in the TEL EPROF table on the CS 2000 side
must match the profile name in the PRODOMAIN table on the MCP
side. Otherwise, interworking between the MCP and CS 2000 will not
work.
Call Forward
Both the MCP and the CS 2000 support call forwarding. No extra
interworking consider ati ons are necessa ry as call forw ardi ng does not
interact across the MCP and CS 200 0 domains, except to deliver a call
between the two domains.
Call Transfer
Call transfer works between the two platforms. The calls are transferred
because from each platfor ms view the other is ju st ini tiatin g a new call.
Ad Hoc Conference calls
There is no change in the conference application between the two
platforms. Whe n an ad hoc conference call is made, the client
application that starts the conference controls where the conference
bridge is allocated. For exa m ple, i f the conference call is made from a
client application on the MCP side, the conference bridge will be
allocated on the MCP.
Overview 7
Media Negotiation
The MCP provides media negotiation for the CS 2000 since the CS
2000 gateway contr ol ler i s not capable of providing this function in the
current release.
The MCP requires a list of all commonly supported codecs across the
CS 2000 media gateways to be provisioned in the cs2k.xml file. The list
is required because the MCP does not determine which gateway the
CS 2000 will use.
Although the MCP also allo ws f or the pr ovision ing o f p acket ti mes th at
the CS 2000 will use, this is not recommended. By provisioning specific
packet times, the SDP packet time will no longer pass transparently
through the MCP. This means that the packet time negotiation that
would normally occur at the client level is now being handled at the
server level, and this could lead to voice connection issues.
The SDP sent by the CS 2000 media gateways is only guaranteed to
contain the v=, c= , m=, and a= SDP heade rs in the SDP message. The
gateways can accept reception of other SDP parameters, so no
screening needs to be done on the SDP that the MCP sends to the CS
2000. The only exception is the screening of the m= lines to only
include the audio codecs supported by the gateways. For the SDP that
is received from the CS 2000, the MCP fills in the missing mandatory
parameters as specified in RFC 2327. Details on the restrictions on
SDP are specifie d in the SN03 IP Gateway InterOP Requirements
document.
Recursive Search
The MCP Back-to-Back User Agent (BBUA) handles SIP 302
responses to an INVITE sent out because of a received INVITE from
the CS 2000. The BB UA sends INVITEs for each contact in the S IP 302
response. The SIP 302 response will not be passed back to the CS
2000. The INVITES fo r each contact can be sent parallel or sequ entially
depending on the mode in which the BBUA processed the initial
INVITE, which then resulted in the SIP 302 response.
Hold
SIP implement s a Hold as a re-INVITE with the connectio n information
in the SDP set to 0.0.0.0. In this release, Hold cannot be handled by all
the CS 2000 media gateways. The MCP shields the CS 2000 from
seeing Hold re-INVITE requests. The MCP, when equipped with an
RTP Media Port al, ca n ma nage the RTP connections witho ut af fe cting
the connection to the CS 2000.
Retrieve
Retrieve is also implemented in SIP through a re-invite. To retrieve a
party on hold the new invite contains va li d SDP. The new SDP is use d
to restore the media connection between the two clients.
Long Call Audit Timers
In order to prevent hung calls between the two platforms, a long call
audit timer is implemented between the two platforms. Both platforms
use the INFO ping capability described in the SIP INFO message
RFC2976. This involves sending an INFO message with no message
body. Upon receipt of this message, a client should send a 200 OK if
the call exists. If the response to the INFO is any of the following
response codes, then the platf orm sending the message assumes that
the call no longer exists and frees all resources associated with the call:
If the platform sending the INFO receives a response code other than
the ones listed above, it tre at s the re sponse a s a valid au dit resp onse,
and does not bring the call down.
The CS 2000 sends a 2 00 OK for a n em pty IN FO message and a 481
response code if the call leg does not exist.
Supported media
The following are the media su pported b y the inter working o f MCP and
the CS 2000:
•G. 711 PCMU
•G. 711 PCMA
•G. 729
•G. 723
•G3 Fax
•Modem
Note 1: This list represents a full list of the media capabilities the
MCP can use while inte rworkin g wit h the CS 2 000. The actual list of
supported media types depends on the capabilities of the gateways
that the CS 2000 is using.
Overview 9
Note 2: G3 Fax and Modem media calls are used only for CS 2000
gateway calls as there are no MCP endpoints that support either of
these two media types.
QoS
MCP implements its Quality of Service through the DiffServ
(Differenti ate d Ser vi c e) feature. The parameters of MCP QoS includ e
the following:
•QoS DiffServ code for s i gnaling: specifies signaling quality for SIP
clients.
•QoS DiffServ code for au dio: specifies audio quality for SIP clients.
•QoS DiffServ code for video: specifies video quality for SIP clients.
•QoS 802.1p for service priority: specifies service priority for SIP
clients.
Interworking with third-party gateways
The MCP can use SIP signaling between the MCP networ k and a
third-party SIP-enabled gateway. The third-party gateway provides the
necessary signalling interworking between the MCP network and the
other network to whic h the gateway is conn ected. For example, a
line-based voicemail server requires that a Line Gateway be placed
between the MCP network and the voicemail server. This Line Gateway
would process SIP message s to/from the MC P network and create the
corresponding line signalling to/from the line network. “Interworking
with third-party voicemail servers” on page 13, provides more
information about how the MCP interworks with non-SIP aware
voicemail servers.
Interworking with traditional phones
The MCP provides Con verged Desktop Servi ces (CDS) to facilit ate the
interworking with traditional phones of the TDM network. This allows
users to have a p ersonal computer (PC) provide the m ultimedia porti on
of their communication session while having the traditional telephony
system provide the voice portion of their communication session.
Functional description
A user’s Converged Desktop consists of a regular TDM telephone, and
a SIP Multimedia PC Client (PC Client) software provisioned as a
Converged PC Client. Figure 2 shows how the Converged PC Client
interconnects wit h the ne twor k. Th e C o nve rged PC C l ient pr ovide s a n
enhanced communication experience to the user, while the TDM
telephone works exactly as it does today.
CDS enhances the end user’s communication experience in a variety
of ways:
•Advanced Call Handling: The user can use the MCP Personal
Agent web pages to control the user’s availability. By providing this
ability to CDS users, features not easily accessible on existing TDM
switching systems now become viable. For example, a user can
activate MCP-based f orking (using the Personal Agent we b pag es)
so that when the user’s desktop telephone is called, the users cell
phone rings as well. Once one leg of the forked call is answered, the
other leg stops ri ng in g.
•Inbound call log: Allows the user to see who has cal l ed and when
the call occurred.
•Video calling line identification: Allows the user to see who is callin g.
The picture is retrieved from the network-based address book
accessible on the Converged PC Client.
•Redirection of incoming calls at the Converged PC Client: Upon the
arrival of an incoming call, the user may click on the “Redirect”
button, and send the incoming call to another address. Once the
user answers the call (using the TDM phone), the redirect function
is no longer available.
Overview 11
•File transfer: If both the originator and terminator support the MCP
file transfer collabora ti on ap pl ic ation , t hen files can be transferred
back and forth between the two users. The PC Client (both
Converged and non- C on ver ge d) is th e only endpoint that supports
this functionality.
•Whiteboard sharing : If both the originator and te rminator support the
MCP whiteboard collaboration application, then a whiteboard
session can be set up between the two user s. The PC Cli ent (bot h
Converged and non- C on ver ge d) is th e only endpoint that supports
this functionality.
•Clipboard transfer: If both the originator and terminator support the
MCP clipboard transfe r collaboration applicati on, then the Windows
System Clipboard may be transferred between the two users. The
clipboard transfer application allows a user to “Copy (CTRL-C)”
items such as PowerPoint slides or sections of Excel sp readsheet s
to the clipboard, and then sends them to the other party. The other
party then “Pastes (CTRL-V)” the items. The PC Client (both
Converged and non- C on ver ge d) is th e only endpoint that supports
this functionality.
•Web Co-bro wsing: If both the or iginator an d termina tor are capa ble
of this functionality, then one user can automatically drive the
other’s web browser. The PC Client (both Converged and
non-Converged) i s the only endpoi nt that support s this functionality.
The Web Client supports the reception of web pages, but cannot
send web pages to a Converged PC Client.
•Instant Messaging (IM): The Converged PC Client can send and
receive messages from any client that support s the Nortel Ne tworks
IM format. All MCP clients support sending a nd receiving of inst ant
messages with each other.
•Presence state indications: The Con verged PC Client allows the
user to select a presence state in the MCP ne twork. The Converged
PC Client also allows the user to see the presence state s for the
Buddies defined in the user’s network-based address book.
PRI is used as the interface between the existing TDM switching
system and the MCP. The MCP supports the following PRI protocol
variants:
•AT&T 4ESS(AT4)
•AT&T 5ESS (E10)
•AT&T TR 41459
•Bellcore National 2
•ETSI
•ECMA-143
•ETS 300 102-1
•Northern Telecom DMS-100 (DMS)
•NIS A211-1
•QSig
For more detai led information a bout the which PRI varian ts the SIP PRI
Gateway supports, please refer to the MCP SIP PRI Gateway Basics
document.
Successful interworking between the MCP and the TDM switch
requires that the TDM switch acti vate the Simultaneous Ring (SimRing)
feature and assign each user a SimRing number. A user in the TDM
switch that has acquired this SimRing n umber can be a C DS user . Th e
SimRing featur e must send “SimRing” calls to a routable and unique
number for each CDS user.
The MCP system operator must provision a user a s a CDS user . A CDS
user cannot use the SIP Multimedia PC Client for voice. The CDS
user’s TDM phone is u sed for voice. In addition, the CDS user m ay use
other SIP endpoints (such as the SIP Multimedia Web Client or an
i2004 controll ed by the IP Client Ma nager (IPCM) for voice over IP calls.
An MCP alias must be set up for each user so that the alia s is the same
as the Calling Line ID sent from the TDM switch to the MCP over PRI.
When a non-CDS MCP user calls a CDS user, the call is sent out the
gateway to the CDS user’s TDM phone and the non-CDS user’s
public/private charge ID is used to identify them to the TDM switch as
the calling party. This charge ID is sent to the Converged PC Client, on
the SimRing leg of the call, an d is used by the Con verged PC Cli ent to
contact the calling party’s MCP client. Therefore, the non-CDS user’s
charge ID must be included as an alias in the non-CDS user’s
provisioning. A non-CDS user’s charge ID cannot be shared amongst
users within a domain because the charge ID must be included as an
alias and a user's aliases must be unique within a domain.
Calls to a CDS user must terminate to the existing switching system of
the CDS user before the call is routed to the MCP. For example, the
originator’s existing switching system must route calls using the
existing systems, as opposed to sending the call to the MCP. This is
required since all calls from the SIP PRI gateway are implied to have
been triggered by the SimRing feature on the existing switching
system.
Overview 13
Interworking with third-party voicemail servers
There are three major types of third-party v oicemail servers. The
following sections describe how the MCP can interwork with the
following types of third-party voicemail servers:
•SIP-based voicemail servers
•Trunk-based voicemail servers
•Line-based voicemail servers
SIP-based voicemail servers
SIP-based voicemail servers are SIP-enabled and can interwork
directly with the MCP network. SIP is used to set up connections
between the client and the voicemail server. The RTP Media Portal is
used to carry the media packets between t he client and the voicemail
server.
Figure 3 shows how the MCP interconnects with a SIP-aware
third-party voicemail server.
For more information on how the SIP Application Module uses Media
Gateway Control Protocol Plus (MGCP+) to control the RTP Media
Portal, please refer to the MCP Media Portal Basics document.
For more information on how the IP Client Manager uses Unified
Networks IP Stimulus (UNIStim) to control the i2004 Internet
Telephone, please refer to the MCP IP Client Manager Basics
document.
Trunk-based voicemail servers
Trunk-based voicemail servers cannot directly communicate with the
MCP network. A SIP PRI Gatewa y is required for the MCP to interwork
with a trunk-based voicemail server. The SIP PRI Gateway also
provides a media path from the IP network to the voicemail server on
the PSTN.
A terminal server, using a Simplified Message Desktop Interface
(SMDI), sends data regarding the storage and retrieval of voicemail
from the trunk-based voicemail server to the MCP network. The MCP
network does not send data back to the voicemail server over the SMDI
link. Figure 4 shows a n etwork vi ew of th e MCP i nter connect ion with a
trunk-based third-party voicemail server.
Line-based voicemail servers cannot directly communica te with the
MCP network. A Line Gateway, also known as an analog station
gateway, is required for the MCP to interwork with a line-based
voicemail server.
Similar to interworking with tru nk-based voicemail servers, an SMDI
terminal server is to exchange data between the MCP and the legacy
voicemail server. However, the SMDI links are used to both send and
receive data regarding the storage and retrieval of voicemail from the
line-based voice mail server to the MCP network. Figure 5 shows a
network view of the MCP interconnection with a line-based third-party
voicemail server.
This chapter provides information about upgrade procedures dealing
with MCP interworking with the following other systems:
•Primary Rate Interface (PRI)-enabled switches
•SIP-T-based switches
•third-party g ateways
•traditional phones
•third-party vo icemail servers
Interworking with PRI-enabled switches
MCP interworking with PRI-enabled switches does not involve
additional software deployment to the PRI-enabled switches. The MCP
SIP PRI Gateway uses standard PRI protocols and is compatible with
any PRI-enabled switch that understands these standard PRI
protocols:
17
•AT&T 4ESS(AT4)
•AT&T 5ESS (E10)
•AT&T TR 41459
•Bellcore National 2
•ETSI
•ECMA-143
•ETS 300 102-1
•Northern Telecom DMS-100 (DMS)
•NIS A211-1
•QSig
Because SIP revisions are backwards compatible, the MCP SIP
Application Module and the MCP SIP-PRI Gateway can be upgraded
independently of one an oth er. Refer to MCP SIP PRI Gateway Basics
and MCP SIP Application Module Basics for more information on
upgrades to those nodes of the MCP network.
Interworking with CS 2000
MCP interworking with the CS 2000 does not involve additional
software deployment. The functionality exists in the SIP Application
Module. Refer to the MCP SIP Application Module Basics for more
information on upgrades.
Note: Since the MCP and CS 2000 can be upgraded at different
times, the two pr oducts are backwards compatible by one release.
Interworking with third-party gateways
MCP interworking with SIP-enabled third-party gateways does not
involve additional soft ware deployment to the third-p arty gateways. The
MCP SIP Application Module uses SIP to successfully communicate
with a third-party gateway that also speaks SIP. Each third-party
gateway software release must be validated and certified against the
current MCP release.
Nortel Networks Confidential
The MCP SIP Application Module and third-party gateways can be
upgraded indepen dently of one an other . Refer to MCP SIP Application Module Basics for more information on upgrades to the MCP SIP
Applicatio n Mo dule.
For information about the upgrade procedures of a specific third-party
vendor’s gateway, please refer to the documentation provided by that
third-party vendor.
Interworking with Traditional Phones
MCP interworking with traditional telephones does n ot involve
additional software deployment to the existing switching system.
However , the SimRing fea ture on the TDM sw itch must be act ivated in
order to route calls to CDS users.
The MCP network and SIP Multimedia PC Client (PC Client) may no t
be upgraded at the same ti me. As new CDS functionality i s introduc ed
in the network through MCP network node upgrades, the existing PC
Clients must continue to interwork with the network. Therefore, the
MCP network nodes must be backwards compatible with older PC
Clients and MCP nodes. In addition, PC Cl ients (both Converged and
non-Converged) must be backwards compatible with all previously
released PC Client s, as dif ferent ver sions of t he client s ma y co-exist i n
a given MCP network.
Compatibility is maintained by version identifiers included in an MCP
user’s service package information. When new CDS functionality
becomes available in the MCP network, older Converged PC Clients
can continue to exist and operate in the upgraded MCP network;
however, they won’t be able to access the new Converged PC Client
services.
Note: In general, MCP network is upgraded before the PC Client is
upgraded.
Interworking with third-party voicemail servers
MCP interworking with third-party voicemail serve rs does not involve
additional softwa re depl o yment to the third-party voicemai l servers.
The MCP SIP Application Module uses SIP to successfully
communicate with third-party voicemail servers. For non-SIP-aware
voicemail servers, a gateway between the M CP network and the lega cy
voicemail server is used, in which case the MCP SIP Applica ti on
Module still relies on SIP to successfully communicate with that
gateway (for example, the MCP SIP PRI Gateway connects the MCP
network to a PRI trunk-based voicemail server).
Upgrades 19
The MCP SIP Application Module and the MCP SI P PRI Gateway can
be upgraded independently of any third-party voicemail server (or
necessary intermediary gateway). Refer to MCP SIP PRI Gateway Basics and MCP SIP Application Module Basics for more informati on
on upgrades to those nodes of the MCP network.
For information about the upgrade procedures of a specific third-party
vendor’s voicemail server, please refe r to th e do cum en t a ti on provi de d
by that third-party vendor.
For more information about fault management on a specific MCP
network node, please refer to the Fault Management chapter in the
corresponding documents:
•MCP SIP Application Module Basics
•MCP SIP PRI Gateway Basics
For information ab out CS 2000 fault mana gement functional ity , refe r to
the CS 2000 Fault Management document.
For information ab out fault management functi onality on any third-part y
gateway or voicemail server, please refer to the documentation
provided by th at third-party vendor.
This chapter provides information a bout the tasks req uired to configure
the MCP to allow interworking with the following other systems:
•PRI-enabled switches
•SIP-T-based switches
•third-party g ateways
•traditional phones
•third-party vo icemail servers
Unless stated otherwise, all tasks are described from the MCP
perspective.
Configuring the MCP SIP PRI gateway
For more information about configuring the MCP SIP PRI Gateway,
please refer to the Configuration Management chapter of the MCP SIP PRI Gateway Basics and MCP SIP Application Server Basics
documents.
23
Configuring CS 2000 interworking
This section describes the tasks required to configure the MCP for CS
2000 interworking. This section also de scribes the key settings required
for the CS 2000 interworking.
Configuration tasks
The configuration uses provisioning t asks that have bee n described in
detail in the MCP SIP Provisioning Client User Guide . This section
focuses on tasks related to configuring a domain for CS 2000
interworking.
The table below shows the provisioning tasks required depending on
whether a domain exists or not. This section provides procedures for
2Enter your user name and password.
3Click LOG IN NOW.
Gateway configuration
The MCP views the CS 2000 as a type of gateway. To complete calls
between the MCP and the CS 2000, gateways, gateway routes, and
virtual trunk groups need to be configured.
Note: A domain must be configured for CS 2000 interworking before
configuring the gatew a y.
Procedure 2 Configure a gateway for CS 2000 interworking
From the SIP Provisioning Client,
1Click Gateways after you log in.
2Click Add Gateway. The system displays Create new gateway
3Enter the informati on for a CS 20 00 gateway ho st. The CS 2000
Configuration Management 25
window.
gateway host requires the following information:
•CS 2000 host name: The name of the server.
•Port: The port number is 5060.
•maddr: The IP address of the CS 2000’s Virtual Router
Distributio n No de (VR D N).
•Transport protocol: Identify UDP as the transport protocol.
Example
An example of the gateway host information is shown as
follows:
SIPSERVER:5060;maddr=10.10.10.10;transport=udp
4Enter cs2k in the Gateway Type field.
5Click Save to conclude the procedure.
Procedure 3 Configure a gateway route for CS 2000 interworking
From the SIP Provisioning Client,
1Click Gateways after you log in.
2Click Add route. The system displays Create new gateway route
3Enter a description of the new route in the Description box, for
example, CS 2000.
4Click the Domain pull-down list and select a domain that is used
for CS 2000 interworking to associate with the route.
5Click Save to complete the procedure.
For more information about using the SIP Provisioning Client and
configuring gatew ays, p lease r efer to the M CP SIP Pr ovisi oning Cl ient User Guide and the MCP SIP PRI Gateway Basics documents.
Procedure 4 Configure a trunk group for CS 2000 interworking
From the SIP Provisioning Client,
1Click Gateways after you log in.
2Click Add Trunk Group. The system displays the Create new
trunk group window.
3Select a CS 2000 gateway from the Gateway pul l-d ow n list.
4Select a CS 2000 gateway route from the Ro ut e pul l -d own l ist .
Nortel Networks Confidential
5Enter a virtual trunk group name.
6Click Save to complete the procedure.
For more information about using the SIP Provisioning Client and
configuring virtual trunk groups, please refer to the MCP SIP Provisioning Client User Guide and the MCP SIP PRI Gateway Basics
documents.
Telephony routes configuration
Telephony routes configuration is required to set up Class of Service
(COS), telephon y routes, and rout e lists for CS 2000 interworking.
Procedure 5 Configure Class of Service for CS 2000 interw orking
From the SIP Provisioning Client,
1Click Domain after you log in.
2Select the in terworking doma in you want to configure.
3Click Telephony Routes and then Routing COS.
4Enter a name for the Class of Service in the Name box. The
name can be alphanumeri c.
5Enter a description for the COS in the Description box.
6Click Save. The system displays the newly created COS in the
7Repeat Step 4-6 to create additional COS values you need.
8Use the Up and Do wn buttons to reorder th e COS in the C urrent
For more information about using the SIP Provisioning Client and
configuring CO S, please ref er to the MC P SIP Provis ioning Client User Guide and the MCP SIP PRI Gateway Basics documents.
Procedure 6 Configure telephony routes for CS 2000
interworking
From the SIP Provisioning Client,
1Click Domain after you log in.
2Select the in terworking doma in you want to configure.
3Click Te lephony Routes and then Add Telephony Route. The
4Enter the parameters of the telephony route.
Configuration Management 27
Choices Avai la bl e bo x. The hi gh er th e o rd er, the more services
and priorities the COS has.
system displays the Create New Telephony Route window.
5Add the route to a route list.
6Click Save.
7Repeat Step 3-6 to add more routes.
8Click List Telephony Routes to display the list of routes crea ted
for CS 2000 interworking.
9Click Change Parameters. The system displays the parameters
related to the gateway route, including the following:
10Set the parameters to the appropriate values.
11Click Save to complete th e procedu re. You can also click Clear
to remove all the existing values in the fields.
For more information about using the SIP Provisioning Client and
configuring teleph ony routes, please refe r to the MCP SIP Provisioning Client User Guide and the MCP SIP PRI Gateway Basics documents.
Procedure 7 Configure route lists for CS 2000 interworking
From the SIP Provisioning Client,
1Click Domain after you log in.
2Select the CS 2000 domain you want to configure.
3Click Telephony Routes and then Add Route List.
4Click Save to complete the procedure. You can click Clear to
remove all the existing values.
For more information about using the SIP Provisioning Client and
configuring rout e lists, pl ease refer to the MCP SIP Provisioning Client User Guide and the MCP SIP PRI Gateway Basics documents.
Configure domain or sub-domain profile
The MCP maps the domains (and sub-domains) of the MCP network to
the route lists/translations of the CS 2000 side, using profile
information. The following procedure configures the header profile fo r
the domain (or sub-domain) so that MCP knows what domain (or
sub-domain) to use in order to communicate with a CS 2000.
If a sub-domain is used, then the sub-d omain data will override the data
in the parent domain.
Procedure 8 Configure domain profile for CS 2000 interworking
From the SIP Provisioning Client,
1Click Domain after you log in.
Nortel Networks Confidential
2Select the domain you want to configure to talk to CS 2000.
3Click Set Profile.
4Enter a prof ile name in the Profile field. The profile name must
be the same as the profile name in table TELEPROF in the CS
2000.
5Click Save to complete the procedure.
Note: The same steps can be used to configure a
sub-domain. After selecting a domain in step 2, click on
Sub-Domain and select Set Profile for the sub-domain.
For more information about using the SIP Provisioning Client and
configuring domain profiles, please refer to the MCP SIP Provisioning Client User Guide and the MCP SIP PRI Gateway Basics documents.
Node name configuration
The SIP Applicati on Module and CS 2 000 use unique nam es to identify
themselves in the network. Node names must be alpha-numeric strings
and can not contain special characters like "_" or "-". Configuring
service node names is performed through the MCP System
Management Console. For more information on using the Sytem
Management Cons ole, please ref er to MCP System Management Console Basics.
When the SIP Application Module is deployed from the management
server, the service node name is defined in one of two places,
depending on whet her o r no t the S IP App lica tion Mod ule is conf igur ed
in an N+M cluster.
Non-N+M node name configuration
In a non-N+M cluster configuration, the service node name is added to
the "Server Properties" tab in the System Management Console. In a
non-N+M config uratio n, the ser vice node name can b e the nod e name
of the SIP Application Module platform. For more information on
configuring the SIP Application Module service node name in a
non-N+M config uration, plea se refer to the Config uration chapter i n the
MCP SIP Application Module Basics document.
Once the service node name in fo rm at ion is configured in the “Server
Properties” tab of the System Management Console, this infor m ation
must then be datafilled on the CS 2000 (table MGCINV).
N+M node name configuration
In an N+M configuration, the service node name has to be assigned to
the service instance so, unlike the non-N+M configuration, the service
node name can not be the node name of the SIP Application Module
platform. Each service instance is defined as a service parameter in
each Network Service Description (NSD) in the “Transport
Management” tab. Each NSD has to de fine a unique ser vice name.
This is done by adding a ser vice name of "Service _Node_Name" in the
label field and the desired node name in the Value part. For more
information on configuring the SIP Application Module service node
name in a N+M configuration, please refer to the Configuration chapter
in the MCP SIP Application Module Basics document.
Configuration Management 29
Once the service node name information is configured in the “Transport
Management” ta b of t he Syste m Ma na ge me nt Console, this
information must then be datafilled on the CS 2000 (table MGCINV).
CS 2000 node authorization
The SIP Application Module allows only authorized network nodes to
send a SIP request to it with out requiring the request to be
authenticated. The SIP PR I Gate wa y is an exam pl e of an aut ho ri ze d
network node; the SIP Application Module does not challenge incoming
call requests from the SIP PRI Gateway. The CS 2000 node must be
added to list of authorized nodes so that it can send SIP-T messag ing
to the SIP Application Module. This is achieved by adding the IP
address of the CS 2000 to the Authorized SIP Nodes field in the
“Authenticatio n” tab of the System Ma nage Console. For more
information on configuring the SIP Application Module service node
please refer to the Configuration chapter in the MCP SIP Application Module Basics document.
Configuring third-party gateway interworking
The provisioning tasks required for the MCP to interwork with
third-party gateways are described in detail in the Gateways chapter of
the MCP SIP Provisioning Client User Guide document.
Configuring traditional phone interworking
Provisioning tasks to configure the MCP to interwork with traditional
phones must be made on both the MCP side and the exis ting switching
system.
MCP configuration
The provisioning tasks to configure an MCP user as a CDS user are
described in detail in the User Management chapter of the MCP SIP Provisioning Client User Guide document.
Switching system configuration
This section describes the steps to configure and activate the SimRing
feature on the Nortel Networks DMS family of TDM switches. Please
refer to feature document AJ4934 Simultaneous Ringing for more
information about the functionality provided by SimRing.
Nortel Networks Confidential
For specific inform ation on en abling the S imRing equi valent featur e on
third-party switches, please refer to the documentation provided by that
third-party vendor.
Successful interworking between the MCP and the TDM switch
requires that the TDM switch activate the SimRing (or equivalent)
feature and assign each CDS user a SimRing number . The SimRing (or
equivalent) featur e sen ds “Si m Rin g” calls to t he ro utable and unique
number for each CDS user.
Figure 6 shows the c onceptual steps required for provisioning the
SimRing (or its equivalent) feature on a TDM switch.
---------------- LEN: HOST 00 1 10 05
TYPE: SINGLE PARTY LINE
SNPA: 613
DIRECTORY NUMBER: 6212064
LINE CLASS CODE: IBN
IBN TYPE: STATION
CUSTGRP: IBNTST SUBGRP: 0 NCOS: 0
SIGNALLING TYPE: DIGITONE
CARDCODE: 6X17AA GND: N PADGRP: STDLN BNV: NL MNO: N
PM NODE NUMBER : 41
PM TERMINAL NUMBER : 326
OPTIONS:
DGT SIMRING 0 ACT $
OFFICE OPTIONS:
AIN LNPOFFICE
Nortel Networks Confidential
SimRing has its own c ommand for viewing its properties. Use the
command QSIMR (query SimRing) on a DN to display the set-up of
SimRing on the line:
Configuring third-party voicemail ser ver interworking
The tasks required to configure the MCP for interworking with a
voicemail server can vary, depending on the type of voicemail server.
The MCP can be configured to interwork with the following types of
voicemail servers:
•SIP-based
•trunk-based
•line-based
The provisioning tasks required for the MCP to interwork with each type
of the above voicema il server s are descri bed in det ail i n the Voice Mail
Servers chapter of the MCP SIP Provisioning Client User Guide
document.
For more information about accounting functionality on a specific MCP
network node, please refer to the Accounting chapter in the
corresponding documents:
•MCP SIP Application Module Basics
•MCP SIP PRI Gateway Basics
The MCP provides both the public and private charge IDs to the SIP
PRI Gateway. For information on configuring the charge IDs for a user,
please refer to th e MCP SIP Provisioning Client User Guide. For more
information on how the charge IDs are used, please refer to the MCP Accounting Module Basics document.
For information ab out CS 2000 accoun ting functional ity , pl ease refer to
the CS 2000 Accounting document.
For information about accounting functionality on any third-party
gateway or voicemail server, please refer to the documentation
provided by th at third-party vendor.
For more informati on about perf ormance ma nagement func tionality on
a specific MCP net w ork node, please refer to the Perfo rmance
Management chapter in the corresponding documents:
•MCP SIP Application Module Basics
•MCP SIP PRI Gateway Basics
For information ab out CS 2000 performance mana gement functionality ,
please refer to the CS 2000 Performance Manageme nt document.
For information about performance management fu nctionality on any
third-party gateway or voicemail server, please refer to the
documentation provided by that third-party vendor.
For more informa tion about secur ity and admin istration functi onality on
a specific MCP network node, please refer to the Security and
Administration chapter in the corresponding documents:
•MCP SIP Application Module Basics
•MCP SIP PRI Gateway Basics
For information about CS 2000 security and administration
functional ity, please refer to the CS 2000 Security and Administration
document.
For information about security and administration functionality on any
third-party gateway or voicemail server, please refer to the
documentation provided by that third-party vendor.
NORTEL NETWORKS CONFIDENTIAL: The information contained in this document is the
property of Nortel Networks. Except as specifically authorized in writing by Nortel Networks, the holder of
this document shall keep the information contained herein confidential and shall protect same in whole or in
part from disclosure and dissemination to third parties and use same for evaluation, operation, and maintenance purposes only. Changes or modifi cations to the MCP Interworking Basics document without the
express consent of Nortel Networks may void its warranty and void the user’s authority to operate the equipment.
Information is subject to change without notice. Nortel Networks reserves the right to make changes in
design or components as progress in engineering and manufacturing may warrant.
*Nortel Networks, the Nortel Networks logo, the Globemark, UNIStim, MCP, Nortel, Northern Telecom, and
NT, are trademarks of Nortel Networks.
Publication number: NN10033-111
Product release: MCP 1.1 FP1 Standard
Document release: Standard MCP 1.1 FP1 (02.02)
Date: April 2003
Printed in the United States of America.
Loading...
+ hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.