Genesys SIP Server Architecture
23 likes25,300 views
The document provides an overview of the Genesys SIP Server, including its fundamental purpose, architecture, deployment modes, load balancing capabilities, multi-threaded design, multi-site support, and important network considerations for ensuring quality voice services. The SIP Server combines call switching and T-Server functionality, and can operate with or without a third-party softswitch in various deployment configurations. Proper network sizing, bandwidth provisioning, quality of service controls, and remote access methods are critical to delivering high quality voice.
Genesys SIP Server Architecture
- 1. Contact Center & IP Telephony Architect Genesys SIP Server Overview
- 2. Contact Center & IP Telephony Architect Table of Contains 1. Genesys SIP Server Fundamental .............................................................................................................. 3 2. SIP Server Architecture ............................................................................................................................... 3 2.1. SIP Server Deployment Modes: .............................................................................................................. 4 2.1.1. Standalone Mode ................................................................................................................................ 4 2.1.2. Application Server Mode..................................................................................................................... 5 2.1.3. Customer-Side Proxy Mode ................................................................................................................ 6 2.2. Media Server Deployment Architecture ................................................................................................. 7 3. Redundant Sip Servers (High Availability) .................................................................................................. 8 4. Load Balancing ............................................................................................................................................ 9 5. Multi-Threaded Architecture.................................................................................................................... 11 5.1. Multi-Threaded Versus Single-Threaded Mode ................................................................................... 11 5.2. Logging .................................................................................................................................................. 11 6. Multi-Site Support .................................................................................................................................... 11 7. Network Considerations ........................................................................................................................... 12 7.1. Voice Quality ......................................................................................................................................... 12 7.2. Bandwidth Requirements ..................................................................................................................... 13 7.3. Remote Agent Configuration ................................................................................................................ 14 7.3.1. Bandwidth and Network Tuning ....................................................................................................... 14 7.3.2. Firewalls............................................................................................................................................. 14
- 3. Contact Center & IP Telephony Architect 1. Genesys SIP Server Fundamental SIP Server has the same position in the Genesys Media Layer as all Genesys T-Servers. SIP Server is a combined T-Server and a call-switching component, in which the call-switching element functions as a SIP (Session Initiation Protocol) Back-to-Back User Agent (B2BUA). In concrete terms, this means that call switching and control is performed by Genesys—no third-party PBX or ACD system is required. A call’s audio signal and its associated data travel on a single network, which eliminates the problems associated with synchronizing separate voice and data networks. Because SIP Server supports the Internet Engineering Task Force (IETF) SIP RFC 3261 suite, it is compatible with the most popular SIP-compatible, off-the-shelf hardware or software. SIP Server can operate with or without a third-party softswitch. Genesys SIP Server gives the entire Genesys line of products access to SIP networks, offering a standards-based, platform-independent means of taking full advantage of the benefits of voice/data convergence. 2. SIP Server Architecture SIP Server provides all SIP signaling and T-Server functions. Stream Manager is an optional component that is used to play music-on-hold, music-in-queue and announcements, and to collect DTMF digits. A third-party music server is an optional component that is used as an external music source for music-on-hold. A Multipoint Conference Unit (MCU) is an optional component that is used for third-party call control (3pcc) conference calls. It is also used for silent voice monitoring, whisper coaching, intrusion monitoring, and agent-initiated call recording. The SIP messages that SIP Server sends or receives are very similar in all configurations, but the destination to which SIP Server sends the SIP requests differs according to the deployment configuration. This mostly applies to the routing of INVITE messages. Other messages follow the path established by INVITE.
- 4. Contact Center & IP Telephony Architect 2.1. SIP Server Deployment Modes: The following SIP Server deployment modes are currently supported: • • • Standalone mode Application Server mode Customer-side proxy mode 2.1.1. Standalone Mode In this configuration, SIP Server sends all messages to the addresses of the customer and agent endpoints. The IP addresses in this scenario are determined by SIP Server from either of the following sources: • Configuration Layer: When, for each agent DN, an IP address is configured on the DN Options/Annex tab. For example, for DN 1077 on the Options/Annex tab in the TServer section, you set the contact option to the 1077@192.168.2.55 value. This is useful for agent endpoints. • Lookup in the local registrar: When the agent DN is defined with the registrar as agent1@company.com,and its SIP endpoint has registered this SIP URI (Uniform Resource Indicator) with the registrar as 1077@192.168.2.55, the INVITE message is sent to the IP address 192.168.2.55. • SIP Server resolves the name as it was dialed. For example, if the dialed name is customer@somedomain.com, the request is sent to the address somedomain.com.
- 5. Contact Center & IP Telephony Architect 2.1.2. Application Server Mode In the configuration shown in Figure 3, SIP Server is deployed as an Application Server behind a softswitch. This is the most common deployment of SIP Server. In the Application Server mode, SIP Server communicates with a single softswitch. SIP Server is configured to send all INVITE requests to the IP address of the softswitch. In this configuration, the softswitch bypasses SIP Server for direct agent-to-agent calls. As a consequence, agent-toagent calls are not visible to SIP Server, and it cannot provide any control over these calls.
- 6. Contact Center & IP Telephony Architect 2.1.3. Customer-Side Proxy Mode In the configuration shown in Figure 4, a softswitch is deployed between SIP Server and agent endpoints, but customer endpoints communicate directly with SIP Server. All inbound calls (from customers to agents) are routed by SIP Server to a softswitch, the IP address of which is configured in Configuration Manager. For outbound calls (from agents to customers), the IP addresses are determined from the Request URI message, or they are configured in Configuration Manager as gateways (DNs of type Trunk). Alternatively, SIP Server can resolve the name as it was dialed. For example, if the dialed name iscustomer@somedomain.com, the request is sent to the address somedomain.com. In this configuration, the softswitch bypasses SIP Server for direct agent-to-agent calls. As a consequence, agent-to-agent calls are not visible to SIP Server, and it cannot provide any control over these calls.
- 7. Contact Center & IP Telephony Architect 2.2. Media Server Deployment Architecture The given figure illustrates one possible deployment architecture for a third-party media server (such as a music server or MCU), or for Genesys Stream Manager used in conjunction with SIP Server and Genesys business applications. Call Scenario: 1. A call arrives and is established with a contact center agent. SIP Server operates as a SIP B2BUA and maintains two separate SIP dialogs, one for the customer and one for the agent. The RTP stream is negotiated between the customer and agent endpoints directly, using the codec. SIP Server provides flexibility with manipulation of SDP information. 2. The agent invokes a call-hold operation either by using a THoldCall request to SIP Server, or by pressing the Hold button on the endpoint. 3. SIP Server selects a media server in sequence from among all configured servers with the same priority, and then establishes a new SIP dialog to the music server. SIP Server then sends the INVITE message to the customer session to connect the RTP stream to the music server, and then reINVITEs the agent session to stop RTP traffic from it. 4. When the agent invokes a call-retrieve operation either by using the TRetrieveCall request, or by pressing the Retrieve button on the endpoint, SIP Server terminates the music dialog by sending a BYE message, and then re-INVITEs the customer session to connect the RTP stream with the agent endpoint.
- 8. Contact Center & IP Telephony Architect 3. Redundant Sip Servers (High Availability) SIP Servers can operate in a high-availability (HA) environment, providing you with redundant systems. One basic principle of redundant SIP Servers is the standby redundancy type, which dictates how quickly a backup SIP Server steps in when the primary SIP Server goes down. The Framework Management Layer currently supports two types of redundant configurations: • Warm Standby • Hot Standby. SIP Server in an HA configuration differs from most Genesys T-Servers in the role it performs in the SIP network. It is not a switch, but it does have traditional switching capabilities. There are several options available for setting up a high-availability SIP Server deployment. Each approach has benefits and drawbacks.
- 9. Contact Center & IP Telephony Architect 4. Load Balancing A load-balancing architecture for situations in which the call rate exceeds the capacity of a single SIP Server. In this configuration, all inbound calls first arrive at the Network SIP Server, which performs all initial routing. The routing on the Network SIP Server is either direct to agents, or to the second tier of Routing Points on the SIP Server. Routing inbound calls directly to agents assumes the following: • Multiple TDM-to-VoIP gateways (or incoming SIP firewalls for pure VoIP calls) are deployed to provide sufficient call capacity. • Multiple SIP Servers are deployed. Each can serve up to 2000 agents. • One or more Network SIP Servers are deployed. Given the high throughput of a Network SIP Server, it is very likely that a single SIP Server will be sufficient for most deployments. • Gateways are configured to send all calls to the Network SIP Servers. If multiple Network SIP Servers are required, you can partition gateways, so that they send calls to different SIP Servers; or you can configure each gateway to send calls to one of the Network SIP Servers, based, for example, on call origination or destination.
- 10. Contact Center & IP Telephony Architect As a result, the following provides a generalized call flow: 1. Network SIP Servers communicate with Universal Routing Server (URS) URS selects an agent on one of the SIP Servers by using real-time state information available from the SIP Servers via Stat Servers (not shown). URS responds to the Network SIP Server with the agent’s DN and the location name of the SIP Server. 2. Network SIP Server communicates the ConnID and attached data to the selected SIP Server. It then responds to the PSTN gateway with a 302 message containing the IP address and External Routing Point number on the destination SIP Server. 3. The gateway processes the 302 message, and then sends a new INVITE message to the selected SIP Server. 4. SIP Server receives the INVITE message from the External Routing Point, matches the call, and reroutes it to the selected agent by means of Inter Server Call Control (ISCC).
- 11. Contact Center & IP Telephony Architect 5. Multi-Threaded Architecture The SIP Server application is made up of several internal modules that are able to run separately from one another, as individual threads in their own apartments, using internal interfaces to communicate. This multi-threaded organization allows SIP Server to take advantage of computers with multiple CPUs. By running the modules in separate threads, SIP Server can execute different tasks in parallel, simultaneously across several CPUs. This parallel processing enables SIP Server to handle more calls over a given length of time, as the number of processors available in the system is increased. 5.1. Multi-Threaded Versus Single-Threaded Mode Starting in release 8.0.3, using the sip-link-type option, SIP Server can be configured to run in either multi-threaded mode, or as a single thread for backward compatibility. If running in multi-threaded mode, in addition to the main thread responsible for processing T-Library requests and distributing Events, SIP Server creates a separate thread to manage SIP calls and process SIP signaling, and another thread for the SIP transport layer. 5.2. Logging By default, in multi-threaded mode SIP Server only logs messages from the T-Library thread into a single log file. However, using the x-sip-log option, you can configure SIP Server to create separate log files to handle messages from the other threads. Log messages from each separate thread do not mix into a single file. 6. Multi-Site Support SIP Server, like any conventional T-Server, is built with the T-Server Common Part that contains the ISCC component responsible for call data transfer between multiple sites. Currently, SIP Server supports the following ISCC transaction types: route, direct-notoken, direct-uui, pullback, and reroute. However, directuui is supported only in a pure SIP environment.
- 12. Contact Center & IP Telephony Architect 7. Network Considerations Deploying SIP Server is similar in many ways to deploying other components of the Genesys Framework, with the significant exception that the voice signal is carried over the data network. This has serious implications for network planning and server sizing. The primary purpose of this section is to highlight the major planning and resource concerns you face in rolling out SIP Server, and to explain how it overlaps with the underlying data network. The performance of SIP Server is directly linked to that of the underlying data network. It is essential that you perform a proper network audit to ensure that the data network has been properly sized and tuned for real-time (voice) packet transport. This section discusses the factors that affect overall performance of an IP-based configuration, and provides some general rules to follow when deploying SIP Server. 7.1. Voice Quality The following factors have a direct impact on voice quality: Network latency—Overall network delay. To minimize network latency and ensure acceptable voice quality, you need to tune the network to prioritize real-time voice packets. There are various available schemes for prioritizing voice packets, depending on the IP router vendor. Packet loss—Voice packets that are dropped for various reasons (physical media error, timeout due to network congestion, and so on). Packet loss is a function result of several factors, including network bandwidth. Packet jitter—Variation in voice packet arrival times. You can minimize packet jitter by using a jitter buffer at the endpoint device. As a general rule, you must set the buffer size to the maximum anticipated deviation from the typical interpacket emission time. Other factors that influence voice quality include: Packet misordering—Packets arrive in the wrong order (similar to packetloss). Type of codec used—Codecs that do not compress the audio signal produce better voice quality but use greater bandwidth. Silence suppression—Silence suppression can save bandwidth, but it can also impact voice quality.
- 13. Contact Center & IP Telephony Architect 7.2. Bandwidth Requirements Determining the bandwidth requirements for the underlying data network is another critical step in achieving proper performance and voice quality. Bandwidth requirements for a video connection are, of course, much higher. Genesys recommends that you verify network performance and voice quality by conducting performance tests and measurements in a lab environment prior to production rollout. For an IP/Ethernet network, two factors that affect bandwidth requirements are: • Codec used. • Protocol headers. When estimating actual network bandwidth needs, you must also consider such factors as network efficiency and utilization.
- 14. Contact Center & IP Telephony Architect 7.3. Remote Agent Configuration SIP Server’s remote agent capabilities range from a single remote agent, to a group of remote agents in a branch office environment. The distributed nature of branch office and remote agent architectures adds to the complexity of network sizing and tuning. 7.3.1. Bandwidth and Network Tuning Just as for local network deployment of a VOIP-based system, you must, if at all possible, allot proper bandwidth for voice communication and tune the underlying network for real-time media. Remote agents using a dial-up connection require greater bandwidth (at least 33 Kbps, with 56 Kbps recommended) because of the extra network overhead. This assumes use of the G.723.1 codec, although some dial-up connections may accommodate G.729. A Digital Subscriber Line (DSL) connection is a better alternative than a dial-up connection. The choice of remote access method is important—avoids sending voice communication over an unmanaged data network, such as the public Internet, where voice quality cannot be guaranteed. For a branch office environment, network bandwidth requirements depend on the number of agents. Again, wide-area network (WAN) connectivity to the corporate LAN must be tuned for real-time voice communications. You need to ensure that service-level agreements from your virtual private network (VPN) provider give details of such requirements. End-to-end network latency must not exceed 250 msec. 7.3.2. Firewalls This release of SIP Server provides no explicit support for Network Address Translation (NAT). Genesys recommends using virtual private networks (such as PPTP) and ensuring that all agents are on the same network, without NAT translators between the agents and SIP Server.