SIP Server Feature Support. Genesys 8.1
Anúncio
Anúncio
Chapter
5
SIP Server Feature Support
This chapter describes the advanced functionality that SIP Server supports. It contains the following sections:
Application Failure Detection, page 114
Associating an ACD Queue with a Routing Point, page 116
Asterisk Voice Mail Integration, page 116
Automatic Inactive Agent Logout, page 119
Call Completion Features, page 119
Call Divert Destination, page 121
Caller Information Delivery Content for AT&T Trunks, page 122
Call Recording—NETANN-Based, page 126
Call Recording—MSML-Based, page 130
Call Recording—Geo-location, page 141
Call Release Tracking, page 142
Call Transfer and Conference, page 167
Consolidated Error Response, page 190
Control of SIP Response Code from within Routing Strategy, page 192
Customizing Music on Hold and in Queue, page 194
Customizing SIP Header Formats, page 198
SIP Server—Deployment Guide 99
Chapter 5: SIP Server Feature Support
DTMF Clamping in a Conference, page 234
DTMF Tones Generation, page 236
E911 Emergency Gateway, page 240
Early Media for Inbound Calls, page 247
Endpoint Service Monitoring, page 253
Failed Route Notification, page 256
HTTP Monitoring Interface, page 260
Keep Alive for TCP Connections, page 274
Mapping Treatment Errors, page 275
Mapping SIP Headers and SDP Messages, page 276
Masking Sensitive Data in SIP Messages, page 286
Media Server Reliability—NETANN/MSML, page 286
Modifying the From Header in SIP INVITE, page 290.
Multi-Threaded Logging, page 290
Music and Announcements, page 293
Nailed-Up Connections, page 298
Network Asserted Identity, page 303
Network Attended Transfer, page 310
No-Answer Supervision, page 313
Outbound IP Solution Integration, page 317
P-Access-Network-Info Private Header, page 330
Presence from Switches and Endpoints, page 336
Preview Interactions, page 348
Providing a Caller ID, page 349
Providing Call Participant Info, page 349
Providing Origination DN Name and Location in EventRinging, page 351
Remote Media on Genesys SIP Endpoint SDK 8.0, page 356
Remote Server Registration, page 357
100 Framework 8.1
Chapter 5: SIP Server Feature Support ACD Queue
Sending Outgoing INVITEs with Multipart Body, page 357
SIP Traffic Monitoring, page 363
Shared Call Appearance, page 365
Smart OtherDN Handling, page 371
SRV Address Support in Contact and Record-Route Headers, page 373
Transport Layer Security for SIP Traffic, page 374
Trunk Capacity Control, page 379
Trunk Optimization for Multi-Site Transfers, page 383
User to User Information (UUI), page 387
Working with Multiple Devices, page 394
Genesys Voice Platform Integration, page 404
ACD Queue
SIP Server supports Automatic Call Distribution (ACD) Queue functionality.
With this feature enabled, SIP Server places queued incoming calls on hold until an agent or representative in the organization becomes available. The caller is placed in a simple queue, where each call is answered in the order it is received. During the wait, SIP Server plays music or other announcements to the caller. When an agent logged into the queue becomes available, SIP Server automatically connects the caller to the agent’s DN (no manual connection is required).
How It Works
1. A call arrives at an
ACD Queue
DN configured in the SIP Server switch.
Note:
If SIP Server is behind a third-party softswitch, a
Routing Point
DN is used instead of an ACD Queue.
2. Agents are logged into this queue using Genesys Agent Desktop
(Interaction Workspace).
An agent DN can log into only one queue at a time.
SIP Server searches the list of associated DNs for an available agent
Extension
DN.
SIP Server—Deployment Guide 101
Chapter 5: SIP Server Feature Support ACD Queue
3. If no logged in agent is available (all agents currently in the Genesys
NotReady
state or currently on a call), the caller is queued.
If no agent is currently logged into the queue, SIP Server applies alternate
routing to avoid a stranded call. See “Alternate Routing for Stranded Calls” on page 108 .
4. SIP Server plays music or other announcement to the caller while they wait. The music played to the caller in the queue is configurable. For more
information, see the music-in-queue-file
option, as well as “Customizing
Music on Hold and in Queue” on page 194
for details.
5. As soon as an agent
Extension
DN becomes available (Genesys
Ready
state and no active call), SIP Server automatically connects that caller to the
DN. Calls with the longest wait time on an ACD Queue are distributed to agents with the longest idle time.
6. After the agent is done with the call, they are placed at the end of the line for receiving new calls.
Feature Configuration
describes how to configure ACD Queue functionality.
Table 15: Configuring ACD Queue
Objective
1. Configure an ACD
Queue DN.
2. Configure music.
Related Procedures and Actions
See “Configuring ACD Queues” on page 77 .
You can define the music file to be played using the following options. These options are listed in order of priority (default-music on the DN takes precedence over all other settings):
1.
2.
Application
3.
If none of these are configured, SIP Server tries to use the file in the music/on_hold
folder.
Feature Limitation
SIP Server only supports first-in-line queue functionality. It does not support prioritization based on any other criteria.
102 Framework 8.1
Chapter 5: SIP Server Feature Support Advice of Charge
Advice of Charge
SIP Server supports the transfer of Advice of Charge (AoC) information between the T-Library client that determines the charge and the third-party component that generates the charge. For example, when integrated into an IP
Multimedia Subsystem (IMS), SIP Server is able to add AoC information received from the Orchestration Server (ORS) to the
INFO
message that it sends to the IMS, which then generates the charge.
How It Works
SIP Server receives AoC information in a
TPrivateService
message sent from a T-Library client. This client is responsible for determining whether a charge is required for calls involving a particular DN. If the client decides a particular
DN requires a charge, it forwards the required AoC information in a
TPrivateService
request. SIP Server maps the AoC information from the
TPrivateService
to an
INFO
message that it sends the external component responsible for generating the charge (IMS or other switch).
Sample Call Flow
The following sample call flow describes the steps for an incoming call from
IMS, with Orchestration Routing Server (ORS) acting as the T-Library client that determines the charge:
1. The IMS sends an inbound
INVITE
request to SIP Server through the IMS
Trunk
DN.
2. The destination DN (Extension, Routing Point) is registered with ORS;
ORS receives any Events related to this DN.
3. Business rules in ORS determine a charge for the call to this destination is required.
Note:
SIP Server does not itself decide about the charge; all decisions are made in the T-Library application, in this case ORS.
4. ORS sends AoC information, as well as related parameters, in a
TPrivateService
request to SIP Server. The request includes the following:
AoC information as the SIP MIME body in the
AttributeExtensions
DN of AoC sender
Connection ID
5. SIP Server copies this AoC information into an
INFO
request that it sends back to the IMS server.
6. The IMS server is responsible for generating the charge for the call.
SIP Server—Deployment Guide 103
Chapter 5: SIP Server Feature Support Alternate Ringtones
Providing AoC Notifications for Established Calls
SIP Server provides the ability to send AoC notifications only when a call is answered (the destination party is in the established state). It is a regulatory requirement in many countries.
For this feature to work, SIP Server distributes calls through a Routing Point
that is configured with the divert-on-ringing
option set to false.
A T-Library client that monitors the Routing Point (for example, URS or ORS) receives the notification that the call is delivered to the destination when the outgoing call is answered. (SIP Server sends
EventRouteUsed, EventDiverted
to its clients.)
This notification can be used as a trigger for generating an AoC notification using a
TPrivateService(3018)
request.
SIP Server is able to process this request and send a SIP
INFO
AoC message to the destination even though the Routing Point DN, used to route the call and passed as a value of
AttributeThisDN
of the
TPrivateService(3018)
request, is already released from the call.
Feature Configuration
Use the sip-enable-aoc-after-established
notifications for established calls.
Alternate Ringtones
Some endpoints can provide a distinctive ringtone that tells the user what kind of call is arriving on their phone. For example, a triple ring can be used to identify the caller as external to the company. To support endpoints that offer this feature, SIP Server is able to include the SIP
Alert-Info
header in the
INVITE
request that it sends to the endpoint. The value of this header gives the endpoint the information that it needs to start the alternate ringtone—a URI to a ringtone file, or a code that triggers a stored ringtone on the phone itself.
How It Works
If alternate ringtones are configured, when SIP Server receives a T-Library request to initiate a call, it adds the
Alert-Info
header to the resulting
INVITE request. A typical call flow is as follows:
1. SIP Server receives a T-Library request to initiate, transfer, or conference a call. Alternate ringtone functionality is configured on the Application, in the destination DN, or in the
SIP_HEADERS
Extension of the T-Library request itself.
2. SIP Server inserts the
Alert-Info
header in the
INVITE
to the call destination. The value of this header depends on the configuration and the type of call.
104 Framework 8.1
Chapter 5: SIP Server Feature Support Alternate Ringtones
3. On receiving the
INVITE
, the endpoint reads the information in the
Alert-
Info
header, which tells it where to go fetch the ringtone, or to start playing the stored ringtone on the phone itself.
How the Alert-Info Header is Built
The content of the
Alert-Info
header is configured using the following options, which can be applied on the Application or DN-level:
•
•
•
Note:
The sip-alert-info
option takes precedence over the
The value of these options determines the content of the
Alert-Info header that, if configured, will be included in the
INVITE
. For example, the following value points the endpoint to the ringtone file that will be used for external calls:
<http://www.provider.com/tones/internal_caller.pcm>
If alternate ringtones are also configured for external or consultation calls
( sip-alert-info-external
or sip-alert-info-consult
), that configuration takes precedence over sip-alert-info
for those types of calls.
In all cases, if the
SIP_HEADERS
extension in the original T-Library request includes the
Alert-Info
header, the value in this extension will take precedence and be used in the
INVITE
sent to the endpoint.
Using the SIP_HEADERS Extension
You can also enable alternate ringtones from within the T-Library request that starts the call operation. In this case, the request must include an
Alert-Info key-value pair in the
SIP_HEADERS
extension.
For an example, see the text in bold in the following
TRouteCall
: message RequestRouteCall
AttributeThisDN'5000'
AttributeConnID006e01886c3d7001
AttributeOtherDN'21101'
AttributeExtensions[371] 00 0B 00 00..
'SIP_HEADERS' 'Alert-Info'
'Alert-Info' '<http://www.provider.com/tones/internal_caller.pcm>'
AttributeDNIS '5000'
AttributeRouteType 1 (RouteTypeDefault)
AttributeReferenceID 9
This
TRouteCall
request would result in the following SIP
INVITE
:
SIP Server—Deployment Guide 105
Chapter 5: SIP Server Feature Support Alternate Ringtones
INVITE sip:21101@ DestinationHost:21101 SIP/2.0
From: <sip:7102@ SourceHost:7102>;tag=28B10B44
To: <sip:21101@ DestinationHost >
Call-ID: 931E620E-F3F9
CSeq: 1 INVITE
Content-Length: 145
Content-Type: application/sdp
Contact: <sip: SourceHost >
Alert-Info: <http://www.provider.com/tones/internal_caller.pcm>
Max-Forwards: 70
Session-Expires: 1800;refresher=uac
Min-SE: 90
Supported: timer
The
Alert-Inf o header can be defined using the
SIP_HEADERS
extension in any of the following T-Library requests:
•
TMakeCall
•
TInitiateTransfer
•
TInitiateConference
•
TSingleStepTransfer
•
TSingleStepConference
•
TRouteCall
•
TPredictiveCall
•
TRedirectCall
Special Codes for Built-In Ringtones
For endpoints that use ringtones built into the phone itself, you must configure
SIP Server to build the
Alert-Info
header so that it includes the code required by the endpoint to invoke the alternate ringtone. For example, the following string is used by some endpoints to trigger a distinctive external ringtone:
<http://notused.invalid>;info=alert-external
The URI portion of the string must be enclosed in angle brackets (the URI itself is empty). The second part of the string contains the code used by the particular endpoint to trigger the ringtone.
Other Uses for the Alert-Info Header
Some endpoints may offer other services that can be triggered using the
Alert-
Info
header. For example, an Auto-Answer feature, where stored messages in the endpoint can be triggered for certain types of calls. In this case, the same configuration rules apply as for enabling alternate ringtones: configure SIP
Server to build the
Alert-Info
header as required for your particular endpoint.
106 Framework 8.1
Chapter 5: SIP Server Feature Support Alternate Routing
Feature Configuration
describes how to enable alternate ringtones, listed in order of highest to lowest priority.
Table 16: Configuring Alternate Ringtones
Objective
1. Configure the
T-Library request.
2. Configure the DN.
3. Configure the
Application.
Related Procedures and Actions
In the T-Library client or URS routing strategy, configure the request to include the following:
•
SIP_HEADERS
—Add
‘alert-info’
to the list of custom SIP headers to be added to the
INVITE
.
• Define the header as follows:
‘alert-info’ ‘<URI>; parameters’
If present, this configuration takes precedence over all other settings.
You can configure alert-info related options in any of the following DNs:
•
Extension
•
ACD Position
In the
Options
tab of the DN, configure any of the following options:
•
•
•
In the SIP Server
Application
object, you can apply any of the same options as at the DN-level:
•
•
•
DN-level and
SIP_HEADERS
extension takes precedence.
Alternate Routing
SIP Server supports call delivery to a variety of alternate default-DN locations to handle complications that can arise during the regular processing of inbound calls. SIP Server also includes a mechanism to delete a call after an inordinate number of routing attempts. These scenarios include the following:
•
“Alternate Routing for Stranded Calls” on page 108
•
“Alternate Routing for Unresponsive DNs” on page 110
SIP Server—Deployment Guide 107
Chapter 5: SIP Server Feature Support Alternate Routing
•
“Alternate Routing for Unresponsive URS/ORS” on page 111
•
“Alternate Routing for Calls to an External Destination” on page 114
Alternate Routing for Stranded Calls
SIP Server offers alternate routing for stranded calls (calls left waiting in a queue after the last agent logs out) and stranded-on-arrival calls (calls arriving at a queue with no remaining logged-in agents). Two new configuration options,
and stranded-on-arrival-calls-overflow
, are used to configure how SIP Server processes calls stranded in ACD queues.
An additional option,
stranded-call-redirection-limit
number of redirections that SIP Server can make when processing a single stranded call (to avoid looping the call indefinitely).
Feature Configuration
describes how to configure stranded call routing.
Table 17: Configuring Stranded Call Routing
Objective
Configure for all queues.
Related Procedures and Actions
In the SIP Server
Application > Options > TServer
section, configure these options:
•
—Enter a list of actions that you want SIP Server to take for all stranded calls to any configured
ACD Queue
DN.
Note: For a list of valid actions, see “Stranded Calls
Overflow Valid Values” on page 109
.
•
stranded-on-arrival-calls-overflow
—Enter a list of actions that you want SIP Server to take for calls arriving on any empty
ACD Queue
DN.
•
stranded-call-redirection-limit
—Set this to a value between
0
and
15
. SIP Server stops trying to redirect stranded calls after the configured number of attempts.
108 Framework 8.1
Chapter 5: SIP Server Feature Support Alternate Routing
Table 17: Configuring Stranded Call Routing (Continued)
Objective
Configure for individual queues.
Related Procedures and Actions
Go to SIP Server
Switch > DNs
folder > individual
ACD Queue
DN >
TServer
section and configure these options:
•
—Enter a list of actions that you want SIP Server to take for stranded calls to this DN only.
•
stranded-on-arrival-calls-overflow
—Enter a list of actions that you want SIP Server to take for calls arriving on this empty ACD Queue DN only (without any logged in agents).
Note: The DN-level overflow options take precedence. The redirection limit, however, is applied only at the Applicationlevel, globally for all stranded calls.
Stranded Calls Overflow Valid Values
describes the valid values for the stranded-calls-overflow
and
stranded-on-arrival-calls-overflow
options, as well as their related SIP
Server actions.
Table 18: Stranded Call Overflow Valid Values
Valid Value
<valid_destination_number> default
or
<empty string> recall release
Related Action
SIP Server redirects stranded calls to this number.
This is the default value which provides backwards-compatible behavior with previous versions of SIP Server.
DN-level:
• If the option is not specified, or contains an empty string or the value default
, SIP Server uses the value of the
Application-level option instead.
Application-level:
• If the option is not specified, or contains an empty string,
SIP Server does not perform any stranded call routing. The call remains waiting in the queue.
SIP Server sends stranded calls back to the previous distribution device as specified in the
OtherQueue
attribute of the call. If the call was not distributed from a previous device,
SIP Server disregards this value, continuing with other values in the list (if available).
SIP Server releases calls stranded in the queue.
SIP Server—Deployment Guide 109
Chapter 5: SIP Server Feature Support Alternate Routing
Table 18: Stranded Call Overflow Valid Values (Continued)
Valid Value Related Action
none
The stranded call remains in the queue. Use this value at the
DN-level when you do not want the value of the Applicationlevel option to apply to this ACD Queue.
General Rules About the Overflow Values
The following general rules apply to both stranded-calls-overflow
and stranded-on-arrival-callsoverflow
options:
• Valid values are case-sensitive.
• If the overflow destination points to the same queue where the call is already stranded, SIP Server skips this value in the list. Similarly, if a loop is detected, SIP Server skips the value.
• The value none
cannot be included in the comma-separated list (valid as a single action only). The remaining values can be combined. If included, the values release and default should be placed last in the list.
• When configured on the application-level, this option applies to all ACD Queues on the switch except for the overflow destination queue.
• The DN-level option takes precedence over the Application-level option.
Alternate Routing for Unresponsive DNs
Introduced in
SIP Server
8.1.102.29
SIP Server supports alternate routing for new calls to Genesys SIP endpoints that fail to respond to an
INVITE
request. If the
INVITE
request to a particular endpoint fails to respond before the sip-invite-timeout
setting expires, SIP
Server sends the call to the alternate location specified in the no-response-dn option, as configured in the unresponsive DN.
Setting SIP INVITE Timeout for Individual DNs
With this enhancement, you can limit how long a SIP transaction will remain in Proceeding state if the only provisional response received was
100 Trying.
When this timeout expires, the call is either sent to the DN configured in the
option, or released if that option is not configured.
The
option set at the Application level specifies the number of seconds SIP Server waits for a response to the
INVITE
message; if no response is received in that interval, the call times out. The maximum value of this option is
34
seconds. To extend the waiting period of time for SIP Server after the
100 Trying
is received before the call times out, configure the siptrying-timeout
option for individual DNs, which offers the maximum value of
256
seconds.
Feature Configuration
describes how to enable alternate routing for unresponsive DNs.
110 Framework 8.1
Chapter 5: SIP Server Feature Support Alternate Routing
Table 19: Configuring Default Routing for Unresponsive DNs
Objective
1. Configure the SIP
Server Application.
Key Procedures and Actions
In the SIP Server
Application > Options > TServer section, configure this option:
•
—Specifies the number of seconds that SIP Server waits before an
INVITE
times out. After this timeout, if the unresponsive
DN is configured for it, SIP Server sends the call to the alternate DN.
Note: This option affects the timeout for all
INVITE
messages sent by SIP
Server. Genesys recommends that you not change this option without considering all the scenarios it may affect.
2. Configure the DN.
Go to SIP Server
Switch
>
DNs
folder > individual DN >
TServer
section and configure the following option:
•
—Enter the DN where SIP Server will send the timed-out
call.
To set the SIP
INVITE
timeout for individual DNs, configure the
Alternate Routing for Unresponsive URS/ORS
Enhanced support introduced in
SIP Server
8.1.101.75
SIP Server supports delivering calls to an alternative location in situations in which the Universal Routing Server (URS) or Orchestration Server (ORS) becomes non-operational or unresponsive. If enabled, SIP Server sends the call to a specified alternate DN if URS/ORS fails or if the call waits too long on a
Routing Point.
In multi-site deployments, calls can be routed by using route
or direct-uui
ISCC transaction types, or by using the ISCC Call Overflow mechanism. If route
or direct-uui
transaction types are used, Genesys recommends configuring inbound trunks with OOSP (Out Of Signaling Path) for efficient use of alternate routing. That way, a call is removed from SIP Server, minimizing its load.
In addition, with this enhancement:
•
When multiple alternate destinations are configured, including those located on different switches, SIP Server load balances them in a round-robin manner.
•
SIP Server prevents loops in the routing path by ignoring all destinations that were already tried, and rejects the call if none are available.
•
SIP Server supports standard log event 52053 for an alternate routing indication.
SIP Server—Deployment Guide 111
Chapter 5: SIP Server Feature Support Alternate Routing
Feature Configuration
describes how to enable alternate routing for unresponsive URS/ORS.
Note:
Alternate routing with attached data is enabled when alternate destinations are configured in a Default DNs list of the Routing Point
DN configuration. However, if you configure the alternate destination using the default-dn
option (on either the Application or the DN level), the alternate destination will be taken from that default-dn option. The alternate destination configured in alternate-routeprofile
will be ignored and not used.
Table 20: Configuring Default DN for Unresponsive URS/ORS
Objective
Configure for all Routing
Points.
Configure for individual
Routing Point.
Key Procedures and Actions
In the SIP Server Application > Options > TServer section, configure these options:
•
—Enter the alternate DN to which SIP Server sends calls in
case of URS failure/timeout.
Note: Applies to all
Routing Point
DNs on the switch, unless configured otherwise at the DN-level.
•
—Enter the max time (in seconds) that a call waits on a
Routing Point before SIP Server sends the call to the default-dn.
Multi-site deployments:
• Use the Application-level option
valid Routing Point DN that contains a Default DNs list. SIP Server uses that list when it encounters a Routing Point with an empty Default
DNs list. (See Figure 7 on page 113 .)
• Set the parameter
alternate-route-cof=<true, false>
to true
to specify that alternate routing uses the ISCC Call Overflow feature.
In the SIP Server switch > DNs folder > individual
Routing Point
DN >
TServer
section, configure the following option:
•
—Enter the alternate DN to be used for URS
failures/timeout on this Routing Point only.
112 Framework 8.1
Chapter 5: SIP Server Feature Support Alternate Routing
Figure 7: Configuration Example of Default DNs List
Feature Limitations
•
Alternate routing does not support default access codes.
•
SIP Server does not trigger alternate routing when the router-timeout timer is in progress and a URS disconnects from SIP Server, or when SIP
Server submits a
TUnregisterAddress
request from the last T-Library client registered on this Routing Point. SIP Server triggers alternate routing only when the router-timeout
timer expires.
SIP Server—Deployment Guide 113
Chapter 5: SIP Server Feature Support Application Failure Detection
Alternate Routing for Calls to an External Destination
SIP Server supports routing inbound 1pcc calls to a specified default location in cases where the incoming
INVITE
request is addressed to an external destination. With this feature enabled, as SIP Server receives an
INVITE
from an external source, it checks all configured DNs and registered endpoints. If the Request URI includes a number that does not match any of the configured
DNs or registered endpoints, SIP Server sends the call to a specified default
(DN configured in the default-route-point
option), even if the destination might match a configured gateway. This feature is used to prevent SIP Server from looping the call back to the same gateway on which the call came in.
Note:
This feature applies to inbound 1pcc calls only (initiated by
INVITE request). This feature does not apply to ISCC calls or to 3pcc calls initiated by T-Library requests.
Feature Configuration
describes how to enable this feature.
Table 21: Configuring Default DN for External Destinations
Objective
Configure the SIP
Server Application.
Key Procedures and Actions
In the SIP Server
Application > Options > TServer section, configure the following option:
•
Server will route calls addressed to an external destination.
For example, a
Routing Point
DN that applies a treatment, then rejects the call.
Application Failure Detection
Application Failure Detection is a Management Layer feature, where a particular application is configured for monitoring by the Local Control Agent
(LCA), so that corrective action can be taken if and when the application becomes unresponsive (hangs up).
For SIP Server, you can configure failure detection for the application itself as well as for any of its individual threaded modules. For more information about
multi-threading, see “Multi-Threaded Architecture” on page 45 .
114 Framework 8.1
Chapter 5: SIP Server Feature Support Application Failure Detection
How Failure Detection Works
1. With failure detection enabled, the Management Layer monitors heartbeat messages (UDP packets) sent by the SIP Server application to the LCA.
2. If the LCA discovers that the application becomes unresponsive, it sends a notification to the Solution Control Server (SCS) stating that a hang-up has occurred, and what caused it. SCS then issues a log message:
5160|STANDARD|GCTI_SCS_APP_HANG_UP_DETECTED| Application hang-up detected, reason %s
; Produced by SCS on behalf of application when LCA reports that application
; hang-up detected
; %s - reason of hang-up detection (application or thread hangup)
is enabled on SIP Server, the LCA will restart SIP
Server.
OR
If hangup-restart
is set to false
, monitoring continues. If the situation resolves itself, at the next successful heartbeat message SCS generates the following log message:
5161|STANDARD|GCTI_SCS_APP_RESTORED_AFTER_HANG_UP| Application restored after hang-up
; Produced by SCS on behalf of application when LCA reports that application
; restores correct behavior after hang-up
Feature Configuration
describes how to enable this feature.
Table 22: Configuring SIP Server for Hang Up Detection
Objective
Configure the SIP Server
Application.
Key Procedures and Actions
In the SIP Server
Application
object >
Annex
tab > sml
section, configure the following options:
•
—Set this option to the length of time, in seconds, that Management Layer will wait before taking corrective action.
•
—Set this option to true
to restart SIP Server in case it becomes unresponsive, false
to send a notification only.
Feature Limitation
In 8.0.3, SIP Server supports application hang-up detection for the main thread class only.
SIP Server—Deployment Guide 115
Chapter 5: SIP Server Feature Support Associating an ACD Queue with a Routing Point
Associating an ACD Queue with a Routing
Point
SIP Server is able to associate an ACD Queue with a Routing Point by specifying the
Routing Point
DN in the
Association
field in the
Properties dialog box of the
ACD Queue
DN object in the Configuration Layer.
The call flow for this functionality is as follows:
•
Agents log into the ACD Queue.
•
An inbound call arrives at the ACD Queue and at the associated Routing
Point. The call is not auto-distributed to an agent in that ACD Queue.
•
A Universal Routing Server (URS) strategy on the Routing Point selects an available agent in the ACD Queue.
•
The call is routed to an agent's DN, which responds with a SIP Ringing message. As a result, an
EventDiverted
message is distributed against the
ACD Queue and
EventRouteUsed
and
EventDiverted
messages are distributed against the Routing Point.
•
The agent answers the call.
Notes:
The inbound call will be treated as a regular call to the ACD Queue if no URS application has registered for the Routing Point associated with the ACD Queue.
The inbound call will be treated as a regular call to the ACD Queue if a
URS application has registered for the Routing Point associated with the ACD Queue, but the routing timeout expires.
Asterisk Voice Mail Integration
SIP Server exchanges SIP messaging with an Asterisk-based Voice Mail system using a SIP trunk. Voice mail boxes with Asterisk have the same names as their corresponding DNs, but you do not need to configure voice mail boxes as DNs in the Configuration Layer. You can access these voice mail boxes by dialing a user-defined prefix and a DN number. It is also possible to dial a prefix and a special extension so that the call will be delivered to the Voice
Mail Main Menu.
SIP Server configuration options are used to organize the delivery of calls to the Voice Mail system when certain conditions are met. For example, when an incoming call is not answered within a specified timeout. Universal Routing
Server strategies are used to organize more flexible control over delivery of the call to a voice mail box.
116 Framework 8.1
Chapter 5: SIP Server Feature Support Asterisk Voice Mail Integration
Note:
Voice mail for DNs is handled by an Asterisk softswitch when using
Asterisk as a softswitch with SIP Server. You do not need to configure voice mail and Message Waiting Indicator (MWI) in SIP Server for any DNs. However, voice mail is configured for agents and Agent
Groups in this scenario.
Genesys Voice Mail Configuration Adapter for Asterisk
The Genesys Voice Mail Configuration Adapter for Asterisk (GVMA) is a utility that allows you to synchronize the Asterisk Voice Mail configuration file ( voicemail.conf
) with data from the Configuration Server. By default,
GVMA creates a voice mail box in Asterisk for each extension DN configured in the Configuration Layer. GVMA can also be configured to use DNs of other types for the same purpose.
GVMA obtains the necessary Asterisk Voice Mail configuration properties from the following objects in the Configuration Layer:
•
DNs are used to configure voice mail boxes for extensions.
•
Agent Logins are used to configure voice mail boxes for agents.
•
Agent Groups are used to configure of voice mail boxes for agent groups.
When it has retrieved this information, GVMA performs the following tasks:
1. Connects to Configuration Server.
2. Makes a backup copy of the current Asterisk configuration.
3. Loads DNs from Configuration Server.
4. Updates the Asterisk Voice Mail configuration file from the retrieved data.
5. Instructs Asterisk to reload configuration files.
GVMA is run manually or scheduled to run periodically using your operating system’s scheduling tools.
Message Waiting Indicator Functionality
SIP Server supports Message Waiting Indicator (MWI) notifications by registering with Asterisk and processing MWI notifications sent by Asterisk within
NOTIFY
messages. SIP Server sends to a DN an
EventUserEvent
message with detailed information about the message waiting status attached in the
UserData
fields.
MWI Processing for Extension Voice Mail Boxes
SIP Server registers (using the
REGISTER
request) all extensions as voice mail
boxes with Asterisk when the option mwi-extension-enable
has a value of true
. Asterisk sends
NOTIFY
SIP messages to SIP Server that contain MWI
SIP Server—Deployment Guide 117
Chapter 5: SIP Server Feature Support Asterisk Voice Mail Integration information. SIP Server stores MWI information received from Asterisk, and distributes an
EventUserEvent
message with the latest MWI information to each registered extension voice mail box.
MWI Processing for Agent Voice Mail Boxes
SIP Server registers each agent voice mail box with Asterisk immediately after the
EventAgentLogin
message is received, and when the
option has a value of true
. SIP Server stores MWI information received from
Asterisk for each agent voice mail box and distributes an
EventUserEvent message with the latest MWI information to the DN that the agent has logged into. SIP Server will terminate this registration immediately after an
EventAgentLogout
message is received.
MWI Processing for Agent Group Voice Mail Boxes
SIP Server registers the agent group voice mail box with Asterisk immediately after the first member’s
EventAgentLogin
message is received and when the
true
. SIP Server stores MWI information received from Asterisk for each agent group voice mail box and distributes an
EventUserEvent
message with the latest MWI information to all
DNs associated with agents that are logged in and configured to use this voice mail box. SIP Server will terminate this registration immediately after an
EventAgentLogout
message is received from the last agent associated with this agent group’s voice mail box.
Note:
SIP Server associates an agent with an agent group voice mail box by using the option gvm_group_mailbox
located in the
TServer
section of the
Agent Login
configuration object. Any agent configuration object that is configured with the same voice mail box specified in this option is associated with this agent group’s voice mail box.
Feature Configuration
MWI functionality is configured on the Asterisk side and on the SIP Server side. The following SIP Server configuration options support MWI functionality:
•
•
•
•
•
•
118 Framework 8.1
Chapter 5: SIP Server Feature Support Automatic Inactive Agent Logout
•
For Asterisk configuration and integration with SIP Server, see the
SIP Server
8.1 Integration Reference Manual .
Automatic Inactive Agent Logout
SIP Server can automatically log an agent out after a specified period of inactivity, so as to ensure the accurate reporting of agent activity. Automatic agent logout can be configured for agents who are in a
NotReady
status, or more strictly for agents who are in either a
NotReady
or a
Ready
status in a workrelated mode (for example,
AfterCallWork
).
Agent activity is determined by monitoring the following:
•
Changes in agent state.
•
Calls that are made or received at the DN from which the agent is logged on (SIP Server will not log out an agent who is currently on a call).
Feature Configuration
describes how to enable the automatic agent-logout feature. For highest priority, set the following options in the
Agent Login
DN.
Table 23: Enabling Auto Agent Logout
Objective Related Procedures and Actions
1. Enable automatic agent logout.
In the
TServer
section of the applicable configuration
object, set the auto-logout-timeout
o ption to a value of
1
or greater.
2. (Optional) Enable a stricter logout policy.
In the
TServer
section of the applicable configuration object, set the
true.
Call Completion Features
SIP Server supports Call Completion on Busy Subscriber (CCBS) and Call
Completion on No Reply (CCNR) when offered by the Siemens OpenScape
Voice switch. This feature provides a callback mechanism, where a caller is able to request a call back from the switch when a line they have tried to reach
(but is busy or does not answer) later becomes available.
SIP Server—Deployment Guide 119
Chapter 5: SIP Server Feature Support Call Completion Features
How It Works
For this feature to work, both the caller DN and the destination DN must be behind the same switch.
Call Completion on Busy Subscriber/No Answer
A sample call flow for a CCBS scenario is as follows:
1. DN1 and DN2 are both behind the switch that provides the CCBS/CCNR feature.
2. DN1 places a call to DN2, but DN2 is either busy or there is no answer.
DN2 includes the
Allow-Events
header in its SIP response, requesting the feature:
486 Busy Here
includes
Allow-Events: CCBS
180 Ringing includes
Allow-Events: CCNR
3. SIP Server passes the
Allow-Events to the switch, which then presents to
DN1 the option to start the callback feature, as per switch functionality.
DN1 accepts the callback.
4. To establish the subscription between the DNs, DN1 sends a
SUBSCRIBE message to DN2 through SIP Server:
SUBSCRIBE
Event: CCBS;queue=tru;service-retention=service-retained
Contact: URI
5. DN2 responds with a
NOTIFY
message confirming the subscription:
NOTIFY
Event: CCBS;queue=tru;service-retention=service-retained
Subscription-state: active
Contact: URI
6. With the subscription established, the original call ends.
7. When DN2 becomes available, it sends a
NOTIFY
(user-free) message as per the subscription. On receiving this
NOTIFY
, the switch sends an
INVITE
to
DN1. If DN1 answers, the switch then sends an
INVITE
to DN2 (now free) and a call between the two parties is established.
Feature Configuration
SIP Server does not provide this functionality itself, but instead supports this functionality when offered by Siemens OpenScape Voice version 6.0.
120 Framework 8.1
Chapter 5: SIP Server Feature Support Call Divert Destination
describes how to enable the call completion features.
Table 24: Configuring Call Completion
Objective
Configure a SIP Server
Application
.
Related Procedures and Actions
In the
TServer
section of the SIP Server
Application
object, configure the following options:
1.
—Set this to false
.
2.
—Set this to the same value as the
contact option configured on the softswitch DN (
Voice over IP Service
DN with service-type
set to softswitch
).
With this configuration, SIP Server processes the
Allow-Events:
CCBS
and
Allow-Events: CCNR
headers if they are included in the
INVITE
request.
Feature Limitation
This functionality is available for 1pcc calls only (not applicable for 3pcc calls).
Call Divert Destination
SIP Server supports routing the caller to a specific destination when, after an initial leg of the call is completed, only the caller remains on the line. For example, this feature could be used to route the caller to a post-call survey.
Feature Configuration
To enable this feature, configure the DN-level option after-call-divertdestination
on the Routing Point DN. You can also enable this feature by
passing the after-call-divert-destination
parameter in the
Extensions attribute of a
TRouteCall
request. Parameters passed in the
Extensions
attribute override the value of the configured option.
Feature Limitations
•
This feature is supported only in single-site deployments.
•
This feature is not supported for calls initiated by
TMakePredictiveCall requests.
SIP Server—Deployment Guide 121
Chapter 5: SIP Server Feature Support Caller Information Delivery Content for AT&T Trunks
Caller Information Delivery Content for
AT&T Trunks
Introduced in
SIP Server
8.1.101.66
Support for GVP added in
8.1.102.00
SIP Server can pass the multipart body content received in
INVITE
messages (as described in RFC 5621) to make it available to URS/ORS and/or GVP. The only content type currently supported is Caller Information Delivery (CID), as defined in the AT&T specification for AT&T IP Toll Free Service SIP trunks.
SIP Server communicates with URS/ORS using T-Library to pass the CID content that it receives in a multipart
INVITE
body, as an attribute of an
EventRouteRequest
message. See “Passing CID Content to T-Library Clients
.
SIP Server communicates with GVP using SIP to pass the CID content that it receives in a multipart
INVITE
body in the relayed
INVITE
Content to SIP Destinations (GVP)” on page 124
.
Notes:
• CID content that is received in a multipart
INVITE
body is still delivered following an MCP failure or a SIP Server failure in HA hot-standby mode.
• CID content is handled in Presence Information Data Format
(PIDF), as RFC 3863 describes in detail.
Enabling CID Content Retrieval
Configure the DN-level option
retrieve CID content from the
INVITE
that it receives from a Trunk DN.
Passing CID Content to T-Library Clients (URS/ORS)
SIP Server previously mapped the SDP portion of a SIP message body to a
T-Library event attribute; see the section “Mapping SIP Headers and SDP
Messages” on page 276 . Now it can also perform CID mapping to T-Library
clients (URS/ORS). SIP Server sends
EventRouteRequest
with the CID content passed in
AttributeExtensions
.
To enable CID mapping to T-Library clients, add this configuration option to the
INVITE
section:
•
extensions-1 = CID
By default, CID content is passed to T-Library clients unchanged (UTF-8 encoding). If conversion to a local charset is enabled for SIP-to-TLib mapping
122 Framework 8.1
Chapter 5: SIP Server Feature Support Caller Information Delivery Content for AT&T Trunks
(set with the encoding option), then this conversion is also applied to CID content.
Note:
CID can be mapped to
AttributeExtensions
only. CID mapping to
AttributeUserData
is not supported.
Example
message EventRouteRequest
AttributeThisDN '5001'
AttributeThisDNRole 2
AttributeThisQueue '5001'
AttributeOtherDN '31001'
AttributeOtherDNRole 1
AttributeConnID 2266025dfcd2c001
AttributeExtensions
'CID'
'Content-Type: application/pidf+xml
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:tf="http://www.att.com/iptf"
entity="pres:[email protected]">
<tf:dataresponse status="available"/>
<dm:device id="3754348893">
<gp:geopriv>
<gp:location-info>
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>40.3958 -74.1322</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">113</gs:radius>
</gs:Circle>
<cl:civicAddress>
<cl:A1>Daly City</cl:A1>
<cl:A3>CA</cl:A3>
<cl:PC>94014</cl:PC>
<tf:streetaddress>2001 Junipero
Serra</tf:streetaddress>
<tf:name>Genesys</tf:name>
<tf:givenName></tf:givenName>
<tf:mailableVerified>true</tf:mailableVerified>
<tf:listType>Bus</tf:listType>
</cl:civicAddress>
</gp:location-info>
</gp:geopriv>
</dm:device>
</presence>'
SIP Server—Deployment Guide 123
Chapter 5: SIP Server Feature Support Call Park/Retrieve
Passing CID Content to SIP Destinations (GVP)
Configure the DN-level option
to specify that the CID content
(taken from one of the call parties) is included in the initial
INVITE
that is sent to the DN.
Configure the Application-level option cid-enable-on-vtp
to simplify provisioning of the IVR configured through the Voice Treatment Port (VTP)
DNs. Set to true
to specify that CID content is passed to the VTP DN in the initial
INVITE
.
Call Park/Retrieve
This feature lets SIP Server support Call Park and Call Retrieve features provided by various Private Branch Exchange (PBX) vendors. This feature lets users (agents) park a call for a period of time—for example, to change phones—and then retrieve the call later.
How It Works
1. A call is established between an agent and a caller.When the agent wants to park the call, he or she initiates a transfer using a 1pcc request to a specially-configured “Call Park” star code—for example,
*10
.
2. SIP Server parks the call on the internal gcti::pbxpark
device (the device does not need to be created in the Configuration Layer because it is an internal SIP Server device). While the call is parked, the agent can hang up their phone if the agent needs to; the caller remains parked and not disconnected from the contact center.
3. When the agent wants to retrieve the call, he or she dials a speciallyconfigured “Retrieve Call” star code, plus the number of the DN from which the call was parked at the internal gcti::pbxpark
device. For example,
*11 1001
, where
*11
is the star code, and
1001
is the DN from which the call was parked.
4. Based on the provided DN, SIP Server retrieves the parked call from gcti::pbxpark
and re-connects the caller with the agent.
5. If, while parking the call, the agent enters the wrong “Call Park” star code, the caller will be placed on hold. If, while unparking the call, the agent enters the wrong “Call Park” star code, SIP Server identifies that there is no associated parked call, checks for other star code features, and applies standard call processing for unknown dialed numbers if no star code features are found.
6. If a call remains parked for longer than the configured max-parking-time option, SIP Server returns the call to the original DN.
124 Framework 8.1
Chapter 5: SIP Server Feature Support Call Pickup
Feature Configuration
describes how to configure Call Park/Retrieve.
Table 25: Configuring Call Park/Retrieve
Objective
Configure the SIP Server
Application
.
Related Procedures and Actions
In the SIP Server
Application > Options > TServer
section, configure the following options:
•
—Enter the number part of the star code to be
used to park the call.
•
—Enter the number part of the star code to be used to retrieve the parked call.
•
—Set the timeout after which a parked call will be reconnected with the initial DN.
•
—Enter the name and path to a valid audio file for the audio that will be played to remote parties connected to the
SIP Server internal gcti::pbxpark
device.
Feature Limitations
•
Call Park and Call Retrieve functionality is only supported in single-site deployments.
•
This functionality only works with 1pcc call flows. SIP Server does not support 3pcc requests (
TSingleStepTransfer, TMakeCall
) to star codes.
Call Pickup
SIP Server supports the Call Pickup feature. When enabled, calls ringing at an agent device may be picked up by another agent from his or her device by dialing a following combination:
*<pickup code><DN where a call is ringing>
For example, if the pickup code is
12 and a call is ringing at DN
1001,
the other agent can dial *
12 1001
from his or her current device to pick up the ringing call at DN
1001
.
SIP Server—Deployment Guide 125
Chapter 5: SIP Server Feature Support Call Recording—NETANN-Based
Feature Configuration
describes how to configure Call Pickup.
Table 26: Configuring Call Pickup
Objective Key Procedures and Actions
1. Configure the SIP Server
Application.
In the SIP Server
Application > Options > TServer
section, configure the following option:
•
—Set this option to the numeric string that will be used as the pickup code. By default, it is set to
12
.
2. Configure a DN.
To enable call pickup on a particular DN, go to
Switch
>
DN
object,
Options/Annex
>
TServer
section and configure the following option:
•
true
.
Feature Limitation
This functionality only works with 1pcc call flows. SIP Server does not support 3pcc requests (
TSingleStepTransfer, TMakeCall
) to star codes.
Call Recording—NETANN-Based
SIP Server supports call recording using two different methods:
•
MSML-based call recording—SIP Server invokes Genesys Media Server to record calls using Media Server Markup Language (MSML), as part of an overall recording solution with one of the following:
Genesys Interaction Recording
Genesys Quality Management
A third-party voice recorder (requires an appropriate Genesys
Connector license for recording)
For details about this kind of recording, see “Call Recording—MSML-
•
NETANN-based call recording—SIP Server invokes Genesys Media
Server (MCP) or Genesys Stream Manager to record calls to a local file using the NETANN protocol.
SIP Server supports both regular call recording and emergency call recording.
Regular Call Recording
Call recording is performed by passing a Real-Time Transport Protocol (RTP) stream through a media server (Stream Manager or Genesys Media Server
(MCP)). This Media Server acts as a proxy for the media stream, recording all media packets into a file. Depending on the configuration, the media server
126 Framework 8.1
Chapter 5: SIP Server Feature Support Call Recording—NETANN-Based may perform media mixing, or it may save the RTP packets as is, thus improving call recording performance. (See the
Genesys Media Server
Deployment Guide
or
Framework 7.6 Stream Manager Deployment Guide
for details.) Call recording is always enabled on a single call leg, such as with a gateway or a SIP phone.
Call recording starts after a call becomes established. It does not result in any changes to the call itself, to event processing, or to any other generated
TEvent.
When call recording starts, SIP Server creates two new SIP dialogs with the media server, SIP Server sends re-
INVITE
requests to all call participants with the SDP from the media server. As a result, the RTP stream between call participants is passed via the media server.
Call recording has the highest priority compared to other operations that can be performed on the call when it is established. That is, when the
EventEstablished
message is generated on the destination DN, the operations on the call are performed in the following order:
1. Call recording, if enabled.
2. Personal greeting, if enabled.
3. Supervisor monitoring, if enabled
Recording is only available for calls with audio media. If a call contains video or IM media, recording will not start.
Only one recording is allowed on a call. If the configuration enables recording on more than one device in the call, recording will only start on the device for which the first
EventEstablished
is distributed.
Consultation Calls
Regular call recording is also available for consultation calls. If re-enabled for it, SIP Server starts call recording when any DN that is involved in the consultation call is set for recording. Once recording is initiated, it continues for as long as at least one party that is set for recording remains in the call.
Recording ends when no more recording-enabled parties are left. For example, if recording for both main and consultation calls is initiated by a single party, and that party then initiates a
TCompleteTransfer
, recording on both calls is terminated once the transfer is completed.
Reassigning Recording
In cases where recording is initiated by a party that then leaves the call, while another party remaining on the call is also configured for call recording, SIP
Server will continue recording the call for the same file. The actual RTP stream is reassigned from the original initiating party to any other party on the call that is configured for call recording. If cases where no remaining party is
SIP Server—Deployment Guide 127
Chapter 5: SIP Server Feature Support Call Recording—NETANN-Based configured for call recording when the initiating party leaves the call, the recording is terminated.
Building the Request URI for the Recording
SIP Server builds the Request URI for the call recording in a number of ways, depending on configuration and type of call recording:
•
For regular call recording, SIP Server builds the Request URI automatically at run-time, so long as the recording-filename
option on the
SIP Server application is correctly configured. SIP Server does not use the value of the request-uri
option on the recording-service
DN, except as a backup in case the recording-filename
is wrong or not configured.
•
For emergency call recording, SIP Server builds the Request URI using both the value of the request-uri
option on the Application (if configured), as well as the value of the emergency-recording-filename
option. If request-uri
is not configured, then the resulting URI is formed as follows:
<RECORDER-DN>@<SIP-ADDRESS>:<SIP-PORT>
For example,
[email protected]:5060
Feature Configuration
describes how to enable NETANN-based call recording.
Table 27: Configuring NETANN-Based Call Recording
Objective
1. Configure a DN.
2. Configure a SIP Server
Application.
3. Configure an
Extension attribute.
Related Procedures and Actions
To enable call recording on a particular DN, in the
TServer
section of the
DN
object, set the configuration option
true.
To record all inbound calls coming for a particular media gateway, set the record
option to true
on the
Trunk
DN that represents this gateway.
In the
TServer
section on the
Options
tab of the SIP Server
Application object, configure the following options:
1.
—Enter the name of the recorded file. For example: call-$ANI$-$DNIS$-$DATE$-$TIME$-$CONNID$-$UUID$-
$AGENTDN$-$AGENTID$
2.
—To enable recording for consultation calls,
set this option to true
.
Specify an
Extension
key in the
TRouteCall
request. See the key values in Table 103, “Use of the Extensions
The routing strategy will determine whether call recording is needed.
128 Framework 8.1
Chapter 5: SIP Server Feature Support Call Recording—NETANN-Based
Table 27: Configuring NETANN-Based Call Recording (Continued)
Objective
4. Configure the Media
Server application.
5. Configure a recording service.
Related Procedures and Actions
Configure either Stream Manager or Genesys Media Sever:
• Stream Manager
Set configuration options in the Stream Manager
Application
object for precise control of how recording is performed. See the Framework
7.6 Stream Manager Deployment Guide for more information.
It is recommended to use pcap
recording mode on Stream Manager for best performance.
• Genesys Media Server (MCP)
Configure and tune the application according to the Genesys Media
Server 8.1 Deployment Guide.
Configure a DN of type
Voice over IP Service with the following configuration options:
• contact:
Set to the device’s IP address and port used for recording.
Note: The device can be either Stream Manager or MCP.
• request-uri:
Set to the SIP URI.
• service-type:
Set to recorder
.
See “Configuring a recording service” on page 88
for details.
Emergency (Manual) Call Recording
SIP Server performs emergency call recording when processing a single-step conference call request that specifies
AttributeOtherDN
as a
Trunk
DN specifying a gcti::record
number. When this attribute is set, SIP Server recognizes this special request and initiates call recording as follows:
•
Selects one of the available call recording units that are configured in the
Configuration Layer. See “Configuring a Recording Service” on page 88
for more information.
•
Performs a single-step conference call and adds the selected call recording unit to the call.
•
Creates the file name as configured in the emergency-recording-filename option that is described on
To stop emergency call recording, the agent must issue the
TDeleteFromConference
request using the gcti::record
number.
Feature Limitations
Emergency call recording cannot be activated on a consultation call if it has already been activated from the same DN on the primary call. Emergency call recording can only be activated on both primary and consultation calls if initiated from different DNs.
SIP Server—Deployment Guide 129
Chapter 5: SIP Server Feature Support Call Recording—MSML-Based
Call Recording—MSML-Based
SIP Server supports call recording using two different methods:
•
MSML-based call recording—SIP Server invokes Genesys Media Server to record calls using Media Server Markup Language (MSML), as part of an overall recording solution with one of the following:
Genesys Interaction Recording
Genesys Quality Management
A third-party voice recorder (requires an appropriate Genesys
Connector license for recording)
•
NETANN-based call recording—SIP Server invokes Genesys Media
Server or Genesys Stream Manager to record calls to a local file, using the
NETANN protocol. For details, see “Call Recording—NETANN-Based” on page 126 .
About Genesys Media Server
The Genesys Media Server is a module that provides MSML-based media services offered by the Genesys Voice Platform. When integrated with SIP
Server, it supports MSML-based call recording, where the Genesys Media
Server acts as a proxy, replicating the media stream in a new recording session with a third-party voice recorder that does the actual recording. In case of file-based call recording, the actual recording is processed by MCP.
Note:
For more information about integrating SIP Server with Genesys
Media Server, see “Configuring Genesys Media Server” on page 93
.
How Call Recording Works
Depending on how call recording is configured, the basic call flow for it is as follows:
1. Call recording is initiated in one of the following ways:
Static configuration—Recording is enabled through static DN-level configuration on either the customer side (
Trunk
DN) or on the agent side (
Extension
DN or Agent Login).
Routing strategy—The routing strategy initiates recording through the
TRouteCall
request that it sends to SIP Server.
T-Library client or 3rd-party recorder—A T-Library client initiates recording through a
TPrivateService
request that it sends to SIP
Server.
2. Based on this trigger, SIP Server builds a request URI that includes key recording-related parameters. It then sends this request URI in an
INVITE
to
Resource Manager.
130 Framework 8.1
Chapter 5: SIP Server Feature Support Call Recording—MSML-Based
3. Resource Manager determines the right MCP to provide the service, and forwards the
INVITE
to the selected MCP to set up the service.
4. SIP Server sends additional MSML instructions in SIP
INFO
messages, telling the media server to start the recording.
5. For additional control over the established recording session, T-Library
TPrivateService
requests can be used to initiate new actions—for example, to pause or resume recording. SIP Server forwards the resulting
MSML instructions in new
INFO
messages.
Supported Media File Format
MSML-based call recording supports the wav
and
MP3
file formats
(NETANN-based recording supports both wav
and pcap
).
Building the Request URI for the Recording
SIP Server builds the Request URI for call recording in a number of ways, depending on configuration and type of call recording: sip:msml=<conf-id>@<resource-managaer>;<dn>=<DN>;record where, msml
Fixed part of the URI. Identifies the protocol as MSML.
conf-id
DN record
Unique identifier for the MSML/recording session. Ensures that all users are connected to the correct media server.
The DN of the endpoint that SIP Server will record.
Identifies “record” as the type of MSML session. Genesys Media
Server can then properly handle recording separately from other
MSML services.
Dynamic Call Recording
Call recording can be started on an as-needed or “emergency” basis during an ongoing call. To initiate dynamic recording, recording-related parameters are included in the
Extensions
attribute in either of the following T-Library messages:
•
TRouteCall
•
TPrivateService
TRouteCall
The URS routing strategy must be configured to include recording-related parameters in the
TRouteCall
request that it sends to SIP Server.
SIP Server—Deployment Guide 131
Chapter 5: SIP Server Feature Support Call Recording—MSML-Based
The
Extensions
attribute must include the key
with one of the following values:
•
source
—The recording will be initiated on the DN that sent the call to the
Routing Point (customer) and will continue as long as the customer stays in the call
.
•
destination
—The recording will be initiated on the routing destination
DN (agent) and will continue as long as the agent stays in the call.
TPrivateService
The T-Library client or 3rd-party recorder must include recording-related parameters in the
TPrivateService
request that it sends to SIP Server.
To initiate dynamic recording with
TPrivateService
, the request uses the following parameters:
Table 28: Dynamic Call Recording Extensions in TPrivateService
Attribute
PrivateMsgID
ThisDN
ConnectionID
Extensions
Reasons
Value
Specifies the type of recording operation to be performed:
•
GSIP_RECORD_START (3013)
—Starts the recording
Specifies the DN on behalf of which recording operation is requested.
This DN must be registered by the T-Library client.
References the ID for the call that is currently being recorded.
Specifies key-value pairs used to control the recording session:
• record
—Set to source
or destination
.
• id
—Adds a recording identifier to the recording session. This identifier must be globally unique; it is passed back in the recording session. If this parameter is not included in the request, SIP Server will
construct a unique identifier based on the recording-filename
option.
• dest
—Overrides the default location of the 3rd party recording server.
• params
—Adds additional parameters that are passed as general keyvalue pairs in the request. There parameters will appear in the recording session.
For example,
AttributeExtensions...
'record' 'source'
'id'
'dest'
'32980asdf320990ad'
'sip:172.24.129.75:5070'
'name1'
'name2'
'value1'
'value2'
Specifies any reasons. Processed the same as for all other T-Library requests.
132 Framework 8.1
Chapter 5: SIP Server Feature Support Call Recording—MSML-Based
Mid-Call Control of the Recording Session
Using
TPrivateService
requests, T-Library clients can control in real-time an ongoing recording session. The client can pause, resume, or stop the recording.
SIP Server translates recording-related parameters from the request to
INFO messages that it sends to Genesys Media Server.
Supported mid-call actions are as follows:
•
Stop the recording.
•
Pause the recording.
•
Resume a paused recording.
To control mid-call recording, the
TPrivateService
request uses parameters described in
.
Table 29: Mid-Call Recording Extensions in TPrivateService
Attribute
PrivateMsgID
ThisDN
ConnectionID
Reasons
Value
Specifies the type of recording operation to be performed:
•
GSIP_RECORD_STOP (3014)
—Stops the recording
•
GSIP_RECORD_PAUSE (3015)
—Pauses the recording.
•
GSIP_RECORD_RESUME (3016)
—Resumes the recording
Specifies the DN on behalf of which recording operation is requested. This
DN must be registered by the T-Library client.
References the ID for the call that is currently being recorded.
Specifies any reasons. Processed the same as for all other T-Library requests.
Recording During Transfers and Conferences
SIP Server supports continuous recording for conference calls if the party
(where the record was initiated) is dropped from the conference, and any party remaining on the call requests the recording (by DN configuration, routing strategy, or T-Library client). Recording ends when no more recording-enabled parties remain. Recording can be stopped by a respective T-Library request.
Feature Limitation
Continuous recording applies only to two-step transfers.
Recording Calls Without Music-on-Hold Treatment
SIP Server provides the ability to record a call without recording a music-onhold treatment when a call is placed on hold. SIP Server sends corresponding
SIP Server—Deployment Guide 133
Chapter 5: SIP Server Feature Support Call Recording—MSML-Based
MSML information in
INFO
messages to Genesys Media Server to pause the recording ( gvp:recorder state="pause"
) when the call is placed on hold and to resume the recording ( gvp:recorder state="start"
) when the call is retrieved.
This functionality also applies to call transfers: the recording is paused when a transfer is initiated, and resumed when the transfer is completed.
When several agents are involved in a call and the call is placed on hold, SIP
Server pauses the recording at the first invocation of the hold operation and resumes the recording at the first invocation of the retrieve call operation.
If SIP Server receives an error message from Genesys Media Server in response to pause or resume the recording, it will not resubmit the request.
Recording will be left in the previous state.
In multi-site deployments (see Figure 8
), where the recording and music-onhold treatment might happen on different SIP Servers, the SIP Servers will use an
EventNetworkPrivateInfo
message containing the
AttributePrivateMsgID
to pass the recording control from one SIP Server to another SIP Server. The value of the
AttributePrivateMsgID
indicates the recording state:
•
6004
—Active recording is paused
•
6005
—Active recording is resumed
•
6006
—Active recording is stopped
TLIB
Caller
SIP
Agent1@SIPS1
SIP
Tlib
SITE-1
SIP Server 1
SIP
ISC
C
SIP
SIP
+M
SM
L
SI
P
SI
P+
M
SM
L
Resource Manager
P
SI
Third Party Recorder
SIP
Tlib
SITE-2
SIP Server 2
MCP
TLIB
Agent2@SIPS2
Figure 8: SIP Server Multi-Site Deployment with Dynamic Recording Capabilities
134 Framework 8.1
Chapter 5: SIP Server Feature Support Call Recording—MSML-Based
Feature Configuration
The
configuration option enables this feature. See “Configuring
MSML-Based Call Recording” on page 138 .
Feature Limitations
•
This feature is supported only for MSML-based call recording.
•
This feature is supported in multi-site deployments (ISCC calls) only when
list
in the extrouter
section of the SIP Server application.
•
Recording can be paused when parties on the call are still speaking. It can happen in the following scenario:
a. Caller (at SIP Server 1), Agent1 (at SIP Server 1), and Agent2 (at SIP
Server 2) are talking.
b. Recording sessions are activated on the caller's leg and on the Agent2 leg.
c. Agent1 or Agent2 places the call on hold.
d. Recording session is paused on both SIP Servers.
•
Recording status can be reported inaccurately if the global command fails on one of the recording SIP Servers. For example, the
PAUSE
command is submitted. It is executed successfully on SIP Server 1 and fails on SIP
Server 2. An agent connected to SIP Server 2 may see the recording status as “
PAUSED
” even though recording is still in progress on SIP Server 1.
Video Call Recording
For video calls, recording applies to the audio portion of the call only. The video part of the dialog remains unaffected by the audio recording process.
Call Recording Alarms
SIP Server supports a standard log event,
01-52051
, for unsuccessful call recording scenarios. A recording scenario is considered unsuccessful if one of the recording operations fails and cannot be recovered by SIP Server. For example, SIP Server tries to start recording on a DN and fails. SIP Server then makes a second attempt to start this recording, using a different MCP. If the second attempt is successful, the alarm is not generated. If the second attempt also fails and recording is not started, then the recording scenario is considered unsuccessful and the alarm is raised.
An alarm can be issued for the start, pause, and resumption of MSML-based recording operations regardless of the method selected as a trigger. For example, an alarm can be triggered for the start recording command if it is submitted from an agent desktop or from the routing strategy in a
TRouteCall request, or if it is activated internally based on a DN configuration. An alarm is
SIP Server—Deployment Guide 135
Chapter 5: SIP Server Feature Support Call Recording—MSML-Based not raised for the stop recording operation. If an attempt to stop the recording fails, SIP Server terminates recording dialogs without raising an alarm.
With this feature enabled, when the first call recording failure is detected, SIP
Server generates a
01-52051
alarm message and starts the timer using the interval defined in the
recording-failure-alarm-timeout
Each consecutive call recording failure detected during this period increments the counter. When the timer expires, SIP Server generates an alarm message with the number of failures detected in the past interval and resets the counter.
If the timer expires and no recording failures have been detected within the past interval, SIP Server does not generate an alarm message.
This call recording alarm is designed as a persistent alarm. An administrator can clear this alarm manually or use the Clearance Timeout timer in Genesys
Administrator.
Here are some examples of alarm messages:
14:34:38.906 Std 52051 1 call recording sessions failed
14:35:38.913 Std 52051 571 call recording sessions failed
Call Recording Failure Count
SIP Server maintains the call recording failure count by using the SIP Server
1536 logs.
When SIP Server starts, a log with suffix
1536
is generated where SIP Server operational statistics are periodically logged. Operational statistics are generated properly only if the
option is configured. The frequency
with which statistics getting printed in the log is controlled by the
configuration option.
The cumulative number of call recording failures is reset after SIP Server restarts.
A SIP Server active call recording failure count is printed in the log of the Call
Manager section. Here is an example of a message containing the call recording failure count that is logged in the SIP Server 1536 log.
10:30:29.945: --------- SIP Server Operational Statistics ------------
.
.10:30:29.945: <sipCallManager>
..
10:30:29.945: NCALLRECORDINGFAILED=10
10:30:29.945: </sipCallManager>
..
10:30:29.945: ------------ End of Operational Statistics ------------
Recording in Outbound Call Scenarios
In Outbound call scenarios (ASM, Transfer, or Proactive modes), recording will be started only after a caller is connected to an agent in both regular
(static) and dynamic recording.
136 Framework 8.1
Chapter 5: SIP Server Feature Support Call Recording—MSML-Based
DN Recording Override
Call recording functionality can be enabled statically on a DN by setting the record
configuration option to true,
or dynamically by using the record
key in the
Extensions
attribute of a
TRouteCall
request.
With this feature, call recording can be selectively disabled through a routing strategy by overriding the record
option configured on a DN. Call recording can be disabled on either the origination DN or destination DN when a routing strategy issues
TRouteCall
containing the record
extension key set to disable_source
or disable_destination,
respectively.
When recording is disabled by the
TRouteCall
request, recording can be started on the DN by issuing a
TPrivateService
request after the call is established.
DN Recording Override is supported with MSML-based call recording, for single-site, multi-site, and Business Continuity deployments. DN Recording
Override is not supported with NETANN-based call recording.
General Rules for DN Recording Override
•
If a recording configuration is overwritten for a DN, recording does not start when a call is answered on this DN. Recording can still be activated on this DN when the call is already established using the
TPrivateService(GSIP_RECORD_START)
request.
•
It is not possible to disable recording on both origination and destination
DNs using the same
TRouteCall
request.
•
Extension key values provided in a
TRouteCall
request are not carried forward to the subsequent requests.
•
Call recording that is already in progress cannot be stopped.
describes how the record
key is processed if a call is routed to the remote SIP Server
.
Table 30: Record Key Processing in Multi-Site Scenarios
Record Extension Key Value in
TRouteCall
ISCC Transaction Type route
destination
Recording is started at the remote site disable_destination source disable_source
Recording configuration is overridden at the remote site
Recording is started at the local site
Recording configuration is overridden at the local site
Note:
For multi-site
REFER
(OOSP) transfers, only the record
key extension values destination
and disable_destination
with the ISCC transaction type
Route
are supported.
SIP Server—Deployment Guide 137
Chapter 5: SIP Server Feature Support Call Recording—MSML-Based
Multi-Site Call Flow Examples
These call flow examples show how DN Recording Override works in multisite deployments.
Example 1: record=‘disable_source’
1. Agent 1 with record=true
at Site 1 dials internally to a Routing Point at
Site 1.
2.
TRouteCall
containing record=’disable_source’
with ISCC transaction type route
is issued to Agent 2 at Site 2.
3. Call recording is disabled for Agent 1 at the origination site (Site 1).
Example 2: record=‘disable_destination’
1. An inbound call arrives at a Routing Point at Site 1.
2.
TRouteCall
containing record=’disable_destination’
with ISCC transaction type route
is issued to Agent 2 with record=true
at Site 2.
3. Call recording is disabled for Agent 2 at the destination site (Site 2).
Configuration Notes
This feature applies only if the following configurations are enabled:
•
Application-level options must be set to true:
msml-support=true msml-record-support=true
•
Multi-site deployment:
The destination site must be controlled by SIP Server
( sip-server-inter-trunk=true
).
ISCC transaction type must be set to route
.
Feature Configuration
describes how to enable MSML-based call recording.
Table 31: Configuring MSML-Based Call Recording
Objective
1. Integrate SIP Server with
Genesys Media Server.
Key Procedures and Actions
Complete the steps described in:
•
Table 12: Integrating Media Server for MSML, on page 95
138 Framework 8.1
Chapter 5: SIP Server Feature Support Call Recording—MSML-Based
Table 31: Configuring MSML-Based Call Recording (Continued)
Objective
2. Configure the SIP Server
Application.
3. Configure the MSML DN.
Key Procedures and Actions
In the
TServer
section of the SIP Server
Application
object, configure the following options:
•
true
.
•
—Enter the name of the recorded file. For example: call-$ANI$-$DNIS$-$DATE$-$TIME$-$CONNID$-$UUID$-
$AGENTDN$-$AGENTID$
•
—Set this option to true
.
•
true
. Required for
backward compatibility for local recording with GVP.
•
—To enable recording for consultation
calls, set this option to true
.
•
—To enable recording without a music-on-hold treatment, set this option to false
(in case if music-on-hold is enabled with the
true
)
.
•
recording-failure-alarm-timeout
alarms, set this option to a value other than 0 (zero).
•
—To enable call recording after a transfer or conference is completed, set this option to true
.
1. Open the
Voice over IP Service
DN that you created in the SIP
Server-Genesys Media Server integration.
2. In the
TServer
section, configure the following additional options:
—Set to false
.
—Set to
1
.
—Set to false
.
Enabling Call Recording Features
Enable full-time call recording.
To start recording based on static DN-level settings, set the record
configuration option to true,
in the
TServer
section, in any of the following:
•
Extension
DN for agent-side recording
•
Agent Login for agent-side recording
•
Trunk
DN for customer-side recording
SIP Server—Deployment Guide 139
Chapter 5: SIP Server Feature Support Call Recording—MSML-Based
Table 31: Configuring MSML-Based Call Recording (Continued)
Objective
Enable dynamic call recording.
To start recording during an ongoing conversation, configure either of the following:
• In the routing strategy, configure the
TRouteCall
request to include the key record
, with the values:
destination
for agent-side recording source
for customer-side recording
• In the T-Library client, configure the
TPrivateService
request to include the key record
, with the values:
source
for recording
ThisDN destination
for recording
OtherDN
You can also add the following optional key-value pairs:
id
—A string used to add an identifier to the recording session.
Must be globally unique. If not configured, Media Server constructs a unique identifier itself.
dest
—A string used to override the default location of the 3rd party recording server.
params
—A string used to add additional parameters that can be passed as generic key-value pairs. These parameters will appear in the recording session.
Note: Full-time recording takes precedence over dynamic recording.
SIP Server rejects any dynamic recording request that arrive while recording is already underway.
Enable mid-call recording control.
To control the recording during an established session, configure
TPrivateService
to include the key
AttrPrivateMsgID
, using one of the following values:
•
GSIP_RECORD_STOP (3014)
•
GSIP_RECORD_PAUSE (3015)
•
GSIP_RECORD_RESUME (3016)
Enable DN recording override.
Key Procedures and Actions
To disable call recording, in the routing strategy, configure the
TRouteCall
request to include the record
key with the appropriate value, as follows:
•
disable_source
—to disable recording on the origination DN.
•
disable_destination
—to disable recording on the destination
DN.
140 Framework 8.1
Chapter 5: SIP Server Feature Support Call Recording—Geo-location
Call Recording—Geo-location
In Active Call Recording scenarios, SIP Server is able to select the Media
Server and Recording Server based on its geographic proximity to either the caller or the agent. This minimizes WAN traffic and telecom costs. SIP Server does not select the service itself, it passes the geo-location information (in the
X-Genesys-geo-location
header) in the initial
INVITE
messages to Resource
Manager, which then uses that information to select the closest Media Server to the caller or agent.
You can configure geo-location in any of the following places:
•
Inbound
Trunk
DN
•
Routing Point
DN
•
Extension
Attribute in
TRouteCall
•
Agent
Extension
DN
SIP Server selects and passes the
X-Genesys-geo-location
header using a different order of configuration precedence, depending on the call scenario.
Inbound Call Scenarios
Configuration Order of Precedence
For inbound calls, the order of precedence for the geo-location configuration is:
1.
Extension
Attribute in
TRouteCall
2.
Routing Point
DN where the incoming call arrives
3. Inbound
Trunk
DN where the call first arrives
4. Agent DN where recording is enabled
Outbound Call Scenarios
Outbound Solution—ASM, Proactive, or Transfer
Modes
For outbound calls using TMakePredictiveCall (ASM, proactive, or transfer mode), the order of precedence for the geo-location configuration is:
1.
Extension
Attribute in
TRouteCall
that is received from URS in response to
SIP Server’s
TRouteCall
, which is issued upon an answered outbound call arrival.
2.
Routing Point
DN from which an outbound call is originated or where the answered outbound call is transferred to from a
Trunk Group
DN for distribution to an agent.
SIP Server—Deployment Guide 141
Chapter 5: SIP Server Feature Support Call Release Tracking
3. Outbound
Trunk
DN where the call is sent to the customer.
4. Agent DN where recording is enabled.
Outbound Solution—Engaging Mode
For outbound calls that engage the agent before making the call out to the customer, the order of precedence for the geo-location configuration is:
1.
Extension
Attribute in
TRouteCall
that is received from URS in response to
SIP Server’s
TRouteCall
, which is issued upon an answered outbound call arrival.
2.
Routing Point
DN from which an outbound call is originated or where the answered outbound call is transferred to from a
Trunk Group
DN for distribution to an agent.
3. Outbound
Trunk
DN where the call is sent to the customer.
4.
Trunk Group
DN for Engaging mode.
Regular Outbound Calls
For outgoing calls using
TMakeCall
(Agent makes a 3pcc or 1pcc outbound call to the customer/external party through a media gateway
Trunk
DN), the order of precedence for the geo-location configuration is:
1.
Extension
Attribute in
TRouteCall
2.
Routing Point
DN
3. Agent DN
4.
Trunk
DN
Feature Limitation
Geo-location for call recording may not work in cases where multiple MSML media services are required.
Call Release Tracking
If configured, SIP Server can provide information about which party—agent or customer—initiated the release of a call. Added to historical and real-time reporting, this information is useful for different applications.
Call release tracking is available for all 3pcc and 1pcc call release scenarios.
142 Framework 8.1
Chapter 5: SIP Server Feature Support Call Supervision
DN-Based Reporting
In DN-based reporting, information about who released the call is reported in the
AttributeExtension
using extension key
ReleasingParty
in
EventReleased and
EventAbandoned events, when those events are distributed.
SIP Server includes one of the following values in the
ReleasingParty
key:
•
1 Local
—The call is released because the
ThisDN
value in the
EventReleased
requested the release.
•
2 Remote
—The call is released because the other party (which is remote to
ThisDN
) in the
EventReleased
or
EventAbandoned
events requested the release.
•
3 Unknown
—The call is released, but SIP Server cannot determine the release initiator.
Feature Configuration
Table 32: Configuring Call Release Tracking
Objective Key Procedures and Actions
Configure the SIP Server
Application.
In the
TServer
section of the SIP Server
Application object, configure the following option:
•
—Set this option to true
.
Call Supervision
Call supervision functionality is designed to enable contact center managers to monitor agent DNs, and it also enables agents to invite their supervisors to the call when dealing with a customer.
SIP Server supports the following call supervision scenarios:
•
Standard Call Supervision—Enables supervisors to monitor agent DNs where supervisors and agents are located on the same site.
•
Multi-Site Supervision—Enables supervisors at a local site, from an endpoint controlled by a local SIP Server, to monitor remote agents, whose
endpoints are controlled by another SIP Server. See “Multi-Site
.
•
Remote Supervision feature—Enables supervisors to monitor agents from outside the contact center—for example, from an off-premise cell phone.
See “Remote Supervision” on page 158 .
SIP Server—Deployment Guide 143
Chapter 5: SIP Server Feature Support
Overview
144
Call Supervision
There are two types of call supervision that SIP Server supports:
•
Subscription monitoring enables supervisors to subscribe and monitor one agent DN. If the subscription is active, SIP Server automatically invites the supervisor to all calls where the agent DN participates. SIP Server stops working in this mode when the subscription is cancelled.
•
Assistance monitoring is activated by an agent by issuing an assistance request sent to the supervisor. The agent can issue this while he or she is on a call with a customer.
Supervision Modes
Call supervision is performed in three different modes:
•
Silent monitoring hides the supervisor’s presence from all call participants, including the monitored DN for the agent who is the target of the supervisor’s attention.
•
Whisper coaching hides the supervisor’s presence from all call participants but the monitored agent. Only the agent can hear the supervisor.
•
Open supervisor presence invites the supervisor to the call through subscription or assistance call supervision scenarios, but all call participants are aware of the supervisor’s presence and can hear the conversation.
The supervisor can choose any of these three modes for the call supervision subscription, but the agent can only use the last two modes for an assistance request.
Supervision Scopes
The call supervision scope specifies the time frame when the supervisor must participate in the call. There are two supervision scopes available:
•
Agent scope allows the supervisor to monitor the agent. The supervisor joins the call when the call is established on the agent’s monitored DN. The supervisor leaves the call immediately after the agent leaves the call.
•
Call scope allows the supervisor to control the customer’s experience. The supervisor joins the call when the call is established on the agent’s monitored DN, or when the supervisor receives the assistance request from the agent. SIP Server keeps the supervisor as part of the call as long as either a customer or monitored agent remains in the call.
The supervisor can choose either of these scopes for the monitoring subscription.
An assistance request issued by the agent does not specify the supervision scope, so the scope always contains the call
value. Therefore, if a supervisor is invited to a call through an assistance request, he or she will stay on the call until the call is finished.
Framework 8.1
Chapter 5: SIP Server Feature Support Call Supervision
Supervision Types
The call supervision type specifies the number of calls to be monitored—either one call or all calls.
•
If one call is chosen for the subscription, the subscription is cancelled automatically when the supervisor finishes monitoring the first call on the monitored DN.
•
If all calls is chosen for the subscription, the supervisor must cancel the subscription manually when he or she wants to stop monitoring the agent’s calls.
The call supervision type cannot be specified for an assistance request. The one call type is always used when call supervision is initiated through an assistance request. The type cannot be changed through the configuration settings.
Monitoring Session
A monitoring session is the process in which a supervisor listens to an agent-customer conversation. There are two types of monitoring sessions that are defined by the session creation scenario:
•
A subscription session is created by SIP Server automatically when a call is delivered to an agent’s DN using the existing call supervision subscription.
•
An assistance session is created as a result of the assistance request sent by an agent to a supervisor.
A monitoring session of any type must be initialized with the following three parameters when it is created:
•
Supervision type
•
Supervision mode
•
Supervision scope
These parameters in the subscription session are initialized with the values of the corresponding parameters in the subscription from which this session was derived. An assistance session uses information passed in the assistance request and includes some configuration parameters for the initialization
purpose. See “Call Supervision Configuration” on page 149
for more information.
A monitoring session begins when a supervisor joins a call, and ends when the supervisor disconnects from the call.
One call can have monitoring sessions of both types, which are active at the same time. Each monitoring session is uniquely identified by the supervisor involved. As a result, the supervisor can participate in only one monitoring session at a time, but one agent can be part of multiple monitoring sessions
SIP Server—Deployment Guide 145
Chapter 5: SIP Server Feature Support Call Supervision where one of the sessions is subscription-based and other sessions are assistance request-based.
The following example demonstrates how multiple monitoring sessions are created in one call:
•
Agent1 answers an incoming call and Supervisor1 is invited to the call based on the existing subscription.
•
Agent1 sends an assistance request to Supervisor2 who also joins the call.
This call has two monitoring sessions active at the same time: the first session has a subscription type, and the second session is an assistance session.
Intrusion
Intrusion occurs when a supervisor activates a new call supervision subscription to monitor an agent who is currently on a call. SIP Server creates the requested subscription and immediately invites the supervisor to join the existing call.
Monitoring Consultation Calls
SIP Server supports the monitoring of consultation calls made to or from a DN under call supervision. This feature is disabled by default. To enable this
feature, use the option monitor-consult-calls
If enabled, monitoring can take place in the following two ways:
•
Consultation call initiated by the agent—If the agent under supervision with scope set to
Agent
initiates a consultation call, the supervisor will continue listing to the held call until the consultation call is established. At that time, the supervisor will be re-invited to the consultation call using the same dialog. The agent under supervision can alternate with or reconnect to the main call, in which case the supervisor will monitor the “active” call.
After the transfer is complete, the agent releases from the call and supervision is terminated. After the conference is completed, the supervisor will continue to monitor the conference call. If the agent under supervision is instead using the
Call
scope, the supervisor will then continue to monitor the main call even after the consultation call is established.
•
Consultation call received by the agent—If the agent under supervision receives a consultation call (
Call
or
Agent
scope), the supervisor is connected to the consultation call and will later be connected to the main call when the transfer/conference is completed.
When enabled, consultation call monitoring is supported for both supervision scopes (
Agent
and
Call
scope), both supervision types (all calls and one call), and all supervision modes (
Open, Silent,
and
Whisper
). Remote and multi-site supervision also support consultation call monitoring. Please note the following:
146 Framework 8.1
Chapter 5: SIP Server Feature Support Call Supervision
•
Intrusion—If a supervisor intrudes on an agent currently in a consultation call, the supervisor will monitor the ‘active’ (non-held) call. If intrusion is made with agent scope, the supervisor will continue to monitor the ‘active’ call of the agent after alternate/reconnect. For call scope, the supervisor will continue to monitor the same call. To allow intrusion, the option
true
.
•
Supervision Type—For “one call” type, the consultation call and main call are considered the same. This means that if the main call is currently under
“one call” type supervision, supervision will still be performed on the consultation call if initiated by the agent under supervision.
•
Assistance Request—If an agent requests assistance during a consultation call, then alternates back to the main call, the supervisor will listen to hold music and will not reconnect with the main call.
•
Double monitoring—The calling and called party cannot both be monitored at the same time. When a consultation call to a monitored destination is made by a monitored agent, the supervisor monitoring the agent (not the destination) will join the call.
•
If a consultation call is answered, but the supervisor has not yet answered the alerting call, the call to the supervisor will be dropped on transfer complete.
Introduced in
SIP Server
8.1.101.38
Switching Between Supervision Modes
A supervisor can switch between any supervision modes—silent monitoring, whisper coaching, or open supervisor presence—in MSML-based call monitoring, as follows:
•
To switch from any mode to connect
(or open supervision), the supervisor uses a
TSetMuteOff
request.
•
To switch from any mode to mute,
the supervisor uses a
TSetMuteOn request.
•
To switch from mute
to coach,
the supervisor uses a
TSetMuteOff
request with the
MonitorMode=coac h extension key.
•
To switch from connect
to coach,
the supervisor uses a
TSetMuteOn
request with the
MonitorMode=coach
extension key.
When a supervisor changes the supervision mode using the
TSetMuteOff
or
TSetMuteOn
request, SIP Server generates an
EventPrivateInfo(4024)
message with the
MonitorMode
key in
AttributeExtensions
to the supervisor and agent
DNs, and all of subscribed T-Library clients.
SIP Server—Deployment Guide 147
Chapter 5: SIP Server Feature Support Call Supervision
Switching between supervision modes can be performed only during an established supervision call (with a supervisor present on the call), and from the same supervisor DN from which the
TMonitorNextCall
request was sent.
Notes:
• This feature is supported for Assistance Supervision and Multi-site
Supervision, and for both monitoring scopes agent
and call
.
• This feature depends on support from specific versions of
Workspace Desktop or a T-Library client. Consult corresponding documentation for the availability of this new feature in those components.
Feature Configuration
In the
TServer
section of the SIP Server Application, configure the following options:
•
—Set this option to true
.
•
true
.
Feature Limitation
Supervision modes cannot be changed during the remote supervision session.
Introduced in
SIP Server
8.1.101.87
Customer-on-Hold Privacy
Some countries require that a customer who is on hold must be muted to the supervisor and agent(s) who are sharing the call.
Conference Behavior
In these examples: a customer, one or more agents, and a supervisor share a conference call.
Example 1
ON THE CALL: Customer, agent, supervisor (in Whisper mode).
ACTION: The agent puts the customer on hold.
RESULT: The customer hears music, and is muted to everyone else.
Example 2
ON THE CALL: Customer, agent, supervisor (in Open mode).
ACTION: The agent puts the customer on hold.
RESULT: The customer and the supervisor can still converse.
Example 3
ON THE CALL: Customer, two agents, supervisor (in Whisper mode).
ACTION: The first agent puts the customer on hold.
148 Framework 8.1
Chapter 5: SIP Server Feature Support Call Supervision
RESULT: The customer and the second agent can still converse.
Notes:
• This feature applies to MSML mode only.
• If the recording is activated on the inbound (customer) trunk, the customer will be recorded even while on hold. If the recording is activated on the agent leg, the customer will not be recorded while on hold.
Feature Configuration
1. In the
TServer
section of the SIP Server Application, configure the following options:
true
.
—Set this option to false.
—Set this option to true
.
2. Verify that the sip-enable-call-info-extended
is set to true.
3. In the
TServer
section of
Trunk
DNs (for all trunks between SIP Servers
participating in the call flow), set the sip-server-inter-trunk
option to true.
Call Supervision Configuration
This section describes how to configure call supervision. It covers the following topics:
•
•
•
Supervisor Auto-release, page 152
•
Hiding Supervisor’s Presence, page 153
•
Configuration Options, page 154
Subscription
Call supervision subscription is controlled by two T-Library requests:
•
TMonitorNextCall
•
TCancelMonitoring
The supervisor’s desktop must be able to process these two requests to perform call supervision.
The first request creates a new subscription, and the second request cancels the existing subscription. These requests use
AttributeThisDN
to identify the supervisor and
AttributeOtherDN
to identify the monitored agent DN.
SIP Server—Deployment Guide 149
Chapter 5: SIP Server Feature Support Call Supervision
Subscription Creation
SIP Server creates a new subscription based on the
TMonitorNextCall
request from the supervisor. The request is either accepted or rejected.
SIP Server rejects the request in the following scenarios:
•
The supervisor or the monitored agent DN already has an active subscription.
However, if the
TMonitorNextCall
request tries to activate a monitoring subscription that is already active (for example, the supervisor who submitted this request is already set up to monitor the agent), SIP Server responds with standard
EventMonitoringNextCall
messages sent to the agent and supervisor DNs. This request is not rejected, because it does not create multiple subscriptions on one DN.
•
The supervisor or the agent DN is not configured in the Configuration
Layer.
If the request is accepted, SIP Server creates a new subscription and initializes it with the type, mode, and scope information that was defined in the request.
This information is part of the request as the following attributes:
•
AttributeMonitorNextCallType, which defines the type of call supervision. Its possible values are
MonitorOneCall
and
MonitorAllCalls
.
•
AttributeExtensions/MonitorMode,
which defines the mode of call supervision. Its possible values are
normal, mute, coach,
and connect
.
•
AttributeExtensions/MonitorScope,
which defines the scope of call supervision. Its possible values are call
and agent
.
If one or both of the monitoring extensions are missing or incorrect, the following values are used:
•
for
MonitorScope
•
MonitorMode
SIP Server confirms the new subscription for both the supervisor and the agent by sending an
EventMonitoringNextCall
message to both destinations. This event always contains
AttributeExtensions
that include both monitoring extensions. These extensions represent the monitoring configuration for a new subscription.
150 Framework 8.1
Chapter 5: SIP Server Feature Support Call Supervision
See “Using the Extensions Attribute” on page 422 for more information.
Notes:
• SIP Server identifies the agent to whom call supervision will be applied by the agent DN specified in the
OtherDN
attribute of the
TMonitorNextCall
request. The agent’s login ID is not used for this purpose. In particular, this means that SIP Server does not try to identify the agent who is logged in on the monitored DN, or to analyze the agent’s state to decide if supervision should be activated for a call. SIP Server monitors calls made to or from the specified
DN, regardless of the person using this DN, until supervision scope
expires (see “Supervision Scopes” on page 144
).
• Supervision starts only when a call is delivered to an agent from a
Routing Point/ACD Queue.
Subscription Cancellation
SIP Server can cancel active subscriptions using the following methods:
•
Manual, where a supervisor submits a
TCancelMonitoring
request.
•
Automatic, where SIP Server cancels the subscription when a
MonitorOneCall
-type monitoring session is terminated.
A supervisor can submit a
TCancelMonitoring
request at any time. SIP Server identifies a subscription by the pair of supervisor and agent DNs. If this subscription exists, then it will be cancelled. Otherwise, SIP Server returns an
EventError
message.
SIP Server generates
EventMonitoringCancelled
events for both the supervisor and the agent to inform them that the subscription was cancelled.
Assistance Request
An assistance request is a
TSingleStepConference
request containing the
AssistMode
parameter in the extensions. SIP Server creates a new monitoring session based on the assistance request, but a monitoring subscription is not created.
The
AssistMode
extension is identical to the
MonitorMode
extension used in the
TMonitorNextCall
request. The difference is that
AssistMode
can contain only the connect
and coach
values.
There are no parameters to define the scope and type of monitoring in an assistance request, so the following monitoring parameters are used:
•
MonitorScope
set to call
•
MonitorType
set to
MonitorOneCall
These two settings are hard-coded and cannot be changed.
SIP Server—Deployment Guide 151
Chapter 5: SIP Server Feature Support Call Supervision
Supervisor Auto-release
Depending on the type of monitoring scope and mode, SIP Server determines whether to release a supervisor from the call. If the monitoring scope is agent,
SIP Server releases the supervisor from the call at the same time that the monitored agent leaves the call. If the monitoring scope is call
and the other party of the call is aware of the supervisor’s presence on the call and can hear this supervisor, SIP Server does not release the supervisor from the call.
Example 1
Example 2
Example 3
Call Scenarios
This section presents two-party and three-party call scenarios to demonstrate how auto-release rules work.
Three-party call,
MonitorScope
= call
:
1. A call is established with three parties: a caller, a supervisor, and Agent 1
(a monitored target of the supervisor).
2. Agent 1 transfers the call to Agent 2 (whose DN is not monitored by the supervisor).
3. The call now has the following parties: the caller, the supervisor, and
Agent 2.
The supervisor is not released in this step, because
MonitorScope
is set to call,
and the call is not finished yet (the monitor scope has not expired).
4. The caller hangs up. Now this call contains only two parties.
5. One of the following happens:
If
MonitorMode
is set to mute
or
coach,
SIP Server will release the supervisor and the call, because the supervisor is on the call with the agent (Agent 2) whose DN is not the monitoring target of this supervisor; and the agent is not aware of the supervisor’s presence.
If
MonitorMode
is set to connect,
SIP Server will not release the supervisor, so Agent 2 can hear the supervisor.
Three-party call,
MonitorScope
= agent
:
1. A call is established with three parties: a caller, a supervisor, Agent 1
(whose DN is a monitored target of the supervisor).
2. Agent 1 transfers a call to Agent 2 (whose DN is not monitored by a supervisor).
3. SIP Server releases the supervisor from the call. The caller and Agent 2 remain on the call.
Three-party call with recording,
MonitorScope
= call, MonitorMode=mute
:
1. A call is established with three parties and a recorder: a caller, a supervisor,
Agent 1 (whose DN is a monitored target of the supervisor), and the recorder.
152 Framework 8.1
Chapter 5: SIP Server Feature Support Call Supervision
Example 4
2. The caller hangs up. Now this call contains three parties: Agent 1, the supervisor, and the recorder.
3. SIP Server releases the supervisor and the call, because
MonitorMode
is set to mute and the agent cannot talk to the supervisor.
Three-party call with recording,
MonitorScope
= call, MonitorMode
= connect
:
1. A call is established with three parties and a recorder: a caller, a supervisor,
Agent 1 (whose DN is a monitored target of the supervisor), and the recorder.
2. Agent 1 transfers the call to Agent 2 (whose DN is not monitored by the supervisor).
Now the call has the following parties: the caller, the supervisor, Agent 2, and the recorder. The supervisor is not released in this scenario, because
MonitorScope
is set to call,
and the call is not finished yet (the monitor scope is not expired).
3. The caller hangs up.
4. SIP Server does not auto-release the call, but will enable the supervisor to continue talking to Agent 2.
Hiding Supervisor’s Presence
A supervisor who is performing silent monitoring or whisper coaching must be hidden from other call participants. If the scenario involves whisper coaching, only the monitored agent (who can hear the supervisor) must be aware of his or her presence on the call.
Call participants receive information about other participants joining or leaving the call from the corresponding T-Library events distributed by SIP Server.
Supervisor presence is not shown to any new participant joining the call. The
T-Library desktop applications used by call center employees must be able to process T-Library events and indicate recent changes in a call status. For example, they can show that new participant has just joined or left the call.
Hiding a supervisor’s presence means filtering out any events that inform other participants about the supervisor's activity. SIP Server inserts specific information into the T-Library events that allow T-Library clients to decide if a particular event must be shown to the customer or it must be suppressed. SIP
Server makes modifications to the events if at least one monitoring session is active on a call. The following attributes support this functionality:
•
AttributeCallState
•
AttributeOtherDNRole
•
AttributeThirdPartyDN
•
AttributeThirdPartyDNRole
The details on how those attributes are modified are found in the Genesys
Events and Models Reference Manual.
SIP Server—Deployment Guide 153
Chapter 5: SIP Server Feature Support Call Supervision
Configuration Options
The following SIP Server Application-level options support call supervision functionality:
•
•
•
•
•
•
Feature Limitations
The following known limitations currently apply to call supervision:
•
Genesys recommends that you not configure agent-greeting functionality for a supervisor that is currently configured for Supervisor Monitoring.
For NETANN-based call monitoring, when agent-greeting functionality is enabled for the supervisor and silence monitoring is requested, then both agent and caller will hear the greeting when the supervisor joins the call.
•
For NETANN-based call monitoring, if the supervisor changes the supervisor mode during a call (with MuteOn/MuteOff), then the mode will be changed for both the consultation call and the main call. For MSMLbased call monitoring, the supervisor mode will be changed only for the call where a corresponding T-Library request is submitted.
•
Call supervision functionality is disabled for video calls.
•
A supervisor participating in a monitoring session should not initiate a
1pcc or 3pcc call transfer or conference call because this can change either the supervisor’s status in the conference call or the status of a new party added to the call because of the conference or transfer.
•
•
If a supervisor is already engaged in a call when an agent DN that it is targeting joins a new call (which requires monitoring), SIP Server does not invite the supervisor to monitor the new agent conversation. Even if the supervisor disconnects from its current call, the monitoring session for the new agent conversation will not start. SIP Server will activate monitoring for the next call on the targeted DN. This limitation is applied to supervision initiated through subscription monitoring (
MonitorMode
) and does not apply to the assistance monitoring (
AssistMode
).
Call supervision functionality is supported only when Stream Manager or Genesys Media Server is used as the MCU. This is because SIP
Server sends proprietary information in the SIP messages to set up a specific conference mode that can only be interpreted by Stream
Manager or Media Server
.
154 Framework 8.1
Chapter 5: SIP Server Feature Support Call Supervision
•
When two agents are monitored by two different supervisors, and one agent calls the other agent, SIP Server invites only one supervisor to the call.
•
Call supervision of the ACD Queue is not supported.
•
Call supervision of the Hunt Group is not supported. Hunt Group members can only be monitored.
•
If a supervisor is using whisper coaching with
MonitorScope
set to call, and the agent under supervision consults to an agent who is also under coach supervision, then after the transfer or conference is complete, the new agent will also be able to hear the supervisor on the main call.
Normally, in all other conditions, only the specific agent under supervision can hear the supervisor when using whisper coaching, even if another agent joins the call.
•
Call supervision of outbound predictive calls in ASM mode is not supported.
See also: known limitations that apply to multi-site supervision on page 158
and remote supervision on page 166 .
Multi-Site Supervision
When SIP Servers operate in a multi-site environment, a supervisor at a local site, from an endpoint controlled by a local SIP Server, can monitor remote agents whose endpoints are controlled by another SIP Server.
A supervisor can switch between modes as described in “Switching Between
Supervision Modes” on page 147
.
Feature Configuration
To enable this feature, both the supervisor’s SIP Server and the agent’s SIP
Server must be configured for mutual multi-site access with the ISCC transaction type route
or direct-uui
(see Chapter 9, “Multi-Site Support,” on page 647
). Additionally, a special
Routing Point
DN, dedicated for multi-site supervision, must be configured under the agent’s
Switch
object. The
Routing
Point
number must be specified in the observing-routing-point
agent’s SIP Server
Application
object. A special routing strategy must be loaded on the observing Routing Point to route the observing call leg to the
supervisor. (See “Routing Strategy Design Sample” on page 156
.)
A multi-site monitoring session can be initiated by a T-Library client connected to the supervisor’s SIP Server by issuing a
TMonitorNextCall request. The request must contain:
•
The
Location
parameter with the remote
value
•
(Optional) The
MonitorMode
parameter
•
(Optional) The
MonitorScope
parameter
SIP Server—Deployment Guide 155
Chapter 5: SIP Server Feature Support Call Supervision
If optional parameters are not specified in the
TMonitorNextCall
request, the
values will be taken from the default-monitor-mode
and
configuration options of the agent’s SIP Server
Application
object.
The
TMonitorNextCall
request, issued by a T-Library client to the supervisor’s
SIP Server, is transmitted through the ISCC connection to the agent’s SIP
Server and registered on both servers.
After a call has been answered by an agent, the agent’s SIP Server initiates the observing service by creating a call leg to the Routing Point specified by the observing-routing-point
option.
The
EventRouteRequest message generated by the agent’s SIP Server reports the supervisor’s switch name and the number in the
Location
and
Number extensions respectively. The routing strategy loaded on the observing Routing
Point must use this information to route the observing leg of the call to the supervisor’s endpoint.
When the supervisor answers, he or she will be connected to the call in the mode defined by the
MonitorMode
parameter of the
TMonitorNextCall
request.
During a multi-site supervision session, the supervisor’s connection to the monitored call can be changed between the initial
MonitorMode
and an open supervisor presence, with the
TSetMuteOff
and
TSetMuteOn
requests containing the supervisor’s DN in the dn
parameter. A supervision session can be canceled with the
TCancelMonitoring
request.
Note:
SIP Server supports
TSetMuteOn
and
TSetMuteOff
for established conferences only to allow for service observing.
Routing Strategy Design Sample
This section provides a routing strategy design sample (see
should be loaded on the observing Routing Point at the agent’s SIP Server to support multi-site supervision.
156
Figure 9: A Routing Strategy Design Sample
The sample strategy uses a single
Multi Function
routing object (see
). The supervisor’s number and switch name are retrieved from the
EventRouteRequest
extensions by the
ExtensionData
function. These values are passed to the
TRoute
function in the
Destination
and
Location
parameters.
Framework 8.1
Chapter 5: SIP Server Feature Support
Figure 10: The Multi Function Object
Call Supervision
Figure 11: The Function Properties
SIP Server—Deployment Guide 157
Chapter 5: SIP Server Feature Support Call Supervision
Feature Limitations
The following known limitations currently apply to multi-site supervision:
•
SIP Server will report a correct
DNRole Observer (10) parameter in corresponding events for a supervisor’s DN only if SIP Server operates in a pure SIP environment.
•
If a supervisor connects to a multi-site call, the
EventPartyAdded
message is not delivered to the remote SIP Servers. Only T-Library clients registered on DNs configured on the same SIP Server as the Supervisor will receive the
EventPartyAdded
message.
•
When SIP Server distributes
EventPartyAdded
toward an agent DN that is under multi-site supervision, this event contains a Routing Point specified in the observing-routing-point
as
AttributeOtherDN
rather than the supervisor’s DN.
•
The call-monitor-acw
option does not apply to the supervisor in multi-site supervision scenarios.
Remote Supervision
The Remote Supervision feature enables supervisors to monitor agent calls from outside the contact center—for example, from an off-premise cell phone.
Call prompting when the supervisor first dials into the contact center is used to determine whether the supervisor is authorized to access the service, what target they want to monitor, and for how long.
The Remote Supervision feature includes the following functionality:
•
Credentials check—SIP Server can check login and password credentials to verify that the supervisor is authorized to access the service.
•
Targeted monitoring—The supervisor can choose to monitor either an individual agent or calls distributed to agents from a particular Routing
Point or ACD Queue.
•
Session persistence—The session can continue after the first monitored call ends, and for all consecutive calls (for the selected target), until the supervisor decides to hang up. In between calls, the supervisor’s call is parked.
•
DN translation—If configured for it, SIP Server can translate the supervisor’s external DN to an internal DN so Reporting can monitor the call.
•
Standard Call Supervision supported—Remote Supervision also supports the following Call Supervision functions: Supervision Modes and
Supervision Scopes. For a description of these functions, see “Call
.
158 Framework 8.1
Chapter 5: SIP Server Feature Support Call Supervision
Feature Configuration
When using this feature, a remote supervisor dials from outside the contact
center to a Routing Point with a special URS routing strategy. The strategy collects a caller’s login information. Additionally, the strategy may collect the following information from the caller (or otherwise specify):
•
A desired monitoring target number
•
A supervision type (
AllCalls
), mode, and scope
•
An associated internal DN, used for reporting purposes
•
A post-feature destination DN
The strategy places these parameters as
Extensions
attributes in the
TRouteCall request.
Monitoring session starts by routing a remote supervisor’s call to the special pre-defined DN with the number gcti::park.
This DN is used to park the supervisor’s call before call monitoring starts, and between calls when several calls are monitored.
While the call is parked, the supervisor hears silence or a music file specified
Procedure:
Configuring remote supervision
Start of procedure
1. In Genesys Administrator, select the SIP Server
Application
object and
TServer
section on the
Options
tab.
This option specifies the music file, which will be played to a remote party parked on the gcti::park
DN.
2. Plan the Remote Supervision routing strategy to meet your specific needs.
The sample strategy described below is a simplified prototype. You may design your own strategy to include any custom logic available in URS, implement credential verification based on accessing enterprise databases, and utilize custom prompts. As a result, the strategy should park a call on the gcti::park
device.
3. Prepare the recordings of the voice prompts, which are used in the routing strategy to collect the caller’s login information and optional feature selection. In this sample configuration, Stream Manager is used for announcement service and caller input collection.
a. Prepare the voice prompts in 8 KHz mono audio format, encoded with one of the codecs supported by Stream Manager.
b. Assign a numeric ID unique within the Stream Manager’s announcement
directory to each announcement.
SIP Server—Deployment Guide 159
Chapter 5: SIP Server Feature Support Call Supervision
c. Name each recording file using the following format:
<ID>_<codec_suffix>.wav
Refer to the Stream Manager 7.6 Deployment Guide for the list of supported codecs and corresponding filename suffixes.
For efficiency, to avoid real-time trans-coding, you may also use the
SMzip utility supplied with Stream Manager to trans-code your prompts off-line into zip files containing the prompts encoded with all supported audio codecs.
To trans-code each prompt, use a command similar to the following:
>smzip -ac all 9000.zip 9000_pcmu.wav
d. Place the resulting audio files (either
.wav
or
.zip
) into the Stream
Manager’s announcement
directory. If you use multiple Stream
Managers, make sure that the files are replicated through all Stream
Managers’ announcement
directories.
The sample strategy collects the caller’s Agent Login and password, requests the monitoring target number, and then initiates multiple-call monitoring, using the collected caller’s input.
The strategy uses the following prompts:
Table 33: Strategy Prompts
Prompt text ID
Welcome to the Sample Remote Supervision. 9000
Please enter your Agent login.
9010
Please enter your password.
Please enter the monitoring target number.
An error occurred while processing your request.
9020
9030
9090
File Name
9000_pcmu.wav
9010_pcmu.wav
9020_pcmu.wav
9030_pcmu.wav
9090_pcmu.wav
4. In Interaction Routing Designer (IRD), design your routing strategy. See
“Routing Strategy Design Sample” on page 161 .
5. Save the complete strategy in IRD.
6. Load the strategy into a Routing Point by using the
Loading
tab in IRD.
7. Test your strategy by placing a call from an external phone to the Routing
Point number. Calls from internal DNs are not allowed.
End of procedure
160 Framework 8.1
Chapter 5: SIP Server Feature Support Call Supervision
Routing Strategy Design Sample
This section describes a strategy design sample (see Figure 12 ), followed by
the explanation of each block called in the IRD terms routing object.
Figure 12: A Routing Strategy Design Sample
Initial Greeting
The first
Play announcement
routing object is used to play back the initial
SIP Server—Deployment Guide 161
Chapter 5: SIP Server Feature Support Call Supervision
Figure 13: Initial Greeting: Parameters Tab
The
LANGUAGE, MSGID and
MSGTXT
parameters are not used by SIP Server implementation of the Announcement treatment. The
Wait for treatment end check box specifies to the URS that it should wait for the treatment to complete before proceeding to the next strategy step.
On the
PROMPT
tab (see
), the
ID
specifies the prompt to be played. The
Interruptible
flag allows the caller to skip the greeting message by pressing any key on the phone keypad.
162
Figure 14: Initial Greeting: PROMPT Tab
Collecting Agent Login Code
Although your strategy may implement an arbitrary approach to perform caller verification, this sample strategy demonstrates the SIP Server’s built-in functionality. SIP Server verifies the login-id
and password
information provided in corresponding extensions parameters against the Agent Login
Code
and
Password
specified in the
Agent Login object in the Configuration
Layer. Therefore, for the purpose of this strategy, ensure that you have configured
Agent Login
objects with the numeric-only Agent Login
Codes
and
Passwords
so they can be entered through the phone keypad.
After the initial greeting, the strategy uses the
Play Announcement and collect digits
routing object to request the caller’s Agent Login (see Figure 15 ). It
plays the “
Please enter your Agent login
” prompt and retrieves the caller’s
Framework 8.1
Chapter 5: SIP Server Feature Support Call Supervision digits input. The caller is expected to enter a numeric login code, up to 31 digits long, terminated by the “
#
” key.
Figure 15: Collecting Digits: Parameters Tab
Figure 16: Collecting Digits: PROMPT Tab
Verifying Caller Input
The next
Generic segmentation
object verifies that the caller's input (returned by the
CED[]
function) is not empty (see Figure 17 ).
SIP Server—Deployment Guide 163
Chapter 5: SIP Server Feature Support Call Supervision
Figure 17: The Generic Segmentation Object
If the caller did not enter any digits within 15 seconds (as specified by the
START_TIMEOUT
parameter in the preceding
Play Announcement and collect digits
object, the segmentation object will repeat the previous prompt.
Storing the Entered Agent Login Code in a Variable
The next
Assign routing object defines the
LoginId
internal strategy variable
(use
Variables
button to define the variable) and assigns the caller’s input
value to this variable (see Figure 18 ).
164
Figure 18: The Assign Object
Framework 8.1
Chapter 5: SIP Server Feature Support Call Supervision
Collecting Password and Monitoring Target
Subsequent routing strategy blocks prompt the caller to enter a password and the desired monitoring target DN number, and a sequence similar to the one used to collect the Agent Login information.
Collected input is placed into the
Password
and
AgentDN
internal variables.
Invoking Remote Monitoring
The key point of the strategy is the
Multi Function
object (see
).
Figure 19: The Multi Function Object
The
Multi Function
object attaches the extensions parameters to the
TRouteCall
request as the request extensions, then routes the call to the gcti::park
DN.
SIP Server determines the desired feature—remote observing from the value of the feature
extension parameter—and verifies the user’s login information.
If the supplied information is correct, SIP Server starts Remote Monitoring session. The supervisor hears silence or a music file until a call comes to the specified target. After that, the caller connects to the monitored call.
It the parameters are incorrect (for example, wrong login, password, or monitoring target information), SIP Server responds with the
EventError message to the
TRouteCall
request. This will trigger the default branch of the
Multi Function object.
Verifying the Result
If an error occurs for any reason, the strategy uses the subsequent
Play announcement
object to notify the caller about the error and returns the control flow to the point where the user is requested to enter the Agent Login again.
SIP Server—Deployment Guide 165
Chapter 5: SIP Server Feature Support Call Supervision
Use of the Extensions Attribute
The following
Extensions
attribute parameters can be used to configure the application that starts and defines the remote supervision session:
•
feature
—This key, with the remote-observing
value, triggers registration of the routed party as a supervisor with parameters specified in additional
Extensions
described in this section.
•
dn
—An optional DN number that can be used during the monitoring session as a substitute for the external PSTN number that the supervisor used to dial in. If you do not include this parameter, no TEvents will be distributed for this DN.
•
login-id
and password
—These optional parameters are used to establish that the supervisor is authorized for remote access to the feature. The treatment can prompt for the login-id
alone, or for both the login-id
and the password
.
•
agent-dn
—The target that the supervisor wants to monitor. This can be a
Routing Point or an agent DN.
•
monitor-type (AllCalls)
—An optional parameter that enables the supervisor to monitor all consecutive calls for the selected target, until the supervisor decides to hang up and end the monitoring session. In between monitored calls, the supervisor’s call is parked.
•
post-feature-dn
—An optional parameter that specifies a Routing Point to which the supervisor will be connected after the supervision session.
Feature Limitations
The following known limitations currently apply to remote supervision:
•
MonitorMode
of remote supervision session cannot be changed during active supervision.
•
One Call
supervision type is not supported.
•
When SIP Server distributes
EventPartyAdded
toward an agent DN which is under remote supervision, this event contains a Routing Point as
AttributeOtherDN
which was used during involvement of the supervisor rather than the supervisor DN.
•
Remote supervision is not supported in IMS environments.
•
There is no synchronization of parked remote supervisor’s calls between primary and backup SIP Servers. After a switchover, the remote supervisor with a parked call is not able to monitor any calls. The supervisor must hang up and call back to the contact center to be able monitor calls.
166 Framework 8.1
Chapter 5: SIP Server Feature Support Call Transfer and Conference
Call Transfer and Conference
SIP Server supports the following call transfers:
•
First-party call control (1pcc) transfers: single-step and two-step transfers.
•
Third-party call control (3pcc) transfers: single-step and two-step transfers.
In these scenarios, the
REFER
request method is used. If an endpoint does not support the
REFER
method, the re-
INVITE
method can be configured for use in two-step transfers.
SIP Server can send a
REFER
message to the transferred party when the following scenarios occur:
•
A
REFER
message was received from an endpoint.
•
A single-step call transfer was received from a client.
This removes SIP Server from the SIP signaling loop.
SIP Server analyzes the destination specified in either scenario and then determines if a different contact is specified in the outgoing
REFER
message based on the following criteria:
•
The destination is unknown to SIP Server (no regular DN and no
Trunk
DN contains the prefix that matches the specified destination).
•
The destination refers to a DN of type
Trunk
that contains the
option set to true
.
If either of the scenarios is true, SIP Server prepares a
Contact
for the
Refer-To header of the outgoing
REFER
message, based on the following conditions:
•
If there is no DN, and no DN of type
Trunk
is specified as the destination, the
Contact
information from the caller DN or the
Trunk
DN will be specified in the
Refer-To
header of the outgoing
REFER
message. It is the responsibility of the caller to determine where to transfer the call.
•
If a
Trunk
DN is specified as the destination, and it contains the oosp-transfer-enabled
option set to true
, the contact information from this trunk will be specified in the
Refer-To
header of the outgoing
REFER message.
Note:
If the caller DN or the
Trunk
DN in either scenario contains the
option specified, the value of this option will be specified in the
Refer-To
header of the outgoing
REFER
message.
Routing to External Destination Using
REFER—Inbound Calls
SIP Server supports the routing of an inbound call to an external destination by using the
REFER method. When the feature is activated, SIP Server places itself
SIP Server—Deployment Guide 167
Chapter 5: SIP Server Feature Support Call Transfer and Conference in the Out Of Signaling Path (OOSP). This feature applies to the following scenarios:
•
An inbound call is routed from a Routing Point to an external destination.
•
An agent transfers an inbound call by using the single-step transfer to a
Routing Point, then the call is routed to an external destination.
•
An agent transfers an inbound call by using the blind transfer to a Routing
Point, then the call is routed to an external destination.
Note:
This feature is not applicable for scenarios (the second and the third, above) where a conference (supervision or emergency recording) is involved.
describes how to enable routing of inbound calls to an external destination using
REFER
.
Table 34: Enabling Inbound External Routing by REFER
Objective Related Procedures and Actions
Configure the
Trunk
DN.
In the
Trunk
DN for inbound calls, configure the following options in the
TServer
section:
•
—Set this to true
.
•
Set this to false
.
This ensures the
REFER for this
Trunk
DN is used only in OOSP (single-step transfer) scenarios.
Routing to External Destinations using
REFER—Outbound Calls
SIP Server can also route outbound calls to an external destination using the
REFER
method, where SIP Server is placed out of the signaling path (OOSP) after the transfer.
describes how enable routing of outbound calls to an external destination using
REFER
.
Table 35: Enabling Outbound External Routing by REFER
Objective Related Procedures and Actions
Configure the
Trunk
DN.
In the
Trunk
DN for outbound calls, configure the following options in the
TServer
section:
•
—Set this to true
.
•
Set this to true
.
168 Framework 8.1
Chapter 5: SIP Server Feature Support Call Transfer and Conference
Selecting SIP Call Flows from the Routing Strategy
SIP Server supports dynamic selection of the SIP call flows for a particular call, based on the setting of the
key returned by a routing strategy in the
TRouteCall request. The routing strategy can use this key to select the SIP call flow that will be used to deliver the call to a routing destination.
Feature Configuration
In the routing strategy, configure the
TRouteCall
to include the key
Transfer-Type
in
AttributeExtensions
with the value set to the type of transfer you want to enable for this call: invite, refer,
or oosp
.
The
Transfer-Type
key with values refer
and invite
has a higher priority than the refer-enabled
option configured on a DN of type
Trunk
or
Extension.
In addition, the
Transfer-Type
key with the value of oosp
has a higher priority than the oosp-transfer-enabled
option configured on a DN of type
Trunk.
If SIP Server receives a
TRouteCall
with
Transfer-Type
set to refer,
but refer-enabled is set to false
on the DN, SIP Server will send
REFER
anyway
(routing strategy takes precedence). This allows the strategy to control the transfer type on a call-by-call basis.
However, SIP Server always monitors the endpoints to determine support for
REFER
. If the targeted endpoint does not announce support for
REFER
through the
SIP dialog, SIP Server will not send
REFER
to this endpoint.
Feature Limitation
The request for a
REFER
method from the routing strategy is not used if an incoming call was not connected (the destination DN did not answer the call, or a treatment was not applied to an unanswered call), SIP Server uses the re-
INVITE
method instead of
REFER.
To ensure that
REFER
is actually used, change the strategy so the
Transfer-Type
is set to oosp instead. With this setting, SIP
Server will use an Out-of-Signaling-Path
REFER
in cases where the call is currently being treated on the IVR, and not yet answered on the remote endpoint.
Single-Step Transfer Using re-INVITE
Scenarios in which single-step transfers use the re-
INVITE
request method
require that the originating DN be configured with the refer-enabled
set to false
. For external single-step transfers, the Trunk DN must be configured with
set to false
.
SIP Server—Deployment Guide 169
Chapter 5: SIP Server Feature Support Call Transfer and Conference
Controlling Transfer Methods to External Destinations
To control SIP messaging (
REFER
or re-
INVITE
) that SIP Server uses to initiate transfers or routing to an external DN, configure the inbound
Trunk
DN according to the following rules:
•
For two-step transfers, the refer-enabled
setting on the
Trunk
DN takes precedence over oosp-transfer-enabled
.
•
For single step transfers, the oosp-transfer-enabled
setting on the
Trunk
DN takes precedence over refer-enabled
.
Note:
Genesys recommends that you not use different values for the oosptransfer-enabled
option when configured on both the transfer destination Trunk and on the transferred party Trunk.
shows how these two options control the SIP methods used.
Table 36: Trunk DN Configuration for External Transfers refer-enabled oosp-transfer-enabled Single-Step Transfer/Route Two- Step Transfer
true true REFER/302 REFER false true false true false false
REFER/302
INVITE
INVITE
INVITE
REFER
INVITE
Conference Calls
SIP Server supports third-party call control (3pcc) conferences with central mixing, using MCUs that support more than three participants.
If the initiator of the 3pcc conference drops the call, other participants will remain on the call. If any participant of the 3pcc conference issues
TClearCall
, the conference will end for all participants (the call will be dropped).
Single-Step Conference to External Destination
Starting with version 8.1.101.55, SIP Server supports a
TSingleStepConference request to an external destination, which, for example, enables bringing an expert in to the conference without putting the caller on hold. The single-step conference operation can be performed from a two-way call or from a preexisting conference. While waiting for the destination to answer the call,
170 Framework 8.1
Chapter 5: SIP Server Feature Support Call Transfer and Conference existing call parties will continue hearing each other. If the destination party does not respond or rejects the request, the call returns to the previous state.
Note:
In multi-site deployments, the single-step conference operation to another site via ISCC is not supported.
Silence Treatment in Conference
SIP Server can provide a silent treatment for conference call participants when one of them places the call on hold. This will allow conference call participants to continue the conference without interruption (or hearing the music-on-hold treatment). This feature is applicable to conference calls where participants are located in single-site or multi-site environments.
For this feature to work, the music-in-conference-file
the valid name of the silent audio file to be played in applicable conferences
(more than two active participants).
Deleting Party From Conference in Multi-site
Deployments
Starting with version 8.1.101.57, SIP Server supports
TDeleteFromConference requests in multi-site deployments in the same way as in single-site deployments; that is, any agent can remove any other party from the conference using a
TDeleteFromConference
request containing a targeted party
DN.
Feature Configuration
To enable
TDeleteFromConference requests support in multi-site deployments, configure the SIP Server Application, as follows:
1. In the
TServer
section, set the following configuration options:
true
.
The Call Participant Info functionality must be activated, enabling SIP
Server to maintain an
LCTParty
list containing DNs and their locations for all parties present in the call. The LCTParty list is distributed to a
T-Library client in
EventUserEvent
.
—Set this option to true
.
2. In the extrouter
section, set the use-data-from
configuration option to current
. This enables Party Events propagation.
Feature Limitations
•
In a multi-site conference in which two DNs have identical names, if
TDeleteFromConference
is requested to remove a DN with the duplicate name, either one or both parties can be deleted from the conference.
SIP Server—Deployment Guide 171
Chapter 5: SIP Server Feature Support Call Transfer and Conference
•
In multi-site scenarios, real-time statistics related to call supervision
(particularly
CallObserved
) may be incorrect if the supervisor is released from the call before the call is finished. See Stat Server documentation for details.
Introduced in
SIP Server
8.1.101.78
Private Conversations During Conference
SIP Server supports T-Library requests
TListenDisconnect
and
TListenReconnect
. These requests can be used in a conference with three or more participants. Any agent who is using a T-Library desktop can submit a
TListenDisconnect
request to disconnect any other party from the conference temporarily. The disconnected party hears music and cannot hear the remaining participants, who can continue their conversation. Remaining conference participants also cannot hear the disconnected party. To return the disconnected party back to the conference, one of the agents in the call submits a
TListenReconnect
request.
If an agent disconnects another participant from the conference and then leaves the conference, the disconnected party remains disconnected until only one active participant exists in the conference. After that, SIP Server releases the conference and establishes the dialog between two remaining parties (the formerly disconnected and active parties).
SIP Server supports
TListenDisconnect
and
TListenReconnect
requests in accordance with the T-Library call model where SIP Server generates
EventListenDisconnected
and
EventListenReconnected
events in responses to the two corresponding requests.
EventListenDisconnected
is always distributed with
AttributeCallState
set to
CallStateHeld,
which indicates that the disconnected party cannot hear and cannot be heard by other members of the conference.
This feature must be used along with the LCTParty functionality enabled in
SIP Server. The state of the disconnected party is reported to all call participants with the standard LCTParty
EventUserEvent,
which contains the
LCTParty<n>_state
extension key with a value set to
ListenDisconnectedHeld, where n is a party index.
TListenDisconnect
and
TListenReconnect
requests must have the
AttributeOtherDN
set to the party alias reported through the LCTParty
EventUserEvent
.
Note:
This feature depends on support from specific versions of Workspace
Desktop or a T-Library client. Consult corresponding documentation for the availability of this new feature in those components.
172 Framework 8.1
Chapter 5: SIP Server Feature Support Call Transfer and Conference
Feature Configuration
In the
TServer
section of the SIP Server Application, set the following configuration options:
•
true
.
•
—Set this option to true
.
•
—Set this option to the path of any valid audio file.
Feature Limitations
•
In multi-site deployments, Genesys recommends setting the sip-enablemoh
false
on inter-trunk DNs, to avoid playing music to a remote party disconnected from the conference.
Muting/Unmuting a Party in a Conference
Starting with version 8.1.102.02, SIP Server allows any conference party on the call to mute or unmute any internal party in a conference. One party can mute several others. If a party mutes some other party and leaves the conference, the muted party remains muted if more than two participants remain in the conference. If only two participants (including the muted party) remain in the conference, SIP Server drops the conference and establishes a dialog between these two parties, thus unmuting the muted party.
Starting with release 8.1.102.20, you can enable muting in two-way calls by setting the sip-enable-two-party-mute
configuration option to true
. That way, when a party in a two-way call issues a
TSetMuteOn
or
TSetMuteOff
request, the two-way call will be converted to a conference and a Media Server
Mute
or
Unmute
command will be issued for the requestor’s leg.
Muting one of the conference's participants can be used in parallel with services, such as supervision, listen disconnect, and recording, except when the
is enabled. See also “Feature Limitations” on page 175
.
This functionality is provided through
TPrivateService
requests. The Call
Participant Info functionality must be activated, enabling SIP Server to maintain an
LCTParty
list containing DNs and their locations for all parties present in the call. The
LCTParty
list is distributed to a T-Library client in
EventUserEvent
. The
OtherDN
attribute of the
TPrivateService
request must contain the party ID received in the
LCTParty
list.
For all internal conference participants, SIP Server sends
EventUserEvent indicating which party was muted. For a disconnected (muted) party,
LCTParty[n]_mute
is set to on
. After a party is unmuted,
LCTParty[n]_mute
is not present to indicate that the party was unmuted. For the muted/unmuted party, SIP Server generates
EventMuteOn
/
EventMuteOff
, respectively.
The T-Library client must include mute/unmute-related parameters in the
TPrivateService
request that it sends to SIP Server, as described in
.
SIP Server—Deployment Guide 173
Chapter 5: SIP Server Feature Support
174
Call Transfer and Conference
Table 37: Mute/Unmute Parameters for TPrivateServer Request
Attribute Value
PrivateMsgID Specifies the type of operation to be performed:
•
SIPTS_PRIVATE_SERVICE_MUTE (3027)
— Mutes or
Unmutes a party in a conference.
ThisDN Specifies the DN on behalf of which the mute/unmute operation is requested. This DN must be registered by the T-
Library client.
ConnectionID References the ID for the call that is currently being muted/unmuted.
Extensions Specifies key-value pairs used to control the mute/unmute operation:
OtherDN
—Specifies a DN to be muted or unmuted.
Mute
—"on" to mute the
OtherDN
, "off" to unmute it.
SIP Server generates
EventPrivateInfo
(
PrivateMsgID 4029
) with the same
ReferenceID
as the one in the request to indicate that a Mute/Unmute request is accepted. The desktop should rely on the
LCTParty of
EventUserEvent
to display the current party state.
Note:
This feature depends on support from specific versions of Workspace
Desktop or a T-Library client. Consult corresponding documentation for the availability of this new feature in those components.
Mute State Duration
In SIP Server,
TSetMuteOn
is applied per-call basis. The Mute state is preserved for the duration of the call or until
TSetMuteOff
is applied. When a new call is created on the same DN, its Mute state is off. When a muted call is released,
EventMuteOff
is not needed and is not generated.
Examples:
•
A main call can be muted, but when a consultation call is created, the consultation call starts in an unmuted state.
•
When a two-step transfer or two-step conference is completed, the DN’s
Mute state will correspond to the Mute state of the main call. The consultation call is released and no
EventMuteOff
is generated.
•
When a call is muted, then parked via the “Call Park/Retrieve”
feature, and then retrieved, that call is reported as a new one and will be unmuted.
•
When a Shared Call Appearance (SCA) call is muted, then parked, and then retrieved, that call is reported as a new one and will be unmuted.
Framework 8.1
Chapter 5: SIP Server Feature Support Call Transfer and Conference
•
Contrary to the park scenarios, when a call is connected via the
feature to the new divert destination, SIP Server considers and reports the diversion as part of the same call. Accordingly, no
EventReleased
is generated and the Mute state is preserved.
Situations When a Mute Operation is Prohibited
SIP Server prohibits Mute operations in the following scenarios:
•
When a call is on hold, Mute or UnMute operations are not allowed.
•
When a greeting is being played to a party in the call, the Mute operation is not allowed (relates to the case when the sip-two-party-mute-enabled option must be set to true
).
Feature Configuration
To configure Muting/Unmuting a Party in a Conference, complete these steps:
•
In the
TServer
section of the SIP Server Application, configure the following options:
1
.
true
.
—Set this option to true
.
(Optional)
true
if required.
•
Verify that the sip-enable-call-info-extended
is set to true
.
•
In the
[TServer]
section of
Trunk
DNs (for all trunks between SIP Servers
participating in the call flow), set the sip-server-inter-trunk
option to true
.
•
In the
[extrouter]
section of the SIP Server Application, set the
option to current
or original
.
Feature Limitations
The following limitations apply to Muting/Unmuting a Party in a Conference:
•
If recording is activated on the inbound (customer) trunk, the customer will be recorded even when muted. If recording is activated on the agent leg, this agent will be recorded while muted.
•
If DNs with the same names configured on different switches participate in the conference, SIP Server might choose the incorrect party to mute.
SIP Server—Deployment Guide 175
Chapter 5: SIP Server Feature Support Call Transfer and Conference
Consultation Transfers and Conferences
SIP Server provides the ability for parties participating in a consultation call to initiate 3pcc (third-party call control) transfers or conferences. A typical supported scenario would be:
1. An inbound call is routed to Agent A.
2. Agent A originates a consultation call with Agent B.
3. Agent B originates a consultation call with Agent C.
Consultation Transfers for Calls on a Routing Point
SIP Server allows an agent to complete a consultation transfer of a call that is located on a Routing Point. This transfer operation is supported in single-site and multi-site environments.
In a single-site environment, the call transfer can be completed both when a treatment is playing for the call on a Routing Point, or when the call is just parked on a Routing Point.
In a multi-site environment, when a consultation call is made to a Routing
Point located on another site, the call transfer can be completed only when a treatment is playing for the call on the Routing Point. If a call is just parked on a Routing Point, the complete transfer operation will not be successful and SIP
Server will generate an
EventError
(
Call in invalid state
) message.
Alternating Between Main and Consultation Calls
SIP Server enables agents to handle up to three 3pcc calls on their SIP endpoint. This functionality supports alternate call operation between the main call and an answered consultation call, as well as the main call and a consultation call that is queued on a Routing Point, as described in the following scenario:
1. A call is routed to Agent A.
2. Agent A places the call on hold and initiates a consultation call by dialing to a Routing Point.
3. Agent A is placed in a queue at the Routing Point, waiting for another agent to become available (a treatment is played).
4. Agent A places the consultation call on hold and retrieves the main call from hold.
For the alternate call operation to work transparently in a multi-site environment, a treatment must be applied to a call on a Routing Point at the earliest possible time. If a treatment is not applied, the alternate call operation will not be successful and SIP Server will generate an
EventError (Call in invalid state)
message.
176 Framework 8.1
Chapter 5: SIP Server Feature Support Call Transfer and Conference
TCompleteTransfer using REFER or REFER with
Replaces
SIP Server supports the
TCompleteTransfer
operation—which completes a previously initiated two-step transfer by merging the held call with the active consultation call—by using either the SIP
REFER
or SIP
REFER
with the
Replaces header based on conditions described below.
•
SIP Server supports
TCompleteTransfer
using the SIP
REFER
method if:
The transferred party and/or the transfer-destination party are internal.
The external transferred party and/or the external transfer-destination party do not support the
Replaces
header in the
REFER
method.
•
SIP Server supports
TCompleteTransfer
using the SIP
REFER
method with
Replaces
if both the external transferred party and the external-transfer destination party support the
Replaces
header in the
REFER
method.
If
TCompleteTransfer
is performed using the
REFER
method, SIP Server stays in the signaling path. If it is performed using the
REFER
method with
Replaces,
SIP Server is taken out of the signaling path.
Feature Configuration
describes how to enable
TCompleteTransfer
operations using
REFER
.
Table 38: Enabling TCompleteTransfer by REFER
Objective Related Procedures and Actions
Configure the
Trunk
DN.
In the
Trunk
DN >
TServer
section:
1. Set
to true
.
2. Set
0
—
SIP Server only uses
REFER if transfercomplete-by-refer is enabled.
1
—
SIP Server only uses
REFER if
Allow header contains
REFER
, and
Supported header contains
Replaces
.
2
— SIP Server always uses
REFER
.
Referred-By Header Support
SIP Server provides the ability to pass the identity of the party, which has originated the transfer, in the SIP URI of the outgoing
REFER
request’s
Referred-By
header. In addition, SIP Server provides the ability to control the
“hostport” component of the SIP URIs in
Refer-To
and
Referred-By
headers of the outgoing
REFER
requests through the configuration options.
SIP Server—Deployment Guide 177
Chapter 5: SIP Server Feature Support Call Transfer and Conference
Feature Configuration
describes how to enable the
Referred-By header.
Table 39: Enabling the Referred-By header
Objective
Configure the SIP Server
Application.
(Optional) Configure a DN associated with the transferred/routed party.
Related Procedures and Actions
Set
to true
.
If it is required to override the “hostport” component of the SIP URI in
Refer-To
and
Referred-By
headers, configure the following options on a DN where an outgoing
REFER
request is sent to:
• Set override-domain-refer-to
to the “hostport” component to be
used as a “hostport” component of the SIP URI in the
Refer-To header of the outgoing
REFER
messages.
• Set
to be used as a “hostport” component of the SIP URI in the
Referred-By
header of the outgoing
REFER
messages.
Override of the “hostport” component of the SIP URI in the
Refer-To
header can be configured by the following options on a DN where an outgoing
REFER request is sent to, in order of priority:
1.
2.
3.
Override of the “hostport” component of the SIP URI in the
Referred-By header can be configured by the following options on a DN where an outgoing
REFER
request is sent to, in order of priority:
1.
2.
Feature Limitations
The following known limitations currently apply to call transfer and conference scenarios:
•
Blind conference calls are not supported.
•
Three-way conference on the telephone is not reported properly. Call participants can talk to each other, but such a call is not reported as conference.
•
SIP Server does not support the use of
REFER
for the
TCompleteTransfer operation for calls in which a Multipoint Conference Unit (MCU) is involved. For example, a call is monitored or emergency recording is applied to a call. If regular call recording is applied to the original call, the
REFER
method can be used for the
TCompleteTransfer
operation.
178 Framework 8.1
Chapter 5: SIP Server Feature Support Class of Service
•
The
Trunk
DNs that are configured between different SIP Server instances, and is ignored on
Trunk
DNs where the sip-server-inter-trunk
option is set to true.
•
1pcc transfer by
REFER
with
Replaces
may fail if SIP Server receives a SIP
REFER
request with the
Replaces
parameter in the
Refer-To
header pointing to a dialog whose SIP
Call-ID
contains a % (percentage) character. This character may appear as part of the IPv6 address scope ID, and sometimes
IP addresses are used as part of SIP
Call-ID
header.
•
In multi-site deployments, the single-step conference operation to another site via ISCC is not supported.
Class of Service
Class of Service (COS) is functionality that defines telephony capabilities for a device or an agent. In SIP Server, COS telephony capabilities are defined by configuring the following:
•
Outbound dialing rules (deprecated in release 8.0.2; Genesys recommends using the
•
Ring-through rules
Class of Service can be assigned to the device (a
DN
object in SIP Server
Switch configuration) or to the agent (an
Agent Login
object in SIP Server
Switch configuration).
The COS assigned to the agent takes precedence over the COS assigned to the device. That is, when different COSs are assigned to the device and to the agent, SIP Server will use the COS assigned to the agent.
Outbound Dialing Rules
.
Outbound dialing rules define whether an agent or device is able to make outbound calls, and they also translate dialed numbers according to the specified patterns.
Note:
Starting in release 8.0.2, the out-rule functionality provided by the
Class of Service feature is deprecated, replaced by the Dial Plan feature. For SIP Server versions 8.0.2 and later, Genesys recommends using the Dial Plan feature for configuring all outbound dial plan
rules. For more information, see “Dial Plan” on page 210 .
An outbound dialing rule is specified as a pair of patterns. The first pattern, in-pattern,
is used to match the dialed number. The second pattern, out-pattern,
defines how to transform the dialed number, when matched, to the in-pattern
.
SIP Server—Deployment Guide 179
Chapter 5: SIP Server Feature Support Class of Service
It is possible to specify several outbound dialing rules within a single COS definition.
When an outbound call is initiated either from a device (1pcc) or from a softphone (3pcc), SIP Server attempts to match the dialed number with one of the outbound dialing rules. If the matching rule is not found, SIP Server will proceed with the outbound call as it is dialed. If the matching rule is found
(that is, in-pattern
in one of the outbound dialing rules matched the dialed number), SIP Server will apply this rule to the call according to the following procedure:
1.
out-pattern
from the outbound dialing rule is applied to the dialed number to produce the resulting dialed number.
2. If the resulting dialed number is empty, SIP Server rejects an attempt to make the outbound call.
3. If the resulting dialed number is not empty, SIP Server attempts to place the outbound call to the resulting dialed number.
If there are multiple outbound dialing rules configured within a single COS, and in-pattern in more than one rule matches the dialed number, SIP Server will choose the outbound dialing rule with the most matched digits in it.
Example
Here is an example of the outbound dialing rule: in-pattern=411;out-pattern=9411
Dialing Rule Format
Dialing rules must conform to the following syntax, represented using
Augmented Backus-Naur Form (ABNF) notation. dialing-plan-rule name in-pattern out-pattern digit-part symbol-part range sequence abstract-group
= [name] in-pattern [out-pattern]
= *( ALPHA / DIGIT / "-")
= 1*(digit-part / abstract-group)
= 1*(symbol-part / group-identifier) *param-part
= digits / range / sequence
= digits / symbols
= "[" digits "-" digits "]" group-identifier
= "[" 1*(digits [","] ) "]" group-identifier
= fixed-length-group / flexible-length-group flexible-length-group = "*" group-identifier param-part param-name
= ";" param-name "=" param-value
= "ext" / "phone-context" / "dn" symbols = 1*("-" / "+" / ")" / "(" / ".")
180 Framework 8.1
Chapter 5: SIP Server Feature Support Class of Service
Common Syntax Notations
Syntax notations common to many of these rules include:
•
*
—Indicates that 0 to an infinite number of the item following this symbol are acceptable.
•
1*
—Indicates that one repetition is required. For T-Server, only one instance is acceptable.
•
/
—Indicates that any of the items mentioned, or a combination of those items, is acceptable.
Component Notations
Component notations include:
•
dialing-plan-rule = [name] in-pattern [out-pattern]
Where:
[name]
is the name of the rule option—for example, rule-01.
In ABNF notation, the brackets (
[)]
indicate that 0 or 1 instance of the component is required. However, for SIP Server, a name is required.
in-pattern
is the part of the rule to which SIP Server looks when attempting to match the input number.
[out-pattern]
is the part of the rule that instructs SIP Server how to translate the input number into the required format. The brackets indicate that either 0 or 1 instance is required. You must create an outpattern
for number translation rules.
•
name = *( ALPHA / DIGIT / "-")
Where:
ALPHA indicates that letters can be used in the name for the rule option.
DIGIT indicates that numbers can be used in the name for the rule option.
“-”
indicates that a dash (
-
) can also be used in the option name—for example, rule-01.
•
in-pattern = 1*(digit-part / abstract-group)
Where: digit-part
represents numbers. SIP Server uses this when selecting the most appropriate rule from the entire dial plan. abstract-group
represents one or more letters with each letter representing one or more numbers. SIP Server uses this when transforming a dial string.
For example,
[1-9] is the digit-part
(representing a range of numbers) and
ABBB
is the abstract-group for in-pattern=[1-9]ABBB
.
• out-pattern = 1*(symbol-part / group-identifier) *param-part
SIP Server—Deployment Guide 181
Chapter 5: SIP Server Feature Support Class of Service
Where: symbol-part
represents digits, symbols, or a combination. Symbols are rarely used. They are not used in the United States.
group-identifier
are letters that represent groups of numbers. A letter in the out-pattern
represents one or more digits, based on the number of times the letter is used in the in-pattern.
*param-part
represents an additional parameter, such as phonecontext.
Remember that an asterisk (*) means that 0 to an infinite number of these are acceptable.
For example, in rule-04; in-pattern=1AAABBBCCC;out-pattern=91ABC, 91 is the symbol-part
;
A, B,
and
C
are group-identifiers in the out-pattern, each representing three digits, since there are three instances of each in the in-pattern
.
Note:
Prefix an out-pattern
value with a plus sign (+) for the inbound rule when the output must be in a global form (E.164 format).
•
digit-part = digits / range / sequence
Where: digits
are numbers 0 through 9.
range
is a series of digits—for example, 1–3.
sequence is a set of digits.
•
symbol-part = digits / symbols
Where: digits are numbers 0 through 9.
symbols include such characters as
+, -,
and so on.
•
range = "[" digits "-" digits "]" group-identifier
Where:
"[" digits "-" digits "]"
represents the numeric range—for example,
[1-2]
.
group-identifier
represents the group to which the number range is applied.
For example,
[1-2]
applies to group identifier
A
for in-pattern=[1-
2]ABBB.
When SIP Server evaluates the rule to determine if it matches the number, it examines whether the first digit of the number, identified as group-identifier A
, is
1
or
2.
•
sequence = "[" 1*(digits [","] ) "]" group-identifier
Where:
"
[" 1*(digits [","] ) "]"
represents a sequence of digits, separated by commas, and bracketed. SIP Server requires that each digit set have the same number of digits. For example, in
[415,650]
the sets have three digits.
182 Framework 8.1
Chapter 5: SIP Server Feature Support Class of Service
group-identifier
represents the group to which the number sequence is applied.
For example, in in-pattern=1[415,650]A*B, [415,650]
applies to group-identifier A
. When SIP Server evaluates the rule to determine if it matches the number, it examines whether the three digits ( groupidentifier A
) following the
1
in the number are
415 or
650.
•
abstract-group = fixed-length-group / flexible-length-group
Where: fixed-length-group
specifies a group composed of a specific number of digits, and determined by the number of times the group identifier is included in the in-pattern.
For example, for in-pattern=1AAABBBCCCC, there are three digits in group
A
and
B,
but four in group
C.
When you create an out-pattern
, you include the group identifier only once, because the in-pattern
tells SIP Server how many digits belong in that group. For example, rule-04
) is in-pattern=1AAABBBCCCC; out-pattern=91ABC.
flexible-length-group
specifies a group composed of 0 or more digits in the group represented by the group-identifier.
For example, in in-pattern=1[415,650]A*B, *B
represents the flexible length group containing the remaining digits in the number.
The component
abstract-group
is used only for the in-pattern
.
•
fixed-length-group = 1*group-identifier
See the earlier explanation under abstract-group.
•
flexible-length-group = "*" group-identifier
See the earlier explanation under abstract-group.
•
param-part = ";" param-name "=" param-value
Where:
“;”
is a required separator element.
param-name
is the name of the parameter.
“=”
is the next required element.
param-value
represents the value for param-name.
•
param-name = "ext" / "phone-context" / "dn"
Where:
“ext”
represents the extension.
“phone-context”
represents the value of the phone-context
option configured on the switch.
“dn”
represents the directory number.
•
param-value = 1*ANYSYMBOL
Where:
ANYSYMBOL
represents any number, letter, or symbol with no restrictions.
SIP Server—Deployment Guide 183
Chapter 5: SIP Server Feature Support Class of Service
•
group-identifier = ALPHA
•
digits = 1*DIGIT
•
symbols = 1*("-" / "+" / ")" / "(" / ".")
Transformation
The transformation algorithm consists of two phases:
1. Input number parsing based on in-pattern.
2. Output number construction based on out-pattern
and the parsed input string.
The first phase consists of selecting all group elements from in-pattern
(the abstract-group, range,
and choice
parameters), and assigning them a corresponding group of digits from the input number. There are three kinds of such assignment:
•
Explicit—For ranges, sets, and fixed-length-groups where the length and position of the group is set explicitly in in-pattern.
•
Positional—For flexible-length-groups; the digits are selected exclusively based on their position with respect to other groups.
•
Analytical—For entities; the digits are selected based on some kind of analytical processing.
Examples
These are examples of how SIP Server applies the rules configured above to various input numbers.
Example 1
Table 40: Class of Service
Input Number in-pattern out-pattern
914159131472 9*A +A
011441581234567 011#CABBB*D +A-(B)-D
1472
911
14159131472
16503570622
[1-8]ABBB
AAA
AB
9A
Output Number
+14159131472
+44-(158)-1234567
1472
9911
*A9131472 80409131472 80409131472
1[415,650]A*B B 3570622
184 Framework 8.1
Chapter 5: SIP Server Feature Support Class of Service
rule-01 rule-02 rule-03 rule-04
Example 2
rule-01=in-pattern=[1-8]ABBB;out-pattern=AB rule-02=in-pattern=AAAA;out-pattern=A rule-03=in-pattern=1[415,650]A*B;out-pattern=B rule-04=in-pattern=1AAABBBCCCC;out-pattern=91ABC rule-05=in-pattern=*A913BBBB;out-pattern=80407913B rule-06=in-pattern=011#CA*B;out-pattern=9011AB
SIP Server receives input number
2326.
As a result of the rule selection process, SIP Server determines that the matching rule is rule-01: name=rule-01;in-pattern=[1-8]ABBB;out-pattern=AB
The matching count for this rule is
1,
because Group
A
matches the digit
2.
As a result of the parsing process, SIP Server detects two groups: Group
A = 2 and Group
B = 326.
SIP Server formats the output string as
2326.
SIP Server receives input number
9122.
As a result of the rule selection process, SIP Server determines that the matching rule is rule-02: name=rule-02;in-pattern=AAAA;out-pattern=A
The matching count for this rule is
0;
however, the overall length of the input number matches that of the in-pattern
configuration.
As a result of the parsing process, SIP Server detects one group:
Group
A = 9122.
SIP Server formats the output string as
9122.
SIP Server receives input number
16503222332.
As a result of the rule selection process, SIP Server determines that the matching rule is rule-03: name=rule-03;in-pattern=1[415,650]A*B;out-pattern=B
The matching count for this rule is
4,
because the first digit matches and all three digits in Group
A
match.
As a result of the parsing process, SIP Server detects two groups:
Group
A = 650
and Group
B = 3222332.
SIP Server formats the output string as
3222332.
SIP Server receives input number
19253227676.
As a result of the rule selection process, SIP Server determines that the matching rule is rule-04: name=rule-04;in-pattern=1AAABBBCCCC;out-pattern=91ABC
The matching count for this rule is
1,
because the first digit matches.
SIP Server—Deployment Guide 185
Chapter 5: SIP Server Feature Support Class of Service
rule-05 rule-06
As a result of parsing process, SIP Server detects three groups: Group
A = 925,
Group
B = 322,
and Group
C = 7676.
SIP Server formats the output string as
919253227676.
SIP Server receives input number
4089137676.
As a result of the rule selection process, SIP Server determines that the matching rule is rule-05: name=rule-05;in-pattern=*A913BBBB;out-pattern=80407913B
The matching count for this rule is
3,
because three digits match.
As a result of the parsing process, SIP Server detects two groups:
Group
A = 408
and Group
B = 7676.
SIP Server formats the output string as
804079137676.
SIP Server receives input number
011441112223333.
As a result of the rule selection process, SIP Server determines that the matching rule is rule-06: name=rule-06;in-pattern=011#CA*B;out-pattern=9011AB
The matching count for this rule is
3,
because three digits match.
As a result of the parsing process, SIP Server detects two groups: Group
A = 44 and Group
B = 1112223333.
SIP Server formats the output string as
9011441112223333.
Call Rejection by Out-Dialing Rules
A call attempt can be rejected by the out-dialing rules. To indicate this condition, SIP Server generates an
EventError
response to the corresponding request, with the reason code
Invalid Destination DN (415).
Ring-Through Rules
The ring-through rules define whether a call is sent to an agent or a device. The following ring-through rules are supported by SIP Server:
•
Reject call when a device is already in a call
This rule is enforced by the
Switch
object-level configuration option
within COS.
•
Reject call when an agent is not ready on a device
This rule is enforced by the
Switch
object-level configuration option
Call Rejection by COS Ring-Through Rules
A call attempt can be rejected by the COS ring-through rules. To indicate this condition, SIP Server generates an
EventError
message to the corresponding
186 Framework 8.1
Chapter 5: SIP Server Feature Support Class of Service request, with the reason code
Destination Invalid State (93)
. When rejecting 1pcc calls, SIP Server generates a SIP
603 Decline
error response.
Feature Configuration
describes how to enable Class of Service.
Table 41: Configuring Class of Service
Objective
1. Configure a COS DN.
2. Assign COS to a device.
3. Assign COS to an agent.
Related Procedures and Actions
Configure a DN of type
Voice over IP Service to represent the
COS entity itself. This DN should have outbound dialing rules and
ring-through rules specified in the options. See “Configuring a COS
Assign the COS DN to one or multiple DNs of type
Extension
or
ACD Position
within the same
Switch
configuration object. See
“Assigning COS to a Device” on page 188
Assign the COS DN to one or multiple Agent Logins. See
“Assigning COS to an Agent” on page 189
.
Procedure:
Configuring a COS DN
Start of procedure
1. Create a COS DN under the SIP Server
Switch
object with the type of
Voice over IP Service.
2. On the
Annex
tab of the COS DN object, in the
TServer section, set the configuration option service-type
to cos.
3. On the
Annex
tab of the COS DN object, in the
TServer section, specify the outbound dialing rules. Each rule is defined using the configuration option named
out-rule-1 = in-pattern=411;out-pattern=9411
Rules must be numbered sequentially—for example, out-rule-1, out-rule-2,
and so on.
4. On the
Annex
tab of the COS DN object, in the
TServer section, specify the ring-through rules—for example: reject-call-incall = true reject-call-notready = true
illustrates a sample configuration for the COS DN with outbound dialing rules and ring-through rules specified.
SIP Server—Deployment Guide 187
Chapter 5: SIP Server Feature Support Class of Service
Figure 20: Configuring COS DN: Sample Configuration
5. When finished, click
Apply
to save your configuration.
End of procedure
Assigning COS to a Device
COS is assigned to a device by associating the COS DN with the device DN of type
Extension
or
ACD Position.
In the
TServer
section on the
Annex
tab, add the cos
configuration option, with the value set to the name of the COS DN.
illustrates a sample configuration of the device DN with COS assigned.
188
Figure 21: Assigning COS to a Device: Sample Configuration
COS may be assigned to multiple DNs by using the
Manage Options
command in Configuration Manager.
Framework 8.1
Chapter 5: SIP Server Feature Support Class of Service
Assigning COS to an Agent
COS is assigned to an agent by associating the COS DN with the
Agent Login object. In the
TServer
section on the
Annex
tab of the
Agent Login
object, add the cos
configuration option, with the value set to the name of the COS DN.
illustrates a sample configuration of the
Agent Login
object with
COS assigned.
Figure 22: Assigning COS to an Agent Login: Sample Configuration
Checking the Destination Availability
SIP Server uses COS to analyze the availability of the destination in the following order:
1. SIP Server checks if an agent is logged in on the extension.
2. If the agent is logged in, the Agent Login COS is applied.
3. If the agent is not logged in on the device, or COS is not configured for the
Agent Login, SIP Server checks if COS is configured for the device.
4. If COS is not configured for the Agent Login, SIP Server uses the options configured for the device.
5. If COS is configured for the device, SIP Server applies the COS.
6. If COS is not configured for the device, SIP Server checks if options reject-call-incall
and reject-call-notready
are specified for the device directly (without using COS).
7. If the reject-call-incall
and reject-call-notready
options are specified,
SIP Server uses these options.
8. If none of the preceding apply, SIP Server considers the destination available.
SIP Server—Deployment Guide 189
Chapter 5: SIP Server Feature Support Consolidated Error Response
Consolidated Error Response
SIP Server supports mapping a range of error messages from multiple sources to a single consistent error message that it sends to the network client. For example, in environments with several Genesys Voice Platform instances, where SIP Server sits in front of GVP (GVP Resource Manager and Genesys
Media Server), SIP Server can translate its own error responses, as well as any error messages that it receives from these GVP instances, into a common error response that it sends to the network client—typically a
503 Service
Unavailable
response. The network client (proxy or UAC) receiving the
503
Service Unavailable
message can then forward the original request to an alternate server—for example, to contact an alternate GVP instance to service the customer.
How It Works
Depending on which method of error detection is enabled, SIP Server consolidates error responses differently.
Passive Out-Of-Service Detection
1. SIP Server forwards a SIP
INVITE
request from the network client to GVP.
2. If GVP fails to respond, the
INVITE
request will timeout.
3. The
Trunk
DN representing the network client is configured to pass the error response to the client ( sip-busy-type
is set to
2
).
4. SIP Server suppresses the busy tone and marks the DN as out-of-service.
With consolidated error response configured on either the DN or
Application-level ( sip-error-conversio n is enabled), SIP Server translates its own error response to the configurable error response. For example, if
SIP Server does not receive a response to an
INVITE
request that it sends to
GVP, SIP Server can be configured to translate the
603 Decline
message that it generates into a
503 Service Unavailable
message that it sends to the client.
Active Out-of-Service Detection
1. SIP Server is configured for active out-of-service detection; it periodically sends
OPTIONS
messages to GVP, testing its availability. If any particular
GVP instance is unavailable, SIP Server will mark that DN (
Trunk
DN as out-of-service.
2. On receiving an
INVITE
request from the network client, SIP Server checks if there are any active GVP DNs that can be used to service the call.
190 Framework 8.1
Chapter 5: SIP Server Feature Support Consolidated Error Response
3. If no active DN is found, by default SIP Server normally sends a
404 Not
Found
error response. However, with consolidated error conversion enabled
( sip-error-conversion
is set to the desired error response), SIP Server translates the
404 Not Found
message to the configured error response—typically
503 Service Unavailable
—and sends that to the client network.
Feature Configuration
describes how to configure a consolidated error response.
Table 42: Configuring Consolidated Error Response
Objective
Configure error conversion for
Active OOS Detection.
Configure error conversion for
Passive OOS Detection.
Configure for individual DNs.
Related Procedures and Actions
In the SIP Server
Application
object, go to the
Options
tab >
TServer
section and configure the following option:
•
—Enter a comma-separated list of errorin/error-out pairs.
For example,
404=503;603=503
In the SIP Server
Application
object, go to the
Options
tab >
TServer
section and configure the following option:
•
—Enter the value
0=503
.
• Suppress the busy tone for network client.
In the
Trunk
DN for the network client, under TServer section configure the following:
2
.
• Configure the consolidated error response.
In either the DN that issues the error (for example, GVP
Trunk
DN) or in the SIP Server
Application
object, configure the following:
—Enter a comma-separated list of errorin/error-out pairs.
SIP Server—Deployment Guide 191
Chapter 5: SIP Server Feature Support Control of SIP Response Code from within Routing Strategy
Control of SIP Response Code from within
Routing Strategy
SIP Server supports the ability to configure how SIP response codes are sent from SIP Server to a routing strategy, and from SIP Server to the original caller:
•
From SIP Server to routing strategy—The option
whether SIP Server sends a SIP Response code instead of a T-Library error code, in cases of an
EventError
.
•
From SIP Server to original caller—When rejecting calls from a routing strategy, you can add the key-value pair sip-status-code
to specify which
SIP Response (in the
>=400
to
<700
range) that SIP Server will send back to the caller.
Feature Configuration
describes how to enable this feature.
Table 43: Configuring SIP Error Response Codes
Objective Key Procedures and Actions
Send SIP Response code to routing strategy.
In the SIP Server
Application > Options > TServer section, configure the following option:
•
false
.
Specify SIP Response code to be sent back to caller.
1. Create a routing strategy that adds the sip-statuscode to the
Extensions
attribute of rejected calls.
2. Configure the SIP Server Application with the following options:
—Set this option to false
.
true
.
For details, see
Procedure: Controlling SIP Response
Codes from a Routing Strategy .
192 Framework 8.1
Chapter 5: SIP Server Feature Support Control of SIP Response Code from within Routing Strategy
Procedure:
Controlling SIP Response Codes from a Routing
Strategy
Start of procedure
1. In Interaction Routing Designer, create an inbound routing strategy that determines under what criteria you want to accept or reject a call. For example, if no agents are currently available, the call is rejected.
2. In the rejection path of the routing strategy, use a function block to set the
Extension attribute with the key-value pair sip-status-code
, where the value equals the SIP Response code you want to send. For example, to configure the Extension so that SIP Server sends a
486 Busy Here
message on call rejection, configure the
ExtensionAttach
function as follows:
ExtensionAttach[‘{d}sip-status-code’,’486’]
3. Connect the
ExtensionAttach
function to another function block that rejects the call. For example, use the
TRoute
function block with the routetype set to reject
:
TRoute[“,”,RouteTypeReject,”]
4. When a call is initially placed, you may receive a
180 ringing
message in response. To suppress ringing, in the
TServer
section of the SIP Server
Application
object, set ringing-on-route-point
to false
.
Note:
Setting
ringing-on-route-point
to false
suppresses automatic ringing sent by SIP Server, allowing you to specify a different response—for example, a busy signal—from the routing strategy
5. To configure SIP Server to use the specified response code (configured in
Step 2 ) instead of the standard error code, in the
TServer
section of the SIP
Server application, set
true
.
End of procedure
SIP Server—Deployment Guide 193
Chapter 5: SIP Server Feature Support Customizing Music on Hold and in Queue
Customizing Music on Hold and in Queue
This section covers the following topics:
•
“Playing Music to Calls on Hold” on page 194
•
“Playing Music to Calls in Queue” on page 198
Playing Music to Calls on Hold
Genesys Media Server can play different media files for various contact center music on hold treatments. For example, Genesys Media Server plays a file that is associated with an agent DN if the agent places the call on hold.
Enabling Music on Hold
You can enable music on hold—as well as define the file to be played—using any of several, prioritized methods:
•
From an agent DN—When the agent places the call on hold, the defined file will be played to the caller or the conference.
•
From a client request—Key-value pairs in the
Extensions
attribute of the client request can specify the file that is to be played for this and subsequent calls. These extensions can be included in the following requests:
THoldCall
TAlternateCall
TInitiateTransfer
TInitiateConference
Typically, the agent logged in to an agent desktop manually selects the music file that the agent wants to play to the caller when the caller is placed on hold.
•
From the SIP Server Application—The default file that is configured on the application is played if no other configured filename is found.
Customizing Music on Hold
Starting with release 8.1.102.31, SIP Server lets you customize music for music-on-hold treatments. When the music-on-hold feature is activated, it applies to scenarios when the hold action is performed by an agent within the duration of the call explicitly (by
THoldCall
), or implicitly (by
TAlternateCall
,
TInitiateTransfer
, or
TInitiateConference
).
When custom music-on-hold is enabled on the Routing Point with the
configuration option, or with the music-on-hold
AttributeExtensions
of
TRouteCall
, it remains attached (sticks) to the call until the call is released. If a
TRouteCall
request arrives with an empty value of the music-on-hold
key in
AttributeExtensions
, the custom music-on-hold
194 Framework 8.1
Chapter 5: SIP Server Feature Support Customizing Music on Hold and in Queue stickiness is removed from the call. If call routing fails, the custom music-onhold setting is rolled back to the previous value.
The value of the music-on-hold
option is attached to calls distributed via this
Routing Point and used for playing the music-on-hold later.
option is set for an Agent Login object, the setting
applies only to a call established by the agent who activated the Hold operation.
Custom Music-on-hold in Conferences and Transfers
The custom music-on-hold setting is not applied to conferences and not shared when a consultation call is merged with the main call. However, the custom music-on-hold setting remains associated with the call, and if only two participants are left on the call, the custom music-on-hold setting will be applied if the caller is placed on hold. When a new party joins the conference, the custom music-on-hold setting is not applied.
For multi-site conferences support, SIP Servers must propagate full
information about call parties. See “Providing Call Participant Info” on page 349
for information on how to enable it.
The custom music-on-hold setting is transferred with the call, which includes call routing, single-step transfers, two-step transfers, and call forwarding. In multi-site transfers, the ISCC connection is used.
If a call is transferred through a Routing Point that has a custom music-on-hold setting, the new music-on-hold setting will be applied to the next Hold scenario.
Media File Priority
The following settings determine the order of priority—from highest to lowest—in which a music file is played for a call on hold:
•
The
AttributeExtensions
in
THoldCall, TAlternateCall,
TInitiateTransfer, TInitiateConference
requests, which initiate the Hold operation for a call.
•
The
key of
AttributeExtensions
in
TRouteCall
(if there are several
TRouteCall
requests for this call containing this key, the value from the last one is applied).
•
The
option on a Routing Point DN (if a call is passed through several Routing Points containing this option, the value from the last one is applied).
•
The
option on an Agent Login level.
•
The
option on an agent's Extension DN level.
•
The
option on a SIP Server Application level.
SIP Server—Deployment Guide 195
Chapter 5: SIP Server Feature Support Customizing Music on Hold and in Queue
Configuring Music on Hold
Table 44 describes the different configuration methods for playing music-onhold media files.
Table 44: Configuring Music on Hold
Objective
Configure client requests.
Related Procedures or Actions
Configure the T-Server client to include the following key-value pairs in the
Extensions
attribute of the client request, as required:
•
—Specify the file name for music on hold for the call.
Applies to:
•
THoldCall
•
TAlternateCall
•
TInitiateTransfer
•
TInitiateConference
Configure an agent DN.
Configure an Agent Login.
Configure a
TRouteCall
request.
Configure a Routing Point DN.
On the agent’s Extension DN, in the
TServer
section, you can configure the following options as required:
•
true
to enable music on hold for this DN.
•
—Specify the music file that is to be played
when this DN places the call on hold.
On the Agent Login, in the
TServer
section, you can configure the following option as required:
•
—Specify the music file that is to be played
when this agent places the call on hold.
You can specify the music-on-hold
TRouteCall
. If there are several
TRouteCall
requests for this call containing this key, the value from the last one is applied.)
On the Routing Point DN, in the
TServer
section, you can configure the following option as required:
•
—Specify the music file that is to be played
s attached to calls distributed via this Routing Point and used for playing the music-on-hold later.
If a call is passed through several Routing Points containing this option, the value from the last one is applied.
196 Framework 8.1
Chapter 5: SIP Server Feature Support Customizing Music on Hold and in Queue
Table 44: Configuring Music on Hold (Continued)
Objective
Configure the SIP Server
Application.
Related Procedures or Actions
In the SIP Server Application, the
TServer
section, configure the following options:
•
true
to enable default music on hold from the application.
•
—Enter the directory and filename of the default
music-on-hold file to be played in case no other settings are found.
•
—Enter the directory and filename of the application-wide default file that is to be played to the other participants (typically a silent audio file) when an agent places the conference on hold.
•
—Enter the directory and filename of the
application-wide default file that is to be played when a call is waiting in an ACD Queue.
Feature Limitations
The following limitations apply to music-on-hold treatments:
•
In multi-site deployments with the music-on-hold setting enabled in
AttributeExtensions
, the iscc-pass-extensions key in
AttributeExtensions
must not be set to a value of local
, because it prevents extensions being passed through ISCC to a remote site.
•
In Business Continuity (BC) deployments, the custom music-on-hold setting is propagated with a call transfer in DR-forward scenarios only if the Call Overflow feature is enabled. That is, the following SIP Server
Application options must be set in the extrouter
section:
cof-feature=true default-network-call-id-matching=sip
SIP Server—Deployment Guide 197
Chapter 5: SIP Server Feature Support Customizing SIP Header Formats
Playing Music to Calls in Queue
Genesys Media Server can provide each queue on a single SIP Server with its own particular media file. Genesys Media Server plays a file that is associated with an
ACD Queue
DN while the call is in the queue.
Table 45: Configuring to Play Music to Calls in Queue
Objective
Configure an ACD Queue.
Configure the SIP Server
Application.
Related Procedures or Actions
On the
ACD Queue
DN, in the
TServer
section, you can configure the following options as required:
•
true
to enable music on hold for calls that are queued on this DN.
•
—Specify the music file that is to be played
when a call is queued on this DN.
Note: In previous releases, the option music-in-queue-file was used to specify the file on the
ACD Queue
DN. This option has been deprecated at the DN-level.
In the SIP Server Application, the
TServer
section, configure the following option:
•
—Enter the directory and filename of the
application-wide default file that is to be played when a call is waiting in an ACD Queue.
Customizing SIP Header Formats
SIP Server provides some flexibility for how different SIP headers are formed, depending on the needs of specific deployments.
•
“Enabling Additional Parameters in Request-URI” on page 198
•
“Enabling Server and User-Agent Headers” on page 200
•
“Contact Header Handling Options” on page 201
•
“Diversion Header” on page 203
•
“Early Media Private Header” on page 208
•
Enabling Additional Parameters in Request-URI
SIP Server can be configured to include additional parameters in the
Request-
URI
, in cases where the deployment requires it. For example, it can add the user=phone
in the
Request-URI
of
INVITE
requests to a particular DN.
198 Framework 8.1
Chapter 5: SIP Server Feature Support Customizing SIP Header Formats
How It Works
In scenarios that require SIP Server to start a new
INVITE
dialog, SIP Server checks the configuration of the destination DN. If the option sip-uri-params
is configured, SIP Server adds the additional parameters, as specified by this option, to the
Request-URI
of the
INVITE
request. No other SIP requests are affected. This feature is available for any DN type and affects any initial
INVITE
sent to that particular DN.
SIP Server supports this feature for both 1pcc and 3pcc calls.
SIP Server can apply this functionality for any of the following 3pcc requests:
•
TMakeCall
•
TMakePredictiveCall
•
TRouteCall
•
TRedirectCall
•
TInitiateConference
•
TInitiateTransfer
•
TSingleStepTransfer
•
TSingleStepConference
Feature Configuration
describes how to enable additional parameters in the
Request-URI
, as required by your deployment.
Table 46: Enabling Additional Request-URI parameters
Objective
Configure the
Trunk
DN.
Configure
Voice over IP
Service
DNs.
Related Procedures and Actions
In the outbound
Trunk
DN >
TServer
section, set the
option to the value of the URI parameters you want to add.
For example, user=phone
SIP Server will include the new parameters in any outbound
INVITE
it sends through this Trunk.
In the
Voice over IP Service
DN (for example, a softswitch or musicon-hold DN) >
TServer
section, set the sip-uri-params
option to the value of the URI parameters you want to add.
SIP Server will include the new parameters in any initial
INVITE
it sends to this service DN.
SIP Server—Deployment Guide 199
Chapter 5: SIP Server Feature Support Customizing SIP Header Formats
Table 46: Enabling Additional Request-URI parameters (Continued)
Objective
Configure
Extension
DNs.
Related Procedures and Actions
In the
Extension
DN >
TServer
section, set the
the value of the URI parameters you want to add.
SIP Server will include the new parameters in any initial
INVITE
it sends to this
Extension
DN.
Note for IMS deployments:
SIP Server ignores this option in IMS deployments.
Use option
Enabling Server and User-Agent Headers
SIP Server supports inserting the
Server
header into all replies that it sends and the
User-Agent
header into all requests. For the
Server
header, you can configure this functionality at the Application level only. For the
User-Agent header, you can configure this functionality on either the Application or the
DN level. For non-
INVITE
dialogs, only the Application-level setting applies.
You can also specify a
User-Agent Extension
attribute by using the following
T-Library requests:
•
TMakeCall
•
TMakePredictiveCall
•
TSingleStepTransfer
•
TSingleStepConference
•
TInitiateTransfer
(applies to consultation calls only)
•
TInitiateConference
(applies to consultation calls only)
Setting the
User-Agent
by using the
Extension
Attribute overrides any values that you set in the configuration options.
Feature Configuration
describes how to enable
Server
or
User-Agent
headers.
200 Framework 8.1
Chapter 5: SIP Server Feature Support Customizing SIP Header Formats
Table 47: Enabling Server and User-Agent Headers
Objective
Enable the
Server
header.
Enable the
User-Agent
header.
Related Procedures and Actions
In the SIP Server
Application
object >
Options
tab >
TServer section, configure the following option:
•
—Enter a string or the special character
*
.
The string can contain the placeholders
$VERSION$, $APP-NAME$
OR
The special value
*
is equivalent to
Genesys SIP Server
$VERSION$ ($APP-NAME$
)
You can enable the
User-Agent
header by using any of the following configurations, listed in order of priority:
1. Extensions Attribute
Add the
User-Agent
key-value pair to the
Extensions
Attribute of the supported T-Library request.
2. DN-level
In the
TServer
section of the individual DN, configure the following option:
—Enter a string or the special character
*.
The string can contain the placeholders
$VERSION$, $APP-NAME$
OR
The special value
*
is equivalent to
Genesys SIP Server
$VERSION$ ($APP-NAME$
)
Note: The DN-level setting applies only to
INVITE
dialogs.
3. Application-level
Configure
Note: This setting applies to all dialogs, including
INVITE dialogs.
Contact Header Handling Options
SIP Server supports two methods for handling the
Contact
header in SIP
REGISTER
requests:
•
SIP Server formats the
Request-URI
in the
INVITE
request that it sends to an endpoint by using an exact match to the value of the URI that is obtained from the
Contact
header of the SIP
REGISTER
request. To use this method,
option to true
.
SIP Server—Deployment Guide 201
Chapter 5: SIP Server Feature Support Customizing SIP Header Formats
SIP Server1
11.22.33.44
•
SIP Server disregards the user-name part of the URI obtained from the
Contact
header of the SIP
REGISTER
request. It replaces the user-name part with the DN name when formatting the
Request-URI for the
INVITE
that it sends to an endpoint. To use this method, set the sip-preserve-contact option to the default value of false
.
When multiple instances of SIP Server are deployed behind a session border control (SBC) device, it is possible for two SIP endpoints at different locations to have the same DN number. When it sends
REGISTER
requests to SIP Server on behalf of these endpoints, the SBC might add session information in the
Contact
header. If you set sip-preserve-contact
to true
, SIP Server will extract the cookie from the
REGISTER
message, then include it in the
INVITE request that it sends to the endpoint through the SBC. The SBC then uses the session information to determine the correct endpoint.
Sample Call Flow Scenario
shows a multi-site scenario that involves an SBC, and in which agents and callers at different locations have the same DN number.
Site 1
To SIP Server1
SIP Server2
Caller2
11.22.33.45
SBC
To SIP Server1
12.34.56.89
Agent A
To SIP Server2
Caller1
Gateway
To SIP Server2
Site 2
Agent B
Figure 23: SIP Server with Cookie Persistence Enabled
In this case, when the SBC forwards a
REGISTER
request from an agent DN to
SIP Server, the SBC translates the contact information from the original DN into contact information that represents the SBC.
For example, a
REGISTER
request that is sent by Agent A from Site—identified in the request to the SBC as
—arrives at the SIP Server from the SBC with the contact info
. SBC overrides the
CONTACT
header and adds session information (a cookie) that uniquely identifies the agent (
-q3uq53j2hht32 for Agent A in the preceding example). If sip-preserve-contact
is set to true
, SIP Server preserves the information in this cookie, then passes it back to the SBC when it is time to
202 Framework 8.1
Chapter 5: SIP Server Feature Support Customizing SIP Header Formats send an
INVITE
to the agent endpoint (
INVITE sip:[email protected]:5060 SIP/2.0
).
Feature Configuration
describes how to enable the
Contact
header handling.
Table 48: Configuring Contact Header Handling
Objective Related Procedures and Actions
Configure for all DNs.
In the SIP Server
Application
>
Options
>
TServer
section:
• To strip the
Contact
header—Set
to the default false
.
• To preserve the
Contact
header—Set sip-preserve-contact
to true
.
Configure for individual DNs. In the SIP Server
Switch
>
DNs folder > individual DN >
Options
>
TServer
section:
• To strip the
Contact
header—Set
to the default false
.
• To preserve the
Contact
header—Set sip-preserve-contact
to true
.
The DN-level setting takes precedence over the Application-level setting.
Diversion Header
For redirected calls, SIP Server supports the
Diversion
header—a SIP extension that provides the ability for the called party to identify where a particular call was diverted and why. SIP Server can process the
Diversion header as follows:
•
Forward the header to an inbound destination.
•
Add a new header in cases of internal call redirection.
Forwarding the Diversion Header
SIP Server can forward a received
Diversion
header directly in the
INVITE
to a destination DN, or by mapping the header to a T-Library message that SIP
Server sends to URS, making this information available to the routing strategy.
Forwarding to a Destination DN
If an incoming
INVITE
request includes the
Diversion
header, SIP Server can include this header in the subsequent outgoing INVITE that it sends to the destination DN. This behavior is specified by the sip-proxy-headers-enabled option. This option takes precedence over the sip-enable-diversion
option. If
SIP Server—Deployment Guide 203
Chapter 5: SIP Server Feature Support Customizing SIP Header Formats sip-proxy-headers-enabled
is disabled (set to the non-default false
), all SIP headers will not be forwarded (it does not matter what the setting is for sipenable-diversion
).
Mapping to T-Library Messages
If the incoming
INVITE
request to a
Routing Point
DN contains the
Diversion header, SIP Server can map this header to UserData in the T-Library events
EventQueued
or
EventRouteRequest
. This makes the information available to the routing strategy for intelligent use. To enable this mapping, you must create a new userdata-n
option in the
INVITE
section of the SIP Server application.
Sample mapping of
Diversion
header from incoming
INVITE
to subsequent
TEvent
is as follows:
INVITE to Routing Point
INVITE sip:[email protected]:5060 SIP/2.0
From: <sip:[email protected]:21001>;tag=0396021E-DB9C-488E-9EC6-
68E6C69263CF-1
To: sip:[email protected]:5060
Call-ID: [email protected]
CSeq: 1 INVITE
Content-Length: 147
Content-Type: application/sdp
Via: SIP/2.0/UDP 127.0.0.1:21001;branch=z9hG4bKB67C60B1-6106-4DD2-
904C-AD8F8D70D2A6-1
Contact: <sip:172.24.129.75:21001>
Diversion: <sip:[email protected]:5060>;reason=unconditional
EventQueued Message
MessageEventQueued
AttributeEventSequenceNumber000000000000008e
...
AttributeDNIS'5000'
AttributeUserData[74]00 01 00 00..
'Diversion''<sip:[email protected]:5060>;reason=unconditional'
AttributeCallUUID'U4BIG099V94A72Q2MIK0SUFLK4000000'
For more detailed information about mapping headers to T-Library messages,
see “Mapping SIP Headers and SDP Messages” on page 276
.
Adding the Diversion Header
SIP Server can also add a new
Diversion
header in the case of certain internal call diversions—like alternate routing to a default DN—or if asked to by the
URS routing strategy.
204 Framework 8.1
Chapter 5: SIP Server Feature Support Customizing SIP Header Formats
Some situations where SIP Server can add a new
Diversion
header to an
INVITE
are:
•
Dial plan—When unattended calls are diverted to alternate DNs specified using additional parameters in the dial plan.
•
Alternate routing—Calls can be diverted to alternate DNs in response to a number of different call scenarios.
•
No-Answer Supervision—Based on the availability of supervised agents or
Extension
DNs, SIP Server can divert the call to a sequence of overflow destinations.
•
Call redirection—When the agent redirects a call to other DNs. Redirection can be either 1pcc or 3pcc.
•
Call forwarding—When the call is forwarded to another DN (1pcc and
3pcc).
•
Mapping from T-Library Request—The routing strategy can be designed to include Diversion parameters in a T-Library request, which SIP Server then maps to the resulting
INVITE
request or
302 Moved Temporarily message.
Mapping from T-Library Request
You can design the routing strategy to include Diversion-related parameters in the
Extension
attribute in T-Library requests. SIP Server can then map these parameters to a
Diversion
header in the resulting
INVITE
or
302 Moved
Temporarily
. In this case, the routing strategy must be designed to include the
Diversion key-value pair in the
SIP_Headers
extension of the T-Library request.
The routing strategy can either create the Diversion header based on other headers mapped from the incoming
INVITE
request, or it can be configured directly.
Note:
The Diversion header should follow the syntax described in RFC 5806
“Diversion Indication in SIP”.
TRouteCall
INVITE
Sample mapping from
TRouteCall
to SIP
INVITE
is as follows:
MessageRequestRouteCall
AttributeThisDN'5000'
AttributeConnID007001e08c992001
AttributeOtherDN'7102'
AttributeLocation''
AttributeExtensions[125]00 03 00 00..
'SIP_HEADERS''Diversion'
'Diversion''<sip:[email protected]:5060>;reason=unconditional'
AttributeDNIS''
AttributeRouteType1(RouteTypeDefault)
INVITE sip:[email protected]:7102 SIP/2.0
SIP Server—Deployment Guide 205
Chapter 5: SIP Server Feature Support Customizing SIP Header Formats
From: sip:[email protected]:21001;tag=9A8776B3-0A32-4089-83AE-
7CE09D79F7C9-2
To: <sip:[email protected]:5060>
...
Contact: <sip:[email protected]:5060>
Diversion: <sip:[email protected]:5060>;reason=unconditional
For more information about mapping from T-Library to SIP requests, see
“Using SIP_HEADERS and SIP_REQUEST_PARAMETERS” on page 284 .
Feature Configuration
describes how to enable processing of the
Diversion
header.
Table 49: Configuring Diversion Header Support
Objective Related Procedures and Actions
Forwarding the Diversion Header
Forward all Diversion headers.
In the SIP Server Application, make sure that
true
.
By default, SIP Server forwards all headers, including
Diversion
, in the subsequent
INVITE
.
Map to T-Library request.
In the SIP Server
Application
object, configure the following:
• In the
Options
tab, create a new section called
INVITE
.
• In this section, create a new option userdata-n.
• For the value of this option, enter
Diversion
.
SIP Server will include the
Diversion
parameter in the
UserData
Attribute of the
EventRouteRequest
or
EventQueued
.
206 Framework 8.1
Chapter 5: SIP Server Feature Support Customizing SIP Header Formats
Table 49: Configuring Diversion Header Support (Continued)
Objective Related Procedures and Actions
Adding the Diversion Header
Enable for dial plan.
Enable for No-Answer
Supervision.
Calls can be diverted based on the routing outcome of a dialing rule.
To define where these calls will be diverted, the dialing rule uses the following parameters:
• ontimeout
• onbusy
• ondnd
To include the
Diversion
header, configure the destination DN defined in these parameters as follows:
• In the
TServer
section, set sip-enable-diversion
to true
.
The header will include a reason that matches the dial-plan parameter used:
• no-answer
• user-busy
• do-not-distur b
For a full description of how to configure dial plans, see “Dial Plan” on page 210
.
With this feature, calls are diverted to a sequence of overflow destinations based on agent timeout.
To add the
Diversion
header in
INVITE s sent to the overflow destination:
1. Check that the overflow destination DN is configured. See “No-
Answer Supervision” on page 313
.
2. In the
TServer
section of the
Annex
tab of the overflow DN, set
true
.
Enable for Alternate
Routing.
Alternate Routing uses a number of different alternate DNs to handle internally redirected calls.
Set
to true
in any of the alternate DNs as defined in the following option:
• default-dn
For more information about configuring these alternate DNs, see
“Alternate Routing” on page 107
.
SIP Server—Deployment Guide 207
Chapter 5: SIP Server Feature Support Customizing SIP Header Formats
Table 49: Configuring Diversion Header Support (Continued)
Objective Related Procedures and Actions
Map from T-Library request.
In the T-Library client or URS routing strategy, configure the request to include the following:
•
SIP_HEADERS
—Add
‘Diversion’
to the list of custom SIP headers to be added to the
INVITE
.
• Define the header as follows:
‘diversion’ ‘<use syntax as described in RFC 5806>’
Enable for Call Redirection. Calls can be redirected or forwarded to another DN.
Set
to true
in the destination target DN.
Early Media Private Header
SIP Server supports passing the
P-Early-Media
header for inbound calls, as described in RFC 5009 “Private Header (P-Header) Extension to the Session
Initiation Protocol (SIP) for Authorization of Early Media”. This header can be used to control the flow of media in the early dialog state. SIP Server supports the
P-Early-Media
header for inbound calls only, and only for the following messages:
18X
,
200
,
INVITE
,
PRACK
, and
UPDATE
.
The
P-Early-Media
header is passed only when both the calling and destination domains are configured with
set to true
.
This functionality is only applicable if the calling side supports early media dialogs. Early media must be configured on the
Trunk
DN (
is set to
1
).
Feature Configuration
describes how to enable the passing of the
P-Early-Media
header.
Table 50: Enabling P-Early-Media Header
Objective Related Procedures and Actions
1. Verify calling side prerequisites.
The calling side must support the option tag
100rel
and early media.
2. Configure the inbound Trunk.
In the inbound
Trunk
DN on which the calls requiring
P-Early-Media
header will arrive, configure the following options in the
TServer
section:
•
—Set this option to true
.
•
—Ensure this option is set to the
default true
.
208 Framework 8.1
Chapter 5: SIP Server Feature Support Customizing SIP Header Formats
Private Headers
SIP Server may include private, Genesys-proprietary custom headers in the
SIP messages that it sends in certain call scenarios—for example, in multi-site scenarios where the call passes through several instances of SIP Server. These headers are identified by the prefix
X-
and include the following:
•
X-Genesys-PartyInfo
—Required for communication between instances of
SIP Server in multi-site deployments.
•
X-ISCC-Id
—Required for communication between instances of SIP Server in multi-site deployments.
•
X-ISCC-CofId
—Required for ISCC/COF call matching between instances of SIP Server in multi-site deployments.
•
X-Genesys-CallUUID
—Required for communication between instances of
SIP Server in multi-site deployments.
•
X-Genesys-<user_data>
—When you are integrating with GVP, Genesys recommends that you configure the userdata-map-trans-prefix
option to use the prefix
X-Genesys
in the custom headers that are used to map user data. In this case, you can expect to find
X-Genesys
- headers in the
INVITE messages that SIP Server sends to GVP.
Forwarding Custom Headers
SIP Server can pass custom SIP headers from a
REFER
request to an outgoing
INVITE
or
REFER
request. The Application-level configuration option, sip-passrefer-headers
, must be configured to enable this functionality.
describes how to configure custom header forwarding.
Table 51: Enabling Custom Header Forwarding
Objective
Configure the SIP
Server Application.
Related Procedures and Actions
In the SIP Server
Application
object, in the
TServer section, configure the following:
•
of the SIP headers to be forwarded in a commaseparated list.
SIP Server will forward these headers from the
REFER
(if included) to the outgoing
INVITE
or
REFER
.
You can use the asterisk (*) as a wildcard for multiple headers with the same prefix.
SIP Server—Deployment Guide 209
Chapter 5: SIP Server Feature Support Dial Plan
Filtering Custom Headers
SIP Server filters out Genesys internal SIP headers from
TRouteCall
and
TMakePredictiveCall
requests when generating an outgoing
INVITE
or
REFER request to a media gateway, unless otherwise specified. The DN-level configuration option, e nable-extension-headers
, is used to define which call request will include the custom headers from the
Extensions
attribute. For call requests not in this list, custom headers will be filtered out from the outgoing
INVITE
or
REFER
. This functionality applies to the following types of call requests:
•
TRouteCall
•
TMakePredictiveCall
describes how to configure custom header filtering.
Table 52: Enabling Custom Header Filtering
Objective Related Procedures and Actions
Configure the
Trunk
DN. In the outbound
Trunk
DN >
TServer
section, configure the following option:
•
request that will include custom headers: predictive
, routing
(one, both, or none
).
If the request is not in this list, custom headers will be filtered.
Dial Plan
The dial plan feature allows you to define the rules that SIP Server applies to the dialed digits that it receives from an endpoint or T-Library request. These rules enable SIP Server to transform the received digits into the actual digits that it uses to make the call.
SIP Server also supports the Dial Plan feature implemented in Genesys SIP
Feature Server. The dial plan can be configured either on the SIP Server side or on the SIP Feature Server side. Refer to the SIP Feature Server 8.1.2
documentation for details.
Introduced in
SIP Server
8.1.102.22
Note:
TMakePredictiveCall
is not processed by Dial Plans provided by SIP
Feature Server.
SIP Server offers the option to use SIP Feature Server as an “external dial plan” as an alternative to the internal SIP Server dial plan. Each choice offers distinct advantages to consider when choosing which dial plan to use. (Note that dial plans may not be combined.)
210 Framework 8.1
Chapter 5: SIP Server Feature Support Dial Plan
SIP Feature Server Dial Plan Highlights
•
User-based calling preferences for Call Waiting and Call Forwarding
(including Find-Me-Follow-Me)
•
Flexible rules with pattern matching logic for choosing a trunk for outgoing calls
•
Enhanced support for deployments where voicemail mailboxes are assigned to users (but not to DNs)
See “Using SIP Feature Server Dial Plan” on page 229
for configuration details.
SIP Server Dial Plan Highlights
•
Many supported parameters for advanced dial-plan rules, such as onbusy, type, calltype, clir, and more
•
Native support by SIP Server (smaller footprint, less complexity if Feature
Server is not required for the deployment)
See “Using SIP Server Dial Plan” on page 221
for configuration details.
Dial Plan Configuration Overview
Dial plans are configured as a set of rules on a
Voice over IP Service
DN with a service-type
of dial-plan
. You then assign the dial plan to any of the following objects, listed in order of priority:
1. Agent Login—Applies to calls made by a caller logged in under this Agent
Login ID.
2. DN-level—Applies to calls made from a DN (where Agent Login dial-plan is undefined) or for inbound calls if the dial-plan is assigned to the Trunk
DN.
3. Application-level—Applies to all calls (where no Agent Login or DN dialplan is defined).
You can also create group dial-plan DNs, where a single
Voice over IP
Service
DN integrates several underlying dial plans within a single assignable
DN.
Introduced in
SIP Server
8.1.102.22
Note:
A dial-plan rule configured on a Routing Point is applied only for calls that are initiated through a
TMakePredictiveCall
request on behalf of that Routing Point.
SIP Server offers additional control over how a dial plan is applied to the destination of
TRouteCall
and/or to multi-site (ISCC) calls that are routed through an External Routing Point with two configuration options:
•
configuration option changes the default behavior of the dial plan to any one of the following:
SIP Server does not apply any dial plan.
SIP Server—Deployment Guide 211
Chapter 5: SIP Server Feature Support Dial Plan
SIP Server applies only the digit translation to a dial plan target.
SIP Server applies the digit translation and forwarding rules to a dial plan target.
The rp-use-dial-plan
option applies to both SIP Server and SIP Feature
Server dial plans. If the
UseDialPlan
key-value pair is present in
AttributeExtensions
of
TRouteCall
, then it takes priority over the rp-usedial-plan
option.
•
The
option enables SIP Server to apply the dial plan to the target destination when a call is routed from an External
Routing Point ( cast-type=route-notoken
) to a DN at the destination site.
Note:
If out-rule functionality (deprecated) is configured on the Class of
Service (COS) DN, then the output of the out-rule will be used as the
“dialed digits” input to the dial-plan rule. For more information about
out-rule functionality on COS DNs, see “Class of Service” on page 179
.
Dial Plan Call Flow
When SIP Server receives an
INVITE
message for a 1pcc call or a T-Library request for 3pcc operation, SIP Server checks to see if a dial-plan is assigned to the DN that initiated the call. If it finds that a dial-plan is assigned to the DN,
SIP Server tries to match the dialed digits provided in the request to any of the patterns configured in the dial-plan. If a match is found, SIP Server can perform digit translation as specified in the dial-plan rule. Depending on what additional parameters are included in the dial-plan rule, SIP Server can perform other actions for the call—for example, to provide alternate routing if the destination is unavailable. If no pattern match is found, then the call proceeds as dialed (no modifications are made to the dialed digits).
When SIP Server applies a dial plan to a call, it includes the
extension key containing the original destination number (the dial plan input) before the dial plan is applied. If a call scenario contains multiple consecutive steps (for example, an inbound call to a Routing Point, routing to an agent, and a single-step transfer to the other agent), then an original dialed number is defined for each call step. For example, one dialed number is defined for an inbound call, another for routing, and a third one for a single-step transfer.
If a destination DN is a Routing Point, then the original-dialplan-digits extension key is passed in
EventQueued
and
EventRouteRequest
messages. If a call is made to the
ACD Position
DN, then a new extension key is added to
EventQueued
. If a call is made to the
Extension
DN, then a new extension key is added to
EventRinging
.
If the dial plan is not applied to the call, original-dialplan-digits
will not be added.
212 Framework 8.1
Chapter 5: SIP Server Feature Support Dial Plan
If the initiating DN is assigned a dial-plan, SIP Server can apply dial-plan functionality to any of the following 3pcc requests:
•
TMakeCall
•
TMakePredictiveCall
•
TInitiateTransfer
•
TInitiateConference
•
TSingleStepTransfer
•
TSingleStepConference
•
TRedirectCall
•
TCompleteTransfer
•
TCompleteConference
•
TRouteCall
(only if the
UseDialPlan
key extension is used)
SIP Server includes the resulting digits when the dial plan is applied as the username part of the
From
header in the
INVITE
message sent to the origination device. This behavior can be changed by setting the
option to true
.
SIP Server will also apply dial-plan logic to 1pcc
INVTE, REFER
, and
302 (moved temporarily)
operations.
Removal Overdialed Digits From DNIS
SIP Server provides the ability for internal and inbound calls coming to a
Routing Point to remove overdialed digits from
DNIS
dial-plan rule parameter is specified. Overdialed digits are added to the
DNIS_OVER
key of
AttributeExtensions
in T-Library events
EventQueued
and
EventRouteRequest
.
Example 1
dial-plan-rule: 0800XXXXXXX!=>1000; dnis-max-length=11
Called number: 080012345670123
Then
EventQueued
and
EventRouteRequest
will contain the following attribute values:
AttibuteThisDN: 1000
AttibuteDNIS: 08001234567
AttibuteExtensions 'DNIS_OVER': 0123
Example 2
The dial-plan-rule
parameter does not modify the DNIS, except when the dnis-max-length is set.
dial-plan-rule: 5566=>1111
Called number: 5566
SIP Server—Deployment Guide 213
Chapter 5: SIP Server Feature Support Dial Plan
Then attributes
ThisDN
and
DNIS
in T-Library events will contain the following values:
AttributeThisDN: 1111
AttributeDNIS: 5566
EventQueued
and
EventRouteRequest
will not contain the
DNIS_OVER
in
AttributeExtensions.
Example 3
dial-plan-rule: 5566=>1111;dnis-max-length=2
Called number: 5566
Then attributes
ThisDN
and
DNIS
in T-Library events will contain the following values:
AttributeThisDN: 1111
AttributeDNIS:55
EventQueued
and
EventRouteRequest
will contain the following attribute value:
AttibuteExtensions 'DNIS_OVER':66
The Dial-Plan Rule
When configuring a dial-plan rule ( dial-plan-rule-<n>
must use the following format: pattern => digits;param1=value1;param2=value2 # comment
Pattern Matching
SIP Server tries to match the pattern
in this string to the actual digits dialed,
using the Asterisk format with the syntax described in Table 53 .
Table 53: Asterisk Dial Plan Syntax for Pattern Matching
N
[ ]
Special Character Pattern Matching
X
Z
Matches any single digit from 0-9.
Matches any single digit from 1-9.
Matches any single digit from 2-9.
Matches any of the digits found inside the square brackets. For example, using the special characters
[12345], SIP Server can match any of the digits 1, 2, 3,
4, or 5.
214 Framework 8.1
Chapter 5: SIP Server Feature Support Dial Plan
Table 53: Asterisk Dial Plan Syntax for Pattern Matching
(Continued)
.
!
Special Character Pattern Matching
[X-Y] (hyphen inside square brackets)
Matches a range of digits. For example,
[125-8] matches any of the digits 1, 2, 5, 6, 7, 8.
(period)
Wildcard match. Matches one or more characters.
(exclamation point)
Wildcard match. Matches 0 or more characters.
Pattern Examples
Multiple Patterns
Some examples of how these special characters can be used to match the dialed digits are as follows:
•
9NXXXXXXXXX
—Matches any 11-digit number beginning with 9, where the second digit is between 2 and 9.
•
9[54]10XXXXXX
—Matches any 11-digit number beginning with either 9510 or 9410.
•
[45]XXX
—Matches any 4-digit number beginning with either 4 or 5.
If multiple patterns match a dialed-number, SIP Server selects the pattern with the most specific match (in other words, the match with the least wildcard uses) from left to right. For example, if
5111
is dialed then the pattern
5XXX would make the match instead of
XXXX
.
{DIGITS} Variable
Digit Translation
After matching the number dialed to the pattern
defined in the dial-plan rule, the digits
parameter tells SIP Server what number to use when it makes the call. These digits can be any alphanumeric string, terminated with a semicolon.
This parameter can also use the
{DIGITS}
variable for flexibility in defining the digits to be dialed.
The digits variable in the dial-plan rule must take one of the following formats:
${DIGITS}, ${DIGITS:x}, ${DIGITS:x:y}
SIP Server—Deployment Guide 215
Chapter 5: SIP Server Feature Support Dial Plan
Translation
Examples
where,
DIGITS
X
Y
Defines the actual digits dialed from the endpoint.
Defines the starting position of the variable, identified by the character position in the digit string. In this case,
0
represents the first character in the string (starting from the left). This value can be negative, which indicates a character position starting from the right instead of left. For example,
-1 indicates the right-most character.
Default for this parameter is
0
.
Specifies the number of characters to be included, starting from the position defined by
X
. By default, all characters in the string are included.
If the number
96501235678
is dialed, some examples of how the
{DIGITS} variable can translate these digits are as follows:
•
${DIGITS}
—Translates to
96501235678
.
•
${DIGITS:1}
—Translates to
6501235678
.
•
${DIGITS:-4:4}
—Translates to
5678
.
•
${DIGITS:0:4}
—Translates to
9650
.
Sample Dial Plan Rules
Some sample values for the dial-plan-rule-<n>
option, configured in the dialplan DN, are as follows:
5XXX=>4351707${DIGITS} # This rule matches any 4-digit number starting with 5 and translates it to the number 43517075XXX
5002=>43517075002 # This rule matches the dialed number 5002 and translates it to the number 43517075002
Dial Plan Parameters
describes additional parameters you can use to define the behavior of the dial-plan rule.
216 Framework 8.1
Chapter 5: SIP Server Feature Support Dial Plan
Table 54: Dial-Plan Rule Parameters
Parameter
type
Value
digits, agent, reject calltype clir internal, inbound, outbound on, off
Description
Defines the meaning of the digits in the dialing rule. Set the value for this parameter to any of the following:
• digits
(default)—SIP Server interprets the digits as regular dialed digits.
• agent
—SIP Server interprets the digits as an agent Extension
DN, an ACD Position DN, or an Agent Login ID.
If calling an Agent Login ID, SIP Server directs the call to the
DN on which the agent is logged in.
Notes:
Genesys recommends using different identifiers for Agent
Login IDs and the agent
Extension
DNs when using this option, otherwise SIP Server will direct the call to the extension even if the agent is logged out.
3pcc calls to an
Agent Login
ID will be converted to the
Extension that the agent is logged into before being processed by the dial-plan rules.
• reject
—SIP Server will reject this call, sending a SIP error code (
400
to
699
) to the caller. This code is provided in the
[ digits
] part of the dial-plan rule. For example, in the dialplan rule
[pattern]=>486;type=reject
,
486
is the error code.
If
0
or any other non-compliant code is provided, SIP Server will use the default code
403 (forbidden)
.
Defines the
AttributeCallType
to be used in T-Library events for the new call. Changes take effect for new non-consultation calls. Set the value for this parameter to any of the following:
• internal
—SIP Server will use
CallTypeInternal
as the attribute.
• inbound
—SIP Server will use
CallTypeInbound
as the attribute.
• outbound
—SIP Server will use
CallTypeOutbound
as the attribute.
Enables or disables Calling Line Identification Restriction. If set to on
, SIP Server does not display caller ID. If set to off
(default), SIP Server displays calling party ID, if it is available
.
SIP Server—Deployment Guide 217
Chapter 5: SIP Server Feature Support Dial Plan
Table 54: Dial-Plan Rule Parameters (Continued)
Parameter
timeout ontimeout onbusy ondnd onunreach onnotreg
Value
integer string string string string string
Description
Specifies the length of time, in seconds, that SIP Server waits for the agent to answer a ringing call. After this timeout period, SIP
Server forwards the call to the destination specified in the ontimeout
parameter. The options timeout
and ontimeout
must be defined together.
Note: If call forwarding is initiated from the endpoint, or by using the no-answer-timeou t option, SIP Server will use whichever forwarding has the shortest timeout setting.
Specifies the destination where SIP Server will forward the call after the timeout period elapses. The timeout parameter must be present for this option to have an effect.
You can use the
${DIGITS} variable to configure ontimeout
.
Specifies the alternate destination where SIP Server will forward calls made to a busy destination.
You can use the
${DIGITS}
variable to configure onbusy
.
Specifies the alternate destination where SIP Server will forward calls made to a destination that is currently set to do-not-distur b, or that returns a DND SIP error code (603).
You can use the
${DIGITS}
variable to configure
ondnd
.
Specifies the destination where SIP Server will forward the call after the unreachable period ( unreach-timeout
parameter) elapses. If the unreach-timeout
parameter is not present, then the unreachable period is set by the option
The onunreach
parameter takes precedence over the option
.
You can use the
${DIGITS}
variable to configure
onunreach
.
Specifies the alternate destination where SIP Server will forward calls made to a destination that has no SIP registration.
You can use the
${DIGITS}
variable to configure onnotreg
.
218 Framework 8.1
Chapter 5: SIP Server Feature Support Dial Plan
Table 54: Dial-Plan Rule Parameters (Continued)
Parameter
unreach-timeout privilege
[space]# dnis-max-length
Value
integer integer string integer
Description
Specifies the length of time, in seconds, that SIP Server waits for a response (provisional or
200 OK
) from an endpoint to an
INVITE request.
After this timeout period elapses, SIP Server forwards the call to the destination specified in the onunreach
parameter. If unreachtimeout is not specified, then SIP Server will use the value in the option
to define this timeout.
If onunreach
is not specified, then on timeout SIP Server will
either forward the call to the DN specified in the option noresponse-dn
, or if this option is not defined, SIP Server will terminate the call.
Specifies the privilege value for this dial-plan rule. Minimum integer is
0
(default), maximum is
10
. Additional configuration as follows:
• To allow the calling DN to use this rule—add the value to the privilege-level
list in the
Class of Service
DN assigned to the calling device.
• To bar the calling DN from using this rule—do not add the value to the privilege-level list.
• To allow all calling DNs to use this rule—do not configure the privilege parameter in the dial-plan rule.
Note: The default setting of 0 allows any class of service to use this rule.
For more information, see “About Privilege Levels” .
Indicates the start of the comments section. Any data after the
# is ignored. You must include a space before the
#
, otherwise SIP
Server interprets it as a regular character
.
Valid values: 1-22. Defines the maximum length of DNIS in the dial-plan rule. The digits that are in position past the specified length are considered overdialed and removed from DNIS.
Overdialed digits are included as a value of the
DNIS_OVER
key of
AttributeExtensions
in
EventQueued
and
EventRouteRequest
.
Any invalid value disables this feature.
See “Removal Overdialed Digits From DNIS” on page 213
.
SIP Server—Deployment Guide 219
Chapter 5: SIP Server Feature Support Dial Plan
About Privilege Levels
Privilege levels are used to define which dial-plan rules are available for calls made by the caller associated with a particular COS.
For example, SIP Server can block a lobby phone from making national or international calls.
To configure privilege levels, you first define the privilege level in the dialplan rule, then add the definition to a list of accepted privilege levels in the class of service DN. If the dialed digits of a new call match a dial-plan rule with a privilege defined, then that privilege must be configured in the COS assigned to the caller. If it is not, the call is rejected.
You can define two different privilege-level options in COS:
•
fwd-privilege-level
—This option applies to all operations that forward an existing call to a new party (transfer, conference, redirect,
302
response).
•
privilege-level
—This option applies to operations that initiate a new call
(1pcc and 3pcc
TMakeCall, TMakePredictiveCall, TInitiateConference,
TInitiateTransfer
), or for all operations if the COS does not also define the fwd-privilege-level
option.
You then assign the COS to any of the following objects, listed in order of priority:
1. Agent Login—Applies to calls made by a caller logged in under this Agent
Login ID.
2. DN-level—Applies to calls made from this DN (where Agent Login COS is undefined).
3. Application-level—Applies to all calls (where no Agent Login or DN COS is defined).
Note:
The default dial-plan rule privilege setting (
0
) is allowed by all COS
DNs and does not need to be explicitly configured.
Feature Configuration
This section describes how to configure a Dial Plan feature depending on whether you use SIP Server or SIP Feature Server.
•
See “Using SIP Server Dial Plan” on page 221
•
See “Using SIP Feature Server Dial Plan” on page 229
220 Framework 8.1
Chapter 5: SIP Server Feature Support Dial Plan
Using SIP Server Dial Plan
describes how to configure a SIP Server dial plan.
Table 55: Configuring a SIP Server Dial Plan
Objective Related Procedure and Key Actions
1. Configure a dial-plan DN.
1. Create a
Voice over IP Service
DN.
2. In the
TServer
section, configure the following options:
For details, see
Procedure: Configuring a Dial-Plan DN, on page 222
.
2. Configure a class of service
DN.
1. Create a
Voice over IP Service
DN.
2. In the
TServer
section, configure the following options:
For details, see
Procedure: Configuring Class of Service for a Dial
.
Note: COS DN is only required if privilege parameters are used in the applicable dial-plan rules. For more information about configuring the
COS DN (for example, the inbound ring-through rules), see “Class of
3. Assign the service DNs.
Global Configuration
1. Open the SIP Server
Application
object.
2. In the
Options
tab >
TServer
section, configure the following options:
Individual Configuration
1. Open the DN or
Agent Login
object.
•
•
2. In the
TServer
section, configure the following options:
For detailed procedures, see the following:
Procedure: Assigning the dial plan to a device, on page 226
Procedure: Assigning COS to a device, on page 228
•
Procedure: Assigning the dial plan and COS globally, on page 228
SIP Server—Deployment Guide 221
Chapter 5: SIP Server Feature Support Dial Plan
Table 55: Configuring a SIP Server Dial Plan (Continued)
Objective Related Procedure and Key Actions
Additional Special Configuration
Include other dial plans in a single dial-plan DN.
To apply a dial plan to the destination of
To apply a dial plan to multisite (ISCC) calls that are routed through an External
Routing Point.
TRouteCall
.
You can include multiple other dial plans under a single dial-plan DN.
1. Open a dial-plan
Voice over IP Service
DN.
2. In the
TServer
section, configure the following option:
See Procedure: Including additional dial plans, on page 225 .
In the SIP Server Application >
TServer
section, configure the following option:
•
In the SIP Server Application >
TServer
section, set this option to true:
•
Procedure:
Configuring a Dial-Plan DN
Name
Start of procedure
1. Under the SIP Server
Switch
object, create a
Voice over IP Service
DN
.
2. On the dial-plan
DN
object, in the
TServer section, set the configuration option service-type
to dial-plan
.
3. Specify the dial plan rules.
For each rule, add a new configuration option
the following format: dial-plan-rule-<n>
222 Framework 8.1
Chapter 5: SIP Server Feature Support
Value
Dial Plan pattern => digits;param1=value1;param2=value2;... # comment
For example: dial-plan-rule-1 = 9NXXXXXX=>9${DIGITS:2} # local out-dial
Note:
For detailed information about the syntax used in the different parts of the dial plan rule, see the following:
• pattern
—See “Pattern Matching” on page 214
.
• digits
—See “Digit Translation” on page 215
.
• param1=value1
, and so on—See “Dial Plan Parameters” on page 216 .
illustrates a sample configuration for a dial-plan DN with dialplan rules specified.
Figure 24: Configuring the Dial-Plan DN: Sample Configuration
4. When finished, click
Apply
to save your configuration.
End of procedure
Next Steps
•
If you are including privilege-level Class of Service configuration, continue to
Procedure: Configuring Class of Service for a Dial Plan .
•
To include additional dial plans in this DN, see
Procedure: Including additional dial plans, on page 225
.
•
To assign the dial plan to a particular device, see
Procedure: Assigning the dial plan to a device, on page 226
.
SIP Server—Deployment Guide 223
Chapter 5: SIP Server Feature Support Dial Plan
•
To assign the dial plan globally for all calls (unless otherwise specified on
the DN or Agent Login-level), see Procedure: Assigning the dial plan and
Procedure:
Configuring Class of Service for a Dial Plan
Start of procedure
1. Under the SIP Server
Switch
object, create a COS DN with a type of
Voice
Over IP Service.
2. On the COS DN object, in the
TServer section, set the configuration option service-type
to cos.
3. In the
TServer
section, configure the privilege levels that will be accessible by this class of service:
•
—Set this option to a list of integers that define which dial-plan rules are allowed for outgoing calls made by the caller associated with this COS DN.
•
—Set this option to a list of integers that define
which dial-plan rules are allowed for transfer/redirect/conference operations.
Tip: The privilege levels defined here must match the privilege
parameter in the dial-plan-rule-<n>
option, otherwise the call will be blocked.
illustrates a sample configuration for the COS DN with the ringthrough rules and privilege-level specified.
224
Figure 25: Configuring COS DN for a Dial Plan: Sample Configuration
4. When finished, click
Apply
to save your configuration.
End of procedure
Framework 8.1
Chapter 5: SIP Server Feature Support Dial Plan
Next Steps
•
To assign the Class of Service to a particular device, see Procedure:
Assigning COS to a device, on page 228
.
•
To assign the Class of Service globally for all calls (unless otherwise specified at the DN or Agent Login-level), see
Procedure: Assigning the dial plan and COS globally, on page 228
.
Procedure:
Including additional dial plans
Purpose: To include additional dial plans in a defined dial-plan DN. This lets you to group several dial plans into a single DN, which you can then assign as required.
Prerequisites
•
A configured dial-plan DN with dial-plan rules (
Voice over IP Servic e
DN with service-type
set to dial-plan
). See Procedure: Configuring a
Note:
The dial-plan-rule will be selected purely on the number of specific digits matched—no preference is given to any rules in this dial-plan or the included dial-plan.
Start of procedure
1. Under the SIP Server
Switch
object, open a configured dial-plan
Voice
Over IP Service
DN.
2. In the
TServer
section, set the
configuration option to the name of the underlying dial plan DN that you want added to this dial-plan DN.
3. Add new instances of the include-dial-plan-<n>
option for every dial-plan
DN to be included in this DN.
shows a sample dial-plan DN that includes other dial plans.
SIP Server—Deployment Guide 225
Chapter 5: SIP Server Feature Support Dial Plan
Figure 26: Sample Dial-Plan DN That Includes Other Dial Plans
4. When finished, click
Apply
to save your configuration.
End of procedure
Next Steps
•
If this dial-plan DN is not already assigned to the required devices, continue to
Procedure: Assigning the dial plan to a device, on page 226
.
Procedure:
Assigning the dial plan to a device
Purpose: To associate the dial-plan DN with the device DN or Agent Login that will use the dial-plan when making a call.
Prerequisites
•
A configured dial-plan DN with dial-plan rules (
Voice over IP Service
DN with service-type
set to dial-plan)
. See Procedure: Configuring a
Start of procedure
1. Under the SIP Server
Switch
, open the configuration object to which you want to apply the dial-plan. Supported objects include:
•
Agent Login
•
Extension
DN
•
ACD Position
DN
•
Trunk
DN
226 Framework 8.1
Chapter 5: SIP Server Feature Support Dial Plan
•
Trunk Group
DN
•
Routing Point
DN
•
Voice over IP Service
DN with service-type=softswitch
2. In the
TServer section, a dd the
configuration option, with the
value set to the name of the dial-plan DN.
illustrates a sample configuration of the device DN with an assigned dial-plan and COS.
Figure 27: Assigning the Dial-Plan to a Device: Sample Configuration
Tip:
Both COS for the dial-plan and the dial-plan itself can be assigned to multiple DNs by using the
Manage Options
command in Configuration
Manager.
3. When finished, click
Apply
to save your configuration.
End of procedure
Next Steps
•
If you are including Class of Service to control the allowed privileges for this DN or agent, continue to
Procedure: Assigning COS to a device, on page 228
.
•
If you want to configure the dial plan and COS globally for all calls (unless
otherwise configured at DN or Agent Login-level), continue to Procedure:
Assigning the dial plan and COS globally, on page 228 .
SIP Server—Deployment Guide 227
Chapter 5: SIP Server Feature Support Dial Plan
Procedure:
Assigning COS to a device
Purpose: To associate the COS DN with the device DN or Agent Login that will use the defined privilege-levels (Class of Service) when making a call.
•
A configured COS DN with defined privilege-levels (
Voice over IP
Service
DN with service-type
set to cos)
. See Procedure: Configuring a
.
Start of procedure
1. Under the SIP Server
Switch
, open the configuration object you want to apply the COS DN. Supported objects include:
•
Agent Login
•
Extension
DN
•
ACD Position
DN
•
Trunk Group
DN
•
Routing Point
DN
2. In the
TServer
section, add the configuration option cos
to the name of the COS DN that you configured in
Procedure: Configuring a COS DN, on page 187
.
3. When finished, click
Apply
to save your configuration.
End of procedure
Procedure:
Assigning the dial plan and COS globally
Purpose: To assign the dial plan to the SIP Server application, where it applies globally to calls made from any DN on the switch (unless otherwise defined on the DN or Agent Login-level).
Prerequisites
•
A configured dial-plan DN with dial-plan rules (
Voice over IP Service
DN with service-type
set to dial-plan
). See Procedure: Configuring a
•
A configured COS DN with defined privilege-levels (
Voice over IP
Service
DN with service-type
set to cos
). See Procedure: Configuring a
.
228 Framework 8.1
Chapter 5: SIP Server Feature Support Dial Plan
Start of procedure
1. Go to the
Applications
folder and open the SIP Server
Application
object.
2. On the
Options
tab, in the
TServer
section, configure the following options:
•
—Set this to the name of the dial-plan DN.
•
—Set this to the name of the COS DN.
3. When finished, click
Apply
to save your configuration.
End of procedure
Procedure:
Using SIP Feature Server Dial Plan
Purpose: To configure a SIP Feature Server Dial Plan.
Start of procedure
1. Administer the SIP Feature Server dial plan as described in the SIP Feature
Server Administration Guide.
2. Configure the SIP Server that is associated with the Feature Server by setting the following option in the
TServer section of the SIP Server
Application:
dial-plan
—Set this option to fs-dialplan,
as described in the SIP
Feature Server Deployment Guide.
3. Under a SIP Server Switch object that is associated with the SIP Server, create a VOIP Service DN named fs-dialplan
and configure these options:
service-type
—Set this option to extended
.
Important: Ensure that you add the final slash character (/) to the end of each of the following URLs.
url
—Set this option to http://<FS Node>:<port>/
For n+1 High Availability (HA), add the following parameters: url-1 = http://<FS Node2>:<port>
/ url-2 = http://<FS Node3>:<port>/ url-n = http://<FS Node_N>:<port>/
Important: A Feature Server’s dial plan URL must be configured only on a VOIP Service DN that was created on the Switch controlled by the SIP Server that is connected to that particular Feature Server.
(Optional)
true
to enable SIP
Server to generate alarms 52035 and 52056. See “SIP Feature Server
.
•
If required, configure the following options in the SIP Server Application object, the
TServer
section:
SIP Server—Deployment Guide 229
Chapter 5: SIP Server Feature Support Dial Plan
—Set this option to a value suitable for your
environment.
—Set this option to true
to enable SIP Server to apply the dial plan to multi-site (ISCC) calls that are routed through an
External Routing Point ( cast-type=route-notoken
).
•
(Optional) In a routing strategy, set the
UseDialPlan
key extension in
TRouteCall
. The key extension setting takes priority over configuration options.
End of procedure
SIP Feature Server Log Messages
option is set to true,
SIP Server generates the following alarms:
•
52056|STANDARD|GCTI_FEATURE_SERVER_URL_TIMEOUT|Feature Server URL
%s missed response timeout
•
when SIP Feature Server does not reply within a specified timeout.
•
52035|STANDARD|GCTI_FEATURE_SERVER_URL_OFFLINE|Feature Server URL
%s now offline when SIP Feature Server does not respond on time a pre-set amount of times.
The 52035 alarm will be cleared by the following message:
52036|STANDARD|GCTI_FEATURE_SERVER_URL_ONLINE|Feature Server URL %s now online
Dial Plan For Multi-Site Calls
For multi-site calls, the Dial Plan is used on both the origination and destination sites. To avoid conflicts, Genesys recommends the following configuration:
Origination Site
•
Dial Plan Selection: The dial plan assigned to the Agent Login or DN that initiated a call to the destination site is used (or the Application-level dial plan, if none is assigned to the Agent Login or DN object).
•
Dial Plan Rule Selection: The dialed digits are used to select the dial-plan rule in the dial plan.
•
Dial Plan Rule Application: Genesys recommends to place digit translation and call-barring rules (privilege and type=reject) at the origination site selected dial plan. Place destination forwarding rules, such as ontimeout and ondnd,
at the destination site dial plan only, to avoid race conditions.
230 Framework 8.1
Chapter 5: SIP Server Feature Support Dial Plan
Destination Site Calls Using External Routing Points (ISCC type=route)
•
Dial Plan Selection: The dial plan assigned to an ISCC trunk is used (or the
Application-level dial plan is used if none is assigned to the ISCC trunk).
•
Dial Plan Rule Selection: If a dial-plan rule matches the external Routing
Point destination, then this rule is used. If there is no match for the external
Routing Point, then a rule is selected that matches the agent destination DN instead.
•
Dial Plan Rule Application: Genesys recommends to place destination forwarding rules only at the destination site selected dial plan (such as ontimeout
and ondnd
), to avoid race conditions with rules at the origination site.
Al Other Destination Site Calls
•
Dial Plan Selection: The dial plan assigned to an ISCC trunk is used (or the
Application-level dial plan will be used if none is assigned to the ISCC trunk).
•
Dial Plan Rule Selection: Dialed digits without the stripped trunk prefix are used to select the dial-plan rule.
•
Dial Plan Rule Application: Genesys recommends to place destination forwarding rules only at the destination site selected dial plan (such as ontimeout
and ondnd
), to avoid race conditions with rules at the origination site.
Note:
Business Continuity configuration must follow the same multi-site recommendations, with the following limitations:
•
For the destination site, Genesys recommends to use only an
Application-level dial plan for destinations to provide consistent behavior for forwarding rules in all scenarios.
•
Feature Server Dial Plan does not support user-based calling profiles.
Feature Limitations
The following limitations apply to a dial plan:
•
Dial plan is not applied to the agent DN destination for calls that are distributed to the agent through an ACD Queue.
•
Dial plan is not be applied to the destination of the
TCallForwardSet request.
SIP Server—Deployment Guide 231
Chapter 5: SIP Server Feature Support DNS Name Resolution
DNS Name Resolution
Using an internal DNS client, SIP Server is able to use DNS procedures for resolving a SIP URI to a corresponding IP address, port, and transport protocol. If enabled, SIP Server complies with the DNS procedures described in RFC 3263 “Session Initiation Protocol (SIP): Locating SIP Servers”, which includes support for multiple resolved destinations.
How It Works
DNS name resolution works in conjunction with the Active Out-of-Service
Detection feature. The DNS server returns information about the resolved destinations from either of the following record types:
•
DNS/A—address records (does not include priority and weight information)
•
DNS/SRV—service records (includes priority and weight information, allowing these fields to be taken into account when resolving the SIP URI to multiple destinations)
Note:
SIP Server performs all DNS name resolution procedures as described in RFC 3263, except for NAPTR records lookup.
If the SIP URI from the contact for a particular DN resolves to multiple
destinations through a DNS/SRV lookup, SIP Server uses the “Active Out-of-
feature to send
OPTIONS
requests to each resolved destination to determine which destination is available.
When sending SIP messages through
Trunk
or
Voice over IP Service
DNs that resolve to multiple destinations, by default SIP Server selects the destination without taking into account the “priority” or “weight” field from the DNS/SRV record. If you want SIP Server to take these fields into account, you must set sip-enable-rfc3263
to true
.
The Device Selection Algorithm
When deciding which device to select, SIP Server takes the following factors into consideration:
•
If the URI contains both hostname and port, SIP Server resolves to IP address using a DNS/A record request.
•
If the URI contains a hostname with no defined port, SIP Server resolves to
IP address using a DNS/SRV record request. To use this method, you must enable
“Active Out-of-Service Detection”
on the DN.
232 Framework 8.1
Chapter 5: SIP Server Feature Support DNS Name Resolution
Example
The following sample call flow demonstrates how SIP Server uses a DNS server to resolve a domain for an external Trunk with multiple destinations:
1. SIP Server sends a request to the DNS server to resolve the FQDN from the
Contact
option of the
Trunk
DN.
2. The DNS Server returns the SRV/A records with a list of the resolved destination IP addresses with the priority and weight for each.
3. SIP Server sends
OPTIONS
requests to each resolved destination to determine availability.
4. The agent initiates an outbound call—to route the call, SIP Server chooses from the list of active destinations according to the priority and weight information included in the SRV/A record. If there are two active destinations with the same priority, SIP Server selects the destination with the higher weight.
Feature Configuration
describes how to enable DNS resolution through A/SRV records.
Table 56: Enabling DNS Name Resolution
Objective
1. Configure the SIP Server
Application.
Related Procedures and Actions
In the SIP Sever Application object, configure the
TServer
section with the following options:
•
—Set this to true
. This enables the internal DNS client.
• (optional) sip-enable-rfc3263
—Set this to true
. This enables priority and weight to be factored in to the destination selection algorithm.
—Enter the FQDN for the SIP Server host machine.
SIP Server—Deployment Guide 233
Chapter 5: SIP Server Feature Support DTMF Clamping in a Conference
Table 56: Enabling DNS Name Resolution (Continued)
Objective
2. Configure the Trunk DN.
Related Procedures and Actions
In the destination DN, in the
TServer
section, configure the following options:
•
—Enter the URI for this destination DN.
•
—Set to option to a valid timeout, in seconds (
1
to
300
).
For a more tuned oos-check performance, you can also enable the following related oos-check options:
•
—Set this to the length of time that SIP Server waits before setting an unresponsive device to out-of-service.
•
—Set this to the length of time that a device is
set to out-of-service in case of an error.
•
—See this to the length of time that SIP
Server waits before it considers a transport as failed (SIP Server abandons the dialog and sets transport out-of-service).
DTMF Clamping in a Conference
Introduced in
SIP Server
8.1.101.68
Multi-site support added in
8.1.101.95
This feature guards a customer’s sensitive credit card information from an agent and from call recording. DTMF clamping is supported in single-site and multi-site deployments. Here is how it works when activated and enabled:
1. The customer needs to enter a credit card number.
2. The agent adds IVR to the call, which bridges the customer, agent, and
IVR.
3. The customer enters the requested credit card digits, but they are not recorded and the agent hears only silence.
4. The credit card number is passed to the IVR, securely.
This behavior is called DTMF clamping, and SIP Server supports it to comply with the Payment Card Industry Data Security Standard (PCI DSS).
MCP performs DTMF clamping for selected parties in a conference, for the following DTMF transmission modes:
•
RTP packets with a Named Telephone Event (NTE) payload as specified by RFC 2833
•
In-band audio tones (encoded using a regular audio codec, such as G.711)
•
SIP
INFO
packets with the content-type application/dtmf-relay
SIP Server uses MSML messages to inform MCP about which legs of the conference should reveal DTMF tones and which legs should suppress DTMF tones. Each leg is controlled individually. SIP Server defines the DTMF mode for each leg based on the DN type or DN-level configuration option.
234 Framework 8.1
Chapter 5: SIP Server Feature Support DTMF Clamping in a Conference
In multi-site deployments, SIP Server uses the same mechanism as for Call
Participant Info notifications (
NOTIFY
requests) to provide information about multi-site call participants. Routing Point parties are now included in these
NOTIFY
requests when DTMF clamping is enabled.
Activating DTMF Clamping
1. Activate DTMF clamping by setting the Application-level option clampdtmf-allowed
to true
.
2. When activated, you can enable the feature on a DN object that is configured as IVR. For this purpose, IVR can be configured as DNs of type
Voice Treatment Port, Trunk,
or
Trunk Group
:
If IVR is configured as a DN of the type
Voice Treatment Port
is added to the conference, then DTMF tones are clamped for all parties in the conference except for the
Voice Treatment Port
DN. No
DN-level configuration is required.
If IVR is configured as a
Trunk
or
Trunk Group
DN, then activate
DTMF clamping by setting the clamp-dtmf-enabled
option to true
on the corresponding
Trunk
or
Trunk Group
DN.
3. In multi-site deployments, set the Application-level option sip-enablecall-info
option to true.
On Routing Points
SIP Server automatically activates DTMF clamping in any conference where a
Routing Point is invited. No DN-level configuration is required, and only a party represented by the Routing Point is allowed to receive DTMF digits.
DTMF clamping is activated regardless of the type of treatment applied at the
Routing Point, and it remains active as long as the Routing Point stays in the conference.
DTMF Clamping in Recordings
PCI compliance requires that DTMF tones are not recorded when clamping is enabled. To satisfy this requirement, recording must be disabled on the caller’s leg. Otherwise, DTMF digits dialed by a caller could be recorded.
SIP Server—Deployment Guide 235
Chapter 5: SIP Server Feature Support DTMF Tones Generation
Genesys recommends that you enable recording on the agent’s leg as shown in
.
Figure 28: DTMF Clamping
Feature Limitations
DTMF Clamping requires the Application-level option
true
(the default value) when DTMF digits are collected via a treatment applied at the Routing Point.
DTMF Tones Generation
SIP Server supports two methods for initiating DTMF tone generation on the media server:
•
The agent can request DTMF tone generation by sending a
TSendDTMF request from Genesys Agent Desktop.
•
A routing strategy can instruct SIP Server to send a request to the media server using the
TApplyTreatment
request with the
PlayApplication treatment.
236 Framework 8.1
Chapter 5: SIP Server Feature Support DTMF Tones Generation
DTMF Parameters for Play Application Treatments
The following key-value pairs (see Table 57 ) are used in the attribute
parameters
for the
PlayApplication
treatment:
Table 57: Key-Value Pairs for TreatmentPlayApplication
Key
GSIP_APP_ID
Type
Integer
Value
Number of the specific application to be executed. Set this parameter to the value of
502
to trigger the play application.
The DTMF string to be generated.
GSIP_DTMF_TO_DIAL
Note: When designing the routing strategy in IRD, you must add the prefix
{s}
so that URS interprets the value as a string. By default,
URS interprets the value as an integer (0).
GSIP_DTMF_DURATION
String
Integer The duration of the DTMF tone in msec. This parameter is optional with the default value of
100 msec.
Feature Configuration
describes how to configure DTMF tones generation support.
Table 58: Configuring DTMF Tones Generation Support
Objective
1. Configure a SIP Server
Application
object.
Related Procedures and Actions
In the
TServer
section on the
Options
tab of the SIP Server
Application
object, set the configuration option
to true
.
Note: This option setting is required for
TSendDTMF
.
2. Configure an application service
(NETANN).
Configure a DN of type
Voice over IP Service with the following configuration options set in the
TServer
section:
• contact:
Set to the device’s IP address used for sending DTMF tones.
• service-type:
Set to application
.
See “Configuring an application service” on page 87 for details.
SIP Server—Deployment Guide 237
Chapter 5: SIP Server Feature Support Dummy SDP
Table 58: Configuring DTMF Tones Generation Support (Continued)
Objective Related Procedures and Actions
3. Configure an application service
(MSML).
Configure a DN of type
Voice over IP Service with the following configuration options set in the
TServer
section:
• contact:
Set to the Resource Manager’s IP address/FQDN.
• service-type:
Set to msml
.
See “Configuring an MSML Service” on page 91 for details.
Dummy SDP
In some cases, SIP Server may need to send “dummy” media session parameters (SDP) in the initial
INVITE
message for certain call routing scenarios. For example, to ensure that a continuous treatment is played to a caller in an established dialog until an available agent answers the call.
How It Works
The dummy SDP is formed according to the parameters specified in the
TRouteCall request. These parameters are configured in the routing strategy as key-value pairs in the
AttributeExtensions
of the
TRouteCall
request:
•
—Any string. The value will be propagated as the connection address in the c= line of Dummy SDP. Typically, this would be the IP address of the media server host.
•
—Any integer that represents a valid UDP port. This value
represents the low part in the range of ports to be included in the m= line of the SDP. Key rules:
The actual port used can equal this low value.
Only even-numbered ports are used.
•
—Any integer that represents a valid UDP port. This value represents the high part in the range of ports to be included in the m= line of the SDP. Key rules:
The actual port used can equal the low value, but cannot equal this high value.
Only even-numbered ports are used. For example, if the range is 4000 to 4010, the port in the INVITE can be 4000, 4002, 4004, 4006, and
4008 only.
If you leave this parameter unspecified (empty), then the value of the sdp-m-port-low
will be used.
•
—An integer that overrides the value of the
configuration option, which specifies the length of time
(in seconds) that SIP Server waits before diverting the call from the
238 Framework 8.1
Chapter 5: SIP Server Feature Support Dummy SDP
Routing Point DN to the destination DN after RequestRouteCall was processed. When the call is not diverted before the timeout expires, SIP
Server generates an EventError message.
Note:
The after-routing-timeout
parameter does not apply to SDP formation only, but can be used for other reasons.
Example of TRouteCall and Corresponding SDP
For example, a
TRouteCall
with the following
Extension
Attributes (as applied from the routing strategy):
AttributeExtensions[107] 00 04 01 00..
'after-routing-timeout'25
'sdp-c-host''192.168.10.10'
'sdp-m-port-low'44000
'sdp-m-port-high'44500 results in a SIP
INVITE
request with the following SDP (bold indicates affected values): v=0 o=Genesys 1287768950 1 IN IP4 192.168.10.10
s=3pcc Make Call c=IN IP4 192.168.10.10
t=0 0 m=audio 44000 RTP/AVP 101 0 8 4 18 3 a=rtpmap:101 telephone-event/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:4 G723/8000 a=rtpmap:18 G729/8000 a=rtpmap:3 GSM/8000
Feature Configuration
describes how to configure a dummy SDP.
Table 59: Configuring Dummy SDP
Objective
1. Configure the
Application.
Related Procedure and Key Actions
In the
TServer
section of the SIP Server
Application
object, configure the following options:
•
—Set this to true
.
•
—Set this to true
.
•
—Set this to false
.
SIP Server—Deployment Guide 239
Chapter 5: SIP Server Feature Support E911 Emergency Gateway
Table 59: Configuring Dummy SDP (Continued)
Objective
2. Configure the routing strategy.
Related Procedure and Key Actions
In Interaction Routing Designer (IRD), configure the strategy to attach the following
Extensions
to the
TRouteCall
:
•
—Enter the connection address provided in the
c=
line of the Dummy SDP.
•
—Enter the low part in the range of valid UDP ports.
•
—Enter the high part in the range of valid UDP
ports.
•
—Enter the length of time that SIP Server
waits for the call to arrive at the destination after processing the
TRouteCall
. Overrides the after-routing-timeout
option.
For more information about configuring routing objects in IRD, consult the Universal Routing 8.1 Reference Manual.
E911 Emergency Gateway
SIP Server supports 911 emergency calling using the integration with the E911
EGW and service. When properly configured, 911 calls made from devices registered to SIP Server are sent through the EGW. Emergency calls can be made directly from the phone (1pcc call) or by request from a T-Library client
(3pcc call); if both methods are available, 1pcc rather than 3pcc is recommended. As well, the EGW integration allows the Public Safety
Answering Point (PSAP, or 911 dispatch) to discover the location of the dialing device and to provide a Call Back Number (CBN) in case the call is prematurely disconnected.
Feature Configuration
describes how to configure SIP Server for E911 support.
Table 60: Configuring SIP Server for E911 Emergency Gateway
Objective
1. Create the EGW DN.
Related Procedures and Actions
SIP Server uses this DN to place the outgoing 911 call as initiated by the SIP endpoint.
•
Procedure: Creating the EGW DN, on page 242
240 Framework 8.1
Chapter 5: SIP Server Feature Support E911 Emergency Gateway
Table 60: Configuring SIP Server for E911 Emergency Gateway (Continued)
Objective
2. Configure the dial plan
(DID allowed).
3. Configure the call path
(DID not allowed).
4. Configure the endpoints.
Related Procedures and Actions
For environments that allow DID calls, do the following:
1.
Procedure: Creating a dial-plan DN for the ANI to CBN conversion, on page 243
2.
Procedure: Assigning the EGW DN to the ANI-to-CBN dial plan, on page 244
3.
Procedure: Creating a dial-plan DN for the CBN to ANI conversion, on page 244
4. Set the dial-plan
option to the name of the dial-plan DN you created in
Step 3 . This option can be set at an Application level or at
a DN level on
Trunk
DNs for inbound calls.
For environments that do not allow DID calls, do the following:
•
Procedure: Configuring the call path (DID not allowed), on page 245
1. Ensure that G711 is supported and enabled on all endpoint devices.
Note that on the Genesys side, even if codec filtering is enabled
( sip-enable-sdp-codec-filter
is set to true
) and G711 is not included in the filter exemption list (audio-codecs option), SIP
Server will not filter the G711 codec, overriding the filter settings.
2. (Recommended) Where possible, configure the endpoint to use the
REFER
method for 3pcc calls (set refer-enabled
to true
).
3. If
MakeCall
using the
REFER
method is not possible, Genesys recommends that you configure the option sip-invite-treatmenttimeout
value to
5
seconds. This guarantees that in case all media services fail, emergency calls will not be stuck for any longer than this 5-second interval.
SIP Server—Deployment Guide 241
Chapter 5: SIP Server Feature Support E911 Emergency Gateway
Table 60: Configuring SIP Server for E911 Emergency Gateway (Continued)
Objective
5. Run the Genesys
Emergency Gateway
Utility.
Related Procedures and Actions
Genesys provides a utility that extracts a list of Extension DNs (and contact IP addresses) from the Configuration Server and uploads it through FTP to the Emergency Gateway.
1.
Procedure: Installing and Configuring the Utility, on page 245
2. When the script is started, it takes the following actions: a. It reads and processes the configuration file.
b. It connects to Configuration Server via SOAP interface.
c. From Configuration Server, it fetches a list of Extensions that belong to a particular switch. If the Extension is configured with an IP address for the option contact
, the IP address will be extracted as well.
d. It creates a
.txt
file in accordance with the EGW requirement.
Note that 911 enable can only use a semicolon as a separator, not a comma.
e. As the final step, the
.txt file is uploaded to the EGW via FTP.
3. If these above operations are successful, three files are created:
Batch file which was uploaded to EGW. It has the same name as configuration file, but with the suffix
.txt
in place of .
cfg
.
Batch file which was uploaded during previous run of this script with the same configuration file. The name of this file includes the symbol "_" placed before the .txt suffix.
Log file which reflects the steps that the script performed. If all steps were successful, the last line should show as “
JOB: completed.
”
Procedure:
Creating the EGW DN
Start of procedure
1. Create a
Trunk Group
DN to represent the EGW, giving it the name of the emergency dialing number; for example, 911.
2. In the
TServer
section, configure the following options:
•
contact
—Enter the IP address for the primary EGW.
•
—Enter a comma-separated list of IP addresses for
the alternate route. The first address in the list must represent the backup EGW. The following addresses can represent any other PSTN gateways that deliver emergency calls to the 911 Enable service.
242 Framework 8.1
Chapter 5: SIP Server Feature Support E911 Emergency Gateway
•
true
to enable this device to conduct emergency calls.
Note:
You can also enable Active Out-of-Service Detection for this DN
(using the options oos-check
and oos-force
). If SIP Server detects this
DN is unresponsive, it will not use the address from the contact but will instead try the addresses configured in the emergency-backup option.
End of procedure
Next Steps
•
If DID is allowed, continue at
Procedure: Creating a dial-plan DN for the
•
If DID is not allowed, continue at Procedure: Configuring the call path
Procedure:
Creating a dial-plan DN for the ANI to CBN conversion
Purpose: This dial plan contains rules for transforming the calling DN (ANI) to the 10-digit Call Back Number (CBN) included as the P-Asserted-Identity header in the INVITE to the EGW. This CBN is required by the Public-safety
Answering Point (PSAP) to identify the location of the 911 caller.
Start of procedure
1. Configure a
Voice over IP Service
DN with service-type
set to dialplan
.
2. In the
TServer
section and create dialing rules to transform the ANI to the
CBN.
For example, if configuring dialing rules for extensions at two different locations (two groups, each with a different country and area code), you can create a separate dialing for each group: dial-plan-rule-1=1XXX=>650466${DIGITS} dial-plan-rule-2=3XXX=>925266${DIGITS}
In this case, the CBN for extension
1334
will be
6504661334
. For extension
3592
the CBN will be
9252663592
. In this example, for extensions that do not start with either 1 or 3 rules will not be applied and DID will not be allowed.
End of procedure
SIP Server—Deployment Guide 243
Chapter 5: SIP Server Feature Support E911 Emergency Gateway
Next Steps
•
Procedure: Assigning the EGW DN to the ANI-to-CBN dial plan
Procedure:
Assigning the EGW DN to the ANI-to-CBN dial plan
Start of procedure
1. Open the EGW
Trunk Group
DN.
2. In the
TServer
section of the EGW
Trunk Group
DN, configure the option
with the name of the dial-plan DN.
End of procedure
Next Steps
•
Procedure: Creating a dial-plan DN for the CBN to ANI conversion
Procedure:
Creating a dial-plan DN for the CBN to ANI conversion
Start of procedure
1. Create a
Voice over IP Service
DN with service-type
set to dial-plan
.
2. In the
TServer
section, create a dialing rule that will translate the 10-digit
CBN back to the original internal DN.
For example, to translate the CBN to the four-digit original extension, configure the dialing rule as follows: dial-plan-rule-1=XXXXXXXXXX=>${DIGITS:-4:4}
End of procedure
Next Steps
1. Configure the endpoints. See the Step 4 in the
Server for E911 Emergency Gateway
.
2. After the endpoints are configured, continue at Procedure: Installing and
244 Framework 8.1
Chapter 5: SIP Server Feature Support E911 Emergency Gateway
Procedure:
Configuring the call path (DID not allowed)
Purpose: For environments that do not allow DID calls, you must create a
Trunk
DN for the EGW.
Start of procedure
1. Create a
Trunk
DN to represent the EGW. The name does not matter (SIP
Server uses the prefix for Trunk selection).
2. In the
TServer
section, configure the following options:
•
contact
—Enter the IP address for the primary EGW.
•
emergency-backup
—Enter the IP address for the alternate route. This must be the address for the backup EGW.
•
emergency-device
—Set this option to true to enable this device to conduct emergency calls.
•
prefix
—Enter a prefix that SIP Server will use to find this DN. This prefix should match numbers from the pool chosen by the administrator of the EGW for dynamic callback.
End of procedure
Next Steps
1. Configure the endpoints. See the Step 4 in the
Server for E911 Emergency Gateway
.
2. After the endpoints are configured, continue at Procedure: Installing and
Procedure:
Installing and Configuring the Utility
Purpose: To install and configure the Perl utility on Ubuntu Linux. The Perl utility
911_Enable.pl
and an example of the configuration file
911_Enable.cfg
can be found in the folder tools
located in the SIP Server installation folder, together with the SIP Server executable file.
As for June 2017, there is no straight-forward procedure to install the script dependency on Windows. It is recommended to use Ubuntu 16.04 Virtual
Machine installed on Oracle Virtual Box or VMware Player.
SIP Server—Deployment Guide 245
Chapter 5: SIP Server Feature Support E911 Emergency Gateway
Start of procedure
1. Install the following SOAP::Lite and NET::Telnet packages:
•
sudo apt-get install libsoap-lite-perl
•
sudo apt-get install libnet-telnet-perl
2. Create the .cfg file required by the utility.
•
[cfgserver]
—Specifies the regular Configuration Server attributes—for example, tenant name, switch name—as well as which
Extensions should be uploaded to the Emergency Gateway. The port parameter in this file does NOT correspond to the port option as set in the confserv
section of Configuration Server. It instead corresponds to the port option as defined in the soap section.
•
[egw]
—Specifies the Emergency Gateway FTP server attributes.
For example, the following shows sample content for a
.cfg file.
[cfgserver]
#host=<config server hostname or IP> host = host12345
#port=<config server port> port=3034
#username = <config server username> username = default
#password = <config server password> password = password tenant = tenant12345 switch = sip_server_switch
[egw] host=172.21.83.197
username=batchendpoint password=911batch
3. Name the
.cfg
file.
If you are going to supply the name for this
.cfg
file as a parameter, then you can use any name with the suffix
.cfg
. For example, your utility and configuration files could be named as follows:
Perl 911_Enable.pl 911_Enable_sip1.cfg
However, if you will be starting the utility without any arguments, then you must use the same filename for both configuration and utility files. For example,
Perl 911_Enable.pl 911_Enable.cfg.
4. Place this
.cfg
file in the same working directly as the
.pl
utility file.
5. For multiple SIP Server instances, create a separate
.cfg
file for each SIP
Server instance. You must start the utility once for each instance.
End of procedure
246 Framework 8.1
Chapter 5: SIP Server Feature Support Early Media for Inbound Calls
Early Media for Inbound Calls
SIP Server supports the exchange of early media before a particular session is accepted—for example, to provide an audio treatment before the call is answered, thereby avoiding toll charges for the caller.
SIP Server provides support for early media through the offer/answer exchange of provisional responses (
183 Session Progress
) and
UPDATE
requests, to manage the session parameters (SDP) that are required to deliver the early media. All early media dialog activity takes place before the
200 Ok
response.
Once the call is established (
200 Ok
is sent), no further toll-free services are possible.
NETANN Sample Call Flow
The following NETANN sample call flow demonstrates the signaling that is used to provide early media for an inbound call in case of early media support
(note that all dialog activity takes place before the
200 Ok
response):
1. An inbound call arrives at a Routing Point from a gateway that is enabled
for SIP early dialog ( sip-early-dialog-mode
1
true
).
2. A treatment is applied. SI P Server sends a reliable
183 response with an answer to the calling-party offer.
3. The next treatment is applied. SIP Server sends an
UPDATE
with a new offer to the calling party.
4. The call is routed to the agent. The connection with the agent is initiated and completed using
UPDATE
. The dialog is then switched to the accepted state by sending a
200 OK
to the initial
INVITE
request, at which point no additional toll-free services are possible.
Introduced in
SIP Server
8.1.102.25
Controlling Early Media with a Routing Strategy
With the Early Media for Inbound Calls feature enabled, this enhancement (a new
extension key) enables you to create a routing strategy that
does the following for an inbound call:
•
Switch audio treatments from cost-free early media to an established state
(charged) in a SIP dialog, which can be made at the initial
TApplyTreatment or at any sequential
TApplyTreatment
. All consecutive audio treatments in this dialog will be charged.
•
Play initial audio treatments in cost-free early media in deployments that are configured to play audio treatments at a cost, until a
TApplyTreatment request containing the charge-type
key set to 2 (charged) arrives.
The transition from early media to an established state can be made only once within a SIP dialog and only when changing from cost-free audio treatments to charged audio treatments.
SIP Server—Deployment Guide 247
Chapter 5: SIP Server Feature Support Emulated Agents
This functionality is supported for MSML deployments and is not supported for NETANN deployments.
To configure controlling early media with a routing strategy, see Step 4 in
.
Feature Configuration
Support for the
UPDATE
method for cost-free early media is configured by using the options sip-early-dialog-mode
and charge-type
describes how to configure this feature.
Table 61: Enabling Cost-Free Early Media
Objective
1. Configure the gateway
Trunk
DN.
Related Procedures and Actions
To support the the
Trunk follows:
UPDATE
DN (in the
method for early media exchange, configure
TServer section) for the incoming gateway as
• Set the
option to
1
.
OR
• Set the
option to true.
2. Configure the SIP device.
3. Configure the SIP Server
Application.
4. (Optional) To control early media with a routing strategy
Enable cost-free early media service on applicable DNs as follows:
•
Voice over IP Service
option at the default setting of
0
.
•
Trunk Group
or
Extension
DNs—Set charge-type
to
1.
Genesys recommends that you also configure the SIP Server
Application as follows:
• In the
TServer
section, set ringing-on-route-point
to false
.
In the routing strategy, specify the
AttributeExtensions
of the
TApplyTreatment
request.
Feature Limitation
SIP Server supports
UPDATE
requests with SDP only for early dialogs and does not support
UPDATE
requests for established dialogs.
Emulated Agents
SIP Server fully emulates business-call–handling functions. It also performs agent emulation for any agent who logs in using a request, when the device provided in the
ThisQueue
attribute is defined as a Routing Point or ACD
Queue in the SIP Server configuration.
248 Framework 8.1
Chapter 5: SIP Server Feature Support Emulated Agents
SIP Server provides a fully functional agent model that enables full agent support for SIP Server desktop applications as well as for other Genesys solutions.
Business-Call Handling
This section describes how SIP Server handles different types of calls.
SIP Server Call Classification
SIP Server automatically assigns every call to one of three categories—business, work-related, or private. Based on this assignment, SIP
Server applies the appropriate business-call handling after the call is released.
Business Calls
SIP Server automatically categorizes any call distributed to an agent either from a Queue or from a Routing Point as a business call. Use the following configuration options to define what additional calls to or from an agent are classified as business calls:
•
•
•
•
•
•
•
Work-Related Calls
SIP Server categorizes any call that an agent makes while in the busy (with a business call), After Call Work (ACW), or aux-work state as a work-related
call. SIP Server does not apply any automatic business-call handling after a work-related call.
Agents can make or receive direct work-related calls while in wrap-up time. If an agent makes a work-related call during this wrap-up time, the call is considered part of the wrap-up activities, and SIP Server continues the emulated wrap-up timer. If the agent receives a call, however, the call is considered unsolicited—not part of the wrap-up activities—and so SIP Server pauses the timer for the duration of this call.
If an agent receives a direct work-related call during legal-guard time, SIP
Server cancels the legal-guard timer and reapplies it at the end of the workrelated call.
SIP Server—Deployment Guide 249
Chapter 5: SIP Server Feature Support Emulated Agents
Private Calls
SIP Server categorizes any call that does not fall into the business or workrelated categories as a private call. SIP Server does not apply any automatic business-call handling after a private call. If emulated agents receive a direct private call while in wrap-up or legal-guard time, the emulated wrap-up or legal-guard timer is not interrupted.
Emulated Agents Support
SIP Server provides a fully functional emulated-agent model that you can use either in addition to agent features available on the PBX, or in place of them where they are not available on the PBX.
When this feature is used, SIP Server emulates the following functionality:
•
Login and logout
•
Agent set Ready
•
Agent set Not Ready (using various work modes)
•
Automatic after-call work
•
After call work in idle
•
Automatic legal-guard time to provide a minimum break between business-related calls
Emulated Agent Login/Logout
You can configure SIP Server to perform emulated login either always, never, or on a per-request basis. Use the following SIP Server configuration options to configure emulated agent login:
•
•
Agent Logout on Client Unregistering from DN
In some scenarios (such as a desktop crash or power failure/disconnection), agents may still receive calls but be unable to handle them. To prevent this problem, SIP Server can be configured to automatically log the agent out in such circumstances.
When a client desktop or application disconnects from the SIP Server while an agent is still logged in, the SIP Server receives a notification that the application is unregistering from the agent’s DN. Also, the SIP Server is able to uniquely identify the client application which sends a T-Library request, including
TAgentLogin
and
TRegisterAddress
.
The SIP Server can associate the client application (the one that sends the initial
TAgentLogin
request) with the agent and automatically log that agent out when the client application unregisters the agent DN while the agent is still
250 Framework 8.1
Chapter 5: SIP Server Feature Support Emulated Agents logged in. (The initial
TAgentLogin
request is the one which first logs the agent in).
This feature is enabled/disabled by the following configuration options:
•
•
•
Emulated Agent Ready/NotReady
Emulated agents can perform an emulated
Ready or
NotReady
request regardless of whether they are on a call, subject to the rules governing work modes.
SIP Server also reports any change in agent mode requested by the agent while remaining in a
NotReady
state (self-transition).
Note:
Note that the Genesys Events and Models Reference Manual and the
Platform SDK 8.x .NET (or Java) API Reference define which agent state/agent mode transitions are permissible.
Timed and
Untimed ACW
Events and
Extensions
Emulated After-Call Work
SIP Server can apply emulated wrap-up (ACW) for agents after a business call is released, unless the agent is still involved in another business call (see
“Business Calls” on page 249 ).
SIP Server applies emulated ACW for an agent after any business call is released from an established state. SIP Server automatically returns the agent to the
Ready
state at the end of a timed ACW period. The agent must return to the
Ready
state manually when the ACW period is untimed.
SIP Server indicates the expected amount of ACW for an agent in
EventEstablished,
using the extension
WrapUpTime
. It is not indicated in
EventRinging, because the value may change between call ringing and call answer. Untimed ACW is indicated by the string value untimed;
otherwise, the value indicates the expected ACW period in seconds.
SIP Server reports ACW using
EventAgentNotReady
with workmode
=
3
(
AgentAfterCallWork
), and it indicates the amount of ACW it will apply using the extension
WrapUpTime.
SIP Server sends
EventNotReady(ACW)
before
EventReleased at the end of the business call.
Emulated ACW Period
The amount of emulated ACW that SIP Server applies (when required) after a
business call is determined by the value in configuration option wrap-up-time .
SIP Server—Deployment Guide 251
Chapter 5: SIP Server Feature Support Emulated Agents
Configuration option
integer value of wrap-up-time
indicates untimed ACW. To specify untimed
ACW in request extensions or user data, you should use the string untimed instead. All positive integer values are treated as indicating timed ACW (in seconds). For backward compatibility, the default value of untimed-wrapup-value
is
1000
.
Note:
Changing the value of untimed ACW should be done with care, because it may affect the interpretation of all integer values of the option wrap-up-time
in the Configuration Layer. If lowered, it may change timed ACW to untimed ACW, or disable ACW altogether. If raised it may change untimed or disabled ACW to timed ACW. The use of the option (string) value
untimed
is encouraged where possible to minimize the impact of any future changes to the value of option untimed-wrap-up-value
.
ACW in Idle
An agent can activate wrap-up time on request when idle, by issuing a
TAgentNotReady request with workmode
=
3 (AgentAfterCallWork)
.
You can configure this feature using the following options:
•
•
Extending ACW
An agent can request an extension to the amount of emulated ACW for a call while in emulated ACW or in the legal-guard state.
The agent requests an extension to ACW by sending
RequestAgentNotReady with workmode
=
3 (AgentAfterCallWork)
. SIP Server determines the period of the extended ACW from the extension
WrapUpTime
, as follows:
•
Value =
0
—There is no change to the ACW period, but SIP Server reports how much ACW time remains.
•
Value greater than
0
—SIP Server adds the given number of seconds to the timed ACW period. Untimed ACW remains unaffected.
•
Value = untimed
—SIP Server applies untimed ACW.
SIP Server sends
EventAgentNotReady with workmode
=
3
(AgentAfterCallWork)
, reporting the newly extended amount of ACW using the extension
WrapUpTime
. If the agent was in the emulated legal-guard state,
SIP Server places the agent back into the emulated ACW state.
The agent may extend the period of ACW as many times as desired. At the end of the extended timed ACW period, SIP Server applies legal-guard time, if any is configured. No legal-guard time is applied if the emulated ACW was untimed.
252 Framework 8.1
Chapter 5: SIP Server Feature Support Endpoint Service Monitoring
Calls While in Emulated ACW
SIP Server’s handling of an agent making or receiving a call while in emulated
ACW is governed by the configuration option
.
Emulated Legal-Guard Time
SIP Server applies emulated legal-guard time for agents before they are about to be automatically set
Ready
after any period of timed ACW, or after the last business call is released where there is no ACW to be applied. It is a regulatory requirement in many countries that agents have a break of a few seconds before the next call can arrive. No legal-guard time is applied if the ACW period was not timed, or if the agent is not being placed into the
Ready
state.
SIP Server reports legal-guard time using
EventAgentNotReady with workmode
=
2 (LegalGuard)
. If an agent requests to be logged out during emulated legal-guard time, SIP Server immediately logs the agent out.
If the agent requests to go to a
Not Ready
or
Ready state during legal-guard time, SIP Server terminates legal-guard time and transitions the agent to the requested state. If the agent requests to return to the ACW state, SIP Server reapplies legal-guard time at the end of ACW, provided that the agent still requires it according to the preceding criteria.
The period of legal-guard time is determined by the configuration option
Endpoint Service Monitoring
When SIP Server starts up, it considers that all DNs that are configured in the
Configuration Layer are in the
In Service
state.
SIP Server supports two methods for detecting whether a particular device is unavailable and needs to be placed in the out-of-service state:
•
Passive Out-of-Service Detection—SIP Server considers a device to be out-of-service after the SIP endpoint fails to respond to the incoming
INVITE
message during the creation of a new call.
Note:
Where SIP Server functions as an application server behind a softswitch, a DN is considered to be in
Out of Service
state if the softswitch responds with a
408 Request Timeout message to an
INVITE
message during creation of a new call.
•
Active Out-of-Service Detection—SIP Server checks the availability of the device by regularly sending SIP
OPTIONS
requests to the DN that represents the device.
SIP Server—Deployment Guide 253
Chapter 5: SIP Server Feature Support Endpoint Service Monitoring
Passive Out-of-Service Detection
In this method, when the SIP endpoint fails to respond to the incoming
INVITE message during the creation of a new call SIP Server generates an
EventDNOutOfService
message.
DNs are considered to be back in service in several scenarios:
•
When a SIP
REGISTER
message comes from the endpoint.
•
When an endpoint initiates a call by sending an
INVITE
message.
•
When an endpoint responds to an
INVITE
message via a
Ringing (OK) message.
•
When a timeout period, as configured by the recovery-timeout
expires. This option can be configured on
Trunk, Voice over IP Service,
Voice Treatment Port, Extension, or
ACD Position
DNs only.
Note:
Genesys recommends using Active Out-of-Service Detection for
Trunk
and
Voice over IP Servic e DNs. If Passive Out-of-Service
Detection is required for these DNs, you can enable the feature by setting
on these DNs to a non-zero value.
•
When the device entry in the Configuration Layer is changed.
An
EventDNBackInService
message is generated in all scenarios.
Note:
Trunk Group
DNs cannot be placed out of service. If a
Trunk Group
DN does not respond to an
INVITE
, the DN remains available for further call attempts.
Enabling Passive Out-of-Service Detection
To enable passive out-of-service detection, configure the following options in the
TServer
section of the corresponding DN:
•
•
Active Out-of-Service Detection
SIP Server supports Active Out-of-Service Detection that can be enabled for the following types of DNs:
•
Voice over IP Service
(msml, MCU, treatment, softswitches, and so on)
•
Trunk
•
Trunk Group
254 Framework 8.1
Chapter 5: SIP Server Feature Support Endpoint Service Monitoring
Enabling Active Out-of-Service Detection
To enable active out-of-service detection, configure the following options in the
TServer
section of the corresponding DN:
•
•
Note:
Genesys recommends that you not configure the recovery-timeout
option when using Active Out-of-Service Detection. This timeout is intended for Passive Out-of-Service Detection only.
However, if recovery-timeout
and Active Out-of-Service Detection are enabled at the same time, when the device is detected as out of service, and the recovery-timeout
is configured to a value less than the oos-check
value, SIP Server will wait the amount of time specified in the recovery-timeout
option before it checks if the device is back in service.
Pinging a Device using SIP OPTIONS message
The oos-check option specifies how often (in seconds) SIP Server sends
OPTIONS
messages to check the device for out-of-service status. When no response is received, and the
oos-force
option is configured, SIP Server waits until the specified oos-force
timeout expires before it places a device that does not respond in the out-of-service state.
Forwarding OPTIONS Through a Proxy
SIP Server provides the ability to configure the value of the
Max-forwards header used in the
OPTIONS
messages that SIP Server sends to check the
availability of a particular SIP device. The DN-level option oos-options-maxforwards
allows a proxy device to forward the
OPTIONS
message to the monitored device, when SIP Server and the monitored device do not share a direct connection. For example, when a session border controller (SBC) sits between SIP Server and the switch where the monitored DN is registered.
Log Messages
For
Voice over IP Service
DNs, SIP Server generates the following log message stating that the specified device is out of service based on Active Outof-Service Detection:
52000|STANDARD|GCTI_DEVICE_OUT_OF_SERVICE|Device [the name of the device] is out of service
SIP Server—Deployment Guide 255
Chapter 5: SIP Server Feature Support Failed Route Notification
For
Voice over IP Service
DNs, SIP Server generates the following log message stating that the specified device is back in service based on Active
Out-of-Service Detection:
52001|STANDARD|GCTI_DEVICE_BACK_IN_SERVICE|Device [the name of the device] is back in service
Failed Route Notification
SIP Server supports a variety of alarm messages for unsuccessful routing scenarios.
When this feature is enabled, a failed route timer is set using the interval defined in the
configuration option. Each routing
failure reported during this period is added to a counter. If this counter exceeds
a “high water mark” threshold value defined by the route-failure-alarmhigh-wm
configuration option, SIP Server sets a route failure alarm condition and resets the counter.
The alarm condition is cleared when fewer route failures than configured in the
configuration option are recorded and there is also no more than the number of route failures configured in route-failurealarm-high-wm in one complete period (configured in route-failure-alarmperiod).
Setting the value of the
0
(zero) disables the feature.
High-Availability Considerations
Only the primary SIP Server maintains the failed routing counter. The backup
SIP Server will not run the route-failure-alarm-period
timer, and keeps the routing failure alarm in the canceled state.
On switchover from primary role to backup role, SIP Server stops the routefailure-alarm-period timer and clears any alarm internally, without sending any
LMS message.
On switchover from backup role to primary role, SIP Server starts the routefailure-alarm-period
timer and starts counting route requests and routing failures.
256 Framework 8.1
Chapter 5: SIP Server Feature Support Find Me Follow Me
Feature Configuration
describes how to configure this feature.
Table 62: Configuring Failed Route Notification
Objective
Configure the SIP Server
Application.
Related Procedures and Actions
In the SIP Server
Application
>
Options
>
TServer
section, configure these options:
•
—Set the duration for the failed routing
timer.
Failed attempts during this period are added to the counter.
•
—Set the high water mark (number of
routing attempts).
If the counter reaches this number during the failure period, an alarm is sent and the counter is reset.
•
—Set the low water mark after which the
alarm condition is cleared.
Find Me Follow Me
Introduced in
SIP Server
8.1.101.75
SIP Server supports the SIP Feature Server Find Me Follow Me functionality for any 1pcc and 3pcc calls where Feature Server dial plans are applied to destinations. The feature is supported for MSML–based environments.
For this feature, SIP Server supports:
•
Sequential dialing (SIP Server dials all locations sequentially)
•
Parallel dialing (all locations are dialed simultaneously)
•
Early media for inbound calls
SIP Server—Deployment Guide 257
Chapter 5: SIP Server Feature Support Genesys Voicemail
Feature Configuration
describes how to configure Find Me Follow Me on the SIP Server side. Refer to the SIP Feature Server documentation for more information.
Table 63: Configuring Find Me Follow Me
Objective
Configure the SIP Server
Application.
Related Procedures and Actions
In the SIP Server
Application
>
Options
>
TServer
section, configure these options:
•
—(Optional) Specify the filename of the
confirmation prompt.
•
—(Optional) Specify the digit that a caller must enter for call confirmation. This digit could be included in the prompt to be used for human recognition.
•
—(Optional) Specify the timeout value, in seconds, that SIP Server waits for a confirmation digit to be entered.
•
—Specify the Trunk Group DN where events are
generated, when each destination leg connects to Media Server.
•
true.
Feature Limitations
•
Find Me Follow Me is not compatible with agent state monitored by Stat
Server. If calls routed to agents have Find Me Follow Me rules applied, then the state of the DN where the agent is logged in might not be changed when the call is delivered to a non-monitored agent phone, and the next call could be delivered to the same agent.
•
Early media is not supported for outgoing calls.
•
Media service recovery is not supported with Find Me Follow Me. If an
MSML dialog for call confirmation fails, SIP Server handles it as successful confirmation.
Genesys Voicemail
SIP Server supports integration with Genesys SIP Feature Server, formerly known as Genesys SIP Voicemail (versions 8.1.0 and 8.1.1). Genesys SIP
Feature Server (version 8.1.2 or later) is a SIP-based voicemail and SIP feature manager for Genesys contact centers and enterprise environments. Callers leave voicemail, and users retrieve and manage that voicemail. Administrators manage users, devices, voicemail, and call disposition (the dial plan). A distributed architecture enables scalability and enhances performance.
258 Framework 8.1
Chapter 5: SIP Server Feature Support HTTP Live Streaming
SIP Server also supports SIP Voicemail of SIP Feature Server in a Business
Continuity deployment. This feature requires SIP Feature Server version 8.1.2 or later.
Supported voicemail features:
•
Voicemail deposit and retrieval
•
Group voicemail deposit and retrieval for Agent Groups only
•
SIP and T-Library MWI notifications
For all configuration details relating to this integration, including DN configuration, refer to the SIP Feature Server documentation .
Reliability And Voicemail Session Recovery
Starting with version 8.1.101.42, SIP Server supports reliability and voicemail session recovery if it detects a problem (such as unresponsiveness or error response) on an attempt to initiate a voicemail session on a Media Server.
Depending on the type of problem, SIP Server may try to restart the session on an alternate available service or a different MSML object for an Active-Active
Resource Manager deployment, or it may try a different voicemail device for an Active-Standby voicemail deployment.
HTTP Live Streaming
Introduced in
SIP Server
8.1.102.28
SIP Server supports HTTP Live Streaming (HLS) in the following scenarios:
•
When treatments are applied on a Routing Point
(
TreatmentPlayAnnouncement/TreatmentMusic
)
•
For music-on-hold treatments, when a call on the DN is placed on hold, or when a call is waiting on an ACD Queue
The feature is available through the MSML protocol.
Feature Configuration
To use this feature, SIP Server must be integrated with MCP version
8.5.161.34 or later.
1. In the SIP Server configuration, do the following as required:
For music-on-hold treatments, either at an Application or DN level, specify the proper URL to HTTP Live Streaming server in the default-music
option.
For example: default-music=http://123.45.678.90/hls/audio
For music treatments, in a routing strategy, specify the URI to the
HTTP Live Streaming server in the
MUSIC_DN
treatment parameter.
For announcements, in a routing strategy, specify the URI to the HTTP
Live Streaming server in the
TEXT
treatment parameter.
SIP Server—Deployment Guide 259
Chapter 5: SIP Server Feature Support HTTP Monitoring Interface
2. In the MCP configuration, specify the format of audio segments in the transcoders parameter. For example: if audio segments are encoded in the
MP3 format, you must add
MP3
into the list of transcoders, as follows:
[mpc].transcoders=G722 GSM G726 G729 MP3
HTTP Monitoring Interface
Introduced in
SIP Server
8.1.102.13
SIP Server provides the ability to monitor various operational statistics for its internal modules and statistics relating to trunks. See the
Supplement to the SIP
Server Deployment Guide for more information.
Hunt Groups
Sequential ringing introduced in
SIP Server
8.1.101.27
Support for BC deployments added
SIP Server supports the Hunt Groups feature as a type of call coverage to distribute incoming calls to a statically configured group of extensions. The
Hunt Group call distribution strategy (sequential or parallel) controls how a call is propagated to one or to all extensions within the group.
Starting with version 8.1.101.49, Hunt Groups with the parallel distribution strategy (simultaneous ringing) are supported in Business Continuity deployments. See the SIP Server 8.1 High-Availability Deployment Guide for details.
How It Works
Hunt Group members are Extension DNs or ACD Position DNs listed in the
option. In contrast to the typical Genesys call distribution using a routing point, URS/ORS and Stat Server, Hunt Group does not rely on or require any login. Hunt Group distribution does take into account the status of each DN, and will distribute calls only to those DNs which meet the following criteria:
•
DN must be in-service
•
DN must be idle (not in a call)
•
DN must not have DND or Call Forwarding set on SIP Server
In a sequential call distribution, SIP Server selects one of the available Hunt
Group members as a target for the call distribution. If the Hunt Group member answers the call, the call is diverted from the Hunt Group and the distribution is complete. If the call is rejected by the Hunt Group member, or not answered within a specified period of time ( hg-noanswer-timeout
), SIP Server selects the next available Hunt Group member for a call distribution. Depending on the configuration, SIP Server uses one of the following strategies for Hunt Group member selection:
260 Framework 8.1
Chapter 5: SIP Server Feature Support Hunt Groups
•
Linear hunting—SIP Server always distributes the calls to the first Hunt
Group member, then to the second, to the third, and so on. Hunting stops at the last Hunt Group member.
•
Circular hunting—SIP Server distributes the calls in a round-robin fashion.
If a call was previously delivered to the first Hunt Group member, the next call SIP Server distributes to the second member, and so on. The succession throughout each of the Hunt Group members continues even if one of the previous members becomes available. When a list of Hunt
Group members is exhausted, the hunting starts over at the first member.
Hunting stops at the Hunt Group member who answered the previous call.
That is, SIP Server makes only one circle through the Hunt Group member list.
In a parallel call distribution, when any Hunt Group member answers the call, the call is diverted from the Hunt Group and SIP dialogs with the non-answered Hunt Group members are dropped. This SIP Server behavior is known as divert-on-answer and works differently from the usual queue
distribution enabled by the divert-on-ringing
configuration option. For the
Hunt Groups feature, you do not need to set the divert-on-ringing
option to false
. The
option triggers that by default.
The call distribution is considered unsuccessful if:
•
None of the Hunt Group members answers the call.
•
There are no available Hunt Group members during the specified period of time ( hg-queue-timeout
).
•
The number of queued calls on the Hunt Group exceeds the specified limit
( hg-queue-limit
).
The unanswered call is distributed to the default destination if it is configured; otherwise the call is released.
It is not recommended to use Extension or ACD Position as the default-dn destination for the Hunt Group to avoid call overflow at that DN. A Routing
Point DN should be used instead.
Note:
Configuration of the default-dn
as a member of the Hunt Group is not supported.
Call forward redirection from a SIP endpoint or from an agent desktop application like Interaction Workspace will be ignored for calls distributed from a Hunt Group. Calls distributed by the Hunt Group to a member will not be diverted to the member's mailbox if there is no answer.
Feature Configuration
describes how to enable this feature.
SIP Server—Deployment Guide 261
Chapter 5: SIP Server Feature Support Hunt Groups
Table 64: Configuring Hunt Groups
Objective Key Procedures and Actions
Configure a DN of type
ACD Queue
.
Go to
Switch
>
DN
object of type
ACD Queue, Annex
tab >
TServer
section and configure the following options:
•
—Specify the type of Hunt Group algorithm that is used to deliver calls to Hunt Group members.
•
—Specify members of the Hunt Group by listing DNs separated by a comma.
•
—Set the period of time that a call distributed to the
members waits to be answered by a member.
•
—Set the period of time that a call can remain in the
Hunt Group (while all Hunt Group members are not reachable) before being sent to Hunt Group members.
•
—Set a maximum number of calls that can be queued on
the Hunt Group at the same time.
•
—Set the period of time during which SIP Server will not distribute calls to the Hunt Group member’s device after it answers with an error.
•
—(Optional) Specifies the default destination where a call is distributed if one of the following conditions occurs:
expires
expires
is exceeded no correct Hunt Group members are defined
• If the Hunt Group does not have the
option defined, SIP
Server uses the Application-level default-dn instead.
Feature Limitations
•
Hunt Groups are not compatible with SIP Server’s Early Media feature. A call to a Hunt Group will be immediately connected, which typically results in the caller being charged before the call is answered by an agent.
•
Predictive calls (initiated by the TMakePredictiveCall request) are not supported. If a predictive call arrives at a Hunt Group, it will be rejected by the Hunt Group.
•
Hunt group is not supported in deployment with IMS (double-triggering).
•
A DN with nailed-up connection ( line-type=1
) must not be a member of a
Hunt Group.
•
DNs of the Hunt Group members must be located on the same switch as the Hunt Group.
262 Framework 8.1
Chapter 5: SIP Server Feature Support IMS Integration
•
Calls distributed from a Hunt Group will not invoke the external Feature
Server dial plan.
•
It is not possible to use the Call Pickup feature to answer ringing calls for members of the Hunt Group. An attempt by a Hunt Group member to answer a call using the Call Pickup feature will be rejected.
•
1pcc semi-attended, 3pcc semi-attended, and 3pcc mute transfers to a Hunt
Group destination are not supported.
IMS Integration
SIP Server supports integration with IP Multimedia Subsystem (IMS) environments. In an IMS architectural framework, SIP Server is configured as the SIP Application Server (SIP AS), which provides the interface with the
Serving-Call Session Control Function (S-CSCF) to deliver the suite of
Genesys applications to the IMS network.
Genesys Contact Center in the IMS Network
When integrated into an IMS network, Genesys provides the following Contact
Center (CC) functions:
•
SIP Server provides the interface between the IMS network and the
Genesys suite.
•
Genesys Stream Manager provides the dedicated Media Resource Function
(MRF, providing media services to Genesys applications (at the signaling level, it does not communicate directly with the IMS core).
•
Genesys Contact Center agents assume the role of IMS users.
Introduced in
SIP Server
8.1.101.20
Routed Calls as Originating or Terminating
In IMS deployments, SIP Server can route calls parked on a Media Server using a call-originating leg or terminating leg. Call-originating legs, compared to call-terminating legs, contain the orig parameter in the Route header of an
INVITE request that SIP Server sends to the IMS.
Originating legs are subject to HSS interactions and might pass through a chain of application servers serving originating calls. Note that this processing consumes network and CPU resources.
For more information about termination and initiation INVITEs in the IMS, see the 3GPP TS 24.229 V9.0.0 (2009-06)—Technical Specification 3rd
Generation Partnership Project; Technical Specification Group Core Network and Terminals; IP multimedia call control protocol based on Session Initiation
Protocol (SIP) and Session Description Protocol (SDP).
SIP Server—Deployment Guide 263
Chapter 5: SIP Server Feature Support IMS Integration
Feature Configuration
.
describes how to integrate SIP Server into an IMS network.
Table 65: Integrating SIP Server with IMS
Objective Related Procedures and Actions
1. Configure the SIP Server
Application.
2. Configure IMS endpoints.
In the SIP Server
Application > Options > TServer
section, configure these options:
•
—Set this to
1
.
•
*
—Set this to the SIP URI for the S-CSCF.
•
*
—Set this to the value configured for the IFCs in the IMS Service Profile.
* These options are not used in the alternative deployment with
Mediation Proxy.
Routed Calls as Originating or Terminating:
To route calls parked on a Media Server using a call-terminating leg, set
to true
.
Go to SIP Server switch
>
DNs
folder.
1. Create a DN of type
Extension
.
2. In the
TServer
section, configure the following options:
—Set to true
.
false
.
3. Do this for every IMS endpoint that is to be integrated into the contact center.
3. Configure the S-CSCF Trunk.
Go to SIP Server switch
>
DNs
folder.
1. Create a DN of type
Trunk
.
2. In the
TServer
section, configure the following options:
—Set to the IP address of the S-CSCF.
—Set to the value of the domain served by
SIP Server used in this particular IMS deployment.
false
.
—Set to any valid SIP URI for the S-CSCF.
—Set to true
.
Note:
describes the minimum mandatory options only. Other options, including IMS-specific options, may be configured as well.
For a list of all IMS-related options, see “IMS-related options” in the
Index.
264 Framework 8.1
Chapter 5: SIP Server Feature Support Instant Messaging
Instant Messaging
SIP Server supports the Instant Messaging (IM) media type as follows:
•
A special SDP message for the IM media type is supported within the SIP
INVITE
dialog.
SIP Server generates IM messages with SDP in the form accepted by
Microsoft Live Communication Server, Office Communicator, and MS
RTC stack.
1
SIP Server supports standard SIP call flows for IM, and the SIP
INVITE messages are assumed to be the same for the IM sessions. SIP Server produces the same TEvents for the IM sessions as it does for voice calls.
•
A SIP
MESSAGE
request method is supported within an established
INVITE dialog to exchange instant messages within a SIP session.
•
The content of an instant message can be distributed via a
EventUserEvent message to a DN of type
Communication DN
with the name gcti::im
.
Any application that need to receive the content of any instant message must register this DN. When a SIP Server
MESSAGE
request is received by the SIP Server IM session, SIP Server informs its clients by distributing an
EventUserEvent
message. The client applications can then perform additional tasks in response to the IM content.
Support for multisite and BC deployments added
Starting with release 8.1.101.97, Instant Messaging (IM) functionality is
supported in multi-site and Business Continuity deployments. See “Instant
Messaging For Multi-Site Calls” on page 270 .
Instant Messaging Transcript
SIP Server supports exchanging instant messages via T-Library within the established call context. This enables applications, such as Agent Desktop, to display instant messages that were sent or received during a conversation, including a chat transcript, and send an instant message to other parties on the call.
The instant message is delivered to a T-Library client via
EventPrivateInfo messages. A T-Library client can send an instant message using a T-Library request
TPrivateService.
SIP Server distributes the
EventPrivateInfo
message when one of the participants in the call sends an instant message. The
EventPrivateInfo message is sent to all other participants in the call.
AttributeExtensions
of the
EventPrivateInfo
message contains information about the instant message.
1.This format is described in the document [MS-CONFIM]: Centralized Conference
Control Protocol: Instant Messaging Extensions, currently located at http://msdn.microsoft.com/en-us/library/cc431500(v=office.12).
SIP Server—Deployment Guide 265
Chapter 5: SIP Server Feature Support Instant Messaging
SIP Server distributes
EventPrivateInfo
messages with the Instant Messages
Transcript when a new participant is added to the call as a result of a transfer or conference operation. The Instant Messages Transcript contains all instant messages that were previously exchanged between the participants in the call.
EventPrivateInfo
with the transcript is sent to the new participant who was added to the call.
The following keys are supported:
•
im
—Contains the text of the instant message.
•
im-content-type
—Contains the value provided in the
Content-Type
header of the SIP message that delivered IM.
•
im-transcript
—Contains the transcript of the IM call. The value of this extension is a string containing an XML document that complies with the
Genesys Multimedia Chat Transcript Schema.
Note:
Transcript data delivery is only supported via T-Library.
Supported Call Operations
This section describes call operations within an IM session.
Preview Interaction
SIP Server supports sending a preview interaction to an IM-enabled DN, allowing the IM user to accept or reject the request before SIP Server establishes the actual IM session. With preview interaction for IM enabled, SIP
Server processes the IM call as follows:
1. The IM client initiates an IM to a
Routing Point
DN on SIP Server.
2. The strategy routes the call to the IM-enabled DN. The
RequestRouteCall includes the
Preview
key-value pair in the
Extensions
attribute.
For example,
AttributeExtensions [75] 00 02 00 00..
'Preview'(list) 'Accept call?' 'respond 'yes' or 'no''
3. SIP Server initiates a preview IM to the selected DN. The preview includes the following message: gsipudata@<IP_address>
Preview
Accept call?: respond ‘yes’ or ‘no’
4. If the DN responds with a
‘yes’
, SIP Server initiates the main IM dialog.
If the DN responds with a
‘no’
, SIP Server returns the call to the routing point.
To enable this preview mechanism, set the preview-interaction
option on the
IM DN to chat
.
266 Framework 8.1
Chapter 5: SIP Server Feature Support Instant Messaging
Direct Calls
SIP Server supports direct 1pcc and 3pcc calls as follows:
•
Direct 1pcc calls—SIP Server processes direct 1pcc calls with IM media the same way as voice calls. SIP Server will specify
AttributeMediaType=5
(
TMediaChat
) in TEvents for such calls.
Note:
Only customers outside the contact center can initiate 1pcc IM sessions. In this case, the chat window does not open until after the call is routed to an agent.
•
Direct 3pcc calls—SIP Server processes a
TMakeCall
request for a call with
IM media, when it is specified in the
Extensions
attribute with the chat
key containing a value of true
. If it is not specified, SIP Server will process the
TMakeCall
request in the normal fashion.
Note:
For 3pcc IM calls from an Agent to a Knowledge Worker (as part of the UC Connect solution), the chat window can open while the call is still being handled by the routing strategy, and before the session is accepted and delivered to the Knowledge Worker. In this case, Genesys recommends that agents do not start entering information in the chat window until after the Knowledge Worker successfully enters the session, otherwise this information may not be delivered to the targeted Knowledge Worker.
Hold
SIP Server supports the Hold operation in the same manner as for voice calls.
The
Hold
request has no effect on the SIP signaling level for IM calls. SIP
Server will not re-
INVITE
SIP endpoints with different SDP dialogs when performing the
Hold
operation, because no changes in the SDP dialog are necessary.
Note:
SIP Server does not support Music On Hold (MOH) for IM calls.
Transfer
SIP Server supports transfers in the same manner as for voice calls. However there are some exceptions:
•
SIP endpoints that are already part of a call are not considered for re-INVITE
requests.
•
The IM SDP dialog is used to
INVITE
the SIP endpoint that is the call transfer destination.
SIP Server—Deployment Guide 267
Chapter 5: SIP Server Feature Support Instant Messaging
Single-step transfers are supported for non-conference calls. Single-step transfer of the conference is not supported.
Two-step transfers are supported for all calls. Agents can exchange IM text with each other during the consultation call. These IM text messages are not visible to the customer.
Conference
SIP Server supports conference for calls made within the IM session, and it is performed in the same manner as for voice calls. However, SIP endpoints that are already part of a call are not considered for re-
INVITE
requests. Also, unlike regular voice calls, SIP Server does not use Stream Manager to establish conference calls. SIP Server establishes an IM conference between the SIP endpoints itself, by issuing SIP
MESSAGE
requests to all conference participants.
Routing
SIP Server supports routing of IM calls using Universal Routing Server (URS) in the same manner as for voice calls. Multiple IM calls can be routed to the same agent. To achieve that, SIP Server distributes
AttributeMediaType set to
5
(
TMediaChat
) in TEvents for IM calls. URS and Stat Server can distinguish
IM calls by this attribute and, according to the configuration, route many calls with IM media to the same agent.
Treatments
SIP Server supports treatments for calls with IM media. However, unlike voice calls, SIP Server does not use Stream Manager to apply treatments. Instead,
SIP Server executes treatments for IM calls itself by using the SIP
MESSAGE request in accordance with the treatment request parameters.
SIP Server supports the following treatments for the IM calls:
•
PlayAnnouncement
•
CollectDigits
•
PlayAnnouncementAndDigits
The
PlayAnnouncement
treatment is performed by SIP Server when it sends the
MESSAGE
request to the caller. The
MESSAGE
request is sent for each prompt specified in the
TreatmentPlayAnnouncement
request. The content of the
MESSAGE request is created using the
TEXT
parameter in the prompt specified by the
TreatmentPlayAnnouncement
request. When processing the
TreatmentPlayAnnouncement
request for IM calls, SIP Server supports the
TEXT parameter only.
The
CollectDigits
treatment is performed by SIP Server when it receives the
MESSAGE
request from the caller, and it then sends the complete content of the
MESSAGE
request as collected digits to URS. When processing the
268 Framework 8.1
Chapter 5: SIP Server Feature Support Instant Messaging
TreatmentCollectDigits
request for IM calls, SIP Server supports the
TOTAL_TIMEOUT
parameter only. All other parameters are not supported.
The
PlayAnnouncementAndDigits
treatment is performed by SIP Server by performing
TreatmentPlayAnnouncement
and then
TreatmentCollectDigits
.
Note:
It is recommended that you start a routing strategy with
TreatmentCollectDigits
when applying treatments to an IM call because the strategy can collect the details of the initial IM and store it as
UserData
.
Supervision
SIP Server supports supervision functionality for IM calls, as described in
“Call Supervision” on page 143 . T-Library messaging for supervisor
monitoring scenarios for IM calls is the same as for voice calls, with the only exception that, for IM calls,
AttributeMediaType
is set to
5
(
TMediaChat
).
SIP Server supports the following call supervision modes for IM calls:
•
Silent monitoring
•
Whisper coaching
•
Open supervisor presence
SIP Server supports the following call supervision scopes for IM calls:
•
Agent
•
Call
SIP Server supports the following call supervision types for IM calls:
•
One call
•
All calls
Silent Monitoring for IM Calls
When silent monitoring is applied to the IM call, SIP Server uses the following algorithm to distribute instant messages:
•
Instant messages sent by a caller or an agent are visible to all participants: the caller, the agent, and the supervisor.
•
Instant messages sent by a supervisor are not visible to the caller or the agent.
Whisper Coaching for IM Calls
When whisper coaching is applied to the IM call, SIP Server uses the following algorithm to distribute instant messages:
•
Instant messages sent by a caller or an agent are visible to all participants: the caller, the agent, and the supervisor.
SIP Server—Deployment Guide 269
Chapter 5: SIP Server Feature Support Instant Messaging
•
Instant messages sent by a supervisor are visible to the agent only.
Open Supervisor Presence for IM Calls
When open supervisor presence is applied to the IM call, SIP Server uses the following algorithm to distribute instant messages:
•
Instant messages sent by caller or agent are visible to all participants: the caller, the agent, and the supervisor
•
Instant messages sent by supervisor are also visible to the all participants: the caller, the agent, and the supervisor
This mode is the same as the normal IM conference mode.
Multiple Instant Messaging Sessions
SIP Server supports the handling of several simultaneous IM sessions by one agent. You can define the maximum number of simultaneous sessions that are distributed by the Universal Routing Server to a particular agent by using a capacity rule for that agent. For more information about capacity rules, see the
Universal Routing 8.1 Reference Manual.
The agent can also handle one voice call and several IM sessions at once.
Instant Messaging For Multi-Site Calls
Starting with release 8.1.101.97, IM functionality is supported in multi-site and
Business Continuity deployments. The IM functionality is performed through a
T-Library client (Workspace Desktop). When an agent at the desktop makes an
IM input, SIP Server receives a
TPrivateService
request. The IM is delivered to the desktop via
EventPrivateInfo
messages. A SIP
INVITE
dialog establishes the IM session between SIP Servers, and a SIP
MESSAGE
message delivers the
IM sentence.
Supported Call Operations
The following call operations are supported within an IM session for multi-site calls:
•
Direct calls between agents using
TMakeCall
•
Routing
•
Treatments
•
Supervision
See “Multi-site or Business Continuity Deployments” on page 271
for information about how to configure the IM in those deployments.
See also limitations for the IM for multi-site calls on page 272
.
270 Framework 8.1
Chapter 5: SIP Server Feature Support Instant Messaging
Feature Configuration
Processing UserData
The following DN-level options are used to configure how
UserData
is processed:
•
•
•
Configuring Microsoft Office Communication Server
Microsoft Office Communicator is the client of Microsoft Office
Communication Server 2007 R2 (OCS 2007 R2). There is no direct communication link between SIP Server and Office Communicator; OCS 2007
R2 is the bridge in this scenario. As such, SIP Server is configured to register with OCS.
Note:
Starting in 8.0.3, SIP Server supports integration with Microsoft
Office Communications Server 2007 R2. For information about
configuring IM and presence with this server, see “Presence
Integration with Microsoft Office Communications Server 2007” on page 342
.
Configuring the Instant Messaging Solution
There are a number of ways to implement the Instant Messaging solutions in
Genesys. This includes enabling DNs in your contact center to handle instant messages after they arrive at SIP Server. Deploying the Instant Messaging solution requires configuring various Genesys components. For detailed information, see the Genesys 7.6 Instant Messaging Solution Guide, which consolidates possible Instant Messaging solutions and configuration information for each of them.
Multi-site or Business Continuity Deployments
•
On the Instant Messaging DN, in the
TServer
section, set the sipsignaling-chat
none
, so no SIP session with an agent endpoint is created for the IM call.
•
For the IM solution to work, make sure the following configuration options are enabled (set to true
) in the Workspace Desktop and Stat Server applications:
multimedia
SIP Server—Deployment Guide 271
Chapter 5: SIP Server Feature Support IPv6 Support
voice
Note:
If a URS/ORS application (a strategy) dedicated to serve IM calls uses
CollectDigits
or
PlayAnouncementAndDigits
treatments, the processing of these treatments should be started after the first
EventPrivateInfo
is received in the application's session. The
SuspendForEvent
URS function will suspend the strategy execution until URS receives the specified event. The
Type
parameter of the
SuspendForEvent
function must be set to the integer value
150
for
EventPrivateInfo
.
Instant Messages Encoding
SIP Server supports encoding of instant messages, received in SIP messages, from UTF-8 to a local character set and vice versa in T-Library messages. To enable instant messages encoding, in the
TServer
section of the SIP Server
Application object, configure the following options:
•
•
chat
area.
Feature Limitations
•
The
Page
mode for Instant Messaging is not supported.
•
In multi-site deployments, the route
or direct-uui
ISCC transaction types are required.
•
Instant Messaging transfers are not supported in multi-site deployments.
•
Instant Messaging conferences are not supported in multi-site deployments.
•
When an IM call is routed across sites, SIP Server will pass the IM transcript to the remote site if an ISCC transaction precedes the actual routing (route or direct-uui), but it will not pass the IM transcript to the remote site if an ISCC transaction follows the actual routing (such as Call
Overflow (COF)).
IPv6 Support
Genesys supports Internet Protocol version 6, commonly known as IPv6, as described in the
Framework 8.1 Deployment Guide
. The implementation of
IPv6 in Genesys is based on the following assumptions:
•
Dual-stack requirement and backward compatibility
•
Dual IPv4/IPv6 server sockets
•
IPv4 preference for DNS
272 Framework 8.1
Chapter 5: SIP Server Feature Support IPv6 Support
However, there are some peculiarities in how IPv6 is supported in SIP Server, compared to non-SIP related components:
•
IP addresses are often explicitly inserted in SIP messages, so SIP Server is aware of IPv4 vs. IPv6 differences.
•
Since SIP Server establishes communications between endpoints that are supposed to stream data to each other directly, the value of dual stack support is limited. IPv4 and IPv6 endpoints most likely are unable to talk to each other. So SIP Server configuration options target support of one type of endpoints, either IPv4 or IPv6.
To enable IPv6 support, SIP Server uses the transport address selection algorithm that conforms to RFC 3484, where local address selection is based on the destination address. SIP Server selects a local IPv6 address when its peer uses IPv6, and selects a local IPv4 address when its peer uses IPv4. An
FQDN resolving to a local IPv4 or IPv6 address can be used instead of explicit addresses.
Feature Configuration
IPv6 must be enabled by setting the
GCTI_CONN_IPV6_ON
environment variable on the machine where SIP Server is installed. Refer to the Framework 8.1
Deployment Guide for details.
In the SIP Server Application and DN configuration, options with the IP address or host name values can be explicitly set to a valid IPv6 address. Note that an IPv6 address is always placed between square brackets [ ]. You can also
configure the sip-fqdn-ip-version
configuration option to specify a preferred
IP version for FQDN resolution.
IPv6 Support by Genesys Components
SIP Server can work with Genesys Media Server using IPv6. DNs of type
Voice over IP Service,
for media services performed by GVP, must be configured with the
option set to the Resource Manager explicit IPv6 address. For more information about GVP component configuration, refer to the Genesys Voice Platform 8.1 Deployment Guide for details.
SIP Server can also work with SIP Proxy using IPv6. No changes are required in SIP Proxy.
High-Availability Considerations
For IP Address Takeover on Windows and Linux operating systems, to support
IPv6, you must use specific HA scripts. Refer to the latest
SIP Server 8.1 High-
Availability Deployment Guide for details.
SIP Server—Deployment Guide 273
Chapter 5: SIP Server Feature Support Keep Alive for TCP Connections
Feature Limitations
•
1pcc transfer by
REFER
with
Replaces
may fail if SIP Server receives a SIP
REFER
request with the
Replaces
parameter in the
Refer-To
header pointing to a dialog whose SIP
Call-ID
contains a % (percentage) character. This character may appear as part of the IPv6 address scope ID, and sometimes
IP addresses are used as part of the SIP
Call-ID
header.
•
IPv6 is only supported on Windows and Linux operating systems.
•
Support of dual stack is limited.
Keep Alive for TCP Connections
Introduced in
SIP Server
8.1.101.43
SIP Server provides the ability to detect stale TCP connections between SIP
Server and a SIP device using the TCP keep-alive mechanism. This functionality is recommended for those environments in which SIP endpoints are located behind a firewall that is configured to drop inactive TCP connections silently and without sending any notification to SIP Server. If SIP
Server tries to use a stale connection to initiate a new call or to execute call control, the attempt would fail. As a result, the SIP endpoint is placed to out of service.
When the TCP keep-alive mechanism is enabled, SIP Server sends keep-alive packets for all existing SIP connections. If there is no response for a configured time interval, and if there is an active transaction for this connection, SIP Server attempts to reopen the connection immediately and resends the last SIP request. If the connection does not have an active transaction, then it will be reopened only when a new transaction is initiated. If an attempt to open a connection for an active transaction fails, SIP Server releases the call.
For this feature to work with TLS over TCP, the SIP Endpoint must be able to accept the connection when SIP Server attempts to reopen it.
The TCP keep-alive mechanism does not replace the active OOS check, which should be configured as usual even if the TCP keep-alive feature is enabled.
Feature Configuration
1. Configure TCP keep-alive timeouts for your operating system. You can use the following links for your reference:
For Windows, see: http://technet.microsoft.com/en-us/library/cc957549.aspx
For Linux, see: http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/usingkeepalive.html
274 Framework 8.1
Chapter 5: SIP Server Feature Support Mapping Treatment Errors
2. In the
TServer
section of the SIP Server Application, configure the
configuration option to enable the TCP keep-alive functionality.
Feature Limitation
For
Voice over IP Service
DNs, SIP Server will not attempt to reopen the connection within an active transaction.
Mapping Treatment Errors
When SIP Server receives a SIP error from a media server (for example, from
GVP), it maps both the error code and error description into the
Extensions
Attribute of the corresponding
EventTreatmentNotApplied
message.
For example, when integrated with GVP for a URS-centric call flow (routing strategy controls the call), a failed Play Application treatment can result in either a SIP error message or an MSML error message. SIP Server maps these error messages, along with their description, to the resulting
TreamentNotApplied
message.
Sample SIP Error Mapping
SIP Server receives a
TApplyTreatment
request and translates that to a SIP
INVITE
request to GVP, with details to start a treatment. If the treatment fails to start, GVP responds with a SIP 4xx/5xx/6xx error code, which may also include a
Warning
header with an error description.
SIP Server sends a
TreatmentNotApplied
message in response to the original
TApplyTreatment
request, with the mapped key-value pairs included in the
Extensions
Attribute:
Attribute ErrorCode 50
AttributeExtensions
SipResponseCode 4xx/5xx/6xx
ResponseDescription “description”
Sample MSML Error Mapping
For MSML-based treatments, a failed treatment can result in either a SIP error or MSML error. For example, GVP may respond to a failed treatment by sending the following MSML error:
<result response=“423”/>
<description>error description</description>
From these fields, SIP Server maps the response
value in the result
tag, as well as the error description in the description
tag to the Extensions Attribute of the
TreatmentNotApplied
message.
For example,
SIP Server—Deployment Guide 275
Chapter 5: SIP Server Feature Support Mapping SIP Headers and SDP Messages
Attribute ErrorCode 50
AttributeExtensions
MsmlResponseCode 423
ResponseDescription <description>
For SIP errors, the same mapping takes place as it does for the NETANN sample above.
Feature Configuration
This feature is enabled by default. No configuration is required.
Mapping SIP Headers and SDP Messages
SIP Server can extract data from some incoming SIP messages and map it to either an
Extensions
or
UserData
attribute in T-Library event messages. SIP
Server can map T-Library request attributes (passed in the
TRouteCall message) to SIP parameters in the outgoing
INVITE
message. SIP Server can also map the whole SDP message body, or any particular line in it as
Extensions
or
UserData
attributes.
From SIP Messages to T-Library Messages
SIP Server processes SIP messages and can map related data to T-Library event attributes as described in this section. This information becomes further available to other Genesys Framework components. This functionality is supported for following SIP messages:
•
INVITE
•
INFO
•
UPDATE
•
REFER
• BYE
Note:
For proper processing of header values of incoming from GVP SIP messages and mapping them into
UserData,
the special characters such as commas (,) in the headers’ value must be encoded.
INVITE Messages
SIP Server can extract data from an incoming
INVITE
message and send the data to Universal Routing Server if the call is made at a Routing Point. Data is retrieved as values from the headers and parameters of the
INVITE
message and then populated into the
Extensions
or
UserData
attributes in the
EventRouteRequest
message. You can configure which headers and parameters
276 Framework 8.1
Chapter 5: SIP Server Feature Support Mapping SIP Headers and SDP Messages to extract data from by creating a section that corresponds to a SIP method name on the
Options
tab of the SIP Server
Application
object.
For example, the
INVITE
section lists the values of the headers and the header parameters that are extracted from the SIP message. The names of the options within this section contain a prefix, a dash (-), and a suffix, in the following format:
<prefix><-><suffix>
The prefix is the name of the TEvent attribute, and begins with either extensions
or
userdata
. The prefix extensions
instructs SIP Server to put the
SIP header or parameter into the
Extensions
attribute. The prefix userdata instructs SIP Server to put the SIP header or parameter into the
UserData attribute.
The suffix value is a number and must be unique for all option names containing the same prefix.
The option value determines which header in the header parameter of the SIP message is processed.
The value of the header or header parameter is added as a key-value pair into the attribute, using the form
<header_name>=<header_value>
. Use the colon character (
:
) to address the parameter name of a header. The SIP method
(
INVITE
) must be used instead of the header name if you want to populate the parameter from the SIP Request-line parameter.
If the names of the headers in the
INVITE
message start with the prefix configured in the userdata-map-trans-prefix
option, these headers will be mapped to
UserData
.
Mapping occurs only if both the following conditions are true:
•
The header or header parameter is contained within the incoming
INVITE message.
•
The header or header parameter is configured within the
INVITE
section.
As a result of mapping, the following key-value pair will be created within the
EventRouteRequest
message:
•
The key in the attribute will be equal to the value of the configuration option.
•
The value of the attribute will be equal to the value of the header or header parameter in the SIP
INVITE
message.
Note:
Data from an incoming SIP
INVITE
message received on a Routing
Point (via ISCC routing) that is located on the destination SIP Server cannot be extracted to
UserData
. In this case, use extraction to
Extensions
to obtain data from the
INVITE
message.
SIP Server—Deployment Guide 277
Chapter 5: SIP Server Feature Support Mapping SIP Headers and SDP Messages
INFO, UPDATE, and BYE Messages
SIP Server can generate an
EventAttachedDataChanged
message if it receives
SIP
INFO
,
UPDATE
, or
BYE
messages. Both the
UserData
attribute in the event and the corresponding call can contain information from the SIP message.
SIP Server supports two methods for mapping user data from
INFO
,
UPDATE
, and
BYE
messages into the
UserData
attribute in the T-Library event:
•
Mapping data from SIP headers
•
Mapping data from the body of
INFO, UPDATE,
and
BYE
messages
•
Mapping data from the MSML body of the
INFO
message
Mapping Data from SIP Headers in INFO, UPDATE, and BYE Messages
For this method, you must configure the
INFO
and
BYE
sections in the SIP
Server
Application
object to map data from these SIP messages to the corresponding T-Library events. The rules for this configuration are the same as the rules for configuring the
INVITE
section.
Also, if the headers from
INFO
,
UPDATE
, and
BYE
messages start with the prefix configured in the userdata-map-trans-prefix
option, these header will be mapped to
UserData
as well.
Note:
Only mapping to the
UserData
attribute is supported for the
INFO
and
BYE
messages. Therefore, the
INFO
and
BYE
sections can contain userdata-<n>
options, but they may not contain extensions-<n> options.
Mapping Data from the Body of INFO, UPDATE, and BYE Messages
For this method, you must configure the application that sends the SIP message to include the following header:
Content-Type: application/x-www-form-urlencoded
278 Framework 8.1
Chapter 5: SIP Server Feature Support Mapping SIP Headers and SDP Messages
The presence of this header instructs SIP Server to parse the body of the SIP message, extracting any user data that it finds there and adding it to the
UserData
attribute in the T-Library message.
Note:
The Genesys Voice Platform uses this
Content-Type
header method for sending user data in the body of
INFO
,
UPDATE
, and
BYE
messages, which SIP Server then maps to the corresponding T-Library event.
When modified user data is received in the body of
INFO, UPDATE,
and
BYE
messages, SIP Server updates the user data in the corresponding
T-Library event. If a key, which must be mapped from a SIP message to T-Library user data, is already present in the user data, then the value of this key in the user data is updated with the one received in the SIP message. In the case when
UserData
contains several KVPs with the key being mapped, all those keys are removed and the only one left has the value received in the SIP message. For integration with GVP, no special configuration on GVP or on the SIP Server switch is required.
Mapping Data from the MSML Body of INFO Message
For this method to work, the SIP
INFO
message must contain the following header:
Content-Type: application/vnd.radisys.msml+xml
In addition, you must set the msml-support
true
in the SIP Server
Application object to map data from MSML messages to the corresponding
T-Library events. This parameter instructs SIP Server to parse the body of the
MSML message, extracting any user data that it finds there and adding it to the
UserData
attribute in the T-Library message.
SIP Message
Example
INFO sip:21001@UTE_HOME:11000 SIP/2.0
From: sip:SVC_Mediaserver@UTE_HOME:11000;tag=467B7835-E194-435E-
B8B4-B82764E327CF-3
To: sip:[email protected]:49904;tag=EC11FCB4-2983-4A3B-8A93-
A15A72D878B8-8
Call-ID: 7E465A2A-F623-4ECF-AC3A-63D3FE271F25-4@UTE_HOME
CSeq: 1 INFO
Content-Length: 239
Content-Type: application/vnd.radisys.msml+xml
Via: SIP/2.0/UDP 172.24.128.63:49903;branch=z9hG4bK807562CD-F67E-
403E-9F26-A003FCCEAC87-3
Contact: <sip:172.24.128.63:49903>
<?xml version="1.0" encoding="UTF-8"?>
<msml version="1.1">
<event name="msml.dialog.exit" id="conn:__MSML-CONN-
ID__ivr_application9>
<name>AccessID</name>
<value>11447700</value>
SIP Server—Deployment Guide 279
Chapter 5: SIP Server Feature Support Mapping SIP Headers and SDP Messages
<name>Status</name>
<value>working</value>
</msml>
T-Library Message
Example
EventAttachedDataChanged
AttributeEventSequenceNumber 000000000000015a
AttributeTimeinuSecs 137000
AttributeTimeinSecs 1433151612 (15:10:12)
AttributeThirdPartyDN '5000'
AttributeThisDNRole 2
AttributeThisDN '5000'
AttributeANI '21001'
AttributeDNIS '5000'
AttributeUserData [41] 00 02 00 00..
'AccessID' '11447700'
'Status' 'working'
AttributeCallUUID '0MS6PSNRF12O593DHFFIR0AVCO000001'
AttributeConnID 226502665c77b001
AttributeCallID 16778217
AttributePropagatedCallType 2
AttributeCallType 2
REFER Messages
The SIP
REFER
method provides single-step transfer functionality. SIP Server retrieves data from headers and parameters of the
REFER
message, and then populates it into the
Extensions
or
UserData
attributes in all events associated with a transfer transaction. This feature also enables Genesys Voice Platform
(GVP) to transfer a call to Genesys Framework with attached data.
When a
REFER
message arrives, SIP Server analyzes the user part of the
REFER
TO
URI to determine if the destination of the call is an internal DN or an external destination. SIP Server checks if any configuration mapping is provided in the
REFER
section of SIP Server
Application
object. If such mappings exist, SIP Server extracts the values of the appropriate SIP headers into the attribute
Extensions
or
UserData,
according to the configuration. If a key, which must be mapped from a SIP message to T-Library user data, is already present in the user data, then the value of this key in the user data is updated with the one received in the SIP message. In the case when
UserData contains several KVPs with the key being mapped, all those keys are removed and the only one left has the value received in the SIP message. If the destination is a Routing Point, after this processing, SIP Server generates an
EventRouteRequest
message containing the necessary attribute values.
You can configure which headers and parameters to extract data from by creating the
REFER
section on the
Options
tab of the SIP Server
Application object. The rules for this configuration are the same as the rules for configuring the
INVITE
).
280 Framework 8.1
Chapter 5: SIP Server Feature Support Mapping SIP Headers and SDP Messages
To map data from the
REFER message into the
Extensions
and/or
UserData attributes, configure userdata-<n>
options and extensions-<n>
option in the
REFER
section.
If the names of the headers in the
REFER
message start with the prefix configured in the userdata-map-trans-prefix
option, these headers will be mapped to
UserData
.
It is possible to configure SIP Server to extract data from custom headers added in the
REFER
message, and to process the data from the custom SIP headers.
Feature Limitation
This feature is applicable only to scenarios where a call is made to a Routing
Point using the
REFER
method. To pass attached data in other scenarios, use the mapping configuration of the
INFO
and
UPDATE
messages instead.
Using EXTRACT_SIP_HEADERS
In addition, you can use the
EXTRACT_SIP_HEADERS
extension key in the
TMakeCall, TInitiateTransfer
, and
TInitiateConference
requests to extract specified headers from an
INVITE
sent to an originating party and map them to
AttributeExtensions
of the
EventDialing
message generated for this party.
Example
The following log excerpt provides the details in which
7000
is a
TMakeCall originating party,
8000
is a destination party:
1. SIP Server processes the
TMakeCall
request containing the
EXTRACT_SIP_HEADERS
key to extract headers
P-Charging-Vector
and
From from the
INVITE
request: message RequestMakeCall
AttributeThisDN'7000'
AttributeConnID006e01886c3d7001
AttributeOtherDN'8000'
AttributeExtensions
'EXTRACT_SIP_HEADERS' 'P-Charging-Vector,From'
AttributeReferenceID 9
2. SIP Server extracts headers
P-Charging-Vector
and
From
from the
INVITE request:
INVITE sip:7000@DestinationHost:8000
From: <sip:8000@SourceHost:8000>;tag=28B10B44
To: <sip:7000@DestinationHost>
Call-ID: 931E620E-F3F9
CSeq: 1 INVITE
SIP Server—Deployment Guide 281
Chapter 5: SIP Server Feature Support Mapping SIP Headers and SDP Messages
Content-Length: 0
Contact: <sip: SourceHost >
Max-Forwards: 70
Session-Expires: 1800;refresher=uac
P-Charging-Vector: 1234-5678-90
Min-SE: 90
Supported: timer
3. SIP Server inserts extracted headers and their values into
EventDialing
as
AttributeExtensions
keys: message EventDialing
AttributeThisDN'7000'
AttributeConnID006e01886c3d7001
AttributeOtherDN'8000'
AttributeExtensions[371] 00 0B 00 00..
'From' '<sip:8000@SourceHost:8000>;tag=28B10B44'
'P-Charging-Vector' '1234-5678-90'
AttributeReferenceID 9
Feature Limitation
In a single-dialog mode, no new dialogs are created for a
ThisDN
device while
SIP Server processes
TInitiateTransfer or
TInitiateConference
requests. So, the
EXTRACT_SIP_HEADERS
extension keys are not included in
TInitiateTransfer or
TInitiateConference
requests. Dialog parameters can be extracted using the
EXTRACT_SIP_HEADERS
key attached to a
TMakeCall
request.
From T-Library Messages to SIP Messages
SIP Server can map headers or header parameters passed in the
TRouteCall message to the outgoing
INVITE
message that is sent as a result of the call routing process. There are two ways to specify the values of the headers or header parameters to be mapped:
•
Use the extensions-<n>
SIP Server configuration option. This method maps only headers.
•
Use the
SIP_HEADERS
and
SIP_REQUEST_PARAMETERS
extension of the
TRouteCall
message.
Both methods can work simultaneously; for example—you can create a mapping list using extensions-<n>
options in the SIP Server configuration, and also specify the names in the
SIP_HEADERS
extension of the
TRouteCall
request.
Note:
The use of the
UserData
key name as a SIP message header field name implies that the
UserData
key name should conform to the IETF RFC
3261 requirement for allowed characters in the SIP message header field name.
282 Framework 8.1
Chapter 5: SIP Server Feature Support Mapping SIP Headers and SDP Messages
User data is also mapped in scenarios in which
TRouteCall
is involved. Refer to chapter 4, “T-Library Unstructured Data”, of the Genesys Events and
Models Reference Manual.
Note:
SIP Server does not pass key-value pairs from a list of key-value pairs to GVP.
Using the extensions-<n> Option
To use extensions-<n>
to configure T-Library request attributes to the SIP mapping, you configure extensions-<n>
options in a SIP Server
Application object. Those options are specified in the section named after the SIP request used to route the call, which is
INVITE
.
Example
This example demonstrates how to map a
TRouteCall
request extension called
InfoToSendInInvite
to the outgoing
INVITE
message.
Follow these steps to configure SIP Server:
1. Create the
INVITE
section on the
Options
tab of the SIP Server
Application object.
2. In the
INVITE
section, create an option named extensions-1,
and set the value to
InfoToSendInInvite
.
Note:
This configuration example is based on the assumption that this is the first extensions-<n>
option in the
INVITE
section.
SIP Server uses this configuration when it receives a
TRouteCall
request from the URS with either
InfoToSendInInvite
or
InfoToSendInRefer
extensions defined. The following log excerpt provides the details: message RequestRouteCall
AttributeThisDN
AttributeConnID
AttributeOtherDN
'5000'
006e01886c3d7001
'21101'
AttributeExtensions [371] 00 0B 00 00..
'InfoToSendInInvite’ ‘INVITE from SIP Server'
AttributeDNIS
AttributeRouteType
AttributeReferenceID
'5000'
1 (RouteTypeDefault)
9
SIP Server adds a new header
InfoToSendInInvite
to the outgoing
INVITE message:
INVITE sip:21101@DestinationHost:21101 SIP/2.0
From: <sip:7102@SourceHost:7102>;tag=28B10B44
To: <sip:21101@ DestinationHost >
SIP Server—Deployment Guide 283
Chapter 5: SIP Server Feature Support
284
Mapping SIP Headers and SDP Messages
Call-ID: 931E620E-F3F9-4D72-A451-36B1BB259532-1
CSeq: 1 INVITE
Content-Length: 145
Content-Type: application/sdp
Contact: <sip: SourceHost:5060>
InfoToSendInInvite: INVITE from SIP Server
Max-Forwards: 70
Session-Expires: 1800;refresher=uac
Min-SE: 90
Supported: timer
Using SIP_HEADERS and
SIP_REQUEST_PARAMETERS
This method does not require any changes to the configuration of the SIP
Server
Application
object. In this case, all mapping information is provided in the
TRouteCall
request that is created by the URS routing strategy and sent to
SIP Server.
The
TRouteCall
request should contain two specialized extensions to trigger
T-Library-to-SIP mapping in SIP Server:
•
SIP_HEADERS
—Contains a list of extension names of
TRouteCall
to be mapped to the outgoing SIP message as headers.
•
SIP_REQUEST_PARAMETERS
—Contains a list of extension names to be mapped to the outgoing SIP message as Request URI parameters.
The values of headers and header parameters must be also specified in the
TRouteCall
request.
The
SIP_HEADERS
extension can be used to map T-Library extensions to the SIP
REFER
message. This applies to the scenarios when
TRouteCall
is executed by the SIP
REFER
message.
Example
This example demonstrates how mapping works in SIP Server when it receives the following
TRouteCall
request: message RequestRouteCall
AttributeThisDN
AttributeConnID
AttributeOtherDN
AttributeExtensions
'5000'
006e01886c3d7001
'21101'
[371] 00 0B 00 00..
'SIP_HEADERS' 'hdr-host1,hdr-host2’
'SIP_REQUEST_PARAMETERS' 'prm-host1,prm-host2'
'hdr-host1'
'hdr-host2’
'prm-host1'
'prm-host2'
AttributeDNIS
'host1'
'host2'
‘local1'
‘local2'
'5000'
Framework 8.1
Chapter 5: SIP Server Feature Support Mapping SIP Headers and SDP Messages
AttributeRouteType
AttributeReferenceID
1 (RouteTypeDefault)
9
This message contains both
SIP_HEADERS
and
SIP_REQUEST_PARAMETERS extensions, which means both new headers and new Request URI parameters should be added to the outgoing SIP message:
INVITE sip:21101@ DestinationHost:21101;prm-host1=local1; prm-host2=local2 SIP/2.0
From: <sip:7102@ SourceHost:7102>;tag=28B10B44
To: <sip:21101@ DestinationHost >
Call-ID: 931E620E-F3F9
CSeq: 1 INVITE
Content-Length: 145
Content-Type: application/sdp
Contact: <sip: SourceHost > hdr-host1: host1 hdr-host2: host2
Max-Forwards: 70
Session-Expires: 1800;refresher=uac
Min-SE: 90
Supported: timer
SDP Message Mapping
SIP Server can map the whole SDP message body, or any particular line in it as
AttributeExtensions
or
AttributeUserData
. Configuring this type of mapping is similar to configuring mapping of SIP Server headers or parameters. The option names in the
INVITE
section must use the same rules described for SIP
Server message mapping; however, the option name must be
SDP,
and it must be followed by a colon and a letter that indicates the type of mapped SDP message. For example, the userdata-1=SDP:m
option is mapped using the following parameters from
AttributeUserData
: m=audio 18234 RTP/AVP 8 101
Note:
If the
AttributeUserData
parameter in the
EventRouteRequest
message contains a pair such as:
SDP:m audio 18234 RTP/AVP 8 101
You must use the
SDP
value to configure the mapping of the whole
SDP message.
Dynamic DN Replacement
SIP Server can dynamically replace the
[DN]
parameter in T-Library to SIP header mapping. If enabled, SIP Server replaces the
[DN]
pattern in the mapped
SIP message with the digits of the DN where the SIP message is being sent.
This applies to both
Extensions
and
UserData
T-Library to SIP mapping.
SIP Server—Deployment Guide 285
Chapter 5: SIP Server Feature Support Masking Sensitive Data in SIP Messages
To enable dynamic DN replacement, in the
TServer
section of the SIP Server
Application
object, set the
to true
.
SIP Headers Encoding
SIP Server supports encoding of SIP headers from UTF-8 to a local character set and vice versa in T-Library messages. To enable SIP headers encoding, in the
TServer
section of the SIP Server Application object, configure the following options:
•
— Specify the converter name to translate UTF-8 data to the local
character set.
•
tlibsip
area.
Masking Sensitive Data in SIP Messages
Introduced in
SIP Server
8.1.102.51
SIP Server can now mask sensitive data in SIP messages contained in SIP
Server logs. When enabled, SIP Server replaces:
•
All private SIP header values with a single asterisk
•
SIP message body content with the phrase
CONTENT FILTERED
SIP Server does not replace the content of type application/sdp, and it replaces application/vnd.radisys.msml+xml in the SIP message body only when it contains user data.
Feature Configuration
Set the x-sip-mask-sensitive-data
configuration option to true
in the
[log] section of the SIP Server Application.
Media Server Reliability—NETANN/MSML
SIP Server supports reliability for music-on-hold; treatments that are set to continuous playback, conference, or supervisor; voice call recording features provided by a media server. SIP Server can provide reliability in cases where the media server:
•
Fails when the service is initially requested.
•
Becomes unavailable while the service is underway.
286 Framework 8.1
Chapter 5: SIP Server Feature Support Media Server Reliability—NETANN/MSML
In either case, SIP Server can restart the service on a second media server, with minimal impact on the customer experience.
Note:
To provide reliability for treatment services, SIP Server supports the
Active Out-of-Service Detection method only. This limitation applies to treatments that are started for calls located on a Routing Point.
How SIP Server Detects a Media Server Failure
To provide reliability for media services, SIP Server must first detect when a media server becomes unavailable. It can perform this detection either of the following methods:
•
Active Out-of-Service Detection.
Active detection is the only method that allows SIP Server to detect service failure before it engages the service.
•
Passive Out-of-Service Detection.
If only passive detection is enabled, SIP Server can only detect a failure after initial service engagement. In this case, if the device fails to respond to an
INVITE
request for a media service, SIP Server considers the device to be out-of-service and tries an alternate media server.
•
Error Response Handling
The media server returns an error in response to the SIP transaction. In this case, SIP Server does not place the device in an out-of-service state.
However, it does try to restart the service on an alternate available media server.
In case of multiple
Voice over IP Service
DNs with service type=msml
:
When Resource Manager returns an error response, SIP Server selects an alternate
Voice over IP Service
DN ( msml
) to recover the media service.
When MCP returns an error response, SIP Server selects a
Voice over
IP Service
DN ( msml
) on a round-robin fashion to recover the media service.
In case of MSML conference, when Media Server responds with a
503 response, SIP Server does not retry the conference, and drops the conference request.
•
The media server application terminates the dialog due to a lost RTP stream or other error.
Termination of a SIP dialog by a continuous service (such as MCU, recorder, or treatment that is set to continuous playback) is considered a failure of the corresponding endpoint. In this case, SIP Server does not
SIP Server—Deployment Guide 287
Chapter 5: SIP Server Feature Support Media Server Reliability—NETANN/MSML consider this to be a media server failure. SIP Server will restore the call without the failed party. For example, in a conference call, SIP Server will release the failed party and then restore the call, minus that party. For emergency call recording, SIP Server restores the call but does not restart recording.
Reliability for Conference Calls
If the Media Server (acting as an MCU) that is supporting a conference call is detected as unavailable while the conference is in progress, SIP Server detects the failure and restarts the conference on a secondary media server with minimal impact on the customer experience.
Reliability for Supervisor Features
In case of Media Server failure, SIP Server restarts the Supervisor features on a second Media Server, with minimal impact on the customer experience.
For details about these features, see the following references:
•
“Call Supervision” on page 143 .
•
The “Supported Functionality in Stream Manager” chapter of the
Framework 7.6 Stream Manager Deployment Guide.
Reliability for Voice Call Recording
SIP Server can provide continuity for voice call recording. In cases where the media server that is supplying the recording function is detected as unavailable, SIP Server can continue recording the call on a second alternate media server with minimal loss of content.
The recording is captured in two separate files:
•
The first part of the call is recorded to a file on the original media server.
•
The second part of the call, which starts after the failover, is recorded to a file on the alternate media server.
Reliability failover for voice call recording applies to both regular and emergency call recording. For more information about the call recording
feature, see “Call Recording—NETANN-Based” on page 126 .
Media Server Reliability—NETANN
In the case of NETANN, SIP Server is responsible for monitoring the Media
Server. When SIP Server detects that a particular Media Server is out of service after a service is started, SIP Server is able to continue the service on an alternate available Media Server device.
288 Framework 8.1
Chapter 5: SIP Server Feature Support Media Server Reliability—NETANN/MSML
However, Genesys recommends that you:
1. Install multiple Media Servers and configure them in such a way that an alternate Media Server of each type (for example, moh
, treatment
, mcu
, recorder
) is available in case of failure of the original server.
2. Enable the Active Out-of-Service Detection feature, which allows SIP
Server to detect a failure in the media service device before attempting to engage it in a service, or replace the failed media service in the middle of a call.
Configuring Active Out-of-Service Detection
To configure the length of time between
OPTIONS
requests, use the options
Annex
tab of the
Voice over IP
Service
DN). For more information about configuring this feature, see “Active
Out-of-Service Detection” on page 254 .
Media Server Reliability—MSML
SIP Server supports the SIP
SUBSCRITBE/NOTIFY
method for providing reliable
MSML-based media services through Genesys Media Server. By subscribing to the DN used to represent Genesys Media Server for MSML-based services,
SIP Server is able to determine when a particular instance of Media Server becomes unavailable, and if so, SIP Server can disconnect from the failed media server, then reconnect to an available instance of Media Server, providing continuity for any ongoing msml-based media services.
How It Works
With subscription enabled, SIP Server typically handles the failure of a Media
Server instance as follows:
1. SIP Server sends periodic
SUBSCRIBE
messages to GVP Resource Manager for each
Voice over IP Service
DN (s ervice-type
is set to msml
) that SIP
Server is subscribed to.
2. If a particular instance of Media Server becomes unavailable, Resource
Manager sends a
NOTIFY
message to SIP Server, which lists the status of each media server monitored by Resource Manager. A sample body for the
NOTIFY
message is as follows:
*msml/<mediaserver-ipaddress>:<mediaserver-port>/out-of-service*
3. SIP Server disconnects all ongoing media services from this Media Server instance, then reconnects with an active Media Server through Resource
Manager.
4. All existing treatments and conference connections are re-established on the alternate Media Server instance.
SIP Server—Deployment Guide 289
Chapter 5: SIP Server Feature Support Modifying the From Header in SIP INVITE
Feature Configuration
This feature requires no special configuration. The feature is enabled through the
option, which is part of the basic configuration of the
Voice over IP Service
DN. For more information, see Table 12: Integrating
Media Server for MSML, on page 95 .
Feature Limitation
SIP Server supports reliability for media services after the initial failure of a
Media Server only. For any subsequent media server failure, SIP Server is unable to restart the service using another Media Server.
Modifying the From Header in SIP INVITE
Introduced in
SIP Server
8.1.102.05
SIP Server provides the ability to modify the
From
header in outgoing SIP
INVITE
messages. Use the following configuration options to enable this functionality, depending on your needs. These cpn-controlling options are configured on an
Extension
DN or
VoIP Service
DN with s ervicetype=softswitch
, in the
TServer
section.
•
•
•
Note:
Genesys does not recommend using the cpn
configuration option and the options described above together on the same device.
Multi-Threaded Logging
SIP Server is a multi-threaded application where the number of threads is controlled by the
configuration option. Each SIP Server thread can produce a dedicated log file. If the standard T-Server log configuration is applied, then only the main thread log is generated. Logs from other threads can be enabled by applying configuration explained in this section.
How It Works
To enable each SIP Server thread to produce a dedicated log file, specify a file
option. SIP Server creates an extra file for each
running thread, as specified in the sip-link-type
provides the
290 Framework 8.1
Chapter 5: SIP Server Feature Support Multi-Threaded Logging recommended x-sip-log
settings and the corresponding SIP Server behavior for different sip-link-type
configurations.
Table 66: Multi-threaded Log Files sip-link-type Log File
0 If the x-sip-log option is set to an empty value, a single log file for all SIP Server activities (including T-Library and SIP messages) is created according to common log file configuration.
If the x-sip-log option does not exist in the configuration
,
SIP Server generates Transport (768) and Operational
Information (1536) log files in addition to the main thread log.
3
4
If the x-sip-log
option is set to an empty value, SIP Server generates one log file, which contains only the T-
Library–related activity.
If the x-sip-log
option does not exist in the configuration
,
SIP Server creates several log files, generated by running threads, including:
• T-Server thread (T-Library messages)
• Call Manager thread (SIP messages)
• Transport thread
• Service Checker thread
• Operational Information thread
The T-Server thread is defined by common logging parameters.
The other threads are defined by the x-sip-log
option.
If the
x-sip-log
option is set to an empty value, SIP Server generates one log file, which contains only the T-
Library–related activity.
If the x-sip-log option does not exist in the configuration
SIP Server creates several log files, generated by running
, threads, including:
• T-Server thread
• 16 Call Manager threads
• Transport thread
• Service Checker thread
• Presence Manager thread
• Operational Information thread
The T-Server thread is defined by common logging parameters.
The other threads are defined by the x-sip-log
option.
SIP Server—Deployment Guide 291
Chapter 5: SIP Server Feature Support Multi-Threaded Logging
How the Filenames are Created
In multi-threaded logging, all log filenames, except for the T-Server thread log, are created using the following format:
LogName-ThreadId.DateTime.log
•
LogName
is defined in the x-sip-log
parameter.
•
ThreadID
identifies the particular thread:
001-016 is used for any of the Call Manager threads
256 is used for the Presence Manager thread
512 is used for the Service Checker thread
768 is used for the Transport thread
1536 is used for the Operational Information thread
•
DateTime
is created using the format yyymmdd-hhmmss_iii
, where iii
shows milliseconds.
Log Expiration
Automatic log deletion upon expiration is controlled by the expire
of the ways to control log expiration is to set a maximum number of files to store. In this case, the limit is applied to each thread separately. For example, if sip-link-type is set to
3,
multi-threaded logging is enabled and the limit is set to
30,
SIP Server keeps approximately 150 files, at least; the rest are considered expired. The five threads (T-Server, Call Manager, Transport,
Service Checker, and Operational Information), each contribute 30 files toward the total.
Logging To Remote Location
SIP Server supports storing log files at the remote network location. This logging mode introduces a number of limitations and, as a result, is not recommended. If logs are stored on the network drive, then a
.snapshot.log
file must be disabled (see no-memory-mapping
). This file is a key for troubleshooting the problems when SIP Server exits unexpectedly. In addition, logging to a network drive may cause SIP Server to stop responding while access to the log file is not available or delayed due to network issues.
Genesys recommends configuring the
option and storing all SIP Server
logs locally, and during a period of low activity periodically move the logs from the SIP Server host to network storage. This widely used approach helps to keep the size of the local hard disk drive small and at the same time to keep all required information for troubleshooting of potential issues.
292 Framework 8.1
Chapter 5: SIP Server Feature Support Music and Announcements
Feature Configuration
describes how to configure multi-threaded logging.
Table 67: Configuring Multi-Threaded Logging
Objective
Enable multi-threaded logging.
Related Procedures and Actions
In the SIP Server Application object, configure the following option:
•
—Enter a path and filename where the
additional SIP-based log files will be created.
Sample Configuration
The following is an example of how the different configuration option settings result in a particular set of log files:
•
x-sip-log
option is set to c:\logs\extralog
•
sip-link-type
is set to
3
In this case, in addition to the main T-Sever log (defined by the common
options found in the log Section
), several additional log files are created, including:
•
extralog-001.20101109_093122_439.log
- Call Manager
•
extralog-768.20101109_093122_376.log
- Transport extralog-1536.20101109_093122_864.log
- Operational Information
Music and Announcements
SIP Server is able to control the playing of announcements by using Genesys
Media Server and Stream Manager. Media Server or Stream Manager provide an announcement service that plays various types of prompts, such as music or recorded files, and also provide a service that plays prompts and collects
DTMF tones inputted by the caller. For information about how to configure
“Configuring Stream Manager” on page 92 .
This section describes the following topics:
•
Announcement Treatments on Routing Points, page 294
•
Music Treatments on Routing Points, page 296
•
Other Treatments on Routing Points, page 297
SIP Server—Deployment Guide 293
Chapter 5: SIP Server Feature Support Music and Announcements
Announcement Treatments on Routing Points
When creating a routing strategy in Interaction Routing Designer for announcement treatments
PlayAnnouncement
and
PlayAnnouncementAndDigits,
include the parameters listed in Table 68 .
Table 68: Announcement Treatment Parameters
Parameter
LANGUAGE
MSGID
MSGTXT
PROMPT
INTERRUPTABLE
ID
DIGITS
USER_ID
Description
Ignored.
Ignored.
Ignored.
Contains up to 10 subprompts. Each contains a music file, and these are played in order.
When this check box is selected, the caller can interrupt the announcement with a
DTMF
keystroke.
Note: See “Feature Limitation” on page 297 .
Contains an integer, that refers to the media file located in the announcement
subdirectory of the installed MCP or Stream Manager root directory.
For example, the value
1
refers to the file announcement/1_alaw.wav
, if the G.711 A-law codec is used.
Ignored.
Supported by Media Server and Stream Manager using the users/<customer id>_<ann.id>
file.
294 Framework 8.1
Chapter 5: SIP Server Feature Support Music and Announcements
Table 68: Announcement Treatment Parameters (Continued)
Parameter
USER_ANN_ID
TEXT
Description
Supported by Media Server and Stream Manager using the users/<customer id>_<ann.id>
file.
Starting with version 8.1.101.15, SIP Server supports the
TEXT parameter in
TApplyTreatment
with the following applicable treatments:
•
PlayAnnouncement
•
PlayAnnouncementAndDigits
•
RecordUserAnnouncement
This parameter is used to specify the URL/path of the file to be played.
It is sent as an item in the
PROMPT
list.
URL format: protocol://FQDN-or-IPAddress:port/path/filename
For example:
Or, http://localhost/rMessages/dk/ATP_VMIntro.wav
file://announcement/test/WelcomeGreeting.wav
If the treatment is terminated early because of a problem with Stream Manager or SIP Server, SIP Server sets the
Extension
data fields
ERR_CODE and
ERR_TEXT.
To determine whether these fields and their values exist, from a routing strategy, use the function
ExtensionData
. Place this function on a normal completion branch (not the error branch) after the treatment.
Refer to the Universal Routing 8.1 Reference Manual for more information on the use and configuration of strategies.
Note:
When creating a new strategy in Interaction Routing Designer, leave the
Wait For Treatment End check box selected, to allow the treatment to play until completion.
SIP Server—Deployment Guide 295
Chapter 5: SIP Server Feature Support Music and Announcements
Music Treatments on Routing Points
When creating a strategy in Interaction Routing Designer for music treatments,
specify the parameters described in Table 69 .
Table 69: Music Treatment Parameters
Parameter
MUSIC_DN
DURATION
Description
Specifies the music source that Media Server or Stream Manager plays. The format is:
<directory>/<music file name>
Example: music/in_queue
Where music
is a subdirectory in the MCP root directory and
in_queue
is a base file name. Refer to the Genesys Media Server Deployment Guide for supported media file types and archives.
The
option is used if the value of the
MUSIC_DN
parameter is not specified.
Specifies the duration of the music (in seconds).
Note: This parameter is ignored if
MUSIC_DN
is blank.
To continue playing music after the treatment terminates, consider creating one of the following strategies using Interaction Routing Designer:
• Execute the treatment inside a route-selection treatment block. In this case, the treatment continues until a route target is selected.
• Follow the treatment with the
SuspendForTreatmentEnd
function. In this case, the treatment plays music until terminated after the delay specified in option
DURATION
.
• Follow the treatment with the delay function. In this case, the treatment plays music for the period specified in option delay
. If
DURATION
is less than delay
, silence is played for the time difference.
Refer to the Universal Routing 8.1 Reference Manual for more information on the use and configuration of strategies.
296 Framework 8.1
Chapter 5: SIP Server Feature Support Music and Announcements
Other Treatments on Routing Points
continuously loop a pre-defined audio file to a call.
The treatment types are as follows:
Table 70: Other Treatments on Routing Points
Treatment Type
Busy
Fast Busy
Silence
Ringback
CollectDigits
RecordUser-
Announcement
Description
Plays a busy tone. To define the busy tone audio file, configure the SIP Server
Plays a fast busy tone. To define the fast busy tone audio file, configure the SIP Server
option.
Plays no sound. To define the silence
audio file, configure the SIP Server
Plays ringback tone. To define the ringback
audio file, configure the SIP Server
Collects customer-entered digits.
Records a user’s announcement and saves into a users folder.
Refer to the Universal Routing 8.1 Reference Manual for more information about the use and configuration of strategies.
Feature Limitation
When digits collection is completed (
MAX_DIGITS
limit is reached or
ABORT
/
TERM_DIGITS
is entered), the treatment
PlayAnnouncementAndCollectDigits ends, causing the interruption of announcement regardless of the
INTERRUPTABLE
flag set for this announcement.
SIP Server—Deployment Guide 297
Chapter 5: SIP Server Feature Support Nailed-Up Connections
Nailed-Up Connections
SIP Server supports a persistent “nailed-up connection” for agents, where it maintains an extended telephone call between SIP Server and the agent.
During this time, the agent can handle multiple customer interactions without dropping the telephone connection to SIP Server.
Nailed-up connections offer a few key benefits, including:
•
Minimal delay between the time an agent is selected and the audio path to the customer is established
•
Improved overall reliability—the connection is already established when delivering a customer “call”, and the agent is less likely to take non-contact center calls
One typical use of nailed-up connections is for agents who use a legacy PSTN phone. These agents could be working from their homes, or in a branch office that has simple PSTN connectivity. Another typical use of nailed-up connections is for agents behind a third-party PBX, when the PBX is connected to SIP Server through a gateway or simple SIP trunk.
SIP Server supports virtually all agent functionality in conjunction with nailedup connections. The agent can make calls, receive calls, transfer calls, consult with other agents, use call supervision, and more. In addition, SIP Server’s call recording functionality is fully compatible with nailed-up connections.
Inbound calls to an agent with a nailed-up connection are delivered by default with “auto answer”—meaning the audio connects immediately. If this “auto answer” experience is not desired, then Preview Interactions should be used to provide the agent the opportunity to see call information in their agent desktop and accept or reject the call.
Nailed-up connections can be established or disconnected either by SIP Server or by the agent.
Note:
In Business Continuity deployments, any DN with a statically configured contact must use dr-forward
set to no-agent
. In practical terms, such a DN is commonly used for a “remote agent”, often in conjunction with the nailed-up connection. See the
SIP Server 8.1
High-Availability Deployment Guide for details.
Establishing the Nailed-Up Connection
Nailed-up connections can be established by three different methods:
•
SIP Server establishes the nailed-up connection on agent login or when an agent is in Ready state.
•
SIP Server establishes the nailed-up connection on the first customer call.
•
Agent establishes the nailed-up connection by calling into a contact center
Route Point.
298 Framework 8.1
Chapter 5: SIP Server Feature Support Nailed-Up Connections
SIP Server Establishes the Nailed-up Connection on
Agent Login or Ready state
SIP Server can establish the persistent nailed-up connection with an agent when the agent logs in, depending on the configuration:
•
When connect-nailedup-on-login
=<Routing Point number>
, SIP Server connects the agent’s endpoint with the specified Routing Point and then, after processing the
TRouteCall
to the predefined gcti::park
device, SIP
Server parks the agent on the gcti::park
device establishing the persistent nailed-up connection with the agent’s endpoint.
•
When connect-nailedup-on-login
=gcti::park
, SIP Server directly parks the agent on the gcti::park
device, establishing the persistent nailed-up connection with the agent's endpoint while processing
TAgentLogin
.
If a nailed-up connection is terminated for any reason, SIP Server places the agent in the
NotReady
state. If an agent is in the
NotReady
state and a nailed-up connection is not yet established, SIP Server, while processing the
TAgentSetReady
request, initiates a SIP call to the agent’s phone with further parking on the gcti::park
device. If the call fails, SIP generates
EventError
in response to
TAgentSetReady
; the agent remains in the
NotReady
state.
If the agent logs out, the nailed-up connection is dropped.
SIP Server Establishes the Nailed-up Connection on
First Customer Call
SIP Server calls the agent to start a session—SIP Server sends the call to a remote TDM agent configured for the nailed-up feature. This applies to the first transfer to the agent, where the initial nailed-up session starts. When the caller releases the call or the agent releases the call using 3pcc, SIP Server parks the agent on Media Server, keeping the connection for the call leg to the nailed-up connection.
The basic call flow when SIP Server first calls an agent configured for the nailed-up feature is as follows:
1. SIP Server receives a customer call, which the Universal Routing Server then processes.
2. After qualification and queuing, the routing strategy selects the agent who will handle the call.
3. SIP Server contacts the agent as it would for any remote TDM extension
(SIP Server does not yet consider the agent to be nailed-up).
4. At the end of the call, when the agent requests to release the call through the Agent Desktop (a 3pcc
TReleaseCall
), SIP Server does not disconnect the call leg to the nailed-up connection but, instead, parks the agent on the
SIP Server—Deployment Guide 299
Chapter 5: SIP Server Feature Support
300
Nailed-Up Connections predefined gcti::park
device. At this point, the agent is considered to be nailed-up. Media Server plays a silent treatment while the nailed-up connection is maintained.
In Business Continuity deployments, SIP Server applies the following “Call
Delivery” logic when establishing the initial call to a DN with a statically configured contact:
1. If the first SIP Server to handle the call determines an agent is locally logged in and using the DN, this SIP Server delivers the call directly to the
DN.
2. Otherwise, the first SIP Server forwards the call to the second SIP Server on the alternate site, using the inter-site Trunk DN and ISCC. The second
SIP Server delivers the call to the DN, regardless of whether any agent is logged in and using the DN or not.
Note:
Carefully consider this behavior. This could result in high telephone connection charges, if, for example, DNs and data centers are distributed across different countries.
Agent Establishes the Nailed-Up Connection by
Calling into a Contact Center Route Point
The agent calls the contact center to start a session—The remote TDM agent
(configured for the nailed-up feature) initiates a call (1pcc) to the contact center.
The basic call flow when a remote TDM agent is configured for the nailed-up feature is as follows:
1. A call from the remote agent arrives at the contact center on a Routing
Point DN.
2. A short treatment is applied, and URS issues a
TRouteCall
to the predefined gcti::park
device (
RouteType=Unknown
;
OtherDN=’gcti::park’
).
3. SIP Server parks the agent on the gcti::park
device, keeping the call leg to the agent connected. At this point, the agent is considered to be nailed-up.
Media Server applies a silent treatment while the nailed-up connection is maintained.
In Business Continuity deployments, each data center should have a unique routing point, which allows an agent to connect to their preferred data center based on which routing point they contact.
Reporting on Nailed-Up Connection Calls
Calls that involve the nailed-up connection use T-Library events that are identical to those used for a regular agent. Each customer interaction established with an agent in a nailed-up connection is reported as a distinct
Genesys call, allowing monitoring and reporting on each individual call.
Framework 8.1
Chapter 5: SIP Server Feature Support Nailed-Up Connections
Disconnecting the Nailed-Up Connection
Nailed-up connections can be disconnected for several reasons:
•
The agent hangs up the phone.
•
A network problem between SIP Server and the phone causes the call to be dropped.
•
The agent logs out (applies when SIP Server established the connection on login, or if the
option is set to true
).
•
The agent is inactive (no changes in agent state or incoming/outgoing calls at the DN) for the specified period of time (
).
Note:
If you enable drop-nailedup-on-logout
, SIP Server can only establish the nailed-up connection when the remote agent is logged in.
Feature Configuration
describes how to configure the nailed-up connection for a remote
TDM agent DN.
Table 71: Configuring a Nailed-Up Connection
Objective Related Procedures and Actions
1. Configure the gateway.
In the
Trunk
DN that represents the gateway that is used to contact the remote agent, set
false
.
For general information about creating a gateway DN, go to:
•
Procedure: Configuring a gateway, on page 81
.
2. Configure the agent DN.
In the
ACD Position or
Extension
DN for the agent, configure the following options:
•
1
.
•
—Set this option to false
.
•
—Set this to false
.
•
true
(recommended, not mandatory).
•
—Ensure that this option is not configured.
For general info about creating agent DNs, go to:
•
Procedure: Configuring endpoints, on page 79 .
SIP Server—Deployment Guide 301
Chapter 5: SIP Server Feature Support Nailed-Up Connections
Table 71: Configuring a Nailed-Up Connection (Continued)
Objective
3. Configure the SIP Server
Application and/or DN objects.
4. (Optional) Configure
Business Continuity.
Related Procedures and Actions
Connection on Agent Login
To enable the persistent nailed-up connection on agent login, use any of the following configurations, listed in order of priority:
1. Extensions Attribute:
2. In the
TServer
section of the individual DN, configure the connectnailedup-on-login
3. In the
TServer
section of the SIP Server Application, configure the
option.
Note: If the agent logs out, the nailed-up connection will be dropped; the same behavior as if the drop-nailedup-on-logou t is set to true
.
Disconnection on Inactivity
To terminate the agent’s nailed-up connection because of agent's inactivity, in the
TServer
section, configure the following option:
•
(can be set at both Application or
DN levels)
Disconnection on Agent Logout
To enable automatic disconnection of the agent from the nailed-up connection on agent logout, in the
TServer
section, configure the following option:
•
true
.
Note: If enabled, SIP Server can only establish the nailed-up connection if the agent is logged in.
For Business Continuity deployments, set dr-forward
to no-agent
. See the
SIP Server 8.1 High-Availability Deployment Guide
.
Feature Limitations
•
Consultation calls for nailed-up DNs are supported in single dialog mode only.
•
If an agent with the nailed-up connection is participating in the first call before it was ever parked, SIP Server cannot park this agent if the call is released before it is established. For example, if the agent with the nailedup connection initiates a call and releases it while the call is ringing, or if the agent with the nailed-up connection completes a two-step transfer in ringing state. To avoid this, the agent must call the call center to get parked first.
302 Framework 8.1
Chapter 5: SIP Server Feature Support Network Asserted Identity
Network Asserted Identity
SIP Server supports the Network Asserted Identity mechanism for controlling the presentation of personal information (caller details) in SIP messages within a trusted network. This mechanism uses special private headers to prevent or allow user information—the SIP URI—from being shared across network nodes, depending on whether a particular node is trusted or untrusted. It allows
SIP Server to comply with caller requests to keep their identity private. For example, Calling Line Identification Restriction (CLIR).
How the Mechanism Works
If privacy is required, the special header privacy:id
is included in the
INVITE
, and all user information in the
From
part of the
URI
is replaced with anonymous content. For example:
From = “Anonymous” <sip:[email protected]>;tag=1928301774
If the
INVITE
is sent between trusted nodes, it will also include the header
P-
Asserted-Identity
, which provides the identity of the caller (a URI and an optional display name) in a controllable header. For example:
P-Asserted-Identity: “Bob” <sip:[email protected]>
If, in the incoming
INVITE, there is a
P-Asserted-Identity
header and no
Privacy
headers, in both trusted and non-trusted modes, the provided
P-Asserted-Identity
header will be supplied in the resulting
INVITE
to the destination.
For example, an
INVITE
between trusted or untrusted entities might look like this:
INVITE sip:UserB@internalresource:5067 SIP/2.0
From: “Anonymous” <sip:[email protected]>;tag=1928301774
To: <sip:UserB@internalresource:5068
P-Asserted-Identity: “Bob” <sip:[email protected]>
Privacy: id..
Note:
For complete information about either the privacy mechanism or the network asserted identity extensions, refer to the following RFCs:
• “RFC 3323: A Privacy Mechanism for the Session Initiation
Protocol (SIP)”
• “RFC 3325: Private Extensions to the Session Initiation Protocol
(SIP) for Asserted Identity within Trusted Networks”
SIP Server—Deployment Guide 303
Chapter 5: SIP Server Feature Support Network Asserted Identity
How SIP Server Supports the Mechanism
SIP Server supports control of the Network Asserted Identity mechanism using the following DN-level options:
•
•
•
•
•
On receiving an
INVITE
request that includes the
P-Asserted-Identity
header,
SIP Server will consider this header as the ANI for the call.
For backwards compatibility for IMS integrations, where all devices inside the
IMS deployment are trusted by default, the enforce-trusted option is also supported on the Application level.
Inserting the P-Asserted-Identity Header
SIP Server will make the
From
header anonymous as well as insert the privacy and
P-Asserted-Identity
headers in the following cases:
•
Incoming
INVITE
request includes the p-preferred-identity
and
Privacy:id
headers.
•
Origination DN is configured with the privacy
option set to id
.
•
Destination DN or outbound
Trunk
DN is configured with the enforce-passerted-identity
option.
Generating the P-Asserted-Identity Header
SIP Server gets the information it needs to generate the
P-Asserted-Identity header, if required, from the following sources listed in order of priority:
1. Value of the enforce-p-asserted-identity
option configured on the destination DN or outbound
Trunk
DN.
2. Value of the p-asserted-identity
option configured on the origination DN or inbound
Trunk
DN.
3. Content in the
P-Asserted-Identity
header included in the incoming
INVITE
from a trusted origination.
4. Content in the
P-Preferred-Identity
header included in the incoming
INVITE
from a trusted origination.
5. Content in the
From
header of the incoming
INVITE
.
304 Framework 8.1
Chapter 5: SIP Server Feature Support Network Asserted Identity
Removing the P-Asserted-Identity Header
SIP Server will remove the
P-Asserted-Identity
header from an outbound request if the
Trunk
or
Voice over IP Service
DN is configured with the enforce-trusted
option set to false
.
Inbound Calls
For inbound calls arriving at SIP Server, the incoming
INVITE
may already include privacy restrictions—if, for example, CLIR was enabled externally by the caller. If SIP Server receives such an
INVITE
, it will forward it to the destination with privacy and, if both the inbound
Trunk
DN and the destination
DN are trusted, with the
P-Asserted-Identity
header as well.
Inbound Call From Trusted Entity to Trusted Entity (Caller Requests Privacy)
shows a sample call flow for an inbound call between a trusted external domain and a trusted destination DN on SIP Server.
External Domain
(trusted Trunk)
SIP Server Domain options:
Inbound Trunk
enforce-trusted =true
SIP Server
Agent SIP Phone
Agent
T-LIB Client
INVITE From: Anonymous To: 7000
P-Asserted-Identity: “Alice” <sip:[email protected]>
Privacy: id
: options: enforce-trusted =true
INVITE From: Anonymous To: 7000
P-Asserted-Identity: “Alice” <sip:[email protected]>
Privacy: id
EventRinging
200 OK
( Extensions: PRIVACY=id)
200 OK
Figure 29: Trusted External Call To Trusted Destination DN (with privacy restriction)
In this case, both the inbound
Trunk
DN and the destination DN are configured with enforce-trusted
set to true
. SIP Server forwards the
INVITE
with all privacy elements included:
From
is anonymous and both privacy: id
and
P-
Asserted-Identity
headers are included.
SIP Server—Deployment Guide 305
Chapter 5: SIP Server Feature Support Network Asserted Identity
Inbound Call From Trusted Entity to Non-Trusted Entity (With Privacy)
In this case, the inbound
Trunk
DN is configured as trusted, but the destination
DN is not trusted. When SIP Server receives a privacy-enabled
INVITE
, it forwards only the anonymous
From
and the privacy:id
header to the destination. It removes the
P-Asserted-Identity
header, so no personal information is presented to the destination device.
Inbound Call From Non-Trusted Entity (With Privacy)
In this case, the inbound
Trunk
DN is configured as non-trusted. It does not matter if the destination DN is trusted or not, SIP Server removes the
P-
Asserted-Identity
header when it forwards the restricted
INVITE
to the destination.
Inbound Call From Trusted Entity (COLR)
In this case, the
Trunk
DN is configured as trusted and the destination DN is configured with Connected Line Identity Restriction (COLR) which restricts presentation of called line identity to the caller. To enable COLR on the destination DN, set the privacy
option to id
. When SIP Server sends the
200 OK back to the caller it includes the
Privacy: id header and the
P-Asserted-
Identity
header, obtained from the p-asserted-identity
option configured on the on destination device.
Inbound Call From Trusted Entity (COLP)
In this case, the
Trunk
DN is configured as trusted, and the destination DN is configured with Connected Line Identity Presentation (COLP), which allows presentation of called line identity to the caller. To enable COLP on the destination DN, set the p-asserted-identity option on the destination DN.
When SIP Server sends the
200 Ok
back to the caller, it includes the
P-
Asserted-Identity
header.
Inbound Call From Any Entity (CLIP)
In this case, SIP Server passes through the
P-Asserted-Identity
header as the identity of the origination DN, regardless of enforce-trusted
option.
Inbound Calls to GVP
For inbound calls to GVP, the following functionality applies:
•
When GVP receives the
P-Asserted-Identity
header in an incoming
INVITE
, it provides the value of the header as the ANI to the VoiceXML application.
•
When GVP receives both the
P-Asserted-Identity
and privacy
headers in an incoming
INVITE
, it provides the value of both headers to the VoiceXML application.
306 Framework 8.1
Chapter 5: SIP Server Feature Support Network Asserted Identity
•
For call transfers using the
<transfer>
tag, the VoiceXML application can set the
P-Asserted-Identity
and privacy headers to be used in the
INVITE from GVP to SIP Server.
•
If the VoiceXML application does not set the
P-Asserted-Identity
and privacy
headers for the call transfer, GVP will propagate the header values from the inbound call leg to the outbound call leg during the transfer.
Outbound Calls
When generating an outbound
INVITE
request, SIP Server will establish privacy if the
Extension
DN that initiates the call is configured with the privacy
option set to id
and the p-asserted-identity
option set to the correct URI and enforce-trusted
is set to true
. In this case, SIP Server will replace the
From with an anonymous URI and add both the privacy
and
P-Asserted-Identity headers to the
INVITE
.
SIP Server Domain
Agent
T-LIB Client
Outbound Call to Non-Trusted Entity (Restricted Identity)
shows a sample call flow for an outbound call from a trusted internal
DN to an untrusted external destination.
Agent SIP Phone
SIP Server
External Domain
Destination Trunk
INVITE 8000
From: 7000 options: enforce- trusted=true p-asserted-identity="Bob" <sip:[email protected]> privacy=id
INVITE 8000
From: Anonymous
Privacy: id
180 Ringing options: enforce-trusted=false
EventDialing
(Extension: PRIVACY=id)
200 OK
200 OK
Figure 30: Outbound Call to Non-Trusted Destination (With Privacy Restriction)
In this case, the
Extension
DN 7000 is configured as both requesting privacy and as a trusted entity. On receiving the
INVITE
from DN 7000, SIP Server translates the
From
to
Anonymous
and adds the privacy:id
header. However, because the
INVITE
is addressed to the non-trusted gateway
Trunk
DN 8000
( enforce-trusted
option set to false
), SIP Server does not include the
P-
Asserted-Identity
header—no personal information is available for the rest of the call.
SIP Server—Deployment Guide 307
Chapter 5: SIP Server Feature Support Network Asserted Identity
Outbound Call to Trusted Entity (Restricted Identity)
In this case, the outbound
Trunk
DN represents a trusted external domain so it is configured with enforce-trusted
option set to true
. The internal DN placing the call is configured for privacy. On receiving the outgoing
INVITE
from the internal DN, SIP Server translates the
From
to
Anonymous
and adds both the privacy:id
header as well as the user identifying
P-Asserted-Identity
header.
Outbound Call to Any Entity (CLIP)
In this case, the internal DN placing the call is configured for presentation using only the p-asserted-identify option. On receiving the outgoing
INVITE from the internal DN, SIP Server passes through the user identifying
P-Asserted-Identity
header, regardless of enforce-trusted
option.
Internal Call (CLIR)
In this scenario, an internal DN sends a CLIR call to another DN on the same domain. For example, if the caller (DN1) is configured for privacy, and the called party (DN2) is configured as non-trusted, SIP Server sends an anonymous
INVITE
without the
P-Asserted-Identity
header:
DN1@SIPServer1 → DN2@SIPServer1
INVITE sip:DN2@SIPServer1:5060 SIP/2.0
From:“Anonymous” <sip:[email protected]>;tag=1928301774
To: <sip:DN2@SIPServer1:5060>
Privacy: id
shows a sample call flow for an internal call from a trusted
Extension DN to an untrusted Extension DN within the SIP Server domain.
SIP Server Domain
Agent
T-LIB Client
Agent SIP Phone
SIP Server
Destination SIP Phone
INVITE DN2
From: DN1 options: enforce-trusted=true privacy=id options: enforce-trusted=false
INVITE DN2
From: Anonymous
Privacy: id
180 Ringing
EventDialing
(Extension: PRIVACY=id)
200 OK
200 OK
Figure 31: Internal Call From Trusted Entity to Non-Trusted Entity
308 Framework 8.1
Chapter 5: SIP Server Feature Support Network Asserted Identity
In this case, the calling entity (DN1) is configured to request privacy. The destination (DN20 is configures as non-trusted. When SIP Server receives the
INVITE
to place the call from DN1 to DN2, it adds the privacy:id
header, anonomizes the
From
header, but does not insert
P-Asserted-Identity
to the outgoing
INVITE
that is forwards to DN2.
Feature Configuration
describes how to control privacy for SIP messaging within the network.
Table 72: Configuring Network Asserted Identity
Objective
Request privacy for outbound calls.
Key Procedures and Actions
In the
Extension
DN that places the call, in the
TServer
section, configure the following options:
•
—Set to id
.
•
•
—Set to true
.
Enable privacy presentation on the inbound Trunk.
If the INVITE includes privacy...
In the
Trunk
DN that represents the external device sending the inbound
INVITE
, in the
TServer
section, configure the following option:
•
—Set to true
.
If the INVITE does not include privacy...
In the
Trunk
DN for the external device, in the
TServer
section, configure the following options:
•
—Set to true
.
•
—Set to id.
•
—Set this to the identity you want to include
in the
P-Asserted-Identity
header. If this option is not configured, then SIP Server gets the content from the
From
header instead.
Disable privacy presentation on the inbound Trunk.
In the
Trunk
DN that represents the external device, in the
TServer section, configure the following option:
•
—Set to false
.
Enable privacy presentation on the DN.
For any DN you would like to allow presentation services, in the
TServer
section, configure the following option:
•
—Set to true
.
SIP Server—Deployment Guide 309
Chapter 5: SIP Server Feature Support Network Attended Transfer
Table 72: Configuring Network Asserted Identity (Continued)
Objective Key Procedures and Actions
Enable privacy presentation on the destination DN or outbound
Trunk
DN.
Request presentation for outbound calls.
For the destination DN or outbound Trunk DN, in the
TServer
section, configure the following options:
•
—Set to id
.
•
In the
Extension
DN that places the call, in the
TServer
section, configure the following option:
•
Feature Limitations
The Network Asserted Identity mechanism is not supported on any scenarios involving Routing Points except predictive calls.
Network Attended Transfer
SIP Server supports Network Attended Transfers (NAT)—the ability of an agent on one SIP Server to consult another agent in a multi-site environment before transferring a call. To prevent signaling loops for these types of transfers, SIP Server supports the following transfer and reconnect operations, used to communicate between SIP Server instances:
•
TNetworkConsult
•
TNetworkAlternate
•
TNetworkTransfer
•
TNetworkReconnect
For NAT, SIP Server supports both implicit and explicit transfers, including premature disconnection and blind transfers, as well as reconnect operations.
Network T-Server Replacement
NAT enables SIP Server to take over some of the functionality that was previously provided by Network T-Server—the key differences being that SIP
Server does not support
NetworkMerge
and performs URS-controlled consultations through a separate call.
310 Framework 8.1
Chapter 5: SIP Server Feature Support Network Attended Transfer
How It Works
The following figure provides an overview of the NAT process in a pure SIP environment, with one SIP Server with network capability, and two premise
SIP Server instances that are used to serve agents.
Site A
1. TNetworkConsult request
Agent A
URS
5. Consultation request and confirmation
2. EventRoute-
Request
3. Routing call to
Agent B
SIP Server 1
(with Network T-Server capability)
4. Call data passing
SIP Server 2 SIP Server 3
Site B
6. Consultation with Agent B
Agent B
Figure 32: Steps in Network Attended Transfer in URS-Controlled Mode
Step 1
Agent A makes a request for a consultation with another agent. A
TNetworkConsult
request is relayed to SIP Server. Depending on the parameter settings of the
TNetworkConsult
request, the NAT feature will operate in either
direct or URS-controlled mode. For more information, see the Platform SDK
8.x .NET (or Java) API Reference.
Step 2
(URS-controlled mode only.) SIP Server 1 creates the call (with new
AttributeConnID
) and s ends
EventRouteRequest
to URS.
Step 3
(URS-controlled mode only.) URS locates an available agent at Site B and instructs SIP Server 1 to route the call to Agent B. SIP Server1confirms the initiation of the network transfer by sending
EventNetworkCallStatus
to SIP
Server 2, which then relays it to Agent A.
Step 4
SIP Server 1 proceeds to obtain the access number from SIP Server 3, and passes the call data to SIP Server 3.
Step 5
SIP Server 1 makes the call to Agent B on SIP Server 3. Once the connection is established, SIP Server 1 distributes
EventNetworkCallStatus
to both SIP
SIP Server—Deployment Guide 311
Chapter 5: SIP Server Feature Support Network Attended Transfer
Server 2 and SIP Sever 3, which then relays it to Agent A and Agent B (in direct mode only) respectively, to indicate that the consultation call is being established.
SIP Server 1 also distributes
EventRouteUsed
to URS to confirm successful routing of the call to the selected agent (URS-controlled mode only).
Step 6
At this point, the customer is on hold, and Agent A is consulting with Agent B.
Agent A can do one of the following:
•
End the consultation and retrieve the original customer call.
•
Alternate between Agent B and the customer.
•
Transfer the customer call to Agent B.
Notes:
• SIP Server supports NAT requests with
AttributeHomeLocation provided that this attribute identifies a network location that is capable of processing such requests.
• For network-capable SIP Server, URS-controlled mode is only supported when
RequestNetworkConsult
includes an
AttributeOtherDN
that is set to the CDN of the network-capable
SIP Server, and does not include an
AttributeLocation
.
Feature Configuration
describes how to enable Network Attended Transfers in multi-site environments that include SIP Server.
Table 73: Configuring Network Attended Transfer
Objective
Configure multi-site connection.
Key Procedures and Actions
Configure multi-site connection (ISCC) between
SIP Server (network capable) and either premise
SIP Server (agent) or TDM T-Server instances.
You do not need to configure multi-site connection between premise SIP Sever or T-Server instances.
For details, see “Configuring Multi-Site Support” on page 691
Feature Limitations
•
Because SIP Server creates a new call for URS-controlled consultations
(with a new
AttributeConnID
), SIP Server will propagate
NetworkCallStatus
events to the consulting party only if, in the extrouter
section, you set the option use-data-from
original
.
312 Framework 8.1
Chapter 5: SIP Server Feature Support No-Answer Supervision
•
While processing a Network Transfer, SIP Server may send an incorrect
EventPartyChanged
message if the use-data-from
option is set to current
.
Genesys does not recommend setting the use-data-from
option to current while using the Network Attended Transfer feature.
No-Answer Supervision
This section describes SIP Server’s No-Answer Supervision feature and its configuration.
Business and Private Calls
No-Answer Supervision can be applied to business and private calls.
Business Calls
SIP Server automatically categorizes any call distributed to an agent either from a Queue or from a Routing Point as a business call. Use the following configuration options to define what additional calls to or from an agent are classified as business calls:
•
•
•
•
•
Private Calls
SIP Server categorizes any call that does not fall into the business or workrelated categories as a private call. SIP Server does not apply any automatic business-call handling after a private call. If an agent receives a direct private call while in wrap-up or legal-guard time, the emulated wrap-up or legal-guard timer is not interrupted.
You can apply No-Answer Supervision to private calls using the configuration option
.
Agent No-Answer Supervision
This feature provides the following functionality:
•
If an agent does not answer a call within a specified timeout, SIP Server can divert the call to a sequence of overflow destinations. Alternatively, you can configure SIP Server to return calls automatically to the last distribution device.
SIP Server—Deployment Guide 313
Chapter 5: SIP Server Feature Support No-Answer Supervision
•
If an agent fails to answer a call within a specified timeout, you can configure SIP Server to either log out the agent or set the agent to
NotReady to prevent further calls from arriving.
Configuration Options
SIP Server provides the following configuration options for defining the behavior of the Agent No-Answer Supervision feature:
•
•
•
•
•
Introduced in
SIP Server
8.1.101.52
Reporting ReasonCode
SIP Server can report
ReasonCode
set to no-answer
in the
AttributeExtensions or
AttributeReason
of the corresponding
EventAgentNotReady
message when an agent is placed in the
Not Ready
state after not answering a call.
To enable this functionality, set the
option to notready
at the Application level or the option no-answer-action
at the
Agent
Login
level. For SIP Server to report the
ReasonCode in
AttributeExtensions
,
true
. For SIP Server to report the
ReasonCode in
AttributeReason,
set the
option to false.
Introduced in
SIP Server
8.1.102.01
Defining After Routing Timeout Action
You can define SIP Server’s default action for setting the state of an agent who was not able to answer the routed call before the
expired. Enable this feature with the
configuration option, or the
AFTER_ROUTING_TIMEOUT_ACTION
key in
AttributeExtensions
of
TRouteCall
. The key extension setting takes priority.
Use the agent-no-answer-timeout
option with the corresponding action
specified by the agent-no-answer-action
option to control direct calls to an agent.
Multi-site support added in
SIP Server
8.1.102.38
Note:
Using No-Answer Supervision when the divert-on-ringing configuration option is set to false
does not require the value of noanswer timeout options to be smaller than the value of the afterrouting-timeout option. The value of no-answer timeout options can be bigger than the value of the after-routing-timeout option.
Starting with SIP Server release 8.1.102.38, this feature is supported in multisite deployments. If the original site is configured with the divert-on-ringing option set to false
, but the routing destination resides at another site, this
314 Framework 8.1
Chapter 5: SIP Server Feature Support No-Answer Supervision feature is supported only if SIP Server stays in the signalling path ( oosptransfer-enabled =false
).
When configured, the after-routing-timeout action is performed at the SIP
Server site of the call routing destination.
If after-routing-timeout
is in progress and a caller ends the call, neither agent-no-answer-action
nor no-answer-action
is performed, and an agent state will not be changed.
The after-routing-timeout-action
option configured at the site where the
TRouteCall
request is processed has higher priority than the agent-no-answeraction
and no-answer-action
parameters at the destination site.
Limitations:
•
The after-routing-timeout action is not supported at destinations where there are no agents logged in.
•
The after-routing-timeout action is not supported for Shared Call
Appearance or Hunt Groups.
•
In case of a switchover, the after-routing-timeout
timer is restarted at the new primary SIP Server.
Extension No-Answer Supervision
The No-Answer Supervision feature includes devices of type
Extension.
If a call is not answered on an extension within a specified timeout, SIP Server can divert the call to a sequence of overflow destinations. Alternatively, you can configure SIP Server to return calls automatically to the last distribution device.
Configuration Options
SIP Server provides the following configuration options for defining the behavior of No-Answer Supervision with devices of type
Extension
:
•
•
Position No-Answer Supervision
The No-Answer Supervision feature includes devices of type
ACD Position.
If a call is not answered on a position within a specified timeout, SIP Server can divert the call to a sequence of overflow destinations. Alternatively, you can configure SIP Server to return calls automatically to the last distribution device.
SIP Server—Deployment Guide 315
Chapter 5: SIP Server Feature Support No-Answer Supervision
Configuration Options
SIP Server provides two configuration options for defining the behavior of No-
Answer Supervision with devices of type
ACD Position
:
•
•
Device-Specific Overrides
SIP Server provides three configuration options to configure device-specific overrides for individual devices. You set the values for these options in the
TServer
section of the individual device.
The options are:
•
•
•
Note:
The no-answer-action, no-answer-overflow
, and no-answer-timeout configuration options are not supported on
Voice over IP Service
DNs in which service-type
set to softswitch
.
Extension Attributes for Overrides for Individual Calls
For all of the No-Answer Supervision options, you can specify the corresponding
Extension
attribute in the
TRouteCall
request, to override the configured value for individual calls. This method allows the no-answer behavior to be determined in a routing strategy. The three extensions are:
•
•
•
Feature Limitations
To use No-Answer Supervision when the
configuration option is set to false
, follow these configuration guidelines:
1. The value of no-answer timeout options ( extn-no-answer-timeout, agentno-answer-timeout, posn-no-answer-timeout, or no-answer-timeout) must be smaller than the value of the after-routing-timeout
option (5 seconds of the time difference is recommended).
2. The value of no-answer overflow options ( extn-no-answer-overflow, agent-no-answer-overflow, posn-no-answer-overflow,
or no-answeroverflow
) must not be set (they must be empty).
316 Framework 8.1
Chapter 5: SIP Server Feature Support Outbound IP Solution Integration
Some details to consider: An agent phone is released from the ringing state as soon as the after-routing-timeout
expires. At the same time, the agent state will be changed as specified by the
no-answer-action
or agent-no-answeraction
option. If a call is answered when the no-answer timeout
expires, but before after-routing-timeout
expires, the call will be established normally, and there will be no change in the agent state specified by options no-answeraction
or agent-no-answer-action
.
Outbound IP Solution Integration
SIP Server supports the Outbound IP Solution, an offering that combines SIP
Server IP signaling with the media services of the Genesys Voice Platform
(GVP) to provide IP-based outbound call campaign functionality. Using either
GVP or the Outbound Contact Server (OCS) to initiate the outbound call,
Outbound IP can perform media services as needed—for example, Call
Progress Detection (CPD) to determine if the called party is a voice or not—and then connect the called party with a Voice XML application for the voice self-service portion of the call.
Outbound IP functionality can be provided through either of the following deployments:
•
Voice Platform Solution (VPS) deployment—This configuration uses a third-party “trigger” application to manage the outbound call campaign.
GVP initiates the outbound call, provides media services, and connects the called party to the voice self-service application.
For more information, see the Voice Platform Solution 8.1 Integration
Guide.
•
Outbound Contact Server (OCS) in an Outbound-VoIP deployment—This configuration uses OCS to manage the outbound call campaign. In this case, OCS initiates the outbound call, while GVP still provides the media services and connects the called party to the voice self-service application.
For more information, see the Outbound Contact 8.1 Deployment Guide.
SIP Server Features for Outbound IP Solution
describes SIP Server features required for the Outbound IP Solution.
SIP Server—Deployment Guide 317
Chapter 5: SIP Server Feature Support Outbound IP Solution Integration
Table 74: SIP Server Feature Support for Outbound IP Solution
Feature Related Options
Device selection procedure
SIP Server incorporates two parameters required by the Outbound IP Solution into the procedure that it uses to select the most appropriate device from a pool of compatible device.
Note: The partition-id for a particular predictive outbound call is assigned based on the partition-id
setting on the Routing Point or
Trunk Group
DN that the call is made from.
For more information, see “Working with Multiple Devices” on page 394 .
•
•
Additional error codes for predictive call failure
When SIP Server tries to engage the GVP Media Control Platform (MCP) to make a predictive call, and MCP returns a SIP error, SIP Server adds this error as an integer value in the new key-value pair,
MediaServerErrorCode
, that it reports to the T-Library clients in the
UserData
for the call.
• No configuration required.
Support for MSML
To support Outbound IP, GVP can integrate with SIP Server using the Media
Server Markup Language (MSML) protocol
.
•
•
Configurable beep timer
SIP Server supports a timer to control the duration of the beep tone used to notify agents participating in an outbound campaign when they are about to be connected to a customer (this option is only available if the outbound campaign is running in the Active Switching Matrix (ASM) mode). Beep tones are configured as Extensions in
TMakeCall
requests. To configure the duration of a beep tone,
SIP Server provides the option
, configured on the GVP Resource
Manager
Trunk Group
DN.
•
Updated timeout for CPD INFO messages
SIP Server supports a modified
•
318 Framework 8.1
Chapter 5: SIP Server Feature Support Outbound IP Solution Integration
Table 74: SIP Server Feature Support for Outbound IP Solution (Continued)
Feature Related Options
Additional Extensions in TMakePredictiveCall
SIP Server supports the OCS ability to add CPD results as the keys in key-value pairs included the
Extensions
attribute of
TMakePredictiveCall
requests:
•
•
•
Use these extensions—configured with the value drop
—to override the corresponding SIP Server Application-level options am-detected
, fax-detected
, and silence-detected
, in cases where any of these options are set to the value connect.
If any of these key-value pairs appear in the
AttributeExtensions
of the
TMakePredictiveCall
, SIP Server disregards its own option settings and drops the call when the corresponding CPD result (
AM
,
FAX
,
Silence
) is detected.
Limitation
Currently, support for these OCS additions to the Extensions attribute is limited.
For details, see the first item in the “Feature Limitations” list on page 323 .
•
•
•
CPD Performed by Media Gateway
If the media gateway is configured to perform CPD analysis, SIP Server sends the
CPD result to GVP as parameters in the MSML dialog. For example, in the
MSML-
INFO
message that SIP Server sends to start a treatment on GVP.
Prior to release 810, CPD results were returned in either
INFO
messages for
Audiocodes gateways, or in
200 OK messages for Paraxip. If you prefer to use
INFO
message for Audiocodes, you can specifically configure that backwards
compatible behavior using the option info-pass-through
For more information about configuring a media gateway trunk for CPD, see the
Voice Platform Solution 8.1 Integration Guide.
•
•
(for backward compatibility)
CPD Performed by Genesys Media Server
SIP Server enables you to improve the reliability of silence detection in deployments where CPD is performed by the Genesys Media Server. The timeguard-reduction
configuration option can be used to make the time interval used by the Media Server for post-connect CPD shorter than the time SIP Server is waiting to receive a CPD result from the Media Server.
Proper configuration can guarantee that SIP Server will always receive CPD results from the Media Server on time and will never be forced to provide its own default CPD result when its internal timeout expires. This feature applies mostly to silence detection because a CPD result of silence takes the longest time to be detected and the highest risk of SIP Server internal timer expiration. Use the timeguard-reduction
option to improve silence detection quality.
•
•
SIP Server—Deployment Guide 319
Chapter 5: SIP Server Feature Support Outbound IP Solution Integration
Table 74: SIP Server Feature Support for Outbound IP Solution (Continued)
Feature Related Options
Routing to Alternate Destination
SIP Server supports routing the call to a special destination in cases where the
CPD result shows that a fax, answering machine, or silence was detected on the other end.
Alternate routing is implemented the following ways:
• Routing Point-based calls
SIP Server sends CPD results in either the
CallState
or
UserData
of the
EventRouteRequest
. The routing strategy can use this information to send the call to an alternate extension.
• Trunk Group-based calls
Starting with version 8.1.101.51, SIP Server attaches CPD results (using the
AnswerClass
key with values
AM, FAX,
or
SILENCE
) in
UserData
along with
CallState
of
EventEstablished/EventReleased
messages on a
Trunk Group
DN. The routing strategy can use this information to send the call to an alternate extension.
CPD in the CallState
Depending on the CPD results, SIP Server returns one of the following
CallState values in the
EventRouteRequest/ EventEstablished
:
•
CallStateFaxDetected
•
CallStateAnsweringMachineDetected
•
CallStateSilenceDetected
CPD in UserData
Depending on the CPD results, SIP Server can return CPD results in UserData, using the
AnswerClass
key with one of the following values:
•
AM
•
FAX
•
SILENCE
Limitation
• For details about how SIP Server am, fax,
and silence-detected
options interact with OCS functionality, see
“Feature Limitations” on page 323 .
This functionality is implemented either in the routing strategy or in the OCS configuration, depending on the call flow.
For more information, consult the following guides:
• Universal Routing
8.1 Reference
Manual
• Outbound Contact
8.1 Deployment
Guide
320 Framework 8.1
Chapter 5: SIP Server Feature Support Outbound IP Solution Integration
Table 74: SIP Server Feature Support for Outbound IP Solution (Continued)
Feature Related Options
Cancelling Calls to Voicemail Number
SIP Server can cancel outbound Predictive Calls when the outbound gateway returns a voicemail number in the redirectNumber
of the
181 Call Is Being
Forwarded
response to the initial outbound
INVITE
request.
The redirectNumber
header includes the number to which the call is being redirected, as well as the reason for the redirection. If SIP Server matches the number in the header to the configured voicemail pattern in the outbound
Trunk configuration, SIP Server cancels the call, mapping the reason to a Genesys call state (for example, Busy).
Option Configuration
You can configure the
voicemail-pattern-<n>
option in the
Trunk
DN representing the outbound calling gateway.
Extensions Configuration
You can also use the key-value pair voicemail-pattern
in the
Extensions attribute of
TMakePredictiveCall
requests to match the redirectHeader
to a particular voicemail number. Multiple patterns can be configured in a commaseparated list. If present in the
TMakePreditiveCall
, this value takes precedence over the Trunk configuration.
•
Media Server alarms
SIP Server supports two alarms used to report the state of the SIP Server subscription to the GVP Resource Manager (RM), for Media Server functionality.
If the
SUBSCRIBE
message sent by SIP Server is rejected or times out, SIP Server generates the following alarm message:
52005 - Media Server <NAME> failed to accept subscription. Subscription is unavailable.
Once the subscription is reactivated (a new
SUBSCRIBE
message for an inactive subscription results in a
200 OK
from the RM), then SIP Server generates the following alarm message:
52006 - Subscription to Media Server <NAME> is restored.
These alarms are useful in cases where the RM is running but is unable to accept the subscription. In this case, the
Trunk Group
DN for outbound calls remains in service, but no subscription is available. The
52005
alarm reports this condition. If the subscription is later restored, the
52006
alarm is generated.
Note: If Active Out-of-Service Detection is configured for the outbound
Trunk
Group
DN ( oos-check
option), SIP Server does not generate the
52005
and
52006 alarms. With Active Out-of-Service Detection, failures are reported using
EventDNOutOfService
and corresponding alarms, as per existing Active Out-of-
Service Detection functionality. Genesys recommends using the Active Out-of-
Service Detection method for monitoring Resource Manager availability; the
52005
and
52006
alarms are offered as backup.
•
SIP Server—Deployment Guide 321
Chapter 5: SIP Server Feature Support Outbound IP Solution Integration
Table 74: SIP Server Feature Support for Outbound IP Solution (Continued)
Feature Related Options
Predictive calls on a Routing Point DN
SIP Server supports a modified
predictive-call-router-timeout
•
Mapping SIP error codes to Genesys call states
SIP Server maps error codes received from the media gateway (in response to predictive-call
INVITE
requests) to specific values in the
AttributeCallState included in the
TEvent
response to the
TMakePredictiveCall
request. By default,
SIP Server uses a hard-coded map of error codes and T-Library messages.
The hard-coded map is as follows, in the format
ErrorCode
—>
TEvent
:
• 404 —>
CallStateSitInvalidnum
• 408 —>
CallStateNoAnswer
• 503 —>
CallStateGeneralError
• 504 —>
CallStateSitNocircuit
• 603 —>
CallStateDropped
• 486 —>
CallStateBusy
•
Feature Configuration
describes configuration options for the Outbound IP solution, which you configure in the
TServer
section of the GVP Resource Manager
Trunk
Group
DN.
Table 75: Configuring the GVP DN for Outbound IP
Option
Setting
Set this option to the Resource Manager IP address and SIP port
(typically
5060
), using the following format: sip:<RM_ip_address>:<RM_sip_port>
Set this option to
1
. This instructs SIP Server to use the 3pcc call flow as defined in the RFC 3725.
Set this option to false
. It forces SIP Server to use the re-
INVITE
method instead of
REFER
, as required for 3pcc calls.
Set this option to false
(no ringtone is required for scenarios that may include CPD).
322 Framework 8.1
Chapter 5: SIP Server Feature Support Outbound IP Solution Integration
Table 75: Configuring the GVP DN for Outbound IP (Continued)
Option
Setting
Set the user part of the URI to msml,
and identify the tenant-id
as the name of the tenant. Format the value of this option as follows: sip:msml@<RMHost>:<RMPort>;media-service=cpd;gvp-tenantid=[<tenant name>]
For example: sip:[email protected]:57393;media-service=media;gvp-tenantid=[Environment]
SIP Server sends an
INVITE
request to Resource Manager with the
Request-uri modified to tell GVP to act as media server for the call.
Set this option to the name of the Tenant to which this
Trunk Group
DN belongs. For a single-tenant deployment, set this option to
Environment
.
Note: Starting in GVP 8.1.2, multi-tenancy is supported.
Set this option to the following:
• mediaserver
—This enables CPD analysis to be performed by the
MCP.
If CPD is to be performed on a media gateway instead, you do not need to configure this option on this DN. Instead, configure it on the
Trunk
DN for the media gateway (set to paraxip
or audiocodes
, depending on the gateway).
For more information about configuring a media gateway trunk for CPD, see the Voice Platform Solution 8.1 Integration Guide.
Feature Limitations
•
OCS is able to assign a value of either drop
or a particular destination DN
(to which the outbound call with a corresponding CPD result should be connected) in the key-value pairs added to the
Extensions
attribute of the
TMakePredictiveCall
request. However, SIP Server in this integration supports only the value drop
. In this case, SIP Sever will drop the call if it detects these key-value pairs in the
Extensions
attribute, regardless of its own internal settings ( am-detected, fax-detected,
or
silence-detected set to connect
). In addition, if any of these SIP Server options are set to drop
, SIP Server is unable to connect the call with a corresponding CPD result to the alternate destination DN provided by the OCS Extensions.
•
After establishing a connection, certain SIP phones can disconnect the call if no RTP packets arrive before a predefined time period runs out. In the
Outbound IP Solution, this disconnection can occur when an agent is waiting for an engaged call to be connected to the customer. To avoid this issue, disable the RTP timeout feature in the configuration of the agent's SIP phone.
SIP Server—Deployment Guide 323
Chapter 5: SIP Server Feature Support Overload Control
•
When using the Paraxip gateway for Outbound IP, SIP Server cannot disable AM detection using the
TMakePredictiveCall
request. If you set the
Extension answer_type_recognition
to no_am_detection
in the
TMakePredictiveCall
request, SIP Server might still report AM as the CPD result in the
EventEstablished
that it generates for the call.
•
Early media for outbound predictive calls is not supported.
Overload Control
SIP Server includes an overflow control mechanism to gracefully handle situations where the load on the SIP Server exceeds its configured rate capacity threshold(s). If SIP Server encounters an overload situation, it first sends a warning stating that one of its monitored capacity levels has been reached. If the load continues to increase, SIP Server will then take graceful action to gradually reduce the load for the particular exceeded level, by rejecting calls with SIP
503 (Service Unavailable)
responses. SIP Server will send a warning cancelled message once the level is reduced to an acceptable level. In cases of severe overload, SIP Server will start immediately rejecting all new requests altogether.
How Overload Control Works
SIP Server monitors the current load levels for the following load factors:
•
Dialog Rate—The number of newly created SIP dialogs per second.
•
Call Rate—The number of newly created calls per second.
•
T-Request Rate—The number of incoming T-Requests.
If SIP Server discovers the load level for any of these factors exceeds the acceptable limit, SIP Server takes action in three phases: Warning, Reaction, and Severe.
Stages of Overload Control Actions
1. First, when the dialog rate reaches 20% or higher above the configured overload-ctrl-dialog-rate
, SIP Server issues a warning message stating that the maximum capacity for that level has been exceeded, and by what percentage.
For example, if the dialog rate rises too far above the maximum capacity,
SIP Server will issue a Warning alarm:
52012|TRACE|GCTI_OVRLOAD_WARN_START|Overload warning mode
DIALOGRATE started
2. If the dialog rate continues to rise past a certain critical percentage (30% above the configured dialog-rate), SIP Server sends a Reaction alarm message, and begins to take gradual action to reduce the load.
324 Framework 8.1
Chapter 5: SIP Server Feature Support Overload Control
52014|STANDARD|GCTI_OVRLOAD_REACT_START|Overload reaction mode '%s' started
Note:
The variable
‘%s’
in this message represents the mode of the overload condition:
CALLRATE, DIALOGRATE.
3. Once the load is reduced to a less than critical level, SIP Server cancels the
Reaction alarm.
52015|STANDARD|GCTI_OVRLOAD_REACT_STOP|Overload reaction mode '%s' stopped
4. Once the load is reduced even further and reaches an acceptable level, SIP
Server cancels the Warning alarm:
52013|TRACE|GCTI_OVRLOAD_WARN_STOP|Overload warning mode '%s' stopped.
Note:
If SIP Server experiences a severe overload (overall call rate reaches
50% or higher than the overload-ctrl-call-rate-capacity
), it immediately begins rejecting all new requests, sending Warning and
Reaction alarms, in either order.
shows the different stages of overload control, and how the capacity rates determine how the stages are implemented.
Severe Overload Control
(All Traffic Rejected)
Overload Control
(Excess Traffic Rejected with SIP 503 Response)
W arning Stage
(W arning Messages Logged)
Buffer Stage
Normal Operation
150%
If the call rate (both allowed and rejected) reaches 50% or higher than the overloadctrl-call-rate-capacity, SIP Server begins rejecting all new requests. All CPU resources are used to send 503 responses.
130%
W hen the dialog rate reaches 30% above the overload-ctrl-dialog-rate-capacity rate, SIP Server starts gradually reducing the load by sending 503 Service
Unavailable responses.
120%
If overload-ctrl-threshold is enabled, SIP
Server sends a warning when the dialog rate reaches 20% above the configured overload-ctrl-dialog-rate-capacity.
100%
Figure 33: Stages of Overload Control Reaction
SIP Server—Deployment Guide 325
Chapter 5: SIP Server Feature Support Overload Control
Recommended Settings
shows a sample historical graph representing peak periods of call volume, and how overload control settings should be set to handle the maximum demand experienced by SIP Server.
Boxing Day
8 PM EST
“Black Friday”
6 PM EST
< Represents peak demand on SIP Server.
< Set call-rate to 2x this max.
<
Set dialog-rate to 6x this max.
<
Set threshold to the peak for a “typical day”.
<
Make sure these capacity rates consume no more than 40% hardware capacity (peak demand should take up no more than 80% of system resources).
Typical Day
Historical Call Volume
Figure 34: Sample Historical Call Volume and Recommended Overload Control Settings
T-Request Rate Control
If SIP Server encounters an overload situation with an excessive number of incoming T-Requests, it first sends a warning that states that the capacity level has been reached. If the load continues to increase, SIP Server takes a graceful action to reduce the load. If a T-Requests rate exceeds the capacity, SIP Server rejects all excessive T-Requests with
EventError
(error code
TERR_SERV_UNAVAIL118
and the following text:
Request rate exceeded threshold
). If the T-Requests rate for a given call exceeds capacity, SIP Server rejects either the corresponding or all excessive T-Requests for the given overloaded calls by sending the
EventError
(error code
TERR_SERV_UNAVAIL118
).
If a particular (
UserData
or
ApplyTreatment
) T-Requests rate for a given call exceeds capacity, SIP Server rejects excessive corresponding T-Requests for the given overloaded call with
EventError
(error code
TERR_SERV_UNAVAIL118
).
SIP Server continues processing T-Requests for all other calls. It sends a warning canceled message once the T-Requests volume is reduced to an acceptable level for non-call-related thresholds.
326 Framework 8.1
Chapter 5: SIP Server Feature Support Overload Control
Introduced in
SIP Server
8.1.102.33
CPU Usage Overload Control
This feature provides the ability to control SIP Server's CPU usage overload by decrementing the server's log level when the CPU usage overload threshold is reached. Overload is detected by per-thread CPU usage measurement. CPU usage is checked every 10 seconds. If the CPU usage of any core SIP Server
thread exceeds the value specified in the log-reduce-cpu-threshold
configuration option, the log level is decremented to allow SIP Server to handle traffic more efficiently. Once the load drops below 40% of the logreduce-cpu-threshold
configuration option setting, it remains at that level for approximately 300 seconds; after that the logging level is restored to the initially configured level.
When configuring the overload threshold, keep in mind the following:
•
The threshold value must not be configured too high; otherwise, the reduced logging can bring a risk not being enabled at all.
•
The threshold must not be configured too low; otherwise, the lack of logging will make troubleshooting impossible in case of any failure.
Genesys recommends monitoring the SIP Server usage during a typical load spike period, detecting both the start and finish of the period, so the overload threshold is set appropriately.
In HA deployments, the primary and backup SIP Servers monitor and process overload conditions independently. For example, the primary server might be overloaded, while the backup server is not.
Feature Configuration
describes how to configure overload control for any of the different overload factors.
Table 76: Configuring Overload Control
Objective
Enable the Dialog Rate and Call
Rate overload control mechanism.
Related Procedures and Actions
In the SIP Server
Application
object, in
Options
>
TServer section, configure the following:
•
—Set this threshold to the call rate
(per second) at which SIP Server starts taking overload control action.
Notes:
• This option enables the overload control feature as a whole.
• Value of this threshold must be at least four times smaller than
overload-ctrl-dialog-rate-capacity
smaller than
overload-ctrl-call-rate-capacity
.
SIP Server—Deployment Guide 327
Chapter 5: SIP Server Feature Support Overload Control
Table 76: Configuring Overload Control (Continued)
Objective
Set the capacities for individual load factors for the Dialog Rate and Call Rate control mechanism.
Related Procedures and Actions
In the SIP Server
Application
object, in
Options
>
TServer section, set the thresholds for the individual load factors as follows:
•
overload-ctrl-dialog-rate-capacity
SIP Dialog Rate (per second) capacity above which SIP Server begins taking corrective action.
•
overload-ctrl-call-rate-capacity
—Set this factor to the Call
Rate (per second) capacity above which SIP Server begins taking corrective action.
Notes:
• These options define the limits for the hardware on which SIP
Server is running, so that SIP Server knows what action to take as these limits are approached. However, no action is taken
unless the feature as a whole is enabled (using overload-ctrlthreshold
).
• SIP Server enforces a call-rate capacity at least 2x higher than the threshold, and a dialog-rate capacity at least 4x higher than the threshold.
• The default values for these capacity rates assume that SIP
Server is running on fairly robust hardware. For older machines,
Genesys recommends setting these capacity rates to a lower
value. You may also need to check that the overload-ctrlthreshold
value is still correct.
328 Framework 8.1
Chapter 5: SIP Server Feature Support Overload Control
Table 76: Configuring Overload Control (Continued)
Objective
Enable T-Request Rate control.
Related Procedures and Actions
In the SIP Server
Application
object, in
Options
>
TServer section, configure the following:
•
T-Request rate (per second) that SIP Server is able to maintain without performance degradation.
•
overload-ctrl-call-trequests-rate
T-Request rate (per second) that is allowed for each call. This prevents performance degradation if particular clients issue too many requests. If the T-Request Rate for any particular call exceeds the configured value, SIP Server first sends a warning and, if T-Requests continues to increase, SIP Server rejects excessive T-Requests for that call.
•
overload-ctrl-call-tupdateuserdata-requests-rate
this option to the User Data update T-Request
(T
AttachUserData, TUpdateUserData, TDeleteUserData,
TDeletePair
) rate (per second) that is allowed for each call. If the T-Request Rate for any particular call exceeds the configured value, SIP Server first sends a warning and, if
T-Requests continues to increase, SIP Server rejects excessive
User Data T-Requests for a particular call.
•
overload-ctrl-call-tapplytreatment-requests-rate
the
TApplyTreatment
request rate (per second) that is allowed for each call. If the T-Request Rate for any particular call exceeds the configured value, SIP Server first sends a warning and, if T-Requests continues to increase, SIP Server rejects excessive
TApplyTreatment
requests for that particular call.
Disable the Dialog Rate and Call
Rate overload control mechanism.
In the SIP Server
Application
object, in
Options
>
TServer section, configure the following:
•
—Set this threshold to
0
. This will completely disable the Dialog Rate and Call Rate overload control feature.
Disable the T-Request Rate control mechanism.
In the SIP Server
Application
object, in
Options
>
TServer section, set the following options to
0,
as required:
• overload-ctrl-call-trequests-rate
• overload-ctrl-call-tupdateuserdata-requests-rate
• overload-ctrl-call-tapplytreatment-requests-rate
• overload-ctrl-trequests-rate
Enable CPU usage overload control.
In the SIP Server
Application
object, in
Options
> overload section, set the
option as required.
SIP Server—Deployment Guide 329
Chapter 5: SIP Server Feature Support P-Access-Network-Info Private Header
P-Access-Network-Info Private Header
SIP Server supports passing the
P-Access-Network-Info
header, as described in
RFC 3455 “Private Header (P-Header) Extensions to the Session Initiation
Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP).” This header can be used to provide access network, location, and emergency call information about the user agent. SIP Server supports the
P-Access-Network-
Info
header only in
INVITE
and
UPDATE
messages.
The
P-Access-Networ k header is passed only when both the calling and destination DNs are configured with
set to true
.
Personal Greetings
Personal greeting functionality enables Stream Manager or Genesys Media
Server to play a media file to a customer and an agent when the agent answers the call. It is possible to play the same file or different files to the customer and agent. You can control how SIP Server handles the personal greeting feature in different scenarios.
This section describes the following greeting features and their configurations:
VXML Support for Agent Greeting, page 332
Disabling Media Before Greeting, page 334
Recording an Agent Greeting, page 335
Filter Greetings By Call Type
Starting in 8.1.100.78, SIP Server lets you suppress agent greetings for different call types. You can block greetings for internal, consultation, and outbound calls, either globally at the Application level, or individually per
Agent Login, by setting the
option, as described below.
Enabling Personal Greetings
describes the basic steps required to enable personal greetings.
330 Framework 8.1
Chapter 5: SIP Server Feature Support Personal Greetings
Table 77: Enabling Personal Greetings
Objective
(Mandatory) Configure the
Agent Login.
(Optional) Configure a routing strategy.
(Optional) Configure the SIP
Server Application.
Key Procedures and Actions
Go to the SIP Server
Switch
object >
Agent Logins folder >
Agent
Login
object. In the
TServer
section, configure the following options:
•
—Set to the name of the media file that will be used as a greeting for the agent.
•
—Set to the name of the media file that will be used as a greeting for the customer. The customer greeting plays continuously until the agent greeting finishes playing.
• (Optional)
internal, consult, and/or outbound
to block greetings for that type of call.
Note: If, for whatever reason, one of these greetings cannot be played, SIP Server does not attempt to play the other greeting, but immediately connects the customer and agent. No greetings are played.
Enable personal greetings by specifying agent-greeting
and
AttributeExtensions
of the
TRouteCall request.
Note: The keys that are contained in
AttributeExtension
take precedence over the options specified in the
Agent Login object. The customer greeting plays continuously until the agent greeting finishes playing.
Control how SIP Server provides greetings for different scenarios.
In the
TServer
section of the SIP Server Application, configure the following options:
•
—Set to true
to enable greetings after transfers or conferences.
•
—Set to internal, consult, and/or outbound
to block greetings for that type of call.
•
EventOffHook
and
EventEstablished
events are sent. Set to false
to send events before the greeting, set to true
to send events after the greeting. If set to true
, it might cause SIP Server to release the call on an
agent DN in the middle of the greeting. See greeting-stops-noanswer-timeout
for details.
•
started
and/or complete
to send notifications.
•
—Set to agent
to play agent greeting once, or set to customer
to play customer greeting once.
•
—Set this option to true
in cases where
SIP Server routes calls via ISCC to another SIP Server instance.
SIP Server—Deployment Guide 331
Chapter 5: SIP Server Feature Support Personal Greetings
Feature Limitation
The following known limitations currently apply to personal greetings:
•
The dynamically requested greeting (for example, through a
TRouteCall request) is not supported in multi-site OOSP call routing scenarios with the
ISCC transaction type direct-uui
.
•
Greetings configured at an Agent Login are not supported for manual outbound calls (MakeCall).
VXML Support for Agent Greeting
Introduced in
SIP Server
8.1.101.29
Support for multisite and BC deployments added in
8.1.101.57
VoiceXML (VXML) support for agent greeting functionality allows an agent to accept, reject, transfer the call (arrived from a Routing Point), or redirect the call (using
TRedirectCall
) to a new destination.
When the agent answers the call, SIP Server informs GVP about the VXML file and Genesys Media Server starts its processing. VXML does the following:
•
Might play the details about the call collected by URS to the agent.
•
Prompts the agent to take action for the call—to accept, reject, or transfer the call to a new destination.
•
Collects the result provided by the agent and passes it as user data to SIP
Server. The VXML file can collect the result from the agent in the following ways:
By asking the agent to press the DTMF keys.
By asking the agent to say some words.
Media Server sends the user data acceptcall
to SIP Server in the SIP
INFO message which terminates VXML file processing. SIP Server receives the user data and based on that does the following:
•
When the agent accepts the call, SIP Server adds the user data acceptcall=true
to the call and connects the agent and the caller.
•
When the agent rejects the call, SIP Server adds the user data acceptcall=false
to the call and returns the call to the same Routing Point.
•
When the agent transfers the call to other destination, SIP Server adds the user data acceptcall=false
to the call and returns the call to the same
Routing Point from which it is routed by URS to the other destination specified by the agent in user data.
Message Example
This is an example of the msml dialog.exit message sent by the MCP at the end of the VXML when an agent rejects the call:
INFO sip:[email protected]:11000 SIP/2.0
From: sip:SVC_Mediaserver@UTE_HOME:11000;tag=C5EC0EA5-84A9-4611-
B864-03E9CBC10EC0-4
332 Framework 8.1
Chapter 5: SIP Server Feature Support Personal Greetings
To: sip:7101@UTE_HOME:11000;tag=F5D150ED-A603-4532-ADF4-
8D8CB1272939-36
Call-ID: [email protected]
CSeq: 1 INFO
Content-Length: 255
Content-Type: application/vnd.radisys.msml+xml
Via: SIP/2.0/UDP 172.24.133.150:53329;branch=z9hG4bK1F4DFBF2-472D-
4068-9747-12AF5BA6720E-3
Contact: <sip:172.24.133.150:53329>
<?xml version="1.0" encoding="UTF-8"?>
<msml version="1.1">
<event name="msml.dialog.exit" id="conn:__MSML-CONN-
ID__/dialog:ivr_application">
<name>acceptcall</name>
<value>false</value>
</msml>
Feature Configuration
describes how to configure VXML support for agent greeting.
Table 78: Enabling VXML Support for Agent Greeting
Objective
1. Configure the SIP Server
Application.
2. Configure the MSML DN.
Key Procedures and Actions
In the
TServer
section of the SIP Server Application, configure the following options for VXML functionality:
•
—Set to false
.
•
true
.
•
—Set to agent
.
•
—(For multi-site deployments) Set
this option to a valid Routing Point.
1. Create a DN of type
Voice over IP Service.
2. In the
TServer
section, configure the following options:
—Set to the Resource Manager IP address and port.
—Set to msml=
. Required for conference and monitoring services only.
—Set to msml
.
—Set to the name of tenant (used for reliability).
(Optional) userdata-map-filter
—Specify a prefix (or a list of prefixes) that must match the initial characters of the key in the
UserData
key-value pair, which SIP Server passes to GVP when agent greeting is played.
SIP Server—Deployment Guide 333
Chapter 5: SIP Server Feature Support Personal Greetings
Table 78: Enabling VXML Support for Agent Greeting (Continued)
Objective Key Procedures and Actions
3. Configure a routing strategy.
1. Enable personal greetings by specifying agent-greeting
keys in
AttributeExtensions
of the
TRouteCall
request.
2. Enable VXML functionality by setting the
key to vxml
. Configure the URS strategy to collect some basic details about the call and to route the call to the agent with the agent greeting VXML file. The VXML file can be in a regular file directory (file://) or on a web server (http://). The
TRouteCall request must have this VXML file along with agent greeting and customer greeting music files.
3. For multi-site deployments: The URS strategy must be able to route a call to the origination Routing Point on the origination SIP
Server. URS can find this information from the
AttributeLastTransferOrigDN
in the
EventQueued
message.
Feature Limitations
VXML support for agent greeting has the following limitations:
•
This feature is supported for MSML-based integration only.
•
Customer greetings are only voice files. VXML files for customer greetings are not supported.
•
This feature is not supported for greetings configured in the
Agent Login object.
•
The
option does not support the direct-uui
ISCC transaction type. Delaying
EventEstablished
until the agent accepts the call is not possible in direct-uui
multi-site call flows.
Disabling Media Before Greeting
Introduced in
SIP Server
8.1.101.50
SIP Server provides the ability to prevent establishing a preliminary audio/video connection between a caller and an agent before greetings are applied. This feature can be applied to scenarios where for a very short time a caller and an agent could hear each other before a greeting starts playing. SIP
Server is able to disable the media connection between the caller and agent for that period of time before greetings are applied.
Feature Configuration
In the
TServer
section of the SIP Server Application (or in the DN object), set the
true
.
334 Framework 8.1
Chapter 5: SIP Server Feature Support Personal Greetings
Feature Limitations
The following known limitations currently apply to the Disabling Media
Before Greeting feature:
•
This feature is enabled only when a call is delivered to an agent from a
Routing Point.
•
This feature does not apply to a greeting after a two-step conference or transfer is completed.
•
This feature does not apply when
TRedirectCall
is used by an agent to whom the call is routed.
•
This feature does not work when early media is involved in a call.
•
The phones must accept an initial
INVITE
with the hold SDP.
•
In the case of the
INVITE
timeout from a Media Server, there is a delay in establishing a media path between a caller and an agent.
•
This feature is enabled only when MSML is used for playing greetings.
•
In the case of a multi-site call, this feature is enabled only for a greeting configured using
TRouteCall
extensions.
Recording an Agent Greeting
Introduced in
SIP Server
8.1.102.26
You can configure SIP Server to record the agent call leg during the personal greeting. This feature works only when both recording and greeting are enabled for the call.
Feature Configuration
To enable recording of the agent call leg during the personal greeting:
1. In the
TServer
section of the SIP Server Application, configure the following options:
option to true
.
true
.
2. Do one of the following:
Set the
option to true in the
TServer
section of the SIP Server Application.
true
in
AttributeExtensions
of the
TRouteCall
request.
If set at both places, the setting in
AttributeExtensions takes precedence.
3. Do one of the following:
option to true
on the agent's DN.
key to source
or destination
in
AttributeExtensions
of the
TRouteCall
request.
SIP Server—Deployment Guide 335
Chapter 5: SIP Server Feature Support Presence from Switches and Endpoints
4. Enable personal greetings by specifying
AttributeExtensions
of the
TRouteCall
request.
Feature Limitations
The following known limitations currently apply to agent greeting recordings:
•
This feature is supported for MSML-based integration only.
•
This feature is supported only for greetings played for inbound calls.
•
This feature is not supported for greetings configured in the
Agent Login object.
Presence from Switches and Endpoints
Presence is an indicator of an agent’s status regarding possible communication.
Presence subscriptions allow SIP Server to receive notifications about the availability status for an agent endpoint and to distribute agent-state TEvents to its clients.
This functionality can be used when:
•
An agent endpoint is behind a third-party softswitch, and that switch is able to provide a notification about the status change for the endpoint. In this case SIP Server is not engaged in signaling for each and every endpoint call, and the endpoint is not registered on SIP Server.
•
Genesys Agent Desktop is not available to the agent, and the agent endpoint supports agent-status notification.
SIP Server can also accept subscription requests from an endpoint, in cases where the endpoint requires notifications regarding the status of a particular
Extension
or
ACD Position
DN.
SIP Server supports the following presence scenarios:
•
“Subscription to SIP Server” on page 336
•
“SIP Server Subscription to Endpoints Behind a Switch” on page 337
•
“Endpoint Sends PUBLISH Requests to SIP Server” on page 338
•
“Agent Login and State Update on SIP Phones” on page 339
•
“Presence Integration with Microsoft Office Communications Server
Subscription to SIP Server
When a user subscribes to a particular
Extension
or
ACD Position
DN on the
SIP Server switch, the user sends a
SUBSCRIBE
request to SIP Server, asking to receive notifications about the targeted DN. In response, SIP Server sends ongoing
NOTIFY
messages whenever the target DN registers with SIP Server,
336 Framework 8.1
Chapter 5: SIP Server Feature Support Presence from Switches and Endpoints indicating whether the DN is in open
status. If the targeted DN is not registered, or the registration has expired, SIP Server sends a
NOTIFY
message indicating a closed
status for that DN.
No configuration on SIP Server is required to accept and process
SUBSCRIBE requests.
SIP Server Subscription to Endpoints Behind a Switch
If SIP Server requires presence information about an endpoint that is behind a third-party switch—where the endpoint DN registers with the third-party switch, and not directly with SIP Server—you must configure a channel that
SIP Server uses for sending the
SUBSCRIBE
request and receiving the subsequent
NOTIFY
messages regarding the presence state of the endpoint. In this case, a specially configured
Trunk
DN provides this channel.
Note:
This presence mechanism is not compatible with other methods of modifying the agent state. For example, the
feature.
Notes:
• A separate
Trunk
DN or
Voice over IP Service
DN is required to
make outbound calls. For more information, see “Configuring
Devices and Services” on page 76
.
• When you are configuring presence subscription for Microsoft
Live Communication Server (LCS), you must also configure the
“channel”
Trunk
DN as specified in “Remote Server Registration” on page 357
.
• When Microsoft Office Communicator is integrated with Microsoft
Office Outlook, and the presence state is set to
In a Meeting
or
Vacation,
LCS sends a presence notification with the
Busy presence state to SIP Server. However, SIP Server is unable to provide
In a Meeting
or
Vacation
presence states to any subscriber.
Instead, a notification with the
Busy
presence state is generated by
SIP Server.
Procedure:
Enabling presence subscription
Start of procedure
1. Create a DN of type
Trunk in the Configuration Layer. Parameters for all presence subscriptions from the SIP Server to a particular softswitch are configured in this
Trunk
DN.
2. Configure these options in the
TServer
section on the
Trunk
DN:
SIP Server—Deployment Guide 337
Chapter 5: SIP Server Feature Support Presence from Switches and Endpoints
•
•
•
•
3. Create a DN of type
Extension
.
4. Configure these options in the
TServer
section on the
Extension
DN:
•
•
•
•
5. Create an
Agent Login
object for each DN that will have subscription enabled. The
Agent Login
name must be equal to the
DN
object name. Each
Agent Login
object must be associated with an agent.
End of procedure
Note:
Any internal calls that are made with this softswitch will not be monitored by SIP Server, and the agent state will be changed by SIP
Server to
Not Ready
.
Endpoint Sends PUBLISH Requests to SIP Server
SIP Server changes the agent state in response to any notifications about presence state changes by using the
PUBLISH
request method. SIP Server accepts the
PUBLISH
request and provides automatic agent state updates based on any presence updates received within the
PUBLISH
request. SIP Server distributes notifications about presence updates to all subscribers based on the presence update received within the
PUBLISH
request.
SIP Server accepts
PUBLISH
requests when they are received for a DN in an internal domain. SIP Server processes the presence update from the
PUBLISH request and distributes presence update notification to all subscribers for this
DN.
The
PUBLISH
request functionality is enabled at the DN level in the
Configuration Layer by specifying the subscribe-presence
must be set to publish
to indicate that presence change notifications are issued from the
PUBLISH
request.
Note:
This functionality has been verified with the Eyebeam SIP endpoint when it is configured to work in
Presence Agent
mode. This mode enables
PUBLISH
request processing.
338 Framework 8.1
Chapter 5: SIP Server Feature Support Presence from Switches and Endpoints
SIP Server updates the agent state when the agent login name matches the DN name. Agent updates are processed as follows:
•
When SIP Server receives a presence notification with an open
status, it performs the following steps:
Confirms if the agent is logged in. If the agent is not logged in, SIP
Server sends an
EventAgentLogin
message.
Confirms if any activity is indicated in the presence notification.
If there is no activity, and if the agent is in a
NotReady
state, SIP
Server sends an
EventAgentReady
message.
If there is activity, and if the agent is in a
Ready
state, SIP Server sends an
EventAgentNotReady
message and attaches the activity from the presence notification as the
ReasonCode
attribute.
•
When SIP Server receives a presence notification with a closed
status, it confirms that the agent is logged in. If the agent is logged in, SIP Server then sends an
EventAgentLogout
message.
•
All notifications about the changes of an agent state are ignored when the agent is in the
NotReady
(
AfterCallWork
) state. The requested agent state is applied when the ACW time is over. For example, if an agent completes the call, SIP Server transfers the agent into the
ACW
state, and the
PUBLISH request with an open
status comes from the agent’s SIP phone, then SIP
Server does not change the agent state immediately. It waits for the ACW time to expire, and then places this agent into the
Ready
state. If in the same scenario SIP Server receives the
PUBLISH
request with a busy
status from the agent’s SIP phone, SIP Server will not change the agent state until the
ACW timer is over, meaning that the agent remains in the
NotReady
state.
Agent Login and State Update on SIP Phones
Introduced in
SIP Server
8.1.101.56
This feature enables an agent to perform agent-related operations from the phone and then synchronize the phone and agent’s desktop. A typical scenario involves an agent using the phone exclusively to log in/log out and set the
Ready/Not Ready
status without using the agent desktop application. Or, if an agent prefers using the agent desktop, then with this feature, the agent login and state will be automatically updated on the phone display. SIP Server fully synchronizes agent actions that are done using the phone or the desktop.
This functionality is implemented using two subscription packages described in the SIP Access Side Extensions Interface document by BroadSoft:
•
Application Server Feature Event Package
•
Hoteling Event Package
SIP phones that support these subscriptions enable agents to perform the following operations without using the desktop:
•
Log in and log out
•
Change the state to
Ready, Not Ready,
or
AfterCallWork
•
Set/synchronize the
Reason
code for the
Not Ready
state
SIP Server—Deployment Guide 339
Chapter 5: SIP Server Feature Support Presence from Switches and Endpoints
SIP Server distinguishes subscription requests by DN (the
From
field) and subscription type (the
Event
field).
Agent Login and Authentication
There is a difference between agent desktop and phone authentication. If an agent logs in to the phone first and enters the password, the agent still must enter the password on the desktop. If an agent logs in to the desktop first and enters the password, the agent gets logged in to the phone automatically. The agent does not re-enter the password to change the agent state or to log out.
High Availability and Business Continuity Deployments
SIP Server synchronizes the agent state if a switchover occurs after the agent logs in from the phone or desktop. If the UDP transport is used, SIP Server continues sending agent state notifications to the phone through the existing subscription. If SIP is sent over TCP, it is expected that the phone should reestablish the TCP connection to SIP Server and use this connection to resubscribe for agent state notifications from SIP Server. If the phone reestablishes the connection but does not re-subscribe, notifications are not sent.
See “Feature Limitations” on page 341
.
In Business Continuity deployments, phones must be configured with a single registration using the FQDN resolved in two IP addresses that correspond to
SIP Server peer 1 and SIP Server peer 2. See Business Continuity deployments in the SIP Server High-Availability Deployment Guide for details.
The Business Continuity recovery steps, if an agent uses both the desktop and phone, are as follows:
•
The desktop remains in the logout state until it receives the registration request from a phone.
•
The phone registers and subscribes.
•
The desktop logs in automatically.
The Business Continuity recovery steps, if an agent uses only a phone, are as follows:
•
The phone registers and re-subscribes.
•
SIP Server sends a notification about the missing the agent-DN link and logout state.
•
The phone can indicate this logout state or automatically re-log in.
Feature Configuration
•
Enable the “ACD agent Availability” and “Hoteling Enhancement” features on the phone.
•
If the ACD login operation on the phone requires agent authentication, provide the agent password in the
Agent Login
configuration object. Note that for agent authentication on the agent desktop, the desktop reads agent information from the
Person
configuration object.
340 Framework 8.1
Chapter 5: SIP Server Feature Support Presence from Switches and Endpoints
Feature Limitations
•
There is no synchronization of subscriptions between primary and backup
SIP Servers. The phone must re-subscribe after the switchover.
•
When an agent uses both the phone and desktop, the phone will not receive notifications after the switchover until the next
SUBSCRIBE
request.
•
If you use phone-based agent operations, the
option must be set to true
or not used at all.
Agent Login Control Using RFC 3863
Note:
Agent login control using RFC 3863 functionality is maintained for backward compatibility with the older versions of SIP phones, which do not support Broadsoft extensions.
For IP phones that support agent-status updates initiated from the device—for example, where the user presses
Login
,
Logout
,
Unavail
, or
Avail
on the phone itself—the endpoint that represents the device can send
SUBSCRIBE
or
NOTIFY requests to SIP Server, which SIP Server then maps into the corresponding
T-Library events.
To enable this mapping, set the option enable-agentlogin-subscribe
true
on the DN that represents the IP phone. In this case, when the agent presses
Login and specifies their agent ID on the IP phone, the agent endpoint sends a
SUBSCRIBE
request to SIP Server. SIP Server generates an
EventAgentLogin message. If the agent presses
Logout
on the phone, the endpoint sends another
SUBSCRIBE
request and an
EventAgentLogout
message is generated by SIP
Server. To control agent-ready status, the agent endpoint sends
NOTIFY
requests with either an open
or a closed
status. SIP Server maps the
NOTIFY
request to an
EventAgentReady
or an
EventAgentNotReady
message, depending on the status.
If agent state was changed as the result of a
RequestAgentReady
or a
RequestAgentNotReady
message, SIP Server notifies the agent endpoint by using a
NOTIFY
request to update agent status on the IP phone.
describes the required configuration for this feature.
Table 79: Mapping Agent Status
Objective
Configure the DN.
Key Actions and Procedures
In the
TServer
section of the
Extension
DN for the IP phone, configure the following:
•
true
.
SIP Server—Deployment Guide 341
Chapter 5: SIP Server Feature Support Presence from Switches and Endpoints
Presence Integration with Microsoft Office Communications
Server 2007
For integrations with Microsoft Office Communications Server (OCS) 2007
R2, presence monitoring between the contact center and the Microsoft OCS environment is used to support the following:
•
Ability for Microsoft OCS 2007 R2 to add a Genesys
Routing Point
DN, configured on SIP Server, as one of its contacts. This allows Microsoft
OCS to push an online
presence status for this contact.
•
Ability for Microsoft Office Communicator or Yahoo Messenger Client to generate IM interactions towards this Routing Point contact.
•
Ability for SIP Server to subscribe to the presence status of a Microsoft
OCS 2007 R2 user—for example, an expert or knowledge worker in the
Enterprise environment with a PSTN phone and Office Communicator—as well as to map this presence status to a Genesys Agent State. For example, an online
status in Communicator maps to the Genesys Agent State
Ready
, offline
maps to
Logged in/NotReady
, while other statuses such as away
, dnd
, or busy
map to
NotReady
.
•
Ability for the OCS knowledge worker to contact agents in the contact center either directly or through additional
Routing Point
DNs (other than the ocs-rp configured for basic presence and routing).
describes how to integrate SIP Server with Microsoft OCS for presence monitoring, based on these assumptions:
•
Access to Microsoft OCS is configured directly through the front-end server (not through Edge server).
•
The OCS user has a PSTN phone with no Genesys client on which to login, or a SIP phone that cannot send
REGISTER
/
NOTIFY
or
PUBLISH
requests to convey presence. In these cases, the ocs-dn
configuration is required.
342 Framework 8.1
Chapter 5: SIP Server Feature Support Presence from Switches and Endpoints
Table 80: Configuring Presence for Microsoft OCS
Objective
1. Configure Microsoft OCS.
2. Configure the SIP Server
Application.
Key Actions and Procedures
In the Microsoft OCS environment, configure the following:
• Add the SIP Server IP address to the list of Trusted Hosts/Server.
IP address—Enter the IP address of the SIP Server host.
Throttle As Server—Enable this setting.
Treat As Authenticated—Enable this setting.
• Create an account/user to represent the Routing Point that you
For example, ocs-rp
Note: The user name on OCS and DN name in the switch must match.
• Create an account/user to represent the expert using Microsoft
Communicator as the IM/Presence endpoint.
• Add a static route through SIP Server.
Domain—Enter the target domain. All requests by MOC users to parties at this domain will be sent to the IP address that you configure for SIP Server below.
For example, domain=callcenter.com
If the MOC user issues a request to [email protected]
,
OCS forwards the request to the static configured SIP Server IP address.
IP address—Enter the IP address of the SIP Server host.
Port—Enter the SIP port used by SIP Server.
Note: You must restart the Front-End Server after configuring a static route.
For details, consult the vendor documentation for Microsoft OCS
2007 R2.
In the
TServer
section, make sure the following option is configured:
•
—Set this to the IP address of the SIP Server host machine (not the URI).
SIP Server—Deployment Guide 343
Chapter 5: SIP Server Feature Support Presence from Switches and Endpoints
Table 80: Configuring Presence for Microsoft OCS (Continued)
Objective
3. Configure the OCS Trunk.
Key Actions and Procedures
In the SIP Server switch, create a
Trunk
DN to represent the
Microsoft OCS front-end server. In the
TServer
section, configure the following options:
•
—Set this to the IP address URI for the Microsoft OCS
2007 front-end server. You must also include the transport parameter, set to tcp
. For example,
192.xxx.xxx.xxx;transport=tcp
• force-online-state-lcs
—Set to true
.
This forces SIP Server to provide an online
status for the ocs-rp to the OCS.
•
—Set this to the Sign-in Name field
(sip:username@domain) for the Route Point user you created in
. Use a SIP URI format.
For example, sip:[email protected]
•
—Set this to any non-duplicated value (no other
Trunk with the same prefix
).
• Set the following options to the domain part of the Sign-in Name.
For example, your-ocs-address.com
•
—Set this to the IP address of the SIP
Server host machine.
•
—Set this to the length of time between SUBSCRIBE requests.
•
—Set this to the Sign-In Name field for
the user you created in Step 1 .
For example, sip:[email protected]
•
register
.
This enables SIP Server to view and map MOC user agent statuses.
For a screenshot of a configured OCS Trunk DN, see Figure 35 on page 346
.
344 Framework 8.1
Chapter 5: SIP Server Feature Support Presence from Switches and Endpoints
Table 80: Configuring Presence for Microsoft OCS (Continued)
Objective Key Actions and Procedures
4. Configure the Routing Point.
Create the
Routing Point
DN to be exposed in the Microsoft OCS environment.
• The name must match the account/name configured in
For example, ocs-rp
.
to the name of the OCS Trunk used for
subscription.
For a screenshot of a configured OCS Routing Point DN, see
5. Configure the Extension DNs. For each expert (using Microsoft Communicator as IM/Presence endpoint), create an
Extension
DN with the following options:
•
—Set this to the IP address or the front-end server. You
must also include the transport
parameter, set to tcp
. For example,
192.xxx.xxx.xxx;transport=tcp
•
—Set to a URI consisting of the Sign-In Name field
for the user (expert) you created in Step 1
.
For example, [email protected]
•
—Set this to the domain served by the OCS.
•
—Set this to the IP address of the SIP
Server host machine.
•
session
.
•
text
.
•
—Set this to the expert account/user name that you created
in
.
For a screenshot of a configure Expert User DN, see Figure 37 on page 347
6. Add contacts in Microsoft
OCS.
To view/access mutual statuses, add all users to the list of contacts for the Route Point, and add the Route Point to the list of contacts for all users.
For more information, see “Feature Limitations” on page 347 .
SIP Server—Deployment Guide 345
Chapter 5: SIP Server Feature Support Presence from Switches and Endpoints
Sample OCS Trunk DN
shows a sample screenshot of a configured OCS
Trunk
DN.
346
Figure 35: Sample OCS Trunk DN
Sample OCS Routing Point DN
shows a sample screenshot of a configured OCS
Routing Point
DN.
Figure 36: Sample OCS Routing Point DN
Framework 8.1
Chapter 5: SIP Server Feature Support Presence from Switches and Endpoints
Sample OCS Expert User DN
shows a sample screenshot of a configured OCS expert user
Extension
DN.
Figure 37: Sample OCS Expert User DN
Feature Limitations
•
Presence information regarding the status of the SIP Server Routing Point
DN is available only to those Microsoft Communicator users authorized to view it. To enable a user to view the Routing Point status, you must do the following:
Run Microsoft Office Communicator once using the Routing Point user account as configured in the OCS 2007 Active Directory.
If additional visibility and access controls are necessary, add all agents authorized to view the status of the Routing Point as contacts.
These steps are required to make changes to visibility. For a simpler solution, consult Microsoft documentation.
•
Microsoft Office Communicator is unable to run on the same host as SIP
Server.
SIP Server—Deployment Guide 347
Chapter 5: SIP Server Feature Support Preview Interactions
Preview Interactions
Preview interactions allow agents to preview desktop interactions before receiving a call. SIP Server sends Preview Interaction messages to the desktop applications using the
EventPrivateInfo
message. The desktop application sends preview interaction messages using the
TPrivateService
request.
SIP Server sends a previewInteractionRequest
message to the desktop application when it receives a
RouteCall
request to a DN that is configured with the
option set to true
.
The desktop application responds with a previewInteractionResponse
message to SIP Server. The previewInteractionResponse
message provides SIP Server with information regarding the agent’s ability to process the incoming interaction. The status
field contains an accepted
value or a rejected
value that specifies if the agent will accept the interaction.
SIP Server sends a previewInteractionAcknowledge
message to the desktop application after it receives the previewInteractionResponse
message from it.
This message informs the desktop application that the previewInteractionResponse
message was successfully processed by SIP
Server.
The previewInteractionCancel
message is sent by SIP Server to an application in the following scenarios if there was an unsuccessful completion of a preview interaction:
•
The preview timeout expired. SIP Server sends the previewInteractionCancel
message with the status
field set to expired
to an application when the previewInteractionRequest
message was issued but SIP Server did not receive a previewInteractionResponse
message
within the specified timeout value for the preview-expired
•
The call was abandoned. SIP Server sends the previewInteractionCancel message to an application with the status
field set to canceled
.
Preview Interaction for IM
SIP Server supports the preview mechanism for Instant Messaging (IM) interactions as well. To enable this mechanism, set the
option to chat
. For more information, see “Preview Interaction” on page 266 .
348 Framework 8.1
Chapter 5: SIP Server Feature Support Providing a Caller ID
Providing a Caller ID
SIP Server supports providing caller ID information that is displayed on a destination party’s phone, and replacing the caller ID with another number if necessary. This feature is supported using either of the following methods:
•
The
Extensions
attribute with the
CPNDigits
key in the following messages:
TMakeCall
TMakePredicitiveCall
TInitiateConference
TInitiateTransfer
TRouteCall
TSingleStepTransfer
TSingleStepConference
If the
CPNDigits
key is set in the
Extensions
attribute, the value of this key overrides the username provided in the URI in the
From
header of the
INVITE
message. This
Extension
is not applicable when performing a
TMakeCall
request using the
REFER
method.
•
option at the
Trunk
DN level. In this case, the caller ID information will be replaced by the SIP URI setting in this option for all outgoing calls through this
Trunk
DN.
Providing Call Participant Info
LCTSupervisor
KVPs introduced in SIP Server
8.1.101.74
SIP Server can distribute information about all call participants—except the trunks allocated for communication between SIP Servers, and distribution devices (such as Routing Points or ACD)—to logged-in agents by using the
SIP
NOTIFY
method and
EventUserEvent
messages. This information is primarily used by T-Library clients, such as Workspace Desktop, to display parties participating in the call.
The information about the call participants is reported in the
Extensions attribute of the relevant event using the following key-value pairs:
•
—An integer that specifies how many parties are
involved in a single call.
•
—An integer that represents a party of the call, where
n
is an integer value starting from
0
.
•
—A string that represents the name of the switch to
which the DN belongs.
The supervisor-related information is reported in the
Extensions
attribute of the relevant event using the following key-value pairs:
•
—An integer that represents the supervisor of the call,
where n
is an integer value starting from
0
.
SIP Server—Deployment Guide 349
Chapter 5: SIP Server Feature Support Providing Call Participant Info
•
—A name of the switch to which this supervisor belongs.
•
—An integer that represents the agent monitored by this supervisor.
•
A supervisor can switch between supervision modes and whenever there is change in supervision mode, SIP Server reports the change in
EventPrivateInfo
.
Using the
EventUserEvent
and
EventPrivateInfo
messages, Workspace
Desktop could improve the customer experience by providing the accurate status of call supervision scenarios.
Note:
Supervision mode is distributed only in the first EventUserEvent message generated immediately after a supervisor answers the call.
Sample Scenario
The following sample scenario describes the enhanced LCTParty interface with the supervision information:
1. Internal DNs 1001 and 1002 are provisioned on Switch A.
2. DN 1002 subscribes to monitor DN 1001 ( mute
mode, call
scope).
3. Inbound call from DN 21001 on Switch B is routed to DN 1001.
4. Call supervision started.
SIP Server generates
EventUserEvent
—immediately after a supervisor answers the call—for DNs 1001@A and 1002@A with the following information:
EventUserEvent
AttributeExtensions
'LCTParty0' '21001'
'LCTParty0_location' 'B'
'LCTParty1' '1001'
'LCTParty1_location' 'A'
'LCTPartiesLength' 2
'LCTSupervisor0' '1002'
'LCTSupervisor0_location' 'A'
'LCTSupervisor0_mode' 'mute'
'LCTSupervisor0_monitoredDN' '1001'
'LCTSupervisorLength' 1
Note:
In a multi-site environment, the Smart OtherDN Handling feature is not supported if you use Workspace Desktop and the LCTParty interface is activated in SIP Server.
350 Framework 8.1
Chapter 5: SIP Server Feature Support Providing Origination DN Name and Location in EventRinging
Feature Configuration
describes how to configure call info for agents.
Table 81: Configuring Call Info for Agents
Objective
1. Configure the
Trunk
DNs.
2. Configure the SIP
Server Application.
Related Procedures and Actions
Set the
option to true for DNs of type
Trunk
that are allocated for direct signaling between SIP Servers. The
NOTIFY
method will be sent only to sessions that are established through such trunks.
For more information, see “Trunk Optimization for
Multi-Site Transfers” on page 383
.
option to true.
To provide call participants’ locations and
supervisor-related information, set the sip-enablecall-info-extended
true
.
Feature Limitations
•
When multi-site supervision is established with the call
scope and if a monitored agent leaves the call, the requests submitted by the supervisor to switch between supervision modes will be rejected by SIP Server.
•
When multi-site supervision is established with the agent
scope and if consultation call supervision is started, the supervisor will not be aware of the consultation call even though the supervisor will be able to hear audio from the consultation call.
Providing Origination DN Name and
Location in EventRinging
Introduced in
SIP Server
8.1.101.85
SIP Server reliably provides the origination DN name and location in
EventRinging
. The agent desktop can use this information to collect extended data about the originating party, such as the agent name, and present it to the destination party while the phone is ringing. In particular, Workspace Desktop
Edition displays this information in the “toast” window, which notifies an agent about a new incoming call.
This feature applies to all scenarios, including transfers, conferences, and call supervision in both single-site and multi-site deployments.
SIP Server—Deployment Guide 351
Chapter 5: SIP Server Feature Support Providing Origination DN Name and Location in EventRinging
SIP Server adds two key-value pairs to
EventRinging
to implement new functionality:
•
OriginationDN
—The name of the origination DN
•
OriginationDN_location
—The name of the SIP Server switch to which the origination DN belongs
Event Examples
The value of
OriginationDN
provided in
EventRinging
is synchronized with the party name delivered through
EventUserEvent
of the LCTParty interface.
EventRinging
AttributeExtensions
'OriginationDN' '21001'
'OriginationDN_location' 'Home'
AttributeThisDN '7101'
AttributeOtherDN '21001'
In the example above, the following LCTParty
EventUserEvent
will be distributed to DN 7101 when the call is established:
EventUserEvent
AttributeExtensions
'LCTParty0' '7001'
'LCTParty0_location' 'Home'
'LCTParty1' '21001'
'LCTParty1_location' 'Home'
'LCTPartiesLength' 2
AttributeThisDN '7101'
Origination Party Generation Rules
The following rules apply to the generation of origination party information:
•
In calls made through a Routing Point, the Origination party for the
TRouteCall
destination will be the party that originated the call to the
Routing Point.
•
In single-step transfer (SST) scenarios, the Origination party for the transfer destination will be the party that originated the call to the transferrer. If the Origination DN of the transferrer has already been released from the call, then any other party except the transferrer will be added as
OriginationDN
.
•
In supervision scenarios, the supervisor desktop will have the same origination DN as distributed for the monitored agent. In addition, if the monitored agent initiates a call, the origination DN for the supervisor will be the party present in the call instead of the monitored agent.
352 Framework 8.1
Chapter 5: SIP Server Feature Support Providing Origination DN Name and Location in EventRinging
shows the origination information (DN and location) distributed in single-site and multi-site scenarios based on the following information:
•
Home and East sites are connected through ISCC.
•
Home site has the following configuration:
Extensions: DN 7101, DN 7102, DN 7103
Routing Point: DN 5000
•
East site has the following configuration:
Extension: DN 7901
Table 82: Example: Origination DN and Location in EventRinging
Scenarios
7101 makes a call to 7102
1. 1. 7101 makes a call to
5000
2. The call is routed to 7102
1. 7101 makes a call to 7102
2. 7102 issues a single-step transfer to 7103
7103
1. 7101 makes a call to 7102
2. 7102 issues a single-step conference to 7103
7103
1. 7103 monitors 7102
2. 7101 makes a call to 7102
3. Call supervision starts
7103
AttributeThisDN OriginationDN OriginationDN
_location
7102
EventRinging Attributes and Extensions
7101 Home
OriginationDN_ location
7101
7102 7101 Home 7101
7101
7102
7101
Home
Home
Home
7101
Not available
7101
1. 7101 makes a call to 5000
2. The call is routed to 7901 with CPNDigits=100100
7901
1. 7101 makes a call to 7102
2. 7102 issues a single-step conference to 5000
3. The call is routed to 7901
7901
7101
7102
Home
Home
100100 confXXX/msml
XXX
SIP Server—Deployment Guide 353
Chapter 5: SIP Server Feature Support Quality of Service
Feature Configuration
Enable the Call Participant Info functionality by setting the
configuration option to true
in the
TServer
section of the SIP Server
Application.
Quality of Service
SIP Server can set quality-of-service (QoS) bits to a user-defined value to
prioritize SIP signaling traffic. Use the option sip-ip-tos
application to define the Type of Service (TOS) byte that SIP Server includes in the IP header of the SIP messages that it sends. Note that by configuring this option, you are not enabling QoS per se; instead, you are defining the packets so that the network engineer can then enable QoS.
On most operating systems, applications that are running on behalf of nonprivileged user accounts are not permitted to set a non-zero TOS value, so you might have to perform additional actions to enable this functionality. In particular:
•
On Linux, the application must have
CAP_NET_ADMIN
capability (that is, run from the root account).
•
On Windows Server 2003, the following registry setting must be set (see also http://support.microsoft.com/kb/248611
):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\
Parameters\DisableUserTOSSetting = (DWORD) 0
•
On Windows Server 2008, set the IP DiffServ bits on outgoing packets by defining the QoS Policy in the QoS Packet Scheduler, which is included in the operating system. For instructions about how to define the IP DiffServ bits on outgoing packets per executable or per port, see the Creating and
Editing a QoS Policy document at the Microsoft website.
•
On Windows Server 2012, create and configure a QoS policy as described in the Configuring Policy-based Quality of Service (QoS) document at the
Microsoft website
Note:
When using this method on Windows, install Microsoft Hotfix referenced in MS14-031: Description of the security update for TCP for Windows (https://support.microsoft.com/en-us/kb/2957189):
• For Windows Server 2008 R2 SP1: http://www.microsoft.com/en-us/download/details.aspx?id=43143
• For Windows Server 2012: http://www.microsoft.com/en-us/download/details.aspx?id=43146
• For Windows Server 2012 R2: http://www.microsoft.com/en-us/download/details.aspx?id=43140
Refer to operating system documentation for additional information.
354 Framework 8.1
Chapter 5: SIP Server Feature Support Remote Agents
Remote Agents
SIP Server supports remote agents that use legacy PSTN phones. These agents could be working from their homes, or in a branch office that has simple PSTN connectivity.
SIP Server supports the following functionality for remote agents:
•
Nailed-up connections (see
)
•
Multi-site supervision (see
)
Feature Configuration
describes how to configure remote agents.
Table 83: Configuring Remote Agents
Objective
Configure the agent DN.
Related Procedures and Actions
In the
ACD Position or
Extension
DN for the agent, configure the following options:
•
—Set this option to false
.
•
—Set this to false
.
•
true
(recommended, not mandatory).
•
—Ensure that this option is not configured.
For general info about creating agent DNs, go to:
•
Procedure: Configuring endpoints, on page 79 .
See also network considerations for “Remote Agent Configuration” on page 56
.
Feature Limitations
Due to the specifics of gateway behavior in performing SIP
REFER
methods, support for remote agents has some limitations. In order to use remote agents, you must perform one of the two following steps:
•
Provision customers and remote agents to use physically separate gateways
(otherwise, calls from agents to customers take shortcuts within gateways, which means that SIP Server loses track of the call and therefore cannot perform call control). Even in this configuration, direct calls between two remote agents on the same gateway are not visible to SIP Server.
Or,
•
Disable the SIP
REFER
method for the gateways where the remote agents are located. This enables SIP Server to see agent-to-customer and agent-toagent calls.
SIP Server—Deployment Guide 355
Chapter 5: SIP Server Feature Support Remote Media on Genesys SIP Endpoint SDK 8.0
Remote Media on Genesys SIP Endpoint
SDK 8.0
SIP Server supports remote 3pcc control of beep tones and DTMF tones generation using proprietary SIP extensions on custom endpoints built from the Genesys SIP Endpoint SDK 8.0:
•
Beep Tones Control—If the DN is configured for it, SIP Server can initiate the playing of a specified audio file on the SIP endpoint for an active call, including during call recording. SIP Server uses
NOTIFY
messages with proprietary extensions to request the beep.
•
DTMF Tones Control—If the DN is configured for it, SIP Server can initiate the generation of DTMF tones on the customer SIP endpoint. SIP
Server uses
NOTIFY
message with proprietary extensions that provide the digits to be played by the endpoint.
Feature Configuration
describes how to enable this feature.
Table 84: Enabling Remote Media Control on SIP Server
Objective
1. Configure the DN.
2. Configure the SIP endpoint.
Key Procedures and Actions
In the SIP Server switch >
DNs
folder > SIP endpoint
DN >
Annex
tab >
TServer
section, configure the following option:
•
—Set this option to either, or both, of the supported values for this endpoint: beep, dtmf
.
Note: Use a comma-separated list if enabling both values.
Both remote media features, Beep Tones Control and
DTMF Tones Control, require customer configuration of the endpoint itself.
For more information setting up a custom endpoint using the Genesys SIP Endpoint SDK 8.x, consult the
SIP Endpoint SDK 8.x API Reference.
356 Framework 8.1
Chapter 5: SIP Server Feature Support Remote Server Registration
Remote Server Registration
SIP Server supports registering with a remote server under a specified account.
The remote server registration is enabled on a per-
Trunk
DN basis. SIP Server registers
Trunk
DNs at a remote server when the force-register
option is configured.
SIP Server also uses the values of the following options when registering with a remote server:
•
contact
, when determining where to send the
REGISTER
request.
•
password
, when the
REGISTER
request is challenged.
See “Configuring endpoints” on page 79 for more information about these
options.
Remote Talk
The Remote Talk feature enables the answering of an incoming call remotely by a T-Library client, by sending the
TAnswerCall
request to SIP Server. For
this feature to work, the sip-cti-control
talk.
The SIP endpoint must support the BroadSoft Application Server interface to use the Remote Talk feature for remote call control.
Sending Outgoing INVITEs with Multipart
Body
Introduced in
SIP Server
8.1.101.83
SIP Server now supports passing geo-location information formed by the routing strategy in the multi-part body of the outgoing
INVITE
message. The new functionality is triggered from the routing strategy by adding two keyvalue pairs to the
AttributeExtensions
:
SIP_MIME_HEADERS
and
Geolocation
:
•
The
SIP_MIME_HEADERS
extension key consists of the following parameters
separated by a colon (see “Mapping Examples” on page 358 ):
The name of the extension key containing an actual payload to be included in the outgoing
INVITE
body. The current supported extension key for this feature is
Geolocation
.
The content type for this payload, one of the IANA-registered MIME types. The current supported content type for this feature is application/pidf+xml
.
•
The value of the
Geolocation
extension key will be included as the body of the outgoing multipart
INVITE
message. No format check, no re-encoding and no other modifications to payload are made by SIP Server; the payload is included in the
INVITE
body as is.
SIP Server—Deployment Guide 357
Chapter 5: SIP Server Feature Support Sending Outgoing INVITEs with Multipart Body
SIP Server generates an outgoing
INVITE
message using the information provided in the two extensions described above, as specified by RFC 6442.
The feature can be triggered on any calls routed to the external number.
Mapping Examples
Example of TRouteCall
RequestRouteCall
AttributeThisDN '5002'
AttributeConnID 22660268d90ab001
AttributeOtherDN '22002'
AttributeRouteType 1 (RouteTypeDefault)
AttributeReferenceID 10
AttributeExtensions
‘SIP_MIME_HEADERS’ ‘Geolocation:application/pidf+xml’
‘Geolocation’ ‘<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gml="http://www.opengis.net/gml" entity="pres:[email protected]">
<tuple id="22c0e6a14348456597c8f02b5915a29b">
<status>
<gp:geopriv>
<gp:location-info>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326" xmlns:gml="http://www.opengis.net/gml">
<gml:pos>43.6198128 -70.2696997</gml:pos>
</gml:Point>
</gp:location-info>
</gp:geopriv>
</status>
<timestamp>2015-07-
16T13:07:06Z</timestamp>
</tuple>
</presence>’
Example of the corresponding outgoing INVITE
INVITE sip:[email protected]:63081 SIP/2.0
From: <sip:msml=5593f1ad00000001@UTE_HOME:11001>;tag=CE972381-9AD5-
46EA-B8E9-43E45959890D-13
To: <sip:5002@UTE_HOME:11001>
Call-ID: 6FE4A45E-37B2-468B-B618-8A9D41F5B751-8@UTE_HOME
CSeq: 1 INVITE
Via: SIP/2.0/UDP UTE_HOME:11001;branch=z9hG4bKD0725BBB-9A0A-4A89-
981C-163DBD1F47A9-16
358 Framework 8.1
Chapter 5: SIP Server Feature Support Sending Outgoing INVITEs with Multipart Body
Contact: <sip:SVC_Mediaserver@UTE_HOME:11001>
X-Genesys-CallInfo: routed
Allow: ACK, BYE, CANCEL, INFO, INVITE, MESSAGE, NOTIFY, OPTIONS,
PRACK, REFER, UPDATE
Max-Forwards: 69
X-Genesys-CallUUID: UQS8MJGDDD0KD8IKDCUQC17F20000001
Session-Expires: 1800;refresher=uac
Min-SE: 90
Supported: geolocation,timer
Geolocation: cid:1430852104988
Content-Type: multipart/mixed; boundary=845F3842_73B5_48B3_AC8A_15B65DA517FA
Content-Length: 947
--845F3842_73B5_48B3_AC8A_15B65DA517FA
Content-Type: application/sdp v=0 o=PhoneSimulator 1 1 IN IP4 192.168.73.29
s=incoming INVITE c=IN IP4 192.168.73.29
t=0 0 m=audio 63209 RTP/AVP 0 a=rtpmap:0 PCMU/8000/1
--845F3842_73B5_48B3_AC8A_15B65DA517FA
Content-Type: application/pidf+xml
Content-ID: 1430852104988
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gml="http://www.opengis.net/gml" entity="pres:[email protected]">
<tuple id="22c0e6a14348456597c8f02b5915a29b">
<status>
<gp:geopriv>
<gp:location-info>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326" xmlns:gml="http://www.opengis.net/gml">
<gml:pos>43.6198128 -70.2696997</gml:pos>
</gml:Point>
</gp:location-info>
</gp:geopriv>
</status>
<timestamp>2015-07-16T13:07:06Z</timestamp>
</tuple>
</presence>
--845F3842_73B5_48B3_AC8A_15B65DA517FA--
SIP Server—Deployment Guide 359
Chapter 5: SIP Server Feature Support SIP Authentication
SIP Authentication
SIP Server supports SIP authentication for both incoming and outgoing calls in networks that require mutual authentication. If configured for mutual authentication, SIP Server can both challenge incoming
INVITE
requests and respond to challenges received from the switch for outbound
INVITE
request that SIP Server sends.
SIP Server also supports the authentication procedure for outgoing
REFER requests in case of
401 Unauthorized
or
407 Proxy Authentication Required responses that contain the
Authenticate
response header.
How It Works
SIP Server uses the HTTP Digest authentication method, in which
401
Unauthorized
or
407 Proxy Authentication
challenges are sent in response to
INVITE
and
REFER
requests where authorization is required.
Inbound Calls
For inbound calls, SIP Server issues these challenges when an
INVITE
is sent to a DN that is configured to demand authentication. If the response to this challenge includes the required authorization parameters, SIP Server can accept the follow-up
INVITE
.
Outbound Calls
For outbound calls, SIP Server receives the challenge from the switch. If authentication is configured on the outbound Trunk, SIP Server can respond to this challenge by sending a new
INVITE
that includes the required authorization parameters.
For example, if the following outbound
INVITE
INVITE
From: A(1001)
To: B(2002) results in the challenge
407 Proxy Authentication
SIP Server, if the outbound Trunk is configured for it, will resend the
INVITE with additional parameters:
INVITE
From: A(1001)
To: B(2002); Proxy-Authorization: <Authorization Parameters>
If the parameters are correct, the new
INVITE
will be accepted by the switch.
360 Framework 8.1
Chapter 5: SIP Server Feature Support SIP Proxy Support
Feature Configuration
describes how to enable this feature.
Table 85: Enabling SIP Authentication
Objective
1. Configure the inbound endpoint.
2. Configure the Trunk.
Key Procedures and Actions
In the endpoint DN, in the
TServer
section, configure the following options:
•
—Set this option to the value
INVITE
.
Incoming
INVITE
requests to this DN will result in an authentication challenge.
•
—Enter the password for realm authentication. The
INVITE
sent in response to the challenge must include this password, otherwise the call will not be authorized.
In the
Trunk
DN, in the
AuthClient
section, configure the following options:
•
—Enter a username to be used in the response to the
Digest challenge.
•
—Enter the password to be used in generating the response.
SIP Proxy Support
Genesys SIP Proxy provides an alternative high-availability option without requiring a virtual IP address. In addition, it provides an interface for SIP communication between SIP devices and SIP Server components.
In a standalone deployment, each SIP Proxy serves one SIP Server HA pair per site. See the
SIP Proxy 8.1 Deployment Guide
for details.
Feature Configuration
describes the required configuration for SIP Server to operate with
SIP Proxy.
SIP Server—Deployment Guide 361
Chapter 5: SIP Server Feature Support SIP Proxy Support
Table 86: Integration with SIP Proxy
Objective Key Actions and Procedures
1. Configure the SIP
Proxy Application.
In the SIP Proxy
Application
object >
Server Info
, set the following options:
•
Host
—Specify the host on which this SIP Proxy is installed.
•
Port IDs
—Specify the following SIP Proxy ports:
sip-port,
Connection Protocol: sip http-port,
Connection Protocol: http
(Optional)
On the
Options tab, create a section named sipproxy.
In the sipproxy section, add the following options:
• applications
—For a multi-site environment with SIP Proxy support, specify the application names of all primary SIP Servers in the environment, separated by a comma.
• serving-sipserver
—Specify the application name of the primary SIP
Server to which all requests from endpoints and media gateways will be forwarded.
• sipproxy-role
—Set this option to
10
.
On the
Tenants
tab, add the tenants as necessary.
2. Configure primary and backup SIP
Server Applications.
In the SIP Server
Application
object >
Options
>
TServer
section, configure the following options:
•
—Set this option to the IP address of the SIP Server interface.
•
—Set this option to true.
•
—Set this option to true
.
•
—Ensure this option is set to true.
3. Create a
Voice over
IP Servic e DN for each switch involved in a standalone environment.
Create a
Voice over IP Servic e DN named, for example, sip-outboundproxy.
In the
Options/Annex > TServer
section, configure the following options:
• service-type
—Set this option to sip-outbound-proxy
.
• contact
—Set this option to the SIP Proxy DNS-SRV name.
• external-contact
—Set this option to the SIP Proxy address using the host:port
format.
• oos-check
—Specify how often, in seconds, SIP Server checks SIP Proxy for out-of-service status.
• oos-force
—Specify the time interval, in seconds, that SIP Server waits before placing an unresponsive SIP Proxy in out-of-service state when the oos-check
option is enabled.
Note: The Active Out-of-Service Detection feature ( oos-check
and oos-force options) must be enabled on a VoIP Service DN with service-type=sipoutbound-proxy
for SIP Proxy support. See “Active Out-of-Service
Detection” on page 254 for details.
362 Framework 8.1
Chapter 5: SIP Server Feature Support SIP Traffic Monitoring
SIP Traffic Monitoring
SIP Server actively monitors the level of SIP traffic that it receives, to initiate a switchover to the backup SIP Server if no messages are received after a configurable length of time.
How it Works
1. SIP Server sends
OPTIONS
messages to SIP devices as part of the Active
Out-of-Service Detection (Active OOS) feature (see “Endpoint Service
).
2. SIP Server actively monitors the length of time since it last received a SIP message—including the responses to the Active OOS
OPTIONS
messages.
3. If the length of time between SIP messages surpasses the maximum length configured out of all of the actively monitored DNs, then SIP Server reports
SERVICE_UNVAVAILABLE
to the Local Control Agent (LCA).
Note:
SIP Server initiates the switchover if no SIP messages are received during a period of time calculated based on oos-check and oos-force
values of all DNs configured for Active Out-of-
Service Detection.
4. The Solution Control Server (SCS) initiates the switchover from primary to backup SIP Server instance—the backup becomes primary and starts monitoring SIP traffic.
Feature Configuration
describes the required configuration for SIP traffic monitoring.
SIP Server—Deployment Guide 363
Chapter 5: SIP Server Feature Support SIP Traffic Monitoring
Table 87: Configuring SIP Traffic Monitoring
Objective
Enable Active Out-of-
Service Detection.
Enable SIP traffic monitoring.
Key Actions and Procedures
You must configure at least one
Voice over IP Service
device for Active OOS
Detection.
In the
Voice over IP Service
DN, in the TServer section, configure the following options:
•
—Enter (in seconds) how often you want SIP Server to send
OPTIONS
messages to this device.
•
—Enter (in seconds) how long you want the device to be placed in
out-of-service.
Active Out-of-Service Detection must be enabled for one or more DNs. When
SIP traffic monitoring is enabled, the primary SIP Server reports the
SERVICE_UNAVAILABLE
status to LCA/SCS when all devices configured with the
Active OOS check have failed and no other SIP messages have been received for a period of time calculated based on the oos-check
and oos-force
values of all DNs configured for Active Out-of-Service Detection.
For details, see “Endpoint Service Monitoring” on page 253
.
In the
TServer
section of the SIP Server
Application
object, configure the following option:
•
true
.
Feature Limitations
•
Monitoring of received messages can result in false-positive alarms triggering a switchover from primary to backup SIP Server instances in cases of a global outage or planned maintenance will cause all SIP messages to stop. To avoid unnecessary switchovers, Genesys recommends distributing the monitored DNs throughout the network.
•
When updating or installing SIP Server, Genesys recommends you not enable the sip-pass-check
option, as any oos-monitored DNs would be unavailable or non-operational during this period.
364 Framework 8.1
Chapter 5: SIP Server Feature Support Shared Call Appearance
Shared Call Appearance
Introduced in
SIP Server
8.1.101.57
Support for BC deployments added
SIP Server supports Shared Call Appearance (SCA) that enables a group of
SIP phones to receive inbound calls directed to a single destination (shared line); that way, any phone from this group can answer the call, barge-in to the active call, or retrieve the call placed on hold.
Starting with version 8.1.101.75, SCA is supported in Business Continuity deployments. See the SIP Server 8.1 High-Availability Deployment Guide for details.
How It Works
The shared line has sub-lines called appearances. Each shared line has one or more appearances; each appearance can handle one call a time. The current status of each call (appearance) is displayed on each phone in the SCA group that includes outbound calls made from any phone in this group, which appear as they are placed from the same origination device.
There are several standards which enable implementation of SCA within the
SIP protocol. Genesys SIP Server implemented the BroadWorks SCA standard that supports barge-in and is supported by leading phone manufacturers. Refer to your SIP phone documentation for information about SCA standards supported by your phone.
These are common scenarios where SCA can be used:
•
Executive/Assistant—The call appearances on the executive's phone also appear on the assistant's phone. The assistant may answer incoming calls to the executive and then place the call on hold for the executive to pick up.
The assistant can always see the state of all calls on the executive's device.
•
Key System Emulation—Multiple lines are shared across two or more phones. A call answered on one phone can be put on hold and picked up on another phone. Another phone can be added/joined/bridged to an existing appearance resulting in a conference call.
•
Single Line Extension—Several phones are formed in to a group to which incoming calls arrive. When one device answers, the other phone are informed. If another phone in the group goes off hook, it is immediately bridged or joined in with the call.
•
Changing devices—A user is on a call on one phone and wishes to change phones and continue the call on another phone. The user places the call on hold, notes the appearance number of the call, then walks to another phone.
Users are able to identify the same appearance number on the other phone, pick up the call, and continue the conversation.
Note:
This feature may also be referred to as Bridged Line Appearance
(BLA) or Shared Line Appearance (SLA).
SIP Server—Deployment Guide 365
Chapter 5: SIP Server Feature Support Shared Call Appearance
Shared Call Appearances are configured using two types of DNs:
•
Primary shared line DN—The Address of Record (AoR), such as 7000 in the example above.
•
Secondary DN—Other DN associated with the Primary shared line DN.
User Experience
•
Incoming calls to a Shared Call Appearance ring on all the associated phones.
•
The status of every call is shown on all phones associated with the Shared
Call Appearance.
•
Calls are always associated with a “line appearance”. Incoming calls will be assigned the lowest numbered idle line appearance. All phones associated with the Shared Call Appearance should have the same number of “line appearances” configured, typically with each line appearance having a dedicated “line key” button.
•
A user may seize (go off hook) a particular line appearance if it is idle by pressing the corresponding line key button. For example, pressing the second line key will seize (go off hook) the second line appearance when it is idle.
•
Held calls may be retrieved by any phone associated with the Shared Call
Appearance.
•
An active call on a phone associated with the Shared Call Appearance may be joined at any time by another phone associated with the Shared Call
Appearance. This is sometimes referred to as a “barge-in.” The parties are then conferenced together.
•
Each phone associated with the Shared Call Appearance might have only one active call at a time, and other calls will be held.
•
Outgoing calls from any line appearance of the Shared Call Appearance will present an outgoing caller ID with the identity of the Shared Call
Appearance. (A phone could have other lines not associated with the SCA, and these are not impacted, they would present a different caller ID).
Note:
According to the BroadWorks SCA standard, one DN cannot be a member of multiple shared lines. If, for example, an executive assistant needs to share lines with two executives, two independent shared lines must be configured on the assistant's phone. All of them are displayed at the screen and operable.
366 Framework 8.1
Chapter 5: SIP Server Feature Support Shared Call Appearance
Sample Call Flow
A sample call flow for a Shared Call Appearance scenario is as follows:
1. Two phones are configured with a Shared Call Appearance of 7000 and all are idle. In this example, they are referred to as Phone A and B, and both are configured to show two line appearances.
2. An incoming call to 7000 rings on both phones using the first line appearance.
3. A user at Phone A answers the call. Phone B reflects the call is active on another phone on the first line appearance.
4. A second incoming call to 7000 rings on both phones on the second line appearance
5. The user at Phone A places the first call on hold. Phone B reflects the initial call is held on the first line appearance.
6. The user at Phone A answers the second call. Phone B reflects the second call is active on another phone on the second line appearance
7. The user at Phone B retrieves the held call from the first line appearance.
Phone A reflects the call is now active on another phone on the first line appearance.
SCA and Other Feature Interaction
•
Call Recording can be set for a particular shared line DN, Primary and/or
Secondary DN.
•
Call Monitoring can be set for a particular shared line DN, Primary and/or
Secondary DN. However, neither Primary nor Secondary DN can monitor other DNs. If, during monitoring, a call placed on hold is retrieved by another shared line DN, the monitoring will be dropped.
•
Greetings can be set for a particular shared line DN, Primary and/or
Secondary DN.
•
Greetings and Barge-In—A shared line user can barge-in to an established call with two parties while a greeting is in progress, after which all three parties will be connected.
•
Hunt Groups—A shared line DN cannot be a member of a Hunt Group.
•
Routing—Only routing to a Primary shared line DN is supported (and all phones will ring). Routing to a Secondary DN directly is not supported. A shared line DN can make a call to a Routing Point using one of the shared line appearances—the same way as for any call.
•
Call Pickup—An inbound SCA call cannot be picked up by a DN rather than a shared line DN. However, if an inbound call is ringing on a regular non-shared line DN, it can be picked up by a shared line DN.
SIP Server—Deployment Guide 367
Chapter 5: SIP Server Feature Support Shared Call Appearance
•
Call Park/Retrieve—Shared line users can park a call, and the call can be retrieved from any phone (shared line or regular phones) using the Primary shared line number. There can be only one parked call per shared line at a time. Shared line users can retrieve calls that were parked by regular phones.
•
Dial Plan—For inbound calls, SIP Server applies dial plans only to resolve call destinations; that is, only digit translation of the selected rule is performed, no additional parameters of the selected rule ( timeout, ontimeout, onbusy,
and so on) is applied. If a destination is the Primary shared line DN, a call delivered to the SCA number is treated as a regular
SCA call, i.e. is ringing on Primary and Secondary DNs. No more dial plan rules are applied after that. For outbound calls, shared line DNs dial plans are applied—for example, if a Secondary DN makes an outbound call, the dial plan configured for that Secondary DN is applied.
SCA Messaging
SCA related data is transported using the Call-Info and Line-Seize Event
Packages. They are used in shared line call-related messages (
INVITE, 180
Ringing, SUBSCRIBE,
and so on).
SIP Server reports T-Library events separately for each Primary and each
Secondary DN. No events are generated for a shared line itself.
Feature Configuration
describes how to configure Shared Call Appearance. (See also “How
Configuration Changes Take Effect” on page 369
.)
Table 88: Configuring Shared Call Appearance
Objective
Configure a Primary shared line
DN.
Key Actions and Procedures
In the DN object:
1. Create a DN of type
Extension
with the number where all incoming calls will be delivered.
2. In the
Annex
->
TServer
section, set the following options:
—Set this option to true
.
—(Optional) Set this option to specify a number of shared line appearances, which limits the maximum number of simultaneous calls per shared line.
—Set this option to register for
enabling an authentication procedure on DN registration.
—Set this option to a valid password to be used for authentication of the Primary shared line DN.
368 Framework 8.1
Chapter 5: SIP Server Feature Support Shared Call Appearance
Table 88: Configuring Shared Call Appearance (Continued)
Objective
Configure a Secondary shared line DN.
Key Actions and Procedures
In the DN object:
1. Create a DN of type
Extension
with the number to be used as a
Secondary DN.
In the
Annex
->
TServer
section, set the
option to the value of the Primary DN.
2. On the SIP phone that supports SCA specify the following properties (the exact property names vary):
DN number—Must be set to the same value as the DN number in the DN object for a Secondary DN.
Line type—Must be set to Shared Line, BroadSoft SCA, or equivalent.
Authentication username—Must be set to the same value as the
Primary DN.
Authentication password—Must be set to the same value as the password option configured for the Primary DN.
3. Repeat the above steps for each Secondary DN to be used as a shared line user.
How Configuration Changes Take Effect
If a regular DN (neither Primary nor Secondary shared line DN) is changed to be a Primary or Secondary DN in the Genesys configuration, SIP Server does the following:
•
Continues processing DN’s existing calls as non-shared line DN calls.
•
Delivers and processes new inbound calls as SCA calls. Outbound calls from this DN can be barged-in or retrieved by other shared line users.
•
Does not send NOTIFY messages with appearance statuses to this DN until it subscribes to SCA statuses. To force the DN to subscribe, it must be reconfigured as a BroadWorks SCA DN. Until then, it is not able to bargein or retrieve calls served by other shared line users.
If a Primary or Secondary DN is changed to be a non-shared line DN, SIP
Server does the following:
•
Continues processing of existing calls for this DN.
•
Processes new inbound/outbound calls as non-shared line calls.
Stops sending NOTIFY messages with appearances statuses to this DNs.
SIP Server—Deployment Guide 369
Chapter 5: SIP Server Feature Support Shared Call Appearance
Configuration Example
In the configuration example, the Primary shared line DN is 7000. The
Secondary DNs are 7001 and 7002.
Figure 38: Shared Call Appearance Configuration Example
Feature Limitations
•
Only 1pcc operations are supported.
•
One DN cannot be a member of multiple shared lines.
•
Calls to Secondary DNs are not supported. Customers may chose to disable calls to Secondary DN numbers through a dial plan.
•
Private Hold SCA Broadsoft functionality is not supported.
•
Agent login to SCA DNs (Primary or Secondary) is not supported.
•
Multi-site scenarios with the direct-notoken
ISCC transaction type to a shared line destination DN is not supported. (No
EventRinging
reporting if the call is answered by a Secondary DN.)
•
TRouteCall
to a Secondary DN is not supported. See “SCA and Other
Feature Interaction” on page 367
.
370 Framework 8.1
Chapter 5: SIP Server Feature Support Smart OtherDN Handling
•
ICON version 8.1.400.08 or earlier might not report redirect scenarios for
SCA calls correctly.
•
In inbound call scenarios, no 3pcc requests can be processed before a call is answered by a shared line user.
•
SCA DNs (Primary or Secondary) cannot be located behind the softswitch.
•
Semi-attended transfers and Mute transfers to the shared line are not supported.
Smart OtherDN Handling
For T-Library clients that provide the Agent ID value as the
OtherDN
in requests to SIP Server, SIP Server can convert this
OtherDN
value using its knowledge of the association between the Agent ID and the DN to ensure the correct execution of the request by the switch.
Supported Requests
shows the requests that assume the use of the
OtherDN value as a switch directory number, and can therefore support Smart OtherDN Handling.
Table 89: Requests That Support Smart OtherDN Handling
TRequest
TMakeCall
TMakePredictiveCall a
TRedirectCall
TInitiateTransfer
TSingleStepTransfer
TInitiateConference
TSingleStepConference
TDeleteFromConference
TCallSetForward b
TGetAccessNumber c
TSetCallAttributes c
TMonitorNextCall
Meaning of OtherDN Attribute
Call destination
Call destination
New destination for a call
Call destination
New destination for a call
New destination for a call
New destination for a call
Conference member to be deleted
Request target
DN for which Access Number is requested
Not specified
Agent DN to be monitored
AgentID-to-DN
Conversion
Yes
No
Yes
Yes
Yes
No
No
Yes
Yes
Yes
Yes
Yes
SIP Server—Deployment Guide 371
Chapter 5: SIP Server Feature Support Smart OtherDN Handling
Table 89: Requests That Support Smart OtherDN Handling (Continued)
TRequest
TCancelMonitoring
TRouteCall d
• RouteTypeUnknown
• RouteTypeDefault
• RouteTypeOverwriteDNIS
• RouteTypeAgentID
Meaning of OtherDN Attribute
Agent DN that was monitored
New destination for a call
AgentID-to-DN
Conversion
Yes
Yes
Yes
No
No a.
TMakePredictiveCall assumes the directory number should be outside the switch; however, this request could also support Smart OtherDN Handling.
b.
TCallSetForward
has a separate flag in the configuration option for enabling conversion.
c. T-Server cannot intercept these requests.
d. Only the listed route types are applicable for OtherDN conversion.
Feature Configuration
describes how to configure Smart OtherDN Handling for SIP Server.
Table 90: Configuring Smart OtherDN Handling
Objective
Enable for all applicable calls.
Enable on a call-by-call basis.
Key Actions and Procedures
In the SIP Server
Application
object, go to the
Options
tab and configure the following:
•
—See the option description for a list of valid
values.
can be used to enable this feature on a call-by-call basis.
Configure the routing strategy T-Library client to include the
key in the
Extensions
attribute of the T-Library request to SIP Server. Set the value of this key to one of the following:
•
0
—disables all conversions for the call.
•
1
—forces the relevant conversion for the call.
372 Framework 8.1
Chapter 5: SIP Server Feature Support SRV Address Support in Contact and Record-Route Headers
Feature Limitation
In a multi-site environment, the Smart OtherDN Handling feature is not supported if you use Workspace Desktop and the LCTParty interface is activated in SIP Server.
SRV Address Support in Contact and
Record-Route Headers
Introduced in
SIP Server
8.1.102.50
SIP Server supports the SRV FQDN—FQDN resolving to SRV records—received in the
Contact
or
Record-Route
headers of a SIP message.
SIP Server also supports the SRV FQDN in the contact
option on a Trunk DN.
If the target destination received in the URI of the
Contact
or
Record-Route headers of a
200 OK message is not a numeric IP address, and no port is present, SIP Server performs an SRV query to obtain the target's IP address:port.
The
OPTIONS
messages are sent over all transports representing
SRV records. The
ACK
messages and all further SIP requests are sent to the active transport with the highest priority. SIP Server uses the original transport if it is among the active transports with the highest priority. If no active SRV records are found, the SIP transaction fails.
If the target destination received in the URI of the
Contact
header of an
INVITE message is not a numeric IP address, and no port is present, SIP Server performs an SRV query to obtain the target's IP address:port
. The
OPTIONS messages are sent over all transports representing SRV records. Further SIP requests are sent to the active transport with the highest priority. SIP Server uses the original transport if it is among the active transports with the highest priority. If no active SRV records are found, SIP Server uses the transport of the original
INVITE
message for further SIP requests.
When SIP Server is deployed with SIP Proxy (the Application-level option sip-outbound-proxy
is set to true
) and it must send a SIP request to a destination configured with the SRV FQDN or list of active transports, SIP
Server selects an active target destination and adds the private
X-Genesys-Route header with a value of sip:IpAddress:Port[;transport=tcp/tls]
. SIP Proxy uses the value of the
X-Genesys-Route
header as the next destination for forwarding the request. For SIP Proxy, this header has priority over the target specified in
Request-URI or
Route
headers. SIP Server uses the same transport value for the
X-Genesys-Route
header until a transport becomes out of service.
Feature Configuration
describes how to configure SIP Server to perform an SRV query:
SIP Server—Deployment Guide 373
Chapter 5: SIP Server Feature Support Transport Layer Security for SIP Traffic
Table 91: Configuring SIP Server to perform an SRV Query
Objective
Configuring SIP Server to perform an SRV query.
Key Actions and Procedures
In the SIP Server
Application
object, go to the
Options
tab and configure the following:
true
.
true
.
• If SIP Proxy is used, set
to true
.
In a multisite SRV/DNS-based configuration:
to the hostname of the SIP Server interface.
to any valid port.
• Set the
option to the SRV FQDN on inter-site Trunk DNs.
Feature Limitations
SIP Server does not support the SRV FQDN in
REGISTER
messages.
Transport Layer Security for SIP Traffic
SIP Server supports secure communication for both the SIP traffic as well as the T-Library communication that it engages in. SIP Server uses the Transport
Layer Security (TLS) protocol to secure both modes of communication—configured separately in the
TServer
section for SIP messaging, and in the common configuration options for T-Library communication.
Note:
This guide presents information for configuring TLS for SIP messaging only. For details about how to configure the common TLS options for T-Library communication, see the Genesys Security
Deployment Guide.
About TLS
SIP Server supports the standard TLS protocol which offers confidentiality, integrity protection, and data compression to client/server applications. For a detailed description of how this protocol works, as well as how security works generally, refer to the relevant RFCs:
•
“RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2”
374 Framework 8.1
Chapter 5: SIP Server Feature Support Transport Layer Security for SIP Traffic
•
“RFC 4568: Session Description Protocol (SDP) Security Descriptions for
Media Streams”
•
“RFC 3711: The Secure Real-time Transport Protocol (SRTP)”
Feature Configuration
describes how to configure TLS for the SIP messaging that SIP
Server engages in.
Table 92: Configuring TLS
Objective Key Actions and Procedures
Prepare server and clients.
Use the Microsoft Management Console (MCC) tool to generate and install server certificates.
For details, see the Genesys Security Deployment Guide.
Prepare Solaris, Linux, or AIX server and clients.
For Solaris, Linux, or AIX, use the Genesys Security Pack to generate certificates.
For details, see the Genesys Security Deployment Guide.
SIP Server—Deployment Guide 375
Chapter 5: SIP Server Feature Support Transport Layer Security for SIP Traffic
Table 92: Configuring TLS (Continued)
Objective
Configure the SIP Server
Application.
Key Actions and Procedures
In the
TServer
section of the SIP Server
Application
object, configure the following TLS-related options:
•
—Set this to the SIP port on which SIP Server listens for incoming requests using TLS encryption.
Note: If you configure ONLY this parameter, SIP Server will use the default host certificate, if one is available. In this case, SIP Server will take the default values for sip-tls-cert
, sip-tls-cert-key
, and siptls-trusted-c a from the
Host
object.
•
—For Windows, set this to the thumbprint obtained from the user certificate generated for the host.
For UNIX, set this option to the path and filename of the
.pem encoded file that contains the host certificate.
•
—Set this to true
for SIP Server to request the client certificate to initiate a mutual TLS connection.
•
—Set this to host
and SIP Server compares the subject field in the server‘s certificate to the target host name. If no match is found, the connection fails.
•
—Specifies the list of ciphers.
Solaris, Linux, or AIX-Only Options
In addition to the options above, Solaris, Linux, or AIX deployments also require the following configuration:
•
—For Solaris, Linux, or AIX only, set this to the
path and filename of the .
pem
encoded file that contains the host
private key.
•
—For Solaris, Linux, or AIX only, set this to the name of the file containing one or more certificates in PEM format, to define the Certificate Revocation List.
•
—For Solaris, Linux, or AIX only, set this to
the path and filename of a
.pem
encoded Certificate Authority
(CA) file, containing one or more certificates in PEM format.
376 Framework 8.1
Chapter 5: SIP Server Feature Support Tromboning Control
Table 92: Configuring TLS (Continued)
Objective
Configure the device DN.
Key Actions and Procedures
To enable TLS for SIP communication to any SIP device described in this guide, configure the destination DN that represents the device as follows:
•
contact
option with the following string: transport=tls
For example,
For an
Extension
DN, in the
TServer
section, set the contact
option to the IP address and port number of the host computer, followed by the tls string:
100.100.100.101:5060;transport=tls
Tromboning Control
In multi-site routing, where transfers from other T-Server or SIP Server instances are made through ISCC, trunk tromboning can sometimes occur. By default, SIP Server performs internal resource matching on incoming
INVITE requests, analyzing the headers to see if there are matches to any internal resources on the corresponding switch. However, there are cases where the username
in the
From
or
Contact
header of the incoming
INVITE
does match the name of an internal DN, but by coincidence. In this case, internal resource matching should be turned off for this call, to prevent SIP Server from incorrectly treating an external call as internal.
Duplicated DN Names
If two SIP Server instances at different sites have DNs with matching numbers, tromboning can occur. For example,
1. SIP Server A and SIP Server B both have an
Extension
DN with the number
9999
.
2. SIP Server A sends an
INVITE
on behalf of DN 9999 to SIP Server B.
3. SIP Server B employs internal resource matching, and mistakenly considers the call to be internal.
To control this behavior, configure the enforce-external-domains
option in
SIP Server to include the computer names or IP addresses for all SIP gateways or hosts associated with other T-Servers or SIP Servers that SIP Server may communicate with over ISCC. SIP Server checks this list of computer names or IP addresses against the computer names or IP addresses specified in the
URI of the
From
header of incoming
INVITE
. If there is a match, then the DN is considered external and the DN name is formed using the
DN.domain format.
SIP Server—Deployment Guide 377
Chapter 5: SIP Server Feature Support Tromboning Control
Typical DN Name
External DN Name
About the DN.domain format
In cases where SIP Server finds a naming match between an external and an internal DN, it forms the DN name for the external DN using the
DN.domain
format. This format clearly differentiates the two DNs for further call processing.
For example, a typical DN might appear in T-Library messaging as follows
(see bold):
AttributeOtherDN '2099'
While if the same DN is found to be external, SIP Server would form the DN name in this way:
AttributeOtherDN '2099.10.208.139.30'
SIP Server uses this
DN.domain
format in the following cases:
•
If the DN is considered external, and it matches an internal DN that is either registered or marked as in service
, SIP Server uses the
DN.domain notation for the external DN.
•
If an
INIVTE
from a particular DN contains the
X-Genesys-PartyInfo
header
(used for communication between multi-site SIP Servers) and this DN matches an internal registered or in service
DN, then SIP Server uses the
DN.domain
format to identify the external DN.
Bounced Calls Between T-Servers
Bounced calls are calls sent back and forth between SIP Server and other SIP or T-Server instances. For example,
1. SIP Server A sends a call on behalf of DN 9999 to SIP Server B.
2. The call arrives at a Routing Point on SIP Server B, which routes the call back to SIP Server A.
3. Instead of considering this a new external call, SIP Server A instead matches it to DN 9999, starting a consultation call for that DN.
When routing an internal 1pcc call, SIP Server preserves the hostname of the incoming call in the
From
header of the outgoing
INVITE
. This hostname often belongs to SIP Server itself. In this case, you cannot add SIP Server’s own address to the enforce-external-domain
option, otherwise 1pcc calls from internal DNs will also be excluded from resource matching.
To control this behavior, configure override-domain-from
Trunk
DN that points to the second SIP Server instance (for example, in the switch for SIP
Server A, configure the trunk pointing to SIP Server B with override-domainfrom
). You must then add the value of this option to the enforce-externaldomains
list.
378 Framework 8.1
Chapter 5: SIP Server Feature Support Trunk Capacity Control
Feature Configuration
Table 93 describes how to configure tromboning control.
Table 93: Configuring Tromboning Control
Objective Related Procedures and Actions
1. Configure basic anti-tromboning.
In the SIP Server
Application
object, in the
TServer
section of the
Options
tab, configure the following option:
•
list of hostnames or IP addresses for each external SIP or
T-Server from which you expect to receive ISCC transfers.
2. Configure anti-tromboning for bounced call routing.
1. In the
Trunk
DN that points to the second SIP Server instance, configure the following option:
—Enter an identifier for the originating SIP Server. For example, the name of the switch corresponding to the SIP Server object.
2. In the second SIP Server object, add the identifier you created in Step 1 to the
list.
Trunk Capacity Control
SIP Server enables control of the number of outgoing and incoming calls to be handled by a specific trunk or a group of trunks in single-site deployments. SIP
Server rejects calls when trunk capacity is reached. Only traffic to and from a single SIP Server HA pair is controlled. In Business Continuity deployments, capacity control must be configured at each site.
Capacity Control of Outgoing Calls
When capacity control is enabled on a trunk, SIP Server keeps a count of every incoming and outgoing call, including every SIP or T-Library request, that it receives. When this count equals the value specified by the
configuration option, SIP Server starts rejecting only outgoing calls, generating accompanying messages depending on the call control type, as follows:
•
1pcc calls are rejected with a SIP error code specified in the
configuration option.
•
3pcc calls are rejected with an
EventError
containing
ErrorCode
specified in the
configuration option.
SIP Server—Deployment Guide 379
Chapter 5: SIP Server Feature Support Trunk Capacity Control
Example
[TServer] capacity=100
With this setting:
•
If there are 50 incoming and 50 outgoing calls established through the trunk, SIP Server rejects an attempt to make an outgoing call through this trunk, but accepts incoming calls arriving to this trunk.
•
If total calls are less than 100, both incoming and outgoing calls are allowed.
Capacity Control on a Group of Trunks
Trunks can be defined as one capacity group by using the
configuration option. When capacity control is enabled on a group of trunks,
SIP Server keeps a count of every incoming and outgoing call, including every
SIP or T-Library request, that it receives. When this count equals the value
configuration option, SIP Server starts rejecting only
outgoing calls, generating accompanying messages depending on the call control type, as follows:
•
1pcc calls are rejected with a SIP error code specified in the
configuration option.
•
3pcc calls are rejected with an
EventError
containing
ErrorCode
specified in the
configuration option.
Example
DN of type
Trunk
with the name
Trunk1
and the following options:
[TServer] capacity=200 capacity-group=TrunkGroup1 prefix=8340
DN of type
Trunk
with the name
Trunk2
and the following options:
[TServer] capacity-group=TrunkGroup1 prefix=8341
With these settings, the number of calls to the
Trunk1
and
Trunk2
will be limited to 200. When the limit is reached, SIP Server rejects attempts to make an outgoing call through these trunks, but accepts incoming calls arriving to these trunks.
380 Framework 8.1
Chapter 5: SIP Server Feature Support Trunk Capacity Control
Capacity Control of Incoming and Outgoing Calls
To control both incoming and outgoing calls, configure the capacity-limitinbound configuration option on the same
Trunk
DN where the
option is defined. This capacity control mode is applicable only to DNs of type
Trunk
.
Example 1
[TServer] capacity=100 capacity-limit-inbound=true
With these settings:
•
If total calls are less than 100, incoming and outgoing calls are allowed.
•
When the limit is reached (for example, 60 incoming and 40 outgoing calls), incoming and outgoing calls are rejected.
Example 2
DN of type
Trunk
with the name
Trunk1
and the following options:
[TServer] capacity=200 capacity-limit-inbound=true capacity-group=TrunkGroup1 prefix=8340
DN of type
Trunk
with the name
Trunk2
and the following options:
[TServer] capacity-group=TrunkGroup1 prefix=8341
With these settings, the number of calls to
Trunk1
and
Trunk2
will be limited to
200. When the limit is reached, incoming and outgoing calls are rejected.
Feature Configuration
describes how to configure Trunk Capacity Control for SIP Server.
SIP Server—Deployment Guide 381
Chapter 5: SIP Server Feature Support Trunk Capacity Control
Table 94: Configuring Trunk Capacity Control
Objective
Configure capacity control of outgoing calls on a trunk.
Key Actions and Procedures
DN Level. On a DN (type
Trunk,
or type
Voice over IP Service with service-type=softswitch
), specify the following configuration option in the
TServer
section:
•
Application Level. Specify these options in the
TServer
section of the SIP Server Application, as required:
• (Optional)
• (Optional)
Configure capacity control of incoming and outgoing calls on a trunk.
DN Level. On a DN of type T runk,
specify the following configuration options in the
TServer
section:
•
•
Application Level. Specify these options in the
TServer
section of the SIP Server Application, as required:
• (Optional)
• (Optional)
Configure capacity control of outgoing calls on a group of trunks.
DN Level. On a DN (type
Trunk,
or type
Voice over IP Service with service-type=softswitch
) that defines capacity and a trunk group to which capacity is applied, specify the following configuration options in the
TServer
section:
•
•
For all other trunks included in the same group to which capacity is applied, specify the following configuration option in the
TServer section:
•
Application Level. Specify these options in the
TServer
section of the SIP Server Application, as required:
• (Optional)
• (Optional)
382 Framework 8.1
Chapter 5: SIP Server Feature Support Trunk Optimization for Multi-Site Transfers
Table 94: Configuring Trunk Capacity Control (Continued)
Objective Key Actions and Procedures
Configure capacity control of incoming and outgoing calls on a group of trunks.
DN Level. On a DN of type
Trunk,
specify the following configuration options in the
TServer
section:
•
•
•
For all other trunks included in the same group to which capacity is applied, specify the following configuration option in the
TServer section:
•
Application Level. Specify these options in the
TServer
section of the SIP Server Application, as required:
• (Optional)
• (Optional)
Trunk Optimization for Multi-Site Transfers
SIP Server supports trunk optimization for multi-site transfers. When the trunk optimization functionality is in use, the
OtherDN
attribute contains correct information and is reported properly in
EventPartyChanged
messages in the following scenarios:
Scenario 1
40 show the state of the call before and after the multi-site
transfer.
SIP signaling 1
SIP Server 1
SIP signaling 2
SIP Server 2
Customer
Endpoint
Gateway
SIP signaling
SIP signaling 3
SIP signaling 3
Agent B
Endpoint
Figure 39: Call Before REFER with Replaces Transfer
Agent A
Endpoint
SIP Server—Deployment Guide 383
Chapter 5: SIP Server Feature Support Trunk Optimization for Multi-Site Transfers
1. An inbound call is routed to Agent A at the SIP Server 2 site.
2. Agent A initiates a two-step transfer to Agent B at the SIP Server 1 site.
In this scenario, SIP Server uses a SIP
REFER
request with the
Replaces
header to report call data for Agent B.
SIP signaling 1
SIP Server 1
Customer
Endpoint
Gateway
SIP signaling
Customer
Endpoint
Agent B
Endpoint
Figure 40: Call After REFER with Replaces Transfer
After the transfer is completed, both the transferring agent (Agent 1) and secondary SIP Server (SIP Server 2) are released from the call.
Scenario 2
42 show the state of the call before and after the multi-site
transfer.
SIP signaling 1
SIP Server 1
SIP signaling 2
SIP Server 2
Gateway
SIP signaling
SIP signaling 3
Agent A
Endpoint
Figure 41: Call Before INVITE with Replaces Transfer
Agent B
Endpoint
1. An inbound call is routed to Agent A at the SIP Server 1 site.
2. Agent A initiates a two-step transfer to Agent B at the SIP Server 2 site.
In this scenario, SIP Server uses a SIP
INVITE
request with the
Replaces
header to report call data for Agent B.
384 Framework 8.1
Chapter 5: SIP Server Feature Support Trunk Optimization for Multi-Site Transfers
Customer
Endpoint
Gateway
SIP signaling 1
SIP Server 1
SIP signaling 2
SIP signaling
SIP Server 2
SIP signaling 3
Agent B
Endpoint
Figure 42: Call After INVITE with Replaces Transfer
In this case, the consultation call between the agents are merged on
SIP Server 1, with user data propagated to the destination SIP Server
(SIP Server 2). After the transfer is completed, SIP Server 1 remains in the signaling path—only the transferring agent (Agent A) is released from the call.
Scenario 3
44 show the state of the call before and after the multi-site
transfer.
SIP Server 1
SIP signaling 1
SIP Server 2
SIP signaling 2
SIP Server 3
SIP signaling
SIP signaling
SIP signaling
Customer
Endpoint
Gateway
Agent B
Endpoint
Figure 43: Call Before INVITE with Replaces Transfer
Agent C
Endpoint
1. From a SIP Server 1 site, a call arrives to Agent B at the SIP Server 2 site.
2. Agent A initiates a two-step transfer to Agent C at the SIP Server 3 site.
In this scenario, SIP Server uses a SIP
INVITE
request with the
Replaces
header to report call data for Agent C.
SIP Server—Deployment Guide 385
Chapter 5: SIP Server Feature Support Trunk Optimization for Multi-Site Transfers
SIP Server 1
SIP signaling
SIP Server 2
SIP Server 3
SIP signaling
SIP signaling
Customer
Endpoint
Gateway
Agent C
Endpoint
Figure 44: Call After INVITE with Replaces Transfer
After the transfer is completed, SIP Server 2 is removed from the signaling path. An
EventPartyChanged
message is generated for Agent C on SIP Server 3, based on information received in the
INVITE
request with the
Replaces
header.
ISCC Path Optimization
Introduced in
SIP Server
8.1.101.33
For trunk optimization scenarios, SIP Server supports the ISCC path optimization feature, which excludes unnecessary hops in the user data propagation path and enhances reliability of data propagation. The ISCC path optimization is enabled by default and is controlled by the path-optimization parameter. This feature does not change event distribution to clients, but rather modifies the path by which these events are conveyed.
See “ISCC Path Optimization” on page 686
for details.
386 Framework 8.1
Chapter 5: SIP Server Feature Support User to User Information (UUI)
Feature Configuration
describes how to configure trunk optimization.
Table 95: Configuring Trunk Optimization
Objective
1. Create
Trunk
DNs.
Related Procedures and Actions
In each SIP Server configuration (origination and destination), in the corresponding SIP Switch, configure a DN of type
Trunk
. These
Trunk
DNs will be used for direct signaling between SIP Servers.
For each
Trunk
DN, in the
TServer
section of the
Annex
tab, configure the following options:
•
false
. This will ensure that the
REFER
method for this
Trunk
DN will be used only for multi-site transfer optimization scenarios.
•
true
.
•
—Set this option to true
.
2. Configure the SIP Server
Application.
In multi-site routing, to avoid reporting an access resource as
AttributeOtherDN
in related events, in the extrouter
section of the SIP
Server
Application
transaction type (such as direct-uui
).
Feature Limitation
This functionality requires direct signaling (no media gateways or session border controllers) between any two SIP Server instances, with no alteration of the SIP attributes (
CALL-ID
, to
header, from
header); as these are used for unique call context matching.
User to User Information (UUI)
SIP Server supports the SIP
User-to-User
header, as specified in the RFC draft
“A Mechanism for Transporting User to User Call Control Information in SIP.”
SIP Server does not generate UUI by itself.
It only receives UUI and passes it through without modifications. UUI is considered correct if it complies with the following rules:
•
UUI must contain the encoding
parameter.
•
The length of the
User-to-User
data must not be greater than the value
specified by the sip-max-uui-length
SIP Server receives UUI in a SIP message or in a
TRouteCall
request. To extract UUI from the
TRouteCall
request, configure mapping the
User-to-User header from the T-Library request to a SIP message. You can also configure
SIP Server—Deployment Guide 387
Chapter 5: SIP Server Feature Support User to User Information (UUI) mapping the
User-to-User
header from a SIP message to a T-Library request.
See “Mapping SIP Headers and SDP Messages” on page 276
for more information.
The
User-to-User header field can be included in
INVITE
and
BYE
messages.
SIP Server supports the uui
tag in the
Supported
or
Require
header.
If SIP Server is configured to use the MSML service for all media services operations using Genesys Media Server, then SIP Server also passes UUI from the initial
INVITE
message to GVP.
SIP Server passes UUI in one of the following ways:
•
In the
User-to-User
header—This method is applicable to
INVITE
,
BYE
, and
REFER
messages. To enable passing the
User-to-User
header from the
REFER requests, this header must be configured in the
configuration option.
•
In the URI parameter of the
Refer-To
header—SIP Server checks the
Refer-To
header of the
REFER
request for User-to-User data. If UUI is present, SIP Server includes it in the
Refer-To
header of the outgoing
REFER or in the
User-to-User
header of the subsequent
INVITE
.
•
In the URI parameter of the
Contact
header—SIP Server checks the
Contact
header of the
302 Moved temporary
response for User-to-User data.
If UUI is present, SIP includes it in the
User-to-User
header of the outgoing
INVITE
message.
Examples
1. If the
REFER
request contains the following information:
Refer-To: <sip:[email protected]:5060?User-to-
User=1234567890abcdef%3Bencoding%3Dhex%3Bpurpose%3Disdnnetwork%3Bco ntent%3Disdn-uui>>
SIP Server includes this in the
INVITE
request:
INVITE sip:[email protected]:5060... …
...
...
User-to-User:1234567890abcdef;encoding=hex;purpose=isdnnetwork;content=isdn-uui
2. If the
302 Moved Temporary
response contains the following information:
Contact: <sip:[email protected]:5060?User-to-
User=1234567890abcdef%3Bencoding%3Dhex%3Bpurpose%3Disdnnetwork%3Bco ntent%3Disdn-uui>
SIP Server includes this in the
INVITE
request:
INVITE sip:[email protected]:5060 …
...
...
User-to-User:
1234567890abcdef;encoding=hex;purpose=isdnnetwork;content=isdn-uui
388 Framework 8.1
Chapter 5: SIP Server Feature Support Video Blocking
Feature Limitations
•
SIP Server does not support multiple
User-to-User
headers in one message.
•
User-to-User information is not synchronized between the primary and backup SIP Servers in the HA pair. As a result, User-to-User information might be lost because of a SIP Server switchover.
Video Blocking
SIP Server provides the ability to block video streams from SDP offers during the call negotiation/establishment process so video will not be played when a call is established.
With this feature enabled:
•
If an SDP offer contains both audio and video media types, only the audio stream is available for the call.
•
If an SDP offer contains only a video media type and no other media types are available for negotiation, the call is rejected.
Example
The following is an example of the SDP body message containing both audio and video media types (highlighted): v=0 o=alice 2890844526 2890844526 IN IP4 host.dalycity.example.com
s= c=IN IP4 host.dalycity.example.com
t=0 0 m=audio 49170 RTP/AVP 0 8 97 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 m=video 51372 RTP/AVP 31 32 a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000
When video blocking is enabled, SIP Server blocks (removes) the video media stream, as indicated in the following: v=0 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s= c=IN IP4 host.atlanta.example.com
t=0 0 m=audio 49170 RTP/AVP 0 8 97 a=rtpmap:0 PCMU/8000
SIP Server—Deployment Guide 389
Chapter 5: SIP Server Feature Support Video Support a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/800
Feature Configuration
The sip-filter-media
configuration option enables this feature. The option
can be set at both Application ( sip-filter-media
)
) levels. The option setting at the DN level takes precedence over the
Application-level setting.
Feature Limitation
SDP media stream type filtering is not performed when SIP Server is placed out of the signaling path (OOSP).
Video Support
SIP Server supports the following scenarios related to Video Call functionality:
•
Push Video
•
Video Call on Hold
•
Video Call Transfer
•
Video Call Treatment
•
Outbound Video Call
•
Video Conference with active speaker detection (with Genesys Media
Server only)
Push Video
Push Video functionality enables a person to play a video file to another call participant during a call. SIP Server can support video streams using Stream
Manager or Genesys Media Server and T-Library functions.
Start Video
To start playing a video file, SIP Server uses the
TSingleStepConference function to push video from an agent to a customer. This function must contain the following attributes:
•
OtherDN
—Represents a video source. It is always defined as the gcti::video
string.
•
Extensions
—Must contain the following key-value pairs:
390 Framework 8.1
Chapter 5: SIP Server Feature Support Video Support
VideoFile
—A string that contains the name of the video file that will be played for the customer. If this key-value pair is not specified, the default video file will be played. The default video file is configured in the SIP Server
Application
object, using the
configuration option.
AgentVideo
—A string that identifies the origin of the video stream played to the agent. The values are as follows: from-third-party
—The agent receives video from a third party—that is, the party that participated in the call before the operation started.
to-third-party
—The agent receives the same video stream as played to the third party—that is, video from the file specified by the
VideoFile
parameter. (The from-video-file value can be used as an alias.)
In either case, both the customer and agent hear each other and the audio that comes with the video file. The customer, the agent, and the audio source from the video file are three participants in the audio conference. When the pushed video ends, the customer and the agent continue a regular two-party conversation.
If the
AgentVideo
key is not specified, or if it is empty, the to-third-party
value will be used.
Stop Video
There are several ways to stop playing a video file:
•
By deleting a party from a conference
•
By releasing the gcti::video
device
•
When the video file ends
Deleting a Conference Call
SIP Server uses the
TDeleteFromConference
function to stop a video stream from a conference call. In this scenario, the
OtherDN
attribute is always defined as the gcti::video
string.
Releasing the Device
SIP Server uses the
TReleaseCall
function to stop a video stream by releasing the gcti::video
device. In this scenario, the
ThisDN
attribute is always defined as the gcti::video
string.
When the File Ends
Stream Manager or Genesys Media Server will end the SIP dialog for the gcti::video
device when the video file ends, but it will not end the other SIP dialogs that belong to the conference.
SIP Server—Deployment Guide 391
Chapter 5: SIP Server Feature Support Video Support
Other Supported Scenarios
Video Call on Hold
The video call can be put on hold by using the
THoldCall
function. Stream
Manager or Genesys Media Server analyzes the endpoint capabilities submitted inside the endpoint’s SDP message, and when supported, plays a video file.
Video Call Transfer
SIP Server supports a video call transfer by providing a regular offer/answer
SDP message exchange between an endpoint during 1pcc operation.
Video Call Treatment
SIP Server supports a video call treatment in which a video file can be played to a customer when their call is on a Routing Point. The treatment prompts can be defined in a URS strategy that points to video files. For the video calls,
Stream Manager or Genesys Media Server plays both video and audio when a video prompt is specified.
Outbound Video Call
An agent can initiate an outbound video call using the
TMakeCall
function. In
the SIP Server configuration, the refer-enabled
true,
or the
option must be set to
1
. The
INVITE
message to an external destination will contain SDP information with the agent’s endpoint video capabilities.
When the agent initiates an outbound video call, and a recipient accepts it, the video file starts playing. If the recipient’s endpoint does not have video capabilities or refuses the video connection, only an audio connection—without the video—is established.
Feature Configuration
describes how to configure video support.
392 Framework 8.1
Chapter 5: SIP Server Feature Support Video Support
Table 96: Configuring Video Support
Objective Related Procedures and Actions
1. Install a PC video camera.
Follow the instructions in the video camera documentation.
2. Configure a SIP endpoint to support video functionality.
3. Configure a SIP
Server
Application.
Follow the instructions specific to the SIP endpoint you are using.
Complete the wizard steps, and select the installed video camera on the corresponding wizard page.
4. Configure a gcti::video device.
In the SIP Server
Application
object, in the
TServer
section on the
Options
tab,
specify the default-video-file
configuration option. This option contains the
name of the video file that is played to the caller if a single-step conference to the gcti::video
device does not contain a
VideoFile
key in the
Extensions
attribute.
For Push Video:
Under a configured
Switch
object >
DNs
folder, create a new DN object by setting the following properties:
•
Number
: Enter gcti::video
.
•
Type
: Select
Trunk
.
5. Configure a video service.
For Push Video:
1. Under a configured
Switch
object >
DNs
folder, create a new DN object by setting the following properties:
Number
: Enter the DN name. This name is currently not used for any messaging, but it must still be unique.
Type
: Select
Voice over IP Service
.
2. In the
TServer
section, configure the following options:
—Specify the value using the Stream Manager or Genesys Media
Server application settings in the following format:
IP address:SIP port
—Specify the value to be used as a template for the source of the video stream and as the value of the
Request-URI
parameter in the
INVITE
message: annc@<sm_or_mediaserver_hostport>;play=
<file>)
;repeat=<number>)
video.
Feature Limitations
The Video Conference functionality is not supported with Stream Manager.
However, Video Conference with active speaker detection is available for integrations with Genesys Media Server.
SIP Server—Deployment Guide 393
Chapter 5: SIP Server Feature Support Working with Multiple Devices
Working with Multiple Devices
When multiple devices within a deployment are able to provide a particular service—for example,
Trunk
DNs representing several possible gateways for placing an outbound call, or
Voice over IP Servic e DNs at different locations configured to provide music treatments for an inbound call—SIP Server uses a selection algorithm to choose the most appropriate device to provide the service.
Device Selection Procedure
Prefix match
Current availability
SIP Server makes its selection from the pool of compatible devices in the following order of descending priority:
1.
2.
3.
4.
5.
6.
7.
8.
SIP Server first narrows the pool of devices by matching the prefix option as defined on the DNs. SIP Server chooses the longest match possible. For example, if SIP Server finds some devices with a prefix of
90
and other devices with a prefix of
900
, SIP Server narrows the pool to those devices that have the longer prefix of
900
.
SIP Server further narrows the pool to those devices that are currently in service. For example, if the maximum capacity for the device has been reached, or if the device has been marked as temporarily unavailable, SIP
Server does not consider the device.
Partition-id parameter
Geo-location attribute
Note:
If at this point in the selection process SIP Server finds no currently available device, it cannot go back and select a shorter prefix match. For example, if the devices that have a prefix of
900 become unavailable, SIP Server cannot then consider devices that have a prefix of
90
. Instead, it returns an error.
SIP Server uses the partition-id parameter to select a service based on the partition to which the call belongs.
Services that have the same geo-location as the target are preferred over all others. If no matching geo-location is found, or if no geo-location is configured
394 Framework 8.1
Chapter 5: SIP Server Feature Support Working with Multiple Devices
Cpd-capability parameter
Priority attribute
Percentage of used capacity
Round-robin
on the target, no differentiation is made from among the pool of available
resources. For more information, see “Selection Based on Geo-Location” on page 397
.
When making an outbound predictive call, SIP Server narrows the pool of available outbound gateways to those configured for cpd-capability
. If no
Trunk
DN with cpd-capability
is found, SIP Server will try to perform CPD on GVP instead, using the media server capability of the GVP Media Control
Platform (MCP).
Services that have higher priority (the lower the configured priority number, the higher the priority) are always preferred over services of lower priority. If the higher priority device becomes unavailable because its maximum capacity is reached, only in this case will a lower priority service be considered.
According to this rule, SIP Server selects the service that has the least amount of used capacity. For example, SIP Server will select a service that has used only 10% of its maximum configured capacity over a service with 50% used capacity. SIP Server compares services in pairs—if either service in the pair is not configured for capacity, SIP Server uses the round-robin method instead.
SIP Server selects the service that has the gone the longest length of time without being selected for a call. SIP Server considers only the time of selection. It does not consider either the reasons for previous selections, or the call end times.
Note:
In cases where SIP Server selects a
Trunk
DN that represents a gateway, but all lines for that gateway are busy, occupied, or otherwise out-of-service, SIP Server will silently try to reach the destination by using another gateway
Trunk
DN, if one is available. SIP Server remembers the failed
Trunk
DN and, if more than one
Trunk
DN is configured, avoids trying it again for the duration of the call.
Feature Configuration
describes how to define the device-selection process—which priorities in the algorithm will be considered when selecting a device.
Table 97: Defining the Device-Selection Process
Objective
1. Selection based on prefix match.
Related Procedures and Actions
(Optional) If disabled, SIP Server does not consider the prefix when selecting a device.
This step in the procedure applies to
Trunk
DN selection only.
• Gateway—To include the prefix match when selecting a gateway,
option on the
Trunk
DN for the gateway to the initial digits of the dialed number that will map to this gateway.
SIP Server—Deployment Guide 395
Chapter 5: SIP Server Feature Support Working with Multiple Devices
Table 97: Defining the Device-Selection Process (Continued)
Objective
2. Selection based on availability.
Related Procedures and Actions
No configuration required.
SIP Server always checks for the availability of compatible devices. If no available device is found, SIP Server returns an error.
3. Selection based on partition.
SIP Server matches originating device with available resource devices using the default SIP Server partition.
To change the default partition, do the following:
1. To define the default partition for all DNs, set the partition-id
option in the SIP Server
Application
object. All DNs on this switch will be considered to belong to this partition, unless otherwise defined.
2. To assign a particular DN to a different partition, set the
option in the DN object to the partition to which it belongs.
4. Selection based on geolocation.
(Optional) If disabled, SIP Server does not consider the geo-location when selecting a device.
1. Configure all applicable
Voice over IP Service
and
Trunk
DNs at a particular premise with the same geo-location
value. For a list
of DN types that support geo-location, see Table 108, “DN
Configuration Objects,” on page 574
.
2. In the SIP Server
Application
object, set the find-trunk-bylocation
true
.
3. (Optional) Configure a routing or treatment block in the routing strategy to include the geo-location
Extension
attribute with the same value as the DNs at the same premise.
Note: This method takes precedence over
geo-location configured at the DN level.
For more information, see Procedure: Setting the geo-location for a call, on page 398
.
5. Selection based on cpdcapability.
To identify a particular gateway or media server as CPD-capable, configure as follows:
• media gateway—On the
Trunk
DN for the gateway, set the cpdcapability
option to one of the following supported gateway
types:
audiocodes
paraxip
• GVP Media Server—On the
Trunk Grou p DN for the GVP media server, set
mediaserver
396 Framework 8.1
Chapter 5: SIP Server Feature Support Working with Multiple Devices
Table 97: Defining the Device-Selection Process (Continued)
Objective
6. Selection based on priority setting.
7. Selection based on used capacity.
Related Procedures and Actions
(Optional) If disabled, SIP Server does not consider the priority
setting when selecting a device.
To include the priority setting when selecting a device, configure the applicable DN as follows:
•
Annex
tab, in the
TServer
section, set this option to the desired priority level.
(Optional) If disabled, SIP Server does not consider the capacity setting when selecting a device.
This step in the procedure applies to
Trunk
DN selection only.
To include the capacity setting when selecting a Trunk, configure all applicable DNs as follows:
•
Trunk
DN, set the
capacity that is available for this device.
•
—You can use this option to assign a defined capacity to multiple
Trunk
DNs.
Selection Based on Geo-Location
Participants within VoIP conversations are divided into two groups:
•
Internal parties that represent agents or supervisor SIP endpoints. These communicate directly with each other by signaling directly with SIP Server and by RTP streams. In the Configuration Layer, they are configured as
DNs of type
Extension.
•
External parties that represent customers or agents at remote sites. These communicate with contact center devices using a media gateway or other proxy services. External parties do not have a direct representation at the
Configuration Layer; instead, they must be represented as a
Trunk
DN or a
“media gateway” that is associated with a SIP Server
Switch
object.
You need to choose a gateway at the same premise where the agent SIP endpoint is located to minimize network load for RTP traffic and for VoIP media services, such as music on hold, central mixing conferencing, or voice recording. Devices in the same premise must be configured with the same
•
An internal party has the same option value as the corresponding
Extension
DN object when a call is established.
•
An external party has the same option value as the corresponding
Trunk
DN object when a call is established.
•
A media server has the same option value as the corresponding
Voice over
IP Service
DN object when a call is established.
SIP Server—Deployment Guide 397
Chapter 5: SIP Server Feature Support Working with Multiple Devices
To include the geo-location
attribute in the procedure that SIP Server uses to select a gateway or trunk for the outbound call, you must set the
true
.
To determine the gateway for an external party of an inbound call, the IP address from the
Via
header of the incoming
INVITE
message must match the host address of the contact
option of the
Trunk
DN. If a match is successful, the geo-location
label for the matched trunk will be used as the geo-location label for the external party. In order for this match to work, the contact of the corresponding trunk must be the same, because it is expected to be inside the
Via
header of the incoming
INVITE
message (most likely a decimal IP address).
If SIP Server cannot find a
Trunk
DN with a contact
option to match the identifier provided in the
Via
header, then SIP Server rejects the call and issues a
404 Not Found
message.
For other services, such as music, treatment
, or recorder
SIP Server searches for the same geo-location
label as the party requesting such service.
Procedure:
Setting the geo-location for a call
Outgoing Calls
Incoming Calls
Consultation Calls
Purpose: To configure the DNs or routing strategy that are required to apply the geo-location for the call.
For geo-location matching to work, both parties in the SIP call must be configured with the same geo-location label. The semantics for the label are arbitrary, but they must be consistent across the premise.
For outgoing calls, the agent DN that is making the call must be configured with a geo-location label. When this agent places a call, SIP Server searches available
Trunk
DNs (according to the selection algorithm) for any that are configured with the matching geo-location
label.
For incoming calls, the geo-location label for a call can be applied either through the
Trunk
DN where the call first arrives, or through a routing strategy that is loaded on the
Routing Point
DN where the call first arrives. Geolocation that is assigned from the routing strategy takes precedence.
For consultation calls, SIP Server looks for an external destination based on the geo-location value as set on the originating DN for the consultation call. If the consultation scenario involves a Routing Point, then SIP Server checks for geo-location according to the following priority (listed in order of precedence from highest to lowest):
•
The
Extensions
parameter in the
RequestRouteCall
.
•
The geo-location
option as set on the
Routing Point
DN.
•
The geo-location
option as set on the originating DN for the consultation call.
398 Framework 8.1
Chapter 5: SIP Server Feature Support Working with Multiple Devices
Internal Calls
Voice over IP
Service
For internal calls, in HoldCall scenarios, the geo-location label for a call is assigned through the party to which the Music-on-Hold (MOH) is played. If geo-location is not configured in that party, then SIP Server chooses the geolocation configured in the originating party. If the scenario involves a Routing
Point, then SIP Server checks for geo-location according to the following priority (listed in order of precedence from highest to lowest):
•
The geo-location
option as set on the DN to which MOH is played.
•
The
Extensions
parameter in the
RequestRouteCall
.
•
The geo-location
option as set on the
Routing Point
DN.
•
The geo-location
option as set on the originating DN.
For call treatments, you can configure the
Voice over IP Service
DN that provides the service (music on hold, for example) with a geo-location label that matches the label for a gateway at the same premise. This allows SIP
Server to choose a server at the same location as the gateway, minimizing RTP
traffic. For a list of DN types that support geo-location, see Table 108, “DN
Configuration Objects,” on page 574 .
Start of procedure
1. For outbound calls—Configure the agent DNs and gateway DNs at the same premise with identical geo-location labels.
a. On the
Extension
DN for the agent, on the
Annex
tab, in the
TServer section, set the geo-location
to the identifier that you want to use for this premise.
b. On the
Trunk
DN for a gateway at the same premise, on the
Annex
tab, in the
TServer
section, set the geo-location
to the same identifier as you did for the agent DNs.
2. For inbound calls—Configure the
Voice over IP Service
DNs for any
SIP services that you expect to provide for calls arriving at the same premise as the server that provides the service.
a. On the
Voice over IP Service
DN, on the
Annex
tab, in the
TServer section, set the geo-location
to the identifier that you use for this premise.
b. If the
Trunk
DN for the gateway at this premise is not already configured for it, set the geo-location
to the identifier that you use for this premise.
OR
In the routing strategy, configure the
Function
object to attach the
Extensions attribute to the call: set the key name to geo-location
and set the value to the identifier you use for the desired premise.
End of procedure
SIP Server—Deployment Guide 399
Chapter 5: SIP Server Feature Support Working with Multiple Devices
Geo-Location Support by GVP
Introduced in
SIP Server
8.1.101.62
Genesys software applies geo-location to multiple configuration objects. This enables Resource Manager to select the closest Media Server to the caller or agent, minimizing WAN traffic and telecom costs. SIP Server passes geolocation data to Resource Manager when Genesys Media Server is configured as:
•
a Trunk DN
•
a Trunk Group DN
•
a Voice Treatment Port (VTP) DN
•
an MSML Voice over IP Service (VOIP) DN
•
a Voicemail VOIP DN
This table matches integration modes with DN types:
Table 98: SIP Server-Genesys Media Server Integration Modes:
Required DN Types
Integration Mode
GVP Inbound mode
Outbound Integration mode
Voicemail Integration mode
Media Server mode
Configure Genesys Media Server as this DN Type:
Trunk DN
Trunk Group DN and VTP DN
VOIP Service DN
( service-type=voicemail
)
VOIP Service DN
( service-type=msml
)
SIP Server puts the geo-location value of a call into the
X-Genesys-geolocation
header of the
INVITE
that it sends to Resource Manager, but only under these conditions:
•
if the call’s geo-location is defined as a call property.
OR
•
if the call's geo-location is passed as an extension in a T-Library request
(such as
TApplyTreatment
and
TRouteCall
).
If neither is true, then SIP Server does not pass the geo-location to Resource
Manager.
For example: some countries require that an incoming call's geo-location be passed as a call property, and other countries do not require it. Now you can configure Media Server to account for that.
For more information about setting geo-location for a call, see “Selection
Based on Geo-Location” on page 397 .
400 Framework 8.1
Chapter 5: SIP Server Feature Support Working with Multiple Devices
Deployment Examples
GVP Inbound mode
•
Single Media Server with MCP farms located at a different geo-location
•
Multiple Media Servers each with MCP farms located in different geolocations
Outbound Integration mode
•
Single Media Server handling multiple geo-location farms
•
Multiple Media Servers handling multiple geo-location farms
CTI through IVR Server (IVR-centric)
•
Single Media Server handling multiple media farms
•
Multiple Media Servers located in multiple locations handling multiple
MCP farms
Voicemail Integration mode
•
Single Media Server and multiple MCP farms
•
Multiple Media Servers located at different locations handling multiple
MCP farms
Strict Geo-location matching scenario
See “Geo-Location for MSML-Based Services: Strict Matching” on page 401 .
Geo-Location for MSML-Based Services: Strict Matching
Introduced in
SIP Server
8.1.101.62
SIP Server supports strict geo-location matching for MSML-based services by ensuring that a call with a particular geo-location is served only by an MSML service within the same geo-location or by an MSML service within the alternate location (if configured). If a correctly geo-located MSML service is unavailable, SIP Server does not provide the required service.
SIP Server—Deployment Guide 401
Chapter 5: SIP Server Feature Support Working with Multiple Devices
SIP Headers
To prevent GVP from using a wrongly located MCP farm, SIP Server adds (in addition to the
X-Genesys-geo-location
header) the
X-Genesys-strictlocation
header with a value of enforce
to the
INVITE
that it sends to GVP.
Table 99: Geo-location: Strict Matching SIP Headers
Header Name
X-Genesys-geo-location
Header Value Meaning
It contains the call geo-location label if an MSML service matching that label is available. It contains the overflow-location label if the initial
MSML service is not available.
Instructs the Resource Manager to choose the MCP that serves a particular location.
X-Genesys-strict-location enforce
Informs the Resource Manager that it must reject
INVITE
if there is no MCP available that serves a particular the geo-location.
Alternate Geo-Location
The alternate geo-location defined by the overflow-location-map
you to pair an alternate MSML-based service with a geo-location label. The alternate (overflow) location will be tried if the primary geo-location is not available or fails. In addition, the overflow-location
key can be provided in
AttributeExtensions
of the
TRouteCall
and
TApplyTreatment
client requests.
The value of the overflow-location
key in
AttributeExtensions
takes precedence over the overflow-location-map
option value. If present in the request, the overflow-location key enables a strict MSML-based service location for the call even if it is disabled at the Application level. If the overflow-location
key is empty, SIP Server removes the previously assigned overflow-location (if set at an Application level) and enables MSML strict geo-location matching.
If SIP Server finds the corresponding service and sends an
INVITE
to that service but does not receive a positive response, SIP Server might retry an
INVITE
attempt once more—but only within the service that has the same geolocation or geo-location equal to the value of the overflow-location
key.
Failure Alarms
SIP Server can generate an MSML geo-location failure alarm whenever an attempt to provide an MSML service fails because of the geo-location strict matching. The option
specifies how often SIP
Server sends that alarm (
52052
code). An alarm message contains a list of failed geo-locations along with a number of failures occurred within the
402 Framework 8.1
Chapter 5: SIP Server Feature Support Working with Multiple Devices timeout. There is no message to reset the alarm. It is supposed to be reset by the Management Layer timeout (should be greater than the timeout defined by the option above) when SIP Server stops detecting new MSML geo-location failures.
Feature Configuration
Table 100 describes how to enable geo-location with strict matching.
Table 100: Configuring Geo-Location with Strict Matching
Objective
Configure the SIP Server
Application.
Configure MSML DN(s).
Related Procedures and Actions
In the
TServer
section of the SIP Server
Application, configure the following options:
•
—Set this option to msml or true.
• (Optional)
this option to geo-location label=overflow-location
label.
• (Optional) msml-location-alarm-timeout
•
—Set this option to true
.
See “Configuring Genesys Media Server” on page 93
.
Configure a Trunk DN.
(Optional) Configure a treatment block in the routing strategy.
1. Create a DN of type
Trunk
.
2. In the
TServer
section, configure the following option:
—Set to the same geolocation value as any of the MSML DNs.
Include the geo-location
extension key with the same value as any of the MSML DNs.
Note: This method takes precedence over geolocation configured at the DN level.
Feature Limitations
•
The feature works only for MSML-based devices (no NETANN support).
•
If an MSML service is selected for a device with contact=::msml
on a corresponding DN (
Trunk, Voice Treatment Port, Trunk Group, or
Voicemail DN), the feature works properly only in the Active-Active RM pair deployment.
SIP Server—Deployment Guide 403
Chapter 5: SIP Server Feature Support Genesys Voice Platform Integration
•
If an MSML service is selected for a device with contact=::msml
on a corresponding DN (
Trunk, Voice Treatment Port, Trunk Group,
or
Voicemail DN), SIP Server does not try the alternate (overflow) location if an initial
INVITE
to the primary geo-location fails. This limitation does not apply to the selection of the destination for the initial
INVITE
.
Genesys Voice Platform Integration
For detailed information about SIP Server integration with the Genesys Voice
Platform (GVP), see the following documents:
•
The
Genesys 7.5 GVP–SIP Server Integration Guide
—This guide provides an overview of the GVP–SIP Server integration in its various modes—In-
Front, Behind, and Standalone—as well as the relevant procedures for completing the integration. This document applies to the 7.5 release of SIP
Server, and the 7.5 and 7.6 releases of GVP.
•
The
Genesys 8.1 Voice Platform Solution Integration Guide
—This guide provides an overview of the Voice Platform Solution (VPS), with the aim of integrating the various components that make up the solution. This document applies to the 7.6 release of SIP Server and the 8.1 release of
GVP.
Active-Active Resource Managers
Resource Managers (RM) can be deployed in an Active-Active High-
Availability cluster, in which both RM instances run together as the active instance, each with a unique IP address. The active pair synchronizes active session information, so that both instances can correctly route incoming requests.
shows a sample deployment in which SIP Server performs load balancing between two RM instances using a round-robin algorithm.
SIP Server
SIP
SIP
Resource
Manager 1
sync
Resource
Manager 2
SIP
SIP
Figure 45: SIP Server/Active-Active RM Pair Deployment
One or more
Media Server farms
404 Framework 8.1
Chapter 5: SIP Server Feature Support Genesys Voice Platform Integration
Multiple Resource Manager Pairs
SIP Server can also work with multiple Active-Active RM pairs, with each
RM pair managing separate Media Server farms. If these RM pair and Media
Server/MCP farms are deployed across multiple locations, SIP Server uses geo-location to select among the locations.
How It Works
In Active-Active RM pair deployments, SIP Server performs load balancing between two RM instances. To check current RM availability, SIP Server sends periodic
OPTIONS
messages to each RM instance.
In the configuration, each Active-Active RM pair is represented by a single
DN of type
Voice over IP Service
with service-type=msml
(or multiple DNs if there are more RM pairs). If a particular RM instance does not respond to the
OPTIONS
message, SIP Server marks that instance as out-of-service. If both instances in the RM pair fail to respond, then SIP Server marks the MSML DN as out-of-service.
When SIP Server needs to send a request to Media Sever (for example, to start a continuous playback treatment), SIP Server selects an active RM instance. If for some reason this RM instance fails, SIP Server sends any further middialog requests to the alternate RM instance. Active-active synchronization between the RM pair ensures that all call details are shared by both instances, providing uninterrupted service.
Building the Request-URI
SIP Server connects to the RM pair using multiple IP addresses or Fully-
Qualified Domain Names (FQDN).
SIP Server builds the Request-URI for Active-Active RM deployments differently, depending on the configuration:
•
If the contact of the RM instance is configured as an FQDN in the contact option, SIP Server sends this FQDN in the Request-URI of the new
INVITE
.
•
If the IP address of the RM instance is configured in the contact-list option, SIP Server builds the Request-URI of the outgoing
INVITE
with the selected transport IP address, port, and protocol information.
OPTIONS Message Optimization
SIP Server integrates with GVP using different modes, where RM is configured as a different DN for each mode. SIP Server can work with GVP in the following modes:
•
Media server mode:
SIP Server uses GVP to play treatments, MOH, and so on.
RM is configured as an MSML DN of type
Voice over IP Service
.
SIP Server—Deployment Guide 405
Chapter 5: SIP Server Feature Support Genesys Voice Platform Integration
•
GVP Inbound mode:
GVP is used as self service and SIP Server forwards requests to GVP.
RM is configured as a
Trunk
DN.
•
Outbound mode:
SIP Server uses GVP for CPD and to play treatments.
RM is configured as a
Trunk Group
DN.
If SIP Server were to send
OPTIONS messages to each of these DNs, this would increase the load on the network. To avoid unnecessary network load, you configure the contact of the RM in the MSML DN. SIP Server sends
OPTIONS messages to this DN to monitor availability. It also creates an active transport list for this DN.
For all other DNs that need to use this RM contact, configure the contact using the special value
::msml
. When SIP Server receives this special contact, it selects the MSML DN and gets the contact information from there. The
::msml value is mandatory only in Active-Active RM pair integration scenarios and must not be used in other integrations, such as Active-Standby RM integration.
Note:
Genesys recommends using the TCP protocol for all transport between SIP Server and GVP. This is mandatory if TLib-to-SIP user data mapping is configured between SIP Server and GVP.
Feature Configuration
Active-Active RM pair support can be configured using the following methods:
•
FQDN-based: The RM contact is configured using the FQDN that resolves to two SRV records; each SRV record resolves to the IP address/port for one RM in the Active-Active RM pair.
•
IP-based: The RM contact is configured using IP address/port information.
406 Framework 8.1
Chapter 5: SIP Server Feature Support Genesys Voice Platform Integration
Table 101 describes the configuration required for both FQDN- and IP-based
Active-Active RM integration scenarios.
Table 101: Integrating with Active-Active RM Pair
Objective
1. Configure the SIP Server
Application.
2. Configure Resource Manager
Applications.
Related Procedures and Actions
In the SIP Server
Application
object >
Options
>
TServer
section, configure the following options:
•
—Set this option to true.
•
—For FQDN-based method, set this option to true.
•
—For FQDN-based method, set this option to true.
•
option should be equal to the sum of the values of the oos-check
options (set at the DN level) multiplied by two.
SIP Server must try to pass a media service request through both
RM instances in the Active-Active RM pair before the
INVITE transaction expires.
Configure two instances of Resource Managers to work in Active-
Active mode.
In the first RM
Application
of the pair (Node 1) >
Options
> cluster
section, configure the following options:
• ha-mode
—Set this option to active-active.
• mymemberid
—Set this option to
1.
• member.1
—Set this option to the IP address of this RM, followed by the cluster-communication-port number, and separated by a colon (:).
• member.2
—Set this option to the IP address of the other RM node (Node 2), followed by the cluster-communication-port number, and separated by a colon.
• hotstandby
—Set this option to
TRUE.
• members
—Ensure this option is set to
1 2
(separated by a space).
SIP Server—Deployment Guide 407
Chapter 5: SIP Server Feature Support Genesys Voice Platform Integration
Table 101: Integrating with Active-Active RM Pair (Continued)
Objective
(continued)
3. Configure the MCP
Application.
Related Procedures and Actions
In the second RM
Application
of the pair (Node 2) >
Options
> cluster
section, configure the following options:
• ha-mode
—Set this option to active-active.
• mymemberid
—Set this option to
2.
• member.1
—Set this option to the IP address of the other RM node (Node 1), followed by the cluster-communication-port number, and separated by a colon.
• member.2
—Set this option to the IP address of this RM, followed by the cluster-communication-port number, and separated by a colon.
• hotstandby
—Set this option to
TRUE.
• members
—Ensure this option is set to
1 2
(separated by a space).
In the MCP
Application
>
Options
> sip
section, configure the following option:
• transport.staticroutelist
—Set this option to the IP addresses of the RM pair, separated by a comma, since they are within the same route group. Do not specify a port number.
408 Framework 8.1
Chapter 5: SIP Server Feature Support Genesys Voice Platform Integration
Table 101: Integrating with Active-Active RM Pair (Continued)
Objective
4. Create a DN to represent the
Active-Active RM pair.
5. Enable GVP Inbound.
Related Procedures and Actions
Create a
Voice over IP Servic e DN to handle the connection between SIP Server and the RM instances:
1. Set the service-type
for this DN to msml
.
2. Configure the contact information as follows:
For FQDN-based configuration:
—Enter the FQDN for the RM instances. See “DNS
Name Resolution” on page 232 for details.
For IP-based configuration:
—Enter a comma-separated list of IP addresses and ports of RM instances.
3. Enable Active-Out-of-Service Detection for this DN:
Configure the
Out-of-Service Detection” on page 254 for details.
4. Configure geo-location for this DN:
—Enter the location for the RM instances. See
“Geo-location attribute” on page 394
for details.
5. Configure subscription for this DN:
—Set this option to the name of the Tenant to which this DN belongs.
For SIP Proxy deployments: In addition to the above, add the following configuration option for FQDN-based configuration:
•
true.
To enable inbound GVP where SIP Server is located in front of
GVP and forwards inbound calls to GVP, complete the following steps:
1. Create a
Trunk
DN to represent GVP.
2. Configure the following options:
—Set this option to
::msml.
—Enter the initial digits to match the DNIS number.
—Set this option to
2
.
— Enter the location for the RM instances.
For SIP Proxy deployments: In addition to the above, add the following configuration option for FQDN-based configuration:
•
true.
SIP Server—Deployment Guide 409
Chapter 5: SIP Server Feature Support Genesys Voice Platform Integration
Table 101: Integrating with Active-Active RM Pair (Continued)
Objective
6. Enable GVP Outbound.
7. For deployments with SIP
Proxy, configure SIP Proxy.
Related Procedures and Actions
To enable outbound GVP where GVP is used as a media server to provide services used for outbound, complete the following steps:
1. Create a
Trunk Group
DN to handle outbound calls through
GVP.
2. Configure the following options:
—Set this option to
::msml.
—Enter the name of the tenant.
(Note: Starting with GVP 8.1.2, multi-tenancy is supported. Set the name of this Trunk Group to the name of the tenant to which this DN applies.)
1
.
—Set this option to false
.
false.
—Enter a URI in the following format:
sip:msml@<RMHost>:<RMPort>;media-service=cpd;gvptenant-id=[<tenant name>]
3. If the outbound integration includes Voice Treatment Ports
(VTPs), you must also configure each VTP DN with the following option:
—Set this option to
::msml.
For SIP Proxy deployments: In addition to the above, add the following configuration option for FQDN-based configuration:
•
true.
See “SIP Proxy Support” on page 361 for configuration details.
Active-Active RM Integration Limitations
•
In both modes (IP-based and FQDN-based), SIP Server does not support configuring priority and weight for each IP address. All entries are considered of equal priority and weight.
•
Genesys recommends that you set the
option to a value equal to twice the sum of the values of the oos-check
options set at the DN level. This ensures that SIP Server tries both Resource Manager instances before deciding that a particular site is not responding.
410 Framework 8.1
Chapter 5: SIP Server Feature Support Genesys Voice Platform Integration
Genesys Media Server
For information about SIP Server integration with the Genesys Media Server
(GVP for media services only), see “Configuring Genesys Media Server” on page 93
, as well as the
Genesys Media Server Deployment Guide
.
GVP Integration Limitation
When SIP Server is working in High-Availability (HA) mode, multiple switchovers between backup and primary SIP Server instances can interfere with SIP Server correctly sending SUBSCRIBE messages to Genesys Voice
Platform. To ensure that SIP Server is able to send these messages, you must enable Active Out-of-Service Detection for the
Trunk Group
DN that represents
GVP, as follows:
•
On the
Trunk Group
DN that represents GVP, enable the options oos-check
and
SIP Server—Deployment Guide 411
Chapter 5: SIP Server Feature Support Genesys Voice Platform Integration
412 Framework 8.1
Download
Link público atualizado
O link público para seu chat foi atualizado. Você pode visualizar e gerenciar seus links de chat após o registro aqui.
Link público do documento
Anúncio
