Genesys SIP Server Architecture

Contact Center & IP Telephony Architect

Genesys SIP Server Overview


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


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.


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 [email protected] value. This is useful for

agent endpoints.

• Lookup in the local registrar: When the agent DN is defined with the registrar as

[email protected],and its SIP endpoint has registered this SIP URI (Uniform

Resource Indicator) with the registrar as [email protected], 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 [email protected], the request is sent to

the address somedomain.com.


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-to-

agent calls are not visible to SIP Server, and it cannot provide any control over these calls.


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

[email protected], 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.


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 re-

INVITEs 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.


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.


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.


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).


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, direct-

uui is supported only in a pure SIP environment.


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.


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.


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.

Genesys SIP Server Architecture

Technology

Transcript of Genesys SIP Server Architecture