Contact Center & IP Telephony Architect

Genesys SIP Server Overview

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

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 Genesysno third-party PBX or ACD system is required. A calls 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.

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.

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.

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.

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.

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.

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.

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

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.

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 latencyOverall 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 lossVoice 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 jitterVariation 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 misorderingPackets arrive in the wrong order (similar to packetloss).

Type of codec usedCodecs that do not compress the audio signal produce better voice quality
but use greater bandwidth.

Silence suppressionSilence suppression can save bandwidth, but it can also impact voice
quality.

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.

Contact Center & IP Telephony Architect

7.3. Remote Agent Configuration

SIP Servers 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 importantavoids 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.