Configuring TDM Trunks On Avaya Aura™ Communication Manager Feature Server Release 5.2.1 - Issue 1.0

Avaya Solution & Interoperability Test Lab
Configuring TDM Trunks on Avaya Aura Communication Manager Feature Server Release 5.2.1 Issue 1.0
Abstract
These Application Notes describe the procedures for configuring TDM trunks on Avaya Aura Communication Manager Feature Server. In the configuration described herein, IP Multimedia Services (IMS) SIP telephones, that are registered to Avaya Aura Session Manager, are assigned to the Avaya Aura Communication Manager Feature Server for both originating and terminating feature processing in support of the half-call model. For bidirectional PSTN calling, Avaya Aura Session Manager can route calls from IMS-SIP users to the PSTN via TDM trunk resources that are accessible on Avaya Aura Communication Manager. Note that only IMS-SIP telephones are supported in this configuration. Capabilities that were verified and system constraints are documented in Section 1.1. Avaya Aura Session Manager 5.2 is a core SIP routing and integration engine that connects disparate SIP devices and applications within an enterprise and is also used here as a SIP Registrar and Location server for IMS-SIP telephones. Avaya Aura Communication Manager is a telephony application server used here to provide IMS-SIP users both feature server processing as well as access to the PSTN over traditional trunks.
VV; Reviewed: SPOC 04/08/2010
Solution & Interoperability Test Lab Application Notes 2010 Avaya Inc. All Rights Reserved.
1 of 38 SM52_TDMTRK_FS
1. Introduction
Avaya Aura Communication Manager Feature Server can be configured with TDM trunks. In the configuration described herein, IP Multimedia Services (IMS) SIP telephones, that are registered to Avaya Aura Session Manager1, are assigned to the Avaya Aura Communication Manager Feature Server for both originating and terminating call processing in support of the half-call model2. In addition, for bi-directional PSTN calling, Avaya Aura Session Manager can route calls from IMS-SIP users to the PSTN via trunk resources that are accessible through the same Avaya Aura Communication Manager Feature Server. These Application Notes provide details on how to configure TDM trunks on Avaya Aura Communication Manager Feature Server.
1.1. Capabilities Verified and System Constraints

Bi-directional point-to-point calls from IMS-SIP telephones to the PSTN were successfully verified. Transfers and conference calls initiated by IMS-SIP telephones including PSTN destinations were also performed successfully3. There are two types of SIP signaling connections from Avaya Aura Communication Manager to Avaya Aura Session Manager. IMS-enabled signaling connections are used for originating feature processing, terminating feature processing and half-call model support. Non-IMS signaling connections are used to access the TDM trunks. Avaya Aura Communication Manager must route all inbound4 PSTN calls to Avaya Aura Session Manager over non-IMS signaling connections. Similarly, outbound PSTN calls must be routed by Avaya Aura Session Manager to Avaya Aura Communication Manager over non-IMS signaling connections. All call routing on Avaya Aura Communication Manager must be designed and implemented to ensure this separation.
Reference [14] describes how to configure 9600-Series SIP telephones as IMS-SIP telephones on Avaya Aura Session Manager Release 5.2. 2 Reference [4] offers more information on the half call model as well as using Avaya Aura Communication Manager Feature Server with TDM trunks. 3 The call flows described herein were used to verify basic calling. For an exhaustive list of supported call-related features see Reference [13]. 4 Inbound and outbound as used here are from the perspective of the IMS-SIP telephone/user. VV; Reviewed: SPOC 04/08/2010 Solution & Interoperability Test Lab Application Notes 2010 Avaya Inc. All Rights Reserved. 2 of 38 SM52_TDMTRK_FS
2. Reference Configuration
The reference configuration described throughout these Application Notes is shown in Figure 1. Note: These Application Notes describe one possible approach for configuring bi-directional call routing from IMS-SIP telephones to the PSTN. While the call flows described in this section and the supporting routing configuration described in Sections 4 and 5 are U.S.-centric, they may be adapted as necessary to meet in-country specific routing needs.
Figure 1: Reference Configuration
2.1. Avaya Aura Session Manager

Session Manager provides core SIP routing and integration services that enables communications between disparate SIP-enabled entities, e.g., PBXs, SIP proxies, gateways, adjuncts, trunks, applications, etc., across the enterprise using centralized and policy-based routing. Configuration of Session Manager is performed from Avaya Aura System Manager. In the reference configuration, Session Manager also serves as a SIP Registrar & Location server for IMS-SIP telephones such as the Avaya one-X 9600-Series SIP Telephones. Session Manager accesses the Feature Server for originating and terminating feature processing. Both IMSenabled and non-IMS SIP trunks are programmed between Session Manager and Communication Manager.
2.2. Avaya Aura Communication Manager Feature Server

In the reference configuration, Communication Manager runs on the Avaya S8800 Server and is used as a Feature Server. An IMS-enabled SIP signaling group and associated trunk group are assigned in support of this role. All IMS-SIP telephones are assigned to the Feature Server for both originating and terminating features5.
2.3. TDM Trunks on Avaya Aura Communication Manager

In the reference configuration, Communication Manager runs on the Avaya S8800 server as the Feature Server and provides access to TDM trunks. The Avaya G430 Media Gateway6 provides the physical trunk interfaces and resources for Communication Manager. An ISDN/PRI trunk terminates on the G430 Media Gateway and provides inbound and outbound voice call access to the PSTN. In addition, a non-IMS SIP signaling group and associated trunk group are assigned between Communication Manager and Session Manager.
2.4. Call Flows

These Application Notes describe one possible approach to configuring PSTN inbound and outbound call routing. As mentioned in Section 1.1, all programming must ensure that, within Communication Manager, calls that are processed using IMS-enabled trunks remain separate from calls that are processed using non-IMS trunks. While IMS to IMS call traffic and non-IMS to non-IMS call traffic is allowed, routing IMS call traffic directly to non-IMS destinations is not supported.
While it is possible to use separate Feature Servers for each IMS-SIP user in a call flow, the same Feature Server was used to provide both originating and terminating feature processing for the IMS-SIP users in the reference configuration. 6 This solution is extensible to the Avaya G450 Media Gateway. VV; Reviewed: SPOC 04/08/2010 Solution & Interoperability Test Lab Application Notes 2010 Avaya Inc. All Rights Reserved. 4 of 38 SM52_TDMTRK_FS
Figure 2 provides a call flow diagram for an outbound call from an IMS-SIP telephone to a PSTN telephone. When a telephone number is dialed by an IMS-SIP telephone user (Call Leg 1), Session Manager first engages the users assigned Feature Server over the IMS-enabled SIP signaling/trunk group in order to do originating feature processing (Call Leg 2).7 The Feature Server then delivers the call back to Session Manager over the IMS-enabled SIP signaling/trunk group (Call Leg 3)8. Based on the called party number and originating location information, Session Manager looks up the corresponding routing policy9 and then routes the call to Communication Manager over the non-IMS SIP signaling/trunk group (Call Leg 4), which in turn routes the call to the PSTN (Call Legs 5 and 6). The SIP Invite from Session Manager towards the Communication Manager (Call Leg 4) may also contain the calling party name and number information. As shown in Section 5.4 Step 1, on Communication Manager, the Calling Party Number Conversion For Tandem Calls table can be configured to manipulate the calling party number prior to delivery to the PSTN, if desired.
Figure 2: Outbound Call Flow
While not shown here, Avaya IMS SIP telephones send two SIP Invite messages: one for the off-hook event and another with the dialed number. 8 In the reference configuration, Call Legs 2 and 3 utilize the same IMS-enabled SIP signaling/trunk group configured on the Feature Server. 9 Session Manager adaptations can also be applied, if desired. VV; Reviewed: SPOC 04/08/2010 Solution & Interoperability Test Lab Application Notes 2010 Avaya Inc. All Rights Reserved. 5 of 38 SM52_TDMTRK_FS
Figure 3 provides a call flow diagram for inbound calls from a PSTN telephone to an IMS-SIP telephone. For inbound calls from the PSTN to IMS-SIP users, Communication Manager receives the incoming call (Call Legs 1 and 2) and routes the call to Session Manager over the non-IMS signaling/trunk group (Call Leg 3). Based on the called party number, Session Manager determines that the requested party is a locally registered IMS-SIP user and engages the users assigned Feature Server over the IMS-enabled SIP signaling/trunk group in order to do terminating feature processing (Call Leg 4).10 The Feature Server delivers the call back to Session Manager (Call Leg 5)11 for termination to the IMS-SIP telephone user (Call Leg 6). The SIP Invite from Communication Manager towards Session Manager (Call Leg 3) may also contain the calling party name and number information. If received from the PSTN, this information is forwarded for display on the IMS-SIP telephone.
Figure 3: Inbound Call Flow
10
Since the SIP users are registered on Session Manager, a routing policy does not need to be defined for the Communication Manager Feature Server. 11 In the reference configuration, Call Legs 4 and 5 utilize the same IMS-enabled SIP signaling/trunk group configured on the Feature Server. VV; Reviewed: SPOC 04/08/2010 Solution & Interoperability Test Lab Application Notes 2010 Avaya Inc. All Rights Reserved. 6 of 38 SM52_TDMTRK_FS
3. Equipment and Software Validated

The following equipment and software were used for the reference configuration provided: Equipment & Software Avaya S8800 Server Version Avaya Aura Communication Manager 5.2.1 (R015x.02.1.016.4) with SP1 (17959) 30.11.3 5.2.1.1.521012 01-14-2010 5.2.0.8.27 2.5
Avaya G430 Media Gateway Avaya Aura Session Manager Avaya Aura System Manager Avaya one-X Deskphone Edition 9620 SIP Telephone
Table 1: Equipment/Software List
4. Configuring Avaya Aura Session Manager

These Application Notes assume that basic System Manager and Session Manager administration has already been performed, and that basic integration with Communication Manager has already been implemented according to References [1-13]. It is also assumed that IMS-SIP telephones are registered with Session Manager and are able to place extension-toextension calls per Reference [14]. The following steps will focus on the Network Routing Policy necessary to route bi-directional calls from IMS-SIP telephones to the PSTN. Configuration of Session Manager is performed from System Manager. To invoke the System Manager Common Console, launch a web browser, enter https://<IP address of the System Manager server>/SMGR in the URL, and log in with the appropriate credentials.
4.1. Background
Session Manager serves as a central point for supporting SIP-based communication services in an enterprise. The various SIP network components are represented as SIP Entities and the connections/trunks between Session Manager and those components are represented as Entity Links. Thus, rather than connecting to every other SIP Entity in the enterprise, each SIP Entity simply connects to Session Manager and relies on Session Manager to route calls to the correct destination. This approach reduces the dial plan and trunking administration needed on each SIP Entity, and consolidates said administration in a central place, namely System Manager. When calls arrive at Session Manager from a SIP Entity, Session Manager applies SIP protocol and numbering modifications to the calls. These modifications, referred to as Adaptations12, are sometimes necessary to resolve SIP protocol differences between disparate SIP Entities, and also serve the purpose of normalizing the calls to a common or uniform numbering format, which allows for simpler administration of routing rules in Session Manager. Session Manager then matches the calls against certain criteria embodied in profiles termed Dial Patterns, and determines the destination SIP Entities based on Routing Policies specified in the matching
12
Adaptations were not required in the reference configuration. Solution & Interoperability Test Lab Application Notes 2010 Avaya Inc. All Rights Reserved. 7 of 38 SM52_TDMTRK_FS
Dial Patterns. Lastly, before the calls are routed to the respective destinations, Session Manager again applies Adaptations in order to bring the calls into conformance with the SIP protocol interpretation and numbering formats expected by the destination SIP Entities.
4.2. Network Routing Policies (NRP)

Network Routing Policies define how Session Manager routes calls between SIP network elements. A Network Routing Policy is dependent on the administration of several inter-related items including: SIP Domains SIP Domains are the domains for which Session Manager is authoritative in routing SIP calls. In other words, for calls to such domains, Session Manager applies Network Routing Policies to route those calls to SIP Entities. For calls to other domains, Session Manager routes those calls to another SIP proxy (either a pre-defined default SIP proxy or one discovered through DNS). Locations Locations define the physical and/or logical locations in which SIP Entities reside. Call Admission Control (CAC) / bandwidth management may be administered for each location to limit the number of calls to and from a particular Location. Adaptations Adaptations are used to apply any necessary protocol adaptations, e.g., modify SIP headers, and apply any necessary digit conversions for the purpose of interworking with specific SIP Entities. SIP Entities SIP Entities represent SIP network elements such as Session Manager instances, Communication Manager systems, Session Border Controllers, SIP gateways, SIP trunks, and other SIP network devices. Entity Links Entity Links define the SIP trunk/link parameters, e.g., ports, protocol (UDP/TCP/TLS), and trust relationship, between Session Manager instances and other SIP Entities. Time Ranges Time Ranges specify customizable time periods, e.g., Monday through Friday from 9AM to 5:59PM, Monday through Friday 6PM to 8:59AM, all day Saturday and Sunday, etc. A Network Routing Policy may be associated with one or more Time Ranges during which the Network Routing Policy is in effect. For example, for a Dial Pattern administered with two Network Routing Policies, one Network Routing Policy can be in effect on weekday business hours and the other Network Routing Policy can be in effect on weekday off-hours and weekends. In the reference configuration no restrictions were placed on calling times. Routing Policies Routing policies identify the SIP Entity to which calls should be routed as well as the applicable Time of Day range. Dial Patterns A Dial Pattern specifies a set of criteria and a set of Routing Policies for routing calls that match the criteria. The criteria include the called party number and SIP domain in the Request-URI, and the Location from which the call originated. For example, if a call arrives at Session Manager and matches a certain Dial Pattern, then Session Manager selects one13 of the Routing Policies specified in the Dial Pattern. The selected Routing Policy in turn specifies the SIP Entity to which the call is to be routed. Note that Dial Patterns are matched after ingress Adaptations have already been applied.
13
The Network Routing Policy in effect at that time with the highest ranking is attempted first. If that Network Routing Policy fails, then the Network Routing Policy with the next highest ranking is attempted, and so on. VV; Reviewed: SPOC 04/08/2010 Solution & Interoperability Test Lab Application Notes 2010 Avaya Inc. All Rights Reserved. 8 of 38 SM52_TDMTRK_FS
To view the sequenced steps required for configuring network routing policies, click on Network Routing Policy (NRP) in the left pane of the System Manager Common Console (see Figure 4).
Figure 4: Introduction to Network Routing Policy (NRP) Page
Step Description 1. Verify the name of the existing SIP Domain. Select Network Routing Policy SIP Domains. Note the SIP domain name in the Name column. In the reference configuration, the name of the SIP domain was avaya.com.
Step Description 2. Verify the name of the existing Location. Select Network Routing Policy Locations. In the reference configuration, AAA.BBB.CC.*14 was entered in the IP Address Pattern field. This address pattern was associated with the Communication Manager and Session Manager servers. In the reference configuration, the name of the location was Location 1.
14
All actual IP addresses and telephone numbers have been removed from these Application Notes for security reasons. VV; Reviewed: SPOC 04/08/2010 Solution & Interoperability Test Lab Application Notes 2010 Avaya Inc. All Rights Reserved. 11 of 38 SM52_TDMTRK_FS
Step Description 3. Verify that the SIP Domain from Step 1 is assigned to two TCP/IP Ports on the Session Manager. Two distinct ports must be assigned in order to separate IMS and non-IMS traffic. In the reference configuration, port 5060 was used for IMS traffic with the Feature Server. Port 5070 was used for non-IMS traffic. Session Manager used avaya.com as the default SIP domain for SIP TCP messages received on both ports 5060 and 5070. Select Network Routing Policy SIP Entities. Select the entity associated with the existing Session Manager (SIP Entity SM1) and verify the port definitions. Under the Port section, click Add. When the new Port line appears, enter 5070 in the Port field, select TCP15 for the Protocol field, select avaya.com from the Default Domain drop-down menu, and enter any optional notes in the Notes field. It is assumed that port 5060 with protocol TCP is pre-existing. Note that this screenshot also shows a pre-existing Entity Link from Session Manager (SIP Entity SM1) to Communication Manager (SIP Entity Feature Server). Click Commit.
15
TCP protocol was used in the reference configuration. However, secure connections using TLS protocol may also be used throughout the configuration on both the Session Manager and the Feature Server. VV; Reviewed: SPOC 04/08/2010 Solution & Interoperability Test Lab Application Notes 2010 Avaya Inc. All Rights Reserved. 12 of 38 SM52_TDMTRK_FS
Step Description 4. Create a new SIP Entity. Select Network Routing Policy SIP Entities. Click New and enter an appropriate name in the Name field, such as Trunk Gateway and enter the FQDN or IP address of the Communication Manager. Note that, in the reference configuration, this FQDN or IP address is the same as the FQDN or IP address of the Feature Server. Select CM from the Type: drop-down menu, enter optional notes in the Notes field, select Location 1 from the Location drop-down menu, and select an appropriate time zone from the Time Zone: drop-down menu. Under SIP Link Monitoring, select Link Monitoring Enabled from the SIP Link Monitoring drop-down menu. The rest of the values can be left at their default values. Click Commit.
Step Description 5. Create a new Entity Link between the Session Manager and the SIP Entity created in Step 4. Select Network Routing Policy Entity Links. Click New and enter an appropriate name in the Name field, such as SM1_Trunk Gateway_5070_TCP, for SIP Entity 1, select the existing Session Manager as SIP Entity 1, for Protocol select TCP, and for Port enter 5070. For SIP Entity 2, select Trunk Gateway and for Port enter 5070. As described in Step 3 above, in the reference configuration, port 5060 was used for IMS traffic with the Feature Server. Port 5070 was used for non-IMS traffic. Check the Trusted checkbox. Click Commit.
Step Description 6. Verify that an existing Entity Link has been programmed between the Session Manager and the Feature Server. Select Network Routing Policy Entity Links. In the reference configuration, the Entity Link was named FS-Link as shown below. Note that SIP Entity 1 was set to the existing Session Manager (SIP Entity SM1), the selected Protocol was TCP, and the Port was set to 5060. For SIP Entity 2, the existing Feature Server (SIP Entity Feature Server) was selected and the Port was 5060. In addition, the Trusted checkbox was marked.
Step Description 7. Verify that a valid Time Range exists. Select Network Routing Policy Time Ranges. In the reference configuration, the name of the time range was 24/7. Note that this time range has all days of the week checked and a Start Time of 00:00 and an End Time of 23:59.
Step Description 8. Create a new Routing Policy to route calls to the Trunk Gateway. Select Network Routing Policy Routing Policies. Click New and enter an appropriate name in the Name field, such as to Trunk Gateway, leave the Disabled: field unchecked, and enter any optional notes in the Notes field. Then, under SIP Entity as Destination, click Select. Click the radio button next to Trunk Gateway and click Select (not shown). Under Time of Day, select the 24/7 time range. Click Commit.
Step Description 9. Create a new Dial Pattern to capture dialed numbers that have a + as the first digit and route the calls to the Trunk Gateway. The + in the called number field will be inserted by the route pattern defined in Section 5.5.1 Step 3. This Dial Pattern will capture the dialed number of the call arriving on Call Leg 3 of Figure 2 and then route the call to the Trunk Gateway via the nonIMS signaling/trunk group as shown in Call Leg 4 of Figure 2. Select Network Routing Policy Dial Patterns. Click New and enter + in the Pattern: field, 1 in the Min field, and 36 in the Max field. Select avaya.com from the SIP Domain: drop-down menu, and enter optional notes in the Notes field. Then, under Originating Locations and Routing Policies, click Add. Under Originating Location, select Location 1 (not shown). Under Routing Policies, select to Trunk Gateway and click Select (not shown). Click Commit.
Step Description 10. Click Commit to distribute changes to the Session Manager system.
5. Configuring Avaya Aura Communication Manager

This section describes the steps for configuring call routing on Communication Manager. The steps are performed from the Communication Manager System Access Terminal (SAT) interface. The following steps will focus on the configuration necessary to route bi-directional calls from IMS-SIP telephones to the PSTN. These Application Notes assume that basic Communication Manager administration has already been performed, and that basic integration with Session Manager has already been implemented. See References [1-13].
5.1. System Parameters

This section reviews the additional licenses and features that are required to access the TDM trunks on the Communication Manager Feature Server as discussed in these Application Notes. For required licenses that are not enabled in the system-parameters customer-options form discussed below, contact an authorized Avaya account representative to obtain the licenses. Step Description 1. Enter the display system-parameters customer-options command. On Page 2 of the system-parameters customer-options form, verify that the Maximum Administered SIP Trunks number has not been reached.
display system-parameters customer-options OPTIONAL FEATURES IP PORT CAPACITIES Maximum Administered H.323 Trunks: Maximum Concurrently Registered IP Stations: Maximum Administered Remote Office Trunks: Maximum Concurrently Registered Remote Office Stations: Maximum Concurrently Registered IP eCons: Max Concur Registered Unauthenticated H.323 Stations: Maximum Video Capable H.323 Stations: Maximum Video Capable IP Softphones: Maximum Administered SIP Trunks: Maximum Administered Ad-hoc Video Conferencing Ports: Maximum Number of DS1 Boards with Echo Cancellation: Maximum TN2501 VAL Boards: Maximum Media Gateway VAL Sources: Maximum TN2602 Boards with 80 VoIP Channels: Maximum TN2602 Boards with 320 VoIP Channels: Maximum Number of Expanded Meet-me Conference Ports: 0 18000 0 0 0 0 0 0 100 0 0 10 0 128 128 0 Page 2 of 10
USED 0 0 0 0 0 0 0 0 20 0 0 0 0 0 0 0
(NOTE: You must logoff & login to effect the permission changes.)
Step Description 2. On Page 3 of the system-parameters customer-options form, verify that the ARS feature is enabled as shown below.
display system-parameters customer-options OPTIONAL FEATURES Abbreviated Dialing Enhanced List? Access Security Gateway (ASG)? Analog Trunk Incoming Call ID? A/D Grp/Sys List Dialing Start at 01? Answer Supervision by Call Classifier? ARS? ARS/AAR Partitioning? ARS/AAR Dialing without FAC? ASAI Link Core Capabilities? ASAI Link Plus Capabilities? Async. Transfer Mode (ATM) PNC? Async. Transfer Mode (ATM) Trunking? ATM WAN Spare Processor? ATMS? Attendant Vectoring? n n n n n y y y n n n n n n n Page 3 of 10
Audible Message Waiting? Authorization Codes? CAS Branch? CAS Main? Change COR by FAC? Computer Telephony Adjunct Links? Cvg Of Calls Redirected Off-net? DCS (Basic)? DCS Call Coverage? DCS with Rerouting?
n n n n n n n n n n
Digital Loss Plan Modification? n DS1 MSP? n DS1 Echo Cancellation? n
3.
On Page 5 of the system-parameters customer-options form, verify that the Private Networking feature is enabled as shown below.
display system-parameters customer-options OPTIONAL FEATURES Multinational Locations? n Multiple Level Precedence & Preemption? n Multiple Locations? n Personal Station Access (PSA)? PNC Duplication? Port Network Support? Posted Messages? n n y n Page 5 of 10
Station and Trunk MSP? n Station as Virtual Extension? n System Management Data Transfer? Tenant Partitioning? Terminal Trans. Init. (TTI)? Time of Day Routing? TN2501 VAL Maximum Capacity? Uniform Dialing Plan? Usage Allocation Enhancements? n n n n y n y
Private Networking? y Processor and System MSP? n Processor Ethernet? y Remote Office? n Restrict Call Forward Off Net? y Secondary Data Module? y
Wideband Switching? n Wireless? n
5.2. Dial Plan

This section describes dial plan settings for the reference configuration described in these Application Notes. Step Description 1. Enter the change dialplan analysis command. Verify that an ext entry exists for use by extensions assigned to IMS-SIP telephones. In the reference configuration, IMS-SIP telephones were assigned 7-digit extension numbers in the range 555xxxx where x can be any digit from 0 through 9. Verify that an fac entry exists for use by the Automatic Alternate Route and Automatic Route Selection (ARS) features. If not, add the entries as shown. Note: In the example below, the Dialed String entry 8 of Total Length 1 and of Call Type fac and the Dialed String entry 9 of Total Length 1 and of Call Type fac are reserved for use as feature access codes.
change dialplan analysis DIAL PLAN ANALYSIS TABLE Location: all Dialed String 0 5 8 9 * * # Total Length 1 7 1 1 3 4 3 Call Type attd ext fac fac fac dac fac Dialed String Total Call Length Type Page 1 of 12 1
Percent Full: Dialed String Total Call Length Type
Step Description 2. Enter the change feature-access-codes command. Verify the fields Auto Alternate Routing (AAR) Access Code and the Auto Route Selection (ARS) - Access Code 1 are defined. Note that complete programming of the Automatic Alternate Routing and Automatic Route Selection features is out of the scope of these Application Notes and is covered in standard user documentation. Note: In the example below, 8 was assigned as the feature access code for Automatic Alternate Routing and 9 was assigned as the feature access code for Automatic Route Selection Access Code 1.
change feature-access-codes FEATURE ACCESS CODE (FAC) Abbreviated Dialing List1 Access Code: Abbreviated Dialing List2 Access Code: Abbreviated Dialing List3 Access Code: Abbreviated Dial - Prgm Group List Access Code: Announcement Access Code: Answer Back Access Code: Auto Alternate Routing (AAR) Access Code: 8 Auto Route Selection (ARS) - Access Code 1: 9 Automatic Callback Activation: Call Forwarding Activation Busy/DA: All: Call Forwarding Enhanced Status: Act: Call Park Access Code: Call Pickup Access Code: CAS Remote Hold/Answer Hold-Unhold Access Code: CDR Account Code Access Code: Change COR Access Code: Change Coverage Access Code: Conditional Call Extend Activation: Contact Closure Open Code: Page 1 of 6
Access Code 2: Deactivation: Deactivation: Deactivation:
Deactivation: Close Code:
5.3. non-IMS Signaling/Trunk Group on the Feature Server

This section describes the configuration steps required on Communication Manager to create a non-IMS signaling/trunk group on the Feature Server. Step Description 1. Create a new signaling group to handle non-IMS traffic. Enter the add signaling-group s command, where s is an unused signaling group number. Set the Group Type: field to sip and the Transport Method: field to tcp. Note that this signaling group has the IMS Enabled? field set to n. Enter procr in the Near-end Node-Name field, 5070 in the Near-end Listen Port field, and in the Far-end Domain: field enter the SIP domain that was identified in Section 4.2 Step 1. In the reference configuration, avaya.com was used in the Far-end Domain: field. The Far-end Network Region was set to 1. Check with your system administrator to identify the pre-existing Far-end Node Name for the Session Manager. The Far-end Node Name should correspond to the Session Managers SM100 network interface. The mapping of the node name to an IP address is performed using the change node-names ip command (not shown). In addition, the Far-end Listen Port should correspond to the TCP/IP port number assigned to SIP Entity 1 (SIP Entity SM1) when creating the Entity Link in Section 4.2 Step 5. Communication Manager will send SIP Invites to this port number. In the reference configuration, 5070 was used. To enable audio shuffling support, set the Direct IP-IP Audio Connections field to y. The remaining values may be left at their defaults.
add signaling-group 2 SIGNALING GROUP Group Number: 2 IMS Enabled? n Group Type: sip Transport Method: tcp
Near-end Node Name: procr Near-end Listen Port: 5070 Far-end Domain: avaya.com
Far-end Node Name: SM1 Far-end Listen Port: 5070 Far-end Network Region: 1
Incoming Dialog Loopbacks: allow DTMF over IP: rtp-payload Session Establishment Timer(min): 3 Enable Layer 3 Test? n H.323 Station Outgoing Direct Media? n
Bypass If IP Threshold Exceeded? RFC 3389 Comfort Noise? Direct IP-IP Audio Connections? IP Audio Hairpinning? Direct IP-IP Early Media? Alternate Route Timer(sec):
n n y n n 6
Step Description 2. Enter the add trunk-group t command, where t is an unused trunk group number. On Page 1 of the trunk group form, set the values as shown below. In the reference configuration, the Direction: field was set to two-way. Set the Service Type: field to tie. The Signaling Group: field should be set to the signaling group number configured in Step 1. 10 was used in the Number of Members field. The remaining values may be left at their defaults.
add trunk-group 2 TRUNK GROUP Group Number: Group Name: Direction: Dial Access? Queue Length: Service Type: 2 Group Type: SM1 Trunk Gateway COR: two-way Outgoing Display? n 0 tie Auth Code? sip CDR Reports: y 1 TN: 1 TAC: *102 n Night Service: n Signaling Group: 2 Number of Members: 10 Page 1 of 21
3.
In the reference configuration, the Far-End Network Region: for the signaling group in Step 1 above was set to a value of 1. For calls arriving to Communication Manager from IP Network Region 1, Communication Manager examines the Authoritative Domain: field of the IP network region associated with the final destination of the call. If the SIP Invite request-URI domain matches the Authoritative Domain: specified in the ipnetwork-region form, Communication Manager will accept the call. Enter the change ipnetwork-region 1 command and set the Authoritative Domain: field to avaya.com.
change ip-network-region 1 IP NETWORK REGION Region: 1 Location: 1 Authoritative Domain: avaya.com Name: MEDIA PARAMETERS Intra-region IP-IP Direct Audio: yes Codec Set: 1 Inter-region IP-IP Direct Audio: yes UDP Port Min: 2048 IP Audio Hairpinning? n UDP Port Max: 3329 DIFFSERV/TOS PARAMETERS RTCP Reporting Enabled? y Call Control PHB Value: 46 RTCP MONITOR SERVER PARAMETERS Audio PHB Value: 46 Use Default Server Parameters? y Video PHB Value: 26 802.1P/Q PARAMETERS Call Control 802.1p Priority: 6 Audio 802.1p Priority: 6 Video 802.1p Priority: 5 AUDIO RESOURCE RESERVATION PARAMETERS H.323 IP ENDPOINTS RSVP Enabled? n H.323 Link Bounce Recovery? y Idle Traffic Interval (sec): 20 Keep-Alive Interval (sec): 5 Keep-Alive Count: 5 Page 1 of 19
5.4. Calling Party Number

As discussed in Section 2.4, calls from IMS-SIP telephones may contain calling party name and number information.16 The Calling Party Number Conversion For Tandem Calls table can be used to manipulate the calling party number prior to delivery to the PSTN. In the reference configuration, IMS-SIP telephones were assigned 7-digit extensions in the range of 555xxxx. The Calling Party Number Conversion For Tandem Calls table was used to generate a 10digit calling party number for outbound calls. Step Description 1. Enter the change tandem-calling-party-num command. Add an entry as follows: Len enter the number of calling party number digits arriving on Call Leg 4 of Figure 2. In this case, enter 7. CPN Prefix enter 555. Trk Grp (s) - enter the trunk group number that routes calls out to the PSTN or leave blank to apply this entry to all ISDN trunk groups. This should be a pre-existing trunk group as defined by your local system administrator. In the reference configuration, the ISDN/PRI trunk facility is assigned to trunk group number 10. If the Calling Party Number Conversion For Tandem Calls table is used to modify the calling party number, verify that the field Modify Tandem Calling Number is set to y on the trunk group form associated with the trunk group that routes calls out to the PSTN. Delete enter the number of digits to be deleted from the calling party number. In this case, no digits are deleted. Insert enter the leading digits to be prefixed to the calling party number. In this case, enter 73217. Number Format natl-pub was used in the reference configuration.
change tandem-calling-party-num CALLING PARTY NUMBER CONVERSION FOR TANDEM CALLS CPN Trk Len Prefix Grp(s) Delete Insert 7 555 732 Page 1 of 8
Number Format natl-pub
16
Calling party number information can be blocked at the trunk group level, by using the Per Call CPN Blocking Code Access Code or by assigning a cpn-blk button on the originating telephone. See Reference [9]. 17 Note that this will result in a 10-digit calling party number of 732-555-xxxx where xxxx are that last four digits of the extension assigned to the calling IMS-SIP telephone. VV; Reviewed: SPOC 04/08/2010 Solution & Interoperability Test Lab Application Notes 2010 Avaya Inc. All Rights Reserved. 26 of 38 SM52_TDMTRK_FS
5.5. Routing IMS-SIP calls to the PSTN (Outbound Call)

This section describes the configuration steps on Communication Manager for routing calls from IMS-SIP telephones to the PSTN. As shown in Figure 2, the initial call processing must result in delivering these calls back to Session Manager over the IMS trunk (Call Legs 2 and 3). Communication Manager then receives these calls from Session Manager as inbound calls over a non-IMS trunk and routes them as outbound calls to the PSTN (Call Legs 4 and 5).
5.5.1. Initial Call Processing through the IMS Signaling/Trunk Group

In the reference configuration, IMS-SIP telephone users can dial outbound calls to the PSTN by first dialing the ARS feature access code of 9, followed by either an 11-digit called party number such as 1XXXYYYZZZZ or an international18 called party number such as 011CCNDCSN19. An ARS entry allows Communication Manager to capture the dialed digits and route the call back to Session Manager.
18
All PSTN dialing, including international numbers, must follow the same initial call processing constraints of routing back to Session Manager over the IMS signaling/trunk group. 19 See Reference [15] for the international public telecommunication numbering plan. VV; Reviewed: SPOC 04/08/2010 Solution & Interoperability Test Lab Application Notes 2010 Avaya Inc. All Rights Reserved. 27 of 38 SM52_TDMTRK_FS
Step Description 1. Verify the pre-existing IMS-enabled signaling group used for Feature Server processing using the display signaling-group s command, where s is the number of the pre-existing IMS-enabled signaling group. In the reference configuration, signaling group 1 was used. Note that this signaling group has the IMS Enabled? field set to y. The Far-end Node Name should correspond to the Session Managers SM100 network interface. In addition, the Far-end Listen Port should correspond to the TCP/IP port number assigned to SIP Entity 1 (SIP Entity SM1) when verifying the Entity Link in Section 4.2 Step 6. Communication Manager Feature Server will send SIP Invites back to Session Manager on this port number. In the reference configuration, 5060 was used in the Far-end Listen Port field and avaya.com was used in the Far-end Domain: field. To enable audio shuffling support, set the Direct IP-IP Audio Connections field to y. The remaining values may be left at their defaults.
display signaling-group 1 SIGNALING GROUP Group Number: 1 IMS Enabled? y Group Type: sip Transport Method: tcp
Near-end Node Name: procr Near-end Listen Port: 5060 Far-end Domain: avaya.com
Far-end Node Name: SM1 Far-end Listen Port: 5060 Far-end Network Region: 1
Incoming Dialog Loopbacks: allow DTMF over IP: rtp-payload Session Establishment Timer(min): 3 Enable Layer 3 Test? n H.323 Station Outgoing Direct Media? n
Bypass If IP Threshold Exceeded? RFC 3389 Comfort Noise? Direct IP-IP Audio Connections? IP Audio Hairpinning? Direct IP-IP Early Media? Alternate Route Timer(sec):
n n y n n 6
Step Description 2. Verify the pre-existing IMS-enabled trunk group for Feature Server processing using the display trunk-group t command, where t is the number of the pre-existing IMS-enabled trunk group. In the reference configuration, trunk group 1 was used. Note that the Direction: field was set to two-way, the Service Type: field to tie, and the Signaling Group: field was set to the signaling group number from Step 1. 10 was used in the Number of Members field.
display trunk-group 1 TRUNK GROUP Group Number: Group Name: Direction: Dial Access? Queue Length: Service Type: 1 Group Type: SM1 Feature Server COR: two-way Outgoing Display? n 0 tie Auth Code? sip CDR Reports: y 1 TN: 1 TAC: *101 n Night Service: n Signaling Group: 1 Number of Members: 10 Page 1 of 21
3.
Enter the change route-pattern r command, where r is an unused route pattern number. In the reference configuration, route pattern 11 was used to return the call to Session Manager over the IMS signaling/trunk group. Modify the route pattern as follows: Grp No enter 1. This is the IMS trunk group. FRL enter 0. This is the least restrictive facility restriction level used in the reference configuration. Inserted Digits enter p. Note that this entry inserts a + to the called party number delivered in the Request-URI. The + will be captured by the Dial Pattern configured on Session Manager in Section 4.2 Step 9.
change route-pattern 11 Pattern Number: 11 Pattern Name: to-fs SCCAN? n Secure SIP? n Grp FRL NPA Pfx Hop Toll No. Inserted No Mrk Lmt List Del Digits Dgts 1: 1 0 p Page 1 of 3
DCS/ IXC QSIG Intw n user
Step Description 4. Enter the change ars analysis 0 command. In the reference configuration, two entries were used to handle US-based national dialing as well as international dialing. 1 and 011 were used as indices or Dialed String entries in the ARS Digit Analysis Table. Add the entries as follows: Dialed String enter 1. Total Min enter 11. Total Max enter 11. Route Pattern enter the route pattern number from Step 3. Call Type natl was used in the reference configuration. Dialed String enter 011. Total Min enter 3. Total Max enter 28. Route Pattern enter the route pattern number from Step 3. Call Type intl was used in the reference configuration.
Page ARS DIGIT ANALYSIS TABLE Location: all Dialed String 1 011 Total Min Max 11 11 3 28 Route Pattern 11 11 Call Type natl intl Node Num 2 of 2 1
change ars analysis 0
Percent Full: ANI Reqd n n
Step Description 5. Verify that the ARS feature is selecting the route pattern number from Step 3 for digits dialed by IMS-SIP telephone users. This can be verified by generating an ARS Route Chosen Report using the list ars route-chosen command. For a national US-based call, if the IMS-SIP telephone user will dial 9 followed by 17325551212, enter the list ars route-chosen 17325551212 command and verify that the Route Pattern column displays the selected route pattern number from Step 3 as shown below.
list ars route-chosen 17325551212 ARS ROUTE CHOSEN REPORT Location: Dialed String 1 1 Total Min Max 11 11 Partitioned Group Number: Route Pattern 11 Call Type natl Node Number 1
Location all
Actual Outpulsed Digits by Preference (leading 35 of maximum 42 digit) 1: p 9:
For an international call, if the IMS-SIP telephone user will dial 9 followed by 01135355512345, enter the list ars route-chosen 01135355512345 command and verify that the Route Pattern column displays the selected route pattern number from Step 3 as shown below.
list ars route-chosen 01135355512345 ARS ROUTE CHOSEN REPORT Location: Dialed String 011 1 Total Min Max 3 28 Partitioned Group Number: Route Pattern 11 Call Type intl Node Number 1
Location all
Actual Outpulsed Digits by Preference (leading 35 of maximum 42 digit) 1: p 9:
5.5.2. Call Processing from the non-IMS Signaling/Trunk Group to the ISDN/PRI Trunk Group
Step Description 1. Enter the change inc-call-handling-trmt trunk group t command, where t is the trunk group number assigned in Section 5.3 Step 2 for non-IMS calls. Digit manipulation of the called party number can be achieved using the Del and Insert fields on the Incoming Call Handling Treatment table. Modify the Incoming Call Handling Treatment table as follows: Del no entry needed. Note: the version of Communication Manager used in the reference configuration automatically deletes the + sign when manipulating the called party number on the Incoming Call Handling Treatment table. However, in future releases of Communication Manager, it may be necessary to enter a 1 in the Del in order to delete the leading + sign from the called party number. Insert enter 9999. The first 9 will activate ARS routing since 9 is the ARS feature access code as verified in Section 5.2. The next three digits will be analyzed by the Automatic Route Selection feature and are used as an index to the ARS Digit Analysis Table.
change inc-call-handling-trmt trunk-group 2 INCOMING CALL HANDLING TREATMENT Service/ Number Number Del Insert Feature Len Digits tie 9999 Page 1 of 30
2.
Enter the change route-pattern r command, where r is an unused route pattern number. In the reference configuration, route pattern 21 was used to select the PSTN trunk group for outbound call routing. Modify the route pattern as follows: Grp No enter 10. This is the PSTN trunk group. FRL enter 0. This is the least restrictive facility restriction level used in the reference configuration. No. Del Dgts enter 3. Note that this entry deletes the digits 99920 (that were inserted in Step 1) prior to delivering the call to the PSTN trunk.
change route-pattern 21 Pattern Number: 21 Pattern Name: to-pstn SCCAN? n Secure SIP? n Grp FRL NPA Pfx Hop Toll No. Inserted No Mrk Lmt List Del Digits Dgts 1: 10 0 3 Page 1 of 3
20
Note that while the configuration in Step 1 inserts 9999, the first digit 9 is not counted, as it is the ARS feature access code. VV; Reviewed: SPOC 04/08/2010 Solution & Interoperability Test Lab Application Notes 2010 Avaya Inc. All Rights Reserved. 32 of 38 SM52_TDMTRK_FS
Step Description 3. Enter the change ars analysis 999 command. In the reference configuration, the digits 999 are used as an index or Dialed String entry in the ARS Digit Analysis Table. Add the entry as follows: Dialed String enter 999. Total Min enter 3. Total Max enter 28. Route Pattern enter the route pattern number from Step 2. Call Type pubu was used in the reference configuration.
change ars analysis 999 ARS DIGIT ANALYSIS TABLE Location: all Dialed String 999 Total Min Max 3 28 Route Pattern 21 Call Type pubu Node Num Page 1 of 2 1
Percent Full: ANI Reqd n
Step Description 4. In the reference configuration, trunk group 10 was used as the PSTN trunk group and is shown here for reference only.
display trunk-group 10 TRUNK GROUP Group Number: Group Name: Direction: Dial Access? Queue Length: Service Type: 10 Group Type: isdn CDR Reports: y PSTNHUB COR: 1 TN: 1 TAC: *110 two-way Outgoing Display? n Carrier Medium: PRI/BRI n Busy Threshold: 255 Night Service: 0 public-ntwrk Auth Code? n TestCall ITC: rest Far End Test Line No: TestCall BCC: 4 display trunk-group 10 Group Type: isdn TRUNK PARAMETERS Codeset to Send Display: 6 Max Message Size to Send: 260 Supplementary Service Protocol: a Trunk Hunt: cyclical Digital Loss Group: 13 Incoming Calling Number - Delete: Insert: Format: Bit Rate: 1200 Synchronization: async Duplex: full Disconnect Supervision - In? y Out? n Answer Supervision Timeout: 0 Administer Timers? n CONNECT Reliable When Call Leaves ISDN? n display trunk-group 10 TRUNK FEATURES ACA Assignment? n Page Measured: none Data Restriction? n Send Name: y 3 of 21 n y Page 2 of 21 Page 1 of 21
Codeset to Send National IEs: 6 Charge Advice: none Digit Handling (in/out): enbloc/enbloc
y Used for DCS? n n Suppress # Outpulsing? n Format: public Outgoing Channel ID Encoding: preferred UUI IE Treatment: service-provider Replace Restricted Numbers? Replace Unavailable Numbers? Send Connected Number: Hold/Unhold Notifications? Modify Tandem Calling Number? Ds1 Echo Cancellation? n n n n n y
Wideband Support? Maintenance Tests? NCA-TSC Trunk Member: Send Calling Number: Send EMU Visitor CPN?
Send UUI IE? y Send UCID? n Send Codeset 6/7 LAI IE? y
Apply Local Ringback? n US NI Delayed Calling Name Update? n Show ANSWERED BY on Display? y Network (Japan) Needs Connect Before Disconnect?
5.6. Routing a PSTN Call to the non-IMS Signaling/Trunk Group (Inbound Call)
This section describes the configuration steps on Communication Manager for routing calls from the PSTN to the non-IMS signaling/trunk group. Note that Communication Manager receives these calls from the PSTN as inbound calls and routes them as outbound calls to Session Manager for delivery to IMS-SIP telephones. Step Description 1. Enter the change inc-call-handling-trmt trunk group 10 command, where 10 is the preexisting ISDN trunk group number as shown in Section 5.5.2 Step 4. In the reference configuration, the PSTN delivers a 7-digit called party number that begins with 555. Modify the Incoming Call Handling Treatment table as follows: Number Len enter 7. Number Digits enter 555. Insert enter 8999. Digit 8 will activate AAR routing. The next three digits will be analyzed by the Automatic Alternate Routing feature.
change inc-call-handling-trmt trunk-group 10 INCOMING CALL HANDLING TREATMENT Service/ Number Number Del Insert Feature Len Digits public-ntwrk 7 555 8999 Page 1 of 30
Per Call Night CPN/BN Serv
2.
Enter the change route-pattern r command, where r is an unused route pattern number. In the reference configuration, route pattern 2 was used to select the non-IMS trunk group for inbound call routing and delivery to Session Manager. Modify the route pattern as follows: Grp No enter 2. This is the non-IMS trunk group. FRL enter 0. This is the least restrictive facility restriction level used in the reference configuration. No. Del Dgts enter 3. Note that this entry deletes the digits 99921 (that were inserted in Step 1) prior to delivering the call to Session Manager.
change route-pattern 2 Pattern Number: 2 Pattern Name: SCCAN? n Secure SIP? n Grp FRL NPA Pfx Hop Toll No. Inserted No Mrk Lmt List Del Digits Dgts 1: 2 0 3 Page 1 of 3
21
Note that while the configuration in Step 1 inserts 8999, the first digit 8 is not counted, as it is the AAR feature access code. VV; Reviewed: SPOC 04/08/2010 Solution & Interoperability Test Lab Application Notes 2010 Avaya Inc. All Rights Reserved. 35 of 38 SM52_TDMTRK_FS
Step Description 3. Enter the change aar analysis 999 command. In the reference configuration, the digits 999 are used as an index or Dialed String entry in the AAR Digit Analysis Table. Add the entry as follows: Dialed String enter 999. Total Min enter 10. Total Max enter 10. Route Pattern enter the route pattern number from Step 2. Call Type pubu was used in the reference configuration.
change aar analysis 999 AAR DIGIT ANALYSIS TABLE Location: all Dialed String 999 Total Min Max 10 10 Route Pattern 2 Call Type pubu Node Num Page 1 of 2 1
Percent Full: ANI Reqd n
6. Verification Steps
6.1. Verification Tests
The following steps may be used to verify the configuration: Place a call from an IMS-SIP telephone to a PSTN telephone by dialing 9 followed by the called party number. Verify that the call is established with two-way audio and that the calling party number on the PSTN telephones caller-ID22 display is a 10-digit number (if originating from a US-based location). Place a call from the PSTN telephone to the IMS-SIP telephone. Verify that the call is established with two-way audio.
6.2. Troubleshooting Tools

The Communication Manager list trace tac, and/or status trunk-group commands are helpful diagnostic tools to verify correct operation and to troubleshoot problems. MST (Message Sequence Trace) diagnostic traces (performed by Avaya Support) can be helpful in understanding specific interoperability issues. The logging and reporting functions within the System Manager Common Console may be used to examine the details of Session Manager calls. In addition, if port monitoring is available, a SIP protocol analyzer such as Wireshark (a.k.a. Ethereal) can be used to capture SIP traces at the Session Manager interface. SIP traces can be instrumental in understanding SIP protocol issues resulting from configuration problems.
22
Caller-ID will only be displayed if the telephone is so equipped and the PSTN is providing the caller-ID information to the telephone. VV; Reviewed: SPOC 04/08/2010 Solution & Interoperability Test Lab Application Notes 2010 Avaya Inc. All Rights Reserved. 36 of 38 SM52_TDMTRK_FS
7. Conclusion
These Application Notes describe the procedures for configuring TDM trunks on Avaya Aura Communication Manager Feature Server. In the configuration described herein, IP Multimedia Services (IMS) SIP telephones, that are registered to Avaya Aura Session Manager, are able to access the TDM trunks on the Feature Server to place bi-directional calls to the PSTN over traditional ISDN/PRI trunks.
8. Additional References
The following documentation may be obtained from http://support.avaya.com. [1] Avaya Aura Session Manager Overview, Document Number 03-603323, Issue 2, Release 5.2, November 2009 [2] Installing and Upgrading Avaya Aura Session Manager, Document Number 03603473, Issue 2, Release 5.2, November 2009 [3] Administering Avaya Aura Session Manager, Document Number 03-603324, Issue 2, Release 5.2, November 2009 [4] Avaya Aura Session Manager Case Studies, Document Number 03-603478, Issue 2, Release 5.2, November 2009 [5] Maintaining and Troubleshooting Avaya Aura Session Manager, Document Number 03-603325, Issue 2, Release 5.2, November 2009 [6] Installing and Configuring Avaya Aura System Platform, Release 1.1, November 2009 [7] Installing and Upgrading Avaya Aura System Manager, Release 5.2, January 2010 [8] Avaya Aura Communication Manager Overview, Document Number 03-300468, Issue 6, Release 5.2, May 2009 [9] Administering Avaya Aura Communication Manager, Document Number 03-300509, Issue 5.0, Release 5.2, May 2009 [10] Avaya Aura Communication Manager Feature Description and Implementation, Document Number 555-245-205, Issue 7.0, Release 5.2, May 2009 [11] Administering Network Connectivity on Avaya Aura Communication Manager, Document Number 555-233-504, Issue 14, May 2009 [12] SIP Support in Avaya Aura Communication Manager Running on Avaya S8xxx Servers, Document Number 555-245-206, Issue 9, May 2009 [13] Administering Avaya Aura Communication Manager as a Feature Server", Document Number 03-603479, Issue 1.2, Release 5.2, January 2010 [14] Configuring 9600-Series SIP Phones with Avaya Aura Session Manager Release 5.2 Issue 1.0, Application Note [15] The international public telecommunication numbering plan, E.164 (02/2005), ITU-T, available at http://www.itu.in
2010 Avaya Inc. All Rights Reserved.
Avaya and the Avaya Logo are trademarks of Avaya Inc. All trademarks identified by and are registered trademarks or trademarks, respectively, of Avaya Inc. All other trademarks are the property of their respective owners. The information provided in these Application Notes is subject to change without notice. The configurations, technical data, and recommendations provided in these Application Notes are believed to be accurate and dependable, but are presented without express or implied warranty. Users are responsible for their application of any products specified in these Application Notes. Please e-mail any questions or comments pertaining to these Application Notes along with the full title and filename, located in the lower right corner, directly to the Avaya Solution & Interoperability Test Lab at interoplabnotes@list.avaya.com

Configuring TDM Trunks On Avaya Aura™ Communication Manager Feature Server Release 5.2.1 - Issue 1.0

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Configuring TDM Trunks On Avaya Aura™ Communication Manager Feature Server Release 5.2.1 - Issue 1.0

Diunggah oleh

Hak Cipta:

Format Tersedia

Avaya Solution & Interoperability Test Lab

VV; Reviewed: SPOC 04/08/2010

1.1. Capabilities Verified and System Constraints

Figure 1: Reference Configuration

VV; Reviewed: SPOC 04/08/2010

2.1. Avaya Aura Session Manager

2.2. Avaya Aura Communication Manager Feature Server

2.3. TDM Trunks on Avaya Aura Communication Manager

2.4. Call Flows

Figure 2: Outbound Call Flow

Figure 3: Inbound Call Flow

3. Equipment and Software Validated

Table 1: Equipment/Software List

4. Configuring Avaya Aura Session Manager

VV; Reviewed: SPOC 04/08/2010

4.2. Network Routing Policies (NRP)

Figure 4: Introduction to Network Routing Policy (NRP) Page

VV; Reviewed: SPOC 04/08/2010

VV; Reviewed: SPOC 04/08/2010

VV; Reviewed: SPOC 04/08/2010

VV; Reviewed: SPOC 04/08/2010

VV; Reviewed: SPOC 04/08/2010

VV; Reviewed: SPOC 04/08/2010

VV; Reviewed: SPOC 04/08/2010

VV; Reviewed: SPOC 04/08/2010

VV; Reviewed: SPOC 04/08/2010

5. Configuring Avaya Aura Communication Manager

5.1. System Parameters

VV; Reviewed: SPOC 04/08/2010

Digital Loss Plan Modification? n DS1 MSP? n DS1 Echo Cancellation? n

Wideband Switching? n Wireless? n

VV; Reviewed: SPOC 04/08/2010

5.2. Dial Plan

Percent Full: Dialed String Total Call Length Type

VV; Reviewed: SPOC 04/08/2010

Access Code 2: Deactivation: Deactivation: Deactivation:

Deactivation: Close Code:

VV; Reviewed: SPOC 04/08/2010

5.3. non-IMS Signaling/Trunk Group on the Feature Server

VV; Reviewed: SPOC 04/08/2010

VV; Reviewed: SPOC 04/08/2010

5.4. Calling Party Number

Number Format natl-pub

5.5. Routing IMS-SIP calls to the PSTN (Outbound Call)

5.5.1. Initial Call Processing through the IMS Signaling/Trunk Group

VV; Reviewed: SPOC 04/08/2010

DCS/ IXC QSIG Intw n user

VV; Reviewed: SPOC 04/08/2010

change ars analysis 0

Percent Full: ANI Reqd n n

VV; Reviewed: SPOC 04/08/2010

Actual Outpulsed Digits by Preference (leading 35 of maximum 42 digit) 1: p 9:

Actual Outpulsed Digits by Preference (leading 35 of maximum 42 digit) 1: p 9:

VV; Reviewed: SPOC 04/08/2010

DCS/ IXC QSIG Intw n user

Percent Full: ANI Reqd n

VV; Reviewed: SPOC 04/08/2010

VV; Reviewed: SPOC 04/08/2010

Per Call Night CPN/BN Serv

DCS/ IXC QSIG Intw n user

Percent Full: ANI Reqd n

6.2. Troubleshooting Tools