Abstract. Avaya Solution & Interoperability Test Lab

Transcription

1 Avaya Solution & Interoperability Test Lab Application Notes for Configuring Bell Canada SIP Trunking Service with Avaya Aura Communication Manager Evolution Server Release and Avaya Session Border Controller for Enterprise Release Issue 1.0 Abstract These Application Notes describe the steps to configure Session Initiation Protocol (SIP) trunk between Bell Canada SIP Trunking Service and an Avaya SIP-enabled enterprise solution. The Avaya solution consists of Avaya Aura Communication Manager Evolution Server 6.0.1, Avaya Session Border Controller for Enterprise and various Avaya endpoints. This documented solution does not extend to configurations without Avaya Session Border Controller for Enterprise. Bell Canada is a member of the Avaya DevConnect Service Provider Program. Information in these Application Notes has been obtained through DevConnect compliance testing and additional technical discussions. Testing was conducted via the DevConnect Program at the Avaya Solution and Interoperability Test Lab. 1 of 62

2 Table of Contents 1. Introduction Test Scope and Results Interoperability Compliance Testing Test Results Support Reference Configuration Equipment and Software Validated Configure Avaya Aura Communication Manager Licensing and Capacity System Features IP Node Names Codecs IP Network Region Signaling Group Trunk Groups Calling Party Information Outbound Routing Saving Communication Manager Configuration Changes Configure Avaya Session Border Controller for Enterprise Log into the Avaya Session Border Controller for Enterprise Global Profiles Uniform Resource Identifier (URI) Groups Routing Profiles Topology Hiding Server Interworking Signaling Manipulation Server Configuration Domain Policies Application Rules Media Rules Signaling Rules Endpoint Policy Groups Session Policy Device Specific Settings Network Management Media Interface Signaling Interface End Point Flows - Server Flow Session Flow Bell Canada SIP Trunking Configuration Verification and Troubleshooting Verification Steps Protocol Traces Troubleshooting: of 62

3 Avaya SBCE Communication Manager Conclusion References of 62

4 1. Introduction These Application Notes describe the steps to configure Session Initiation Protocol (SIP) trunk between Bell Canada SIP Trunking Service (Bell Canada) which is designed for enterprise business customers and an Avaya SIP-enabled enterprise solution. The Avaya solution consists of Avaya Aura Communication Manager configured as an Evolution Server, Avaya SBC for Enterprise (Avaya SBCE) and various Avaya endpoints. Customers using this Avaya SIP-enabled enterprise solution with Bell Canada are able to place and receive PSTN calls via a broadband connection. This converged network solution is an alternative to traditional PSTN trunk such as analog and/or ISDN-PRI. 2. Test Scope and Results DevConnect Compliance Testing is conducted jointly by Avaya and DevConnect members. The jointly-defined test plan focuses on exercising APIs and/or standards-based interfaces pertinent to the interoperability of the tested products and their functionalities. DevConnect Compliance Testing is not intended to substitute full product performance or feature testing performed by DevConnect members, nor is it to be construed as an endorsement by Avaya of the suitability or completeness of a DevConnect member s solution. Bell Canada is a member of the Avaya DevConnect Service Provider Program. The general test approach is to connect a simulated enterprise to Bell Canada via the public internet and exercise the features and functionality listed in Section Error! Reference source not found Interoperability Compliance Testing To verify Bell Canada SIP Trunking Service interoperability, the following features and functionalities are covered during the compliance testing: Request and response to OPTIONS heartbeat. Inbound PSTN call to various phone types including H.323, Avaya one-x Communicator softphone, digital and analog telephone at the enterprise. All inbound calls from PSTN are routed to the enterprise across the SIP trunk from the service provider. Outbound PSTN call from various phone types including H.323, Avaya one-x Communicator softphone, digital and analog telephone at the enterprise. All outbound calls to PSTN are routed from the enterprise across the SIP trunk to the service provider. Both Avaya one-x Communicator (1XC) Computer Mode (where 1XC is used for call control as well as audio path) and Telecommuter Mode (where 1XC is used for call control and a separate telephone is used for audio path) were tested. The 1XC also supports two signaling protocols (H.323 and SIP), but only H.323 was tested as the test configuration does not require Avaya Aura Session Manager which is needed to support SIP phone. Dialing plans including local, long distance, international, outbound toll-free, operator assisted calls, local directory assistance (411) etc. 4 of 62

5 Calling party presentation and calling party restriction (private call). Proper codec negotiation with G.729 and G.711MU codecs. Proper Early Media transmission with G.729 and G.711MU codecs. Inbound and outbound fax over IP using G.711MU codec. DTMF tone transmissions as out-of-band RTP event as per RFC2833. Voic navigation for inbound and outbound calls. User features such as hold and resume and conference. Off-net call transfer with re-invite method. Off-net call forward with Diversion method. EC500 mobility (extension to cellular). Routing inbound PSTN calls to call center agent queues. Response to incomplete call attempts and trunk errors. SIP Digest Authentication. Session Timers refresh implemented by the service provider. Items are not supported by Bell Canada or not tested including the following: Inbound toll-free and outbound emergency calls (911) are supported but were not tested as part of the compliance testing because Bell Canada has not provided the necessary configuration. Fax over IP using T.38 codec is not supported. Off-net calls transfer using REFER method is not supported. Vector call redirection before answering using 302 Moved Temporarily method is not supported. Vector call redirection after answering using REFER method is not supported. Off-net call forward using History-Info method is not supported Test Results Interoperability testing of Bell Canada SIP Trunking Service with the Avaya SIP-enabled enterprise solution is completed with successful results for all test cases with the exception of the observations/limitations described below. 1. In an off-net call transfer scenario, the calling party name and number are not updated to PSTN parties. Communication Manager off-net transfers an inbound call back to PSTN. After completing the transfer, Communication Manager sends UPDATE with Remote-Part-ID header to update the true connected calling party name and number to both PTSN parties. The call display information, however, is not being updated. It depends on either Bell Canada or intermediate service providers which route the call from Bell Canada to the endpoint to support the display update. 2. The calling party name for outbound call is not consistent. In outbound call scenario, Communication Manager sends both calling party name and number to Bell Canada. In some cases, PSTN phone displays just calling party number and no calling party name. In some other cases, PSTN phone displays both calling party name and number. The calling party name may be overridden by the intermediate service providers that route the call from Bell Canada to the PSTN party. 5 of 62

6 3. The calling number of inbound PSTN call contains a "+" character that needs to be deleted. The inbound call from Bell Canada to the enterprise contains a "+" followed by 11 digits in the From header for the calling number. The EC500 mobility call features does not work properly since the EC500 mobile number configured on Communication Manager (in off-pbx-telephone station-mapping form) is not allowed to contain nondigits like + to match the number in the inbound From header. The workaround is to have Avaya SBCE to normalize the calling number contained in the From header to remove the plus sign. For the detail configuration, please refer to Section 6.2.5). 4. The Call-ID for outbound call is not modified. In an outbound call, Bell Canada expects the Call-ID sent from Communication Manager to be appended. With a SigMa script configured to manipulate the Call-ID header, the outbound call works, but the inbound call fails. Even though Bell Canada requires the Call-ID to be sent in a specific format, it should not be manipulated by the Avaya SBCE. Changing the Call-ID is not recommended as it will cause inbound calls to fail. This is a known issue of the Avaya SBCE with no resolution available at this time. The compliance test is conducted without Call-ID modification, the inbound and outbound calls appear to work properly. 5. Performing an Application Restart on Ayaya SBCE causes SigmaScript or Authentication to stop working. If the SigMa script or Authentication do not work after an Application Restart, please contact Avaya for support on the Avaya SBCE by telephone numbers toll free or Note: The password for Authentication should not contain special character e.g.!. A product defect has been reported to Avaya team for investigation but there is no resolution available at this time. This issue is listed here as a limitation Support For technical support on the Avaya products described in these Application Notes visit For technical support on Bell Canada SIP Trunking, contact Bell Canada at 3. Reference Configuration Figure 1 illustrates a sample Avaya SIP-enabled enterprise solution connected to the Bell Canada SIP Trunking service (vendor validation circuit) through a public Internet connection. For security purposes, the real public IP addresses and PSTN routable phone numbers used in the compliance testing are disguised in these Application Notes. The Avaya SBCE is located at the edge of the enterprise network. It has two connection points, a public side connecting to Bell Canada via internet and a private side connecting to the enterprise network. All SIP and RTP traffic entering or leaving the enterprise network flows through the 6 of 62

7 Avaya SBCE which can protect the enterprise against outside SIP-based attacks. The Avaya SBCE provides network address translation at both the IP and SIP layers. The transport protocol between the Avaya SBCE and Bell Canada across the public network is UDP, the transport protocol between the Avaya SBCE and Communication Manager across the enterprise network is TCP. In the compliance testing, the Avaya lab environment is configured with SIP domain avayalab.com for the enterprise. The Avaya SBCE is used to adapt the enterprise SIP domain to the service provider SIP domain assigned by Bell Canada. Figure 1 below illustrates the network diagram for the enterprise. Figure 1: Avaya IP Telephony Network Connecting to Bell Canada SIP Trunking Service 7 of 62

8 4. Equipment and Software Validated The following equipment and software were used for the sample configuration provided: Avaya IP Telephony Solution Components Component Release Avaya Aura Communication Manager running on Avaya S8800 Server with patch (R016x ) Avaya G450 Media Gateway Avaya Session Border Controller for Q09 Enterprise Avaya 96xx Series IP Telephone (H.323) Avaya one-x Deskphone Edition Avaya one-x Communicator (H.323) SP3-Patch Avaya 1408 Digital Telephone n/a Avaya 6210 Analog Telephone n/a Bell Canada SIP Trunking Solution Components Component Release Acme Packet Net-Net 4250 SBC Firmware SC6.2.0 MR-4 Patch 1 (Build 718) Broadsoft SoftSwitch Rel16 Legacy Nortel CS2K Media Gateway SN10 PVG/IW-SPM Table 1: Equipment and Software Tested 5. Configure Avaya Aura Communication Manager This section describes the procedure for configuring Communication Manager for inter-operating with the Bell Canada SIP Trunking service. Two separate SIP trunk groups were created between Communication Manager and the Avaya SBCE to carry traffic to and from the service provider respectively. Any specific trunk or codec settings required by the service provider were applied only to these dedicated trunks so as not to affect other enterprise SIP traffic. Inbound calls flow from the Bell Canada infrastructure to the Avaya SBCE to Communication Manager. Incoming calls may undergo call treatment at Communication Manager such as incoming digit translations and class of service restrictions may be performed. Outbound calls to PSTN are first processed by Communication Manager for outbound feature treatment such as automatic route selection and class of service restrictions. Once Communication Manager selects the proper SIP trunk, the call is routed to the Avaya SBCE for egress to the Bell Canada network. For the compliance testing, Bell Canada applied Digest Authentication for outbound calls from the enterprise, using challenge-response authentication base on a user name and password (provided by Bell Canada and configured on Avaya SBCE). This call authentication scheme as specified in SIP RFC3261 provides security and integrity protection for SIP signaling. 8 of 62

9 These Application Notes assume the basic configuration has already been administered and not discussed here. For further information on Communication Manager, please consult references in Section 10. Communication Manager configuration is performed using the System Access Terminal (SAT). Some screens in this section have been abridged for brevity and clarity in presentation Licensing and Capacity Use the display system-parameters customer-options command to verify that the Maximum Administered SIP Trunks value on Page 2 is sufficient to support the desired number of simultaneous SIP calls across all SIP trunks at the enterprise including any trunks to and from the service provider. The example shows that licenses are available and 96 are in use. The license file installed on the system controls the maximum values for these attributes. If a required feature is not enabled or there is insufficient capacity, contact an authorized Avaya sales representative to add additional capacity. display system-parameters customer-options Page 2 of 11 OPTIONAL FEATURES IP PORT CAPACITIES USED 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 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: System Features Use the change system-parameters features command to set the Trunk-to-Trunk Transfer field to all to allow inbound calls from the PSTN to be transferred to another PSTN endpoint. If for security reasons, inbound calls should not be allowed to transfer back to the PSTN then leave the field set to none. 9 of 62

10 change system-parameters features Page 1 of 19 FEATURE-RELATED SYSTEM PARAMETERS Self Station Display Enabled? n Trunk-to-Trunk Transfer: all Automatic Callback with Called Party Queuing? n Automatic Callback - No Answer Timeout Interval (rings): 3 Call Park Timeout Interval (minutes): 10 Off-Premises Tone Detect Timeout Interval (seconds): 20 AAR/ARS Dial Tone Required? y Music (or Silence) on Transferred Trunk Calls? no DID/Tie/ISDN/SIP Intercept Treatment: attd Internal Auto-Answer of Attd-Extended/Transferred Calls: transferred Automatic Circuit Assurance (ACA) Enabled? n Abbreviated Dial Programming by Assigned Lists? n Auto Abbreviated/Delayed Transition Interval (rings): 2 Protocol for Caller ID Analog Terminals: Bellcore Display Calling Number for Room to Room Caller ID Calls? n On Page 9 verify that a text string has been defined to replace the Calling Party Number (CPN) for restricted or unavailable calls. The compliance test used the values of AV-Restricted for restricted calls and AV-Unavailable for unavailable calls. change system-parameters features Page 9 of 19 FEATURE-RELATED SYSTEM PARAMETERS CPN/ANI/ICLID PARAMETERS CPN/ANI/ICLID Replacement for Restricted Calls: AV-Restricted CPN/ANI/ICLID Replacement for Unavailable Calls: AV-Unavailable DISPLAY TEXT Identity When Bridging: principal User Guidance Display? n Extension only label for Team button on 96xx H.323 terminals? n INTERNATIONAL CALL ROUTING PARAMETERS Local Country Code: International Access Code: ENBLOC DIALING PARAMETERS Enable Enbloc Dialing without ARS FAC? n CALLER ID ON CALL WAITING PARAMETERS Caller ID on Call Waiting Delay Timer (msec): IP Node Names Use the change node-names ip command to verify that a node name procr and SBCE have been previously defined for Communication Manager and the Avaya SBCE respectively. These node names will be needed for defining the service provider signaling groups in Section of 62

11 change node-names ip Page 1 of 2 IP NODE NAMES Name IP Address AAM SBCE default procr procr6 :: 5.4. Codecs Use the change ip-codec-set command to define a list of codecs to use for calls between the enterprise and the service provider. For the compliance testing, ip-codec-set 1 was used for this purpose. Bell Canada currently supports G.729 and G.711MU. Enter the codec to be used in priority order in the Audio Codec column of the table. Default values can be used for all other fields. The following screen shows the codec set configuration at a certain time of the compliance testing. During testing, the codec set specifications are varied to test for individual codec support as well as codec negotiation between the enterprise and the service provider at call setup stage. change ip-codec-set 1 Page 1 of 2 Codec Set: 1 IP Codec Set Audio Silence Frames Packet Codec Suppression Per Pkt Size(ms) 1: G.711MU n : G.729 n : 4: On Page 2, set the FAX Mode to off. The T.38 fax is not supported. Bell Canada only supports G.711MU fax in this compliance testing. In inbound or outbound fax calls with codec G.711MU between the enterprise and PSTN, the SIP call dialog looks identical to a regular voice call. The fax document was received in acceptable quality. Communication Manager does not officially support G.711MU fax. However, inbound and outbound G.711MU fax calls appeared to work during testing when configuring fax = off. Communication Manager only supports G.711MU fax in best effort, it handles the fax call like a regular voice call. change ip-codec-set 1 Page 2 of 2 IP Codec Set Allow Direct-IP Multimedia? n Mode Redundancy FAX off 0 Modem off 0 TDD/TTY US 3 Clear-channel n 0 11 of 62

12 5.5. IP Network Region In the compliance testing, ip-network-region 1 was created for the service provider trunk groups. This allows separate codec or quality of service settings to be used for calls between the enterprise and the service provider versus calls within the enterprise or elsewhere. Use the change ip-network-region command to configure region 1 with the following parameters: Set the Authoritative Domain field to match the SIP domain of the enterprise. In this configuration, the domain name is avayalab.com as assigned to the Avaya test lab. This domain name appears in the From header of SIP messages originating from this IP region. Note that the Avaya SBCE Topology Hiding is used to convert this enterprise domain name to the specific SIP domain as assigned by Bell Canada. For detail configuration of Topology Hiding, please refer to Section Enter a descriptive name in the Name field.e.g. Bell_cust6. Enable IP-IP Direct Audio (shuffling) to allow audio traffic to be sent directly between IP endpoints without using media resources in the Avaya G450 Media Gateway. Set both Intra-region and Inter-region IP-IP Direct Audio to yes. This is the default setting. Shuffling can be further restricted at the trunk level on the Signaling Group form, which is discussed in Section 5.6. Set the Codec Set field to the IP codec set defined in Section 5.4. Default values can be used for all other fields. change ip-network-region 1 Page 1 of 20 IP NETWORK REGION Region: 1 Location: 1 Authoritative Domain: avayalab.com Name: Bel_cust6 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 Call Control PHB Value: 46 Audio PHB Value: 46 Video PHB Value: P/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 On Page 4, define the IP codec set to be used for traffic between region 1 and other regions. In this testing, Communication Manager, the Avaya SBCE and IP phones were assigned to the same region 1. Enter the desired IP codec set in the codec set column of the row with destination region (dst rgn). Default values may be used for all other fields. The example below shows the settings used for the compliance test. It indicates that codec set 1 will be used for calls between the service provider region 1 and other region.e.g of 62

13 change ip-network-region 1 Page 4 of 20 Source Region: 1 Inter Network Region Connection Management I M G A t dst codec direct WAN-BW-limits Video Intervening Dyn A G c rgn set WAN Units Total Norm Prio Shr Regions CAC R L e 1 1 all 2 1 y NoLimit n t Non-IP telephones (e.g. analog, digital) derive network region from the Avaya Media Gateway to which the device is connected. IP telephones can be assigned a network region based on an IP address mapping. The following screen illustrates a subset of the IP network map configuration used to verify these Application Notes. For the compliance testing, devices with IP addresses in the /24 subnet were assigned to network region 1 as shown in the screenshot below. These include Communication Manager, the internal interface of the Avaya SBCE and IP telephones including the Avaya 9600 IP Telephones and the Avaya one-x Communicator soft phones. In the production environments, different sites will typically be on different networks and range of IP address assigned by the DHCP scope serving the site can be entered as one entry in the network map to assign all telephones to a specific network region. display ip-network-map Page 1 of 63 IP ADDRESS MAPPING Subnet Network Emergency IP Address Bits Region VLAN Location Ext FROM: /24 1 n TO: FROM: / n TO: 5.6. Signaling Group Use the add signaling-group command to create a signaling group between Communication Manager and the Avaya SBCE for use by both inbound calls from the service provider network and outbound calls from the enterprise. For the compliance testing, the signaling group 1 was added and configured using the parameters highlighted below. Set the Group Type field to sip. Set the IMS Enabled field to n. This specifies Communication Manager will serve as an Evolution Server for the SIP trunk. Set the Transport Method to tcp which is the transport method between Communication Manager and the Avaya SBCE. Set the Near-end Listen Port and Far-end Listen Port to a valid unused port.e.g Set the Peer Detection Enabled field to n and the Peer-Server field to Others as recommended values to define far-end endpoint for the Avaya SBCE. 13 of 62

14 Set the Near-end Node Name to procr. This node name maps to the IP address of Communication Manager as defined in Section 5.3. Set the Far-end Node Name to SBCE. This node name maps to the IP address of the Avaya SBCE as defined in Section 5.3. Set the Far-end Network Region to the IP network region 1 for the service provider as defined in Section 5.5. Set the Far-end Domain to avayalab.com. This SIP domain will be used as URI-Host of the Request-URI and To headers for outbound calls from this signaling group. Note: The Avaya SBCE Topology Hiding is used to convert this enterprise domain name to the specific SIP domain as assigned by Bell Canada. For detail configuration of Topology Hiding, please refer to Section Set Direct IP-IP Audio Connections to y. This field enables media shuffling on the SIP trunk, allowing Communication Manager to redirect media traffic directly to the enterprise endpoint. If this value is set to n, then the Avaya Media Gateway will remain in the media path of all calls on the SIP trunk. Depending on the number of media resources available on the Avaya Media Gateway, these resources may be depleted during high call volume preventing additional calls from completing. Verify that the Initial IP-IP Direct Media is set to n as default. This setting allows media paths to be firstly connected to the Avaya Media Gateway then shuffled to the enterprise endpoint. Set the DTMF over IP field to rtp-payload. This setting enables Communication Manager to send DTMF transmissions using RFC2833. Set the Enable Layer 3 Test? to y. This setting allows Communication Manager to send OPTIONS heartbeat to query for the status of the SIP trunk. In this compliance testing, the Avaya SBCE was configured to forward this OPTIONS heartbeat to Bell Canada for responses. For detail configuration, please refer to Section Note: The Avaya SBCE does not respond to the OPTIONS heartbeat. Change the Alternate Route Timer (sec) default setting of 6 to 30. This allows more time for PSTN calls to complete through the Bell Canada networks. Default values may be used for all other fields. 14 of 62

15 add signaling-group 1 Page 1 of 1 SIGNALING GROUP Group Number: 1 Group Type: sip IMS Enabled? n Transport Method: tcp Q-SIP? n IP Video? n Peer Detection Enabled? n Peer Server: Others SIP Enabled LSP? n Enforce SIPS URI for SRTP? y Near-end Node Name: procr Far-end Node Name: SBCE Near-end Listen Port: 5060 Far-end Listen Port: 5060 Far-end Network Region: 1 Far-end Domain: avayalab.com Bypass If IP Threshold Exceeded? n Incoming Dialog Loopbacks: eliminate RFC 3389 Comfort Noise? n DTMF over IP: rtp-payload Direct IP-IP Audio Connections? y Session Establishment Timer(min): 3 IP Audio Hairpinning? n Enable Layer 3 Test? y Initial IP-IP Direct Media? N H.323 Station Outgoing Direct Media? n Alternate Route Timer(sec): Trunk Groups Use the add trunk-group command to create two trunk groups for inbound and outbound calls, using the signaling group created in Section 5.6. For the compliance testing, trunk group 1 was configured to receive inbound calls and trunk group 2 was configured to send outbound calls with the parameters highlighted below. Set the Group Type field to sip. Enter a descriptive name for the Group Name. Enter an available trunk access code (TAC) that is consistent with the existing dial plan in the TAC field. Set the Direction field to incoming for trunk group 1 and outgoing for trunk group 2. Set the Outgoing Display to y to enable name display on the trunk. Set the Service Type field to public-ntwrk. Set Member Assignment Method to auto. Set the Signaling Group to the signaling group defined in Section 5.6. Set the Number of Members field to the number of trunk members of the SIP trunk. This value determines maximum simultaneous SIP calls can be supported. Default values were used for all other fields. 15 of 62

16 add trunk-group 1 Page 1 of 21 TRUNK GROUP Group Number: 1 Group Type: sip CDR Reports: y Group Name: Incoming_Bell_cust6 COR: 1 TN: 1 TAC: *001 Direction: incoming Outgoing Display? y Dial Access? n Night Service: Service Type: public-ntwrk Auth Code? n Member Assignment Method: auto Signaling Group: 1 Number of Members: 32 On Page 2, verify that the Preferred Minimum Session Refresh Interval (sec) is set to a value acceptable to the service provider. This value defines the interval that a re-invite must be sent to keep the active session alive. By default, the value is set to 600 seconds. add trunk-group 1 Page 2 of 21 Group Type: sip TRUNK PARAMETERS Unicode Name: auto Redirect On OPTIM Failure: 5000 SCCAN? n Digital Loss Group: 18 Preferred Minimum Session Refresh Interval(sec): 600 Disconnect Supervision - In? y XOIP Treatment: auto Delay Call Setup When Accessed Via IGAR? n On Page 3, set the Numbering Format field to private. This field specifies the format of the CPN sent to the far-end. Beginning with Communication Manager 6.0, public numbers are automatically preceded with a + sign when passed in the From, Contact and P-Asserted Identity headers. The addition of the + sign impacted interoperability with Bell Canada. Therefore, the Numbering Format is set to private and the Numbering Format in the route pattern 2 is set to unk-unk (see Section 5.9). Set the Replace Restricted Numbers and Replace Unavailable Numbers fields to y. This will allow the CPN displays on local endpoints to be replaced with the value set in Section 5.2 in case of receiving inbound private call. Default values are used for all other fields. 16 of 62

17 add trunk-group 1 Page 3 of 21 TRUNK FEATURES ACA Assignment? n Measured: none Maintenance Tests? y Numbering Format: private UUI Treatment: service-provider Replace Restricted Numbers? y Replace Unavailable Numbers? y Show ANSWERED BY on Display? y On Page 4, the Network Call Redirection field can be set to n. This setting disables call transfer using REFER method which Bell Canada has not supported on the SIP trunk. It allows Communication Manager to use re-invite method to transfer off-net an inbound call back to PSTN.. Note: The same setting is also applicable to outgoing trunk group. Set the Send Diversion Header field to y. This field provides additional information to the network if the call has been re-directed. This is needed to support call forwarding of inbound calls back to PSTN and some Extension to Cellular (EC500) call scenarios. Set the Support Request History field to n. This parameter determines the History- Info header will be excluded in the call-redirection INVITE from the enterprise as it is not supported by Bell Canada. Set the Telephone Event Payload Type to 101 which is the value preferred by Bell Canada. Set the Convert 180 to 183 for Early Media field to y. add trunk-group 1 Page 4 of 21 PROTOCOL VARIATIONS Mark Users as Phone? n Prepend '+' to Calling Number? n Send Transferring Party Information? n Network Call Redirection? n Send Diversion Header? y Support Request History? n Telephone Event Payload Type: 101 Convert 180 to 183 for Early Media? y Always Use re-invite for Display Updates? n Identity for Calling Party Display: P-Asserted-Identity Enable Q-SIP? n For outgoing trunk group 2, the screen below shows Page 1 of the trunk group form used for outbound calls from the enterprise, with the Direction was set to outgoing. The other configurations of outgoing trunk group 2 are identical to incoming trunk group of 62

18 add trunk-group 2 Page 1 of 21 TRUNK GROUP Group Number: 2 Group Type: sip CDR Reports: y Group Name: Outgoing_Bell_cust6 COR: 1 TN: 1 TAC: *002 Direction: outgoing Outgoing Display? y Dial Access? n Queue Length: 0 Service Type: public-ntwrk Member Assignment Method: auto Signaling Group: 1 Number of Members: Calling Party Information The calling party number is sent in the From, Contact and P-Asserted-Identity headers. Since private numbering was selected to define the format of this number (Section 5.7), use the change private-numbering command to create an entry for a range of extensions which has DID numbers assigned. The normal 10-digit DID number is comprised of the local extension plus a configured Private Prefix. A single private numbering entry can be applied for all extensions. In the example below, all extensions with a 4-digit beginning with 18 will send the calling party number as the Private Prefix of plus the extension number of 18XX. change private-numbering 4 Page 1 of 2 NUMBERING - PRIVATE FORMAT Ext Ext Trk Private Total Len Code Grp(s) Prefix Len Total Administered: 1 Maximum Entries: 540 Even though private numbering was selected, currently the number used in the Diversion header is derived from the public unknown numbering table and not the private numbering table. As a workaround for this, the entries in the private numbering table must be repeated in the public unknown numbering table. change public-unknown-numbering 0 Page 1 of 2 NUMBERING - PUBLIC/UNKNOWN FORMAT Total Ext Ext Trk CPN CPN Len Code Grp(s) Prefix Len Total Administered: Maximum Entries: 9999 Note: If an entry applies to a SIP connection to Avaya Aura(tm) Session Manager, the resulting number must be a complete E.164 number. 18 of 62

19 5.9. Outbound Routing In these Application Notes, the Automatic Route Selection (ARS) feature was used to route outbound calls via the SIP trunk to the service provider. In the sample configuration, the single digit 9 is used as the ARS access code. Enterprise callers will dial 9 to reach an outside line. This common configuration is illustrated below with little elaboration. Use the change dialplan analysis command to define a dialed string beginning with 9 of length 1 as a feature access code (fac). change dialplan analysis Page 1 of 12 DIAL PLAN ANALYSIS TABLE Location: all Percent Full: 0 Dialed Total Call Dialed Total Call Dialed Total Call String Length Type String Length Type String Length Type 18 4 ext 6 1 dac 9 1 dac * 4 dac Use the change feature-access-codes command to configure 9 as the Auto Route Selection (ARS) Access Code 1. change feature-access-codes Page 1 of 10 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: *007 Answer Back Access Code: Attendant Access Code: Auto Alternate Routing (AAR) Access Code: *000 Auto Route Selection (ARS) - Access Code 1: 9 Access Code 2: 6 Automatic Callback Activation: Deactivation: Call Forwarding Activation Busy/DA: All: Deactivation: Call Forwarding Enhanced Status: Act: Deactivation: 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: Deactivation: Contact Closure Open Code: Close Code: Use the change ars analysis command to configure the routing of dialed digits following the first digit 9. The example below shows a subset of the dialed strings tested as part of the compliance test. See Section 2.1 for the complete list of tested call types. All dialed strings are mapped to route pattern 2 for both outbound calls on the SIP trunk. 19 of 62

20 change ars analysis 0 Page 1 of 2 ARS DIGIT ANALYSIS TABLE Location: all Percent Full: 0 Dialed Total Route Call Node ANI String Min Max Pattern Type Num Reqd pubu n fnpa n svcl n pubu n pubu n pubu n The route pattern defines which trunk group will be used for the outbound calls and performs any necessary digit manipulation. Use the change route-pattern command to configure the parameters for the service provider trunk route pattern 2 in the following manner. The example below shows the values used for route pattern 2 for outbound call. Pattern Name: Enter a descriptive name.e.g. Bell_cust6. Grp No: Enter the outbound trunk group 2 as defined in Section 5.7. FRL: Set the Facility Restriction Level (FRL) field to a level that allows access to this trunk for all users that require it. The value of 0 is the least restrictive level. Pfx Mrk: 1 The prefix mark (Pfx Mrk) of one will prefix any FNPA 10-digit number with a 1 and leave numbers of any other length unchanged. This will ensure digits are sent to the service provider for the long distance North American Numbering Plan (NANP) numbers. All HNPA 10 digit numbers are left unchanged. Numbering Format: unk-unk: All calls using this route pattern will use the private numbering table. See setting of the Numbering Format in the trunk group form for full details in Section 5.7. change route-pattern 2 Page 1 of 3 Pattern Number: 2 Pattern Name: Bell_cust6 SCCAN? n Secure SIP? n Grp FRL NPA Pfx Hop Toll No. Inserted DCS/ IXC No Mrk Lmt List Del Digits QSIG Dgts Intw 1: n user 2: n user 3: n user 4: n user 5: n user 6: n user BCC VALUE TSC CA-TSC ITC BCIE Service/Feature PARM No. Numbering LAR M 4 W Request Dgts Format Subaddress 1: y y y y y n n rest unk-unk none 2: y y y y y n n rest none Saving Communication Manager Configuration Changes The command save translation all can be used to save the configuration changes made on Communication Manager. 20 of 62

21 6. Configure Avaya Session Border Controller for Enterprise This section covers the configuration of the Avaya Session Border Controller for Enterprise (Avaya SBCE). It is assumed that the software has already been installed. For additional information on these configuration tasks, please see Reference Error! Reference source not found. and Error! Reference source not found.. The compliance test comprises of configuration for two major components: i. Trunk server for the service provider ii. Call server for the enterprise Each component consists of a set of Global Profiles, Domain Policies and Device Specific Settings. The configuration is performed using the Avaya SBCE web user interface as described in the following sections. Trunk server configuration elements for service provider Bell Canada: Global Profiles: o URI Groups o Routing o Topology Hiding o Server Interworking o Signaling Manipulation o Server Configuration Domain Policies: o Application Rules o Media Rules o Signaling Rules o Endpoint Policy Group o Session Policy Device Specific Settings: o Network Management o Media Interface o Signaling Interface o End Point Flows Server Flows o Session Flows Call server configuration elements at the enterprise for Communication Manager: Global Profiles: o URI Groups o Routing o Topology Hiding o Server Interworking o Server Configuration Domain Policies: o Application Rules o Media Rules 21 of 62

22 o Signaling Rules o Endpoint Policy Group o Session Policy Device Specific Settings: o Network Management o Media Interface o Signaling Interface o End Point Flows Server Flows o Session Flows 6.1. Log into the Avaya Session Border Controller for Enterprise Use a Web browser to access the Unify Communication Security (UC-Sec) web interface, enter in the address field of the web browser (not shown), where <ip-addr> is the management LAN IP address of UC-Sec. Enter appropriate credentials and click Sign In. The main page of the UC-Sec Control Center will appear as shown below. 22 of 62

23 To view system information that has been configured during installation, navigate to UC-Sec Control Center System Management. A list of installed devices is shown in the right pane. In the compliance testing, a single device named sipera is added. To view the configuration of this device, click the View Config icon (the third icon from the right) as shown below. The System Information screen shows Network Settings, DNS Configuration and Management IP information provided during installation and corresponds to Figure 1. The Box Type is set to SIP and the Deployment Mode is set to Proxy. Default values are used for all other fields. 23 of 62

24 6.2. Global Profiles Global Profiles allows for configuration of parameters across all UC-Sec appliances Uniform Resource Identifier (URI) Groups URI Group feature allows user to create any number of logical URI groups that are comprised of individual SIP subscribers located in that particular domain or group. These groups are used by the various domain policies to determine which actions (Allow, Block, or Apply Policy) should be used for a given call flow. To add an URI Group, select UC-Sec Control Center Global Profiles URI Groups then click on the Add Group button (not shown). In the compliance testing, an URI Group named CM_Bell_cust6 was added with URI type Regular Expression. It consists of enterprise SIP domains.*avayalab\.com for regular call and.*nonymous\.invalid for private call; service provider SIP domains.*cust6- tor\.vsac\.bell\.ca,.*siptrunking\.bell\.ca and.*unknowncallder\.invalid ; IP addresses in URI-Host of OPTIONS heartbeat originated by Communication Manager 24 of 62

25 .*110\.10\.97\.13 and.*110\.10\.97\.189 ; IP address and value in URI-Host of OPTIONS heartbeat originated by the service provider.*220\.20\.237\.205 and.*avayacs1k. Domain.*nonymous\.invalid is defined for outbound private calls from Communication Manager which URI-Host is masked as anonymous.invalid. And domain name.*unknowncaller\.invalid is defined for outbound private calls from Bell Canada which URI-Host is masked as UNKNOWNCALLER.invalid. The enterprise domain name.*avayalab\.com is for SIP domain defined in ip-network-region 1 (see Section 5.5) and signaling group 1 (see Section 5.6) between Communication Manager and the Avaya SBCE. For the public SIP trunk between the Avaya SBCE and Bell Canada, the URI-Host in the From, PAI and Diversion headers need to include domain.*cust6-tor.vsac.bell.ca while the URI-Host in the Request-URI and To headers will have domain.*siptrunking.bell.ca. These domains are assigned by Bell Canada. The IP addresses and value of URI-Host in OPTIONS heartbeat is defined to route inbound and outbound OPTIONS between Communication Manager and Bell Canada for keep-alive purpose. This URI-Group is used to match the From and To headers in a SIP call dialog received from both Communication Manager and Bell Canada. If there is a match, the Avaya SBCE will apply the appropriate Routing Profile and Server Flow to route inbound and outbound calls to the right destinations. The Routing Profile and Server Flow are configured in Section and Section appropriately. The screenshot below illustrates the URI Listing for URI Group CM_Bell_cust Routing Profiles Routing Profiles define a specific set of packet routing criteria that are used in conjunction with other types of domain policies to identify a particular call flow and thereby ascertain which security features will be applied to those packets. Parameters defined by Routing Profiles include 25 of 62

26 packet transport settings, name server addresses and resolution methods, next hop routing information and packet transport types. To create a Routing Profile, select UC-Sec Control Center Global Profiles Routing then click on the Add Profile button (not shown). In the compliance testing, a Routing Profile named To_Bell_cust6 was created to be used in conjunction with the Server Flow defined for Bell Canada. This entry is to route the outbound call from the enterprise to Bell Canada. In the opposite direction, a Routing Profile named To_CM_cust6 is created to be used in conjunction with the Server Flow defined for Communication Manager. This entry is to route the inbound call from Bell Canada to the enterprise. For detail of Server Flows configurations, please refer to Section Routing Profile for Bell Canada The screenshot below illustrate the UC-Sec Control Center Global Profiles Routing: To_Bell_cust6. If there is a match in the To header of the URI Group CM_Bell_cust6 defined in Section Error! Reference source not found., the call will be routed to the Next Hop Server 1 which is the IP address of Bell Canada SIP trunk on destination port as As shown in Figure 1, Bell Canada SIP trunk is connected with transportation protocol UDP Routing Profile for Communication Manager The Routing Profile To_CM_cust6 in the screenshot below is defined to route call where the To header matches the URI-Group CM_Bell_cust6 defined in Section Error! Reference source not found. to Next Hop Server 1 which is the IP address of Communication Manager, on destination port as As shown in Figure 1, SIP trunk between Communication Manager and the Avaya SBCE is using transportation protocol TCP. 26 of 62

27 Topology Hiding Topology Hiding is a security feature of the Avaya SBCE which allows changing certain key SIP message parameters to hide or mask how the enterprise network may appear to an unauthorized or malicious user. To create a Topology Hiding profile, select UC-Sec Control Center Global Profiles Topology Hiding then click on the Add Profile button (not shown). In this compliance test, two Topology Hiding profiles were created: To_Bell_cust6 and To_CM_cust Topology Hiding Profile for Bell Canada Profile To_Bell is defined to for outbound call to Bell Canada to: Mask URI-Host of the Request-URI and To headers with service provider SIP domain siptrunking.bell.ca to meet the SIP specification requirement of Bell Canada. Mask URI-Host of the From header to service provider SIP domain cust6- tor.vsac.bell.ca. Replace the Record-Route, Via headers and Session Description Protocol (SDP) added by Communication Manager by external IP addresses known to Bell Canada. This implementation is to secure the enterprise network topology and also to meet the SIP requirement from the service provider. The screenshots below illustrate the Topology Hiding profile To_Bell_cust6. 27 of 62

28 Notes: The Criteria should be selected as IP/Domain to give the Avaya SBCE the capability to mask both domain name and IP address present in the URI-Host. The masking applied to the From header also applies to the Referred-By and P- Asserted-Identity headers. The masking applied to the To header also applies to the Refer-To headers Topology Hiding Profile for Communication Manager Profile To_CM_cust6 is defined for inbound call to Communication Manager to: Mask URI-Host of the Request-URI, To and From headers with the enterprise SIP domain avayalab.com. Replace the Record-Route, Via headers and SDP added by Bell Canada by internal IP address known to Communication Manager. The screenshots below illustrate the Topology Hiding profile To_CM_cust6. Notes: 28 of 62

29 The Criteria should be IP/Domain to give the Avaya SBCE the capability to mask both domain name and IP address present in the URI-Host. The masking applies to the From header also applies to the Referred-By and P- Asserted-Identity headers. The masking applies to the To header also applies to the Refer-To headers Server Interworking Server Interworking profile features are configured differently for call server and trunk server. To create a Server Interworking profile, select UC-Sec Control Center Global Profiles Server Interworking then click on the Add Profile button (not shown). In the compliance testing, two profiles Bell_cust6 and CM_cust6 were created for Bell Canada and Communication Manager Server Interworking profile for Bell Canada Profile Bell_cust6 is defined to match the specification of Bell Canada. The General and Advanced settings are configured with following parameters while the other settings for Timers, URI Manipulation and Header Manipulation are kept as default. General settings: Hold Support = None. The Avaya SBCE will not modify the hold/ resume signaling from Communication Manager to Bell Canada. 18X Handling = None. The Avaya SBCE will not handle 18X responses. It keeps the 18X responses unchanged from Communication Manager to Bell Canada. Refer Handling = Unchecked. Avaya SBCE will not handle REFER request. It keeps REFER request unchanged from Communication Manager to Bell Canada. T.38 Support = Unchecked. Bell Canada has not supported T.38 fax in the compliance testing. Privacy Enabled = Unchecked. Avaya SBCE will not mask the From header with anonymous for outbound call to Bell Canada. It depends on Communication Manager to enable/ disable privacy on individual call basis. DTMF Support = None. Avaya SBCE will send original DTMF supported by Communication Manager to Bell Canada. Advanced settings: Record Routes = Both Sides. Avaya SBCE will send the Record-Route header to both call and trunk servers. Topology Hiding: Change Call-ID = Unchecked. Avaya SBCE will not modify the Call-ID header. It keeps original Call-ID unchanged from Communication Manager to Bell Canada. Change Max Forwards = Checked. Avaya SBCE will adjust the original Max- Forwards value from Communication Manager to Bell Canada by reducing the intermediate hops involving in the call flow. 29 of 62

30 Has Remote SBC = Checked. Bell Canada has the SBC which interfaces its Central Office (CO) with enterprise the SIP trunk. The screenshots below illustrate the Server Interworking profile Bell_cust6. 30 of 62

31 Server Interworking Profile for Communication Manager Profile CM_cust6 is defined to match the specification of Communication Manager. The General and Advanced settings are configured with the following parameters while the other settings for Timers, URI Manipulation and Header Manipulation are kept as default. General settings: Hold Support = RFC3264. Communication Manager supports hold/ resume as per RFC X Handling = None. Avaya SBCE will not handle 18X responses. It keeps 18X responses unchanged from Bell Canada to Communication Manager. Refer Handling = Unchecked. Avaya SBCE will not handle REFER request. It keeps REFER request unchanged from Bell Canada to Communication Manager. T.38 Support = Unchecked. Bell Canada has not supported T.38 fax in the compliance test. 31 of 62

32 Privacy Enabled = Unchecked. Avaya SBCE will not mask the From header with anonymous for inbound call to Communication Manager. It depends on Bell Canada to enable/ disable privacy on individual call basis. DTMF Support = None. Avaya SBCE will send original DTMF supported by Bell Canada to Communication Manager. Advanced settings: Record Routes = Both Sides. Avaya SBCE will send the Record-Route header to both call and trunk servers. Topology Hiding: Change Call-ID = Unchecked. Avaya SBCE will not modify the Call-ID header. It keeps original Call-ID unchanged from Bell Canada to Communication Manager. Change Max Forwards = Checked. Avaya SBCE will adjust the original Max- Forwards value from Bell Canada to Communication Manager by reducing the intermediate hops involving in the call flow. Has Remote SBC = Checked. Communication Manager is directly connected to Avaya SBCE without a remote SBC. The screenshots below illustrate the Server Interworking profile CM_cust6. 32 of 62

33 33 of 62

34 Signaling Manipulation Signaling Manipulation feature allows the ability to add, change and delete any of the headers in a SIP message. This feature will add the ability to configure such manipulation in a highly flexible manner using a proprietary scripting language called SigMa. The SigMa scripting language is designed to express any of the SIP header manipulation operations to be done by the Avaya SBCE. Using this language, a script can be written and tied to a given Server Configuration which is configured in the next steps through the EMS GUI. The Avaya SBCE appliance then interprets this script at the given entry point or hook point. These Application Notes will not discuss the full feature of the Signaling Manipulation but will show an example of a script created during compliance testing to aid in Topology Hiding. 34 of 62

35 To create a Signaling Manipulation script, select UC-Sec Control Center Global Profiles Signaling Manipulation then click on the Add Script button (not shown). In the compliance testing, a SigMa script named Bell_cust6 was created for Server Configuration for Bell Canada and described detail as following: within session "ALL" { act on message where %DIRECTION="OUTBOUND" and %ENTRY_POINT="POST_ROUTING" { %HEADERS["P-Asserted-Identity"][1].URI.HOST="cust6-tor.vsac.bell.ca"; append(%headers["contact"][1].uri.user,";tgrp=vsac_ _01a;trunkcontext=siptr unking.bell.ca"); } act on message where %DIRECTION="INBOUND" and %ENTRY_POINT="AFTER_NETWORK" { %HEADERS["From"][1].URI.USER.regex_replace("(\+)",""); %HEADERS["Contact"][1].URI.USER.regex_replace("(\+)",""); } } The statement act on message where %DIRECTION="OUTBOUND" and %ENTRY_POINT="POST_ROUTING" is to specify the script will take effect on all type of SIP messages for outbound calls to Bell Canada and the manipulation will be done after routing. The manipulation will be according to the rules contained in this statement. The Topology-Hiding profile Bell_cust6 could mask URI-Host of the P-Asserted-Identity header successfully in request SIP messages. As a limitation, however, the P-Asserted-Identity header in response SIP messages will still contain the private enterprise SIP domain. Therefore, a SigMa rules is used to correct the URI-Host of the P-Asserted-Identity header as shown in the screenshot below. %HEADERS["P-Asserted-Identity"][1].URI.HOST="cust6-tor.vsac.bell.ca"; Bell Canada also requires that the Contact header must include a pre-defined trunk group ID, this value is obtained by Bell Canada and it is assigned per individual SIP trunk basis. In the certification testing, the trunk group ID was inserted in the Contact header as shown the following rule. append(%headers["contact"][1].uri.user,";tgrp=vsac_ _01a;trunkcontext=siptrun king.bell.ca"); The statement act on message where %DIRECTION="INBOUND" and %ENTRY_POINT="AFTER_NETWORK" is to specify the script will take effect on all types of SIP messages for inbound calls from Bell Canada and the manipulation will be done before routing. The manipulation will be according to the rules contained in this statement. In the compliance testing, Bell Canada sent + sign in URI-User of the From and Contact headers. Two rules as shown in the screenshot below are added to remove the + sign to make the dialing plan compliant to North America numbering. 35 of 62

36 %HEADERS["From"][1].URI.USER.regex_replace("(\+)",""); %HEADERS["Contact"][1].URI.USER.regex_replace("(\+)",""); Note: The SigMa script for Server Configuration of Communication Manager is not necessary as all signaling manipulations have been done for Server Configuration of Bell Canada which will apply to both inbound and outbound traffics Server Configuration Server Configuration screen contains four tabs: General, Authentication, Heartbeat, and Advanced. These tabs are used to configure and manage various specific parameters such as TCP and UDP port assignments, heartbeat signaling parameters, DoS security statistics and trusted domains. To create a Server Configuration entry, select UC-Sec Control Center Global Profiles Server Configuration then click on the Add Profile button (not shown). In the compliance testing, two separate Server Configurations were created, server entry Bell_cust6 for Bell Canada and server entry CM_cust6 for Communication Manager Server Configuration for Bell Canada The Server Configuration named Bell_cust6 was added for Bell Canada, it will be discussed in detail as below. The General, Authentication and Advanced tabs are provisioned. The Heartbeat tab, however, is kept disabled as default to allow the Avaya SBCE to forward the OPTIONS heartbeat originated from Communication Manager to Bell Canada to query for the status of the SIP trunk. Two tabs of Dos Whitelist and Dos Protection are automatically added by checking on the option to Enable DoS Protection under Advanced tab. These tabs are kept unchanged to use the default configurations. In the General tab, specifies Server Type for Bell Canada as a Trunk Server. The connection parameters have also been defined as shown in the screenshot below. In this compliance testing, Bell Canada supported transport protocol UDP and listens on port of 62

37 Bell Canada implements Digest Authentication on the SIP trunk which requires enterprise to provide proper information in the Authorization header for authentication purpose. In the compliance testing, the Avaya SBCE was configured to support Digest Authentication for trunk server under Authentication tab as shown in the screenshot below. It is set with information of User Name, Realm and Password which are obtained from Bell Canada. Under Advanced tab, check on the Enable DoS Protection. For Interworking Profile drop down list, select Bell_cust6 as defined in Section Error! Reference source not found. and for Signaling Manipulation Script drop down list, select Bell_cust6 as defined in Section Error! Reference source not found.. These configurations are applied to the specific SIP profile and SigMa rules for the traffic from and to Bell Canada. The other settings are kept as default. 37 of 62

38 Server Configuration for Communication Manager The Server Configuration named CM_cust6 was added for Communication Manager and is discussed in detail as below. Only the General and Advanced tabs required provisioning. The Heartbeat tab is kept disabled as default to allow the Avaya SBCE to forward the OPTIONS heartbeat from Bell Canada to Communication Manager to query for the status of the SIP trunk. In the General tab, specifies Server Type for Communication Manager as Call Server. The connection parameters have also been defined as shown in the screenshot below. In this compliance testing, Communication Manager Signaling Group was configured with transport protocol TCP and listened on port For detail configuration, please refer to Section of 62

39 Under Advanced tab, for Interworking Profile drop down list, select CM_cust6 as defined in Section Error! Reference source not found. and for Signaling Manipulation Script drop down list select None. The other settings are kept as default Domain Policies Domain Policies feature configures, applies, and manages various rule sets (policies) to control unified communications based upon various criteria of communication sessions originating from or terminating in the enterprise. These criteria can be used to trigger policies which, in turn, activate various security features of the UC-Sec security device to aggregate, monitor, control, and normalize call flows. There are default policies available to use, or a custom domain policy can be created. 39 of 62

40 Application Rules Application Rules define which types of SIP-based Unified Communications (UC) applications the Avaya SBCE will protect.i.e. voice, video, and/or Instant Messaging (IM). In addition, it is possible to determine the maximum number of concurrent voice and video sessions in order to prevent resource exhaustion. An Application Rule was created to set the number of concurrent voice traffic. The sample configuration cloned and modified the default application rule to increase the number of Maximum Concurrent Session and Maximum Sessions Per Endpoint. To clone an application rule, navigate to UC-Sec Control Center Domain Policies Application Rules, select the default rule then click on Clone Rule button (not shown). Enter a descriptive name.e.g. BellCanada_AppR for the new rule then click on the Finish button. Click Edit button (not shown) to modify the rule. Set the Maximum Concurrent Sessions and Maximum Session Per Endpoint for the Voice application to a value high enough for the amount of traffic the network is able process. The following screen shows the modified Application Rule with the Maximum Concurrent Sessions and Maximum Session Per Endpoint set to In the compliance testing, Communication Manager was programmed to control the concurrent sessions by setting the number of members in the trunk group (Section 5.7) to the allotted amount. Therefore, the values in the Application Rule named BellCanada_AppR were set high enough to be considered non-blocking. 40 of 62

41 Media Rules Media Rules define RTP media packet parameters such as prioritizing encryption techniques and packet encryption techniques. Together these media-related parameters define a strict profile that is associated with other SIP-specific policies to determine how media packets matching these criteria will be handled by the UC-Sec security product. A custom Media Rule is created to set the Quality of Service and Media Anomaly Detection. The sample configuration showed Media Rule BellCanada_MediaR which was created and used for both the enterprise and Bell Canada networks. To create a Media Rule, navigate to UC-Sec Control Center Domain Policies Media Rules, select the default-low-med rule then click on the Clone Rule button (not shown). Enter a descriptive name.e.g. BellCanada_MediaR for the new rule then click on the Finish button. 41 of 62

42 When the RTP packets of a call are shuffled from Communication Manager to an IP phone, the Avaya SBCE interprets this as an anomaly and an alert will be created in the Incidents Log. Disabling Media Anomaly Detection could prevent the RTP Injection Attack alerts from being created during an audio shuffling. To modify the rule, select the Media Anomaly tab and click on the Edit button (not shown). Then uncheck Media Anomaly Detection and click on the Finish button. On the Avaya SBCE, Media Silencing feature detects the silence when the call is in progress. If the silence is detected and exceeds the allowed duration, the Avaya SBCE generates alert in the Incidents Log. In the compliance testing, the Media Silencing detection was disabled to prevent the call from unexpectedly being disconnected due to RTP packet lost on the public Internet network. To modify Media Silencing, select the Media Silencing tab and click on the Edit button (not shown). Then uncheck Media Silencing and click on the Finish button. Under Media QoS tab, click on the Edit button (not shown) to configure the Quality of Service (QoS). The Avaya SBCE can be configured to mark the Differentiated Services Code Point (DSCP) in the IP packet header with specific values to support Quality of Services policies for the media. The following screen shows the QoS values used for the compliance testing. 42 of 62

43 Signaling Rules Signaling Rules define the action to be taken (Allow, Block, Block with Response, etc.) for each type of SIP-specific signaling request and response message. When SIP signaling packets are received by the UC-Sec, they are parsed and pattern-matched against the particular signaling criteria defined by these rules. Packets matching the criteria defined by the Signaling Rules are tagged for further policy matching. To clone a signaling rule, navigate to UC-Sec Control Center Domain Policies Signaling Rules, select the default rule then click on the Clone Rule button (not shown). In the compliance testing, two Signaling Rules were created one for Bell Canada and a second for Communication Manager Signaling Rule for Bell Canada Clone a Signaling Rule with a descriptive name.e.g. BellCanada_SigR for Bell Canada and click on the Finish button. 43 of 62

44 The BellCanada_SigR was configured to allow the Avaya SBCE to accept inbound and outbound call requests from Bell Canada. Cloning the Signaling Rule default, the BellCanada_SigR will block all requests with 403 Forbidden. To start accepting calls, go to General tab, click on the Edit button (not shown). Then change Inbound and Outbound Requests to Allow as shown in following screenshot. 44 of 62

45 On the Signaling QoS tab, select the proper Quality of Service (QoS). The Avaya SBCE can be configured to mark the Differentiated Services Code Point (DSCP) in the IP packet header with specific values to support Quality of Services policies for signaling. The following screen shows the QoS value used for the compliance testing Signaling Rule for Communication Manager Clone a Signaling Rule with a descriptive name.e.g. CM_SigR for Communication Manager and click on the Finish button. This CM_SigR was configured to allow the Avaya SBCE to accept inbound and outbound call requests from Communication Manager. Cloning the Signaling Rule default, the CM_SigR will block all requests with 403 Forbidden. To start accepting calls, select CM_SigR then go to General tab, click on the Edit button (not shown). Then change Inbound-Requests and Outbound-Requests to Allow as shown in following screenshot. 45 of 62

46 On the Signaling QoS tab, select the proper Quality of Service (QoS). The Avaya SBCE can be configured to mark the Differentiated Services Code Point (DSCP) in the IP packet header with specific values to support Quality of Services policies for signaling. The following screen shows the QoS value used for the compliance testing. 46 of 62

47 Endpoint Policy Groups The rules created within the Domain Policy section are assigned to an Endpoint Policy Group. The Endpoint Policy Group is then applied to a Server Flow defined in the next section. Endpoint Policy Groups were separately created for Bell Canada and Communication Manager. To create a policy group, navigate to UC-Sec Control Center Domain Policies Endpoint Policy Groups and click on the Add Group button (not shown) Endpoint Policy Group for Bell Canada The following screen shows BellCanada_PolicyG created for Bell Canada. Set Application and Media rules created in Section Error! Reference source not found. and Section Error! Reference source not found.. Set Signaling rule BellCanada_SigR created in Section Set Border and Time of Day rules to default. Set Security rule to default-high Endpoint Policy Group for Session Manager The following screen shows policy group CS1K_PolicyG created for Communication Manager. Set Application and Media rules created in Section Error! Reference source not found. and Section Error! Reference source not found.. Set Signaling rule CM_SigR created in Section Set the Border and Time of Day rules to default. Set the Security rule to default-low. 47 of 62

48 Session Policy Session Policy applies base on the source and destination of a media session e.g. which codec to be applied to the media session between its source and destination. The source and destination are defined in URI Group in Section In this sample configuration, the Session Policy named Bell_cust6 was created to match to codec configuration for Bell Canada. The policy also allows the Avaya SBCE to anchor media in offnet call forward and call transfer scenarios. To clone a common Session Policy which applies to both Bell Canada and Communication Manager, navigate to UC-Sec Control Center Domain Policies Session Policies, select the default rule then click on the Clone Rule button (not shown). Enter a descriptive name.e.g. Bell_cust6 for the new policy and click on the Finish button. Bell Canada supports voice codec G.729 and G.711MU in prioritized order with payload 101 for RFC2833/ DTMF. To define Codec Prioritization for Audio Codec, select the profile Bell_cust6 created above, click on the Edit button (not shown). Select Preferred Codec #1 as G.711MU, Preferred Codec #2 as G.729 and Preferred Codec #3 as Dynamic (101) for RFC2833/ DTMF. Check Allow Preferred Codecs Only to prevent the unsupported codec from being sent to both ends. 48 of 62

49 Notes: Bell Canada has not supported T.38 fax. This Session Policy prioritizes voice codec G.711MU to establish the voice call. It is mandatory for a G.711MU fax call to be successful established because both Bell Canada and Communication Manager cannot switch the voice call using different codec to G.711MU for fax. Under Media tab of the Session Policy Bell_cust6 created above, click on the Edit button (not shown) then check on Media Anchoring to allow the Avaya SBCE to anchor media in off-net call forward and call transfer scenarios. 49 of 62

50 6.4. Device Specific Settings Device Specific Settings feature allows aggregate system information to be viewed, and various device-specific parameters to be managed to determine how a particular device will function when deployed in the network. Specifically, it gives the ability to define and administer various device-specific protection features such as Message Sequence Analysis (MSA) functionality and protocol scrubber rules, end-point and session call flows, as well as the ability to manage system logs and control security features Network Management The Network Management screen is where the network interface settings are configured and enabled. During the installation process of the Avaya SBCE, certain network-specific information is defined such as device IP addresses, public IP addresses, subnet mask, gateway, etc. to interface the device to the network. This information populates the various Network Management tab displays, which can be edited as needed to optimize device performance and network efficiency. Navigate to UC-Sec Control Center Device Specific Settings Network Management. Under Network Configuration tab, verify the IP addresses assigned to the interfaces and that the interfaces are enabled. The following screen shows the private interface is assigned to A1 and the public interface is assigned to B1 appropriate to the parameters shown in the Figure of 62

51 On the Interface Configuration tab, enable the interfaces connecting to the inside and outside networks. To enable an interface click it s Toggle State button. The following screen shows interface A1 and B1 were Enabled Media Interface Media Interface screen is where the media ports are defined. The Avaya SBCE will listen for RTPs on the defined ports. To create a new Media Interface, navigate to UC-Sec Control Center Device Specific Settings Media Interface and click on the Add Media Interface button (not shown). Two separate Media Interfaces are needed for both the inside and outside interfaces. The following screen shows the Media Interfaces named InsideMedia and OutsideMedia_Bell_cust6 were created for the compliance testing. 51 of 62

52 Note: After the media interfaces are created, an application restart is necessary before the changes will take effect Signaling Interface Signaling Interface screen is where the SIP signaling port is defined. The Avaya SBCE will listen for SIP request on the defined port. To create a new Signaling Interface, navigate to UC-Sec Control Center Device Specific Settings Signaling Interface and click on the Add Signaling Interface button (not shown). Two separate Signaling Interfaces are needed for both inside and outside interfaces. The following screen shows the Signaling Interfaces named InsideSIP and OutsideSIP_Bell_cust6 were created in the compliance testing with TCP/5060 for the inside interface and UDP/5060 respectively for the outside interface End Point Flows - Server Flow When a packet is received by UC-Sec, the content of the packet (IP addresses, URIs, etc.) is used to determine which flow it matches. Once the flow is determined, the flow points to a policy which contains several rules concerning processing, privileges, authentication, routing, etc. Once 52 of 62

53 routing is applied and the destination endpoint is determined, the policies for this destination endpoint are applied. The context is maintained, so as to be applied to future packets in the same flow. The following screen illustrates the flow through the Avaya SBCE to secure a SIP trunk call. In the compliance testing, two separate Server Flows were created for Bell Canada and Communication Manager. To create a Server Flow, navigate to UC-Sec Control Center Device Specific Settings End Point Flows, select the Server Flows tab and click on the Add Flow button (not shown). In the new window that appears, enter the following values while the other fields are kept as default. Flow Name: Enter a descriptive name. Server Configuration: Select a Server Configuration created in Section to which the Server Flow associates. URI Group: Select the URI Group created in Section to assign to the Sever Flow. Received Interface: Select the Signaling Interface created in Section from which the Server Configuration is allowed to receive SIP traffic. Signaling Interface: Select the Signaling Interface created in Section which is used to send SIP traffic to the Server Configuration. Media Interface: Select the Media Interface created in Section which is used to send RTP traffic to the Server Configuration. End Point Policy Group: Select the End Point Policy Group created in Section to assign to the Server Flow. Routing Profile: Select the Routing Profile created in Section which is used to route inbound SIP traffic from the Server Configuration. Topology Hiding Profile: Select the Topology Hiding profile created in Section to apply to outbound SIP traffic to the Server Configuration. Click on the Finish button. The following screen shows the Sever Flow named Bell_cust6 for Bell Canada. 53 of 62

54 The following screen shows the Sever Flow named CM_cust6 for Communication Manager. 54 of 62

55 Session Flow Session Flows features allow to define certain parameters that pertain to the media portions of a call, whether it originates from within the enterprise or from without. These features provide the complete and unparalleled flexibility to monitor, identify, and control very specific types of calls based upon these user-definable parameters. Session Flows profiles SDP media parameters, to completely identify and characterize a call placed through the network. A common Session Flow is created for both the Bell Canada and Communication Manager. To create a session flow, navigate to UC-Sec Control Center Device Specific Settings Session Flows then click on the Add Flow button (not shown). In the new window that appears, enter the following values while the remaining fields are kept as default. Flow Name: Enter a descriptive name. URI Group #1: Select the URI Group created in Section to assign to the Session Flow as the source URI Group. URI Group #2: Select the URI Group created in Section to assign to the Session Flow as the destination URI Group. Session Policy: Select the Session Policy created in Section to assign to the Session Flow Click on the Finish button. 55 of 62

56 Note: A unique URI Group is used for source and destination, since it contains multiple URIs defined for the source as well as for the destination. The following screen shows the Session Flow named Bell_cust6. 7. Bell Canada SIP Trunking Configuration Bell Canada is responsible for the configuration of its SIP Trunking Service. The customer will need to provide the IP address used to reach the Avaya SBCE at enterprise side. Bell Canada will provide the customer with the necessary information to configure the SIP trunk connection from enterprise to the Bell Canada. The information provided by Bell Canada includes: IP address of the Bell Canada Session Border Controller Bell Canada SIP domain Enterprise SIP domain Supported codecs DID numbers IP addresses and port numbers used for signaling or media through any security devices Digest Authentication information The sample configuration between Bell Canada and the enterprise for the compliance testing is a static configuration. There is no registration on the SIP trunk implemented on either Bell Canada or enterprise side. 8. Verification and Troubleshooting This section provides verification steps that may be performed in the field to verify that the solution is configured properly. This section also provides a list of useful troubleshooting commands. 56 of 62