Integration Reference Manual. SIP Server 8.1.1

Transcription

1 Integration Reference Manual SIP Server /4/2018

2 Table of Contents SIP Server 8.1 Integration Reference 3 Siemens OpenScape Voice 5 SIP Server and OpenScape Voice Integration Overview 6 Configuring OpenScape Voice 9 Configuring DN Objects 33 Support for First-Party Call-Control Operations 43 Support for Split-Node Deployments 44 Handling Call Forwarding Loop 46 Cisco Unified Communications Manager 47 Managing Agents over SIP 48 Configuring CUCM 53 Configuring DN Objects 54 Asterisk 57 SIP Server and Asterisk Integration Overview 58 Asterisk for Business Calls Routing 71 Asterisk as a Voic Server 76 Configuring Asterisk 81 Asterisk as a Media Server 89 Cisco Media Gateway 93 SIP Server and Cisco Media Gateway Integration Overview 94 Configuring Cisco Media Gateway 96 Configuring DN Objects 102 F5 Networks BIG-IP LTM 104 SIP Server and BIG-IP LTM Integration Overview 105 Configuring SIP Server HA 109 Configuring BIG-IP LTM 112 Configuring TLS 136 Deployment Architecture Example 140 RedSky E911 Manager 141

3 SIP Server 8.1 Integration Reference SIP Server 8.1 Integration Reference Welcome to the SIP Server 8.1 Integration Reference. This document introduces you to the concepts, terminology, and procedures related to integrating SIP Server with SIP endpoints, softswitches, and gateways. The reference information includes, but is not limited to, configuration options, limitations, and switch-specific functionality. This document is designed to be used along with the Framework 8.1 SIP Server Deployment Guide. SIP Endpoint Application Notes SBC Application Notes Polycom SIP Phones CounterPath Bria SIP Phones Yealink SIP Phones AudioCodes/Genesys SIP Phones Grandstream GXP SIP Phones Sonus 1000/2000 SBC Sonus 5000 SBC AudioCodes Mediant SBC Oracle Acme Enterprise SBC CUBE SBC Grandstream GXP1625/GCC1700 SIP Phones Tenacity accessaphone iptty SIP Phones Switch Integrations Siemens OpenScape Voice Cisco Unified Communications Manager Asterisk Alcatel OXE BroadSoft BroadWorks RedSky E911 Manager Integration Reference Manual 3

4 SIP Server 8.1 Integration Reference SIP Trunks Application Notes Media Gateway Application Notes AT&T IP Toll Free with AudioCodes Mediant SBC AT&T IP Flexible Reach with AudioCodes Mediant SBC AudioCodes Mediant Gateway Cisco Media Gateway AT&T IPTF and IPXC with Sonus SBC GSX/ PSX Colt SIP Trunk with AudioCodes Mediant SBC Telenor SIP Trunk with AudioCodes Mediant SBC Network Load Balancer Integrations SIP Endpoint SDK Windstream SIP Trunk with AudioCodes Mediant SBC CenturyLink F5 Networks BIG-IP SIP Trunk LTMwith AudioCodes Mediant SBC SIP Endpoint SDK AireSpring SIP Trunk with AudioCodes Mediant SBC BT Italia SIP Trunk with AudioCodes Mediant SBC Integration Reference Manual 4

5 Siemens OpenScape Voice Siemens OpenScape Voice This topic describes how to integrate SIP Server with the Siemens OpenScape Voice. It contains the following sections: Overview Configuring OpenScape Voice Configuring DN Objects Support for First-Party Call-Control Operations Support for Split-Node Deployments Handling Call Forwarding Loop Note: The instructions in this topic assume that OpenScape Voice is fully functional and is routing calls before Genesys products are installed. They also assume that SIP Server has already been configured to function properly in stand-alone mode, and that configuration between SIP Server and Universal Routing Server (URS) has already been completed. Integration Reference Manual 5

6 Siemens OpenScape Voice SIP Server and OpenScape Voice Integration Overview SIP Server and OpenScape Voice Integration Overview The SIP Server and OpenScape Voice integration solution that is described in this topic is not the only method that will work. Although there are other methods, this is the only one that has been tested and approved by Genesys, and that is supported by Genesys Customer Support. This topic contains best-practice guidelines that have been determined by both Genesys and Siemens Engineering departments. Deviating from the solution that is described in this topic can have unexpected consequences. Although this topic provides steps to log in to OpenScape Voice, login credentials are site-specific and should be different for each installation, due to the nature of the equipment. Note: The OpenScape Voice screen captures in this topic were taken from the HiPath Assistant 3.0R0.0.0 Build 860. Depending on your onsite version, the onscreen output might differ. Assumptions The integration solution described in this topic makes the following assumptions about the desired call flow: Agent endpoints (SIP Phones) register directly with OpenScape Voice. Genesys SIP Server does not signal these endpoints directly; instead, it always goes through OpenScape Voice. A single instance of SIP Server is configured behind OpenScape Voice. If it is used for treatments, music on hold, MCU (Multipoint Conference Unit) recording, and supervisor functionality, Media Server is signaled only by SIP Server. No direct SIP signaling occurs between OpenScape Voice and Media Server. For information about configuring SIP Server to use Media Server, see the Framework 8.1 SIP Server Deployment Guide. In the event that these assumptions are not valid for the required deployment, you can still configure SIP Server for integration with OpenScape Voice; however, you might have to modify the configuration that is described in this topic. To configure multiple instances of SIP Server to work with OpenScape Voice, create a unique Numbering Plan for each SIP Server and each group of agents that is associated with it and related switch entities, as described in Configuring OpenScape Voice. For example, to configure two SIP Servers, create two unique SIP Server Numbering Plans, two Agent Numbering Plans, and all related switch entities as required for each Numbering Plan. For GVP integration with SIP Server, the configuration must be performed on the SIP Server side, not on the OpenScape Voice side. Integration Reference Manual 6

7 Siemens OpenScape Voice SIP Server and OpenScape Voice Integration Overview Endpoint Support When Genesys SIP Server is integrated with Siemens OpenScape Voice, the endpoints register directly to the Siemens switch. Genesys validates the integration using a representative selection of endpoints recommended by Siemens. However, this selection is not an exhaustive list of endpoints, and Genesys defers the official endpoint support statement to Siemens. Also note that the Click-to-Answer feature requires the referenced Patchset on OpenScape Voice and a device that supports it. Deployment Architecture A successful implementation requires that Genesys SIP Server be in the communications path for every call in the contact center, both internal and external (see the following figure). This can be done efficiently and effectively by using multiple Numbering Plans. Note, however, that gateways should not be put into the Global Numbering Plan. Doing so can cause complications by routing gateway calls directly to the agents, bypassing SIP Server. SIP Server - OpenScape Voice Deployment Architecture In the General Numbering Plan (the Numbering Plan that contains the gateways), the contact center is given a range of numbers for agents (assuming that the agents have direct lines) and Routing Points. Those numbers route directly to SIP Server, which then routes the calls accordingly. SIP Server must have its own Numbering Plan, because it will make calls on behalf of the agents. These calls are sent to the E.164 Numbering Plan (to reach internal phones) or, if necessary, to available gateways. The Agent Numbering Plan is simple; all calls go to SIP Server. The configuration of SIP Server Numbering Plan will determine how the calls should be routed. Integration Reference Manual 7

8 Siemens OpenScape Voice SIP Server and OpenScape Voice Integration Overview Accessing Configuration Tools HiPath Assistant The HiPath Assistant is a thin, Web-based application that runs within a browser to provide a common user experience. It is primarily intended for use as a Service Management Center that provides administrators of communications networks with provisioning information and control over their subscribers' voice services. Its purpose is to provide enterprises with a cost-effective, IP-based system that works seamlessly with OpenScape Voice. For enterprises with more than 5,000 lines, the HiPath Assistant can be installed on an external server as a standalone (off-board) installation, separated from the OpenScape Voice switch. To access the HiPath Assistant, enter the following URL in your browser: Address> Command-Line Interface OpenScape Voice also has an SSL (Secure Sockets Layer) command-line interface that you can access. SSL is the same as Telnet, except that it is encrypted to provide more security. There are many SSL client applications available on the Web for free, in addition to commercial applications. A common application for SSL is PuTTY. You can download PuTTY from the following web page: After you have your SSL application, configure it to connect to the management IP address of OpenScape Voice. Integration Task Summary To integrate SIP Server with OpenScape Voice, complete the following procedures: 1. Configure OpenScape Voice. 2. Configure DN objects in the Configuration Layer. Integration Reference Manual 8

9 Siemens OpenScape Voice Configuring OpenScape Voice Configuring OpenScape Voice This page provides an overview of the main steps that are required to configure OpenScape Voice. Complete all steps in the order in which they are listed. Configuring OpenScape Voice 1. Check that OpenScape Voice is working. Check Minimum Functionality in OpenScape Voice The procedures in this topic assume that OpenScape Voice is functional and routing calls appropriately. There should already be at least one Numbering Plan that has gateways and nonagent subscribers in it. For more information, see Siemens OpenScape Voice-specific documentation. 2. Configure the Numbering Plans. Configuring Numbering Plans The instructions in this topic assume that OpenScape Voice is functional and routing calls appropriately. There should already be at least one Numbering Plan with configured gateways and nonagent subscribers. Purpose To create the Numbering Plans that will contain the Agents and SIP Server. Start 1. Log in to the HiPath Assistant, and navigate to the Business Group of the contact center that you want to configure--for example, GenesysLab (see the following figure). Integration Reference Manual 9

10 Siemens OpenScape Voice Configuring OpenScape Voice Selecting the Business Group 2. Click Private Numbering Plans (see the following figure). Selecting Private Numbering Plans 3. In the Private Numbering Plans dialog box, click Add. 4. Add two new Private Numbering Plans: one for your agents and one for SIP Server itself--for example, Agents and SIPServer, respectively (see the following figure) Creating Private Numbering Plans When you are finished, the dialog box shown in the following figure appears. Integration Reference Manual 10

11 Siemens OpenScape Voice Configuring OpenScape Voice Private Numbering Plans End 3. Configure the Endpoint Profile. Configuring a SIP Server Endpoint Profile Start 1. Click Private Numbering Plan, and then click the SIP Server Numbering Plan for example, SIPServer (see the following figure). Selecting the Numbering Plan 2. Click Endpoint Management, and then click Endpoint Profiles (see the following figure). Selecting Endpoint Profiles Integration Reference Manual 11

12 Siemens OpenScape Voice Configuring OpenScape Voice 3. In the Endpoint Profile: <Business Group> dialog box on the General tab, enter a name for this configured Endpoint Profile in the Name text box. This will associate the endpoint that uses it with the Numbering Plan in which the Endpoint Profile was created (see the following figure). Configuring an Endpoint Profile 4. (Optional) If there are existing dialing rules and conventions that require the use of Class of Service and Routing Areas, enter that information. As a general rule, give this Endpoint Profile the same calling access as you would give to your agents 5. When you are finished, click Save. 6. In the Endpoint Profile: <Business Group> dialog box on the Services tab, enable the Call Transfer service, by selecting Yes from the drop-down menu (see the following figure). Enabling the Call Transfer Service End 4. Configure the Endpoint. Integration Reference Manual 12

13 Siemens OpenScape Voice Configuring OpenScape Voice Configuring a SIP Server Endpoint Start 1. Click Private Numbering Plan, and then click the SIP Server Numbering Plan for example, SIPServer. 2. Click Endpoints, and then click Add (see the following figure). Selecting Endpoints 3. In the Endpoint: <Business Group> dialog box, click the General tab, and do the following: a. In the Name text box, enter a unique name for this configured Endpoint. b. Select the Registered check box. c. Set the Profile text box to the Endpoint Profile that you created for SIP Server, by clicking the browse (...) button. Configuring Endpoints: General Tab 4. In the Endpoint: <Business Group> dialog box, click the SIP tab, and do the following: a. Make sure that the Type text box is set to Static. b. In the Endpoint Address text box, enter the IP address of SIP Server. c. From the Transport protocol drop-down box, select UDP or TCP, depending on SIP Server. Integration Reference Manual 13

14 Siemens OpenScape Voice Configuring OpenScape Voice Configuring Endpoints: SIP Tab 5. Click the Attributes tab, and do the following: a. Select the Transfer HandOff check box. There is a known limitation of the Transfer HandOff feature. The full number must be used to transfer a call when this feature is activated. b. Select the Do not Send Invite without SDP check box. c. When you are done, click Save. Configuring Endpoints: Attributes Tab 6. Click the Aliases tab, and then click Add. 7. In the Alias dialog box, do the following: a. In the Name text box, enter the IP address that you entered in the Endpoint Address text box in Step 4. b. Unless you have OpenScape Voice version 5 and later, set the Type text box to SIP URL. (This is done automatically in version 5.) Integration Reference Manual 14

15 Siemens OpenScape Voice Configuring OpenScape Voice c. Click OK. Configuring Endpoints: Aliases Tab 8. In the Endpoint dialog box, click Save. 9. When the confirmation message box appears, informing you that the Endpoint was created successfully, click Close. End 5. Configure Gateway Destinations. Configuring SIP Server Destinations for Gateways Purpose To create Gateway Destinations for SIP Server to route calls. The Endpoints of such Gateway Destinations must already be configured in OpenScape Voice. SIP Server routes calls to Gateways and to phones. Because calls to the phones are routed via the E.164 Numbering Plan, no Destinations have to be configured for them. Start 1. Click Private Numbering Plan, and then click the SIP Server Numbering Plan for example, SIPServer. 2. Click Destinations and Routes, then Destinations, and then click Add (see the following figure). Integration Reference Manual 15

16 Siemens OpenScape Voice Configuring OpenScape Voice Selecting Destinations 3. In the Destination dialog box, on the General tab, do the following: a. In the Name text box, enter a unique name for the Destination for example, SIPServerGWDEST. The name must be unique within the switch configuration database. b. Make sure that all check boxes are cleared. c. When you are finished, click Save. Configuring a Gateway Destination 4. In the Destination - <Business Group> dialog box, click the Destination that you just created. 5. Click the Routes tab, and then click Add. 6. In the Route dialog box, do the following: a. In the ID text box, enter 1 for this particular route. b. Set the Type text box to SIP Endpoint. c. Set the SIP Endpoint text box to the Endpoint that you created in Configuring a SIP Server Endpoint by clicking the browse (...) button, selecting the Numbering Plan that contains the Endpoint for the gateway to which you will be routing (for example, the general Numbering Plan), and then selecting the Endpoint. d. Do not modify the digit string for calls that are being routed from SIP Server. All modifications to the digit string should be completed before the calls arrive to SIP Server. Integration Reference Manual 16

17 Siemens OpenScape Voice Configuring OpenScape Voice Configuring a Route for a Gateway Destination 5. When you are finished, click Save. 6. When the confirmation message box appears, informing you that the Route was added successfully, click Close. 7. In the Destination dialog box, click OK. You will now be able to view the Route that you just created in the Routes dialog box. 8. Repeat Steps 2-9 to create other gateway Destinations for SIP Server, as necessary. End 6. Configure Prefix Access Codes. Configuring SIP Server Prefix Access Codes Purpose To configure Prefix Access Codes that SIP Server will dial to reach Subscribers and Gateways. Integration Reference Manual 17

18 Siemens OpenScape Voice Configuring OpenScape Voice Start 1. Click Private Numbering Plan, and then click the SIP Server Numbering Plan for example, SIPServer. 2. Click Translation, click Prefix Access Codes, and then click Add (see the following figure). Selecting Prefix Access Codes 3. For calls that are to be routed to Subscribers: In the Prefix Access Code: <Business Group> dialog box, do the following: a. In the Prefix Access Code text box, enter the digits you want to use to route calls to Subscribers. Note: For the SIP Server Numbering Plan, minimal modifications should be required. Dialed numbers should be modified before they reach SIP Server. This convention should be followed at all sites, to simplify the solution as much as possible. b. Set the Prefix Type text box to Off-net Access. c. Set the Nature of Address text box to Unknown. d. Set the Destination Type text box to E164 Destination. e. Click Save. Integration Reference Manual 18

19 Siemens OpenScape Voice Configuring OpenScape Voice Configuring a Prefix Access Code for Calls Routed to Subscribers 6. When the confirmation message box appears, informing you that the Prefix Access Code was created successfully, click Close. 7. If agents will be allowed to make external calls: In the Prefix Access Code dialog box, click Add again. 8. In the Prefix Access Code dialog box, do the following: a. In the Prefix Access Code text box, enter the digits that you want to use to route calls to Gateways. The matched digits will be site-specific, and there should be minimal modification of the digit string. b. Set the Prefix Type text box to Off-net Access. c. Set the Nature of Address text box to Unknown. d. Set the Destination Type text box to None, so you will be able to route the call from a Destination Code. e. Click OK. Integration Reference Manual 19

20 Siemens OpenScape Voice Configuring OpenScape Voice Configuring a Prefix Access Code for Calls Routed to Gateways 6. When the confirmation message box appears, informing you that the Prefix Access Code was created successfully, click Close. End Next Steps Continue with the following procedure, unless calls are routed only to Subscribers: Procedure: Configuring SIP Server Destination Codes 7. Configure Destination Codes. Configuring SIP Server Destination Codes Purpose To configure SIP Server Destination Codes to route calls to non-subscriber devices. Integration Reference Manual 20

21 Siemens OpenScape Voice Configuring OpenScape Voice Start 1. Click Private Numbering Plan, and then click the SIP Server Numbering Plan for example, SIPServer. 2. Click Prefix Access Codes. 3. Click the Prefix Access Code that you created for non-subscriber devices (see the following figure). Selecting a Prefix Access Code 4. In the Prefix Access Code dialog box, click the Destination Codes tab. 5. In the Destination Code dialog box, do the following: a. Set the Destination Type text box to Destination. b. Set the Destination Name text box to the Destination that you created for SIP Server in Configuring SIP Server Destinations for Gateways, by clicking the browse (...) button. Integration Reference Manual 21

22 Siemens OpenScape Voice Configuring OpenScape Voice Configuring a Destination Code 6. Click Save. 7. When the confirmation message box appears, informing you that the Destination Code was created successfully, click Close. End 8. Configure Agent Destinations. Configuring an Agent Destination for SIP Server Purpose To configure a Destination for the Agent Numbering Plan for SIP Server. Start 1. Click Private Numbering Plan, and then click the Agent Numbering plan for example, Agents. Integration Reference Manual 22

23 Siemens OpenScape Voice Configuring OpenScape Voice 2. Click Destinations and Routes, click Destinations, and then click Add. Selecting Destinations 3. In the Destination - <Agent Numbering Plan> dialog box, click the General tab, and then do the following: a. In the Name text box, enter a unique name for the Destination. Note: Destinations must be unique within the switch configuration database, not just within the Numbering Plan and Business Group. b. Make sure that all check boxes are cleared. c. When you are finished, click Save, and then close the dialog box. Configuring a SIP Server Destination in the Agent Numbering Plan 4. Click the Destination that you just created for example, SIPServer. 5. Click the Routes tab, and then click Add. 6. In the Route dialog box, do the following: a. In the ID text box, enter 1. Note: The ID of the first Route must always be 1. b. Set the Type text box to SIP Endpoint. c. Set the SIP Endpoint text box to the Endpoint that you created for SIP Server in Configuring a SIP Server Endpoint, by clicking the browse (...) button. Integration Reference Manual 23

24 Siemens OpenScape Voice Configuring OpenScape Voice d. When you are finished, click Save. Note: Genesys recommends that you not modify the dialed-digit string that is passed on to SIP Server at this point. Configuring a Route for SIP Server in the Agent Numbering Plan 5. When the confirmation message box appears, informing you that the Route was added successfully, click Close. End 9. Configure Agent Access and Destination Codes. Configuring Agent Prefix Access Codes and Destination Codes In this section, you configure dialing patterns for the Agents. Every number that the agent dials must be configured. If an agent dials a four-digit extension, the Prefix Access Code should be configured to convert the dialed-digit string to the full E.164 code that OpenScape Voice expects. If the agent dials a number that must to be routed to an external gateway, make sure that the dialed-digit string is correct for that gateway before it reaches SIP Server. Integration Reference Manual 24

25 Siemens OpenScape Voice Configuring OpenScape Voice As mentioned earlier, all calls must go to SIP Server first; otherwise, the calls will not be visible to SIP Server. In the Private Numbering Plan for agents, every Prefix Access Code must route the call to a Destination Code that points the call to SIP Server. It is best to copy the nonagent Prefix Access Codes from the General Numbering Plan; however, make sure that the destination is always SIP Server. Start 1. Click Private Numbering Plan, and then click the Agent Numbering Plan for example, Agents. 2. Click Translation, click Prefix Access Codes, and then click Add. 3. In the Prefix Access Code dialog box, do the following: a. In the Prefix Access Code text box, enter the digits you that want to use for routing, and any modifications that OpenScape Voice will need to make in order to route the call properly. b. Set the Prefix Type text box to Off-net Access. c. Set the Nature of Address text box to Unknown. d. Set the Destination Type text box to None. e. Click Save, and close the dialog box. Configuring a Prefix Access Code for the Agent Numbering Plan f. In the Prefix Access Code dialog box, click the Prefix Access Code that you just created, and then click the Destination Codes tab. Integration Reference Manual 25

26 Siemens OpenScape Voice Configuring OpenScape Voice 7. In the Destination Code dialog box, click the General tab, and then do the following: a. Do not modify the Destination Code text box. b. Make sure that the Nature of Address text box is set to Unknown. c. Make sure that the Destination Type text box is set to Destination. d. Set the Destination Name text box to the Destination that you created for SIP Server in Configuring an Agent Destination for SIP Server for example, SIPServer--by clicking the browse (...) button. e. When you are finished, click Save. Configuring a Destination Code for the Agent Destination 6. When the confirmation message box appears, informing you that the Destination Code was created successfully, click Close. 7. Repeat Steps 2-6 to create other Prefix Access Codes and Destination Codes, as necessary. End Integration Reference Manual 26

27 Siemens OpenScape Voice Configuring OpenScape Voice 10. Configure Click-to-Answer. Optional Configuration for SIP Server This configuration is not required for the integration to work, however, some might be required by local laws, or make the solution easier to configure. Configuring Click-to-Answer Purpose The Click-to-Answer feature enables agents to click within Genesys Agent Desktop to answer the phone. The Clickto-Answer feature requires the referenced Patchset on OpenScape Voice and a device that supports it. The current procedure provides instructions for OpenStage phones. Start 1. On the phone that you have to configure, select Configuration (see the following figure). Selecting Configuration on the OpenStage Phone 2. Click Incoming calls, and then click CTI calls (see the following figure). Configuring CTI Calls on the OpenStage Phone 3. Select the Allow auto-answer check box, and click Submit (see the following figure). Integration Reference Manual 27

28 Siemens OpenScape Voice Configuring OpenScape Voice Submitting Allow auto-answer on the OpenStage Phone 4. Repeat Steps 1-3 for every agent phone on the switch. End 11. Configure emergency call routing. Optional Configuration for SIP Server This configuration is not required for the integration to work, however, some might be required by local laws, or make the solution easier to configure. Configuring emergency call routing The emergency call routing feature provides alternate call routing in cases in which SIP Server is unavailable, if your local emergency (or 911) laws require some form of alternate routing for agents. During the first 30 seconds after the emergency calling support is activated, calls will fail to route. After that, OpenScape Voice will route calls via the alternate route that you configure and the calls will work. Start 1. Log in to the HiPath Assistant, and navigate to the Business Group of the contact center that you want to configure for example, GenesysLab. 2. Click Private Numbering Plan, and then click the Agent Numbering Plan. 3. Click Destinations and Routes, click Destinations, and then click Add. 4. In the Destination dialog box, do the following: a. In the Name text box, enter a new destination for the gateway through which you want emergency calls to go for example, EmergencyBypass. b. Make sure that all check boxes are cleared. c. Click Save. Integration Reference Manual 28

29 Siemens OpenScape Voice Configuring OpenScape Voice Configuring a Destination for Emergency Call Routing 4. Click the Destination that you just created for example, EmergencyBypass. 5. Click the Routes tab, and then click Add. In this step you are adding a route that goes to SIP Server. This is necessary in order to prevent calls from bypassing SIP Server while it is working. 6. In the Route dialog box, do the following: a. In the ID text box, enter 1. This route goes to SIP Server, just like all the others. b. Set the Type text box to SIP Endpoint. c. Set the SIP Endpoint text box to the Endpoint that you created in Configuring a SIP Server Endpoint. 4. When you are finished, click Save. 5. Click the Destination that you just created for example, EmergencyBypass. 6. Click the Routes tab, and then click Add again. 7. In the Route dialog box, do the following: a. In the ID text box, enter 2. b. Set the Type text box to SIP Endpoint. c. Set the SIP Endpoint text box to the gateway for emergency calling. d. When you are finished, click Save. Integration Reference Manual 29

30 Siemens OpenScape Voice Configuring OpenScape Voice Configuring a Route for Emergency Call Routing 5. Click Prefix Access Codes, and then click Add. 6. In the Prefix Access Code dialog box, do the following: a. In the Prefix Access Code text box, enter the digits for your emergency number. b. Set the Prefix Type text box to Off-net Access. c. Set the Nature of Address text box to Unknown. d. Set the Destination Type text box to None. e. Click Save, and close the dialog box. Integration Reference Manual 30

31 Siemens OpenScape Voice Configuring OpenScape Voice Configuring a Prefix Access Code for Emergency Call Routing 6. In the Prefix Access Code dialog box, click the Destination Codes tab. 7. On the General tab, do the following: a. Make sure that the Destination Type text box is set to Destination. b. Set the Destination Name text box to the Destination that you created in Step 4 for example, EmergencyBypass by clicking the browse (...) button. c. When you are finished, click OK. Integration Reference Manual 31

32 Siemens OpenScape Voice Configuring OpenScape Voice Configuring a Destination Code for Emergency Call Routing End Next Steps Configuration of OpenScape Voice is now complete. Proceed with Configuring DN Objects. Integration Reference Manual 32

33 Siemens OpenScape Voice Configuring DN Objects Configuring DN Objects You configure DN objects for the OpenScape Voice in the Configuration Layer under the Switch object that is assigned to the appropriate SIP Server. 1. Configure a Voice over IP Service DN. Configuring a Voice over IP Service DN Purpose To configure a DN of type Voice over IP Service that specifies the connection and options for OpenScape Voice communication with a SIP Server that is running in Application Server (B2BUA) mode. Start 1. In Configuration Manager, under a configured Switch object, select the DNs folder. From the File menu, select New > DN to create a new DN object. 2. In the New DN Properties dialog box, click the General tab, and then specify the following properties: a. Number: Enter the softswitch name for example, OpenScape Voice. Although this name is currently not used for any messaging, it must still be unique. b. Type: Select Voice over IP Service from the drop-down box. Integration Reference Manual 33

34 Siemens OpenScape Voice Configuring DN Objects Creating a Voice over IP Service DN for OpenScape Voice: Sample Configuration c. Click the Annex tab. d. Create a section that is named TServer. In the TServer section, create options as specified in the following table. Option Name Option Value Description The contact URI that SIP Server uses for communication with the OpenScape Voice softswitch, where <ipaddress> is the IP address of the softswitch and <SIP port> is the SIP port number of the softswitch. contact <ipaddress>:<sip port> TLS configuration: use the following format: contact =<ipaddress>:<sip port>;transport=tls Integration Reference Manual 34

35 Siemens OpenScape Voice Configuring DN Objects Option Name Option Value Description For more information about how to configure SIP Server, see the Transport Layer Security for SIP Traffic section in the SIP Server Deployment Guide. dual-dialog-enabled false makecall-subst-uname 1, or none make-call-rfc3725-flow 1 refer-enabled false ring-tone-on-make-call true Set this option to false if Siemens phones are used in re- INVITE mode for third-party callcontrol (3pcc) operations. For OpenScape Voice version 2.1, set this option to 1.For OpenScape Voice version 2.2 and later, do not configure this option. When this option is set to 1, SIP Server sets the From header to the same value as the To header in the INVITE request, to work around issues with pre-2.2 versions of OpenScape Voice. Set this option to 1.When this option is set to 1, SIP Server selects the SIP call flow number 1 (described in RFC 3725) for a call that is initiated by a TMakeCall request. Set this option to false for SIP Server to use a re-invite request method when contacting the softswitch. This is the only method that is supported in the OpenScape Voice configuration. When this option is set to true, SIP Server connects the caller with an audio ringtone from Stream Manager when the destination endpoint responds with a 180 Ringing message. Integration Reference Manual 35

36 Siemens OpenScape Voice Configuring DN Objects Option Name Option Value Description service-type softswitch Set this option to softswitch. sip-cti-control talk When this option is set to talk, SIP Server instructs the endpoint to go off-hook by sending a SIP NOTIFY message with the Event: talk header. This enables a TAnswerCall request to be sent to SIP Server. SIP Server then sends the NOTIFY message to the switch. Setting this option to talk sets the default for all endpoints that are configured with this softswitch.the talk value is supported only on OpenScape Voice version 2.2 Patchset 14 or later. Note: You must also configure OpenScape Voice to support this functionality. See Configuring Click-to- Answer. sip-ring-tone-mode 1 When this option is set to 1, SIP Server waits for a response from the called device, and connects Stream Manager to a call to play an audio ring tone only when the returned response cannot be used as the offer to a calling device. e. When you are finished, click Apply. Integration Reference Manual 36

37 Siemens OpenScape Voice Configuring DN Objects Setting Options for a Voice over IP Service DN: Sample Configuration End 2. Configure a Trunk DN. Configuring a Trunk DN Purpose To configure a DN of type Trunk that specifies how SIP Server handles outbound calls. It is also used for configuration of gateways, SIP proxies (including connections to other instances of SIP Server), and other SIPbased applications. From the SIP Server perspective, OpenScape Voice in Application Server (B2BUA) mode is considered a gateway or SIP proxy. Start 1. Under a configured Switch object, select the DNs folder. From the File menu, select New > DN to create a new DN object. 2. In the New DN Properties dialog box, click the General tab, and then specify the following properties: a. Number: Enter a name for the Trunk DN. This name can be any unique value, and it can be a combination of letters and numbers. b. Type: Select Trunk from the drop-down box. Integration Reference Manual 37

38 Siemens OpenScape Voice Configuring DN Objects Creating a Trunk DN for OpenScape Voice: Sample Configuration 3. Click the Annex tab. 4. Create a section that is named TServer. In the TServer section, create options as specified in the following table. Option Name Option Value Description contact prefix <ipaddress>:<sip port> Any numerical string The contact URI that SIP Server uses for communication with the OpenScape Voice softswitch, where <ipaddress> is the IP address of the softswitch and <SIP port> is the SIP port number of the softswitch. The initial digits of the number that SIP Server matches to determine whether this trunk should be used for outbound calls. For example, if prefix is set to 78, dialing a number that starts with 78 will cause SIP Server to consider this trunk a gateway or SIP proxy. If multiple Trunk objects match the prefix, SIP Server will select the one that has the longest prefix that matches. Integration Reference Manual 38

39 Siemens OpenScape Voice Configuring DN Objects Option Name Option Value Description refer-enabled replace-prefix false Any numerical string Set this option to false for SIP Server to use a re-invite request method when contacting the softswitch. This is the only method that is supported in the OpenScape Voice configuration. The digits (if necessary) that replace the prefix in the DN. For example, if prefix is set to 78, and replace-prefix is set to 8, the number will be replaced with before it is sent to the gateway or SIP proxy (in this case, OpenScape Voice). Setting Options for a Trunk DN: Sample Configuration 5. When you are finished, click Apply. End 3. Configure Extension DNs. Configuring Extension DNs Purpose To configure DNs of type Extension that represent agent phone extensions and register directly with the softswitch. Integration Reference Manual 39

40 Siemens OpenScape Voice Configuring DN Objects When you configure an extension where the phone registers directly with SIP Server, you must configure options in the TServer section on the Annex tab. However, if you are using a softswitch in Application Server (B2BUA) mode, SIP Server takes the Extension DN name together with the value of the contact option in the softswitch object configuration (not the Extension object) to access the phone. This procedure describes the configuration for phones that are registered directly with OpenScape Voice and not with SIP Server. As a result, SIP Server sends the request to OpenScape Voice to communicate with the phone. Start 1. Under a configured Switch object, select the DNs folder. From the File menu, select New > DN to create a new DN object. 2. In the New DN Properties dialog box, click the General tab, and then specify the following properties: a. Number: Enter a name for the Extension DN. In general, this should be the 10-digit phone number of the extension. You must not use symbol or a computer name. The name of this DN must map to the SIP user name of the extension in OpenScape Voice. b. Type: Select Extension from the drop-down box. Creating an Extension DN for OpenScape Voice: Sample Configuration c. When you are finished, click Apply. Note: No configuration options are required for the Extension DN. Adding configuration options such as contact, password, referenabled, and others might cause unexpected results. End Integration Reference Manual 40

41 Siemens OpenScape Voice Configuring DN Objects 4. Configure Routing Point DNs. Configuring Routing Point DNs Purpose To configure a DN of type Routing Point that is used to execute a routing strategy with Genesys URS. When SIP Server receives an INVITE request on a DN that is configured as a Routing Point, it sends an EventRouteRequest message to URS. Start 1. Under a configured Switch object, select the DNs folder. From the File menu, select New > DN to create a new DN object. 2. In the New DN Properties dialog box, click the General tab, and then specify the following properties: a. Number: Enter a number for the Routing Point DN. This number must be configured on OpenScape Voice. b. Type: Select Routing Point from the drop-down box. Creating a Routing Point for OpenScape Voice: Sample Configuration c. When you are finished, click Apply. Integration Reference Manual 41

42 Siemens OpenScape Voice Configuring DN Objects Although no configuration options are required for the Routing Point, URS does look at options to determine how to handle the Routing Point and what strategy is currently loaded. For details about these options, see the Genesys 8.x Universal Routing Server Reference Guide. End Integration Reference Manual 42

43 Siemens OpenScape Voice Support for First-Party Call-Control Operations Support for First-Party Call-Control Operations Beginning with the Siemens OpenScape Voice switch release V5, SIP Server provides support for first-party callcontrol (1pcc) operations, including a transfer that uses the REFER method when it is integrated with the OpenScape Voice softswitch. Feature Configuration To support 1pcc operations, you must configure a DN of type Voice over IP Service DN and Extension DNs. See Configuring DN Objects for details. To enable a blind transfer, set the blind-transfer-enabled configuration option to true, at the SIP Server Application level, or at the Voice over IP Service DN level. Feature Limitations There are several known limitations that result from the Siemens OpenScape Voice release V5 integration: Mix of 1pcc and 3 pcc with a call is not supported. For 3 pcc calls, the re-invite--based call control method is used. Integration Reference Manual 43

44 Siemens OpenScape Voice Support for Split-Node Deployments Support for Split-Node Deployments The Siemens OpenScape PBX can be configured to operate in a SIP Business Continuity configuration. There are two supported modes: High-availability pair configuration, in which two OpenScape Voice nodes are physically located in the same area and share the same IP address for initiating and receiving calls. Split-node configuration, in which each OpenScape Voice node is geographically separated from the other. In this configuration, each PBX node has its own IP address on different subnets. Each node can be active for certain DNs; so, when a failure occurs, the remaining node will handle all calls, without taking over the IP address of the failed node. Previous deployments of SIP Server with OpenScape Voice utilized only the first mode. Beginning with release 8.1, SIP Server supports a split-node configuration. In a split-node configuration of the OpenScape Voice (with the same SIP Server), each OpenScape Voice node has a different IP address on different subnets. When both nodes are active, calls from each node arrive at SIP Server (typically, each node handles a subset of DNs). SIP Server recognizes all calls as coming from the same switch, as both nodes are part of the same OpenScape Voice switch. When one of the OpenScape Voice nodes fails, the remaining node takes over all existing and future calls. SIP Server will handle existing and future calls to and from the remaining node, which has a different IP address on a different subnet. This take-over process will be transparent to endpoints (which are registered at the OpenScape Voice switch and will be re-registered at the remaining node in case of failure), to agents, and to Genesys T-Library client applications. See the Split-Node Deployment figure. Split-Node Deployment Integration Reference Manual 44

45 Siemens OpenScape Voice Support for Split-Node Deployments Configuring Split-Node deployment To support the split-node configuration, all OpenScape Voice (or PBX) nodes are represented in the configuration environment as a single Voice over IP Service object with the service-type option set to softswitch. All PBX nodes share the same FQDN, which could be resolved through the DNS SRV records. DNS SRV records must be administered in such a way that the IP address of the node, in which endpoints are registered by default, has the highest priority. SIP Server tests the availability of all resolved addresses by using OPTION requests. The available address with the highest priority is used for SIP communication. If the original node fails, endpoints are reregistered at an alternative node. SIP Server starts using the alternative node when it discovers that the original node is not available. Configuration steps: 1. Configure each SIP Server. In the SIP Server Application object, in the TServer section, configure the following options: sip-enable-gdns Set this option to true. This enables the internal DNS client. sip-address Set this option to the IP address of the SIP Server host computer (not the URI). sip-address-srv Set this option to the FQDN of the SIP Server host computer. SIP Server will send this address as its own contact inside SIP requests to the PBX. 2. Configure the Voice over IP Service DN: service-type Set this to softswitch. contact Specify the FQDN of Siemens PBX. The FQDN must be resolvable by DNS SRV records. oos-check Specify the time interval, in seconds, in which SIP Server will send OPTION requests to transport addresses returned by DNS SRV resolution. SIP Server will send an OPTION request by transport for those addresses at which active SIP communication is not present. oos-force Specify the time interval, in seconds, in which SIP Server will mark the transport address as unavailable when there is no response to the OPTION request. This configuration option applies only if the configuration option oos-check is set to a non-zero value. See also the following configuration options for this softswitch DN. 3. Configure Extension DNs by completing the following procedure: Procedure: Configuring Extension DNs 4. (Optional) Configure a Trunk DN for SIP Server to handle outbound calls with the following option: contact=<fqdn of Siemens PBX> This is the same value as configured on the softswitch DN. Feature Limitations Verification of split-node functionality was done with geographically-separated nodes that were configured without RG8700 as a SIP Proxy Server. Integration Reference Manual 45

46 Siemens OpenScape Voice Handling Call Forwarding Loop Handling Call Forwarding Loop In a SIP Server deployment with the Unified OpenScape Voice platform, you can configure SIP Server to support call forwarding from a back office phone to an agent phone, without creating an extra T-Library call in SIP Server. Feature Configuration Set the sip-enhance-diversion option to true. sip-enhance-diversion Setting: TServer section, Application level Default Value: false Valid Values: false, true Changes take effect: For the next call Specifies how SIP Server processes an INVITE message based on the value of the Diversion header. If the option is set to true and the Diversion header references the call forwarding party, SIP Server rejects that INVITE, waits until that rejection is propagated by the PBX back to the SIP Server in the original SIP dialog, and sends a new INVITE message to a forwarding destination. Feature Limitations This feature does not apply to the scenario in which an external number is forwarding multiple calls back to SIP Server simultaneously. Integration Reference Manual 46

47 Cisco Unified Communications Manager Handling Call Forwarding Loop Cisco Unified Communications Manager Genesys SIP Server is a key integration point between the Genesys Customer Experience Platform and Cisco Unified Communications Manager (CUCM). The integration supports several capabilities: In-Front Qualification & Parking provides centralized queuing & qualification (basic IVR), before routing calls to an agent. (See the T-Server for Cisco Unified Communications Manager Deployment Guide for details.) Advanced Self Service integrates Genesys Voice Platform with advanced VXML, ASR, TTS (and more) to CUCM. Manage Agent-related Calls allows agents to utilize CUCM as the underlying telephony platform, while SIP Server manages calls & agent state. This is an effective alternative to the standard JTAPI-based T-Server integration. Recording Integration integrates with Genesys Interaction Recording or the Genesys Recording Connector. You can deploy any combination of these capabilities. For instance, In-Front Qualification & Parking could be deployed in conjunction with the JTAPI-based T-Server. Or a pure SIP deployment could utilize In-Front Qualification & Parking, and SIP-based agent management. The configuration for Genesys SIP Server, as it relates to the CUCM integration, is largely the same for most of these capabilities. It contains the following sections: Managing Agents over SIP Configuring CUCM Configuring DN Objects Note: The instructions on the following pages in this topic assume that both CUCM and SIP Server are fully functional as stand-alone products. The instructions only highlight modifications to the existing configuration to make these products work as an integrated solution. Integration Reference Manual 47

48 Cisco Unified Communications Manager Managing Agents over SIP Managing Agents over SIP Overview of SIP-based Integration for Managing Agents Genesys SIP Server supports operation as a type of Application Server. Effectively, agents will have their telephone service (dial tone) provide by a phone which is part of a Cisco UCM deployment. SIP Server will serve as the application server which manages contact center calls to and from the agents. This integration utilizes a SIP Trunk between the two components, and typically involves an exchange of presence information for each DN. The presence information informs SIP Server when an agent is involved in a non-contact center call, and this status is taken into account when the Genesys URS/ORS routing components select an agent (such as not routing a contact center call to an agent who is already busy). This SIP-based integration offers several key benefits: Standards based integration using the SIP protocol. Fewer components SIP Server is often deployed for purposes of recording or qualification & parking, and extending it to manage agents requires nothing more than configuration updates. This benefit is also valuable in case it is not practical to deploy a dedicated JTAPI-based T-Server (such as when Cisco UCM is geographically distant from the Genesys infrastructure). Access to unique features provided by SIP Server such as full support of Genesys Interaction Recording, Personal Greetings for agents, support of Genesys SIP Voic . The SIP-based integration does have some limitations which will be visible to the agents: First-Party Call Control (1PCC) Limitations Agents are not allowed to use their phone for initiating mid-call changes like hold/retrieve, conference or transfer. These operations must be initiated using the agent desktop application. Third-Party Call Control (3PCC) Limitations SIP Server does not have complete control over the phone, so some 3PCC operations are not supported; the main 3PCC operation which is missing is Click-to-answer (the agent must manually answer each call, or they must set the phone to auto answer each incoming call). Deployment Architecture SIP Server is integrated with CUCM via SIP trunks.the figure below depicts a sample deployment architecture of SIP Server with CUCM. Integration Reference Manual 48

49 Cisco Unified Communications Manager Managing Agents over SIP This sample call flow describes the steps for an incoming call handled by the CUCM SIP Server integration solution: 1. Genesys SIP Server is monitoring the status of each agent s phone. 2. An incoming customer call arrives at CUCM. 3. CUCM delivers the call to SIP Server via a configured SIP Trunk. 4. Genesys SIP Server (typically) uses a routing strategy on URS/ORS which selects a qualified agent who is in the Ready state, or places the call in queue until an agent is available. Direct calls to an agent are also possible if the agent has a Direct Inward Dial (DID) phone number. 5. SIP Server delivers the call to CUCM via a SIP trunk (if multiple SIP trunks are defined, the selection is configurable as round-robin or primary/backup). 6. CUCM delivers the call to the agent s phone and the agent answers the call. The agent will use their desktop application (connected to SIP Server) for all mid-call operations, such as transfer, conference, supervision, recording control, and hold/retrieve. 7. The call disconnects when the caller or the agent hangs up. Call Flows Subscription Genesys SIP Server integration with CUCM relies on the SUBSCRIBE/NOTIFY feature that is supported by CUCM. At startup, SIP Server sends subscription messages for a device or a list of configured devices to be notified about the endpoints status change. CUCM provides NOTIFY messages to SIP Server according to the endpoints status. As soon as an endpoint registers with CUCM, CUCM sends a NOTIFY message to SIP Server with the status reported as active. Integration Reference Manual 49

50 Cisco Unified Communications Manager Managing Agents over SIP Private Calls A CUCM dialing plan can be set up in such a way that private calls (direct calls to an agent, for example) are not forwarded to SIP Server. Instead, only the notification about the busy status of the endpoint is passed to SIP Server. SIP Server uses this status change notification to set the endpoint DN to a busy state (EventAgentNotReady), so that the rest of the Genesys suite will not consider that DN available for the routing of contact center calls. As soon as the call is released at the endpoint, CUCM notifies SIP Server, which then generates an EventAgentReady message. The agent is then considered available for contact center calls. The mechanism for private outbound call processing is exactly the same. SIP Server receives the NOTIFY messages sent by CUCM. Contact Center Calls In the same way that you can set up a CUCM dialing plan to bypass SIP Server for private calls, you can write rules governing how CUCM connects contact center calls (typically, calls to the service number of the company) to SIP Server. After connection, SIP Server triggers a strategy for Universal Routing Server (URS) to process this type of call. Eventually, an agent DN is selected to handle the customer call and SIP Server initiates a new dialog to CUCM for the selected endpoint. Finally, CUCM delivers the call to the agent endpoint. This mechanism creates a signaling loop inside SIP Server, which is then in charge of maintaining the inbound leg from CUCM (customer leg) with the outbound leg to CUCM (agent leg). By staying in the signaling path, SIP Server detects any change in call status, and generates call-related events (EventRinging, EventEstablished, EventReleased, and so on). Any call control operation from the agent must be performed using a third-party call control (3pcc) procedure. In other words, the agent desktop must be used for any call control operation (including the answer call operation). This includes, but is not limited to, hold, transfer, and conference requests. If a Network/Media Gateway is directly connected to SIP Server, then contact center calls are first received by SIP Server. The call flow for routing the call is very similar to the flow described above, except that there is only one call leg in CUCM. Conferences SIP Server supports conferences for agents on CUCM. A conference is initiated by a T-Library client (for example, Workspace Desktop). SIP Server can be configured to use either Media Server or other third-party MCUs to provide the conferencing feature. Call Supervision Supervisor features such as, Silent-Monitoring and Barge-In are also supported for this integration with CUCM. Supervisor functionality is supported via a T-Library interface. SIP Server includes a supervisor in a call between a customer and an agent (conference) and signals Media Server to either keep the supervisor media leg open for two-way media (sendrecv - Barge-In) or one way (for Silent Monitoring). Integration Reference Manual 50

51 Cisco Unified Communications Manager Managing Agents over SIP Presence Genesys needs to be aware of non-contact center calls (and general phone status), to make the best contact center routing decisions. Towards this goal, SIP Server SUBSCRIBEs towards CUCM for presence information per RFC 3856, and CUCM NOTIFYs of device state. SIP Server maps this presence information to the agent/device state in the Genesys T-Library model. SIP Server transforms notifications about presence state changes into the Agent State updates, according to the following rules: For the initial NOTIFY with a basic status Open: SIP Server uses the initial NOTIFY message to generate EventAgentLogin and EventAgentReady messages. For subsequent NOTIFY messages with the basic status Open: SIP Server checks whether an agent is logged in. If not, SIP Server sends an event that the agent has logged in (EventAgentLogin). SIP Server checks whether any activity is indicated in presence notification. If not, and if the agent is in the Not Ready state, SIP Server sends an event that the agent is Ready (EventAgentReady). If an activity is indicated in the presence notification, and if the agent is Ready, SIP Server sends an event that the agent is not Ready (EventAgentNotReady), attaching the activity from the presence notification as a ReasonCode. For presence notification with the basic status Closed is received: SIP Server checks whether the agent is logged in. If yes, SIP Server sends an event that the agent has logged out (EventAgentLogout). Agent States through SIP Presence and T-Library Interface While working with CUCM, SIP Server could modify agent states based on two different inputs: NOTIFY message within a SUBSCRIBE dialog T-Library client requests from the agent desktop Such dualism could lead to conflict unless some priority rules are applied. SIP Server always considers a message that brings an agent in the Not Ready/Logout state of the higher priority over a message that brings an agent in the Logging/Ready state coming from a different interface. Endpoint Support The SIP-based integration between SIP Server and CUCM works for all known endpoints including Cisco IP Communicator and Cisco Hardphones (with a minor disclaimer that only a select few phones were actually tested, but all had positive results). With IP communicator CUCM sends NOTIFY with the Open state when it starts, so SIP Server can set an agent linked to this extension in the Login/Ready state. At proper exit of IP Communicator, CUCM sends NOTIFY with the terminated state, so SIP Server sets an agent in the Logout state. Integration Reference Manual 51

52 Cisco Unified Communications Manager Managing Agents over SIP Supported Versions For supported CUCM versions, see the Genesys Supported Media Interfaces Guide Supported Infrastructure page. Integration Task Summary To integrate SIP Server with CUCM, complete the following procedures: 1. Configure CUCM. 2. Configure DN objects for CUCM. Integration Reference Manual 52

53 Cisco Unified Communications Manager Configuring CUCM Configuring CUCM This is an overview of the main steps that are required to configure CUCM. Refer to the Cisco Unified Communcations Manager documentation for standard configuration procedures. 1. Configure Cisco Phones to point to CUCM. Genesys SIP Server currently supports this integration with only SIP Phones that are compatible with CUCM. 2. Ensure that the Service Parameter Configuration for the [server-name], the Clusterwide parameters (System Presence) for Default Inter-Presence Group Subscription is set to Allow Subscription. 3. Ensure that the SIP Trunk Security Profile > Outgoing Transport Type is set to UDP, and the Accept Presence Subscription checkbox is selected. 4. Build a SIP Trunk to point it to the SIP Server host using the SIP Trunk Security Profile configured in the previous step, with an appropriate Inbound Calling Search Space and SUBSCRIBE Calling Search Space. Note: If a Presence Group is added to segregate resources, the SIP trunk and all appropriate resources must be in the same Presence Group, and resources must also share the same SUBSCRIBE Calling Search Space. Integration Reference Manual 53

54 Cisco Unified Communications Manager Configuring DN Objects Configuring DN Objects You configure Genesys DN objects to represent CUCM in the Configuration Layer under the Switch object that is assigned to the appropriate SIP Server. 1. Configure a Voice over IP Service DN. For each CUCM SIP Trunk present in the cluster, create a DN object of type Voice over IP Service. Configure the following options in the TServer section for such object. contact Option Name Option Value Description dual-dialog-enabled enable-agentlogin-presence make-call-rfc3725-flow 1 oos-check oos-force refer-enabled SIP URI false true false Specify the contact URI that SIP Server uses for communication with CUCM. Set this option to false to instruct SIP Server not to create new a SIP dialog when making a consultation call. Set this option to true for SIP Server to provide accurate information about agent states. Set this option to 1, so SIP Server selects the SIP call flow number 1 (described in RFC 3725) for a call that is initiated by a TMakeCall request. Specify how often (in seconds) SIP Server checks a device for out-ofservice status. Specify the time interval (in seconds) that SIP Server waits before placing a device that does not respond in outof-service state when the ooscheck option is enabled. Set this option to false for SIP Server to use a re-invite request method when contacting CUCM. service-type softswitch Set this option to softswitch. Integration Reference Manual 54

55 Cisco Unified Communications Manager Configuring DN Objects 2. Configure a Trunk DN. Create a DN of type Trunk with the name, for example, CUCMTrunk. Create a section that is named TServer. In the TServer section, create options as specified in the following table. contact contact-backup oos-check oos-force Option Name Option Value Description subscribe-presence-domain subscribe-presence-from subscribe-presence-expire SIP URI SIP URI Any valid domain SIP URI Specify the contact URI that SIP Server uses for communication with CUCM. If there is a cluster CUCM deployment, specify the address of any CUCM. (For CUCM cluster only) May contain a comma-separated list of addresses of other members of the CUCM cluster. In case of a single node CUCM deployment, this option must not be configured. Specify how often (in seconds) SIP Server checks a device for out-ofservice status. Specify the time interval (in seconds) that SIP Server waits before placing a device that does not respond in outof-service state when the ooscheck option is enabled. Specify the subscription domain information for the Trunk DN. This option value is used with the DN name to form the SUBSCRIBE request URI and the To header. Specify the subscription endpoint information. This option value is used to form the From header in the SUBSCRIBE request to CUCM. This must be the same address as the SIP Server host that is part of the SIP trunk configuration in CUCM. Specify the subscription renewal interval (in seconds). 3. Configure Extension DNs. Enable a presence subscription for the Extension DNs by specifying the option subscribe-presence. This option's value must be the name of the Trunk DN that contains subscription parameters for example, CUCMTrunk. Integration Reference Manual 55

56 Cisco Unified Communications Manager Configuring DN Objects Extension DN objects......must not have any other options configured....must not have the option contact configured....must be created for all DNs used as agent phones. 4. Create Agent IDs. Create Agent IDs for all Extension DNs with the subscription enabled. The Agent ID must be same as the ID of the DN of type Extension. Integration Reference Manual 56

57 Asterisk Configuring DN Objects Asterisk This topic describes how to integrate SIP Server with the Asterisk switch. It contains the following sections: Overview Asterisk for Business Calls Routing Asterisk as a Voic Server Asterisk as a Media Server Note: The instructions in this topic assume that both Asterisk and SIP Server are fully functional as stand-alone products. The instructions only highlight modifications to the existing configuration to make these products work as an integrated solution. Integration Reference Manual 57

58 Asterisk SIP Server and Asterisk Integration Overview SIP Server and Asterisk Integration Overview Asterisk integrated with SIP Server can function in three different roles: As a PBX with a business call routing capability. Asterisk is configured to send business calls to SIP Server to engage a Genesys routing solution. SIP Server uses the routing results to forward the call to the selected agent. As a voic server. SIP Server uses Asterisk as a voic server. Unanswered calls are forwarded to Asterisk to record the voice messages. Contact center agents receive indication on their T-Library agent desktops about new voice messages waiting in their voic box. Agents can access and manage their voic boxes hosted on Asterisk. As a media server. SIP Server uses Asterisk as a Media Server. Asterisk is engaged in the call to perform one of the following functions: Call recording Announcement or music playing DTMF digits collection Conferences Asterisk with a Business Call Routing Capability The SIP Server - Asterisk Deployment Architecture figure depicts a sample deployment architecture of SIP Server with Asterisk, in which: Asterisk is connected to the network via a SIP gateway. The agent endpoint is registered on Asterisk. The agent endpoint is associated with a T-Library desktop application. Integration Reference Manual 58

59 Asterisk SIP Server and Asterisk Integration Overview SIP Server - Asterisk Deployment Architecture Integration with the Asterisk switch relies on the SIP presence subscription from SIP Server. For any call handled by the agent endpoint, Asterisk is requested to provide a notification about the status change for that endpoint. SIP Server uses those notifications to synchronize an agent state visible to all Genesys T-Library clients with the actual state of this agent. The business call routing solution that is built on these integration principles involves SIP Server to handle the business calls only. Private calls are processed locally on Asterisk. Agent statuses are reported to SIP Server for all call types, because they are used to identify the agents' availability for the Genesys Routing Solution. All figures in this topic depicting Stream Manager refer to the Genesys Stream Manager. This component, when working together with SIP Server, provides different kinds of media services, such as ring-back, music-on-hold, DTMF digit collection, and others. You can also configure Asterisk to work as a media server for SIP Server. For information about architectural and configuration details of this solution, see Asterisk as a Media Server. Private Calls An Asterisk dialing plan can be set up in such a way that private calls (direct calls to an agent, for example) are not forwarded to SIP Server. Instead, only the notification about the busy status of the endpoint is passed to SIP Server. SIP Server uses this status change notification to set the endpoint DN to a busy state (EventAgentNotReady), so that the rest of the Genesys suite will not consider that DN available for the routing of contact center calls. The following figure illustrates the processing of private calls. Integration Reference Manual 59

60 Asterisk SIP Server and Asterisk Integration Overview Private Call Processing Contact Center Calls In the same way that you can set up an Asterisk dialing plan to bypass SIP Server for private calls, you can write rules so that Asterisk connects contact center calls (typically, calls to the service number of the company) to SIP Server. After that, SIP Server triggers a strategy for Universal Routing Server (URS) to process this type of call. Eventually, an agent DN is selected to handle the customer call and SIP Server initiates a new dialog to Asterisk for the selected endpoint. Finally, Asterisk delivers the call to the agent endpoint. This mechanism creates a signaling loop inside SIP Server, which is then in charge of maintaining the inbound leg from Asterisk (customer leg) with the outbound leg to Asterisk (agent leg). Note: From the Asterisk perspective, the two legs are two completely separate calls. Correlation is performed at the SIP Server level. By staying in the signaling path, SIP Server detects any change in call status, and can therefore produce callrelated events (EventRinging, EventEstablished, EventReleased, and so on). Any call control operation from the agent must be performed using a third-party call control (3pcc) procedure. In other words, the agent desktop must be used for any call control operation (besides the answer call operation). This includes, but is not limited to, hold, transfer, and conference requests. The following figure illustrates the processing of contact center calls. Integration Reference Manual 60

61 Asterisk SIP Server and Asterisk Integration Overview Contact Center Call Processing Call Flows Subscription At startup, SIP Server sends SUBSCRIBE messages to the Asterisk switch, which notifies about changes in the endpoints' status. The Asterisk switch sends NOTIFY messages to SIP Server to report the endpoints' status. See the following figure. Presence Subscription from SIP Server If an endpoint is not yet registered, the Asterisk switch reports its status as closed. As soon as the endpoint registers, Asterisk sends a NOTIFY message to SIP Server, reporting the status open. See the following figure. Private Calls For private calls, the Asterisk dialing plan is set up in such a way that the call is sent directly to the endpoint. Asterisk notifies SIP Server about the call activity on that particular endpoint. In this case, SIP Server generates EventAgentNotReady, which reports the overall agent status as unavailable for contact center calls. (See the Private Call Processing figure.) SIP Server generates only agent-related TEvents for the private Asterisk calls"for example, EventAgentReady and EventAgentNotReady. Call-related events"such as EventRinging, EventEstablished, and so on--are not generated for private calls, because SIP Server is not involved in the processing of private calls. As soon as the call is released at the endpoint, Asterisk notifies SIP Server, which then generates an EventAgentReady message. The agent is then considered available for contact center calls. Note: The mechanism for private outbound call processing is exactly the same. SIP Server receives the NOTIFY messages sent by Asterisk. Integration Reference Manual 61

62 Asterisk SIP Server and Asterisk Integration Overview Contact Center Calls Inbound Calls to SIP Server Inbound contact center calls are programmed within the Asterisk dialing plan to be directed to SIP Server. In this case, the call arrives at a Routing Point, and URS is triggered. You can request a call treatment (using the TApplyTreatment request) to play announcement or music. If Stream Manager is configured to provide a treatment functionality, SIP Server connects a caller to Stream Manager to listen to the treatment while waiting for an agent to become available. See the following figure. Handling Contact Center Calls Whenever the agent becomes ready, SIP Server receives a TRouteCall request to the targeted agent endpoint. Because this endpoint is configured to point to Asterisk, SIP Server then initiates a new dialog with Asterisk to engage the agent. Asterisk forwards the call to the specified endpoint and reports to SIP Server the call activity on that endpoint with a NOTIFY message (EventAgentNotReady). When the call is answered, Stream Manager is disconnected, and the original SIP dialog is renegotiated between SIP Sever and Asterisk. Because SIP Server is in the signaling path for contact center calls, it generates all call-related events (EventRinging, EventEstablished, and so on) for the agent's DN. See the following figure. Delivering the Call to the Agent Integration Reference Manual 62

63 Asterisk SIP Server and Asterisk Integration Overview Furthermore, when the call is released, SIP Server also generates EventReleased, and Asterisk notifies SIP Server with a NOTIFY message (EventAgentReady). See the following figure. Contact Center Call Disconnection Inbound Calls to Extensions Inbound contact center calls, and manual internal first-party call control (1pcc) calls that are directed to extensions, are not visible to SIP Server; as a result, you cannot make third-party call control (3pcc) calls for them. Only inbound calls that are directed to Routing Points on SIP Server, and manual internal calls, which go via Routing Points can be seen by SIP Server; as a result, 3pcc calls can be made for them. Outbound Calls An outbound call that is contact-center-related (for example, a call back to a customer) must be performed using 3pcc operations. This ensures that SIP Server creates and controls the SIP dialogs on behalf of the agent endpoint. SIP Server uses the call flow 1 described in RFC 3725 to create a call initiated from the agent's T-Library client using the TMakeCall request. An agent initiates the outbound call by sending the TMakeCall request from the T-Library client to SIP Server. SIP Server attempts to engage the agent by sending the INVITE message to this agent endpoint (via Asterisk). Note: If the phone is not configured with auto-answer, the agent must manually answer the call. This is the only manual action that is required for contact center calls. If Stream Manager is configured to provide treatments, then SIP Server connects the agent to Stream Manager to listen to a ringback tone while establishing a connection to the outbound call destination. See the following figure. Integration Reference Manual 63

64 Asterisk SIP Server and Asterisk Integration Overview Engaging the Agent Endpoint for an Outbound Call SIP Server contacts the requested destination number. After the destination answers the call, SIP Server discontinues the ringback tone (by sending the BYE message to Stream Manager) and renegotiates with the agent endpoint (via Asterisk), so that the media stream is connected between the agent and the customer. See the following figure. Connecting to the Customer Although disconnection would work if it were initiated directly from the agent endpoint, it is good practice to always use a desktop application to perform any actions related to contact center calls. Therefore, the disconnection is requested by sending the TReleaseCall request to SIP Server. SIP Server manages two dialogs: one for the agent and another for the customer. It sends the BYE message to both of them, and the call is eventually disconnected. See the following figure. Integration Reference Manual 64

65 Asterisk SIP Server and Asterisk Integration Overview Outbound Call Disconnection Asterisk as a Voic Server Asterisk can provide the voic server functionality. A stand-alone Asterisk solution allows all agents registered on Asterisk to use multiple voic boxes. SIP Server integration with Asterisk adds several new voic related features to the standard Asterisk set: 1. Agents registered on SIP Server (an agent VOIP phone sends the SIP REGISTER message to SIP Server) can use voic boxes hosted on Asterisk. 2. All agents (registered on Asterisk or on SIP Server) can receive voic notifications on their T-Library client desktops. 3. Voic boxes can be associated with extensions, agent logins, and agent groups. Voic Boxes For Agents Registered on SIP Server One or multiple voic boxes can be created on Asterisk for the agents registered on SIP Server. All voic features configured on Asterisk become available for SIP Server agents. Unanswered calls can be forwarded to the corresponding voic box allowing callers to leave a voice message. SIP Server agents can call their voic boxes from their VOIP phones to listen to the voice messages and to manage the voic box. Voic Notifications Sent to SIP Server T-Library Clients Genesys contact center agents use T-Library client desktops. If Asterisk is configured as a voic server for SIP Server, agents can receive notifications about the new voice messages left in their voic boxes on their T- Library client desktops. These notifications also provide information about the number of old and new messages stored in the voic box. Integration Reference Manual 65

66 Asterisk SIP Server and Asterisk Integration Overview Voic Boxes Associated with Extensions, Agent Logins, or Agent Groups SIP Server associates each voic box it controls on Asterisk with one of the following configuration objects in the Configuration Layer: Extension, Agent Login, or Agent Group. The voic box associated with a corresponding object defines a group of SIP Server T-Library clients to receive voic status notifications for a particular voic box. Voic notifications described in this section are transmitted using the T-Library interface. SIP Server sends messages to its T-Library clients. If the voic box is associated with an extension, then notifications are sent to an agent whose T-Library client is registered to this extension. If the voic box is associated with the agent login, then SIP Server sends voic notifications to this agent T-Library client. In this case, it does not matter what DN this agent used to log in. It is also possible to associate a voic box with the agent group. If a new voice message is left in such a voic box, then all logged in agents associated with this agent group will receive a notification about this message. Call flows The following figure illustrates a general integration schema representing Asterisk configured as a voic server for SIP Server. Asterisk Configuration as a Voic Server Integration Reference Manual 66

67 Asterisk SIP Server and Asterisk Integration Overview The figure also shows how voic services can be provided for two agents: Agent DN 1000 and Agent DN Both agents use T-Library desktops connected to SIP Server via the T-Library protocol. Agent DN 1000 has the VOIP phone that is registered on Asterisk. Agent DN 2000 has the VOIP phone that is registered on SIP Server. Asterisk is configured to fully support all calls made from and to DN For this purpose, it has a SIP entity [1000] configured in the sip.conf file to represent the agent's phone. It also has a voic box configured in some private context [MY_COMPANY] in the Asterisk voic .conf configuration file. SIP Server integration with Asterisk requires adding a new object to the Asterisk configuration to provide the voic functionality for the SIP Server agent at DN A new voic box for this agent is created in the [GVM_DN] context of the Asterisk voic .conf configuration file. The Asterisk Message Waiting Indicator (MWI) interface is used to integrate Asterisk as a voic server with SIP Server. The MWI interface utilizes the SIP subscription schema. SIP Server subscribes to the message-summary event at Asterisk using the SIP SUBSCRIBE request method: SUBSCRIBE sip:gvm-1000@ SIP/2.0 From: sip:gvm-1000@ ;tag=7c217d88 To: sip:gvm-1000@ ;tag=as050e992c Call-ID: 1CD815F7-1@ CSeq: 1103 SUBSCRIBE Content-Length: 0 Via: SIP/2.0/UDP :5060;branch=z9hG4bK3B Event: message-summary Accept: application/simple-message-summary Contact: <sip:gsipmwi@ :5060;mb=1000;dn=1000;tp=1> Expires: 600 Asterisk sends notifications to SIP Server about the voic box status using the SIP NOTIFY message: NOTIFY sip:gsipmwi@ :5060;mb=1000;dn=1000;tp=2 SIP/2.0 Via: SIP/2.0/UDP :5070;branch=z9hG4bK219f391e From: "asterisk" <sip:asterisk@ :5070>;tag=as13d3077a To: <sip:gsipmwi@ :5060;mb=1000;dn=1000;tp=2> Contact: <sip:asterisk@ :5070> Call-ID: 1CD815F7-1@ Integration Reference Manual 67

68 Asterisk SIP Server and Asterisk Integration Overview CSeq: 102 NOTIFY User-Agent: Asterisk PBX Event: message-summary Content-Type: application/simple-message-summary Content-Length: 43 Messages-Waiting: yes Voice-Message: 1/0 SIP Server generates the EventUserEvent message based on this notification and sends it to the T-Library client registered on a DN associated with a particular voic box. This is an example of such a T-Library event: EventUserEvent AttributeUserData [120] 'gsipmwi'(list) 'Mailbox 1000' 'Messages-Waiting' 'true' 'Voice-Message' '1/0' 'NewMessages " 1 "OldMessages " 0 AttributeUserEvent [1001] AttributeThisDN '1000' Dedicated SIP objects are created in the sip.conf Asterisk configuration file to support the MWI subscription. These objects are gvm-1000 and gvm-2000 in the Asterisk Configuration as a Voic Server figure. The GVM acronym in the object name stands for Genesys Voic . These objects are created in Asterisk for MWI subscription purposes only, and no SIP clients are registered on these objects. Both objects have a parameter pointing to a specific Asterisk voic box: [gvm-1000] mailbox=1000@my_company [gvm-2000] mailbox=2000@gvm_dn SIP Server activates one SIP subscription per voic box it needs to monitor. The above configuration guarantees that SIP Server will receive notification on a correct voic box when it subscribes to a corresponding GVM object. Integration Reference Manual 68

69 Asterisk SIP Server and Asterisk Integration Overview MWI Subscription Scope SIP Server activates one or multiple MWI subscriptions for each voic box it needs to monitor. Individual voic boxes created for Extensions or Agent Logins are monitored by a single MWI subscription per box. The number of MWI subscriptions activated per Agent Group voic box is equal to the number of agents currently logged in to this Agent Group. SIP Server is designed in the assumption that all extensions have voic boxes. So, if MWI monitoring is enabled for the extensions (mwi-extension-enable is set to true), SIP Server at start up attempts to activate MWI subscriptions for all extensions configured in the Configuration Layer. Subscriptions for the Extension-related voic boxes are deactivated when SIP Server shuts down. MWI subscription for Agent Login is when an agent with the corresponding agent ID logs in to SIP Server. SIP Server keeps this subscription active while the agent is logged in and stops it when the agent logs out. The same MWI subscription logic is applied to the monitoring of voic boxes created for the Agent Groups. SIP Server activates MWI subscription for the group when the first agent associated with this group logs in. SIP Server stops the subscription when the last agent of this group logs out. If, for some reason, a subscription request for any voic box type is rejected or times out, SIP Server attempts to activate this subscription again in one minute. Building a Voic Solution The Voic functionality in SIP Server and Asterisk allows you to build multiple Voic solutions with different complexity to address different business needs. This section provides examples that show how to build Voic solutions. It outlines general architectural ideas that refer to some configuration options only for clarification purposes. For configuration procedures, see the Framework 8.1 SIP Server Deployment Guide. The easiest approach to a Voic solution is to have calls, which are not answered on a DN during a specified timeout, forwarded to the voic box associated with this DN (extension). This solution requires that you associate an Asterisk-hosted voic box with the DN. A DN object in Configuration Manager should be configured with the following options: no-answer-overflow no-answer-timeout The no-answer-timeout option specifies the time during which the call must be answered. When the noanswer-timeout timer expires and the call is not answered, SIP Server uses the value of option no-answeroverflow to decide how to process the call. If this option contains the name of the voic box associated with this DN, then SIP Server sends the call to this voic box. A similar solution can be configured for agents. SIP Server can apply the same algorithm that is used for process unanswered calls for an agent who ignores the DN where the agent logs in. In this case, the Asterisk-hosted voic box should be associated with the Agent Login (and not the extension). Also, the no-answer-timeout and no-answer-overflow options should be specified in the Agent Login configuration object. Integration Reference Manual 69

70 Asterisk SIP Server and Asterisk Integration Overview SIP Server also allows you to use voic boxes in business call routing. Usually in those scenarios, calls are controlled by the URS strategy, which attempts to find an appropriate agent to forward the call to. There are many ways to write a URS strategy to utilize a Voic solution. For example, if a call is routed to an agent group that does not have any currently available agents, URS can send a call to the voic box associated with the Agent Group. In this case, all logged in members of this group will receive a notification about the new message left in the group voic box. SIP Server can also redirect unanswered calls to the voic box based on the options configured for the SIP Server Application configuration object. There are two groups of options, which define how SIP Server processes unanswered calls for extensions and for agents: extn-no-answer-xxx agent-no-answer-xxx See the Framework 8.1 SIP Server Deployment Guide for more information about the options. Asterisk as a Media Server You can configure Asterisk as a media server for SIP Server. SIP Server can utilize the following services provided by Asterisk: Play announcements. Collect DTMF digits. Organize conferences. Recording calls. Communication between two servers is mainly based on RFC an exception is the recording service, which is not described in this RFC. Integration Reference Manual 70

71 Asterisk Asterisk for Business Calls Routing Asterisk for Business Calls Routing Integration Task Summary The following table summarizes the steps to integrate SIP Server with Asterisk to support business calls routing. Objective Related Procedures and Actions 1. Configure Asterisk to support business call routing. See Configuring Asterisk. 2. Configure DNs for the Asterisk Switch object in the Configuration Layer. See Configuring DN Objects. Configuring Asterisk This section describes the procedures for configuring Asterisk in the following environment: Asterisk is connected to the network via a SIP gateway. Two SIP endpoints, 2001 and 2002, are registered on Asterisk. Each endpoint is associated with a T-Library desktop application. Asterisk Sample Configuration The following table provides an overview of the main steps to integrate SIP Server with Asterisk. Integration Reference Manual 71

72 Asterisk Asterisk for Business Calls Routing Objective Related Procedures and Actions 1. Confirm that Asterisk is functional and handling calls appropriately. The procedures in this topic assume that Asterisk is functional and handling calls appropriately. For more information, see Asterisk documentation. 2. Configure the sip.conf file. See Configuring the sip.conf file. 3. Configure the extensions.conf file. See Configuring the extensions.conf file. Configuring the sip.conf file Purpose To configure the sip.conf file for Asterisk. Start 1. Configure two peers, one describing the gateway access, and the other describing SIP Server access for example: [gwsim] type=peer host= port=5066 context=default canreinvite=no [gsip] type=peer username=gsip host= context=default canreinvite=no 2. Configure the endpoints. The user name of the endpoint must match the Extension DN configured on the SIP Server side for example: [2001] type=friend username=2001 host=dynamic context=default notifyringing=yes canreinvite=no [2002] type=friend username=2002 host=dynamic context=default notifyringing=yes canreinvite=no Note: SIP Server does not support receiving authentication challenges. For this reason, Asterisk users must not be configured with the secret option; otherwise, Asterisk would challenge INVITE messages that SIP Server issues on behalf of the user, and SIP Server would fail to respond to the challenge. 3. When you are finished, save your configuration. End Configuring the extensions.conf file Purpose To configure the extensions.conf file for Asterisk. Start 1. For each endpoint that SIP Server monitors, configure a hint entry to ensure that Asterisk will accept a presence subscription (from SIP Server, in this case) for those endpoints for example: exten => 2001,hint,SIP/2001 exten => 2001,1,Dial(SIP/2001,60) exten => 2002,hint,SIP/2002 exten => 2002,1,Dial(SIP/2002,60) Integration Reference Manual 72

73 Asterisk Asterisk for Business Calls Routing 2. Configure a basic dialing plan for contact center calls. In this example, extension 2400 is used as a company's service number, so all business calls should arrive to this extension. Those calls are routed to SIP Server. If a call is not answered within 30 seconds, it will be dropped. The "r" flag tells Asterisk to generate a ringback tone for the caller while the call is being routed. ; Inbound call to routing point > contact SIP Server exten => 2400,1,Dial(SIP/${EXTEN}@gsip,30,r) exten => 2400,2,Hangup() 3. Configure a basic dialing plan for calls to external numbers for example: ; Any number with prefix "0' -> contact gateway (with remaining digits only) exten => _0.,1,Dial(SIP/${EXTEN:1}@gwsim,60) 4. When you are finished, save your configuration. End Configuring DN Objects The following table provides an overview of the main steps to configure different DNs under the Asterisk Switch object in the Configuration Layer. Objective Related Procedures and Actions 1. Configure a Trunk DN. See Configuring a Trunk DN. 2. Configure an Extension DN. See Configuring Extension DNs. If you integrate SIP Server with Asterisk in order to support the business routing capability, you do not need to set any configuration options in the SIP Server Application object. Instead, you configure DNs for the Asterisk Switch object that is assigned to the appropriate SIP Server. Configuring a Trunk DN Purpose To configure a DN of type Trunk to support the presence SUBSCRIBE/NOTIFY functionality and to configure external access through Asterisk. Start 1. Under a configured Switch object, select the DNs folder. From the File menu, select New > DN to create a new DN object. 2. In the New DN Properties dialog box, click the General tab, and then specify the following properties (see the following figure): a. Number: Enter a name for the Trunk DN. This name can be any unique value, and it can be a combination of letters and numbers. Integration Reference Manual 73

74 Asterisk Asterisk for Business Calls Routing b. Type: Select Trunk from the drop-down box. 3. Click the Annex tab. 4. Create a section named TServer. In the TServer section, create options as specified in the following table (see also the following figure): Option Name Option Value Description contact subscribe-presence-domain subscribe-presence-expire subscribe-presence-from prefix refer-enabled 5. When you are finished, click Apply. SIP URI A string Any positive integer SIP URI Any positive integer false The contact URI to which SIP Server sends the SUBSCRIBE message. The subscription domain information for the Trunk DN. This option value will be used with the DN name to form the SUBSCRIBE request URI and the To: header. The subscription renewal interval (in seconds). The subscription endpoint information. This option value will be used to form the From: header in the SUBSCRIBE request. The initial digits of the number used to direct to Asterisk any call that SIP Server does not recognize as an internal DN. Set this option to false for SIP Server to use a re-invite request method when contacting Asterisk. End Configuring Extension DNs Purpose To configure Asterisk endpoints that SIP Server will monitor and control. Start 1. Under a configured Switch object, select the DNs folder. From the File menu, select New > DN to create a new DN object. 2. In the New DN Properties dialog box, click the General tab, and then specify the following properties: a. Number: Enter a name for the Extension DN. In general, this should be the phone number of the extension. You must not use symbol or a computer name. Integration Reference Manual 74

75 Asterisk Asterisk for Business Calls Routing b. Type: Select Extension from the drop-down box. 3. Click the Annex tab. 4. Create a section named TServer. In the TServer section, create options as specified in the following table: Option Name Option Value Description contact SIP URI dual-dialog-enabled false make-call-rfc3725-flow 1 refer-enabled false sip-hold-rfc3264 false subscribe-presence A string The contact URI to which SIP Server sends the SUBSCRIBE message. Set this option to false so that consultation calls are handled using the same SIP dialog that is sent to Asterisk. Set this option to 1, so that 3pcc call flow will be used according to RFC3725. Set this option to false if you are using the RFC3725 flow. Set this option to false so that RTP stream hold is performed in a manner compliant with RFC2543. The name of the Trunk DN that is configured for the presence subscription messages to be sent to Asterisk. 5. When you are finished, click Apply. End Integration Reference Manual 75

76 Asterisk Asterisk as a Voic Server Asterisk as a Voic Server The following table summarizes the steps to integrate SIP Server with Asterisk to support the Voic solution. Objective Related Procedures and Actions 1. Configure the SIP Server Application configuration object. See Configuring a SIP Server Application object. 2. Configure DNs, Agent Logins, and Agent Groups in the SIP Server Switch object to use voic boxes. See Configuring Configuration Layer Objects. 3. Configure Asterisk using the GVMA utility. The GVMA utility is used to collect all GVM-options from the Switch objects in the Configuration Layer and propagate these options into the Asterisk configuration. Some manual Asterisk configuration may be required. See Configuring Asterisk. Configuring a SIP Server Application object Start 1. Set the MWI mode: In the SIP Server Application object, set the mwi-mode option to REGISTER or SUBSCRIBE. This is the SIP method that SIP Server uses to utilize the MWI interface. With a value of SUBSCRIBE (default), SIP Server activates SIP subscriptions for all voic box owners as configured by other mwi-<xxx> options. With a value of REGISTER, SIP Server activates MWI functionality using the REGISTER SIP message. Note: It is recommended that you use SUBSCRIBE for SIP Server release 7.6 and later. The SUBSCRIBE-based method works both for agents registered on Asterisk and for agents registered on SIP Server, whereas the REGISTER-based method does not work for agents registered on Asterisk. Set the mwi-domain option to the domain name, which SIP Server should send to Asterisk in the MWI REGISTER or SUBSCRIBE requests. This option must be synchronized with the Asterisk settings. But in the basic configuration it can be set to the Asterisk hostname or IP address. 2. Configure SIP Server access to Asterisk: In the SIP Server Application object, set the following configuration options: mwi-host: Enter the host name or IP address where Asterisk runs. mwi-port: Enter the port on Asterisk to listen to the SIP messages. SIP Server sends MWI-related REGISTER and SUBSCRIBE requests to the address specified by these two options. Integration Reference Manual 76

77 Asterisk Asterisk as a Voic Server 3. Select the types of voic boxes to use: In the SIP Server Application object, set the parameters corresponding to the voic box types to be used in the system to true to activate a support of the voic boxes of this type. Multiple voic box types can be enabled simultaneously. End mwi-extension-enable--for a voic box of type Extension mwi-agent-enable--for a voic box of type Agent mwi-group-enable--for a voic box of type Agent Group Configuring Configuration Layer Objects Genesys provides the Genesys Voic Adapter (GVMA) utility, which reads the configuration related to the Voic solution from the Configuration Layer. The GVMA utility uses this information to modify the Asterisk configuration accordingly. All Configuration Layer objects that you will associate with the Asterisk-hosted voic boxes must be supplied with the GVM options, which provide necessary information for the GVMA utility. There are three types of configuration objects that can be associated with the voic boxes: DN Agent Login Agent Groups A DN object can be associated only with the Extension voic box. An Agent Login object can be associated with two types of voic boxes at the same time: Agent voic box Agent Group voic box An Agent Groups object can be associated with the Agent Group voic box only. GVM Configuration Options You specify GVM configuration options in the TServer section on the Annex tab of the following three configuration objects: DN Agent Login Agent Group Integration Reference Manual 77

78 Asterisk Asterisk as a Voic Server You can use all GVM options in all objects with one exception the gvm_group_mailbox option, which can appear only in the Agent Login object. A full set of GVM options, which you can use to configure objects, is provided below: gvm_mailbox: This option is used in two ways: The GVMA utility uses this option as the name of the voic box it creates on Asterisk for the DN, Agent Login, and Agent Group objects. SIP Server uses the value of this option to activate the MWI subscription for a voic box created for the DN and Agent Login objects. SIP Server compiles an object name for the MWI subscription as shown in the following table: Example of Compiled Object Names for the MWI Subscription Configuration Layer Objects gvm_mailbox Value MWI Subscription Name DN 1000 gvm-1000 Agent Login 1000 gvm-a-1000 The MWI subscription name is sent in the SIP SUBSCRIBE message to Asterisk to activate the MWI subscription. See more information about this option in Configuring the Voic Boxes for Agent Groups. gvm_group_mailbox: This option can be specified only in Agent Login objects. SIP Server uses the value of this option to compile the MWI subscription name for the Agent Group voic box. For example, if this option is set to 1000, then SIP Server sends a SUBSCRIBE message to Asterisk to activate the MWI subscription to the object gvmg See more information about this option in Configuring the Voic Boxes for Agent Groups. gvm_mailbox_context: This option is defined only if the voic box already exists for this configuration object and a new one must not be created. In this case, the option contains the name of the Voic context in the voic .conf file where the voic box resides. gvm_name: This option specifies the owner's name associated with the voic box. gvm_password: This option specifies the voic box password. gvm_ This option specifies the associated with the voic box. Asterisk can be configured to send Voic notifications to this address. gvm_pager_ This option specifies the pager associated with the voic box. gvm_options: This option specifies a list of voic box options separated by a pipe ( ) symbol. For more information, see Asterisk documentation. Integration Reference Manual 78

79 Asterisk Asterisk as a Voic Server Voic Boxes Created by the GVMA Utility The GVMA utility scans the following objects to decide if it should create new voic boxes for them in the Asterisk configuration: All DNs for a switch specified in the GVMA configuration file. All Agent Logins for a switch specified in the GVMA configuration file. All Agent Groups for a tenant specified in the configuration file. A new voic box, which does not have the GVM option gvm_mailbox_context specified, is created for all DNs. The voic box name is set to the value of the gvm_mailbox option if it is specified for this DN. If this option is undefined, then the voic box is created with the name of the DN. The DN name is also used as the default value of the gvm_password and gvm_name options. A new voic box is created for the Agent Login or Agent Group object only if the gvm_mailbox option is specified for this object in the Configuration Layer. If there is no such option, a voic box is not created. Configuring the Voic Boxes for Agent Groups The voic box configuration for an Agent Group should be provided in the TServer section on the Annex tab of the corresponding Agent Group object. This information is used by the GVMA utility, which creates a MWI subscription object for SIP Server in the Asterisk configuration. The GVMA utility monitors either the existing voic box or the one specifically created for the Agent Group. SIP Server does not read information about Agent Groups from the Configuration Layer. So, the configuration information specified in the Agent Group objects is not available for SIP Server. It also means that SIP Server does not have information about how agents are organized into the Agent Groups. SIP Server uses the GVM option gvm_group_mailbox specified in the TServer section on the Annex tab of the Agent Login object to associate an agent with the Agent Group. SIP Server analyzes two GVM options specified for an agent when this agent logs in: gvm_mailbox gvm_group_mailbox If the gvm_mailbox is specified, SIP Server activates the MWI subscription to a voic box for this agent. If the gvm_group_mailbox is defined for this agent, SIP Server initiates the MWI subscription to the Agent Group voic box. In this scenario, one agent has multiple MWI subscriptions active. This agent will receive Voic related notifications for both personal Agent voic boxes and Agent Group voic boxes. Configuring Agents Registered on Asterisk or on SIP Server There are two possible scenarios to configure GVM options for a corresponding configuration object: Integration Reference Manual 79

80 Asterisk Asterisk as a Voic Server A voic box is already created for this object. A new voic box should be created for this object. The first scenario occurs when SIP Server is added to the existing Asterisk installation in which agents register directly on Asterisk and already have the voic boxes configured for them. In this case, it is only required for SIP Server to monitor existing voic boxes to provide appropriate notifications to the T-Library clients. The second scenario takes place when Asterisk is added to the SIP Server installation. All agents register on SIP Server and all of them need new voic boxes created. It is also possible to build a system with both types of agents. The GVMA utility uses the gvm_mailbox_context option to differentiate these two scenarios. If this option is not specified in the corresponding object, then GVMA creates a new mail box in one of the GVMA default contexts (GVMA_DN / GVMA_AGENT / GVMA_AGENTGROUP). If this option is specified, then GVMA does not create a new voic box for this configuration object, and it uses the specified context in the voic box option of the sip.conf file. Configuring Access to Voic Boxes for the Agents Registered on SIP Server SIP Server supports three types of voic boxes: Extension Agent Login Agent Group The GVMA utility used for the Asterisk configuration creates voic boxes in three different contexts in the voic .conf Asterisk configuration file: GVMA_DN: The voic boxes are associated with Extensions. GVMA_AGENT: The voic boxes are associated with Agent Logins. GVMA_AGENTGROUP: The voic boxes are associated with Agent Groups. Correspondingly, three different prefixes (wild cards) are configured in the extensions.conf configuration file to reach voic boxes in three contexts. To utilize this configuration on the Asterisk side there should be one or several trunks configured in the SIP Server Switch configuration object to send all voic calls to Asterisk. Prefixes defined for these trunks should match the wild cards used on Asterisk to reach different voic contexts. Configured prefixes will be supplied as options for the GVMA utility later. To access a voic box with this configuration, agents need to dial a prefix corresponding to a voic box type, followed by the voic box number. Integration Reference Manual 80

81 Asterisk Asterisk as a Voic Server Configuring Asterisk The Genesys Voic Adapter (GVMA) utility is provided by Genesys to propagate the Voic configuration from the Configuration Layer to the Asterisk configuration files. GVMA performs the following steps: 1. GVMA starts. 2. GVMA connects to Configuration Server using the SOAP protocol. 3. GVMA makes a backup copy of the Asterisk configuration. 4. GVMA loads the Voic configuration from the following configuration objects: DNs Agent Logins Agent Groups 5. GVMA updates Asterisk configuration files with the information retrieved from the Configuration Layer during Step GVMA instructs Asterisk to reload configuration files. 7. GVMA exits. GVMA can be run manually or scheduled for periodic execution using the OS scheduling tools, such as cron on Linux systems. The following table provides an overview of the main steps to integrate SIP Server with Asterisk to support the Voic solution. Configuring Asterisk Objective Related Procedures and Actions See the following sections: 1. Define all required parameters in the GVMA configuration file. Prerequisites GVMA Location Configure the GVMA Configuration File 2.Run the GVMA utility on the Asterisk host to configure Asterisk. Run the GVMA utility by executing the gvma_asterisk76.pl script. Integration Reference Manual 81

82 Asterisk Asterisk as a Voic Server Prerequisites Back Up the Asterisk Configuration The GVMA utility modifies the following Asterisk configuration files: extensions.conf, sip.conf, and voic .conf. To save the original Asterisk configuration, create backup copies of all Asterisk configuration files before using the GVMA utility. Perl Interpreter You must install the Perl interpreter on the Asterisk host to run the GVMA utility, which is written as a perl script. Install these additional perl packages that are required to run GVMA: SOAP-Lite Net-Telnet Enable the Asterisk Manager Interface Enable the Asterisk Manager Interface (AMI) by setting the following parameters in the manager.conf Asterisk configuration file: [general] enabled = yes port = 5038 bindaddr = Enable the GVMA Utility to Change the Asterisk Configuration Enable the GVMA utility to change the Asterisk configuration by adding the following section in the manager.conf Asterisk configuration file: [gvma] secret = genesys1 deny= / permit= / read = system,call,log,verbose,command,agent,user write = system,call,log,verbose,command,agent,user Integration Reference Manual 82

83 Asterisk Asterisk as a Voic Server GVMA Location The GVMA utility is located in the tools folder of the SIP Server installation utility. Files in the tools directory include: gvma_asterisk76.cfg--the GVMA utility for 7.6 SIP Server. gvma_asterisk76.pl--the GVMA utility configuration file for 7.6 SIP Server. gvma_asterisk.cfg--the GVMA utility for 7.5 SIP Server. gvma_asterisk.pl--the GVMA utility configuration file for 7.5 SIP Server. Depending on the mwi-mode option value set in the SIP Server Application object, you choose which configuration file and script to run. If the mwi-mode option is set to SUBSCRIBE, use the following files: gvma_asterisk76.cfg gvma_asterisk76.pl If the mwi-mode option is set to REGISTER, use the following files: gvma_asterisk.cfg gvma_asterisk.pl The REGISTER value of the mwi-mode option is for backward compatibility with 7.5 releases of SIP Server. Configure the GVMA Configuration File Configure the following sections in the GVMA configuration file before using the utility: cfgserver gvma_settings Section cfgserver Parameters in the cfgserver section define how GVMA connects to Configuration Manager and what information GVMA reads from it. Note that option port refers to the SOAP port of Configuration Server and not to the port where Configuration Manager is connected. The Configuration Server SOAP port is specified in the Configuration Server configuration file as a port option in the [soap] section. [cfgserver] host=<config server hostname or IP> port=<config server SOAP port> Integration Reference Manual 83

84 Asterisk Asterisk as a Voic Server username = <config server username> password = <config server password> The second part of the cfgserver section provides several examples about how to define a query to allow for the GVMA utility to collect information about DNs, Agent Logins, and Agent Groups from the Configuration Layer. One query should be chosen for each of these three object types. The following placeholders in the selected queries should be replaced with the information from the Configuration Layer: <Switch DBID> <tenant DBID> <tenant name> <Switch Name> #Query examples using DBIDs: #dnquery = CfgDN[(@ownerDBID=<Switch DBID>) and (@type=1)] #agentquery = CfgAgentLogin[@ownerDBID=<Switch DBID>] #agentgroupquery = CfgAgentGroup[@tenantDBID=<tenant DBID>] #Query examples using switch and tenant names: dnquery = CfgTenant[@name='<tenant Name>']/switches/CfgSwitch[@name='<swith name>']/dns/cfgdn[@type='1'] agentquery = CfgSwitch[@name='<Switch name>']/agentlogins/cfgagentlogin agentgroupquery = CfgTenant[@name='<tenant name>']/agentgroups/cfgagentgroup Section gvma_settings The first group of parameters in the gvma_settings section specifies the location of Asterisk configuration files and what files you have to change: asterisk_cfg_path=/etc/asterisk asterisk_cfg_file_sip=sip.conf asterisk_cfg_file_vm=voic .conf asterisk_cfg_file_exten=extensions.conf The following parameters define the comments, which GVMA puts as a boundaries around the parts it inserts into the Asterisk configuration files. asterisk_cfg_gvma_begin=;$ -GVMA-BEGIN-GVMA -$ asterisk_cfg_gvma_end=;$ -GVMA-END-GVMA -$ GVMA creates backup copies of the configuration files to be modified in the location defined by the backup_path parameter: backup_path=./gvma_backup GVMA uses the Asterisk Manager Interface port to connect to Asterisk: Integration Reference Manual 84

85 Asterisk Asterisk as a Voic Server asterisk_cm_port=5038 On the Asterisk side, this port is defined in the manager.conf file. Use the siptserver_host and siptserver_port parameters to specify the host and port, respectively, in the GVM subscription objects created in the sip.conf file. siptserver_host=<sip Server hostname or IP> siptserver_port=<sip Server Port> Finally, the gvma_settings section has a group of parameters specifying how to access different types of voic boxes from the agent VOIP phones: vm_dn_ext_prefix=37 vm_agt_ext_prefix=38 vm_grp_ext_prefix=39 vm_voic _main_ext=9500 GVMA Modifications to Asterisk Configuration Files You can easily find all modifications the GVMA utility makes to the Asterisk configuration files by searching for the beginning and end key specified in the GVMA configuration file in the parameters asterisk_cfg_gvma_begin and asterisk_cfg_gvma_end. File extensions.conf GVMA creates a new context called [GVMA] in the Asterisk dialing plan. This context includes six wildcards. The following wildcard is created to provide access to the agent voic boxes from the agent VOIP phones: exten => _37X.,1,Wait(1) exten => _37X.,2,Set(GVM_DEST=${EXTEN:2}) exten => _37X.,3,GotoIf($["${CALLERID(num)}" = "${GVM_DEST}"]?4:6) exten => _37X.,4,Voic Main(${GVM_DEST}@GVMA_DN) exten => _37X.,5,Hangup exten => _37X.,6,GotoIf($["${GVM_DEST}" = "9500"]?7:9) exten => _37X.,7,Voic Main(@GVMA_DN) exten => _37X.,8,Hangup exten => _37X.,9,Voic (${GVM_DEST}@GVMA_DN,u) Integration Reference Manual 85

86 Asterisk Asterisk as a Voic Server exten => _37X.,10,Hangup Three wildcards of this type are created to provide access to three different types of voic boxes: Extensions, Agent Logins</tt>, and Agent Groups. Prefixes used in these wildcards are taken from the following GVMA configuration file parameters: vm_dn_ext_prefix vm_agt_ext_prefix vm_grp_ext_prefix Another three wildcards that are created in the GVMA context are: _gvm-x _gvm-a-x _gvm-g-x These wildcards are not supposed to be dialed directly, but they are required for the MWI subscription to function properly. Note: You must manually include a new GVMA context into the existing dialing plan context that is used to process agent calls on Asterisk. If there is no special context created for this purpose, you must include the GVMA context into the default dialing plan context. Include the following parameters: [default]include => GVMA File sip.conf The GVMA utility creates a block of new GVM SIP entities in the sip.conf file. Each SIP entity is associated with one voic box. SIP Server activates one MWI subscription for each GVM SIP entity. ;$ -GVMA-BEGIN-GVMA -$ ; Generated by Genesys Voic Configuration Adapter for Asterisk. ; Content generated at Tue Jan 15 20:36: [gvm-1111] type=friend host= port=5060 mailbox=1111@gvma_dn vmexten=1111 Integration Reference Manual 86

87 Asterisk Asterisk as a Voic Server... ;$ -GVMA-END-GVMA -$ The GVMA utility creates multiple gvm-* objects in the sip.conf configuration file. If Asterisk is also integrated with SIP Server to perform a business call routing, then the sip.conf file also contains an object representing a SIP Server. The host and port parameters specified for the SIP Server object are the same as the ones defined for the gvm-* entities in the sip.conf file. This configuration can cause a problem if the Asterisk dialing plan uses the host:port format in the Dial() function to send calls to SIP Server. For example: SIP-SERVER_HOST = SIP-SERVER_PORT = 5060 exten => 2400,1,Dial(SIP/${EXTEN}@${SIP-SERVER_HOST}:${SIP-SERVER_PORT},30,r) Asterisk can select any gvm-* object to send calls, instead of the SIP Server object. In this case, a call is delivered to the correct destination but the call processing depends on the sip.conf object parameters, which are different for SIP Server and gvm-* objects. To avoid this problem, Genesys recommends using the dial plan Dial() function with reference to the object name defined in the sip.conf file instead of using the host:port format. For example: extensions.conf: exten => 2400,1,Dial(SIP/${EXTEN}@genesys-sip-server,30,r) sip.conf: [genesys-sip-server] host= port= File voic .conf The GVMA utility creates three new Voic contexts in the voic .conf Asterisk configuration file: GVMA_DN, GVMA_AGENT and GVMA_AGENTGROUP. Those contexts contain voic boxes created for Extensions, Agent Logins, and Agent Groups, respectively. GVMA takes all parameters that are specified for the GVM voic boxes from the configuration of the corresponding the Configuration Layer objects. ;$ -GVMA-BEGIN-GVMA -$ ; Generated by Genesys Voic Configuration Adapter for Asterisk. ; Content generated at Tue Jan 15 20:36: ; ######## Voic Boxes for the Extensions ####### [GVMA_DN] Integration Reference Manual 87

88 Asterisk Asterisk as a Voic Server 1111 => 1111,1111,, ; ######## Voic Boxes for the Agents ####### [GVMA_AGENT] 2222 => 2222, 2222, 2222@ , 2222@ ,operator=yes ; ######## Voic Boxes for the Agent Groups ####### [GVMA_AGENTGROUP] 3333 => 3333, 3333, 3333@ , 3333@ ,operator=yes ;$ -GVMA-END-GVMA -$ Integration Reference Manual 88

89 Asterisk Asterisk as a Media Server Asterisk as a Media Server In order for Asterisk to work as a media server integrated with SIP Server, you must enhanced the Asterisk dialing plan with several Genesys macros and global variables as described in this section. Configuring Asterisk Dialing Plan Global Variables You must add the following list of global variables to the [globals] section of the Asterisk dialing plan. SIP_PREFIX=.*sip:.*@.*:[0-9]+.* DIG_PRMT_REGEX=silence/1?[0-9] FIND_CLT_REGEX=${SIP_PREFIX}play=[ ]*(music/collect).* FIND_PLY_REGEX=${SIP_PREFIX}play=[ ]*([^>\;]*)[>\;].* FIND_REP_REGEX=${SIP_PREFIX}repeat=[ ]*([^>\;]*)[>\;].* FIND_REC_REGEX=${SIP_PREFIX}record=[ ]*([^>\;]*)[>\;].* FIND_COF_REGEX=.*sip:conf=(.*)@.*:[0-9]+.* DEFAULT_FILE_TO_PLAY= /var/lib/asterisk/moh/fpm-calm-river Variable DEFAULT_FILE_TO_PLAY points to the default music file that is played for the Genesys treatments. In the example, above it refers to the voice file, which comes with Asterisk (if Asterisk is installed in the standard directory). You can change this reference to any other file in the actual deployment. Dialing Plan Macro to Perform Genesys Treatments You must add this treatment to the Asterisk dialing plan to perform Genesys treatments. [macro-treatment] ; ; ${ARG1} - SIP_HEADER(To) ; ; IF treatment == CollectDigits ; exten => s, 1, Answer exten => s, 2, Set(collect=$["${ARG1}":"${FIND_PLY_REGEX}"]) exten => s, 3, GotoIf($[$["${collect}"="music/collect"] $["${collect}"="music/ silence"]]? 15 : 20) exten => s, 15, macro(get-digits,${collect}) exten => s, 16, Goto(s,99) ; ; ELSE IF treatment == record ; exten => s, 20, Set(rec_file=$["${ARG1}":"${FIND_REC_REGEX}"]) Integration Reference Manual 89

90 Asterisk Asterisk as a Media Server exten => s, 21, Set(ply_file=$["${ARG1}":"${FIND_PLY_REGEX}"]) exten => s, 22, GotoIf($[${LEN(${rec_file})}!= 0]? 30 : 40) ; ; Recording Treatment exten => s, 30, GotoIf($[${LEN(${ply_file})} = 0]? 32 : 31) exten => s, 31, Playback(${ply_file}) ; exten => s, 32, Record(genesys-rec-${rec_file}.wav) ;can't detect report dtmf exten => s, 33, Goto(s,98) ; ; ELSE ; Play treatment exten => s, 40, GotoIf($[${LEN(${ply_file})} = 0]? 41 : 43) exten => s, 41, Set(ply_file=${DEFAULT_FILE_TO_PLAY}) exten => s, 42, Goto(s,44) exten => s, 43, Set(ply_count=$["${ARG1}":"${FIND_REP_REGEX}"]) exten => s, 44, GotoIf($[$[${LEN(${ply_count})} = 0] $["$ply_count" = "forever"]]? 50 : 60) ; Playback forever exten => s, 50, Playback(${ply_file}) exten => s, 51, GotoIf($[${PLAYBACKSTATUS}=FAILED]? 52 : 50) ;Goto(s, 50) exten => s, 52, Goto(s, 99) ; Counted playback ; here probably possible to use background() exten => s, 60, Playback(${ply_file}) ; Playback exten => s, 61, Set(ply_count=$[${ply_count} - 1]) exten => s, 62, GotoIf($[$[${ply_count} > 0] & $[${PLAYBACKSTATUS} = SUCCESS]]? 61 : 98) exten => s, 98, Hangup exten => s, 99, NoOp(end-withot-hagup) Dialing Plan Macro to Collect DTMF Digits You must add this treatment to the Asterisk dialing plan to collect DTMF digits. Replace <COLLECT-MESSAGE- PLACEHOLDER> in the macros below with the name of the file to play to announce digit collection. [macro-get-digits] exten => s,1, GotoIf($[$[${ARG1}=music/collect] $[${ARG1}=music/silence]]? 2 : 3) exten => s,2, Set(ARG1=silence/2) exten => s,3,read(dncdigits,<collect-message-placeholder>,1,s) exten => s,4,sendtext(signal=${dncdigits}) exten => s,5, Goto(macro-get-digits,s,3) Dialing Plan Macro to Create a Conference You must add this treatment to the Asterisk dialing plan to organize a conference using the Asterisk MeetMe application. [macro-conf] exten => s, 1, Set(conf_id=$["${ARG1}":"${FIND_COF_REGEX}"]) exten => s, 2, NoOp(${ARG1}) Integration Reference Manual 90

91 Asterisk Asterisk as a Media Server exten => s, 3, GotoIf($[${LEN(${conf_id})}!= 0]? 4 : 20) exten => s, 4, Set(rec_file=$["${ARG1}":"${FIND_REC_REGEX}"]) exten => s, 5, GotoIf($[${LEN(${rec_file})}!= 0]? 6 : 8) exten => s, 6, MeetMe(${conf_id},drq) exten => s, 7, Goto(s,20) exten => s, 8, MeetMe(${conf_id},dq) exten => s, 20, NoOp() Integrating Genesys Macros into the Dialing Plan The Asterisk dialing plan all macros provided above. This section suggests one possible way to do that. Add the following macro in the dialing plan: [moh_conf_treatment] include => macro-treatment exten => annc, 1, macro(treatment,${sip_header(to)}) exten => _co[n]f=., 1, macro(conf,${sip_header(to)}) You must include this macro into the context used to process agent calls. If there is no special context created for this purpose, you must include macro into the default dialing plan context. [default] include => moh_conf_treatment Media Files Media files used for the Genesys treatments should be placed into the standard Asterisk sounds directory. The default location of this directory is: /var/lib/asterisk/sounds Call recordings created by Asterisk are also stored in this directory. There are two types of recordings, which can be activated by SIP Server: Regular (proxy mode) Emergency By default, names of the recordings made in regular mode are prefixed with genesys-rec. Names of the emergency recordings start with the meetme-conf-rec prefix. In both cases, the name prefix is followed by a conference ID. Configuring DN Objects SIP Server utilizes media services through the DNs of type Voice over IP Service configured under the Switch object. The Voice over IP Service DNs have a service-type configuration option, which defines the kind of service this DN can provide. SIP Server selects an appropriate DN when the client application requests a media service. When you use Asterisk as a media server for SIP Server, you should configure the Voice over IP Service DNs with the following service-type values in the SIP Server Switch object: Integration Reference Manual 91

92 Asterisk Asterisk as a Media Server mcu treatment recorder music For information about configuring DNs for different types of services, see the "SIP Device Configuration" topic of the SIP Server Deployment Guide. Integration Reference Manual 92

93 Cisco Media Gateway Asterisk as a Media Server Cisco Media Gateway This section describes how to integrate SIP Server with the Cisco Media Gateway Controller (MGC). It contains the following sections: Overview Configuring Cisco Media Gateway Configuring DN Objects Note: The instructions in this section assume that the Cisco Media Gateway is fully functional. Integration Reference Manual 93

94 Cisco Media Gateway SIP Server and Cisco Media Gateway Integration Overview SIP Server and Cisco Media Gateway Integration Overview The SIP Server and Cisco Media Gateway integration solution described in this topic is not the only method that will work. Although there are other methods, this is the only one that has been tested and approved by Genesys, and that is supported by Genesys Customer Support. The following Cisco IOS Software versions were tested: 2800 Series 3700 Series 3800 Series 5300 Series 5400 Series For confirmation of the supported Cisco IOS Software versions, contact Genesys Technical Support. For more information about Cisco IOS Software, go to the Cisco web site at Deployment Architecture The following figure depicts a sample deployment architecture of SIP Server with Cisco Media Gateway. SIP Server - Cisco Media Gateway Deployment Architecture Integration Reference Manual 94

95 Cisco Media Gateway SIP Server and Cisco Media Gateway Integration Overview Integration Task Summary To integrate SIP Server with Cisco Media Gateway, complete the following procedures: 1. Configure Cisco Media Gateway. 2. Configure a Trunk DN for Cisco Media Gateway. Integration Reference Manual 95

96 Cisco Media Gateway Configuring Cisco Media Gateway Configuring Cisco Media Gateway This page provides an overview of the main steps that are required to configure Cisco Media Gateway. Integrating with Cisco Media Gateway 1. Check Prerequisites. Verify that Cisco Media Gateway is working Verify that Cisco Media Gateway is functional and handling calls appropriately. The procedures in this topic assume that Cisco Media Gateway is functional and handling calls appropriately. For more information, see Cisco Media Gateway-specific documentation. 2. Configure an E1 environment. Configuring an E1 environment Purpose To configure an E1 environment. This section provides an example of an E1 configuration. Start 1. Configure a controller: controller E1 0/2/0 framing NO-CRC4 ds0-group 0 timeslots 1 type fxo-loop-start ds0-group 1 timeslots 2 type fxo-loop-start ds0-group 2 timeslots 3 type fxo-loop-start 2. Configure voice ports: voice-port 0/2/0:0 output attenuation 0 station-id name voice-port 0/2/0:1 output attenuation 0 station-id name Integration Reference Manual 96

97 Cisco Media Gateway Configuring Cisco Media Gateway voice-port 0/2/0:2 output attenuation 0 station-id name Configure dial peers: dial-peer voice pots destination-pattern 6... supplementary-service pass-through port 0/2/0:0 forward-digits all dial-peer voice pots destination-pattern 6... supplementary-service pass-through port 0/2/0:1 forward-digits all dial-peer voice pots destination-pattern 6... supplementary-service pass-through port 0/2/0:2 forward-digits all dial-peer voice 8800 voip service session destination-pattern 8800 voice-class codec 4 session protocol sipv2 session target ipv4: dtmf-relay rtp-nte supplementary-service pass-through End Next Steps Configuring a T1 CAS environment 3. Configure a T1 CAS environment. Configuring a T1 CAS environment Purpose To configure a T1 CAS environment. This section provides an example of a T1 CAS configuration. Start Integration Reference Manual 97

98 Cisco Media Gateway Configuring Cisco Media Gateway 1. Configure a controller: controller T1 1/0/1 framing sf clock source internal linecode ami ds0-group 0 timeslots 1 type e&m-immediate-start ds0-group 1 timeslots 2 type e&m-immediate-start ds0-group 2 timeslots 3 type e&m-immediate-start 2. Configure voice ports: voice-port 0/2/0:0 output attenuation 0 station-id name voice-port 0/2/0:1 output attenuation 0 station-id name voice-port 0/2/0:2 output attenuation 0 station-id name Configure dial peers: dial-peer voice pots destination-pattern 6... supplementary-service pass-through port 0/2/0:0 forward-digits all dial-peer voice pots destination-pattern 6... supplementary-service pass-through port 0/2/0:1 forward-digits all dial-peer voice pots destination-pattern 6... supplementary-service pass-through port 0/2/0:2 forward-digits all dial-peer voice 8800 voip service session destination-pattern 8800 voice-class codec 4 session protocol sipv2 session target ipv4: dtmf-relay rtp-nte supplementary-service pass-through End Next Steps Configuring a T1 PRI environment Integration Reference Manual 98

99 Cisco Media Gateway Configuring Cisco Media Gateway 4. Configure a T1 PRI environment. Configuring a T1 PRI environment Purpose To configure a T1 PRI environment. This section provides an example of a T1 PRI configuration. Start 1. Configure a controller: controller T1 0/0/0 framing esf linecode b8zs pri-group timeslots Configure an interface serial: interface Serial0/0/0:23 no ip address encapsulation hdlc isdn switch-type primary-ni isdn incoming-voice voice no cdp enable 3. Configure a voice port: voice-port 0/0/0:23 4. Configuring dial peers: dial-peer voice 9 pots destination-pattern 9T incoming called-number 9... port 0/0/0:23 dial-peer voice 8800 voip service session destination-pattern 8800 voice-class codec 4 session protocol sipv2 session target ipv4: dtmf-relay rtp-nte supplementary-service pass-through End Next Steps Configuring an E1 PRI environment Integration Reference Manual 99

100 Cisco Media Gateway Configuring Cisco Media Gateway 5. Configure an E1 PRI environment. Configuring an E1 PRI environment Purpose To configure an E1 PRI environment. This section provides an example of an E1 PRI configuration. Start 1. Configure a controller: controller E1 0/2/1 framing NO-CRC4 pri-group timeslots Configure an interface serial: interface Serial0/2/1:15 no ip address encapsulation hdlc isdn switch-type primary-net5 isdn protocol-emulate network isdn incoming-voice voice no cdp enable 3. Configure a voice port: voice-port 0/2/1:15 4. Configure dial peers: dial-peer voice 130 pots destination-pattern 130T direct-inward-dial port 0/2/1:15 dial-peer voice 8800 voip service session destination-pattern 8800 voice-class codec 4 session protocol sipv2 session target ipv4: dtmf-relay rtp-nte supplementary-service pass-through End Next Steps Configuring a SIP User Agent Integration Reference Manual 100

101 Cisco Media Gateway Configuring Cisco Media Gateway 6. Configure a SIP User Agent. Configuring a SIP User Agent Purpose To configure a SIP User Agent. This section provides an example of a SIP User Agent configuration. Start Configure a SIP User Agent: enter global configuration "configure terminal": sip-ua timers notify 400 sip-server dns:host.genesyslab.com End Integration Reference Manual 101

102 Cisco Media Gateway Configuring DN Objects Configuring DN Objects Configure a Trunk DN for Cisco Media Gateway under the Switch object associated with SIP Server in the Configuration Layer. Configuring a Trunk DN for Cisco Media Gateway Start 1. Under a configured Switch object, select the DNs folder. From the File menu, select New > DN to create a new DN object. 2. In the New DN Properties dialog box, click the General tab, and then specify the following properties (see the following figure): a. Number: Enter the gateway name. b. Type: Select Trunk from the drop-down box. 3. Click the Annex tab. 4. Create a section named TServer. In the TServer section, create options as specified in the following table. Option Name Option Value Description contact <ipaddress>:<sip port> oos-check oos-force 0-30 prefix Any numerical string The contact URI that SIP Server uses for communication with the gateway, where <ipaddress> is the IP address of the gateway and <SIP port> is the SIP port number of the gateway. How often (in seconds) SIP Server checks a DN for out-of-service status. How long (in seconds) SIP Server waits before placing a DN out of service. The initial digits of the number that SIP Server matches to determine whether this trunk should be used for outbound calls. For example, if prefix is set to 78, dialing a number starting with 78 will cause SIP Server to consider this trunk a gateway or SIP proxy. If multiple Trunk objects match the prefix, SIP Server will select the one with the longest prefix that matches. Integration Reference Manual 102

103 Cisco Media Gateway Configuring DN Objects Option Name Option Value Description priority Any non-negative integer refer-enabled false recovery-timeout replace-prefix Any numerical string The gateway priority that SIP Server uses to decide a route. A smaller number designates higher priority. If more than one gateway with the same prefix is selected, the gateway with highest priority is normally selected. This priority option is used to control primarybackup gateway switchover, and to provide lowest-cost routing. Set this option to false for SIP Server to use a re-invite request method when contacting the gateway. This is the only method supported in the Cisco Media Gateway configuration. The length of time that a device is set to out-of-service in case of an error. The digits that replace the prefix in the DN. For example, if prefix is set to 78, and replace-prefix is set to 8, the number will be replaced with before it is sent to the gateway or SIP proxy (here, Cisco Media Gateway). 5. When you are finished, click Apply. End Integration Reference Manual 103

104 F5 Networks BIG-IP LTM Configuring DN Objects F5 Networks BIG-IP LTM This document describes how to integrate SIP Server with the F5 Networks BIG-IP Local Traffic Manager (hereafter referred to as BIG-IP LTM) to support SIP Server hot standby high-availability (HA) mode. It contains the following sections: Overview Configuring SIP Server HA Configuring BIG-IP LTM Configuring TLS Deployment Architecture Example Note: The instructions in this document assume that BIG-IP LTM is fully functional. They also assume that Genesys SIP Server has already been installed and configured to function properly. Integration Reference Manual 104

105 F5 Networks BIG-IP LTM SIP Server and BIG-IP LTM Integration Overview SIP Server and BIG-IP LTM Integration Overview The SIP Server and BIG-IP LTM integration solution described in this document enables you to preserve SIP sessions between SIP Server and other SIP-enabled devices that are involved in contact center operations, in switchover scenarios. In this integration solution, one Virtual Server configured on the BIG-IP LTM is associated with a single IP address (referred to as Virtual IP address), and it represents one HA pair of SIP Servers configured as members of one server pool that is associated with the Virtual Server. Integration Solution Notes UDP, TCP, or TLS can be used as the transport for SIP signaling. Up-front load balancing via Network SIP Server or other device could be implemented, but is not described in this document. Configuration of BIG-IP High Availability is not described in this document and has not been validated with SIP Server. BIG-IP LTM can be configured in a more complex load-balancing role. This is beyond the scope of this document. Supported Versions The integration solution described in this document supports the following software versions: Genesys SIP Server Software and later Version and later (does not support TLS/Active-Active RM) Genesys Voice Platform F5 BIG-IP Local Traffic Manager and later (required for TLS/Active-Active RM) BIG-IP v11.x (v Build Final or later) Deployment Architecture The figure below depicts the architecture of a sample deployment of primary and backup SIP Servers with the BIG- IP LTM, in which: BIG-IP LTM is positioned as a network router between a SIP Server HA pair and other network entities. Hosts where SIP Servers are running use the BIG-IP LTM as the default gateway. BIG-IP LTM is configured to apply SNAT (Secure Network Address Translation) to all outbound packets, with the exception of destinations that are defined in the SNAT exclusion group. Integration Reference Manual 105

106 F5 Networks BIG-IP LTM SIP Server and BIG-IP LTM Integration Overview Deployment Requirements There are four different communication groups of devices that interact with SIP Server (see the preceding figure). Each group has its own requirements that must be considered when configuring the BIG-IP LTM. Agent SIP Endpoints Group The Agent SIP Endpoints Group (group A in the preceding figure) includes SIP phones that are used by agents. Initially, devices of this group use the REGISTER method to notify SIP Server of the current Contact URI (IP address). SIP Server uses the Contact information for further communication with the device. By default, SIP Server uses the UDP to communicate with devices of the group. Devices send requests to and receive responses from the BIG-IP LTM Virtual IP address. This group requires that: Integration Reference Manual 106

107 F5 Networks BIG-IP LTM SIP Server and BIG-IP LTM Integration Overview Any inbound packets received at the BIG-IP LTM Virtual IP address are directed to the primary SIP Server. SNAT is applied to any outbound packets that are sent to devices of the group, which means that a source IP address of the outbound packet is translated from a SIP Server physical IP address to the BIG-IP LTM Virtual IP address. SIP Service Devices Group The SIP Service Devices Group (group B in the preceding figure) includes media gateways, softswitches, Session Border Controllers (SBC), and SIP-based VoIP Service devices such as Genesys Media Server (Resource Manager and MCP). These devices do not register with SIP Server; their contact information is known in advance and it remains consistent. By default, SIP Server uses the UDP to communicate with devices of the group. Devices receive requests from the BIG-IP LTM Virtual IP address. This group requires that: Any inbound packets received at the BIG-IP LTM Virtual IP address are directed to the primary SIP Server. SNAT is applied to any outbound packets that are sent to devices of the group. Genesys Systems Group The Genesys Systems Group includes Genesys Configuration Server, Genesys Message Servers and other SIP Servers in multi-site deployments (group C in the preceding figure). SIP Server maintains permanent TCP/IP connections with members of the Genesys Systems Group. Connections with members of the Genesys Systems Group are initiated from a SIP Server physical IP address. Responses from them are directed to the SIP Server physical IP address. Note that missing definitions of Genesys Systems Group members in the SNAT exclusion group result in SNAT being applied to the outbound packets. In this case, the Genesys Systems are unaware of physical IP addresses of the SIP Servers and, instead, receive packets from the Virtual IP address; this complicates troubleshooting. IT infrastructure servers, such as DNS, LDAP, log server, or software repository, are typically included into this group for similar reasons. This group requires that: No SNAT is applied to outbound packets sent to the members of the Genesys Systems Group. Note: In this deployment architecture, HA synchronization traffic between primary and backup SIP Servers does not traverse the BIG-IP LTM, and SNAT control is not applicable to this type of connections (the primary and backup SIP Servers do not belong to the Group). Genesys T-Client Group The Genesys T-Client Group includes clients initiating and maintaining connections with the SIP Server (group D in the preceding figure). These are Stat Servers, URSs, ORSs, T-Library desktops like Interaction Workspace, and other T-Library clients. For this group, connection is initiated by the members of the group toward the SIP Server (primary or backup) physical IP address, and SIP Server accepts the connection. In this case, SNAT is not applied to the outbound packets, and SNAT control does not apply to this type of connections; from the perspective of group members, both SIP Servers send packets from the physical IP address of SIP Server. Integration Reference Manual 107

108 F5 Networks BIG-IP LTM SIP Server and BIG-IP LTM Integration Overview IT infrastructure systems, such as monitoring servers querying hosts, or the workstation of the system administrator, belong to this group. This group requires that: The primary or backup SIP Server is accessible via its physical IP address. Note: SNAT pool must not be activated as the configuration element of Virtual Server. SNAT must not be applied to SIP messages sent by clients to SIP Server. Enabling SNAT for these messages results in a broken call flow, as in some circumstances the SNAT is not aligned with SIP Protocol. Integration Network and Host Prerequisites BIG-IP LTM and SIP Server hosts must be on the same network (broadcast domain, VLAN). The Self-IP (or Floating IP address) of BIG-IP LTM must be configured as the Default Gateway in routing tables of SIP Server hosts. All traffic between SIP Server hosts and any other SIP peers in the deployment, represented by groups A and B such as Agent SIP Endpoints, MGW, SBC, and RMs, must traverse BIG-IP LTM. Firewall settings of SIP Server hosts must enable sending of the ICMP Port Unreachable messages towards the other SIP peers of the deployment represented by groups A and B, such as Agent SIP Endpoints, MGWs, SBCs, and RMs. Firewall settings of SIP Server hosts must enable receiving of the ICMP Echo Requests from the Self-IP (or Floating IP address) of BIG-IP LTM. Required Provisioning The IP address of the Virtual Server configured on BIG-IP LTM for SIP communications with SIP Server over UDP, TCP, or TLS must match the value of the sip-address option configured in the TServer section of the SIP Server application. The port of the Virtual Server configured on BIG-IP LTM for SIP communications with SIP Server over UDP and TCP must match the value of the sip-port option configured in the TServer section of the SIP Server application. The port of the Virtual Server configured on BIG-IP LTM for SIP communications with SIP Server over TLS must match the value of the sip-port-tls option configured in the TServer section of the SIP Server application. Integration Steps To integrate SIP Server with the BIG-IP LTM, complete the following procedures: 1. Configure SIP Server HA. 2. Configure BIG-IP LTM. 3. Configure Resource Manager HA. Note: Genesys strongly advises to use Resource Manager in Active-Active high-availability. Refer to the Genesys Voice Platform Integration section in the ''Framework 8.1 SIP Server Deployment Guide''. Integration Reference Manual 108

109 F5 Networks BIG-IP LTM Configuring SIP Server HA Configuring SIP Server HA To configure SIP Server HA, complete the following steps: 1. Configure Host objects for primary and backup SIP Server applications. 2. Configure primary and backup SIP Server applications. Configuring Host objects Purpose To configure a Host object for the computer on which a primary SIP Server application runs and to configure a Host object for the computer on which a backup SIP Server application runs. Start 1. In Configuration Manager, right-click the Environment > Hosts folder and select New > Host. 2. On the General tab: a. Enter the name of the host for the primary SIP Server application for example, b. Enter the IP address of the host for example, c. Select the type of operating system from the OS Type drop-down list, and enter its version, if known. d. Enter the LCA port number or accept the default (4999) to be used by the Management Layer to control applications running on this host. 3. Click OK. 4. Right-click the Environment > Hosts folder and select New > Host. 5. On the General tab: a. Enter the name of the host for the backup SIP Server application for example, b. Enter the IP address of the host for example, c. Select the type of operating system from the OS Type drop-down list, and enter its version, if known. d. Enter the LCA port number or accept the default (4999) to be used by the Management Layer to control applications running on this host. 6. Click OK. End Next Steps Configuring primary and backup SIP Server applications Integration Reference Manual 109

110 F5 Networks BIG-IP LTM Configuring SIP Server HA Configuring primary and backup SIP Server applications Purpose To configure primary and backup SIP Server applications. Note: To configure SIP Server to use TLS encryption, refer to the Transport Layer Security for SIP Traffic section in the Framework 8.1 SIP Server Deployment Guide. Start 1. Open the primary SIP Server application. 2. Click the Server Info tab, and then specify the Host you created for the primary SIP Server application for example, Click the Options tab. In the TServer section, set options as specified in the following table: Configuration Options for a Primary SIP Server Application Option Name Option Value Description sip-address String Set this option to the value of the BIG-IP LTM Virtual IP address, which is the destination address for all incoming SIP messages. In our example, this would be sip-port 5060 Set this option to the value of the port on which SIP Server listens to incoming SIP requests. The same port number is used for both TCP and UDP transports. The port of the Virtual Server configured on BIG-IP LTM for SIP communications with SIP Server over UDP and TCP must match this value. In our example, this would be sip-interface String Set this option to the value of the host physical IP address where the primary SIP Server runs. In our example, this would be internal-registrar-enabled true, false Set this option to true. internal-registrar-persistent true, false Set this option to true. sip-hold-rfc3264 true, false Set this option to true. 4. When you are finished, click OK. 5. Open the backup SIP Server application. Integration Reference Manual 110

111 F5 Networks BIG-IP LTM Configuring SIP Server HA 6. Click the Server Info tab, and then specify the Host you created for the backup SIP Server application for example, Click the Options tab. In the TServer section, set options as specified in the following table: Configuration Options for a Backup SIP Server Application Option Name Option Value Description sip-address String Set this option to the value of the BIG-IP LTM Virtual IP address, which is the destination address for all incoming SIP messages. In our example, this would be sip-port 5060 Set this option to the value of the port on which SIP Server listens to incoming SIP requests. The same port number is used for both TCP and UDP transports. The port of the Virtual Server configured on BIG-IP LTM for SIP communications with SIP Server over UDP and TCP must match this value. In our example, this would be sip-interface String Set this option to the value of the host physical IP address where the backup SIP Server runs. In our example, this would be internal-registrar-enabled true, false Set this option to true. internal-registrar-persistent true, false Set this option to true. sip-hold-rfc3264 true, false Set this option to true. 8. When you are finished, click OK. End Integration Reference Manual 111

112 F5 Networks BIG-IP LTM Configuring BIG-IP LTM Configuring BIG-IP LTM The following page provides an overview of the main steps that are required in order to configure the BIG-IP LTM. Complete all steps in the order in which they are listed. Integrating with BIG-IP LTM 1. Check Prerequisites. Verify that BIG-IP LTM is working The procedures in this topic assume that the BIG-IP LTM is properly licensed and fully functional, with login and password access configured. For more information, see BIG-IP LTM specific documentation. 2. Configure VLANs. Configuring VLANs Purpose To configure two VLANs (Virtual Local Area Networks): one VLAN for the external interface (physical interface 1.3) and one VLAN for the internal (SIP Server side) interface (physical interface 1.6). VLANs are used to logically associate Self IP interfaces with physical interfaces on the BIG-IP LTM. Prerequisites You are logged in to the BIG-IP LTM web interface. Start 1. Go to Network > VLANs > VLAN List. 2. Click Create. 3. In the dialog box that appears, specify the following properties: a. Name: Enter the VLAN name for the external interface for example, dc1ext. b. Tag: 4092 (it is set automatically). Integration Reference Manual 112

113 F5 Networks BIG-IP LTM Configuring BIG-IP LTM c. Resources > Interfaces > Untagged: Select 1.3 in the Available section and click the left-pointing arrow button to move it into the Untagged section. Configuring a VLAN for the External Interface 4. Click Finished. 5. Click Create. 6. In the dialog box that appears, specify the following properties: a. Name: Enter the VLAN name for the internal interface for example, dc2sip. b. Tag: 4090 (it is set automatically). c. Resources > Interfaces > Untagged: Select 1.6 in the Available section and click the left-pointing arrow button to move it into the Untagged section. Configuring a VLAN for the Internal Interface Integration Reference Manual 113

114 F5 Networks BIG-IP LTM Configuring BIG-IP LTM 7. Click Finished. End 3. Configure Self IP addresses. Configuring Self IP addresses Purpose To configure two Self IP addresses one for the external interface and one for the internal interface and associate them with the VLANs, to access hosts in those VLANs. Prerequisites Procedure: Configuring VLANs Start 1. Go to Network > Self IPs. 2. Click Create. 3. In the dialog box that appears, specify the following properties: a. Name: Enter the name for the Self IP address for example, dc1ipext. b. IP Address: Enter the IP address for the internal interface for example, c. Netmask: Enter the netmask for example, d. VLAN: Select the name of the VLAN to which you want to assign the Self IP address for example, dc1ext. Configuring a Self IP Address for the External Interface 4. Click Finished. Integration Reference Manual 114

115 F5 Networks BIG-IP LTM Configuring BIG-IP LTM 5. Click Create. 6. In the dialog box that appears, specify the following properties: a. Name: Enter the name for the Self IP address for example, dc2ipsip. b. IP Address: Enter the IP address for the internal interface for example, c. Netmask: Enter the netmask for example, d. VLAN: Select the name of the VLAN to which you want to assign the self IP address for example, dc2sip. Configuring a Self IP Address for the Internal Interface 7. Click Finished. End 4. Configure the Default IP route. Configuring the Default IP route Purpose To configure the default IP route. Prerequisites Procedure: Configuring Self IP addresses Start 1. Go to Network > Routes. 2. Click Add. Integration Reference Manual 115

116 F5 Networks BIG-IP LTM Configuring BIG-IP LTM 3. In the dialog box that appears, specify the following properties: a. Name: Enter Default. b. Resource: Select Use Gateway. c. Gateway Address: Enter the IP address for this default IP route for example, Configuring Default IP Route 4. Click Finished. End 5. Configure SIP Server nodes. Configuring SIP Server nodes Purpose To configure two SIP Server nodes, primary and backup. Prerequisites Procedure: Configuring the Default IP route Start 1. Go to Local Traffic > Nodes. 2. Click Create. 3. In the dialog box that appears, specify the following properties: a. Name: Enter the node name for example, nodeha01primary. b. Address: Enter the IP address for the primary SIP Server node for example, Integration Reference Manual 116

117 F5 Networks BIG-IP LTM Configuring BIG-IP LTM c. Health Monitors: Select Node Specific. d. Select Monitors > Active: Select icmp. Configuring a Primary SIP Server Node 4. Click Finished. 5. Click Create. 6. In the dialog box that appears, specify the following properties: a. Name: Enter the node name for example, nodeha01backup. b. Address: Enter the IP address for the backup SIP Server node for example, c. Health Monitors: Select Node Specific. d. Select Monitors > Active: Select icmp. Integration Reference Manual 117

118 F5 Networks BIG-IP LTM Configuring BIG-IP LTM Configuring a Backup SIP Server Node 7. Click Finished. 6. Configure a health monitor. Configuring a health monitor In general, the BIG-IP LTM uses health monitors to determine whether a server to which messages can be routed is operational (active). Servers that are flagged as not operational (inactive) will cause the BIG-IP LTM to route messages to another server if one is present in the same server pool. However, primary and backup SIP Servers must be configured as the only members of the same server pool--one member active (primary) and one member inactive (backup). In this procedure, the BIG-IP LTM is configured to use the health monitor of SIP type in UDP mode. This means that the OPTIONS request method will be sent to both primary and backup SIP Servers. Any response to OPTIONS is configured as Accepted Status Code. SIP Server always starts in backup mode, establishes a permanent connection with the Genesys Management Layer, and changes its role to primary only if a trigger from the Management Layer is received. Such trigger is only generated if no other primary SIP Server is currently running. After switching to primary mode, SIP Server responds to UDP packets received on the SIP port specified by the sip-port configuration option. Therefore, after receiving Integration Reference Manual 118

119 F5 Networks BIG-IP LTM Configuring BIG-IP LTM the OPTIONS request from the BIG-IP LTM, SIP Server responds to the health check, and the BIG-IP LTM marks SIP Server as active. When running in backup mode, SIP Server ignores UDP messages. Since the BIG-IP LTM does not receive any response to the OPTIONS request, it marks the backup SIP Server as inactive. If SIP Server does not respond because of network latency or other reasons, the BIG-IP LTM will mark SIP Server as inactive, and continue sending ping messages periodically. The Interval setting defines how often pool members (primary and backup) are checked for presence. The Timeout setting defines the waiting time before an unresponsive member of the pool is marked as inactive. Regardless of the member's status (or SIP Server status), the BIG-IP LTM will always check servers for presence. When an inactive member responds to the health check, it is marked as active. In this configuration, the Interval parameter is set to 1 second and Timeout to 4 seconds in order to minimize a possible delay that might result from a switchover. Start 1. Go to Local Traffic > Monitors. 2. Click Create. 3. In the dialog box that appears, specify the following properties: a. Name: Enter the name for this health monitor for example, monsipudp. b. Type: Select SIP. c. Configuration: Select Basic. d. Interval: Enter 1 (seconds). e. Timeout: Enter 4 (seconds). f. Mode: Select UDP. g. Additional Accepted Status Codes: Select Any. Integration Reference Manual 119

120 F5 Networks BIG-IP LTM Configuring BIG-IP LTM Configuring a Health Monitor 4. Click Finished. End 7. Configure a server pool. Configuring a server pool Purpose To configure a server pool with which the BIG-IP LTM will communicate. Start 1. Go to Local Traffic > Pools. 2. Click Create. 3. In the dialog box that appears, specify the following properties: a. Name: Enter the name for this server pool for example, the poolha01. b. Health Monitors > Active: Select monsipudp. c. Action On Service Down: Select Reselect. Integration Reference Manual 120

121 F5 Networks BIG-IP LTM Configuring BIG-IP LTM d. Priority Group Activation: Select Disabled. Configuring a Server Pool 4. Click Finished. End 8. Add server pool members. Adding server pool members Purpose To add primary and backup SIP Servers to the server pool. Note that they must be the only members of this server pool. Integration Reference Manual 121

122 F5 Networks BIG-IP LTM Configuring BIG-IP LTM Start 1. Go to Local Traffic > Pools > poolha01 > Members. 2. Click Add. 3. In the dialog box that appears, specify the following properties: a. Node Name: Select the primary server node you created in Configuring SIP Server nodes. In our example, it would be nodeha01primary. b. Address: Specify the IP address of the primary server node. In our example, it would be c. Service Port: Enter Adding the Primary SIP Server to the Server Pool 4. Click Finished. 5. Click Add. 6. In the dialog box that appears, specify the following properties: a. Node Name: Select the backup server node you created in the Configuring SIP Server nodes. In our example, it would be nodeha01backup. b. Address: Specify the IP address of the backup server node. In our example, it would be c. Service Port: Enter Integration Reference Manual 122

123 F5 Networks BIG-IP LTM Configuring BIG-IP LTM Adding the Backup SIP Server to the Server Pool 7. Click Finished. 8. Set the Load Balancing Method to Round Robin. 9. Go to Local Traffic > Pools. The status of the nodeha01primary server pool member displays as available (green). The Server Pool of Two Members End 9. Configure data groups. Configuring data groups Purpose Integration Reference Manual 123

124 F5 Networks BIG-IP LTM Configuring BIG-IP LTM To configure data groups that will be used by the irule. One data group (datagroupsnatha01) contains physical IP addresses of primary and backup SIP Server nodes. The second data group (datagroupsnatexcludedha01) contains IP addresses of the systems that will be excluded from applying SNAT, such as Genesys Configuration Server, Genesys Message Servers and other SIP Servers in multi-site deployments (see the Device Communication Groups figure). Start 1. Go to Local Traffic > irules > Data Group List. 2. Click Create. 3. In the dialog box that appears, specify the following properties: a. Name: Enter the name for this data group for example, datagroupsnatexcludedha01. b. Type: Select Address. c. Address Records > Type Host > Address: Enter the host IP address of the primary server node for example, d. Click Add. e. Address Records > Type Host > Address: Enter the host IP address of the backup server node for example, f. Click Add. Configuring a Data Group for SNAT 4. Click Finished. 5. Click Create. Integration Reference Manual 124

125 F5 Networks BIG-IP LTM Configuring BIG-IP LTM 6. In the dialog box that appears, specify the following properties: a. Name: Enter the name for this data group for example, datagroupsnatexcluded01. b. Type: Select Address. c. Address Records > Type Host > Address: Enter the host IP address of Genesys Configuration Server for example, d. Click Add. Configuring a Data Group for SNAT Exclusions 7. Click Finished. End 10. Configure a SNAT pool. Configuring a SNAT pool Purpose To configure a SNAT pool that specifies the Virtual IP address to be used as a source IP address for any packet that originates from the primary or backup SIP Server to which SNAT is applied (with the exception of the devices specified in the datagroupsnatexcluded01 data group). SNAT is the mapping of one or more original IP addresses to a translation address. Integration Reference Manual 125

126 F5 Networks BIG-IP LTM Configuring BIG-IP LTM Start 1. Go to Local Traffic > SNATs. 2. Click Create. 3. In the dialog box that appears, specify the following properties: a. Name: Enter the name for this SNAT pool for example, snatpoolvipha01. b. Configuration > Members List > IP Address: Enter the IP address to be used as a source IP address for example, c. Click Add. Configuring a SNAT Pool 4. Click Finished. End 11. Configure an irule. Configuring an irule Purpose To configure an irule that is used to perform SNAT to the Virtual IP address to any packets that originate from the primary or backup SIP Server (with the exception of the packets addressed to Configuration Server and the Genesys T-Library Clients group). This irule will then be associated with a Virtual Server for the outbound traffic, vswildcardoutbound. In this deployment architecture, the HA synchronization traffic between primary and backup SIP Servers does not pass through the BIG-IP LTM, that is why it is excluded from applying SNAT. Integration Reference Manual 126

127 F5 Networks BIG-IP LTM Configuring BIG-IP LTM Start 1. Go to Local Traffic > irules. 2. Click Create. 3. In the dialog box that appears, specify the following properties: a. Name: Enter the name for this irule for example, irulesnatoutboundha01. b. Definition: Enter the following text: #======================================================# # Apply SNAT as specified in snatpoolvipha01 for all # packets originated from datagroupsnatha01 members. # Exclude packets addressed to members of # datagroupsnatexcludedha01. #======================================================# when CLIENT_ACCEPTED { if { [class match [IP::remote_addr] equals datagroupsnatha01] } { if { [class match [IP::local_addr] equals datagroupsnatexcludedha01] } { } else { snatpool snatpoolvipha01 } } } 4. Click Finished. End 12. Configure a Virtual Server. Configuring a Virtual Server Complete the following steps: [+] Configuring a Virtual Server for outbound traffic Purpose To configure a Virtual Server to be used for outbound traffic. It is associated with a VLAN that is configured for the internal interface (see Procedure: Configuring VLANs) and it has irule assigned to Resources, which applies SNAT to all packets (except for packets addressed to Configuration Server). Prerequisites Integration Reference Manual 127

128 F5 Networks BIG-IP LTM Configuring BIG-IP LTM Procedure: Configuring an irule Start 1. Go to Local Traffic > Virtual Servers. 2. Click Create. 3. In the dialog box that appears, specify the following properties: a. Name: Enter the name for this Virtual Server for example, vswildcardoutbound. b. Type: Select Forwarding (IP). c. Destination > Type: Select Network. d. Destination > Address: Enter e. Destination > Mask: Enter f. Service Port: Enter * All Ports. g. Configuration: Select Advanced. h. Protocol: Select * All Protocols. i. VLAN Traffic: Select Enabled on... j. VLAN List Selected: Select dc2sip. k. SNAT Pool: Select None. l. Source Port: Select Preserve. Integration Reference Manual 128

129 F5 Networks BIG-IP LTM Configuring BIG-IP LTM Configuring a Wildcard Virtual Server for Outbound Traffic 4. Click Finished. 5. Go to Local Traffic > Virtual Server List > vswildcardoutbound > Resources. 6. Add irule as follows: Resources > irule Enabled > irulesnatoutboundha01 End [+] Configuring a Virtual Server for inbound traffic Purpose Integration Reference Manual 129

130 F5 Networks BIG-IP LTM Configuring BIG-IP LTM To configure a Virtual Server for inbound traffic. In Layer 3/Routing configuration mode, the BIG-IP LTM passes through only those packets that have a destination matching a virtual server. Having the Virtual Server for inbound traffic allows packets with a destination that matches the physical IP address of the primary or backup SIP Server to pass through. Start 1. Go to Local Traffic > Virtual Servers. 2. Click Create. 3. In the dialog box that appears, specify the following properties: a. Name: Enter the name for this Virtual Server for example, vswildcardinbound. b. Type: Select Forwarding (IP). c. Destination > Type: Select Network. d. Destination > Address: Enter e. Destination > Mask: Enter f. Service Port: Enter * All Ports. g. Configuration: Select Advanced. h. Protocol: Select * All Protocols. i. VLAN Traffic: Select Enabled on... j. VLAN List Selected: Select dc1ext. Integration Reference Manual 130

131 F5 Networks BIG-IP LTM Configuring BIG-IP LTM Configuring a Wildcard Virtual Server for Inbound Traffic 4. Click Finished. End [+] Configuring Virtual Servers for UDP and TCP SIP communications Purpose To configure two virtual servers to handle traffic directed to a Virtual IP address: one virtual server for SIP communications using the UDP as a transport protocol and one virtual server for SIP communications using the TCP as a transport protocol. The Virtual IP address is used by SIP clients to contact SIP Server. In other words, the Virtual IP address hides two physical IP addresses (used by the primary and backup servers) and presents the SIP Server HA pair as a single entity for all SIP-based communications. Integration Reference Manual 131

132 F5 Networks BIG-IP LTM Configuring BIG-IP LTM Start 1. Go to Local Traffic > Virtual Servers. 2. Click Create. 3. In the dialog box that appears, specify the following properties: a. Name: Enter the name for this Virtual Server for example, vsvipudpha01. b. Destination > Type: Select Host. c. Destination > Address: Enter the IP address for this Virtual Server for example, d. Service Port: Enter 5060 and select Other. e. State: Select Enabled. f. Configuration: Select Advanced. g. Type: Select Standard. h. Protocol: Select UDP. i. SMTP Profile: Select None. j. SIP Profile: Select sip. k. VLAN Traffic: Select Enabled on... l. VLAN List Selected: Select dc1ext. Integration Reference Manual 132

133 F5 Networks BIG-IP LTM Configuring BIG-IP LTM Configuring a Virtual Server for UDP-Based Communications Integration Reference Manual 133

134 F5 Networks BIG-IP LTM Configuring BIG-IP LTM 4. Click Finished. 5. Select Resources > Load Balancing > Default Pool: Select poolha Click Update. 7. Go to Local Traffic > Virtual Servers. 8. Click Create. 9. In the dialog box that appears, specify the following properties: a. Name: Enter the name for this Virtual Server for example, vsviptcpha01. b. Destination > Type: Select Host. c. Destination > Address: Enter the IP address for this Virtual Server for example, d. Service Port: Enter 5060 and select Other. e. State: Select Enabled. f. Configuration: Select Basic. g. Type: Select Standard. h. Protocol: Select TCP. i. SMTP Profile: Select None. j. SIP Profile: Select sip. k. VLAN Traffic: Select Enabled on... l. VLAN List Selected: Select dc1ext. Integration Reference Manual 134

135 F5 Networks BIG-IP LTM Configuring BIG-IP LTM Creating a Virtual Server for TCP-Based Communications 10. Click Finished. 11. Select Resources > Load Balancing > Default Pool: Select poolha Click Update. End Note: SNAT pool must not be activated as the configuration element of Virtual Server. SNAT must not be applied to SIP messages sent by clients to SIP Server. Enabling SNAT for these messages results in a broken call flow, as in some circumstances the SNAT is not aligned with SIP Protocol. Integration Reference Manual 135

136 F5 Networks BIG-IP LTM Configuring TLS Configuring TLS Secure data transfer using TLS is now supported between SIP Server and Active-Active Resource Managers in a deployment where SIP Server high-availability is configured using the F5 Networks BIG-IP LTM. TLS is also supported between SIP Server and all SIP devices in this deployment, including SBCs, Media Gateways, and SIP phones. BIG-IP LTM is not a TLS peer as are other elements in the environment; there is no TLS negotiation between BIG-IP LTM and other components. Integration Solution Assumptions The integration solution described in this section makes the following assumptions: BIG-IP LTM is deployed as a single instance TLS transport is used for SIP signaling SIP Server performs load balancing between an Active-Active Resource Manager pair See Deployment Architecture Example. Deploying the TLS Solution To support TLS data transfer in a SIP Server deployment with an Active-Active RM pair and a BIG-IP LTM used for the SIP Server HA, complete the following procedures: 1. Configure BIG-IP LTM for TLS. 2. Provision SSL certificates for workstations hosting SIP Servers, RM, and MCP applications. Refer to the ''Genesys 8.1 Security Deployment Guide''. 3. Configure SIP Server to use TLS data transfer. Refer to the Transport Layer Security for SIP Traffic section in the Framework 8.1 SIP Server Deployment Guide. 4. Configure Resource Managers in an Active-Active high-availability cluster. Refer to the Genesys Voice Platform Integration section in the ''Framework 8.1 SIP Server Deployment Guide''. To configure TLS data transfer between Genesys Media Server components, refer to the ''Genesys Media Server 8.1 Deployment Guide''. Configuring BIG-IP LTM for TLS 1. Complete general configuration procedures. Before starting the TLS-specific configuration of BIG-IP LTM, complete the configuration procedures. Integration Reference Manual 136

137 F5 Networks BIG-IP LTM Configuring TLS 2. Configure a health monitor. To configure a health monitor: 1. Go to Local Traffic > Monitors. 2. Click Create. 3. In the dialog box that appears, specify the following properties: Name: Enter the name for this health monitor for example, monsiptls. Type: Select TCP. Parent Monitor: Select TCP. Configuration: Select Basic. Interval: Enter 1 (seconds). 4. Click Finished. 3. Configure a server pool. To configure a server pool: 1. Go to Local Traffic > Pools. 2. Click Create. 3. In the dialog box that appears, specify the following properties: Name: Enter the name for this server pool for example, the poolha01tls. Configuration: Select Advanced. Health Monitors > Active: Select monsiptls. Action On Service Down: Select Reselect. Slow Ramp Time: Enter0 (seconds). 4. Click Finished. 4. Add server pool members. To add server pool members: 1. Go to Local Traffic > Pools > poolha01tls > Members. 2. Click Add. Integration Reference Manual 137

138 F5 Networks BIG-IP LTM Configuring TLS 3. In the dialog box that appears, specify the following properties: Node Name: Select the primary server node. In our example, it would be nodeha01primary. Address: Specify the IP address of the primary server node. In our example, it would be Service Port: Enter Click Finished. 5. Click Add. 6. In the dialog box that appears, specify the following properties: Node Name: Select the backup server node. In our example, it would be nodeha01backup. Address: Specify the IP address of the backup server node. In our example, it would be Service Port: Enter Click Finished. 8. Set the Load Balancing Method to Round Robin. 5. Configure a Virtual Server. To configure a Virtual Server: 1. Go to Local Traffic > Virtual Servers. 2. Click Create. 3. In the dialog box that appears, specify the following properties: Name: Enter the name for this Virtual Server for example, vsviptlsha01. Destination > Type: Select Host. Destination > Address: Enter the IP address for this Virtual Server for example, Service Port: Enter 5061 (Other). State: Select Enabled. Configuration: Select Basic. Type: Select Standard. Protocol: Select TCP. VLAN and Tunnel Traffic: Select Enabled on... VLANs and Tunnels Selected: Select dc1ext. 4. Click Finished. 5. Select Local Traffic > Virtual Server List > vsviptlsha01 > Resources. Integration Reference Manual 138

139 F5 Networks BIG-IP LTM Configuring TLS 6. Add Default Pool: poolha01tls 7. Click Update. 6. Disable Virtual Servers for UDP and TCP. At this point, the BIG-IP LTM is configured for handling communications over different protocols: UDP, TCP, and TLS. If TLS is mandatory for security reasons, Genesys strongly recommends disabling virtual servers for insecure protocols, such as UDP and TCP. To disable Virtual Servers for UDP and TCP: 1. Go to Local Traffic > Virtual Servers. 2. Select check boxes of the following virtual servers: vsvipudpha01 and vsviptcpha Click Disable. This completes configuring BIG-IP LTM. Integration Reference Manual 139

140 F5 Networks BIG-IP LTM Deployment Architecture Example Deployment Architecture Example The figure below depicts the architecture of a sample deployment of primary and backup SIP Servers, Active-Active Resource Manager pair, and the BIG-IP LTM, in which: BIG-IP LTM provides a single Virtual IP address for SIP phones and Media Server. The pair of SIP Servers configured in Hot-Standby mode is located behind BIG-IP LTM and the actual IP addresses of the primary and backup SIP Servers are not exposed to phones or Media Server components. All SIP entities in the environment phones, SIP Servers, Resource Managers, MCPs can use TLS for SIP signaling if configured. Integration Reference Manual 140

141 RedSky E911 Manager Deployment Architecture Example RedSky E911 Manager Starting with release , Genesys SIP Server can operate with the RedSky E911 Manager system, the provider of emergency (911) calls in the VoIP environment. Workspace SIP Endpoint version or later must be used for this integration. SIP Server was tested with the following RedSky components: RedSky E911 Manager version RedSky Emergency Gateway version All communication transport protocols are supported: UDP, TCP, or TLS. For this integration, you configure: Genesys SIP Server, DN configuration objects RedSky components Genesys Configuration Configure the following DN configuration objects under the SIP Server switch: The DN object of type Trunk for the RedSky E911 Manager must have the following options configured in the TServer section: contact Set to the RedSky E911 Manager URI. The URI format is described in the contact option description in the Framework 8.1 SIP Server Deployment Guide. prefix Set to a value that matches emergency call starting digits. contact-list Configure this option if there is more than one instance of the Red Sky E911 Manager in the environment. oos-check oos-force emergency-device Set to true. The DN object of type Trunk for the RedSky Emergency Gateway must have the following options configured in the TServer section: contact Set to the RedSky Emergency Gateway URI. prefix Set to a value different from the Trunk DN pointing to Red Sky Server. contact-list Configure this option if there is more than one instance of the Red Sky Server in the environment. oos-check Integration Reference Manual 141

142 RedSky E911 Manager Deployment Architecture Example oos-force emergency-device Set to true. The SIP Server Application must contain the following configuration options in the TServer section: subscription-event-allowed Set this option to reg or * (asterisk). subscription-max-body-size Define the maximum size of the NOTIFY XML body (in bytes) within the SUBSCRIBE dialog. The default value is The range of valid values is If the option is set to 0 (zero), the message body can be any size. The zero value can be used for TCP transport but is not recommended for UDP. For bulk notification, SIP Server sends more than one NOTIFY, so adjust the size accordingly. sip-elin-timeout Define the time interval, in seconds, for SIP Server to keep in memory the association between a 911 caller and the Emergency Location Identification Number (ELIN) assigned to the caller. The default value is The range of valid values is If a call arrives at that ELIN before the timeout expires, the call is sent to the associated 911 caller DN. If within this time interval there are several emergency calls with the same ELIN, SIP Server directs the callback to the latest caller. RedSky Configuration On the RedSky side, configure the following components: RedSky Emergency Gateway RedSky E911 Manager Add "Genesys" as a call server using the Call Servers module. Refer to RedSky documentation for details. RedSky E911 Manager subscribes to SIP Server for endpoint state notifications. It discovers a physical location of a DN based on its IP address and, if possible, its MAC address, then assigns the Emergency Location Identification Number (ELIN) to each endpoint. When E911 Manager receives an emergency call initial INVITE message, it redirects it providing the ELIN of the calling endpoint. The RedSky Emergency Gateway receives the redirected INVITE and sends the voice call to the public-safety answering point (PSAP) agency. Integration Reference Manual 142

143 RedSky E911 Manager Deployment Architecture Example Known Limitations For the SIP Server and RedSky solution to work correctly, the following conditions must be met: SIP Server is running in the non-cloud environment (no SBC to mask endpoint IP addresses with its own address). Agent DNs are self-registered endpoints. The MAC address is provided to RedSky only for deployment with Genesys SDK-based endpoints running on dedicated hardware hosts (not virtual machines). Integration Reference Manual 143