Genesys 8.1 SIP Server Deployment Guide
Publicitate
Publicitate
Framework 8.1
SIP Server
Deployment Guide
The information contained herein is proprietary and confidential and cannot be disclosed or duplicated without the prior written consent of Genesys Telecommunications Laboratories, Inc.
Copyright © 2004–2017 Genesys Telecommunications Laboratories, Inc. All rights reserved.
About Genesys
Genesys powers 25 billion of the world's best customer experiences each year. Our success comes from connecting employee and customer conversations on any channel, every day. Over 10,000 companies in 100+ countries trust our
#1 customer experience platform to drive great business outcomes and create lasting relationships. Combining the best of technology and human ingenuity, we build solutions that mirror natural communication and work the way you think. Our industry-leading solutions foster true omnichannel engagement, performing equally well across all channels, on-premise and in the cloud. Experience communication as it should be: fluid, instinctive and profoundly empowering.
Go to www.genesys.com
for more information.
Each product has its own documentation for online viewing at the Genesys Documentation website or on the
Documentation Library DVD, which is available from Genesys upon request. For more information, contact your sales representative.
Notice
Although reasonable effort is made to ensure that the information in this document is complete and accurate at the time of release, Genesys Telecommunications Laboratories, Inc., cannot assume responsibility for any existing errors.
Changes and/or corrections to the information contained in this document may be incorporated in future versions.
Your Responsibility for Your System’s Security
You are responsible for the security of your system. Product administration to prevent unauthorized use is your responsibility. Your system administrator should read all documents provided with this product to fully understand the features available that reduce your risk of incurring charges for unlicensed use of Genesys products.
Trademarks
Genesys and the Genesys logo are registered trademarks of Genesys Telecommunications Laboratories, Inc. All other company names and logos may be trademarks or registered trademarks of their respective holders.
The Crystal monospace font is used by permission of Software Renovation Corporation, www.SoftwareRenovation.com
.
Technical Support from VARs
If you have purchased support from a value-added reseller (VAR), please contact the VAR for technical support.
Customer Care from Genesys
If you have purchased support directly from Genesys, please contact Genesys Customer Care . Before contacting
Customer Care, please refer to the
Genesys Care Support Guide for On-Premises
for complete contact information and procedures.
Ordering and Licensing Information
Complete information on ordering and licensing Genesys products can be found in the
Genesys Licensing Guide.
Released by
Genesys Telecommunications Laboratories, Inc. www.genesys.com
Document Version: 81fr_dep-sip_07-2017_v8.1.101.4
4
Table of Contents
List of
Procedures
Preface
Part 1
Chapter 1
Reading Prerequisites ........................................................................ 18
Making Comments on This Document .................................................... 18
Contacting Genesys Customer Care....................................................... 19
Document Change History ...................................................................... 19
New in Document Version 8.1.101.44 ................................................ 19
New in Document Version 8.1.101.40 ................................................ 19
New in Document Version 8.1.101.35 ................................................ 20
New in Document Version 8.1.101.30 ................................................ 21
New in Document Version 8.1.101.25 ................................................ 23
New in Document Version 8.1.101.22 ................................................ 23
New in Document Version 8.1.101.18 ................................................ 24
New in Document Version 8.1.101.14 ................................................ 25
New in Document Version 8.1.101.10 ................................................ 26
New in Document Version 8.1.101.05 ................................................ 26
New in Document Version 8.1.101.00 ................................................ 27
New in Document Version 8.1.003.08 ................................................ 27
SIP Server Deployment............................................... 29
New in Release 8.1.1.......................................................................... 30
New in Release 8.1.0.......................................................................... 35
SIP Server Fundamentals .................................................................... 39
SIP Server Deployment Modes .......................................................... 40
Media Server Deployment Architecture .............................................. 43
Redundant SIP Servers (High Availability) .............................................. 44
SIP Server—Deployment Guide 3
Table of Contents
Chapter 2
Chapter 3
Chapter 4
4
Multi-Threaded Architecture .................................................................... 45
SIP Server General Deployment.......................................................... 49
Software Requirements ...................................................................... 50
Hardware and Network Environment Requirements........................... 51
Licensing Requirements ..................................................................... 52
About Configuration Options............................................................... 54
Network Considerations .......................................................................... 54
Bandwidth Requirements.................................................................... 55
Remote Agent Configuration .............................................................. 56
Deployment Sequence ............................................................................ 57
Deployment of SIP Server ....................................................................... 57
Configuration of Telephony Objects .................................................... 57
Configuration of SIP Server ................................................................ 59
Installation of SIP Server .................................................................... 61
Starting and Stopping SIP Server ....................................................... 65
Command-Line Parameters .................................................................... 65
Starting and Stopping with the Management Layer ................................. 67
Verifying Successful Startup .................................................................... 70
Starting and Stopping with Windows Services Manager ......................... 72
SIP Devices Support ............................................................................ 73
About Trunk and Trunk Group DNs .................................................... 75
Configuring Devices and Services........................................................... 76
Configuring ACD Queues ................................................................... 77
Configuring MCUs .............................................................................. 77
Configuring Endpoints......................................................................... 78
Configuring Gateways ........................................................................ 81
Configuring Music Servers.................................................................. 83
Configuring Routing Points ................................................................. 85
Framework 8.1
Table of Contents
Chapter 5
Configuring Softswitches .................................................................... 85
Configuring an Application Service..................................................... 87
Configuring a Recording Service ........................................................ 88
Configuring a Treatment Service ........................................................ 90
Configuring an MSML Service ............................................................ 91
Configuring Agent Logins ........................................................................ 92
Configuring Stream Manager................................................................... 92
Location of Media Files....................................................................... 93
Load Balancing of Media Services ..................................................... 93
Determining Codecs ........................................................................... 93
Configuring Genesys Media Server......................................................... 93
About Genesys Media Server............................................................. 93
SIP Server and Media Server Integration ........................................... 95
Genesys Media Server Integration ..................................................... 95
SIP Server Feature Support................................................................. 99
Feature Configuration ....................................................................... 102
Feature Limitation ............................................................................. 102
Feature Configuration ....................................................................... 104
How the Alert-Info Header is Built..................................................... 105
Other Uses for the Alert-Info Header ................................................ 106
Feature Configuration ....................................................................... 107
Alternate Routing for Stranded Calls ................................................ 108
Alternate Routing for Unresponsive DNs.......................................... 110
Alternate Routing for Unresponsive URS/ORS .................................111
Alternate Routing for Calls to an External Destination...................... 114
Application Failure Detection................................................................. 114
How Failure Detection Works ........................................................... 115
Feature Configuration ....................................................................... 115
Feature Limitation ............................................................................. 115
Associating an ACD Queue with a Routing Point.................................. 116
Asterisk Voice Mail Integration .............................................................. 116
Genesys Voice Mail Configuration Adapter for Asterisk ................... 117
Message Waiting Indicator Functionality .......................................... 117
Feature Configuration ....................................................................... 118
Automatic Inactive Agent Logout........................................................... 119
Feature Configuration ....................................................................... 119
SIP Server—Deployment Guide 5
Table of Contents
6
Call Completion Features ...................................................................... 119
Feature Configuration ....................................................................... 120
Feature Limitation ............................................................................. 121
Feature Configuration ....................................................................... 121
Feature Limitations ........................................................................... 121
Caller Information Delivery Content for AT&T Trunks............................ 122
Feature Configuration ....................................................................... 125
Feature Limitations ........................................................................... 125
Feature Configuration ....................................................................... 126
Feature Limitation ............................................................................. 126
Call Recording—NETANN-Based ......................................................... 126
Regular Call Recording..................................................................... 126
Feature Configuration ....................................................................... 128
Emergency (Manual) Call Recording................................................ 129
Call Recording—MSML-Based.............................................................. 130
About Genesys Media Server........................................................... 130
How Call Recording Works ............................................................... 130
Feature Configuration ....................................................................... 138
Call Recording—Geo-location ............................................................... 141
Inbound Call Scenarios..................................................................... 141
Outbound Call Scenarios.................................................................. 141
Feature Limitation ............................................................................. 142
DN-Based Reporting......................................................................... 143
Feature Configuration ....................................................................... 143
Call Supervision Configuration ......................................................... 149
Feature Limitations ........................................................................... 154
Multi-Site Supervision ....................................................................... 155
Remote Supervision ......................................................................... 158
Call Transfer and Conference................................................................ 167
Conference Calls .............................................................................. 170
Consultation Transfers and Conferences ......................................... 176
Feature Limitations ........................................................................... 178
Outbound Dialing Rules.................................................................... 179
Ring-Through Rules.......................................................................... 186
Feature Configuration ....................................................................... 187
Consolidated Error Response ............................................................... 190
Framework 8.1
Table of Contents
Feature Configuration ....................................................................... 191
Control of SIP Response Code from within Routing Strategy ............... 192
Feature Configuration ....................................................................... 192
Customizing Music on Hold and in Queue ............................................ 194
Playing Music to Calls on Hold ......................................................... 194
Playing Music to Calls in Queue ....................................................... 198
Customizing SIP Header Formats ......................................................... 198
Enabling Additional Parameters in Request-URI.............................. 198
Enabling Server and User-Agent Headers ....................................... 200
Contact Header Handling Options .................................................... 201
Diversion Header .............................................................................. 203
Early Media Private Header.............................................................. 208
Private Headers ................................................................................ 209
Dial Plan Configuration Overview ..................................................... 211
Dial Plan Call Flow............................................................................ 212
The Dial-Plan Rule............................................................................ 214
About Privilege Levels ...................................................................... 220
Feature Configuration ....................................................................... 220
Dial Plan For Multi-Site Calls ............................................................ 230
Feature Limitations ........................................................................... 231
DNS Name Resolution .......................................................................... 232
Feature Configuration ....................................................................... 233
DTMF Clamping in a Conference .......................................................... 234
Activating DTMF Clamping ............................................................... 235
DTMF Clamping in Recordings......................................................... 235
Feature Limitations ........................................................................... 236
DTMF Tones Generation ....................................................................... 236
DTMF Parameters for Play Application Treatments ......................... 237
Feature Configuration ....................................................................... 237
Feature Configuration ....................................................................... 239
E911 Emergency Gateway .................................................................... 240
Feature Configuration ....................................................................... 240
Early Media for Inbound Calls ............................................................... 247
Feature Configuration ....................................................................... 248
Feature Limitation ............................................................................. 248
Business-Call Handling..................................................................... 249
Emulated Agents Support ................................................................. 250
SIP Server—Deployment Guide 7
Table of Contents
8
Endpoint Service Monitoring.................................................................. 253
Passive Out-of-Service Detection..................................................... 254
Active Out-of-Service Detection........................................................ 254
High-Availability Considerations ....................................................... 256
Feature Configuration ....................................................................... 257
Feature Configuration ....................................................................... 258
Feature Limitations ........................................................................... 258
HTTP Live Streaming ............................................................................ 259
HTTP Monitoring Interface .................................................................... 260
Feature Configuration ....................................................................... 261
Feature Limitations ........................................................................... 262
Genesys Contact Center in the IMS Network ................................... 263
Feature Configuration ....................................................................... 264
Instant Messaging Transcript............................................................ 265
Supported Call Operations ............................................................... 266
Instant Messaging For Multi-Site Calls ............................................. 270
Feature Configuration ....................................................................... 271
Feature Limitations ........................................................................... 272
Feature Configuration ....................................................................... 273
High-Availability Considerations ....................................................... 273
Feature Limitations ........................................................................... 274
Keep Alive for TCP Connections ........................................................... 274
Mapping Treatment Errors..................................................................... 275
Feature Configuration ....................................................................... 276
Mapping SIP Headers and SDP Messages........................................... 276
From SIP Messages to T-Library Messages..................................... 276
From T-Library Messages to SIP Messages..................................... 282
SDP Message Mapping .................................................................... 285
Dynamic DN Replacement ............................................................... 285
SIP Headers Encoding ..................................................................... 286
Masking Sensitive Data in SIP Messages ............................................. 286
Media Server Reliability—NETANN/MSML ........................................... 286
How SIP Server Detects a Media Server Failure.............................. 287
Reliability for Conference Calls......................................................... 288
Reliability for Supervisor Features.................................................... 288
Reliability for Voice Call Recording................................................... 288
Framework 8.1
Table of Contents
Media Server Reliability—NETANN .................................................. 288
Media Server Reliability—MSML ...................................................... 289
Feature Configuration ....................................................................... 290
Feature Limitation ............................................................................. 290
Modifying the From Header in SIP INVITE............................................ 290
Multi-Threaded Logging......................................................................... 290
Feature Configuration ....................................................................... 293
Music and Announcements ................................................................... 293
Announcement Treatments on Routing Points ................................. 294
Music Treatments on Routing Points ................................................ 296
Other Treatments on Routing Points................................................. 297
Feature Limitation ............................................................................. 297
Nailed-Up Connections.......................................................................... 298
Establishing the Nailed-Up Connection ............................................ 298
Disconnecting the Nailed-Up Connection ......................................... 301
Feature Configuration ....................................................................... 301
Feature Limitations ........................................................................... 302
Network Asserted Identity...................................................................... 303
How the Mechanism Works .............................................................. 303
How SIP Server Supports the Mechanism........................................ 304
Outbound Calls ................................................................................. 307
Internal Call (CLIR) ........................................................................... 308
Feature Configuration ....................................................................... 309
Feature Limitations ........................................................................... 310
Network Attended Transfer.................................................................... 310
Feature Configuration ....................................................................... 312
Feature Limitations ........................................................................... 312
No-Answer Supervision ......................................................................... 313
Business and Private Calls ............................................................... 313
Agent No-Answer Supervision.......................................................... 313
Extension No-Answer Supervision ................................................... 315
Position No-Answer Supervision ...................................................... 315
Device-Specific Overrides................................................................. 316
Extension Attributes for Overrides for Individual Calls...................... 316
Feature Limitations ........................................................................... 316
Outbound IP Solution Integration .......................................................... 317
SIP Server Features for Outbound IP Solution................................. 317
Feature Configuration ....................................................................... 322
Feature Limitations ........................................................................... 323
How Overload Control Works ........................................................... 324
Feature Configuration ....................................................................... 327
SIP Server—Deployment Guide 9
Table of Contents
10
P-Access-Network-Info Private Header................................................. 330
VXML Support for Agent Greeting .................................................... 332
Disabling Media Before Greeting...................................................... 334
Recording an Agent Greeting ........................................................... 335
Presence from Switches and Endpoints................................................ 336
Subscription to SIP Server................................................................ 336
SIP Server Subscription to Endpoints Behind a Switch .................... 337
Endpoint Sends PUBLISH Requests to SIP Server.......................... 338
Agent Login and State Update on SIP Phones................................. 339
Presence Integration with Microsoft Office
Communications Server 2007 ...................................................... 342
Preview Interaction for IM ................................................................. 348
Providing Call Participant Info ............................................................... 349
Feature Configuration ....................................................................... 351
Feature Limitations ........................................................................... 351
Providing Origination DN Name and Location in EventRinging............. 351
Feature Configuration ....................................................................... 354
Remote Media on Genesys SIP Endpoint SDK 8.0............................... 356
Feature Configuration ....................................................................... 356
Remote Server Registration .................................................................. 357
Sending Outgoing INVITEs with Multipart Body .................................... 357
Feature Configuration ....................................................................... 361
Feature Configuration ....................................................................... 361
Feature Configuration ....................................................................... 363
Feature Limitations ........................................................................... 364
Shared Call Appearance ....................................................................... 365
Feature Configuration ....................................................................... 368
Feature Limitations ........................................................................... 370
Smart OtherDN Handling....................................................................... 371
Supported Requests ......................................................................... 371
Feature Configuration ....................................................................... 372
Feature Limitation ............................................................................. 373
Framework 8.1
Table of Contents
Chapter 6
Chapter 7
SRV Address Support in Contact and Record-Route Headers ............. 373
Feature Configuration ....................................................................... 373
Feature Limitations ........................................................................... 374
Transport Layer Security for SIP Traffic................................................. 374
Feature Configuration ....................................................................... 375
Duplicated DN Names ...................................................................... 377
Bounced Calls Between T-Servers ................................................... 378
Feature Configuration ....................................................................... 379
Feature Configuration ....................................................................... 381
Trunk Optimization for Multi-Site Transfers ........................................... 383
ISCC Path Optimization.................................................................... 386
Feature Configuration ....................................................................... 387
Feature Limitation ............................................................................. 387
User to User Information (UUI).............................................................. 387
Feature Configuration ....................................................................... 390
Feature Limitation ............................................................................. 390
Other Supported Scenarios .............................................................. 392
Feature Configuration ....................................................................... 392
Working with Multiple Devices............................................................... 394
Device Selection Procedure ............................................................. 394
Selection Based on Geo-Location .................................................... 397
Geo-Location Support by GVP ......................................................... 400
Geo-Location for MSML-Based Services: Strict Matching................ 401
Genesys Voice Platform Integration ...................................................... 404
Active-Active Resource Managers.................................................... 404
Genesys Media Server ..................................................................... 411
GVP Integration Limitation ................................................................ 411
T-Library Functionality Support........................................................ 413
Using T-Library Functions...................................................................... 413
Using the Extensions Attribute .............................................................. 422
Third-Party Equipment—Known Limitations ..................................... 442
SIP Server Configuration Options .................................................... 443
Application-Level Options...................................................................... 443
SIP Server—Deployment Guide 11
Table of Contents
Part 2
Chapter 8
Chapter 9
12
TServer Section ................................................................................ 443
UPDATE, INVITE, INFO, and REFER Sections ............................... 546
SIP Error Map Section ...................................................................... 549
Agent Login–Level and DN-Level Options ............................................ 550
AuthClient Section ............................................................................ 550
TServer Section ................................................................................ 551
GVP Integration Options........................................................................ 621
Changes from Release 8.0 to Release 8.1............................................ 623
T-Server Common Functions and Procedures....... 631
New for All T-Servers in 8.1................................................................... 631
T-Server Fundamentals...................................................................... 633
Learning About T-Server ....................................................................... 633
Framework and Media Layer Architecture........................................ 633
T-Server Requests and Events ......................................................... 635
Advanced Disconnect Detection Protocol ............................................. 639
Redundant T-Servers ............................................................................ 640
Multi-Site Fundamentals........................................................................ 648
ISCC Call Data Transfer Service ........................................................... 649
ISCC Call Flows................................................................................ 650
ISCC Transaction Types ................................................................... 656
T-Server Transaction Type Support .................................................. 663
Transfer Connect Service Feature.................................................... 667
ISCC/Call Overflow Feature .................................................................. 668
Number Translation Feature.................................................................. 672
Number Translation Rules ................................................................ 673
Network Attended Transfer/Conference Feature................................... 681
Event Propagation Feature.................................................................... 683
User Data Propagation ..................................................................... 683
Party Events Propagation ................................................................. 684
Switch Partitioning ............................................................................ 685
ISCC Path Optimization.................................................................... 686
Framework 8.1
Table of Contents
Chapter 10
Chapter 11
Event Propagation Configuration ...................................................... 688
ISCC Transaction Monitoring Feature ................................................... 691
Configuring Multi-Site Support............................................................... 691
Switches and Access Codes ............................................................ 693
Configuration Examples.................................................................... 704
Common Configuration Options....................................................... 707
Setting Configuration Options................................................................ 707
Log Output Options........................................................................... 714
Debug Log Options........................................................................... 720
T-Server Common Configuration Options ....................................... 729
Setting Configuration Options................................................................ 729
agent-reservation Section...................................................................... 738
ISCC Transaction Options ................................................................ 741
Transfer Connect Service Options.................................................... 746
ISCC/COF Options ........................................................................... 746
Event Propagation Options ............................................................... 749
Number Translation Option............................................................... 750
Translation Rules Section...................................................................... 753
Timeout Value Format ........................................................................... 754
Changes from Release 8.0 to 8.1.......................................................... 755
SIP Server—Deployment Guide 13
Table of Contents
Supplements
Related Documentation Resources ................................................... 757
Document Conventions ...................................................................... 759
Index
14 Framework 8.1
List of Procedures
Configuring SIP Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Installing SIP Server on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Installing SIP Server on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Verifying the installation of SIP Server . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Configuring SIP Server to start with the Management Layer . . . . . . . . . 67
Starting SIP Server on UNIX with a startup file . . . . . . . . . . . . . . . . . . . 68
Starting SIP Server on Windows with a startup file . . . . . . . . . . . . . . . . 69
Starting SIP Server on UNIX manually. . . . . . . . . . . . . . . . . . . . . . . . . . 70
Starting SIP Server on Windows manually. . . . . . . . . . . . . . . . . . . . . . . 70
Stopping SIP Server on UNIX manually . . . . . . . . . . . . . . . . . . . . . . . . . 71
Stopping SIP Server on Windows manually . . . . . . . . . . . . . . . . . . . . . . 71
Configuring an ACD Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Configuring a gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Configuring a Music Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Configuring Routing Points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Configuring softswitches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Configuring an application service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Configuring a recording service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Configuring a treatment service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Configuring an MSML Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Configuring remote supervision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Configuring a COS DN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Controlling SIP Response Codes from a Routing Strategy . . . . . . . . . 193
Configuring a Dial-Plan DN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Configuring Class of Service for a Dial Plan. . . . . . . . . . . . . . . . . . . . . 224
Including additional dial plans. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Assigning the dial plan to a device . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
SIP Server—Deployment Guide 15
List of Procedures
Assigning COS to a device. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Assigning the dial plan and COS globally. . . . . . . . . . . . . . . . . . . . . . . 228
Using SIP Feature Server Dial Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Creating the EGW DN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Creating a dial-plan DN for the ANI to CBN conversion . . . . . . . . . . . . 243
Assigning the EGW DN to the ANI-to-CBN dial plan . . . . . . . . . . . . . . 244
Creating a dial-plan DN for the CBN to ANI conversion . . . . . . . . . . . . 244
Configuring the call path (DID not allowed) . . . . . . . . . . . . . . . . . . . . . 245
Installing and Configuring the Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Enabling presence subscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Setting the geo-location for a call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
Activating Transfer Connect Service . . . . . . . . . . . . . . . . . . . . . . . . . . 668
Configuring Number Translation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 680
Activating Event Propagation: basic configuration . . . . . . . . . . . . . . . . 689
Modifying Event Propagation: advanced configuration . . . . . . . . . . . . 689
Configuring T-Server Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
Configuring Default Access Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . 694
Configuring Access Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695
Configuring access resources for the route transaction type . . . . . . . . 700
Configuring access resources for the dnis-pool transaction type . . . . . 701
Configuring access resources for direct-* transaction types . . . . . . . . 702
Configuring access resources for ISCC/COF. . . . . . . . . . . . . . . . . . . . 702
Configuring access resources for non-unique ANI . . . . . . . . . . . . . . . . 703
Modifying DNs for isolated switch partitioning . . . . . . . . . . . . . . . . . . . 704
16 Framework 8.1
Preface
Welcome to the Framework 8.1 SIP Server Deployment Guide. This document introduces you to the concepts, terminology, and procedures relevant to
T-Servers ® in general and provides detailed reference information about SIP
Server.
The information includes, but is not limited to, configuration options, limitations, and switch-specific functionality. You must configure the configuration objects and options described in this document in the Framework
Configuration Layer.
Use this document only after you have read through the
Framework 8.1
Deployment Guide
, and the Release Note for SIP Server.
This document is valid only for the 8.1 release of this product.
Note:
For versions of this document created for other releases of this product, visit the Genesys Documentation website, or request the
Documentation Library DVD, which you can order by e-mail from
Genesys Order Management at [email protected]
.
This preface contains the following sections:
Making Comments on This Document, page 18
Contacting Genesys Customer Care, page 19
Document Change History, page 19
For information about related resources and about the conventions that are used in this document, see the supplementary material starting on
About SIP Server
SIP Server is the Genesys software component that provides an interface between your telephony hardware and the rest of the Genesys software components in your enterprise. It translates and keeps track of events and requests that come from, and are sent to the telephony device. SIP Server is a
TCP/IP-based server that can also act as a messaging interface between SIP
Server clients. It is the critical point in allowing your Genesys solution to facilitate and track the contacts that flow through your enterprise.
SIP Server—Deployment Guide 17
Preface Intended Audience
Intended Audience
This guide is intended primarily for system administrators, both those who are new to SIP Server and those who are familiar with it.
•
If you are new to SIP Server, read the Framework 8.1 SIP Server
Deployment Guide and the Release Note mentioned earlier, and then read all of the sections of this document that apply to your software and its accompanying components. Refer back to the Framework 8.1 Deployment
Guide as needed.
•
If you are an experienced SIP Server user—someone with computer expertise, who is used to installing, configuring, testing, or maintaining
Genesys software—you may find it more time efficient to go to the Index to see what is new or different in SIP Server release 8.1. If you take that approach, please also read Release Notes and refer to other related resources, such as the Genesys Events and Models Reference Manual.
In general, this document assumes that you have a basic understanding of, and familiarity with:
•
Network design and operation.
•
Your own network configurations.
•
Your telephony hardware and software.
•
Genesys Framework architecture and functions.
•
Configuration Manager or Genesys Administrator interface and objectmanaging operations.
Based on your specific contact center environment and your responsibilities in it, you may need to be familiar with a much wider range of issues as you deploy SIP Server.
Reading Prerequisites
You must read the Framework 8.1 Deployment Guide before using this SIP
Server Deployment Guide. That book contains information about the Genesys software you must deploy before deploying SIP Server.
Making Comments on This Document
If you especially like or dislike anything about this document, feel free to email your comments to
.
You can comment on what you regard as specific errors or omissions, and on the accuracy, organization, subject matter, or completeness of this document.
Please limit your comments to the scope of this document only and to the way in which the information is presented. Contact your Genesys Account
18 Framework 8.1
Preface Contacting Genesys Customer Care
Representative or Genesys Customer Care if you have suggestions about the product itself.
When you send us comments, you grant Genesys a nonexclusive right to use or distribute your comments in any way it believes appropriate, without incurring any obligation to you.
Contacting Genesys Customer Care
If you have purchased support directly from Genesys, please contact Genesys
Customer Care .
Before contacting Customer Care, please refer to the
Genesys Care Support
Guide for On-Premises
for complete contact information and procedures.
Document Change History
This section lists topics that are new or that have changed significantly since the first release of this document.
New in Document Version 8.1.101.44
The following topics have been added or changed since the previous release of this document:
•
Added “SRV Address Support in Contact and Record-Route Headers” on page 373
.
•
Added “Masking Sensitive Data in SIP Messages” on page 286 .
•
Added the following configuration options:
•
Updated the following configuration options:
New in Document Version 8.1.101.40
The following topics have been added or changed since the previous release of this document:
•
Added “Recording an Agent Greeting” on page 335
.
•
Added “Controlling Early Media with a Routing Strategy” on page 247
.
SIP Server—Deployment Guide 19
Preface Document Change History
•
Added “HTTP Live Streaming” on page 259 .
•
Added “SIP Feature Server Log Messages” on page 230
.
•
Added “Setting SIP INVITE Timeout for Individual DNs” on page 110
.
•
Revised “Customizing Music on Hold and in Queue” on page 194
.
•
Added “CPU Usage Overload Control” on page 327
.
•
Added the following configuration options:
find-outbound-msml-by-location
(Application level)
(Application level)
(Application level)
(Application level)
(Application level)
(Application level)
(Application level)
(DN level)
(Application level)
(DN level)
•
Updated the following configuration options:
•
Removed
sip-save-rejected-sdp
New in Document Version 8.1.101.35
The following topics have been added or changed since the previous release of this document:
•
Added “Instant Messaging For Multi-Site Calls” on page 270 .
•
Added “Defining After Routing Timeout Action” on page 314 .
•
Updated “Caller Information Delivery Content for AT&T Trunks” on page 122
to include support for GVP.
•
Added “Modifying the From Header in SIP INVITE” on page 290
.
•
Added “Muting/Unmuting a Party in a Conference” on page 173
.
•
Added “HTTP Monitoring Interface” on page 260
.
•
Updated “Dial Plan” on page 210 to include support for the SIP Feature
Server dial plan.
•
Added the following configuration options:
20 Framework 8.1
Preface Document Change History
(DN level)
(Application level)
(Application level)
(DN level)
greeting-stops-no-answer-timeout
(Application level)
(Application level)
(Application level)
(Application level)
(Application level)
(Application level)
(Application level)
(DN level)
(DN level)
(Application level)
(Application level)
(Application level)
•
Updated the following configuration options:
(Application level)
(DN level)
(Application level)
(Application level)
(DN level)
(DN level)
New in Document Version 8.1.101.30
The following topics have been added or changed since the previous release of this document:
•
Added “Find Me Follow Me” on page 257 .
•
Added “Customer-on-Hold Privacy” on page 148 .
•
Added “Caller Information Delivery Content for AT&T Trunks” on page 122
.
•
Added “DTMF Clamping in a Conference” on page 234
.
•
Added “Private Conversations During Conference” on page 172
.
•
Added “Remote Agents” on page 355 .
•
Added “Sending Outgoing INVITEs with Multipart Body” on page 357
.
•
Added “Providing Origination DN Name and Location in EventRinging” on page 351 .
SIP Server—Deployment Guide 21
Preface Document Change History
•
Added reference to “HTTP Monitoring Interface” on page 260.
•
Updated “Alternate Routing for Unresponsive URS/ORS” on page 111
.
•
Updated “Providing Call Participant Info” on page 349
.
•
Updated “ISCC/Call Overflow Feature” on page 668
to include SIP Server support of ANI matching.
•
Updated the following configuration options:
•
Added the following configuration options:
(Application level)
(Application level)
(DN level)
(Application level)
(DN level)
(Application level)
(Application level)
(Application level)
(Application level)
(Application level)
(Application level)
(Application level)
(
Application level)
(Application level)
(DN level)
(Application level)
(Application level)
(Application level)
(Application level)
sip-release-call-on-disable-dn
(Application level)
(Application level)
(Application level)
(Application level)
22 Framework 8.1
Preface Document Change History
New in Document Version 8.1.101.25
The following topics have been added or changed since the previous release of this document:
•
Added “Shared Call Appearance” on page 365
.
•
Added “Disabling Media Before Greeting” on page 334 .
•
Added “Geo-Location Support by GVP” on page 400 .
•
Added “Deleting Party From Conference in Multi-site Deployments” on page 171
.
•
Updated “VXML Support for Agent Greeting” on page 332
.
•
Updated “Geo-Location for MSML-Based Services: Strict Matching” on page 401
.
•
Updated “Quality of Service” on page 354 .
•
Updated “Genesys Media Server Integration” on page 95 .
•
Updated “Nailed-Up Connections” on page 298
.
•
Added the following configuration options:
(DN level)
(Application level)
(DN level)
(Application level)
(DN level)
(Application level)
(Application level)
(DN-level) shared-line-capacity
(DN level)
(Application level)
New in Document Version 8.1.101.22
The following topics have been added or changed since the previous release of this document:
•
Added “Switching Between Supervision Modes” on page 147
.
•
Added “Keep Alive for TCP Connections” on page 274 .
•
Added “Geo-Location for MSML-Based Services: Strict Matching” on page 401
.
•
Added “ISCC Path Optimization” on page 386
and
.
SIP Server—Deployment Guide 23
Preface Document Change History
•
Added “Logging To Remote Location” on page 292 .
•
Updated the following configuration options:
overload-ctrl-call-tapplytreatment-requests-rate
(Application level)
overload-ctrl-call-tupdateuserdata-requests-rate
(Application level)
overload-ctrl-call-trequests-rate
(Application level)
(Application level)
(Application level)
•
Added the following configuration options:
(DN level)
(Application level)
(DN level)
(Application level)
(DN level)
(Application level)
(Application level)
(Application level)
userdata-map-invite-after-refer
•
Removed:
sip-call-retain-timeout
New in Document Version 8.1.101.18
The following topics have been added or changed since the previous release of this document:
•
Updated Hunt Groups to support sequential ringing. See “Hunt Groups” on page 260
.
•
Added “VXML Support for Agent Greeting” on page 332 .
•
Added “Routed Calls as Originating or Terminating” on page 263 .
•
Updated “Music and Announcements” on page 293 .
•
Updated “Nailed-Up Connections” on page 298
.
•
Updated “Call Recording—NETANN-Based” on page 126 .
•
Updated “Call Recording—MSML-Based” on page 130 .
•
Updated “Overload Control” on page 324
.
•
Updated “Providing Call Participant Info” on page 349
.
•
Updated “Smart OtherDN Handling” on page 371
.
•
Updated “SIP Traffic Monitoring” on page 363
.
24 Framework 8.1
Preface Document Change History
•
Updated “User to User Information (UUI)” on page 387
.
•
Updated “Agent Login and State Update on SIP Phones” on page 339
.
•
Updated “Multi-Threaded Versus Single-Threaded Mode” on page 46 .
•
Added information about a number of client connections that SIP Server
supports for Windows and Linux operating systems. See “Client
•
Added the following keys to
AttributeExtensions
:
•
Added the following configuration options:
(Application level)
(DN level)
•
Updated the following configuration options:
(DN level)
(Application level)
(DN level)
(Application level)
(DN level)
(Application level)
(DN level)
New in Document Version 8.1.101.14
The following topics have been added or changed since the previous release of this document:
•
Updated “Trunk Capacity Control” on page 379
.
•
Added “Video Blocking” on page 389
.
•
Added “User to User Information (UUI)” on page 387 .
•
Updated “Dial Plan” on page 210 .
•
Added “Removal Overdialed Digits From DNIS” on page 213 .
•
Added “DN Recording Override” on page 137
.
SIP Server—Deployment Guide 25
Preface Document Change History
•
Added the following configuration options:
(Application level)
(Application level)
(Application level)
(DN level)
•
Updated the following configuration options:
(Application level)
New in Document Version 8.1.101.10
The following topics have been added or changed since the previous release of this document:
•
Updated “Network Asserted Identity” on page 303 .
•
Added “Providing AoC Notifications for Established Calls” on page 104 .
•
Added support for the original-dialplan-digits
extension key to provide
the original destination number before the dial plan is applied. See “Dial
.
•
Added “Recording Calls Without Music-on-Hold Treatment” on page 133 .
•
Added “Call Recording Alarms” on page 135 .
•
Added “SDP Message Mapping” on page 285
.
•
Added support for CPD performed by the Genesys Media Server. See
“Outbound IP Solution Integration” on page 317 .
•
Added “Referred-By Header Support” on page 177 .
•
Added “Filter Greetings By Call Type” on page 330
.
•
Removed Wizard deployment procedures.
New in Document Version 8.1.101.05
The following topics have been added or changed since the previous release of this document:
•
Updated the Active-Active Resource Managers support. See “Active-
Active Resource Managers” on page 404
.
•
Added “SIP Proxy Support” on page 361
.
26 Framework 8.1
Preface Document Change History
•
Added the T-Request overload control section and related configuration
options for this functionality. See “Overload Control” on page 324
for details.
•
Updated “Guidelines for Deploying SIP Server on Various Operating
•
Added “Selecting SIP Call Flows from the Routing Strategy” on page 169
.
•
Updated the following configuration options:
(DN level)
(DN level)
New in Document Version 8.1.101.00
This document has been updated to support SIP Server release 8.1.1.
•
See “New in Release 8.1.1” on page 30 for information about new
supported features.
New in Document Version 8.1.003.08
The following topics have been added or changed since the previous release of this document:
•
Changed several Application and DN-level options that were incorrectly described as changes to the options taking effect immediately. Changes at the DN-level typically do not take place until the next call. The following options were changed:
(DN level)
(DN level)
(DN level)
(DN level)
(DN level)
(DN level)
SIP Server—Deployment Guide 27
Preface Document Change History
(DN level)
(DN level)
(DN level)
(DN level)
(DN level)
(DN level)
(DN level)
•
Added new features for post 8.1.0 releases. See “New in This Release” on page 29 .
•
Added a feature description for ACD Queue functionality on “ACD
•
Added memory limit recommendation for deployments on Linux, Solaris,
and AIX. See “Guidelines for Deploying SIP Server on Various Operating
•
Updated the following configuration options:
(DN level)
(Application level)
(Application level)
•
Added the configuration option
.
28 Framework 8.1
Part
1
SIP Server Deployment
Part One of this SIP Server Deployment Guide contains deployment information specific to your SIP Server. The information in Part One is divided into the following chapters:
•
Chapter 1, “SIP Server Fundamentals,” on page 39 , provides information
about SIP Server architectures and deployment considerations.
•
Chapter 2, “SIP Server General Deployment,” on page 49 , presents
configuration and installation procedures for SIP Server.
•
Chapter 3, “Starting and Stopping SIP Server,” on page 65 , describes how,
and in what order, to start up T-Server among other Framework components. It also provides possible stopping commands.
•
Chapter 4, “SIP Devices Support,” on page 73
, describes compatibility and configuration information specific to SIP Server, including instructions for setting the DN properties and recommendations for the device configuration.
•
Chapter 5, “SIP Server Feature Support,” on page 99
, describes which features SIP Server supports and how to configure them.
•
Chapter 6, “T-Library Functionality Support,” on page 413
, describes the
T-Library functionality that SIP Server supports, known limitations, and error messages.
•
Chapter 7, “SIP Server Configuration Options,” on page 443
, describes configuration options specific to SIP Server.
New in This Release
This section describes new or changed functionality that was introduced in SIP
Server 8.1.x releases:
“New in Release 8.1.1” on page 30
“New in Release 8.1.0” on page 35
SIP Server—Deployment Guide 29
Part 1: SIP Server Deployment New in This Release
New in Release 8.1.1
The following features are introduced in release 8.1.1 of SIP Server:
• SRV address support in
Contact
and
Record-Route
headers. SIP Server supports the SRV FQDN—FQDN resolving to SRV records—received in the
Contact
or
Record-Route
headers of a SIP message. See “SRV Address
Support in Contact and Record-Route Headers” on page 373
.
•
Masking sensitive data in SIP messages. SIP Server can mask sensitive
data in SIP messages contained in SIP Server logs. See “Masking Sensitive
Data in SIP Messages” on page 286 .
•
Recording an Agent Greeting. SIP Server supports recording of the agent
call leg during the personal greeting. See “Recording an Agent Greeting” on page 335 .
•
HTTP Live Streaming. SIP Server must be integrated with MCP version
8.5.161.34 or later. See “HTTP Live Streaming” on page 259 .
•
SIP INVITE timeout for individual DNs. See “Setting SIP INVITE
Timeout for Individual DNs” on page 110
.
•
Music-on-hold enhancement. SIP Server lets you customize music for
music-on-hold treatments. See “Customizing Music on Hold and in
•
CPU usage overload control. This feature provides the ability to control
SIP Server’s CPU usage overload by automatically decrementing the server's log level when the CPU usage overload threshold is reached. See
“CPU Usage Overload Control” on page 327 .
• New Standard-level log events to monitor SIP Feature Server
availability. See “SIP Feature Server Log Messages” on page 230
.
•
Dial Plan enhancement. SIP Server supports the SIP Feature Server dial
plan as an alternative to the internal SIP Server dial plan. See “Dial Plan” on page 210 .
•
Instant Messaging enhancement. SIP Server supports Instant Messaging
for multi-site calls. See “Instant Messaging For Multi-Site Calls” on page 270
.
•
No-Answer Supervision enhancement. 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 after-routing-timeout
After Routing Timeout Action” on page 314
.
• Caller Information Delivery Content for AT&T Trunks enhancement.
SIP Server supports passing the multipart body content received in
INVITE
.
•
From Header in SIP INVITE. SIP Server provides the ability to modify the
From
header in outgoing SIP
INVITE
From Header in SIP INVITE” on page 290 .
30 Framework 8.1
Part 1: SIP Server Deployment New in This Release
•
Muting/Unmuting a Party in a Conference. SIP Server allows any conference party on the call to mute or unmute any internal party in a
conference. See “Muting/Unmuting a Party in a Conference” on page 173
.
•
HTTP Monitoring Interface. SIP Server provides the ability to monitor various operational statistics for its internal modules and statistics relating
to trunks. See “HTTP Monitoring Interface” on page 260 .
•
Caller Information Delivery Content for AT&T Trunks. SIP Server supports passing the multipart body content received in
INVITE
messages
(as described in RFC 5621) to URS/ORS. See “Caller Information
Delivery Content for AT&T Trunks” on page 122
.
•
Alternate Routing enhancement. 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. See “Alternate Routing for Unresponsive URS/ORS” on page 111 .
•
Call Supervision enhancement. SIP Server supports muting a customer who is on hold to the supervisor and agent(s) who are sharing the call. See
“Customer-on-Hold Privacy” on page 148
.
•
DTMF Clamping in a Conference. This feature guards a customer’s sensitive credit card information from an agent’s ears and from call
recording. See “DTMF Clamping in a Conference” on page 234 .
•
Find Me Follow Me. 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. See “Find Me Follow Me” on page 257
.
•
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. See
“Private Conversations During Conference” on page 172
.
•
Sending Outgoing INVITEs with Multipart Body. SIP Server supports passing geo-location information formed by the routing strategy in the multi-part body of the outgoing
INVITE
message. See “Sending Outgoing
INVITEs with Multipart Body” on page 357 .
•
Providing Origination DN Name and Location in EventRinging. SIP
Server 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. See “Providing Origination
DN Name and Location in EventRinging” on page 351 .
SIP Server—Deployment Guide 31
Part 1: SIP Server Deployment New in This Release
•
Providing Call Participant Info enhancement. SIP Server can distribute information about all call participants, including a supervisor’s in-call presence, to logged-in agents by using the SIP
NOTIFY
method and
EventUserEvent
messages in multi-site and complex single-site scenarios.
See “Providing Call Participant Info” on page 349 .
•
Shared Call Appearance. 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. See “Shared Call Appearance” on page 365
.
•
Disabling Media Before Greeting. SIP Server provides the ability to prevent establishing a preliminary audio/video connection between a caller
and an agent before greetings are applied. See “Disabling Media Before
.
•
TDeleteFromConference requests. SIP Server supports
TDeleteFromConference
requests in multi-site deployments. See “Deleting
Party From Conference in Multi-site Deployments” on page 171 .
•
Geo-location support by GVP enhancement. See “Geo-Location
•
Nailed-up connection enhancement. Nailed-up connections can be established on agent login or when an agent is in the Ready state. See
“Nailed-Up Connections” on page 298 .
•
Agent Login and State Update on SIP Phones enhancement. See
“Agent Login and State Update on SIP Phones” on page 339 .
•
Single-step conference enhancement. SIP Server supports a
TSingleStepConference
request to an external destination.
•
Call Supervision enhancement. SIP Server supports switching between
supervision modes. See “Switching Between Supervision Modes” on page 147
.
•
Keep Alive for TCP connections. SIP Server provides the ability to detect stale TCP connections between SIP Server and a SIP device using the TCP
keep-alive mechanism. See “Keep Alive for TCP Connections” on page 274
.
•
Geo-location for MSML-based services: strict matching. 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). See “Geo-Location for
MSML-Based Services: Strict Matching” on page 401 .
•
ISCC Path Optimization. This improves the TEvent Propagation path in
trunk optimization scenarios. See “ISCC Path Optimization” on page 386
.
•
Hunt Groups enhancement. Hunt Groups enhancement to support
sequential ringing. See“Hunt Groups” on page 260 .
32 Framework 8.1
Part 1: SIP Server Deployment New in This Release
•
VXML support for Agent Greeting enhancement. This enhancement allows an agent to accept, reject, transfer the call, or redirect the call to a
new destination. See “VXML Support for Agent Greeting” on page 332
.
•
IMS integration enhancement. See “Routed Calls as Originating or
•
Nailed-up connections enhancement. SIP Server supports agents with nailed-up connections in Business Continuity deployments. See the
SIP
Server 8.1 High-Availability Deployment Guide
.
•
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. See “Video Blocking” on page 389 .
•
Trunk Capacity Control enhancement. 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. See “Trunk Capacity
.
•
Dial Plan enhancement. SIP Server provides the ability for internal and inbound calls coming to a Routing Point to remove overdialed digits from
DNIS when the dnis-max-length
dial-plan rule parameter is specified. See
“Removal Overdialed Digits From DNIS” on page 213
.
•
Call Recording enhancement. Call recording can be selectively disabled through a routing strategy by overriding the record
option configured on a
DN. See “DN Recording Override” on page 137 .
•
Hardware Sizing Tool. SIP Server offers the Sizing Tool to evaluate the
CPU load and network traffic of SIP Server and SIP Proxy applications in your environment. Download the tool from the Genesys SIP Server documentation .
•
Support for a restricted release of SIP Cluster. For information on
Genesys SIP Cluster technology, contact your Genesys representative.
•
Call Park/Retrieve support. See “Call Park/Retrieve” on page 124
.
•
Call Pickup support. See “Call Pickup” on page 125 .
•
Hunt Group support. See “Hunt Groups” on page 260 .
•
IPv6 support. See “IPv6 Support” on page 272
.
•
Support for Resource Manager in Active-Active HA mode. See
“Active-Active Resource Managers” on page 404 .
•
Support for Genesys SIP Proxy. Starting with 8.1.1 release, SIP Server supports Genesys SIP Proxy, which provides an alternative highavailability option without requiring a virtual IP address. In addition, it provides an interface for SIP communication between SIP devices and SIP
Server components. See“SIP Proxy Support” on page 361 .
•
High-Availability enhancements. High-availability functionality has been improved in the following areas:
SIP Server—Deployment Guide 33
Part 1: SIP Server Deployment New in This Release
Network-interface card (NIC) status monitoring
Recovery after network failure
Primary/backup SIP Server synchronization
Note: HA improvements depend on 8.1.2 Management Framework components.
•
Overload Control enhancement. This allows SIP Server to control
incoming T-Requests. See “Overload Control” on page 324 .
•
Network Asserted Identity enhancement. See “Network Asserted
.
•
Personal Greeting enhancement. SIP Server provides the ability to 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. See “Personal
•
Advice of Charge enhancement. SIP Server provides the ability to send
AoC (Advice of Charge) notifications only when a call is answered (that is, the destination party is in the established state). It is a regulatory
requirement in many countries. See “Providing AoC Notifications for
Established Calls” on page 104
.
•
Dial Plan enhancement. Support for the original-dialplan-digits extension key to provide the original destination number before the dial
plan is applied. See “Dial Plan” on page 210
.
•
Blind transfer support. SIP Server supports 3pcc and 1pcc blind transfer operations when a complete transfer operation is performed while the transfer destination party is in the alerting state. To enable this feature, set the blind-transfer-enabled
option to true
at either the Application level, or at the DN level of the transfer destination.
•
Call recording enhancement. SIP Server provides the ability to record a call without recording a music-on-hold treatment when a call is placed on
hold. See “Recording Calls Without Music-on-Hold Treatment” on page 133
.
•
Call recording alarms. SIP Server can monitor the health and status of
Active Call Recording, and generate an alarm if required. See “Call
Recording Alarms” on page 135 .
•
TLS encryption is supported between SIP Server and Active-Active
Resource Managers in a deployment where SIP Server high-availability is configured using the F5 Networks BIG-IP Local Traffic Manager. See the
SIP Server 8.1 Integration Reference Manual
.
•
SIP-to-T-Library Mapping enhancement. SIP Server supports the
EXTRACT_SIP_HEADERS
extension key in the
TMakeCall, TInitiateTransfer, and
TInitiateConference
EXTRACT_SIP_HEADERS” on page 281 .
34 Framework 8.1
Part 1: SIP Server Deployment New in This Release
•
Support for 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. See “Outbound IP
Solution Integration” on page 317
.
•
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. See “Referred-By Header
.
•
Support for Red Hat Enterprise Linux 6 64-bit native.
•
Support for Cisco UCM versions 9.0, 10.5.
•
Support for Siemens OpenScape Voice v7.
New in Release 8.1.0
The following features are introduced in release 8.1.0 of SIP Server:
•
Support for Geo-location in Active Call Recording. See “Call
Recording—Geo-location” on page 141 .
•
Call Completion Feature support. SIP Server supports the features Call
Completion on Busy Subscriber (CCBS) and Call Completion on No
Reply (CCNR). See “Call Completion Features” on page 119 .
•
Additional parameters in Request-URI. SIP Server can be configured to include additional parameters in the
Request-URI
, where the deployment requires it. For example, user=phone
in
INVITE
requests to a particular DN.
See “Enabling Additional Parameters in Request-URI” on page 198 .
•
Support for Server and User-Agent headers. See “Enabling Server and
User-Agent Headers” on page 200 .
•
Enhanced MWI support. SIP Server can send
NOTIFY
requests to endpoint subscriptions regardless of the SIP registration for that endpoint. See
“mwi-notify-unregistered-dn” on page 493 .
•
Network Attended Transfer support. SIP Server supports network attended transfer, alternate and reconnect operations in multi-site
environments. See “Network Attended Transfer” on page 310 .
•
Enhanced Error code handling. SIP Server supports the following improvements to its error code handling:
Simplified error response handling. SIP Server supports mapping different error messages from multiple GVP instances to a single consistent error message (typically, 503 Service Unavailable) that it
sends to the network. See “Consolidated Error Response” on page 190
.
Enhanced error code mapping. SIP Server supports mapping standard SIP and MSML errors sent by GVP to resulting T-Library
messages. See “Mapping Treatment Errors” on page 275 .
SIP Server—Deployment Guide 35
Part 1: SIP Server Deployment New in This Release
•
Disconnect on remote agent logout. SIP Server releases the nailed-up
connection when the remote agent logs out. See “Disconnecting the
Nailed-Up Connection” on page 301
.
•
Call release tracking. SIP Server supports reporting the identity of which party (agent or customer) is responsible for releasing a particular call. See
“Call Release Tracking” on page 142
.
•
Alternate ringtones. SIP Server supports insertion of the SIP
Alert-Info header into
INVITE
requests, in order to specify a distinctive ring-tone
depending on the type of call. See “Alternate Ringtones” on page 104
.
•
Diversion header support. SIP Server supports the
Diversion
header for
redirected calls. See “DNS Name Resolution” on page 232
.
•
Enhanced Private and Custom header support. SIP Server supports the following new private and custom header functionality:
Support for
P-Early-Media
header, used to control the flow of media in
the early dialog state. See “Early Media Private Header” on page 208
.
Support for
P-Access-Network-Info
header, used to provide access to
network information about the user. See “P-Access-Network-Info
Forwarding custom headers—SIP Server can pass custom headers from a
REFER
to an outgoing
INVITE
or
REFER
.
Filtering custom headers—SIP Server can filter custom headers from a
T-Library request to an outgoing
INVITE
or
REFER
.
•
MSML-based Call Recording. SIP Server supports call recording through Media Server Markup Language (MSML), based on integration
with the Genesys Media Server. See “Call Recording—MSML-Based” on page 130
.
•
Media Server Reliability—MSML. SIP Server supports the
SUBSCRIBE/NOTIFY
method for providing reliable MSML-based media
services. See “Media Server Reliability—NETANN/MSML” on page 286
.
•
User to User Information (UUI) support. 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”. It also supports a configurable limit for the length of data included in the UUI
header, up to a maximum of 8192 characters. See “User to User
Information (UUI)” on page 387
.
•
Network requests for media services. SIP Server supports network requests for media services as described in RFC 4240 “Basic Network
Media Services with SIP”. For general support, see
on
page 609 . For information about supporting network
requests through Genesys Media Server, see“Requests from the Network” on page 94
.
36 Framework 8.1
Part 1: SIP Server Deployment New in This Release
•
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. See “Advice of
.
•
Smart OtherDN handling. SIP Server supports converting the Agent ID to the corresponding DN in certain T-Library messages where the Agent ID is included as the value of the
OtherDN
•
Monitoring of consultation calls. SIP Server supports supervisor
monitoring of DNs involved in a consultation call. See “Monitoring
Consultation Calls” on page 146 .
•
Enhanced logging for multi-threaded mode. SIP Server can write log files for each module in a multi-threaded mode architecture to a separate
log file. See “Multi-Threaded Logging” on page 290
.
•
DNS Name Resolution. SIP Server supports DNS name resolution in accordance with RFC 3263. For example, it includes priority and weight information from returned DNS records when resolving hostnames to
multiple corresponding IP addresses. See “DNS Name Resolution” on page 232
.
•
Set trunk capacity from routing strategy. SIP Server supports the use of the
Dest-Capacity
key-value pair in the
Extensions
attribute, as applied by the URS routing strategy, to set the capacity for a targeted Trunk. See
.
•
SIP Authentication for outbound trunks. SIP Server can respond to
HTTP Digest authentication challenges with authentication parameters
configured on the outbound Trunk DN. See “SIP Authentication” on page 360
.
•
Configurable domain in the Refer-To header of a REFER message. See
the option description “override-domain-oosp” on page 584
.
•
Send CPD results from gateway to GVP using MSML. SIP Server sends
CPD results to GVP in the Outbound IP Solution using the existing MSML dialog, instead of using particular SIP messages depending on the gateway
type. See “CPD Performed by Media Gateway” on page 319
.
•
Support for graceful shutdown. Users can shut down applications and solutions gracefully. During this process, applications may be in the new
SUSPENDING
or
SUSPENDED
state before they are finally stopped. For more information, refer to the Framework 8.1 Deployment Guide.
•
Genesys Voicemail Server integration. SIP Server supports integration with Genesys SIP Voicemail Server. For details, see the Genesys SIP
Voicemail 8.1 Deployment Guide.
•
Additional dial-plan parameters. SIP Server supports new parameters in
the dial-plan rule: “onunreach” ,
SIP Server—Deployment Guide 37
Part 1: SIP Server Deployment New in This Release
details, see “Dial-Plan Rule Parameters” on page 217
.
Notes:
• For a list of configuration-option changes that apply to SIP Server,
see “Changes from Release 8.0 to Release 8.1” on page 623 .
• For a list of new features that are common to all T-Servers, see
“New for All T-Servers in 8.1” on page 631 of this document.
38 Framework 8.1
Chapter
1
SIP Server Fundamentals
This chapter provides more in-depth information about SIP Server and contains the following sections:
SIP Server Architecture, page 40
Redundant SIP Servers (High Availability), page 44
Multi-Threaded Architecture, page 45
Overview
SIP Server has the same position in the Genesys Media Layer as all Genesys
T-Servers. SIP Server is a combined T-Server and a call-switching component, in which the call-switching element functions as a SIP (Session Initiation
Protocol) Back-to-Back User Agent (B2BUA). In concrete terms, this means that call switching and control is performed by Genesys—no third-party PBX or ACD system is required. A call’s audio signal and its associated data travel on a single network, which eliminates the problems associated with synchronizing separate voice and data networks. Because SIP Server supports the Internet Engineering Task Force (IETF) SIP RFC 3261 suite, it is compatible with the most popular SIP-compatible, off-the-shelf hardware or software.
SIP Server can operate with or without a third-party softswitch. Genesys SIP
Server gives the entire Genesys line of products access to SIP networks, offering a standards-based, platform-independent means of taking full advantage of the benefits of voice/data convergence.
SIP Server—Deployment Guide 39
Chapter 1: SIP Server Fundamentals SIP Server Architecture
SIP Server Architecture
Figure 1 presents a generalized architecture of the SIP Server network.
PSTN Gateway
PSTN
Customer
Endpoint
PBX Gateway
PBX
SIP Server
Genesys
Suite
IP Network
Softswitch
Customer
Endpoint
Agent
Endpoint
Figure 1: SIP Network Architecture
SIP Server provides all SIP signaling and T-Server functions. Stream Manager is an optional component that is used to play music-on-hold, music-in-queue and announcements, and to collect DTMF digits. A third-party music server is an optional component that is used as an external music source for music-on-hold. A Multipoint Conference Unit (MCU) is an optional component that is used for third-party call control (3pcc) conference calls. It is also used for silent voice monitoring, whisper coaching, intrusion monitoring, and agent-initiated call recording.
The SIP messages that SIP Server sends or receives are very similar in all configurations, but the destination to which SIP Server sends the SIP requests differs according to the deployment configuration. This mostly applies to the routing of
INVITE messages. Other messages follow the path established by
INVITE.
See Chapter 4, “SIP Devices Support,” on page 73
for full details on how to configure the elements of such a network.
SIP Server Deployment Modes
The following SIP Server deployment modes are currently supported:
•
Standalone mode
•
Application Server mode
•
Customer-side proxy mode
40 Framework 8.1
Chapter 1: SIP Server Fundamentals SIP Server Architecture
Stream Manager is used as an MCU in these scenarios. For more information, see the Framework 7.6 Stream Manager Deployment Guide.
Standalone Mode
Figure 2 illustrates SIP Server in the Standalone mode.
SIP
SIP
SIP Server
Agent
Endpoint
Customer
Endpoint
SIP
Agent
Endpoint
Figure 2: Standalone Mode
In this configuration, SIP Server sends all messages to the addresses of the customer and agent endpoints. The IP addresses in this scenario are determined by SIP Server from either of the following sources:
•
Configuration Layer.
When, for each agent DN, an IP address is configured on the DN
Options/Annex
tab. For example, for DN
1077
on the
Options/Annex
tab in the
TServer
section, you set the contact
option to the
[email protected] value. This is useful for agent endpoints.
•
Lookup in the local registrar.
When the agent DN is defined with the registrar as [email protected], and its SIP endpoint has registered this SIP URI (Uniform Resource
Indicator) with the registrar as
the
INVITE
message is sent to the IP address
192.168.2.55
.
•
SIP Server resolves the name as it was dialed.
For example, if the dialed name is [email protected], the request is sent to the address somedomain.com.
Application Server Mode
In the configuration shown in
Figure 3 , SIP Server is deployed as an
Application Server behind a softswitch. This is the most common deployment of SIP Server.
SIP Server—Deployment Guide 41
Chapter 1: SIP Server Fundamentals
42
SIP Server Architecture
Customer
Endpoint
SIP
SIP
Agent
Endpoint
SIP
Softswitch
SIP
SIP Server
Agent
Endpoint
Figure 3: Application Server Mode
In the Application Server mode, SIP Server communicates with a single softswitch. SIP Server is configured to send all
INVITE
requests to the IP address of the softswitch.
In this configuration, the softswitch bypasses SIP Server for direct agent-to-agent calls. As a consequence, agent-to-agent calls are not visible to
SIP Server, and it cannot provide any control over these calls.
Customer-Side Proxy Mode
In the configuration shown in
Figure 4 , a softswitch is deployed between SIP
Server and agent endpoints, but customer endpoints communicate directly with
SIP Server.
SIP Server
SIP
Softswitch
SIP
SIP
Agent
Endpoint
Customer
Endpoint
Agent
Endpoint
Figure 4: Customer-Side Proxy Mode
All inbound calls (from customers to agents) are routed by SIP Server to a softswitch, the IP address of which is configured in Configuration Manager.
For outbound calls (from agents to customers), the IP addresses are determined from the
Request URI
message, or they are configured in Configuration
Manager as gateways (DNs of type
Trunk).
Alternatively, SIP Server can resolve the name as it was dialed. For example, if the dialed name is [email protected], the request is sent to the address somedomain.com.
Framework 8.1
Chapter 1: SIP Server Fundamentals SIP Server Architecture
In this configuration, the softswitch bypasses SIP Server for direct agent-to-agent calls. As a consequence, agent-to-agent calls are not visible to
SIP Server, and it cannot provide any control over these calls.
Media Server Deployment Architecture
Figure 5 illustrates one possible deployment architecture for a third-party
media server (such as a music server or MCU), or for Genesys Stream
Manager used in conjunction with SIP Server and Genesys business applications.
Media Server
SIP
Business
Application
SIP
T-Library
SIP
SIP Server
Customer
Endpoint
Agent
Endpoint
RTP
Figure 5: Media Server Deployment Architecture
Call Scenario
1. A call arrives and is established with a contact center agent. SIP Server operates as a SIP B2BUA and maintains two separate SIP dialogs, one for the customer and one for the agent. The RTP stream is negotiated between the customer and agent endpoints directly, using the codec. SIP Server provides flexibility with manipulation of SDP information.
2. The agent invokes a call-hold operation either by using a
THoldCall
request to SIP Server, or by pressing the
Hold
button on the endpoint.
3. SIP Server selects a media server in sequence from among all configured servers with the same priority, and then establishes a new SIP dialog to the music server. SIP Server then sends the
INVITE message to the customer session to connect the RTP stream to the music server, and then re-
INVITEs the agent session to stop RTP traffic from it.
4. When the agent invokes a call-retrieve operation either by using the
TRetrieveCall
request, or by pressing the
Retrieve
button on the endpoint,
SIP Server terminates the music dialog by sending a
BYE
message, and then re-
INVITEs
the customer session to connect the RTP stream with the agent endpoint.
SIP Server—Deployment Guide 43
Chapter 1: SIP Server Fundamentals Redundant SIP Servers (High Availability)
Redundant SIP Servers (High Availability)
SIP Servers can operate in a high-availability (HA) environment, providing you with redundant systems. One basic principle of redundant SIP Servers is the standby redundancy type, which dictates how quickly a backup SIP Server steps in when the primary SIP Server goes down. The Framework
Management Layer currently supports two types of redundant configurations: warm standby
and hot standby
.
SIP Server in an HA configuration differs from most Genesys T-Servers in the role it performs in the SIP network. It is not a switch, but it does have traditional switching capabilities.
Supported HA Configuration Models
There are several options available for setting up a high-availability SIP Server deployment. Each approach has benefits and drawbacks. For more information about the different HA models, as well as detailed configuration information, see the
Framework 8.1 SIP Server High-Availability Deployment Guide
.
Note:
If you have to stop SIP Server running in HA mode, you must first promote it to a backup role. Likewise, you must do this if you have to reboot or stop the host on which the primary SIP Server is running.
Load Balancing
Figure 6 illustrates a load-balancing architecture for situations in which the call
rate exceeds the capacity of a single SIP Server.
Customer
Endpoint
PSTN
Network SIP
Server
302 Moved
INVITE
INVITE
PSTN Gateway
SIP Server
SIP
Agent
Endpoint
SIP Server
SIP
Agent
Endpoint
SIP Server
SIP
Agent
Endpoint
Figure 6: SIP Server Sample Load-Balancing Configuration
44 Framework 8.1
Chapter 1: SIP Server Fundamentals Multi-Threaded Architecture
In this configuration, all inbound calls first arrive at the Network SIP Server, which performs all initial routing. The routing on the Network SIP Server is either direct to agents, or to the second tier of Routing Points on the SIP
Server.
Routing inbound calls directly to agents assumes the following:
•
Multiple TDM-to-VoIP gateways (or incoming SIP firewalls for pure VoIP calls) are deployed to provide sufficient call capacity.
•
Multiple SIP Servers are deployed.
•
One or more Network SIP Servers are deployed. Given the high throughput of a Network SIP Server, it is very likely that a single SIP
Server will be sufficient for most deployments.
•
Gateways are configured to send all calls to the Network SIP Servers. If multiple Network SIP Servers are required, you can partition gateways, so that they send calls to different SIP Servers; or you can configure each gateway to send calls to one of the Network SIP Servers, based, for example, on call origination or destination.
As a result, the following provides a generalized call flow:
1. Network SIP Servers communicate with Universal Routing Server (URS)
(not shown in Figure 6 on page 44
). URS selects an agent on one of the SIP
Servers by using real-time state information available from the SIP Servers via Stat Servers (not shown). URS responds to the Network SIP Server with the agent’s DN and the location name of the SIP Server.
2. Network SIP Server communicates the
ConnID
and attached data to the selected SIP Server. It then responds to the PSTN gateway with a
302 message containing the IP address and External Routing Point number on the destination SIP Server.
3. The gateway processes the
302
message, and then sends a new
INVITE message to the selected SIP Server.
4. SIP Server receives the
INVITE
message from the External Routing Point, matches the call, and reroutes it to the selected agent by means of Inter
Server Call Control (ISCC).
Multi-Threaded Architecture
The SIP Server application is made up of several internal modules that are able to run separately from one another, as individual threads in their own apartments, using internal interfaces to communicate. This multi-threaded organization allows SIP Server to take advantage of computers with multiple
CPUs. By running the modules in separate threads, SIP Server can execute different tasks in parallel, simultaneously across several CPUs. This parallel processing enables SIP Server to handle more calls over a given length of time, as the number of processors available in the system is increased.
SIP Server—Deployment Guide 45
Chapter 1: SIP Server Fundamentals Multi-Site Support
Multi-Threaded Versus Single-Threaded Mode
Starting in release 8.0.3, using the sip-link-type
configured to run in either multi-threaded mode, or as a single thread for backward compatibility.
If running in single-threaded mode, the SIP Server Main thread is responsible for processing T-Library requests, distributing Events, managing SIP calls, and processing SIP signaling. If running in multi-threaded mode, the Main thread functionality is split into three threads, each performing the following functions:
•
The T-Server thread processes T-Library requests and distributes Events
•
The Call Manager thread manages SIP calls and processes SIP signaling
(except
OPTIONS
messages)
•
The Service Checker thread performs Active Out-of-Service Detection
(
OPTIONS
messages)
In both single-threaded and multi-thread modes, SIP Server runs the following threads:
•
The SIP transport layer thread dispatches SIP messages
•
The Operational Information thread collects and reports statistics; performs
NIC monitoring
•
A number of auxiliary threads
Logging
By default, in multi-threaded mode SIP Server only logs messages from the
T-Library thread into a single log file. However, using the x-sip-log
option, you can configure SIP Server to create separate log files to handle messages from the other threads. Log messages from each separate thread do not mix
into a single file. For details, see “Multi-Threaded Logging” on page 290 .
Multi-Site Support
SIP Server, like any conventional T-Server, is built with the T-Server Common
Part that contains the ISCC component responsible for call data transfer between multiple sites. Currently, SIP Server supports the following ISCC transaction types: route, direct-notoken, direct-uui, pullback,
and reroute.
However,
direct-uui is supported only in a pure SIP environment.
For instructions on installing and configuring a multi-site environment,
including information on the ISCC features, please see Chapter 9, “Multi-Site
46 Framework 8.1
Chapter 1: SIP Server Fundamentals Next Steps
Next Steps
Now that you have gained a general understanding of the roles and features available in SIP Server, you are ready to learn how SIP Server is installed and configured. That information is presented in the next few chapters of this
Deployment Guide. So unless you are already familiar with SIP Server
deployment and operation procedures, continue with Chapter 2, “SIP Server
General Deployment,” on page 49 . Otherwise, you may want to proceed to
Chapter 5, “SIP Server Feature Support,” on page 99
, where you will find information about feature configurations that SIP Server supports.
SIP Server—Deployment Guide 47
Chapter 1: SIP Server Fundamentals Next Steps
48 Framework 8.1
Chapter
2
SIP Server General
Deployment
This chapter contains general information for the deployment, configuration, and installation of your SIP Server. You may have to complete additional configuration and installation steps specific to your SIP Server and devices.
You will find these steps in Part One of this document.
This chapter contains the following sections:
Network Considerations, page 54
Deployment of SIP Server, page 57
Note:
You must read the
Framework 8.1 Deployment Guide
before proceeding with this SIP Server guide. That document contains information about the Genesys software you must deploy before deploying SIP Server.
Prerequisites
SIP Server has a number of prerequisites for deployment. Read through this section before deploying your SIP Server.
SIP Server—Deployment Guide 49
Chapter 2: SIP Server General Deployment Prerequisites
Software Requirements
Framework Components
You can only configure SIP Server after you have deployed the Configuration
Layer of Genesys Framework. This layer contains DB Server, Configuration
Server, and Configuration Manager. If you intend to monitor or control SIP
Server through the Management Layer, you must also install and configure components of this Framework layer, such as Local Control Agent (LCA),
Message Server, Solution Control Server (SCS), and Solution Control
Interface (SCI), before deploying SIP Server.
Refer to the Framework 8.1 Deployment Guide for information about, and deployment instructions for, these Framework components.
Media Layer and LCA
To monitor the status of components in the Media Layer through the
Management Layer, you must load an instance of LCA on every host running
Media Layer components. Without LCA, Management Layer cannot monitor the status of any of these components. If you do not use the Management
Layer, LCA is not required.
Supported Platforms
Refer to the
Genesys Supported Operating Environment Reference Guide
for the list of operating systems and database systems supported in Genesys releases 8.x.
For UNIX-based (UNIX) operating systems, also review the list of patches
Genesys uses for software product builds, and upgrade your patch configuration if necessary. A description of patch configuration is linked to installation read_me.html
files for the Genesys applications that operate on
UNIX, and is available within the installation packages.
Guidelines for Deploying SIP Server on Various
Operating Systems
Genesys recommends running SIP Server on Windows or Linux operating systems. AIX and Solaris are also supported.
SIP Server must be run as a service or daemon in the background under an account with appropriate permissions. SIP Server requires permissions to access the network, network configuration, and file system.
SIP Server is started by LCA. On Windows, LCA runs as a service under the
“Local System” account. On all platforms, LCA is started as a service or daemon when the host starts. LCA must be configured to be restarted by the
50 Framework 8.1
Chapter 2: SIP Server General Deployment Prerequisites operating system if it is stopped or terminated. In some cases, when system settings are changed, LCA and then SIP Server must be restarted for the new settings to take effect. SIP Server inherits its permission from LCA.
The number of allowed network connections for the SIP Server process must be adequate or “unlimited.” This should take into account the requirements of other Genesys components, T-Library clients, and SIP Endpoints that communicate with SIP Server over TCP/IP.
The Windows 2003/2008 Server default configuration does not limit the number of open connections. Refer to the Microsoft documentation for details.
On Linux, AIX, and Solaris, the maximum number of open files/sockets for the SIP Server process must be set to an adequate value or “unlimited.” The ulimit
settings have effect only for the SIP Server process. A new shell must be forked and the desired limit set, and then SIP Server is started. Otherwise,
SIP Server inherits limits from the parent process (LCA).
On Linux, AIX, and Solaris, the maximum core file size and the maximum memory size of the process must be set to an adequate number. Genesys recommends at least 4 GB. See the respective documentation about the ulimit parameter.
Hardware and Network Environment Requirements
Hosting
Genesys recommends that you or your IT specialist assign host computers to
Genesys software before you start Genesys installation. Remember the following restrictions:
•
Do not install all the Genesys server applications on the same host computer.
•
When installing a few server applications on the same host computer, prevent them (except for Configuration Server) from using the swap area.
Installation Privileges
During deployment, be sure to log in with an account that will permit you to perform administrative functions—that is, one that has root privileges.
Server Locations
Refer to the “Network Locations for Framework Components” chapter of the
Framework 8.1 Deployment Guide
for recommendations on server locations.
SIP Server—Deployment Guide 51
Chapter 2: SIP Server General Deployment Prerequisites
Supported Platforms
Refer to the
Genesys Supported Media Interfaces Reference Manual
for the list of supported switch and PBX versions.
Licensing Requirements
All Genesys software is licensed—that is, it is not shareware. Genesys products are protected through legal license conditions as part of your purchase contract. However, the level of technical license-control enforcement varies across different solutions and components.
Before you begin to install SIP Server, remember that, although you may not have had to use technical licenses for your software when you deployed the
Configuration and Management Layers in their basic configurations, this is not the case with the Media Layer.
SIP Server requires seat-related DN technical licenses to operate even in its most basic configuration. Without appropriate licenses, you cannot install and start SIP Server. If you have not already done so, Genesys recommends that you install License Manager and configure a license file at this point. For complete information on which products require what types of licenses, and on the installation procedure for License Manager, refer to the Genesys Licensing
Guide.
The sections that follow briefly describe the T-Server/SIP Server license types.
Note:
Starting with release 7.2, the licensing requirements for T-Server
(including SIP Server) have changed from previous releases. Please read this section carefully and refer to the
Genesys Licensing Guide
for complete licensing information.
Licensing Basic Implementations
A standalone SIP Server serving a single site requires licenses to register all
DNs it monitors. DNs that agents use in day-to-day contact center operations, such as Extensions and ACD Positions, have to be registered using licenses that control agent seats.
Note:
Configure all seat DNs that agents use (Extensions and ACD Positions) in the Configuration Layer. This enables detailed call monitoring through Genesys reporting, and generally allows you to control access to individual DNs.
52 Framework 8.1
Chapter 2: SIP Server General Deployment Prerequisites
Licensing HA Implementations
SIP Servers operating with the hot standby
redundancy type require a special
CTI HA technical license, which allows for high-availability implementations, in addition to regular SIP Server licenses. Neither SIP Server in a redundant pair configured for hot standby
starts if this license is unavailable. Moreover, the primary and backup SIP Servers must use the same licenses to control the same pool of DNs. If your SIP Servers are configured with the hot standby redundancy type, order licenses for CTI HA support.
Licensing Multi-Site Implementations
SIP Servers performing multi-site operations require licenses that allow for such operations, in addition to regular SIP Server licenses. If some of your SIP
Servers are configured for multi-site routing while others are not, either order licenses for multi-site support for all SIP Servers or install an additional
License Manager to handle the SIP Servers involved in multi-site routing.
Note:
You do not need licenses for multi-site support if some SIP Server clients include the local location as the location
attribute value in their requests for routing within the same site.
Configuring License Files
You need a license to configure and install Media Layer components. Genesys recommends that, if you have not already done so, at this point you:
1. Install License Manager.
2. Configure license files.
Note:
If you use the
<port>@<server>
format when entering the name of the license server during installation, remember that some operating systems use
@
as a special character. In this case, the installation routine is unable to write license information for SIP Server to the
Configuration Layer or the run.sh
file. Therefore, when you use the
<port>@<server>
format, you must manually modify the command-line license parameter after installing SIP Server.
For information about which products require what types of licenses and for the installation procedure for License Manager, refer to the
Genesys Licensing
Guide
.
SIP Server—Deployment Guide 53
Chapter 2: SIP Server General Deployment Network Considerations
About Configuration Options
Configuring SIP Server is not a onetime operation. It is something you do at the time of installation and then in an ongoing way to ensure the continued optimal performance of your software. You must enter values for SIP Server configuration options on the
Options
tab of your SIP Server
Application
object in Configuration Manager or Genesys Administrator. The instructions for configuring and installing SIP Server that you see here are only the most rudimentary parts of the process. You must refer extensively to the configuration options chapters located in Part One and Part Two of this book.
Pay particular attention to the configuration options specific to SIP Server.
Configuration options common to all T-Servers, independent of switch type,
are described in Chapter 11, “T-Server Common Configuration Options,” on page 729
. SIP Server-specific configuration options are described in Chapter 7,
“SIP Server Configuration Options,” on page 443 . SIP Server also supports
unified Genesys log options, as described in the Chapter 10, “Common
Configuration Options,” on page 707 .
Options that configure values for the TSCP (T-Server Common Part) software in your SIP Server are common to all T-Servers. Options based on the SIP custom features apply to your SIP Server only. Familiarize yourself with both types of options. You will want to adjust them to accommodate your production environment and the business rules that you want implemented there.
Network Considerations
This section is for system administrators, contact center operations heads, and developers who are planning to deploy Genesys SIP Server.
Deploying SIP Server is similar in many ways to deploying other components of the Genesys Framework, with the significant exception that the voice signal is carried over the data network. This has serious implications for network planning and server sizing. The primary purpose of this section is to highlight the major planning and resource concerns you face in rolling out SIP Server, and to explain how it overlaps with the underlying data network. However, this section is not intended to be an exhaustive guide to network planning. Refer to the
Framework 8.1 Deployment Guide
for further help with Framework rollout.
The performance of SIP Server is directly linked to that of the underlying data network. It is essential that you perform a proper network audit to ensure that the data network has been properly sized and tuned for real-time (voice) packet transport. This section discusses the factors that affect overall performance of an IP-based configuration, and provides some general rules to follow when deploying SIP Server.
54 Framework 8.1
Chapter 2: SIP Server General Deployment Network Considerations
Voice Quality
The following factors have a direct impact on voice quality:
•
Network latency—Overall network delay.
To minimize network latency and ensure acceptable voice quality, you need to tune the network to prioritize real-time voice packets. There are various available schemes for prioritizing voice packets, depending on the
IP router vendor.
•
Packet loss—Voice packets that are dropped for various reasons (physical media error, timeout due to network congestion, and so on).
Packet loss is a function result of several factors, including network bandwidth.
•
Packet jitter—Variation in voice packet arrival times.
You can minimize packet jitter by using a jitter buffer at the endpoint device. As a general rule, you must set the buffer size to the maximum anticipated deviation from the typical interpacket emission time.
Other factors that influence voice quality include:
•
Packet misordering—Packets arrive in the wrong order (similar to packet loss).
•
Type of codec used—Codecs that do not compress the audio signal produce better voice quality but use greater bandwidth.
•
Silence suppression—Silence suppression can save bandwidth, but it can also impact voice quality.
Bandwidth Requirements
Determining the bandwidth requirements for the underlying data network is another critical step in achieving proper performance and voice quality.
Bandwidth requirements for a video connection are, of course, much higher.
Genesys recommends that you verify network performance and voice quality by conducting performance tests and measurements in a lab environment prior to production rollout.
For an IP/Ethernet network, two factors that affect bandwidth requirements are:
•
Codec used.
•
Protocol headers.
When estimating actual network bandwidth needs, you must also consider such factors as network efficiency and utilization.
Note:
Genesys recommends careful network planning to avoid conditions which result in excess latency or packet loss.
SIP Server—Deployment Guide 55
Chapter 2: SIP Server General Deployment Network Considerations
Remote Agent Configuration
SIP Server’s remote agent capabilities range from a single remote agent, to a group of remote agents in a branch office environment. The distributed nature of branch office and remote agent architectures adds to the complexity of network sizing and tuning.
Bandwidth and Network Tuning
Just as for local network deployment of a VOIP-based system, you must, if at all possible, allot proper bandwidth for voice communication and tune the underlying network for real-time media. Remote agents using a dial-up connection require greater bandwidth (at least 33 Kbps, with 56 Kbps recommended) because of the extra network overhead. This assumes use of the
G.723.1 codec, although some dial-up connections may accommodate G.729.
A Digital Subscriber Line (DSL) connection is a better alternative than a dialup connection. The choice of remote access method is important—avoid sending voice communication over an unmanaged data network, such as the public Internet, where voice quality cannot be guaranteed.
For a branch office environment, network bandwidth requirements depend on the number of agents. Again, wide-area network (WAN) connectivity to the corporate LAN must be tuned for real-time voice communications. You need to ensure that service-level agreements from your virtual private network
(VPN) provider give details of such requirements. End-to-end network latency must not exceed 250 msec.
Firewalls
This release of SIP Server provides no explicit support for Network Address
Translation (NAT). Genesys recommends using virtual private networks (such as PPTP) and ensuring that all agents are on the same network, without NAT translators between the agents and SIP Server.
56 Framework 8.1
Chapter 2: SIP Server General Deployment Deployment Sequence
Deployment Sequence
This is the recommended sequence to follow when deploying SIP Server.
Task Summary: SIP Server Deployment Sequence
Objective Related Procedures and Actions
1. Deploy Configuration Layer objects and ensure Configuration Manager or Genesys Administrator is running.
See the
Framework 8.1 Deployment
Guide
for details.
2. Deploy Network objects (such as
Host objects).
3. Deploy the Management Layer.
4. Deploy SIP Server.
5. Test your configuration and installation.
See the Framework 8.1 Deployment
Guide for details.
See the Framework 8.1 Deployment
Guide for details.
See “Deployment of SIP Server” on page 57
.
See Chapter 3, “Starting and Stopping
Note:
If, during the installation procedure for any of the Genesys applications, the script warns you that Configuration Server is unavailable and that the configuration cannot be updated, continue with the installation. Following the installation, you must complete the information on the
Start Info
tab to ensure that SIP Server will run.
Deployment of SIP Server
Deploying SIP Server manually requires that you configure a number of different objects in the Configuration Layer prior to setting up your SIP Server objects and then installing SIP Server. This section describes the manual deployment process.
Configuration of Telephony Objects
This section describes how to manually configure SIP Server telephony objects if you are using Configuration Manager. For information about configuring
SIP Server telephony objects using Genesys Administrator, refer to the
Framework 8.1 Genesys Administrator Help.
SIP Server—Deployment Guide 57
Chapter 2: SIP Server General Deployment Deployment of SIP Server
Recommendations
Genesys recommends registering (configuring) only those entities you plan to use in the current configuration. The more data there is in the Configuration
Database, the longer it takes for the CTI setup to start, and the longer it will take to process configuration data. Remember that adding configuration objects to the Genesys Configuration Database does not cause any interruption in contact center operation.
Depending on how much work is required to manually configure all applications and objects, consider registering more
Person
objects first, with a set of privileges that lets them perform configuration tasks.
Switching Offices
Your telephony network may contain many switching offices, but you should only configure those that are involved with customer interactions.
Using Configuration Manager, be sure to register a
Switching Office object of type
SIP Switch
that accommodates your
Switch
object under
Environment.
Until you have done this, you cannot register a
Switch
object under
Resources
(single-tenant environment) or a
Tenant
(multi-tenant environment).
Note:
The value for the switching office name must not have spaces in it.
Switches
1. Configure a
Switch
object for each switch on your telephony network.
Assign each
Switch
object to the appropriate SIP Server
Application object.
2. If implementing the multi-site configuration, specify access codes for all switches on the network so that the call-processing applications can route and transfer calls between switches.
Two types of access codes exist in a Genesys configuration:
Default access codes that specify how to reach this switch from any other switch in the Genesys environment.
Switch-to-switch access codes that specify how to reach a particular switch from any other switch. Use this type when either a nondefault dial number or routing type is required between any two locations.
When a switch-to-switch access code is configured, its value has a higher priority than that of a default access code.
See Chapter 9, “Multi-Site Support,” on page 647 , for step-by-step
instructions.
58 Framework 8.1
Chapter 2: SIP Server General Deployment Deployment of SIP Server
Note:
When the numbering plan uses unique directory number (DN) assignment across sites and multi-site routing is not used, you do not have to configure access codes.
DNs and Agent Logins
For each SIP Server for which you are configuring DNs, you must configure all DNs that agents and their supervisors use in day-to-day contact center operation—so-called seat-related DNs—such as Extensions and ACD
Positions. Otherwise, SIP Server does not register such DNs.
1. To configure telephony objects within each switch, consult the switch documentation. For configuration information specific to your SIP devices,
see Chapter 4, “SIP Devices Support,” on page 73
.
2. Check the numbering plan for different types of DNs, to see if you can save time by registering Ranges of DNs. Usually, DNs of the same type have consecutive numbers, which will make an otherwise tedious configuration task easy.
Agent Login
objects almost always have consecutive numbers, which means you can register them through the
Range of Agent Logins feature as well.
3. If you plan to use Virtual Queues and Virtual Routing Points in the contact center operation, Genesys recommends registering them after you have outlined the call-processing algorithms and identified your reporting needs.
Note:
Remember that CTI applications, not the switch, generate telephony events for DNs of these types.
Multi-Site Operations
See the section, “Configuring Multi-Site Support” on page 691 , for
information on setting up DNs for multi-site operations.
Configuration of SIP Server
Use the Framework 8.1 Deployment Guide to prepare accurate configuration information. You may also want to consult Configuration Manager Help or and/or Genesys Administrator Help, which contains detailed information about configuring objects
Recommendations
Genesys recommends using an Application Template when you are configuring your SIP Server application. The Application Template for SIP
Server contains the most important configuration options set to the values
SIP Server—Deployment Guide 59
Chapter 2: SIP Server General Deployment Deployment of SIP Server recommended for the majority of environments. When modifying configuration options for your SIP Server application later in the process, you can change the values inherited from the template rather than create all the options by yourself.
Procedure:
Configuring SIP Server
Start of procedure
1. Follow the standard procedure for configuring all
Application
objects to begin configuring your SIP Server
Application
object. Refer to the
Framework 8.1 Deployment Guide for instructions.
2. In a multi-tenant environment, specify the
Tenant
to which this SIP Server belongs on the
General
tab of the
Properties
dialog box.
3. On the
Connections
tab, add all Genesys applications to which SIP Server must connect.
Note:
For multi-site deployments, you should also specify SIP Server connections on the
Connections tab for any SIP Servers that may transfer calls directly to each other.
4. On the
Options
tab, specify values for configuration options as appropriate for your environment.
Note:
For SIP Server option descriptions, see Chapter 7, “SIP Server
Configuration Options,” on page 443 . The configuration options
common to all T-Servers are described in the Chapter 11, “T-
Server Common Configuration Options,” on page 729 chapter. SIP
Server also uses common Genesys log options, described in the
Chapter 10, “Common Configuration Options,” on page 707 .
5. In a multi-site environment, you must complete additional SIP Server
configuration steps to support multi-site operations; see Chapter 9, “Multi-
End of procedure
Next Steps
•
See “Installation of SIP Server” on page 61 .
60 Framework 8.1
Chapter 2: SIP Server General Deployment Deployment of SIP Server
Installation of SIP Server
The following directories on the Genesys 8.1 SIP Server product CD contain
SIP Server installation packages:
•
SIP_Server/<component>/<platform>
for UNIX installations, where
<component>
is SIP Server, and
<platform>
is your operating system.
•
SIP_Server\<component>\windows
for Windows installations, where
<component>
is SIP Server.
Procedure:
Installing SIP Server on UNIX
Note:
During installation on UNIX, all files are copied into the directory you specify. No additional directories are created within this directory.
Therefore, do not install different products into the same directory.
Start of procedure
1. In the directory to which the SIP Server installation package was copied, locate a shell script called install.sh.
2. Run this script from the command prompt by typing sh
and the file name.
For example: sh install.sh.
3. When prompted, confirm the host name of the computer on which SIP
Server is to be installed.
4. When prompted, specify the host and port of Configuration Server.
5. When prompted, enter the user name and password to access Configuration
Server.
6. When prompted, select the SIP Server application you configured in
“Configuring SIP Server” on page 60 from the list of applications.
7. Specify the destination directory into which SIP Server is to be installed, with the full path to it.
8. If asked which version of the product to install, the 32-bit or the 64-bit, choose the one appropriate to your environment.
9. Specify the license information that SIP Server is to use: either the full path to, and the name of, the license file, or the license server parameters.
10. As soon as the installation process is finished, a message appears announcing that installation was successful. The process places SIP Server in the directory with the name specified during the installation.
End of procedure
SIP Server—Deployment Guide 61
Chapter 2: SIP Server General Deployment Deployment of SIP Server
Next Steps
•
To verify manual installation, go to “Verifying the installation of SIP
.
•
To test your configuration and installation, go to Chapter 3, “Starting and
Stopping SIP Server,” on page 65
, and try it out.
•
To configure and install redundant SIP Servers, see “Redundant SIP
Servers (High Availability)” on page 44 .
•
To install SIP Servers for a multi-site environment, proceed to Chapter 9,
“Multi-Site Support,” on page 647 .
Procedure:
Installing SIP Server on Windows
Start of procedure
1. In the directory to which the SIP Server installation package was copied, locate and double-click
Setup.exe
to start the installation.
2. When prompted, specify the connection parameters to the Configuration
Server associated with this SIP Server.
3. When prompted, select the SIP Server
Application
object you configured
in “Configuring SIP Server” on page 60
from the list of applications.
4. Specify the license information that SIP Server is to use: either the full path to, and the name of, the license file, or the license server parameters.
5. Specify the destination directory into which SIP Server is to be installed.
6. Click
Install
to begin the installation.
7. Click
Finish
to complete the installation.
By default, SIP Server is installed as a Genesys service (Windows
Services
) with
Automatic
startup type.
End of procedure
Next Steps
•
To verify manual installation, go to “Verifying the installation of SIP
.
•
To test your configuration and installation, go to Chapter 3, “Starting and
Stopping SIP Server,” on page 65
, and try it out.
•
To configure and install redundant T-Servers, see “Redundant SIP Servers
(High Availability)” on page 44
.
•
To install SIP Servers for a multi-site environment, proceed to Chapter 9,
“Multi-Site Support,” on page 647 .
62 Framework 8.1
Chapter 2: SIP Server General Deployment Next Steps
Procedure:
Verifying the installation of SIP Server
Purpose: To verify the completeness of the installation of SIP Server to ensure that SIP Server will run.
Prerequisites
•
Procedure: Installing SIP Server on UNIX, on page 61
•
Procedure: Installing SIP Server on Windows, on page 62
Start of procedure
1. Open the
Properties
dialog box for a corresponding
Application
object in
Configuration Manager.
2. Verify that the
State Enabled
check box on the
General
tab is selected.
3. Verify that the
Working Directory, command-line,
and
Command-Line
Arguments
are specified correctly on the
Start Info
tab.
4. Click
Apply
and
OK
to save any configuration updates.
End of procedure
Next Steps
At this point, you have configured and installed SIP Server. If you want to test
your configuration and installation, go to Chapter 3, “Starting and Stopping
, and try it out. Otherwise, if you want to configure and
install redundant SIP Servers, see “Redundant SIP Servers (High Availability)” on page 44
. If you want to install SIP Server for a multi-site environment,
proceed to Chapter 9, “Multi-Site Support,” on page 647
.
SIP Server—Deployment Guide 63
Chapter 2: SIP Server General Deployment Next Steps
64 Framework 8.1
Chapter
3
Starting and Stopping
SIP Server
This chapter describes methods for stopping and starting SIP Server, focusing on manual startup for SIP Server. It contains the following sections:
Command-Line Parameters, page 65
Starting and Stopping with the Management Layer, page 67
Starting with Startup Files, page 68
Verifying Successful Startup, page 70
Starting and Stopping with Windows Services Manager, page 72
Command-Line Parameters
You can start and stop Framework components using the Management Layer, a startup file, a manual procedure, or the Windows Services Manager.
With all these methods, command-line parameters are usually required for a server application in addition to an executable file name.
Common command-line parameters are as follows:
-host
-port
-app
The name of the host on which Configuration Server is running.
The communication port that client applications must use to connect to Configuration Server.
The exact name of an Application object as configured in the Configuration Database.
SIP Server—Deployment Guide 65
Chapter 3: Starting and Stopping SIP Server Command-Line Parameters
-l
-V
-nco X/Y
-lmspath
The license address. Use for the server applications that check out technical licenses. Can be either of the following:
• The full path to, and the exact name of, the license file used by an application. For example,
-l
/opt/mlink/license/license.dat
.
• The host name and port of the license server, as specified in the
SERVER
line of the license file, in the port@host format. For example,
-l 7260@ctiserver.
Note: Specifying the License Manager’s host and port parameter eliminates the need to store a copy of a license file on all computers running licensed applications.
The version of a Framework component. Note that specifying this parameter does not start an application, but returns its version number instead. You can use either uppercase or lowercase.
The Nonstop Operation feature is activated;
X
exceptions occurring within
Y
seconds do not cause an application to exit. If the specified number of exceptions is exceeded within the specified number of seconds, the application exits or, if so configured, the Management Layer restarts the application. If the
-nco
parameter is not specified, the default value of
6
exceptions handled in
10
seconds applies.
To disable the Nonstop Operation feature, specify
-nco 0 when starting the application.
The full path to log messages files (the common file named common.lms
and the application-specific file with the extension
*.lms
) that an application uses to generate log events. This parameter is used when the common and application-specific log message files are located in a directory other than the application’s working directory, such as when the application’s working directory differs from the directory to which the application is originally installed.
Note that if the full path to the executable file is specified in the startup command-line (for instance, c:\gcti\ multiserver.exe
), the path specified for the executable file is used for locating the
*.lms
files, and the value of the lmspath
parameter is ignored.
Note:
In the command-line examples in this document, angle brackets indicate variables that must be replaced with appropriate values.
66 Framework 8.1
Chapter 3: Starting and Stopping SIP Server Starting and Stopping with the Management Layer
Starting and Stopping with the
Management Layer
Procedure:
Configuring SIP Server to start with the Management
Layer
Start of procedure
1. Open the SIP Server
Application’s Properties
dialog box.
2. Click the
Start Info
tab.
3. Specify the directory where the application is installed and/or is to run as the
Working Directory
.
4. Specify the name of the executable file as the command-line
.
5. Specify command-line parameters as the
Command
–
Line Arguments
.
The command-line parameters common to Framework server components are described on
6. When you are finished, click
Apply
.
7. Click
OK
to save your changes and exit the
Properties
dialog box.
End of procedure
Note:
Before starting an application with the Management Layer, make sure the startup parameters of the application are correctly specified in the application’s
Properties
dialog box in Configuration Manager.
After its command-line parameters are correctly specified in the
Properties dialog box, you can start and stop SIP Server from Solution Control Interface
(SCI), which is the graphical interface component of the Management Layer.
(The starting procedure for SCI is described in the Framework 8.1 Deployment
Guide.) Framework 8.1 Solution Control Interface Help provides complete instructions on starting and stopping applications.
You can also use the Management Layer to start a SIP Server that has failed.
To enable SIP Server’s auto-restart functionality, select the corresponding check box in the
Application’s Properties
dialog box.
Note that when you start (or restart) an application via the Management Layer, the application inherits environment variables from Local Control Agent
(LCA), which executes the startup command. Therefore, you must also set the
SIP Server—Deployment Guide 67
Chapter 3: Starting and Stopping SIP Server Starting with Startup Files environment variables required by the application for the account that runs LCA.
Warning!
Stopping an application via the Management Layer is not considered an application failure. Therefore, the Management
Layer does not restart applications that it has stopped unless an appropriate alarm condition and alarm reaction are configured for these applications.
Note:
If you have to stop SIP Server running in HA mode, you must first promote it to a backup role. Likewise, you must do this if you have to reboot or stop the host computer on which the primary SIP Server is running.
Starting with Startup Files
Startup files are files with the extension run.sh
(on UNIX) or startServer.bat
(on Windows), which installation scripts create and place into the applications’ directories during the installations. These files are created for all Framework server applications except:
•
Configuration Server (primary or backup) running on Windows.
•
Backup Configuration Server running on UNIX.
•
DB Server running on Windows.
•
LCA running on either Windows or UNIX.
When using a startup file, verify that the startup parameters the installation script inserted in the startup file are correct. Use the following instructions for
UNIX and Windows to start those application for which startup files are
created. See the appropriate sections in “Starting Manually” on page 69 to
identify which applications should be running for a particular application to start.
Procedure:
Starting SIP Server on UNIX with a startup file
Start of procedure
1. Go to the directory where an application is installed.
2. Type the following command line: sh run.sh
End of procedure
68 Framework 8.1
Chapter 3: Starting and Stopping SIP Server Starting Manually
Procedure:
Starting SIP Server on Windows with a startup file
Start of procedure
To start SIP Server on Windows with a startup file, use either of these methods:
•
Go to the directory where an application is installed and double-click the startServer.bat
icon.
Or
•
From the
MS-DOS
window, go to the directory where the application is installed and type the following command-line: startServer.bat
End of procedure
Starting Manually
When starting an application manually, you must specify the startup parameters at the command prompt, whether you are starting on UNIX or
Windows. At the command prompt, command-line parameters must follow the name of the executable file. On the
Shortcut
tab of the Program
Properties dialog box, command-line parameters must also follow the name of the executable file.
The command-line parameters common to Framework server components are
If an
Application
object name, as configured in the Configuration Database, contains spaces (for example,
T-Server Nortel
), the
Application
name must be surrounded by quotation marks in the command-line:
-app “T-Server Nortel”
Before starting SIP Server, be sure that the following components are running:
•
DB Server that provides access to the Configuration Database
•
Configuration Server
•
License Manager
SIP Server—Deployment Guide 69
Chapter 3: Starting and Stopping SIP Server Verifying Successful Startup
Procedure:
Starting SIP Server on UNIX manually
Start of procedure
◆
Go to the directory where SIP Server is installed, and type the following command-line: sip_server -host <Configuration Server host>
-port <Configuration Server port> -app <SIP Server Application>
-l <license address> -nco [X]/[Y]
End of procedure
Procedure:
Starting SIP Server on Windows manually
Start of procedure
◆
Start SIP Server from either the
Start
menu or the
MS-DOS
window. If you use the
MS-DOS
window, go to the directory where SIP Server is installed, and type the following command-line parameters: sip_server.exe -host <Configuration Server host>
-port <Configuration Server port> -app <T-Server Application>
-l <license address> -nco [X]/[Y]
End of procedure
Verifying Successful Startup
After executing the startup command, you might want to check whether it was successful.
If you used the Management Layer to start SIP Server, check whether Solution
Control Interface displays
Started
or
Service Unavailable
status for the corresponding application. Refer to the “Troubleshooting” section of the
Framework 8.1 Management Layer User’s Guide if the startup command does not result in either
Started
or
Service Unavailable
status for some period of time.
If you start your SIP Server with startup files or manually, and if you have configured logging to console or a log file, check the log for messages similar to the following:
•
SIP Server log file:
Link connected
70 Framework 8.1
Chapter 3: Starting and Stopping SIP Server Stopping Manually
Stopping Manually
The following stopping procedures apply to Genesys server applications, such as DB Server, Configuration Server, Message Server, Local Control Agent,
Solution Control Server, HA Proxy, T-Server, SIP Server, and Stat Server.
Procedure:
Stopping SIP Server on UNIX manually
Start of procedure
To stop a server application from its console window on UNIX, use either of these commands:
•
Ctrl+C
•
kill <process number>
End of procedure
Procedure:
Stopping SIP Server on Windows manually
Start of procedure
To stop a server application on Windows, use either of these commands:
•
To stop a server application from its console window on Windows, use the
Ctrl+C
command.
•
To stop a server application on Windows, use the
End Task
button on the
Windows
Task Manager
.
End of procedure
Note:
If you have to stop SIP Server running in HA mode, you must first promote it to a backup role. Likewise, you must do this if you have to reboot or stop the host on which the primary SIP Server is running.
SIP Server—Deployment Guide 71
Chapter 3: Starting and Stopping SIP Server Starting and Stopping with Windows Services Manager
Starting and Stopping with Windows
Services Manager
When starting an application installed as a Windows Service, make sure the startup parameters of the application are correctly specified in the
ImagePath
in the
Application
folder in the
Registry Editor
. The
ImagePath
must have the following value data:
<full path>\<executable file name> -service <Application Name as
Service> -host <Configuration Server host>
-port <Configuration Server port> -app <Application Name>
-l <license address> where the command-line parameters common to Framework server
components are described on page 65 and
-service
The name of the Application running as a Windows Service; typically, it matches the Application name specified in the
-app
command-line parameter.
Framework components installed as Windows Services with the autostart capability are automatically started each time a computer on which they are installed is rebooted.
You can start Framework components installed as Windows Services with the manual start capability with the
Start
button in
Services Manager.
Note:
Use the
Windows Services
window to change the startup mode from
Automatic
to
Manual
and vice versa.
Regardless of a component’s start capability, you can stop Framework components installed as Windows Services with the
Stop
button in
Services
Manager
.
Next Steps
This chapter concludes SIP Server general deployment. Refer to subsequent chapters in this guide for detailed reference information and any special procedural instructions that pertain to SIP Server.
72 Framework 8.1
Chapter
4
SIP Devices Support
This chapter presents reference information for configuring devices and the switch elements of SIP Server. It contains the following sections:
Configuring Devices and Services, page 76
Configuring Agent Logins, page 92
Configuring Stream Manager, page 92
Configuring Genesys Media Server, page 93
Overview
SIP devices that represent SIP endpoints are configured in Configuration
Manager or Genesys Administrator as the following DN types:
•
Extension
(or
ACD Position)
—An agent’s endpoint (SIP phone)
•
Trunk
—Any external number (for example, a gateway access number)
•
Trunk Group
—An internal DN (for example, used to represent GVP in
Outbound IP integrations)
Note:
For more information about the difference between
Trunk
and
Trunk Group
DNs, see “About Trunk and Trunk Group DNs” on page 75 .
•
Voice over IP Service
—SIP services (Stream Manager, Music-On-Hold server, Genesys Media Server, and so on)
•
Routing Point
—Used internally by SIP Server
•
ACD Queue
—Used internally by SIP Server
SIP Server—Deployment Guide 73
Chapter 4: SIP Devices Support Overview
Note:
DNs of type
External Routing Point
are also supported by SIP Server.
They are not specific to SIP Server and are used by the T-Server
Common Part (TSCP) component of SIP Server in a multi-site environment.
Table 1 contains cross-reference information on SIP devices and Genesys DN
types. Use this information to configure SIP devices properly in the
Configuration Layer.
Table 1: Device Type Cross Reference
SIP Device Type
Endpoints (SIP phones)
Routing Points
Genesys DN Type
Extension
(or
ACD Position)
Routing Point
ACD Queue
Note: SIP Server does not support
Routing Queue
DNs
Trunk
Gateway
SIP Proxy
SIP Server in a multi-site deployment
Voice Mail Service (Asterisk only)
MCU
Softswitch
Music servers
Treatment service
Recording service
Application service
MSML service
Voice over IP Service, with service type
set to mcu
Voice over IP Service, with service-type set to softswitch
Voice over IP Service, with service-type
set to music
Voice over IP Service, with service-type
set to treatment
Voice over IP Service, with service-type
set to recorder
Voice over IP Service, with service-type
set to application
Voice over IP Service
, with service-type
set to msml
.
74 Framework 8.1
Chapter 4: SIP Devices Support Overview
About Trunk and Trunk Group DNs
For SIP Server,
Trunk Group
DNs are a special class of an internal DN used to handle multiple calls—similar to regular
Trunk
DNs, but with the full range of
T-Library messaging needed to track internal call processing and generate reports.
Trunk
and T runk Group
DNs are not interchangeable. The way SIP Server selects the DN, the kind of reporting available to the DN, and the available features are all different.
When to Use Trunk DNs
Use
Trunk
DNs for external devices where:
•
The DN needs prefix-based dialing.
•
Active Out-of-Service Detection must be enabled.
•
The external device needs to be configured in a primary/backup model. In this case you can configure multiple
Trunk
DNs with the same prefix but
set to different priority. For details, see “Working with Multiple Devices” on page 394 .
When to Use Trunk Group DNs
Use
Trunk Group
DNs to represent an internal module or process that requires full T-Library messaging and reporting.
Typically,
Trunk Group
DNs are used in integrations with other Genesys products or solutions, and the documentation for that product would make it clear when this configuration is required. For example,
Trunk Group
DNs are used to represent GVP in Outbound IP integrations, where T-Library requests must be made on behalf of the DN. This functionality is available only with internal DNs.
Note:
Regular GVP integrations for inbound calls use
Trunk
DNs.
Usage Guidelines
Table 2 highlights the main differences between these two types of DNs.
SIP Server—Deployment Guide 75
Chapter 4: SIP Devices Support Configuring Devices and Services
Table 2: Guidelines for Trunk and Trunk Group DNs
Trunk DNs Trunk Group DNs
• External
Trunk
DNs are used to represent external SIP devices, like gateways.
• Internal
Trunk Group
DNs are used to represent internal Genesys modules, like GVP in an Outbound IP integration.
• Limited T-Library messaging.
For example, as Trunks represent external devices,
EventRinging
and
EventEstablished
messages are not required.
• Full T-Library messaging.
This supports detailed reporting on internal call processing.
• Prefix-based DN selection.
SIP Server selects
Trunk
DNs based on the prefix
option.
• Name-based DN selection.
SIP Server selects
Trunk Group
DNs based on the name of the DN only.
• Full-featured.
Trunk
DNs can be configured for a range of features unavailable to
Trunk Group
DNs. For example,
Device selection algorithm
.
• Limited features.
The features available to
Trunk
Group
DNs are limited by design.
Configuring Devices and Services
This section describes how to configure the SIP device types for SIP Server environments. It contains the following sections:
•
“Configuring ACD Queues” on page 77
•
•
“Configuring Endpoints” on page 78
•
“Configuring Gateways” on page 81
•
“Configuring Music Servers” on page 83
•
“Configuring Routing Points” on page 85
•
“Configuring Softswitches” on page 85
•
“Configuring an Application Service” on page 87
•
“Configuring a Recording Service” on page 88
•
“Configuring a Treatment Service” on page 90
•
“Configuring an MSML Service” on page 91
76 Framework 8.1
Chapter 4: SIP Devices Support Configuring Devices and Services
Configuring ACD Queues
To configure ACD Queues, follow the provided procedure using Configuration
Manager.
Procedure:
Configuring an ACD Queue
Start of procedure
1. Under a configured
Switch object, select the
DNs
folder. From the
File menu, select
New > DN
to create a new
DN
object.
2. In the
New DN Properties
dialog box, on the
General
tab, specify the following properties:
a.
Number:
Enter the number of the configured DN. This value must be a dialable number on the switch. You must not use the @ symbol or a computer name when configuring this property.
b.
Type:
Select
ACD Queue from the drop-down box.
3. When you are finished, click
Apply
.
End of procedure
Configuring MCUs
To configure a Multipoint Conference Unit (MCU), follow the provided procedure using Configuration Manager.
Procedure:
Configuring an MCU
Start of procedure
1. Under a configured
Switch object, select the
DNs
folder. From the
File menu, select
New > DN
to create a new
DN
object.
2. In the
New DN Properties
dialog box, on the
General
tab, specify the following properties:
a.
Number:
Enter the MCU name. This name is used during SIP registration only if the MCU registers with the SIP registrar. If the
MCU does not register with the registrar, enter a short description of
MCU for this property
.
b.
Type:
Select
Voice over IP Service from the drop-down box.
3. Click the
Annex
tab.
SIP Server—Deployment Guide 77
Chapter 4: SIP Devices Support Configuring Devices and Services
4. Create a section named
TServer.
In the
TServer
section, create options as specified in
Table 3: Configuring an MCU
Option Name
Option Value
SIP URI
0
–
300
0
–
30
String
0
–
86400 seconds mcu
Description
Specifies the contact URI (Uniform Resource Indicator) that
SIP Server uses for communication with the MCU. See the
URI format and option description on
(Optional) Specifies how often (in seconds) SIP Server checks a device for out-of-service status.
See the option description on
(Optional) Specifies the time interval (in seconds) that SIP
Server waits before placing a device that does not respond in out-of-service
state when the oos-check
option is enabled.
See the option description on
(Optional) Specifies the starting digits of the number that are used when sending calls to MCU.
See the option description on
(Optional) Specifies whether an MCU is taken out of service when an error is encountered, and for how long it is out of service.
See the option description on
Set this option to mcu.
5. When you are finished, click
Apply
.
End of procedure
You can configure multiple MCUs. In this case, SIP Server distributes the load for all MCUs in a round-robin fashion.
Configuring Endpoints
To configure SIP endpoints, follow the provided procedure using
Configuration Manager.
Note:
In order to update the
DN
object, SIP Server must have
Full Control permission for it. By default, it does not have this permission. You must grant the
System
account
Full Control permission by changing the
Permissions
on the
DN s folder object in Configuration Manager.
78 Framework 8.1
Chapter 4: SIP Devices Support Configuring Devices and Services
Procedure:
Configuring endpoints
Start of procedure
1. Under a configured
Switch object, select the
DNs
folder. From the
File menu, select
New > DN
to create a new
DN
object.
2. In the
New DN Properties
dialog box, on the
General
tab, specify the following properties:
a.
Number:
Enter the username
part of the endpoint’s Address of Record
(AOR) as an alphanumeric string. You must not use the @ symbol or a computer name when configuring this property.
b.
Type:
Select
Extension
(or
ACD Position
) from the drop-down box.
3. Click the
Annex
tab.
4. Create a section named
TServer.
In the
TServer
section, create options as specified in
Table 4: Configuring Endpoints
Option Name
Option Values Description
register, invite
SIP URI
Specifies whether incoming SIP requests are treated with an authentication procedure under the following conditions:
1. The name of the incoming SIP message exists in the list of the authenticate-requests
parameter.
2. The option password
is configured on the same
DN object.
See the option description on page 552
.
(Optional, depends on the phone registration) Specifies the contact URI that SIP Server uses for communication with the endpoint. See the URI format and option description on
true, false
Set the value to false
for endpoints that accept only one active SIP dialog and for endpoints that can accept more than one SIP dialog but are not able to place the call on hold or retrieve it through the SIP
NOTIFY
request.
Set the value to false for Siemens optiPoint phones that are used in re-
INVITE
mode for third-party call control (3pcc) operations.
See the option description on page 566
.
SIP Server—Deployment Guide 79
Chapter 4: SIP Devices Support Configuring Devices and Services
Table 4: Configuring Endpoints (Continued)
Option Name
1, 2
Option Values Description
String
String
The geo-location
set on the
Extension
DN (or
ACD
Position
DN) is used to select the
Trunk
DN for outbound and consultation calls.
See the option description on page 573
.
Specifies which SIP call flow will be used when a call is initiated by the
TMakeCall request. Only flow 1 and flow 2 from RFC 3725 are currently supported.
See the option description on page 578
.
Specifies the password for SIP endpoint registration with the local registrar. If it is present, registration attempts are challenged, and the password is verified. If it is not present, the registration is not challenged.
The realm for password authentication is configured globally; there is one realm per SIP Server.
See the option description on page 587
.
true, false
Controls whether a device is taken out of service when an error is encountered, and for how long it is out-ofservice.
See the option description on page 591
.
true, false
true, false
SIP URI talk, hold
Specifies whether the
REFER method is sent to an endpoint. The recommended setting is true
.
See the option description on page 592
.
(Optional, for Genesys SIP Endpoints only) Specifies whether the endpoint is placed on hold by re-inviting it with the hold SDP.
See the option description on page 593
.
Specifies the value of the
Request-URI
address to be used in the
INVITE
message, if that address is different from the address where the message will be sent.
See the option description on page 594
.
Specifies the behavior of the DN representing the SIP endpoint that supports the BroadSoft SIP Extension
Event Package.
See the option description on page 602
.
5. When you are finished, click
Apply
.
End of procedure
80 Framework 8.1
Chapter 4: SIP Devices Support Configuring Devices and Services
Configuring Gateways
To configure gateways, follow the provided procedure using Configuration
Manager.
Procedure:
Configuring a gateway
Start of procedure
1. Under a configured
Switch object, select the
DNs
folder. From the
File menu, select
New > DN
to create a new
DN
object.
2. In the
New DN Properties
dialog box, on the
General
tab, specify the following properties:
a.
Number:
Enter the gateway name. This name is used only during SIP registration when the gateway registers with the SIP registrar. If the gateway does not register with the registrar, enter a short description of the gateway for this property.
b.
Type:
Select
Trunk
from the drop-down box.
3. Click the
Annex
tab.
4. Create a section named
TServer.
In the
TServer
section, create options as specified in
Table 5: Configuring a gateway
Option Name
Option Value
SIP URI
Description
Specifies the contact URI that SIP Server uses for communication with the gateway. See the URI format and option description on
Note: SIP Server selects a
Trunk
DN to represent the external party of an inbound call by matching the IP address from the
Via
header of the incoming
INVITE message to the host address of the contact
option of the
Trunk
DN. If there are more than one
Trunk
DNs with the same contact
matching the incoming
INVITE,
SIP Server may select any of these DNs. That means to work reliably, the set of options affecting further call flows must be the same on all of these DNs. This rule does not affect the prefix
option, because it is only involved into selection of the
Trunk
DN for outgoing calls.
SIP Server—Deployment Guide 81
Chapter 4: SIP Devices Support Configuring Devices and Services
Table 5: Configuring a gateway (Continued)
Option Name
Option Value
String
0
–
300
0
–
30
String
String
Any non-negative integer true, false
Description
(Optional) Specifies the
geo-location for a particular gateway. If the f ind-trunk-by-location
option on the
DN is enabled, SIP Server includes the geo-location attribute in the procedure that it uses to select an available gateway or trunk for an outbound call.
See the option description on page 573
.
(Optional) Specifies how often (in seconds) SIP Server checks a device for out-of-service status.
See the option description on page 581
.
(Optional) Specifies the time interval (in seconds) that
SIP Server waits before placing a device that does not respond in out-of-service
state when the oos-check option is enabled.
See the option description on page 582
.
(Optional) Specifies the password for gateway registration with the local registrar. This is used for incoming
REGISTER
requests, not for outgoing
INVITE requests.
See the option description on page 587
.
(Optional) Contains the initial characters of the number that must match a particular gateway for that gateway to be selected. If multiple gateways match the prefix, the gateway with the longest prefix that matches is selected.
See the option description on page 588
.
(Optional) Specifies a gateway priority when deciding a route—a smaller number designates higher priority. If more than one gateway with the same prefix is selected, the gateway with highest priority is normally selected.
This option is used to control primary-backup gateway switchover during a failure, and to provide lowest-cost routing.
See the option description on page 589
.
Specifies whether the
REFER method is sent to an endpoint. The recommended setting is true
.
See the option description on page 592
.
82 Framework 8.1
Chapter 4: SIP Devices Support Configuring Devices and Services
Table 5: Configuring a gateway (Continued)
Option Name
Option Value
0
–
86400 seconds
Digit string
Description
(Optional) Specifies whether a gateway is taken out of service when an error is encountered, and for how long it is out-of-service.
See the option description on page 591
.
(Optional) Specifies the characters that are inserted in the
DN instead of the prefix for the gateway. If this annex is empty or absent, the initial characters that match the prefix
option will be removed from the DN.
See the option description on page 594
.
5. When you are finished, click
Apply
.
End of procedure
Configuring Music Servers
To configure external music servers, follow the provided procedure using
Configuration Manager.
Procedure:
Configuring a Music Server
Start of procedure
1. Under a configured
Switch object, select the
DNs
folder. From the
File menu, select
New > DN
to create a new
DN
object.
2. In the
New DN Properties
dialog box, on the
General
tab, specify the following properties:
a.
Number:
Enter the Music Server name. This name is used only during
SIP registration if the Music Server registers with the SIP registrar. If the music server does not register with the registrar, enter a short description of the Music Server for this property.
b.
Type:
Select
Voice over IP Service
from the drop-down box.
3. Click the
Annex
tab.
4. Create a section named
TServer.
In the
TServer
section, create options as specified in
SIP Server—Deployment Guide 83
Chapter 4: SIP Devices Support Configuring Devices and Services
Table 6: Configuring a Music Server
Option Name
Option Values
SIP URI
String
0
–
300
0
–
30
0
–
86400 seconds
SIP URI
Description
Specifies the contact URI that SIP Server uses for communication with the music server. See the URI format and option description on
(Optional) Specifies the geo-location
attribute that SIP
Server uses to select a particular music service in load balancing scenarios. SIP Server will consider those
Voice over IP Service
DNs whose configured geo-location matches the preferred geo-location assigned for the call.
See the option description on
(Optional) Specifies how often (in seconds) SIP Server checks a device for out-of-service status.
See the option description on
(Optional) Specifies the time interval (in seconds) that
SIP Server waits before placing a device that does not respond in out-of-service
state when the oos-check option is enabled.
See the option description on
(Optional) Specifies whether a music server is taken out of service when an error is encountered, and for how long it is out of service.
See the option description on
Specifies the value of the
Request-URI
address to be used in the
INVITE
message, if that address is different from the address where the message will be sent.
See the option description on
Set this option to music
or moh
.
music or moh
5. When you are finished, click
Apply
.
End of procedure
84 Framework 8.1
Chapter 4: SIP Devices Support Configuring Devices and Services
Configuring Routing Points
To configure routing points, follow the provided procedure using
Configuration Manager.
Procedure:
Configuring Routing Points
Start of procedure
1. Under a configured
Switch object, select the
DNs
folder. From the
File menu, select
New > DN
to create a new
DN
object.
2. In the
New DN Properties
dialog box, on the
General
tab, specify the following properties:
a.
Number:
Enter the numeric-only DN number that is easily dialed directly from a phone keypad. You must not use the @ symbol or a computer name when configuring this property.
b.
Type:
Select
Routing Point
from the drop-down box.
Note:
SIP Server does not support the use of
Routing Queue
DNs when configuring the SIP Routing Point device.
3. When you are finished, click
Apply
.
End of procedure
Configuring Softswitches
If you deploy proxies or softswitches between SIP Server and any internal DNs or agent endpoints, configure the proxies or softswitches using the provided procedure in Configuration Manager.
Procedure:
Configuring softswitches
Start of procedure
1. Under a configured
Switch object, select the
DNs
folder. From the
File menu, select
New > DN
to create a new
DN
object.
SIP Server—Deployment Guide 85
Chapter 4: SIP Devices Support Configuring Devices and Services
2. In the
New DN Properties
dialog box, on the
General
tab, specify the following properties:
a.
Number:
Enter the softswitch server name. This name is currently not used for any messaging, but it must still be unique. Enter a short description for this property.
b.
Type:
Select
Voice over IP Service
from the drop-down box.
3. Click the
Annex
tab.
4. Create a section named
TServer.
In the
TServer
section, create options as specified in
Table 7: Configuring Softswitches
Option Name
Option Value Description
SIP URI Specifies the contact URI that SIP Server uses for communication with the softswitch. On some softswitches this is the same as the public IP address used by endpoints to contact the softswitch. However, other softswitches require a separate port. See the URI format and option description on
Note: To resolve the contact SIP URI through DNS/SRV request, you must configure Active Out-of-Service detection on
this DN. See “DNS Name Resolution” on page 232
.
String
String
IP address
(Optional) Contains the initial characters of the number that must match a particular softswitch for that softswitch to be selected. If multiple softswitches match the prefix, the softswitch with the longest prefix that matches is selected.
This setting ensures that all resources that belong to this softswitch will have numbers starting with the same digits. This allows SIP Server to select the softswitch (contact) so that
INVITE
requests can reach DNs behind the softswitch for inbound calls and 3pcc operations.
See the option description on
(Optional) Specifies the geo-location
attribute that SIP Server uses to select trunks for outbound and consultation calls, as well as to determine the softswitch object to be selected to send the call to a DN for inbound calls.
See the option description on
Contains the public host:port
pair for a softswitch. This is the public IP address of the softswitch. SIP Server uses this address to fill the destination (
Refer-To
) address in
REFER
requests.
On some switches, this is the same as the contact
address; if this is the case, you do not need to specify this parameter.
See the option description on
86 Framework 8.1
Chapter 4: SIP Devices Support Configuring Devices and Services
Table 7: Configuring Softswitches (Continued)
Option Name
Option Value Description
softswitch
Integer
Set this option to softswitch.
(Optional) Set this option to enable DNS name resolution for
this DN using SRV records. See “DNS Name Resolution” on page 232
.
For the option value, enter how often (in seconds) you want SIP
Server to check the availability of this DN
.
5. When you are finished, click
Apply
.
End of procedure
Additional Information
You can configure multiple softswitches in either an active load-balancing configuration or in a primary-standby configuration. For load-balancing, define services with the same priority to each service. For the primary-standby configuration, give higher priority to the primary service entry.
Configuring an Application Service
To configure an application service, follow the provided procedure using
Configuration Manager.
Procedure:
Configuring an application service
Start of procedure
1. Under a configured
Switch object, select the
DNs
folder. From the
File menu, select
New > DN
to create a new
DN
object.
2. In the
New DN Properties
dialog box, on the
General
tab, specify the following properties:
a.
Number:
Enter the treatment server name.
b.
Type:
Select
Voice over IP Service
from the drop-down box.
3. Click the
Annex
tab.
4. Create a section named
TServer.
In the
TServer
section, create options as specified in
SIP Server—Deployment Guide 87
Chapter 4: SIP Devices Support Configuring Devices and Services
Table 8: Configuring an Application Service
Option Name Option Values Description
SIP URI application
Specifies the contact URI that SIP Server uses for communication with the treatment server. See the URI format and option description on
Set this option to application.
5. When you are finished, click
Apply
.
End of procedure
Configuring a Recording Service
To configure a recording service, follow the provided procedure using
Configuration Manager.
Note:
To configure a recording service DN for use with Genesys Media
Server, consult the
Genesys Media Server Deployment Guide
.
Procedure:
Configuring a recording service
Start of procedure
1. Under a configured
Switch object, select the
DNs
folder. From the
File menu, select
New > DN
to create a new
DN
object.
2. In the
New DN Properties
dialog box, on the
General
tab, specify the following properties:
a.
Number:
Enter the recorder server name.
b.
Type:
Select
Voice over IP Service
from the drop-down box.
3. Click the
Annex
tab.
4. Create a section named
TServer.
In the
TServer
section, create options as specified in
88 Framework 8.1
Chapter 4: SIP Devices Support Configuring Devices and Services
Table 9: Configuring a Recording Service
Option Name
Option Value Description
SIP URI Specifies the contact URI that SIP Server uses for communication with the recorder server. See the URI format
and option description on page 557
.
SIP URI recorder
For emergency recording:
1. Specifies the value of the
Request-URI
address to be used in the
INVITE
message, if that address is different from the address where the message will be sent.
Note: This value is only used for emergency call
recording, used in conjunction with emergencyrecording-filename
2. (Optional) You can also append the Request-URI with the following sub-string: record=<directory>
You can use this to specify a particular directory or name for the recording file. For example,
record=recs/
saves the recording file to the directory recs
, with the filename taken from the configuration option.
See the option description on page 594
.
Set this option to recorder.
5. When you are finished, click
Apply
.
End of procedure
Additional Information
SIP Server can also record a file name when emergency recording is initiated
by an agent. See the emergency-recording-filename
configuration option for more information.
SIP Server—Deployment Guide 89
Chapter 4: SIP Devices Support Configuring Devices and Services
Configuring a Treatment Service
To configure a treatment service, follow the next procedure using
Configuration Manager.
Procedure:
Configuring a treatment service
Start of procedure
1. Under a configured
Switch object, select the
DNs
folder. From the
File menu, select
New > DN
to create a new
DN
object.
2. In the
New DN Properties
dialog box, on the
General
tab, specify the following properties:
a.
Number:
Enter the treatment server name.
b.
Type:
Select
Voice over IP Service
from the drop-down box.
3. Click the
Annex
tab.
4. Create a section named
TServer.
In the
TServer
section, create options as specified in
.
Table 10: Configuring a Treatment Service
Option Name Option Values Description
SIP URI Specifies the contact URI that SIP Server uses for communication with the treatment server. See the URI format and option description on
treatment
Set this option to treatment.
5. When you are finished, click
Apply
.
End of procedure
90 Framework 8.1
Chapter 4: SIP Devices Support Configuring Devices and Services
Configuring an MSML Service
To configure an MSML service, follow the provided procedure using
Configuration Manager.
Procedure:
Configuring an MSML Service
Start of procedure
1. Under a configured
Switch object, select the
DNs
folder. From the
File menu, select
New > DN
to create a new
DN
object.
2. In the
New DN Properties
dialog box, on the
General
tab, specify the following properties:
a.
Number:
Enter the MSML server name.
b.
Type:
Select
Voice over IP Service
from the drop-down menu.
3. Click the
Annex
tab.
4. Create a section named
TServer.
In the
TServer
section, create options as specified in
Table 11: Configuring an MSML Service
Option Name
Option Value Description
SIP URI Set this option to the Resource Manager IP address and port. Use the following format: sip: <RM_IP_address:RM_SIP_port>
Specifies the contact URI that SIP Server uses for communication with the treatment server. See the URI
format and option description on page 557
.
msml msml=
Set this option to msml
.
(Optional) Required for conference and monitoring services only.
Set this option to msml=
.
Name of SIP
Server tenant
Set this option to the name of the Tenant to which SIP
Server switch belongs.
For a single-tenant deployment, set this option to
Environment
.
See the option description on page 615
.
SIP Server—Deployment Guide 91
Chapter 4: SIP Devices Support Configuring Agent Logins
Table 11: Configuring an MSML Service (Continued)
Option Name Option Value Description
Required for Outbound Solution only
(to support MakePredictiveCall—Genesys Media Server functionality is not affected)
false
Set this option to false
.
See the option description on page 592
.
1
false
mediaserver
For MSML service, set this option to
1
.
Specifies which SIP call flow will be used when a call is initiated by the
TMakeCall request. Only flow 1 and flow 2 from RFC 3725 are currently supported.
See the option description on page 578
.
Set this option to false.
To enable call progress detection using the Genesys Media
Server, set this option to mediaserver
.
5. When you are finished, click
Apply
.
End of procedure
Configuring Agent Logins
SIP Server can work either with softswitches or in stand-alone mode, in which the SIP endpoint communicates directly with SIP Server. In both scenarios, you must configure the
Switch
object in the Configuration Layer. The manner in which you configure your SIP Server must reflect the properties of all the objects that your SIP Server monitors. If a client issues a
TRegisterAddress request for a DN that is not configured in Configuration Manager, SIP Server will generate an
EventError
message.
Because only SIP Server uses agent logins, they do not need to match user information on the softswitch. SIP Server manages the status of agents who use these logins, and allows these agents to log in to the SIP addresses.
Configuring Stream Manager
Stream Manager is a Genesys client application that streams media files in order to provide announcements and music to callers queued on Routing Points and ACD queues. It can also serve as a music server or as an MCU. SIP Server does not need Stream Manager for normal call handling.
92 Framework 8.1
Chapter 4: SIP Devices Support Configuring Genesys Media Server
You configure Stream Manager as a
DN
object of type
Voice over IP service, with the service-type
option set in the
TServer
section on the
Annex tab. The values are: music, mcu, treatment, conference, and recorder.
To use Stream Manager as a music server, it must be configured as described in
“Configuring Music Servers” on page 83
.
Location of Media Files
Stream Manager must be able to access the audio files that SIP Server requests to play. These files are located in subdirectories of the installed Stream
Manager root directory. The files must be in the appropriate codec format, with the filename suffix corresponding to the codec type. All Stream Managers integrated with SIP Server must contain the same announcement/music files in the same directory structure. The treatment will fail if the file does not exist in the specified directory.
Load Balancing of Media Services
When SIP Server performs load balancing of media services across multiple instances of Stream Manager, if a service fails to start at a particular instance of
Stream Manager, SIP Server tries the next instance; however, if the service cannot start on any of the instances, the call fails permanently. To avoid looping or network overload, SIP Server does not retry any instance of Stream
Manager where the service has previously failed.
Determining Codecs
If you are using a gateway, you must determine the codec it uses before you determine which codec is specified in Genesys.
See the
Framework 7.6 Stream Manager Deployment Guide
for more information about Stream Manager.
Configuring Genesys Media Server
When integrated with SIP Server, the Genesys Media Server provides Real-
Time Protocol (RTP) streaming for a variety of media services—treatments, conferences, call recording, and so on—using the Media Server Markup
Language (MSML).
About Genesys Media Server
The Genesys Media Server is a module that provides MSML-based media services offered by the Genesys Voice Platform, as well as NETANN-based services for requests coming in from the network. When integrated with SIP
SIP Server—Deployment Guide 93
Chapter 4: SIP Devices Support Configuring Genesys Media Server
Server, it supports the same set of features that were previously provided by
Genesys Stream Manager (7.x). In addition to these features, Genesys Media
Server also supports new codec formats for voice delivery associated with outbound calling, call parking, call recording, conferencing, and IVR prompting.
MSML-Based Media Services
When enabled for MSML, SIP Server responds to a media service request by sending an
INVITE
message first, to establish a connection with the media server, then an
INFO
message to start the particular service, such as treatment or conference.
Requests from the Network
For NETANN-based requests for media services coming in from the network, the incoming
INVITE
contains a URI that specifies the kind of media service required for the call. SIP Server forwards this request in the
INVITE
to Genesys
Media Server, which can then provide the service for the call. This functionality can be used for network requests for announcements, conferences, and other NETANN-based media services.
Load Balancing of Media Servers
SIP Server performs load balancing of media services across multiple instances of Media Server (Resource Manager and an MCP farm). If a service does not start at a particular instance of Media Server, SIP Server tries the next instance of Media Server.
Media Server Reliability
SIP Server uses the SIP
SUBSCRIBE
/
NOTIFY
model for monitoring active MCP instances, and reconnecting ongoing media services in case a particular MCP
instance becomes unavailable. For more information, see “Media Server
Reliability—NETANN/MSML” on page 286 .
Geo-Location
SIP Server is able to send geo-location information so that the GVP Resource
Manager can select the closest Media Server instance to the caller.
For More Information
For more information about the Media Server, see the
Genesys Media Server
Deployment Guide
.
94 Framework 8.1
Chapter 4: SIP Devices Support Configuring Genesys Media Server
SIP Server and Media Server Integration
A SIP Server deployment with Genesys Media Server includes the following components:
•
SIP Server
•
GVP Resource Manager
•
GVP Media Control Platform
SIP Server integrates with the Media Server using a
Voice over IP Service
DN with service-type
set to msml
. Only one DN is required for all media services. SIP Server does not communicate directly with the Media Server
(MCP), but instead sends the msml service requests to Resource Manager, which then selects and manages the MCP independently from SIP Server. This allows for efficiencies in scalability and redundancy.
Genesys Media Server Integration
13 describe the required configuration to integrate SIP Server
with Genesys Media Server. Table 14 describes the steps to enable a ringing
period for predictive calls of greater than 32 seconds.
Table 12: Integrating Media Server for MSML
Objective Key Procedures and Actions
1. Configure SIP Server for
MSML.
In the
TServer
section of the SIP Server Application object, configure the following options:
•
true
.
•
—Set this option to true
.
2. Configure the MSML
DN.
1. Create a
Voice over IP Service
DN.
2. In the
TServer
section, configure the following options:
—Set to the RM IP address and port.
—Set to msml=
(Required for conferencing, call recording, and call monitoring)
—Set to msml
.
—Set to the name of the Tenant to which this DN belongs (used for reliability).
See Procedure: Configuring an MSML Service, on page 91 .
SIP Server—Deployment Guide 95
Chapter 4: SIP Devices Support Configuring Genesys Media Server
Table 12: Integrating Media Server for MSML (Continued)
Objective
3. Configure GVP components.
4. Configure an MCP resource group for
MSML services.
5. Configure Resource
Manager application.
6. Create a default IVR
Profile.
Key Procedures and Actions
Configure the following GVP components to their default settings:
• Resource Manager
• Media Control Platform
Note: SIP Server and Resource Manager use the same port
5060
. If both are deployed on the same host, you may have to change port numbers to avoid conflicts. Genesys suggests shifting the port numbers in the
Resource Manager options up by 100—from
5060-5067
to
5160-5167
.
For more information, see the Genesys Media Server 8.1 Deployment
Guide.
1. Create a resource group for the MCP instances that will be used to provide MSML service.
2. Configure the resource group with the following minimum mandatory options:
load-balance-scheme
—Set to round-robin
.
monitor-method
—Set to option
.
port-usage-type
—Set to
in-and-out
.
resource-confmaxsiz e—Set to
-1
.
service-type s—Ensure that msml
is included in the list of servicetypes.
For more information, see the Genesys Media Server 8.1 Deployment
Guide.
• In the rm
section, configure the following parameters:
conference-sip-error-respcode
—Set to
503
.
resource-unavailable-respcode
—Set to
603
.
• In the monitor section, configure the following parameter:
sip.proxy.releaseconfonfailure
—Set to false
.
Create a new IVR Profile to be used as the default for your particular tenant.
1. In the
Voice Platform Profiles folder, create a new
GVP IVRProfile
.
2. On the
Annex
tab of the IVR Profile, create a gvp.general
section, adding the following options:
service-type
—Set to voicexml
.
For more information, see the Genesys Media Server 8.1 Deployment
Guide.
96 Framework 8.1
Chapter 4: SIP Devices Support Configuring Genesys Media Server
Table 12: Integrating Media Server for MSML (Continued)
Objective
7. Configure the Tenant object.
Key Procedures and Actions
Assign the IVR Profile as the default for your tenant.
1. Right-click your
Tenant
object, then select
Properties
.
2. On the
Annex
tab of the
Properties
window, create a gvp.general
section.
3. Add the following options:
default-application
—Set to the name of the default IVR Profile.
service-type
—Set to voicexml
.
For more information, see the Genesys Media Server 8.1 Deployment
Guide.
describes the steps for allowing request for media services to come in directly from the network.
Table 13: Enabling Network Requests for Media Services
Objective
Configure GVP Trunks.
Key Procedures and Actions
Configure a separate
Trunk
DN for each type of NETANN media service.
For example, for NETANN announcements, configure the Trunk DN as follows:
• Set the
option to annc
.
This matches the userpart
of the
Request-UR
I in the network
INVITE
:
INVITE sip:[email protected]:5060;play=greetings.wav SIP/2.0
• Set sip-proxy-uri-parameters
true.
SIP Server will match the prefix to this Trunk, copying the URI from the network
INVITE
to the outgoing
INVITE
it sends to this Media
Server
Trunk
DN.
For other NETANN media services, create a separate
Trunk
DN with prefix
configured as follows:
• conf
—Enables network requests for NETANN conferences.
• dialog
—Enables network requests for simple VoiceXML prompt/collect applications.
SIP Server supports an increased maximum ringing period for predictive calls
through Genesys Media Server. Table 14 describes the steps to enable a ringing
period of greater than 32 seconds.
SIP Server—Deployment Guide 97
Chapter 4: SIP Devices Support Configuring Genesys Media Server
Table 14: Increasing Ringing Period for Predictive Calls
Objective
1. Configure a Genesys
Media Server DN.
2. Configure a MCP. application
Key Procedures and Actions
In the
TServer
section of the DN (
Trunk Group
or
Voice over IP
Service
) object, configure the following option:
•
—Set this option to false
.
1. Set the sip.timer_si
option to a value greater than the
AttributeTimeout
in
TMakePredictiveCall
used by SIP Server to control the call. Typically this setting comes into effect for stuck calls only, or in cases where
AttributeTimeout
is set to
0
.
2. Set the sessmgr.acceptcalltimeout
option to a value greater than the sip.timer_si
. This prevents the MCP application from interfering with the SIP level timers.
98 Framework 8.1
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
Chapter
6
T-Library Functionality
Support
This chapter describes the T-Library functionality that SIP Server supports. It contains the following sections:
Using T-Library Functions, page 413
Using the Extensions Attribute, page 422
Using T-Library Functions
Table 102 presents the T-Library functionality supported in SIP Server. The
table entries use these notations:
N—Not supported
Y—Supported
E—Event only is supported
I—Supported, but reserved for Genesys Engineering
, when a set of events is sent in response to a single request, the events are listed in an arbitrary order. An asterisk (*) indicates the event that contains the same
Reference ID
as the request. For more information, refer to the Genesys Events and Models Reference Manual and the Platform SDK 8.x
.NET (or Java) API Reference for complete information on the T-Server events, call models, and requests.
Table 102 reflects only the switch functionality that Genesys software supports
and might not include the complete set of events that the switch offers.
Certain requests listed in
are reserved for Genesys Engineering and are listed here merely for completeness of information.
SIP Server—Deployment Guide 413
Chapter 6: T-Library Functionality Support Using T-Library Functions
Table 102: Supported Functionality
Feature Request
TOpenServer
TOpenServerEx
TCloseServer
TSetInputMask
TDispatch
TScanServer
TScanServerEx
TRegisterAddress a
TUnregisterAddress a
TMakeCall b
TAnswerCall
TReleaseCall
TClearCall
THoldCall
TRetrieveCall
TRedirectCall d
TMakePredictiveCall e
Request Subtype Corresponding Event(s) Supported
General Requests
EventServerConnected
EventServerConnected
EventServerDisconnected
EventACK
Y
Y
Y
Y
Y
Y
Y
Not Applicable
Not Applicable
Not Applicable
Registration Requests
EventRegistered
EventUnregistered
Call-Handling Requests
EventDialing Regular
DirectAgent
SupervisorAssist
Priority
DirectPriority
Y
Y
Y
N
N
N
N
Y c
Y
EventEstablished
EventReleased
EventReleased
EventHeld
EventRetrieved
EventReleased
EventDialing*
EventQueued
Y
Y
Y
Y
Y
414 Framework 8.1
Chapter 6: T-Library Functionality Support Using T-Library Functions
Table 102: Supported Functionality (Continued)
Feature Request
TInitiateTransfer b
TCompleteTransfer
TInitiateConference b
TCompleteConference
TDeleteFromConference
TReconnectCall
TAlternateCall
TMergeCalls
TMuteTransfer b,f
TSingleStepTransfer b
TSingleStepConference
Request Subtype Corresponding Event(s) Supported
Transfer/Conference Requests
Y EventHeld
EventDialing*
EventReleased*
EventPartyChanged
Y
Y EventHeld
EventDialing*
EventReleased*
EventRetrieved
EventPartyChanged
EventPartyAdded
EventPartyDeleted*
EventReleased
EventReleased
EventRetrieved*
Y
Y
Y
ForTransfer
ForConference
EventHeld*
EventRetrieved
EventHeld
EventReleased*
EventRetrieved
EventPartyChanged
EventHeld
EventReleased*
EventRetrieved
EventPartyChanged
EventPartyAdded
EventHeld
EventDialing*
EventReleased
EventPartyChanged
EventReleased*
EventPartyChanged
EventRinging*
EventEstablished
Y
N
N
Y
Y
Y
SIP Server—Deployment Guide 415
Chapter 6: T-Library Functionality Support Using T-Library Functions
Table 102: Supported Functionality (Continued)
Feature Request
TRouteCall b
TApplyTreatment
Request Subtype
Unknown
Default
Call-Routing Requests
EventRouteUsed
Label
OverwriteDNIS
DDD
IDDD
Direct
Reject
Announcement
PostFeature
DirectAgent
Priority
DirectPriority
AgentID
Corresponding Event(s) Supported
Y
Y
N
N
N
N
N
Y
N
N
N
N
N
N
N CallDisconnect
Call-Treatment Requests
Unknown
IVR
(EventTreatmentApplied +
EventTreatmentEnd)/
EventTreatmentNotApplied
Music
RingBack
N
N
Y
Y
Silence
Busy
CollectDigits
PlayAnnouncement
Y
Y
Y
Y
416 Framework 8.1
Chapter 6: T-Library Functionality Support Using T-Library Functions
Table 102: Supported Functionality (Continued)
Feature Request
TApplyTreatment
(continued)
Request Subtype
PlayAnnouncementAnd-
Digits
PlayApplication
VerifyDigits
RecordUserAnnouncement
DeleteUserAnnouncement
CancelCall
SetDefaultRoute
TextToSpeech
TextToSpeechAndDigits
FastBusy
Corresponding Event(s) Supported
TGiveMusicTreatment
TGiveRingBackTreatment
TCollectDigits
TSendDTMF
EventTreatmentApplied
EventTreatmentApplied
TGiveSilenceTreatment EventTreatmentApplied
DTMF (Dual-Tone Multi-Frequency) Requests
EventDigitsCollected
EventDTMFSent
Voice-Mail Requests
TOpenVoiceFile
TCloseVoiceFile
TLoginMailBox
TLogoutMailBox
TPlayVoice
TAgentLogin
TAgentLogout
EventVoiceFileOpened
EventVoiceFileClosed
EventMailBoxLogin
EventMailBoxLogout
EventVoiceFileEndPlay
Agent & DN Feature Requests
EventAgentLogin
EventAgentLogout
Y
N
Y
N
N
N
N
N
Y
Y
N
N
N
N
Y
N
Y
N
N
N
Y
N
SIP Server—Deployment Guide 417
Chapter 6: T-Library Functionality Support Using T-Library Functions
Table 102: Supported Functionality (Continued)
Feature Request
TAgentSetIdleReason
TAgentSetReady
TAgentSetNotReady
TMonitorNextCall
TCancelMonitoring
TCallSetForward
TCallCancelForward
TSetMuteOff g
TSetMuteOn
TListenDisconnect
TListenReconnect
TSetDNDOn
TSetDNDOff
TSetMessageWaitingOn
TSetMessageWaitingOff
TQuerySwitch a
OneCall
AllCalls
None
Request Subtype
Unconditional
OnBusy
OnNoAnswer
OnBusyAndNoAnswer
SendAllCalls
DateTime
ClassifierStat
Corresponding Event(s) Supported
EventAgentIdleReasonSet N
EventAgentReady
EventAgentNotReady
EventMonitoringNextCall
Y
Y
Y
Y
EventMonitoringCanceled
EventForwardSet
N
N
N
Y
Y
N
Y
Y
EventForwardCancel
EventMuteOff
EventMuteOn
EventListenDisconnected
EventListenReconnected
EventDNDOn
EventDNDOff
EventMessageWaitingOn
EventMessageWaitingOff
Query Requests
EventSwitchInfo
N
N
Y
Y
Y
Y
Y
Y
N
N
418 Framework 8.1
Chapter 6: T-Library Functionality Support Using T-Library Functions
Table 102: Supported Functionality (Continued)
Feature Request
TQueryCall a
TQueryAddress a
Request Subtype
PartiesQuery
StatusQuery
AddressStatus
MessageWaitingStatus
AssociationStatus
CallForwardingStatus
AgentStatus
NumberOfAgentsInQueue
NumberOfAvailableAgents-
InQueue
Number Of Calls InQueue
AddressType
CallsQuery
SendAllCallsStatus
QueueLoginAudit
NumberOfIdleClassifiers
NumberOfClassifiersInUse
NumberOfIdleTrunks
NumberOfTrunksInUse
DatabaseValue
DNStatus
QueueStatus
Corresponding Event(s) Supported
EventPartyInfo N
EventAddressInfo
N
N
Y
Y
Y
Y
N
Y
N
N
N
Y
Y
Y
Y
N
Y
N
N
Y
SIP Server—Deployment Guide 419
Chapter 6: T-Library Functionality Support Using T-Library Functions
Table 102: Supported Functionality (Continued)
Feature Request
TQueryLocation
TQueryServer a a
Request Subtype
AllLocations
LocationData
MonitorLocation
CancelMonitorLocation
MonitorAllLocations
Corresponding Event(s) Supported
EventLocationInfo
CancelMonitorAllLocations
EventServerInfo
User-Data Requests
h
I
I
I
I
I
I
Y
Y
Y
Y
Y
TAttachUserData EventAttachedDataChanged
TUpdateUserData
TDeleteUserData
TDeleteAllUserData
EventAttachedDataChanged
EventAttachedDataChanged
EventAttachedDataChanged
ISCC (Inter Server Call Control) Requests
TGetAccessNumber b
TCancelRegGetAccess-
Number
EventAnswerAccessNumber
EventReqGetAccess-
NumberCanceled
Special Requests
TReserveAgent
TSendEvent
TSendEventEx
TSetCallAttributes
TSendUserEvent
TPrivateService
TNetworkConsult
TNetworkAlternate
EventAgentReserved
EventACK
EventACK
EventCallInfoChanged
EventACK
EventPrivateInfo
Network Attended Transfer/Conference Requests i
EventNetworkCallStatus
EventNetworkCallStatus
I
I
Y
Y
I
I
I
I
Y
Y
420 Framework 8.1
Chapter 6: T-Library Functionality Support Using T-Library Functions
Table 102: Supported Functionality (Continued)
Feature Request
TNetworkTransfer
TNetworkMerge
TNetworkReconnect
TNetworkSingleStep-
Transfer
TNetworkPrivateService
Request Subtype
TTransactionMonitoring
Corresponding Event(s) Supported
EventNetworkCallStatus Y
EventNetworkCallStatus
EventNetworkCallStatus
EventNetworkCallStatus
N
Y
N
EventNetworkPrivateInfo
ISCC Transaction Monitoring Requests
EventACK
EventTransactionStatus
N
Y
E a. Only the requestor receives a notification of the event associated with this request. b. This feature request may be made across locations in a multi-site environment. However, if the location attribute of the request contains a value relating to any location other than the local site—except when the response to this request is
EventError
—there will be a second event response that contains the same reference
ID
as the first event. This second event will be either
EventRemoteConnectionSuccess
or
EventRemoteConnectionFailed.
c. Supported for SIP endpoints that have the Remote Talk feature activated.
d. SIP Server treats unsuccessful redirect operations differently, depending on whether they were initiated through 3pcc (
TRedirectCall
) or 1pcc (
302 Moved
). Incase of
TRedirectCall
, if the destination rejects the redirect for some reason (capacity, DND, for example), the call remains alive. In case of an unsuccessful SIP
302 Moved
attempt, the call is rejected. The following sample scenario explains the difference:
- DN1 has reached its configured capacity.
- DN2 is dialing DN3, and DN3 is ringing.
- DN 3 redirects to DN1.
In case of a 3pcc redirect, the call between DN2-DN3 will remain in the ringing state. In case of a 1pcc redirect, the call between DN2-DN3 is released.
e. SIP Server does not use the extensions
parameter. Any data in this parameter is ignored.
f. SIP Server supports
TMuteTransfer
requests with the following limitations:
- The
TMuteTransfer
operation does not support the out-of-signaling-path (OOSP) transfer mode.
- The
TMuteTransfer
operation to a Hunt Group will be completed only after a Hunt Group member picks up the call.
g. SIP Server supports
TSetMuteOn
and
TSetMuteOff
only for established conferences, to allow for service observing h. Two subtypes are supported by
EventLocationInfo
:
LocationInfoLocationMonitorCanceled
and
LocationInfoAllLocationsMonitorCanceled.
i. All T-Servers support NAT/C requests with
AttributeHomeLocation
provided that this attribute identifies a network location that is capable of processing such requests. Refer to the Network T-Server Deployment
Guides to determine whether a specific Network T-Server can process these requests.
SIP Server—Deployment Guide 421
Chapter 6: T-Library Functionality Support Using the Extensions Attribute
Using the Extensions Attribute
SIP Server supports the use of the
Extensions
attribute as documented in the
Genesys Events and Models Reference Manual and the Platform SDK 8.x .NET
(or Java) API Reference. See those documents for complete information on the
T-Server events, call models, and requests. Additionally, the
Extensions described in
Table 103: Use of the Extensions Attribute
Extension Used In
Key Type
AOC-Destination-DN after-call-divertdestination
AnsMachine
FaxDest
String
String
String
String
Description
Advice of Charge
TPrivateService If set, the value of this key points to an existing party in the call in the established state.
See “Providing AoC Notifications for
Established Calls” on page 104 for details.
Call Divert Destination
TRouteCall A destination DN where SIP Server will divert the call in cases where the caller remains on the line when all other parties have left.
See “Call Divert Destination” on page 121
for details.
Call Progress Analysis
TMakePredictive-
Call
TMakePredictive-
Call
If set, the value of this key (can only be set to drop
) overrides the Application-level parameter
. If the CPD result shows that the predictive call reached an answering machine,
SIP Server drops the call.
See “Outbound IP Solution Integration” on page 317 for details.
If set, the value of this key (can only be set to drop
) overrides the Application-level parameter
. If the CPD result shows that the
predictive call reached a fax machine, SIP
Server drops the call.
See “Outbound IP Solution Integration” on page 317 for details.
422 Framework 8.1
Chapter 6: T-Library Functionality Support Using the Extensions Attribute
Table 103: Use of the Extensions Attribute (Continued)
Extension Used In Description
Key
SilenceDest
Type
String record String
TMakePredictive-
Call
If set, the value of this key (can only be set to drop
) overrides the Application-level parameter
. If the CPD result shows that silence is detected, SIP Server drops the call.
See “Outbound IP Solution Integration” on page 317 for details.
Call Recording
TRouteCall,
TPrivateService
For
TRouteCall
:
• When set to destination, call recording is initiated on the routing destination DN
(agent), and will continue until the agent leaves the call.
• When set to source, call recording is initiated on the DN that sent a call to the
Routing Point (customer), and will continue until the customer leaves the call.
See “Call Recording—NETANN-Based” on page 126
for details.
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.
See “DN Recording Override” on page 137 for details.
SIP Server—Deployment Guide 423
Chapter 6: T-Library Functionality Support Using the Extensions Attribute
Table 103: Use of the Extensions Attribute (Continued)
Extension Used In Description
Key
record
(cont.)
Type
MonitorMode
MonitorScope
String
String
For
TPrivateService:
• When set to source,
call recording is initiated for
ThisDN
(the source DN for the request).
• When set to destination,
call recording is initiated for
OtherDN
(identified in the request).
See “Call Recording—MSML-Based” on page 130
for details.
Call Supervision
TMonitorNextCall,
TRouteCall,
TSetMuteOn,
TSetMuteOff,
EventPrivateInfo
Specifies the monitoring mode as follows:
• mute, normal
—A mute connection.
• connect
—A three-party conference call
(open supervision).
• coach
—Only the agent can hear the supervisor (whisper coaching).
If
MonitorMode
is set to coach
in the
TSetMuteOff
or
TSetMuteOn
request, the monitoring mode is changed to whisper coaching for the current supervision session.
Note:
TSetMuteOn
and
TSetMuteOff
support only the coach
value.
See “Call Supervision” on page 143 for details.
TMonitorNextCall,
TRouteCall
Specifies the required intrusion/observation scope. Values:
• agent
—The monitoring is initiated for a specific agent. The supervisor is disconnected when the call is transferred or released, but will be connected to the next call that is routed to the same agent.
• call
—The monitoring is initiated to track an entire customer call. If the call is transferred to another agent, queue, or VRU, the monitoring function continues with the call until the customer disconnects the call.
424 Framework 8.1
Chapter 6: T-Library Functionality Support Using the Extensions Attribute
Table 103: Use of the Extensions Attribute (Continued)
Extension Used In Description
Key
AssistMode
Type
String
Transfer-Type String original-dialplan-digits Integer
TSingleStep-
Conference
Specifies the required assistance mode. Values:
• connect
—This is the default value - a threeparty conference call.
• coach
—Only the agent can hear the supervisor (whisper coaching).
Call Transfer
TRouteCall the SIP call flow that will be used to deliver the call to a routing destination. Valid values:
• invite
—An
INVITE
transaction is used to connect an origination party with a routing destination.
• refer
—A
REFER
method is used to complete the call routing. The
Host
name in the
Refer-
To
header points to SIP Server. Therefore,
SIP Server remains in the signaling path when two parties are connected after the routing.
Note: The
REFER
method cannot be used if the call is not answered by the remote party, and no treatment is applied to the call.
• oosp
(Out Of Signaling Path)—SIP Server is taking itself out of the signaling path by sending the
REFER
request or a
302
response, pointing to the routing destination, to the origination party. Two parties are connected directly when routing is complete. SIP Server no longer controls the call.
See “Selecting SIP Call Flows from the Routing
Strategy” on page 169 for details.
Dial Plan
EventQueued,
EventRouteRequest,
EventRinging
If set, this key specifies the call’s original destination (dialed) number before the dial plan is applied to the call.
See “Dial Plan” on page 210 for details.
SIP Server—Deployment Guide 425
Chapter 6: T-Library Functionality Support Using the Extensions Attribute
Table 103: Use of the Extensions Attribute (Continued)
Key
DNIS_OVER
Extension
Type
Integer
Used In Description
UseDialPlan String
EventQueued,
EventRouteRequest
TRouteCall
Contains overdialed digits removed from DNIS when the dnis-max-length
dial-plan rule parameter is specified.
See “Removal Overdialed Digits From DNIS” on page 213 for details.
If set, specifies how SIP Server applies the dial plan:
• full
—The dial plan is applied to the destination of
TRouteCall
, including the digit translation and forwarding rules.
• partial
—Valid for both SIP Server and SIP
Feature Server dial plans. Only the digit translation is applied to a dial-plan target.
Forwarding rules, such as forwarding on no answer ( ontimeout
), forwarding on busy
( onbusy
), forwarding on DND ( ondnd
), forwarding on no response ( onunreach
), and forwarding on not SIP registered ( onnotreg
) are not applied.
• false
—No dial plan is applied to the destination of
TRouteCall
.
Notes:
• For ISCC calls, this extension is applied only to calls routed through an External Routing
Point (c ast-type=route-notoken).
• This extension is not supported in Business
Continuity deployments.
426 Framework 8.1
Chapter 6: T-Library Functionality Support Using the Extensions Attribute
Table 103: Use of the Extensions Attribute (Continued)
Extension Used In Description
Key Type
divert-on-ringing sdp-c-host sdp-m-port-low
String
String
Integer
Divert On Ringing
TRouteCall Valid values:
• true
—SIP Server generates
EventRouteUsed and
EventDiverted
messages when any SIP
18x
response (
180 Ringing
or
183 Session
Progress
) arrives for the
INVITE
request at the routing destination.
• false
—SIP Server postpones .
EventRouteUsed
and
EventDiverted messages until the call is answered by the routing destination with a SIP
200 OK message. If the call is not answered within the value specified by the after-routingtimeout
option, the destination SIP dialog is canceled and an
EventError
message is generated.
Dummy SDP
TRouteCall 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.
See “Dummy SDP” on page 238 for details.
TRouteCall 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.
See “Dummy SDP” on page 238 for details.
SIP Server—Deployment Guide 427
Chapter 6: T-Library Functionality Support Using the Extensions Attribute
Table 103: Use of the Extensions Attribute (Continued)
Extension
Key
sdp-m-port-high
Type
Integer
Used In Description
charge-type Integer
AgentLogoutOnUnregist er
String
TRouteCall 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-portlow will be used.
See “Dummy SDP” on page 238 for details.
Early Media
TApplyTreatment If set, the value of this key overrides the value set in the
configuration option for the current call.
1
—Free. When SIP Server receives this key in the initial TApplyTreatment request, SIP Server forces audio treatments to be played in early media, free of charge, instead of media in the established state, in deployments where the
option is set to
2
(charged).
Consecutive audio treatments are played in early media until the new
TApplyTreatment
request containing the charge-type
key set to
2
(charged) arrives.
2
—Charged. SIP Server forces audio treatments to be played in the established state and ignores the charge-type key value in consecutive
TApplyTreatment
requests.
See “Controlling Early Media with a Routing
Strategy” on page 247 for details.
Emulated Agents
TAgentLogin If set to true,
SIP Server logs out emulated agents on unregister.
See “Emulated Agents Support” on page 250
.
428 Framework 8.1
Chapter 6: T-Library Functionality Support Using the Extensions Attribute
Table 103: Use of the Extensions Attribute (Continued)
Extension Used In Description
Key Type
agent-greeting customer-greeting agent-greeting-type
record-agent-greeting music music-on-hold
String
String
String
String
String
String
Greetings
TRouteCall
TRouteCall
TRouteCall
Specifies the name of the media file that will be used as a greeting for the agent.
See “Personal Greetings” on page 330
for details.
Specifies the name of the media file that will be used as a greeting for the customer.
See “Personal Greetings” on page 330
for details.
When set to vxml
, enables VXML support for
agent greeting. See “VXML Support for Agent
Greeting” on page 332 for details.
TRouteCall Specifies whether the agent greeting or customer greeting must be recorded when both recording and greeting are enabled for the call.
• If set to true,
the agent greeting is recorded.
• If set to false,
the customer greeting is recorded.
If set, the key value takes precedence over the
See “Recording an Agent Greeting” on page 335
for details.
Music on Hold
THoldCall,
TAlternateCall,
TInitiateTransfer,
TInitiate-
Conference
TRouteCall
Specifies the file name for music on hold for the call.
See “Customizing Music on Hold and in Queue” on page 194 for details.
Specifies the name of the file that is played for the music-on-hold treatment when one of the parties in the call is placed on hold.
See “Customizing Music on Hold and in Queue” on page 194 for details.
SIP Server—Deployment Guide 429
Chapter 6: T-Library Functionality Support Using the Extensions Attribute
Table 103: Use of the Extensions Attribute (Continued)
Extension Used In Description
Key Type
connect-nailedup-onlogin
ReasonCode
String
String
Nailed-up Connections
TAgentLogin
EventAgentNot-
Ready
If set, the value of this key overrides any value set in the
setting but only for a current login session.
Specifies SIP Server actions when receiving a
TAgentLogin
request from a DN with the configured nailed-up connection, as follows:
• When this key is set to a Routing Point number, SIP Server immediately establishes a nailed-up connection between an agent’s endpoint and the specified Routing Point.
After processing the
TRouteCall
request to the gcti::park device, SIP Server parks the agent on gcti::park
, establishing the persistent SIP connection with the agent’s endpoint.
• When this key is set to gcti::park
, SIP
Server parks the agent on the gcti::park device directly, establishing the persistent
SIP connection with the agent’s endpoint.
• When this key is set to an empty value, SIP
Server disables this feature for a particular agent in a current login session.
See “Nailed-Up Connections” on page 298
for details.
Value:
NailedUpConnectionTerminated
Specifies that the nailed-up connection is terminated.
430 Framework 8.1
Chapter 6: T-Library Functionality Support Using the Extensions Attribute
Table 103: Use of the Extensions Attribute (Continued)
Extension Used In Description
Key Type
AFTER_ROUTING_TIMEO
UT_ACTION after-routing-timeout
NO_ANSWER_ACTION
String
Integer
String
No Answer Supervision
TRouteCall
TRouteCall
If set, the value of this key overrides any value set in the after-routing-timeout-action configuration option for the current call.
Values:
• none
—SIP Server takes no action.
• notready
—When an agent is logged in to a routing destination that does not answer the call, SIP Server sets this agent to
NotReady state.
• logout
—When an agent is logged in to a routing destination that does not answer the call, SIP Server logs this agent out.
See “No-Answer Supervision” on page 313 for
details.
A positive integer that overrides the value of the
which specifies the length of time (in seconds) that SIP Server waits before diverting the call from the
Routing Point
DN to the destination
DN after
TRouteCall
was processed. When the call is not diverted before the timeout expires,
SIP Server generates an
EventError
message.
If set to a value of
0
(zero), this extension is ignored and the value of the after-routingtimeout
configuration option is used instead.
TRouteCall If set, the value of this key overrides any value set in any of the following configuration options for the current call:
• no-answer-action
• agent-no-answer-action
See “No-Answer Supervision” on page 313 for
details.
SIP Server—Deployment Guide 431
Chapter 6: T-Library Functionality Support Using the Extensions Attribute
Table 103: Use of the Extensions Attribute (Continued)
Key
Extension
NO_ANSWER_OVERFLOW
NO_ANSWER_TIMEOUT
Type
Commaseparated list
Used In Description
ReasonCode
LCTPartiesLength
LCTParty<n> no-answer EventAgentNot-
Ready
If configured, reports
ReasonCode
set to noanswer
when an agent is placed in the
Not Ready state after not answering a call.
See “Reporting ReasonCode” on page 314
for details.
Providing Call Participant Info
(See “Providing Call Participant Info” on page 349 for details)
Integer EventUserEvent
Integer EventUserEvent
Specifies how many parties are involved in a single call.
Represents a party of the call, where n is an integer value starting from
0
.
LCTParty<n>_location String
LCTSupervisor<n>
String
Integer
TRouteCall
TRouteCall
EventUserEvent
EventUserEvent
If set, the value of this key overrides any value set in any of the following configuration options for the current call:
• no-answer-overflow
• agent-no-answer-overflow
• extn-no-answer-overflow
• posn-no-answer-overflow
See “No-Answer Supervision” on page 313 for
details.
If set, the value of this key overrides any value set in any of the following configuration options for the current call:
• no-answer-timeout
• agent-no-answer-timeout
• extn-no-answer-timeout
• posn-no-answer-timeout
See “No-Answer Supervision” on page 313 for
details
Provides the DN location name; that is, the name of the switch to which this DN belongs.
Represents the supervisor of the call, where n is an integer value starting from
0
.
432 Framework 8.1
Chapter 6: T-Library Functionality Support Using the Extensions Attribute
Table 103: Use of the Extensions Attribute (Continued)
Extension
Key
LCTSupervisor<n>_ location
Type
String
LCTSupervisor<n>_ monitoredDN
LCTSupervisor<n>_ mode
Integer
String
Used In
EventUserEvent
EventUserEvent
EventUserEvent
Description
Provides the name of the switch to which this supervisor belongs.
Represents the agent monitored by this supervisor.
Provides Supervision mode.
CPNDigits
DisplayName
String
String call_timeguard_timeout Integer
Providing Caller ID
TMakeCall,
TMakePredictive-
Call,
TInitiate-
Conference,
TInitiateTransfer,
TRouteCall,
TSingleStep-
Transfer,
TSingleStep-
Conference
If set, the value of this Extension 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.
See “Providing a Caller ID” on page 349 for
details.
TMakeCall,
TMakePredictive-
Call,
TInitiate-
Conference,
TInitiateTransfer,
TRouteCall,
TSingleStep-
Transfer,
TSingleStep-
Conference
TMakePredictive-
Call
Allows users to define their own display name and Calling Party Number (CPN) for OCS outbound dialing
If set, the value of this Extension is used as the display name, in addition to the CPN digits, when providing the Caller ID. This setting only applies if the
CPNDigits
key-value pair is also present in the Extensions.
SIP Server maps this info from the request to the
From
header of the SIP
INVITE
. For example,
From: “DisplayName”
<sips:[email protected]>;tag=a48s
If set, the value of this key specifies the maximum time, in milliseconds, allowed for post-connect CPD results to be received from the device performing CPD (either Genesys Media
Server or Media Gateway). See “Outbound IP
Solution Integration” on page 317
for details.
SIP Server—Deployment Guide 433
Chapter 6: T-Library Functionality Support Using the Extensions Attribute
Table 103: Use of the Extensions Attribute (Continued)
Key
feature dn agent-dn login-id monitor-type password
Extension
post-feature-dn
Used In
Type
Remote Supervision
String
“remoteobserving”
TRouteCall
String
String
TRouteCall
TRouteCall
This extension triggers registration of a routed party as a supervisor with parameters specified in additional
Extensions
described in this subsection.
See “Remote Supervision” on page 158
for details.
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.
The target that the supervisor wants to monitor.
This parameter can be a Routing Point, ACD
Queue, or an agent DN.
String TRouteCall
Description
AllCalls
String
String
TRouteCall
TRouteCall
TRouteCall
(Optional) A Login ID, which will be used for remote client authorization.
(Optional) The supervisor will 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.
(Optional) A password, which will be used for remote client authorization for a specified Login
ID.
(Optional) A Routing Point, to which the remote supervisor will be connected after the supervision session.
434 Framework 8.1
Chapter 6: T-Library Functionality Support Using the Extensions Attribute
Table 103: Use of the Extensions Attribute (Continued)
Extension Used In Description
Key Type
geo-location overflow-location busy-on-reject
ConvertOtherDN
String
String
String
( true
, false
)
String
Routing
TRouteCall,
TApplyTreatment
TRouteCall,
TApplyTreatment
If
TRouteCall
or
TApplyTreatment
contains the geo-location extension, SIP Server makes this geo-location to be the most preferable on the current call. It means that each time when the switch resource is selected based on the geolocation parameter, resources with the preferred geo-location take precedence.
If the preferable geo-location is activated on the call, but
TRouteCall
or
TApplyTreatment requests does not contain the geo-location extension specified, SIP Server deactivates the preferred geo-location mode, and switch resources are selected in accordance with a regular selection procedure.
Note: The overflow-location
extension key applies only if the geo-location
extension key is defined in the same request.
See “Geo-Location for MSML-Based Services:
Strict Matching” on page 401 .
TRouteCall If SIP Server receives
TRouteCall
with busy-onreject=true
in
AttributeExtensions
and if the destination responds with the
486 Busy Here message, it generates
EventDestinationBusy
for the origination party.
Smart OtherDN Handling
.
A value of
0
disables all conversions for the call.
A value of
1
forces the relevant conversion for the call.
SIP Server—Deployment Guide 435
Chapter 6: T-Library Functionality Support Using the Extensions Attribute
Table 103: Use of the Extensions Attribute (Continued)
Extension Used In Description
Key Type
User-Agent
Server and User-Agent Headers
String TMakeCall,
TMakePredictive-
Call,
TSingleStep-
Transfer,
TSingleStep-
Conference,
TInitiateTransfer,
TInitiate-
Conference
Enables inserting the
User-Agent
header.
See “Enabling Server and User-Agent Headers” on page 200 .
Sending Outgoing INVITEs with Multipart Body
SIP_MIME_HEADERS String
Geolocation String
TRouteCall Value:
Geolocation:application/pidf+xml
Passes geolocation content from
TRouteCall
into an outgoing
INVITE
message.
See “Sending Outgoing INVITEs with Multipart
TRouteCall included into an outgoing
INVITE
message.
See “Sending Outgoing INVITEs with Multipart
Trunk Capacity
Dest-Capacity sdn-licenses-in-use Integer sdn-licenses-available
Integer TRouteCall Specifies the trunk capacity as defined in the
URS routing strategy. SIP Server checks the current load of the targeted Trunk, and if the
Dest-Capacity value is exceeded, SIP Server replies to the RouteRequest with a
403
Forbidden
error message.
T-Server Common Part Extensions
Integer
EventServerInfo Specifies how many SDN licenses are currently in use.
Specifies how many SDN licenses are currently available.
436 Framework 8.1
Chapter 6: T-Library Functionality Support Error Messages
Table 103: Use of the Extensions Attribute (Continued)
Extension Used In Description
Key Type
VideoFile
AgentVideo
String
String
Video Support
TSingleStep-
Conference
A string that contains the name of the video file that will be played for the customer. If this keyvalue pair is not specified, the default video file will be played. The default video file is configured in the SIP Server
Application
using the
configuration option.
See “Video Support” on page 390 for details.
TSingleStep-
Conference
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 played to the third party—that is, video from the file specified by the
VideoFile
parameter.
See “Video Support” on page 390 for details.
Error Messages
Table 104 presents the complete set of error messages SIP Server distributes in
EventError,
which SIP Server generates when it cannot execute a request because of an error condition
.
Table 104: Error Messages for SIP Server
Code Symbolic Name
40 TERR_NOMORE_LICENSE
Description
No more licenses are available.
41 TERR_NOT_REGISTERED Client has not registered for the DN.
42 TERR_RESOURCE_SEIZED Resource is already seized.
43 TERR_IN_SAME_STATE Object is already in requested state.
SIP Server—Deployment Guide 437
Chapter 6: T-Library Functionality Support Error Messages
Table 104: Error Messages for SIP Server (Continued)
Code
50
Symbolic Name
TERR_UNKNOWN_ERROR
51 TERR_UNSUP_OPER
52 TERR_INTERNAL
53 TERR_INVALID_ATTR
54 TERR_NO_SWITCH
55 TERR_PROTO_VERS
56 TERR_INV_CONNID
57 TERR_TIMEOUT
Description
Unknown error code. Request cannot be processed.
Operation is not supported.
Internal error.
Attribute in request operation is invalid.
No connection to the switch.
Incorrect protocol version.
Connection ID in request is invalid.
Switch or T-Server did not respond in time.
58
59
TERR_OUT_OF_SERVICE
TERR_NOT_CONFIGURED
Switch or T-Server is out of service.
DN is not configured in the Configuration
Database.
DN in request is invalid.
61 TERR_INV_CALL_DN
71 TERR_INV_CALD_DN Invalid called DN.
93 state.
96 TERR_CANT_COMPLETE_CONF
118 TERR_SERV_UNAVAIL
119 TERR_BAD_PASSWD
122
123
128
166
TERR_CANT_REG_DNS
TERR_DN_NOT_EXIST
TERR_BAD_DN_TYPE
TERR_RES_UNAVAIL
168 TERR_INV_ORIG_ADDR
173 TERR_UNSUCC_CONFER
177 TERR_TARG_DN_INV
Call cannot add new conference party.
Requested service is unavailable.
Password was invalid. May occur when SIP
Server receives a
404 Not Found message from the Media Gateway after an unsuccessful attempt to route a call.
Cannot register DNs on the switch.
DN for association does not exist.
Invalid DN type for DN registration.
(JTAPI object) resource is not available.
Originating address in request was invalid.
Unsuccessful conference.
DN target (in route call) was invalid.
438 Framework 8.1
Chapter 6: T-Library Functionality Support Error Messages
Table 104: Error Messages for SIP Server (Continued)
Code Symbolic Name
185 TERR_SET_WRONG_STATE
192 TERR_AGENT_ID_INV
195 TERR_CFW_DN_INV
212 TERR_ADMIN_DEV_DIS
223 TERR_BAD_PARAM
226 TERR_OUT_OF_MEM
231 TERR_DN_BUSY
232 TERR_DN_NO_ANSWER
233 TERR_CALL_REJECTED
236 TERR_TIMEOUT_PRF_OP
237 TERR_DISCON_CALL
243 TERR_CLNT_NOT_MON
259 TERR_INV_PASSWD
Description
Set is in the wrong state for invocation.
Agent ID is invalid.
Call forwarding address is invalid.
Device disabled by administration.
Bad parameter is passed to function.
Out of memory (local).
DN is busy.
No answer at a DN.
Call has been rejected.
Timeout performing operation.
Call has disconnected.
Internal error—client corrupted in T-Server.
Invalid credentials (login_id or password).
282 TERR_NO_VCHAN_AVAIL
291 TERR_OTHER_TEL_OPER
302 TERR_INV_DTMF_STRING
355 TERR_OPER_INVALID
No voice channel available.
Other telephony operation is in progress.
DTMF string invalid.
Operations are invalid on system messages.
410 TERR_INAPPR_TRTM Invalid treatment type.
415 DN in the request is invalid.
470
496
TERR_PARTY_NOT_ON_CALL
TERR_INV_CALL_STATE
506 TERR_RECVD_INV_STATE
527 TERR_ALRDY_SIGN_IN
549 TERR_OTHER_INV_FRMT
565 TERR_INVALID_STATE
Party in request is not involved in a call.
Party in request is in the call
state.
Call/Party is in invalid state for this time
The agent’s sign-in number is already active at another console.
Other invalid format.
Invalid state.
SIP Server—Deployment Guide 439
Chapter 6: T-Library Functionality Support Error Messages
Table 104: Error Messages for SIP Server (Continued)
Code Symbolic Name
649 TERR_ASAI_OUT_CALL_BARRED
700 TERR_INV_LOGIN_REQ
701 TERR_INV_LOGOUT_REQUEST
702 TERR_INV_READY_REQ
726 TERR_DMS_INV_AUTHCODE
1141 TERR_CSTA_OPER_REQ_INCOMPAT
1143 TERR_CSTA_OPER_OBJ_NOT_KNOWN
1150 TERR_CSTA_OPER_INV_CALL_ID
1151 TERR_CSTA_OPER_INV_DEV_ID
1152 TERR_CSTA_OPER_INV_CONN_ID
1161 TERR_CSTA_INCOMP_INCORR_STATE
1165 TERR_CSTA_INCOMP_NO_CALL_TO_
CLEAR
Description
Outgoing call has been barred.
Agent cannot log in at this time.
Agent cannot logout.
Agent cannot go to ready
state.
Invalid AuthCode.
Request incompatible with object.
Object is unknown.
Invalid call identifier.
Invalid device identifier.
Invalid connection identifier.
Incorrect object state.
No call to clear.
1183 TERR_CSTA_SUBRES_OUTST_LIMIT_EXC Rejects the second consecutive call party control request if it comes in less than one second after the first one.
1605 TERR_INVALIDPARTY Party in request was invalid on switch.
2100
2101
3005
TERR_SIPCS_ERR
TERR_SIPTS_PENDING_INV_TRN
TERR_UNSUCC_ROUTECALL
Unspecified kind of error.
Operation cannot be completed due to the pending INVITE transaction.
2130 TERR_SIPTS_INCOMPATIBLE_OPTION_
VALUE
Operation cannot be initiated due to current value of the configuration option.
2131 TERR_SIPTS_REFER_ENABLED_SHOULD_
BE_TRUE
Operation cannot be initiated if “referenabled=false”.
2132 TERR_SIPTS_NOT_SUPPORTED_IN_
CURRENT_SCENARIO
3002 TERR_PRIVVIOLATION
Operation is not supported in current scenario.
User doesn’t have security privilege on the switch.
TRouteCall
request was unsuccessful.
440 Framework 8.1
Chapter 6: T-Library Functionality Support Known Limitations
Known Limitations
Several known limitations result from the current SIP Server and softswitches/gateways interface:
•
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-to-agent calls.
•
SIP Server supports
TSetMuteOn
and
TSetMuteOff
only for established conferences, to allow for service observing.
•
SIP Server does not support User Datagram Protocol (UDP) messages of more than 16 KB in length. If SIP Server encounters a message larger than
16 KB, it truncates the message without warning. This can cause problems in scenarios that require larger UDP messages. For example, when using the Busy Lamp Field (BLF) feature, SIP Server can sometimes receive
UDP messages of up to 35 KB. In this scenario, the 16 KB UDP limitation restricts SIP Server support to a maximum of 20 monitored users over a single BLF subscription.
•
You must configure the Outbound Contact Solution to use a single-step transfer when you use
Transfer
Mode. SIP Server does not support consultation calls when it is working with the Outbound Contact Solution.
•
An
EventReleased (switch::)
message is issued when the last internal party leaves a call.
•
Third-party call control (3pcc) blind conference calls are not supported.
•
The
TDeleteFromConference
request is not supported for first-party call control (1pcc) conference calls.
•
SIP Server does not report a first-party call control (1pcc) conference with mixing on an endpoint.
•
SIP Server does not process third-party call control (3pcc) requests that have the same value for
AttributeThisDN
and
AttributeOtherDN
, even if the requests have a non-empty value for
AttributeLocation,
meaning that the destination DN (
AttributeOtherDN
) is located remotely. These requests are rejected with
EventError
with
Error Code
of
415
(
Invalid Destination DN
).
SIP Server—Deployment Guide 441
Chapter 6: T-Library Functionality Support Known Limitations
•
SIP Server does not support registering several SIP devices on the same
DN—only a single SIP device must be registered on a DN at a time.
Third-Party Equipment—Known Limitations
The known limitations when SIP Server is operating with a third-party equipment are as follows:
•
The Siemens OpenScape Voice switch is supported with the following limitations:
1pcc (first-party call control) calls are only supported starting with switch version V5.
The remote answer feature (
TAnswerCall
) is not available with version
2.0. However, the remote answer feature is supported with version 2.2.
For 3pcc calls with OpenScape Voice (HiPath 8000) switch versions,
SIP Server must be configured to use re-INVITE-based call control methods.
Genesys recommends setting the dual-dialog-enabled
configuration option to false
if Siemens optiPoint phones are used in re-INVITE mode for third-party call control (3pcc) operations.
Sometimes SIP Server cannot retrieve a call within a mixed phone environment. To avoid this problem, set the sip-hold-rfc3264
option with a proper value on the DN.
•
The following media gateways support re-INVITE
-based call transfers only:
Alcatel 7515
Cisco A5350
Cisco A5400
Asterisk
Sonus
•
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.
442 Framework 8.1
Chapter
7
SIP Server Configuration
Options
This chapter describes the configuration options that are unique to SIP Server and contains the following sections:
Application-Level Options, page 443
Agent Login–Level and DN-Level Options, page 550
GVP Integration Options, page 621
Changes from Release 8.0 to Release 8.1, page 623
SIP Server also supports common log options described in Chapter 10 on page 707
and options common to all T-Servers described in Chapter 11 on page 729
. Refer to the Framework 7.6 Stream Manager Deployment Guide if you need to configure Stream Manager for use with SIP Server.
Application-Level Options
Unless specified otherwise, set configuration options in the
Options
of the SIP
Server
Application
object, using one of the following navigation paths:
•
In Genesys Administrator—
Application
object >
Options
tab >
Advanced
View (Options)
•
In Configuration Manager—
Application
object >
Properties
dialog box >
Options tab
TServer Section
This section must be called
TServer.
For ease of reference, the options have been arranged in alphabetical order.
SIP Server—Deployment Guide 443
Chapter 7: SIP Server Configuration Options
444
Application-Level Options
acw-in-idle-force-ready
Default Value: true
Valid Values: true, false
Changes Take Effect: Immediately
Related Feature: “Emulated Agents” on page 248
Specifies whether, after timed manual wrap-up (when option
is set to true
), SIP Server forces the agent to the
Ready
state. With value false,
SIP Server returns the agent to the state prior to requesting manual wrap-up.
Note:
For compatibility with the previous SIP Server releases, you can use the name cwk-in-idle-force-ready for this option as an alias.
acw-persistent-reasons
Default Value: true
Valid Values: true, false
Changes Take Effect: Immediately
If set to true,
SIP Server populates
AttributeReasons
in unsolicited
EventAgentReady
messages generated by the After Call Work (ACW) feature.
If set to false,
SIP Server does not populate
AttributeReasons
in
EventAgentReady
messages.
after-routing-timeout
Default Value:
10
Valid Values: Any positive integer
Changes Take Effect: Immediately
Related Feature: “No-Answer Supervision” on page 313
Specifies the length of time (in seconds) that SIP Server waits before diverting the call from the
Routing Point
DN to the destination DN after
TRouteCall
was processed. If the call is not diverted before the specified number of seconds, the
EventError
message is issued, containing the
Reference ID
of the
TRouteCall
request.
When set to
0
(zero), the after-routing-timeout timer is disabled.
Notes:
• The after-routing-timeout option is also dependent on the
option:
• When the divert-on-ringing
option is set to
true,
the call is considered as “diverted” when the
180 Ringing
message arrives from the destination DN.
• When the divert-on-ringing
option is set to
false, the call is considered as “diverted” when the
200 OK
message arrives from the destination DN.
• You can override this option by configuring the routing strategy to include the
after-routing-timeout
key-value pair to the
Extensions
attribute of the
TRouteCall
.
Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
after-routing-timeout-action
Default Value: none
Valid Values: none
SIP Server takes no action.
notready
When an agent is logged in to a routing destination that does not answer the call, SIP Server sets this agent to NotReady state. logout
When an agent is logged in to a routing destination that does not answer the call, SIP Server logs this agent out.
Changes Take Effect: For the next call
Related Feature: “No-Answer Supervision” on page 313
Defines SIP Server’s default action if the
after-routing-timeout
is disabled (set to
0
), then SIP Server ignores the after-routing-timeout-action
value.
When you set this option to a valid non-default value, it takes priority over the
no-answer-action
parameters, which are not applied to an agent logged in to a routing destination if the after-routingtimeout
expires. In addition, none of the following parameters are applied if the after-routing-timeout
is in progress:
,
, or
.
agent-emu-login-on-call
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Related Feature: “Emulated Agents Support” on page 250
Specifies whether the SIP Server allows an emulated agent login on a device where there is a call in progress. Note that SIP Server always allows an emulated agent logout on a device where there is a call in progress.
The option can be set in the Configuration Layer in the following places in order of precedence (highest to lowest):
1. The
TServer
section of an agent DN.
2. The
TServer
section of a device.
3. The
TServer
section of the application.
The value can also be set by using the
AgentEmuLoginOnCall extension in the
TAgentLogin
requests. The value specified by the extension, where present, takes precedence over the settings configured in the Configuration Layer.
SIP Server—Deployment Guide 445
Chapter 7: SIP Server Configuration Options Application-Level Options
agent-group
Default Value: No default value
Valid Value: Any agent-group value
Changes Take Effect: At the next agent login session
Specifies a value for an agent group that will be used for SIP Server reporting.
SIP Server obtains the value for this option in the following order of precedence:
1. In the
TServer
section of the
DN
object.
2. In the
TServer
section of the SIP Server
Application
object.
agent-logout-on-unreg
Default Value: false
Valid Values: true false emu-only
SIP Server will log out emulated and native agents on unregister.
SIP Server will not log out emulated or native agents on unregister.
SIP Server will log out only emulated agents on unregister.
Changes Take Effect: After agent logs out and then logs in again
Related Feature: “Emulated Agents Support” on page 250
Specifies whether SIP Server performs an automatic logout of an agent whenever their client application unregisters the DN from the SIP Server. This happens whenever a client application disconnects from the SIP Server.
The option can be set in the Configuration Layer in the following places in order of precedence (highest to lowest):
1. The
TServer
section of the device representing the agent’s group (such as an ACD Queue).
2. The
TServer
section of an agent DN.
3. The
TServer
section of a device.
4. The
TServer
section of the Application level.
The Configuration Layer settings may be overridden by adding the extension
AgentLogoutOnUnregister
to the
TAgentLogin
request.
The initial
TAgentLogin
request can override the current agent association by adding the
AgentLogoutOnUnregister
key of the
Extensions
attribute with a value of true.
Note:
This option is not applicable if the logout-on-disconnect
option is set to true.
446 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
agent-logout-reassoc
Default Value: false
Valid Values: true false
SIP Server automatically associates a new client application with the agent.
SIP Server does not automatically associate a new client application with the agent.
Changes Take Effect: After agent logs out and then logs in again
Related Feature: “Emulated Agents Support” on page 250
Specifies whether SIP Server automatically associates a new client application with the agent, when the application either:
•
Registers on the agent DN, or;
•
Sends a login request while SIP Server is currently waiting to log the agent out due to the previously associated client disconnecting.
Note:
The new client application must have the same application name as the previously disconnected client.
agent-no-answer-action
Default Value: none
Valid Values: none notready
SIP Server takes no action on agents when calls are not answered.
SIP Server sets agents to
NotReady
when calls are not answered.
SIP Server automatically logs out agents when calls are not logout answered.
Changes Take Effect: Immediately
Related Feature: “No-Answer Supervision” on page 313
Defines SIP Server’s default action if a logged-in agent fails to answer a call within the time defined in the agent-no-answer-timeout
option. See also the
NO_ANSWER_ACTION
extension in section “Using the Extensions Attribute” on page 422
for more information about how this option is used
.
SIP Server obtains the value for this option in the following order of precedence:
1.
no-answer-action if defined at an
Agent Login
level.
2.
agent-no-answer-action if defined at a SIP Server
Application
level.
SIP Server—Deployment Guide 447
Chapter 7: SIP Server Configuration Options Application-Level Options
agent-no-answer-overflow
Default Value: none
Valid Values: none recall release
Any valid overflow destination
SIP Server does not attempt to overflow a call on an agent desktop when the agent-no-answer-timeout
option expires.
SIP Server returns the call to the last distribution device (the device reported in the
ThisQueue
attribute of the call) when the agent-no-answer-timeout
option expires.
SIP Server releases the call.
SIP Server returns the call to the specified destination when the value set when the agent-no-answer-timeout option expires.
Changes Take Effect: Immediately
Related Feature: “No-Answer Supervision” on page 313
Specifies a sequence of overflow destinations (separated by comma) that SIP
Server attempts to overflow to when the time specified in the agent-no-answer-timeout option expires. SIP Server attempts to overflow in the order specified in the list.
•
When all overflow attempts fail, SIP Server abandons overflow. See also the
NO_ANSWER_OVERFLOW
extension
in section “Using the Extensions
Attribute” on page 422 for more information about how this option is used
.
•
When the list of overflow destinations contains the recall
value and the call was not distributed, SIP Server skips to the next destination in the list.
SIP Server obtains the value for this option in the following order of precedence:
1.
no-answer-overflow if defined at an
Agent Login
level.
2.
agent-no-answer-overflow if defined at a SIP Server
Application
level.
agent-no-answer-timeout
Default Value:
15
Valid Value: Any integer from
0
–
600
Changes Take Effect: Immediately
Related Feature: “No-Answer Supervision” on page 313
Defines the default time (in seconds) that SIP Server allows for a logged-in agent to answer a call before executing the actions defined in the agent-no-answer-overflow
and agent-no-answer-action
options.
If set to
0
, the Agent No-Answer Supervision feature is disabled. See the
NO_ANSWER_TIMEOUT
extension in section “Using the Extensions Attribute” on page 422
for more information about how this option is used.
SIP Server obtains the value for this option in the following order of precedence:
1.
no-answer-timeout if defined at an
Agent Login
level.
2.
agent-no-answer-timeout if defined at a SIP Server
Application
level.
448 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
agent-only-private-calls
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Related Feature: “Emulated Agents” on page 248
Specifies whether SIP Server blocks the classification of a call’s business type as private when there is no agent on the call. If set to false
, calls with no agents present are classified with business type private
, enabling No-Answer
Supervision (NAS) to be applied for private calls.
If set to true
, calls remain classified with business type unknown
and NAS is not applied to such calls.
agent-strict-id
Default Value: false
Valid Values: true
, false
Changes Take Effect: Immediately
Related Feature: “Emulated Agents” on page 248
Specifies whether SIP Server enables any
AgentID
to be used during login
(value false
), or only those configured in the Configuration Layer (value true
).
alternate-route-profile
Default Value: An empty string
Valid Values: A Routing Point DN with non-empty Default DNs list
Changes Take Effect: For the next default routing
Related Feature: “Alternate Routing for Unresponsive URS/ORS” on page 111
Defines a Routing Point DN with a Default DNs list in its configuration. This list is used for alternate routing for all Routing Points with an empty Default
DNs list.
am-detected
Default Value: drop
Valid Values: drop connect
The call is released.
The connected call stays connected.
Changes Take Effect: Immediately
Related Feature: “Outbound IP Solution Integration” on page 317
Specifies the behavior of SIP Server where CPD is operating, and an answering machine is detected on an Outbound call. SIP Server provides the
CPD result in
UserData
attached to the call as a key-value pair with key
AnswerClass
containing the value
AM
. This
UserData
in
EventRouteRequest provides extra information to the strategy, so that the strategy can decide to drop the
AM
call if required.
SIP Server—Deployment Guide 449
Chapter 7: SIP Server Configuration Options
450
Application-Level Options
audio-codecs
Default Value: telephone-event, PCMU, PCMA, G723, G729, GSM
Valid Values: Any valid codec; if the codec has a dynamic payload and clock rate other than 8000, you must include the clock rate along with the codec name, separated by a slash (/). For example, SIREN/16000.
Changes Take Effect: For the next call
Related Option:
on
Specifies a list of codecs that SIP Server uses to modify the Session
Description Protocol (SDP) message body during SIP re-negotiation. SIP
Server picks codecs in this list from the incoming SDP, and passes only these codecs on to the remote side. As a result, all call center audio traffic is established based on the codecs listed in this option.
This option is also used to supply a list of codecs in the SDP offer for the initial
INVITE
to the caller for a 3pcc
MakeCall
operation.When creating the
INVITE
,
SIP Server will use from this list only those codecs with a static payload.
You can also specify this option at the DN-level. If s ip-enable-sdp-codecfilter
is set to true
in the DN configuration, SIP Server, as it propagates the
SDP to and from the device represented by this DN, will use as its list of available codecs the value configured in the audio-codecs
option on the DN rather than on the application. If sip-enable-sdp-codec-filter
is set to true
at both the application and the DN level, the audio-codecs
configured in the DN should contain a subset of the audio-codecs
configured in the application.
Note:
This option only takes effect for SDP renegotiation if sip-enable-sdpcodec-filter
is set to true
. The option is still used for 3pcc
MakeCall operations even if sip-enable-sdp-codec-filter
is set to false
.
auto-logout-ready
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Related Feature: “Automatic Inactive Agent Logout” on page 119
Enables a stricter enforcement of the automatic agent-logout policy (as set in the related auto-logout-timeout
option). If this option is set to true
, SIP
Server will log the agent out regardless of agent state. If it is set to false
, SIP
Server will not log agents out when in the following agent states:
Ready
,
NotReady/ACW
,
NotReady/AuxWork
,
NotReady/LegalGuard
.
You can configure this option in the
TServer
section of the following objects
(listed in order of precedence):
•
Agent Login
object (
Annex
tab)
•
DN object (
Annex
tab of the
ACD Position
or
Extension
DN) that represents the device to which the agent is logged on.
•
DN object (
Annex
tab of the
Routing Point or
ACD Queue
DN) that represents the queue the agent is logged on.
•
SIP Server
Application
object (
Options
tab), which specifies the serverwide default.
Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
Calls While in
Emulated ACW
auto-logout-timeout
Default Value:
0
Valid Values:
0
, or any positive integer up to
35791
Changes Take Effect: Immediately
Related Feature: “Automatic Inactive Agent Logout” on page 119
Enables automatic agent logout and specifies the length of time, in minutes, after which the logout occurs. To enable this feature, enter a value of
1
or greater; the agent is allowed to remain inactive for this length of time before having to be automatically logged out. To disable this feature, enter a value of
0
(default).
You can configure this option in the
TServer
section of the following objects
(listed in order of precedence):
•
Agent Login
object (
Annex
tab)
•
DN object (
Annex
tab of the
ACD Position
or
Extension
DN) that represents the device to which the agent is logged on.
•
DN object (
Annex
tab of the
Routing Point or
ACD Queue
DN) that represents the queue to which the agent is logged on.
•
SIP Server
Application
object (
Options
tab), which specifies the serverwide default.
backwds-compat-acw-behavior
Default Value: false
Valid Value: true, false
Changes Take Effect: Immediately
Related Feature: “Emulated Agents” on page 248
Specifies whether pre-7.5 behavior after-call work is enabled (value = true
) or disabled (value = false
), for backward compatibility.
With value true,
if an agent receives or makes a business call while in emulated After Call Work (ACW), SIP Server does the following:
1. Stops the ACW timer.
2. Forces the agent to the
Ready
state.
3. Restarts ACW (and the legal-guard timer) after the new business call is released.
If an agent makes or receives a work-related call while in ACW, SIP Server does the following:
1. Suspends the ACW, but leaves the agent in the ACW state.
2. Resumes the ACW timer once the work-related call is released.
SIP Server categorizes as a work-related call any call that an agent makes while in the
NotReady
state with workmode
set to
AfterCallWork
or
AuxWork
.
SIP Server—Deployment Guide 451
Chapter 7: SIP Server Configuration Options Application-Level Options
Business Call
While Not Ready
After the ACW and any configured legal-guard time have been completed, the agent is forced to the
Ready state. If an agent makes or receives a private call during ACW, no action is taken and the ACW timer keeps running.
With value false,
if an agent receives or makes a business call while in emulated ACW, SIP Server does the following:
1. Stops the ACW timer and adds the remaining amount of ACW to the ACW period for the new call. If either of the ACW periods is untimed, the resulting ACW will also be untimed.
2. Forces the agent to the
NotReady (ManualIn) state.
3. Restarts ACW after the business call is released.
If an agent makes or receives a work-related or private call while in ACW, SIP
Server does the following:
1. Suspends the ACW timer.
2. Forces the agent to the
NotReady (ManualIn) state.
3. Returns the agent to the ACW state and resumes the ACW timer once the call is released.
After the ACW and any configured legal-guard time have been completed, the agent is forced to the
Ready state.
With value true,
if an agent receives a business call while in an emulated
NotReady
state, except for ACW or legal-guard time, SIP Server sets the agent state to
Ready
for the duration of the business call.
With value false,
if an agent receives a business call while in emulated
NotReady
state, except for ACW or legal-guard time, SIP Server will maintain the current agent state for the duration of the business call. After the call and any associated wrap-up are completed, SIP Server will return to the previous
NotReady
state. Note that no legal-guard time is applied, because the agent does not go into the
Ready
state.
blind-transfer-enabled
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Specifies whether SIP Server processes certain transfer requests while a consultation call is in the dialing state. If set to true,
SIP Server processes
TCompleteTransfer
requests or SIP
REFER
messages while a consultation call is in the dialing state. Otherwise, such requests are rejected.
Notes:
• This option can also be configured at the DN level. The DN-level configuration takes precedence.
• This option is for blind transfers only. Blind conference calls are not supported.
452 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
bsns-call-dev-types
Default Values:
+acdq +rp +rpq +xrp
Valid Values: A set of space separated flags.
+/-acdq
+/-rp
Turns on/off the classification of the call type as business on an
ACD Queue.
Turns on/off the classification of the call type as business on a
Routing Point.
+/-rpq
Turns on/off the classification of the call type as business on a
Routing Queue.
+/-xrp Turns on/off the classification of the call type as business on an
External Routing Point.
Changes Take Effect: Immediately
Related Feature: “Business-Call Handling” on page 249
Specifies which types of distribution devices will be exempt from default business-call handling. By default, SIP Server classifies any call arriving at a distribution device (ACD Queue, Routing Point, Routing Queue, External
Routing Point) as a business call. Using this option, you can disable automatic classification for calls to a particular type of distribution device. For example, if the value for this option is set to
-rp,
calls to
Routing Poin t DNs will not be automatically classified as business
, allowing the routing strategy to use the
BusinessCallType
extension key.
busy-tone
Default Value: music/busy_5sec
Valid Values: Name and path of any valid audio file
Changes Take Effect: Immediately for all new calls
Specifies the audio file to be played for the
Busy
treatment.
busy-tone-duration
Default Value:
5
Valid Values: Any integer from
1
–
3600
Changes Take Effect: The next time the
Busy
treatment is played
,
Specifies, in seconds, the maximum duration of the busy or fast-busy tone treatment is played to a party because of a busy condition or an error.
call-monitor-acw
Default Value: false
Valid Values: true, false
Changes Take Effect: For the next call
If set to true,
SIP Server applies emulated After Call Work (ACW) to a service observer (supervisor) after a call is released.
SIP Server—Deployment Guide 453
Chapter 7: SIP Server Configuration Options Application-Level Options
call-observer-with-hold
Default Value: false
Valid Values: true, false
Changes Take Place: Immediately
If this option is set to true,
SIP Server sends the initial
INVITE
with hold SDP to a supervisor in a monitoring scenario. This is done so Early Media does not affect the conversation between call participants when a supervisor is monitoring the session. After the supervisor answers the call, SIP Server sends a re-
INVITE
to add the supervisor to the conference.
cancel-monitor-on-disconnect
Default Value: true
Valid Values: true false
Call supervision subscription is canceled.
Call supervision subscription is not canceled.
Changes Take Effect: Immediately
Related Feature: “Call Supervision” on page 143
Specifies whether the call supervision subscription is canceled when the client that requested it disconnects from SIP Server.
cancel-monitor-on-unpark
Default Value: true
Valid Values: true, false
Changes Take Effect: Immediately
Specifies whether SIP Server cancels the supervisor monitoring subscription when the nailed-up connection is dropped. If set to true,
SIP Server cancels the supervisor subscription when the supervisor is unparked. If set to false,
SIP Sever does not cancel the supervisor subscription in case of unpark.
capacity-sip-error-code
Default Value:
603
Valid Values:
400
–
699
Changes Take Effect: Immediately
Related Feature: “Trunk Capacity Control” on page 379
Specifies the SIP error code that SIP Server distributes in response to a rejected
SIP request (incoming or outgoing) when trunk capacity is reached.
454 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
capacity-tlib-error-code
Default Value: No default value
Valid Values: Any positive integer
Changes Take Effect: Immediately
Related Feature: “Trunk Capacity Control” on page 379
Specifies the error code that SIP Server distributes in the
AttributeErrorCode of the T-Library
EventError
message in response to a rejected T-Library request when trunk capacity is reached. Recommended value is
282,
which corresponds to the error message
No Voice Channel Available
. If the value of this option is not specified, SIP Server uses different error codes for different
T-Library requests to indicate a capacity problem.
cid-enable-on-vtp
Default Value: false
Valid Values: true, false
Changes Take Effect: For the next call
Related Feature: “Caller Information Delivery Content for AT&T Trunks” on page 122
Use this option to simplify provisioning of the IVR that is configured through the Voice Treatment Port (VTP) DNs.
•
If set to true,
SIP Server passes the CID content to the VTP DN in the initial
INVITE
.
•
If set to false,
SIP Server does not pass the CID content to the VTP DN in the initial
INVITE
.
Note:
CID content default encoding is in UTF-8. No content re-encoding and no URL encoding is performed; CID is passed to SIP destinations as it is received
clamp-dtmf-allowed
Default Value: false
Valid Values: true, false
Changes Take Effect: For the next call
Related Feature: “DTMF Clamping in a Conference” on page 234
When set to true,
enables the DTMF Clamping feature.
When set to false,
disables this feature. This setting also preserves backward compatibility.
collect-tone
Default Value: music/collect
Valid Values: Name and path of any valid audio file
Changes Take Effect: Immediately for all new calls
Specifies the audio file that SIP Server uses to produce a noncompletion tone played during DTMF digit collection.
SIP Server—Deployment Guide 455
Chapter 7: SIP Server Configuration Options Application-Level Options
connect-nailedup-on-login
Default Value: An empty string
Valid Values: Routing Point number, gcti::park
Changes Take Effect: At the next agent login session
Related Feature: “Nailed-Up Connections” on page 298
Specifies SIP Server actions when receiving a
TAgentLogin
request from a DN with the configured nailed-up connection, as follows:
•
When this option is set to a DN of type
Routing Point,
SIP Server immediately establishes a nailed-up connection between an agent’s endpoint and the specified Routing Point. After processing the
TRouteCall request to the gcti::park
device, SIP Server parks the agent on gcti::park
, establishing the persistent SIP connection with the agent’s endpoint.
•
When this option is set to gcti::park,
SIP Server parks the agent on the gcti::park
device directly, establishing the persistent SIP connection with the agent’s endpoint.
•
When the value for this option is not specified (the default), SIP Server does not take any action.
Note:
This option can be configured at both Application and DN levels.
Setting at the DN level takes precedence over the Application level.
control-remote-vip-scripts
Default Value: true
Valid Values: true, false
Changes Take Effect: After SIP Server restart
Related Feature: See the SIP Server 8.1 High-Availability Deployment Guide.
If only a single SIP Server is started out of the HA pair, the sip-vip-scriptdown
option might need to be executed on the host where SIP Server is not started. When set to true,
SIP Server connects to the remote LCA and executes the Virtual IP address control scripts on the remote host. This option applies only if the value of the
true
.
Note:
This option is reserved by Genesys Engineering. Use it only when requested by Genesys Customer Care.
control-vip-scripts
Default Value: false
Valid Values: true, false
Changes Take Effect: After SIP Server restart
Related Feature: See the SIP Server 8.1 High-Availability Deployment Guide.
For the Hot Standby configuration. When set to true,
SIP Server itself controls execution of Virtual IP address control scripts through the LCA component.
The names of the Application objects representing scripts are configured using
456 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options the
LCA to execute the sip-vip-script-up
option when switching to the primary mode, or the sip-vip-script-down
option when switching to the backup mode.
convert-otherdn
Default Value:
+agentid +reserveddn +fwd
+/-agentid
Turns on/off the conversion of the Agent ID value provided in the
OtherDN
attribute of a T-Library request to the DN where the agent was logged in. SIP Server processes requested T-
Library operations with this DN.
+/-reserveddn
(Does not apply for use with SIP Server)
+/-fwd
Turns on/off conversion of
OtherDN
in request
TSetCallForward.
Changes Take Effect: Immediately
Related Feature: “Smart OtherDN Handling” on page 371
Defines whether SIP Server has to convert (if applicable) the value provided in
AttributeOtherDN
of a T-Library request to the DN where the agent was logged in.
For example:
The Application-level option convert-otherdn
is set to
+agentid.
The agent with Agent ID 4040 is logged in on DN 2003. When an internal call is made by a
TMakeCall
request containing OtherDN =4040, SIP Server sends the call to
DN 2003 where Agent 4040 was logged in.
cos
Default Value: No default value
Valid Values: Any COS
Voice over IP Service
DN ( service-type=cos
)
Changes Take Effect: Immediately
Related Features: “Class of Service” on page 179
Specifies the Class Of Service (COS) DN assigned globally for all calls made from any DN on the Switch (unless otherwise defined on the DN or Agent
Login-level).
Class of Service (COS) is the functionality that defines telephony capabilities for a device or an agent. This option is used in both of the dial plan-related features supported by SIP Server—Class of Service and Dial Plan. For more information about how to use this option for either functionality, see the following:
•
“Class of Service” on page 179
•
Class of Service can also 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).
SIP Server—Deployment Guide 457
Chapter 7: SIP Server Configuration Options Application-Level Options
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.
If this option is not specified for both the device and logged-in agent, COS functionality is disabled for the calls to and from the device.
cpd-info-timeout
Default Value:
3
Valid Values: Any valid integer
Changes Take Effect: Immediately
Related Feature: “Outbound IP Solution Integration” on page 317
Specifies the length of time, in seconds, that SIP Server will wait for the
INFO message with the CPD result. The timer starts at the moment that SIP Server receives the
200 Ok
from the media gateway. If the timer expires before the
CPD result is available, SIP Server generates an
EventEstablished
with a
CallState
of
0
(voice is detected). You can specify this option at both the
Application and DN level (DN-level takes priority). By default, the DN-level option is initialized with the value of the Application-level option. The default value of the application-level option is 3 seconds. If the call_timeguard_timeout
key is included in the
Extensions attribute in the
TMakePredictiveCall
request, the value of this key will override the value of the cpd-info-timeout option.
To increase the probability that the timer expires after the CPD result is available, you can reduce the value of the post-connect CPD timer sent to the
Genesys Media Server by using the
Performed by Genesys Media Server” on page 319
for more information about using this option.
If the post-connect CPD timeout is explicitly set to 0 by the cpd-info-timeout option or by the
Extensions
attribute of the
TMakePredictiveCall
request, then SIP Server does not start its own postconnect CPD timer and does not send a proposed timer value to the Genesys
Media Server. In this case, the Outbound solution relies on the value of the post-connect CPD timeout configured in the Genesys Media Server. This configuration is not recommended, because in case of missing post-connect
CPD result notification from Genesys Media Server, SIP Server will not be able to process the call and the call can only be released by the customer.
458 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
default-dn
Default Value:
NULL
Valid Value: Any valid DN
Changes Take Effect: For the next call
Specifies the DN to which calls are sent when URS is nonoperational, or when the timeout specified in the
Notes:
• You can also use this option for emergency ACD routing.
• You can define this option at both the Application and the DN level.
The DN-level option takes precedence.
default-monitor-mode
Default Value: mute
Valid Values:
Silent monitoring is used (supervisor connection is mute) mute
(or normal
) coach connect
Whisper coaching is used (only the monitored agent can hear the supervisor)
The open supervisor presence is used
Changes Take Effect: Immediately
Related Feature: “Call Supervision” on page 143
Initializes a new call supervision subscription monitor mode if the
MonitorMode extension is not provided (or if its value is specified incorrectly) in the
TMonitorNextCall
request.
default-monitor-scope
Default Value: call
Valid Values: call agent
The supervisor remains on the call until it is finished.
SIP Server disconnects the supervisor from the call automatically when the monitored agent leaves the call.
Changes Take Effect: Immediately
Related Feature: “Call Supervision” on page 143
Initializes a new call supervision subscription monitor scope if the
MonitorScope
extension is not provided (or its value is specified incorrectly) in the
TMonitorNextCall
request.
SIP Server—Deployment Guide 459
Chapter 7: SIP Server Configuration Options Application-Level Options
default-music
Default Value: music/on_hold
Valid Value: Name and path of any valid audio file
Changes Take Effect: Immediately for all new calls
Related Feature: “Customizing Music on Hold and in Queue” on page 194
Specifies the name of the file that is played for the music treatment if none is specified in
TApplyTreatment,
or if the specified file is missing.
Note:
You can define this option at the Application, the DN level, and the
Agent-Login level. The Agent-Login level option takes precedence.
default-route-point
Default Value: No default value
Valid Value: Any valid DN, or reject=<SIP ERROR>, w here
<SIP ERROR>
is a three-digit number in the range of
400
–
699
representing the valid SIP
ERROR
—for example, reject=404
Changes Take Effect: For the next call
Specifies the DN to which an inbound call is routed when its destination number is external. For this call, SIP Server will report the call’s original destination number taken from the
Request-URI
of the
INVITE
message in the
DNIS
attribute of the
EventRouteRequest
message.
If set to reject
, SIP Server, while applying a default-route-point rule, does not direct a call to a particular route point, rejecting the call instead with the configured SIP error code.
If default-route-point is set to reject=<SIP ERROR>
and default-routepoint-order is set to before-dial-plan,
SIP Server rejects a call without applying any dial plan.
If default-route-point is set to reject=<SIP ERROR>
and default-routepoint-order is set to after-dial-plan,
SIP Server applies a dial plan, as follows:
•
If a dial plan does not fit the original target, SIP Server rejects the call.
•
If a dial plan fits the original target but the modified target, after the dial plan was applied, does not match any internal resource, SIP Server rejects the call.
•
If a dial plan fits the original target and the modified target, after the dial plan was applied, matches an internal resource, SIP Server sends the call to that resource.
If the default-route-point
option is not configured (or does not have any value), then inbound calls are handled in accordance with the regular procedure
Note:
This functionality is applicable only to inbound calls initiated by incoming
INVITE
requests. This functionality is not applicable to ISCC calls or to calls initiated by T-Library requests, such as
TMakeCall,
TInitiateTransfer
, and so on.
460 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
default-route-point-order
Default Value:
before-dial-plan
Valid Values: before-dial-plan, after-dial-plan
Changes Take Effect: For the next call
When the option is not configured or set to a value of before-dial-plan
, SIP
Server applies a default-route-point
rule before processing the target destination according to a dial plan.
When the option is set to a value of after-dial-plan
, SIP Server first applies the dial plan and only after that applies the default-route-point
rule to the dial-plan result.
default-video-file
Default Value:
NULL
Valid Values: Any valid video file codec and path
Changes Take Effect: Immediately
Related Feature: “Video Support” on page 390
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.
dial-plan
Default Value: No default value
Valid Values: Any dial-plan
Voice over IP Service
DN
Changes Take Effect: For the next call
Related Feature: “Dial Plan” on page 210
Specifies which dial-plan DN will be applied to calls. You can define the option on any of the following locations listed in order of highest to lowest 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).
disable-media-before-greeting
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Related Feature: “Disabling Media Before Greeting” on page 334
Specifies whether SIP Server establishes a call in hold state if greetings are configured to be played for a caller and an agent. If set to true,
SIP Server establishes a call in hold state (an SDP to the caller and the agent is placed on
SIP Server—Deployment Guide 461
Chapter 7: SIP Server Configuration Options Application-Level Options hold/inactive state). If the recording is enabled, the SDP to a recorder is also placed on hold before the greeting is played. If set to false,
SIP Server establishes the call in active state and the media is played before the greeting.
Note:
This option can be configured at both Application and DN levels.
Setting at the DN level takes precedence over the Application level. If this option is set at an Application level and if a particular DN does not support this functionality, this option must be explicitly set to false
for that DN. For a DN-level activation of this feature, this option must be set for both origination and destination DNs.
disconnect-nailedup-timeout
Default Value:
0
Valid Values: Any positive integer
Changes Take Effect: At the next nailed-up connection
Related Feature: “Nailed-Up Connections” on page 298
Specifies whether SIP Server terminates an agent’s nailed-up connection because of the agent’s inactivity. When set to a non-zero value, SIP Server waits this time interval, in seconds, before terminating the agent’s nailed-up connection. When set to
0
(the default), SIP Server does not terminate the agent connection.
Note:
This option can be configured at both Application and DN levels.
Setting at the DN level takes precedence over the Application level.
divert-on-ringing
Default Value: true
Valid Values: true false
SIP Server generates
EventRouteUsed
and
EventDiverted
messages when any SIP
18x response (
180 Ringing
or
183 Session
Progress
) arrives for the
INVITE
request at the routing destination.
SIP Server postpones
EventRouteUsed
and
EventDiverted messages until the call is answered by the routing destination with a SIP
200 OK
message. If the call is not answered within the value specified by the after-routing-timeout
option, the destination
SIP dialog is canceled and an
EventError
message is generated.
Changes Take Effect: Immediately
Determines SIP Server behavior when routing calls.
462 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
drop-nailedup-on-logout
Default Value:
false
Valid Values: true, false
Changes Take Effect: Immediately
Related Feature: “Disconnecting the Nailed-Up Connection” on page 301
If enabled, on receiving a
TAgentLogout
from an agent with a nailed-up connection, SIP Sever will end the nailed-up connection to the agent DN. If the agent is currently on the call when the
TAgentLogout
is issued, SIP Server does not reconnect the agent DN to the gcti::park
device when the current call ends, but instead ends the connection.
dr-forward
Default Value: off
Valid Values off no-agent oos
Disaster Recovery (DR) peer forwarding to the peer switch is turned off. SIP Server works in the traditional single mode and always tries to deliver the call to the requested destination on the local switch.
SIP Server delivers a call to a DN on the local switch when there is an agent logged in on this DN; if there is no agent logged in,
SIP Server forwards the call to the peer switch. This setting applies only to DNs on “dual-registered” SIP endpoints that simultaneously register to both peers, or for DNs without any registered endpoints, such as for “remote agents.”
SIP Server delivers a call to a DN on the local switch when the
DN is in service; if the DN is out of service, SIP Server forwards the call to the peer switch. This setting applies only to DNs on
“single-registered” SIP endpoints that register only to the preferred peer unless there is an error, in which case they register to the alternate peer.
Changes Take Effect: Immediately
Defines a system-wide mode of forwarding inbound and internal calls when
SIP Server is operating in Business Continuity mode. This option can also be set at the DN level, in which case will override the Application level.
SIP Server—Deployment Guide 463
Chapter 7: SIP Server Configuration Options Application-Level Options
Notes:
• The registration timing of endpoints must be carefully considered when using the oos
setting. For maximum responsiveness in a disaster scenario, a short registration interval must be used so the phone can quickly detect when a peer is unavailable. The deployment should be properly planned to account for the corresponding load of
REGISTER
messages.
• For both the no-agent and oos
settings, SIP Server only forwards calls targeting an Extension DN, and it will only forward each call a single time; if the other peer is unable to deliver the call, an error is generated.
• With the oos
setting, if a desktop is unable to connect to the site where a SIP phone is registered, it might result in a phone registering a DN on one peer while the agent desktop connects to the other peer. Calls would be delivered to the phone, but the agent desktop would be unaware of these calls.
dr-peer-location
Default Value:
NULL
Valid Values: A valid name of the DR peer Switch
Changes Take Effect: on the next target detection
Specifies the location of the other SIP Server in the DR pair. If set to
NULL
(the default), SIP Server is unable to support the Dial Plan feature.
dr-peer-trunk
Default Value:
NULL
Valid Values: A valid name of a
Trunk
DN that points to the DR peer site.
Changes Take Effect: Immediately
Specifies that this SIP Server is a part of a DR pair and identifies the
Trunk
DN that points to the other SIP Server in the DR pair. If set to
NULL
(the default),
SIP Server operates in the traditional single mode.
dtmf-payload
Default Value:
101
Valid Values: Any integer from
0
–
128
Changes Take Effect: Immediately
Specifies the value to be used in negotiations for the DTMF payload type, when Stream Manager release 7.0.2 (or earlier) treatments are used.
Note:
This option is obsolete. It can be used for backward compatibility with the previous SIP Server releases.
464 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
emergency-recording-cleanup-enabled
Default value: false
Valid values: true false
SIP Server automatically terminates emergency recording.
SIP Server does not terminate emergency recording.
Changes Take Effect: Immediately
Specifies whether SIP Server automatically terminates emergency recording when no internal parties remain on a call.
emergency-recording-filename
Default Value:
NULL
Valid Values: Any valid file name using the variables specified below
Changes Take Effect: When the next emergency call recording is initiated
Specifies the recorded file name when emergency call recording is initiated by an agent. When this option contains a value, the generated emergency call recording file name is added as
UserData
to the call with the
GSIP_EMRGREC_FN key. When this option does not contain a value, the recorded file name will be the
UUID
of the call.
The following variables are used when creating the file:
$ANI$
:
$DNIS$
:
$DATE$
:
$TIME$
:
$CONNID$
:
$UUID$
:
$AGENTID$
:
$AGENTDN$
:
The calling number.
The called number.
The current date (GMT) in the Y-M-D format.
The current time (GMT) in the H-M-S format.
The
Connection ID
of the call.
The
UUID
of the call.
The
Agent Login
ID, if the agent is logged in on the device where the emergency call recording is initiated.
The
DN
where the emergency call recording is initiated.
emulated-login-state
Default Value: ready
Valid Values: ready not-ready
SIP Server distributes
EventAgentReady
after
EventAgentLogin.
SIP Server distributes
EventAgentNotReady
EventAgentLogin.
Changes Take Effect: Immediately
Related Feature: “Emulated Agents” on page 248
after
When SIP Server performs an emulated agent login and the client specifies an agent work mode other than
ManualIn
or
AutoIn,
SIP Server uses this option to determine which event to distribute.
When the client specifies the agent work mode
ManualIn,
SIP Server distributes
EventAgentNotReady
after
EventAgentLogin,
and places the agent in the
NotReady
state.
SIP Server—Deployment Guide 465
Chapter 7: SIP Server Configuration Options Application-Level Options
When the client specifies the agent work mode
AutoIn,
SIP Server distributes
EventAgentReady
after
EventAgentLogin,
and places the agent in the
Ready
state.
This option can be set in a number of places, and SIP Server processes it in the following order of precedence, highest first. If the value is not present at the higher level, SIP Server checks the next level, and so on.
1. The
Agent Login
object on the
Annex tab in the
TServer
section.
2. The
DN
object which represents the device on the
Annex tab in the
TServer section.
3. The
DN
object which represents the Agent Group, such as an ACD Queue, on the
Annex
tab in the
TServer
section.
4. The SIP Server
Application
object on the
Options tab in the
TServer section.
enable-busy-on-routed-calls
Default Value: true
Valid Values: true, false
Changes Take Effect: At next call
Specifies whether SIP Server plays a busy tone when routing multi-site calls to an agent through direct-uui
. If this option is set to
false,
the destination SIP
Server does not play a busy tone for calls routed to a busy agent in cases where the transaction type is direct-uui
. SIP Server sends a negative response to the route origination site, and the call can then be routed to an available agent. If this option is set to true,
SIP Server plays a busy tone for a routed call and then ends the call.
enable-ims
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Specifies how SIP Server will handle
REGISTER
requests and populate SIP headers for this DN.
•
false
—For non-IMS endpoints (local to SIP Server) that are registered to
SIP Server. SIP Server will not include IMS-related headers in SIP messages sent to all DNs (unless enabled on the DN).
466 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
•
true
—For IMS endpoints registered to the IMS-CN (using
REGISTER requests through the third-party IMS registration). SIP Server communicates with its DNs through the S-CSCF, and adds IMS-specific headers to all SIP messages (applies globally—you cannot disable on a per-DN basis).
Note:
SIP Server considers this option enabled if set to true
on either the
Application or DN-level. If enabled on the Application, you cannot disable locally on a per-DN basis. Similarly, if enabled on a particular
DN, it stays enabled despite the Application-level setting.
For IMS environments, you must either enable globally for all DNs, or set to true
for all IMS endpoints, as well as for the
Trunk
DN used for routing to IMS.
enable-iscc-dial-plan
Default Value: true
Valid Values: true, false
Changes Take Effect: At the next call
Related Feature: “Dial Plan” on page 210
Specifies whether SIP Server applies the dial plan to the agent destination of multi-site (ISCC) calls that are routed through an External Routing Point
( cast-type=route-notoken
), as follows:
•
If set to true
, the dial plan (full, including the digit translation and forwarding rules) is applied.
•
If set to false,
the dial plan is not applied.
This option must be configured on the remote (destination) site. SIP Server applies the dial plan when a call is routed from an External Routing Point to a
DN at the destination site.
Note:
SIP Server will still apply the dial plan to the External Routing Point destination of multi-site (ISCC) calls, and this will take priority over the agent DN destination dial-plan rule regardless of the setting of enable-iscc-dial-plan
.
enable-legacy-reporting
Default Value: false
Valid Values: true, false
Changes Take Effect: On the next call
Starting with version 8.1.102.13, in single-site routing scenarios, SIP Server generates
EventReleased
with
AttributeCallState=7 (NoAnswer)
for an unanswered party when the
8.1.102.13, SIP Server generated
EventReleased
with
AttributeCallState=22
(Redirected)
.
SIP Server—Deployment Guide 467
Chapter 7: SIP Server Configuration Options Application-Level Options
This option, enable-legacy-reporting
, enables backward compatibility for reporting
AttributeCallState
that SIP Server distributes in
EventReleased
for an unanswered routing target party in single-site routing scenarios.
•
If set to true,
SIP Server distributes
EventReleased
with
AttributeCallState=22 (Redirected)
.
•
If set to false,
SIP Server distributes
EventReleased
with
AttributeCallState=7 (NoAnswer)
.
enable-strict-location-match
Default Value: No default value (empty string)
Valid Values: msml ( or
true), softswitch, trunk, all
Changes Take Effect: On the next call
Related Feature: “Geo-Location for MSML-Based Services: Strict Matching” on page 401
Controls the SIP Server behavior in cases where an MSML service that matches a call by geo-location or overflow-location is not available, or, if during an attempt to apply a treatment, the matching service responds to the
INVITE
message with a SIP error, as follows:
•
If this option is not present or not configured, SIP Server tries other available services for a call.
•
If this option is set to msml
(or true
), SIP Server tries other available services that match a call by geo-location or overflow-location. If there is no match, SIP Server does not apply a service to the call with a different geo-location. (A value of true
is supported for compatibility with previous releases of this feature.)
•
If this option is set to trunk
or softswitch,
SIP Server tries other available trunks or softswitches that match a call by geo-location. This applies to calls directed to an external destination or DNs located behind the softswitch. If there is no match, SIP Server does not send a call to a device with a different geo-location.
•
If this option is set to all,
SIP Server applies the msml setting for calls to
GVP and the trunk/softswitch
setting to other cases.
Note:
If the
enable-strict-location-match
option is set to msml
or true,
it is possible to specify an alternative geo-location using the Application level option
, or using the overflow-location key in
AttributeExtensions
of
TRouteCall
and
TApplyTreatment
client requests.
468 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
enable-unknown-gateway
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Specifies whether SIP Server will accept or reject calls arriving from a gateway that is not represented as a
Trunk
DN in Configuration Manager. To accept calls from un-represented gateways, set this value to true
. To reject calls from un-represented gateways, set this option to the default false
.
encoding
Default Value: No default value
Valid Values: See the
ICU Home > Converter Explorer
pages for values
(http://demo.icu-project.org/icu-bin/convexp)
Changes Take Effect: After SIP Server restart
Related Feature: “Mapping SIP Headers and SDP Messages” on page 276
Provides Unicode support for the SIP-to-TLib and TLib-to-SIP mapping functionality. If the option value is not specified, a default local character set is used for conversion. If the option value is specified, the character set that is specified by this option is used for conversion. To change the default, set this option to the name of a converter that can translate UTF-8 data to the local character set. The converter suitable for a particular deployment can be found using the ICU Converter Explorer.
If enabled, SIP Server can convert UTF-8 encoded data received in SIP messages to a local character set. Reverse conversion (from a local character set to UTF-8) is performed by sending data from T-Library messages encoded in a local character set to the remote destination using SIP messages.
encoding-area
Default Value: No default value
Valid Values: A list of areas separated by a comma (,) where encoding will be applied. Supported areas:
•
tlibsip
—For the “Mapping SIP Headers and SDP Messages” on page 276
feature
•
chat
—For the “Instant Messaging” on page 265 feature
Changes Take Effect: Immediately
Specifies the list of areas where encoding applies.
enforce-external-domains
Default Value:
NULL
Valid Values: A list of computer names or IP addresses that are external to SIP
Server. The list can be separated by semicolons (;).
Changes Take Effect: Immediately
When a value is configured, SIP Server checks the list of computer names or
IP addresses against the computer names or IP addresses specified in the URI of the
From
header. If there is a match, then the DN is considered external.
SIP Server—Deployment Guide 469
Chapter 7: SIP Server Configuration Options Application-Level Options
When a value is not configured, SIP Server uses the user part of the URI only to find the device.
Note:
You must include in the value of this option the computer names or IP addresses of SIP gateways or hosts associated with other T-Servers so that SIP Server may communicate with over ISCC. In certain configurations, you may also have to configure the option overridedomain-from
.
enforce-trusted
Default Value: true
Valid Values: true, false
Changes Take Effect: For the next call
Related Feature: “Network Asserted Identity” on page 303
Specifies the default trust-level for all DNs on the SIP Server switch. For backward compatibility with IMS deployments (where all entities within the
IMS deployment are trusted by default), all DNs on the SIP Server switch will be considered trusted by default, unless otherwise specified at the DN-level. If you set this option to false
, then all DNs on the switch will be considered nontrusted, unless otherwise specified at the DN-level
This option is also used to enable SIP Server to pass following private headers:
•
P-Early-Media
—See “Early Media Private Header” on page 208
.
•
P-Access-Network-Info
—See “P-Access-Network-Info Private Header” on page 330
.
Note:
To establish the trust-level for individual DNs, see the DN-level option
.
event-ringing-on-100trying
Default Value:
false
Valid Values: true false
SIP Server generates
EventRinging
.
SIP Server does not generate
EventRinging
.
Changes Take Effect: Immediately
Specifies whether SIP Server generates an
EventRinging
message for a DN when it receives a
100 Trying
SIP message. Normally, the
EventRinging message is generated on a
180 Ringing
SIP message, but this option allows for
GVP integration when the IVR Server is configured in Behind-the-Switch mode.
Note:
This option must be set at both the
Application
and at the
DN
level because it is used for proper synchronization with the I-Server
Application
.
470 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
external-registrar
Default Value:
NULL
Valid Values: String conforming to the SIP-URI syntax of RFC 3261, defined as: sip:[userinfo]hostport uri-parameters[headers]
Changes Take Effect: Immediately
Specifies the location of an external registrar service. SIP Server implements very limited registrar functionality to support clients that can only register dynamically (for example, Microsoft Messenger 4.7–5.1). Such clients must be configured in the Configuration Layer as DNs. Depending on the state of the internal SIP Server registrar, registration subscriptions from either all, or not configured clients are forwarded to the external registrar.
For example: sip:192.168.8.100:5090;transport=tcp
If no external registrar is specified, a
503 Service Unavailable
error is returned for the
REGISTER method.
extn-no-answer-overflow
Default Value: none
Valid Values: none recall release
Any valid overflow destination
SIP Server does not attempt to overflow a call on an extension when extn-no-answer-timeout
expires.
SIP Server returns the call to the last distribution device (the device reported in the
ThisQueue
attribute of the call) when extn-no-answer-timeout
expires.
SIP Server releases the call.
SIP Server returns the call to the specified destination when the value set for the extn-no-answer-timeout
Changes Take Effect: Immediately
Related Feature: “No-Answer Supervision” on page 313
option expires.
Specifies a sequence of overflow destinations (separated by comma) that SIP
Server attempts to overflow to when the time specified in option extn-noanswer-timeout has expired. SIP Server attempts to overflow in the order specified in the list.
•
When all overflow attempts fail, SIP Server abandons overflow. See also the
NO_ANSWER_OVERFLOW
extension
in section “Using the Extensions
for more information about how this option is used
.
•
When the list of overflow destinations contains the recall
value and the call was not distributed, T-Server skips to the next destination in the list.
SIP Server obtains the value for this option in the following order:
1.
no-answer-overflow if defined at a DN level of type
Extension
.
2.
extn-no-answer-overflow if defined at a SIP Server
Application
level.
SIP Server—Deployment Guide 471
Chapter 7: SIP Server Configuration Options Application-Level Options
extn-no-answer-timeout
Default Value:
15
Valid Value: Any integer from
0
–
600
Changes Take Effect: Immediately
Related Feature: “No-Answer Supervision” on page 313
Defines the default no-answer timeout (in seconds) that SIP Server applies to any device of type extension.
When the timeout ends, SIP Server executes the actions defined in option extn-no-answer-overflow.
If set to
0
, the No Answer Supervision feature for
DN s of type
Extension
is disabled. See the
NO_ANSWER_TIMEOUT
extension in section “Using the
Extensions Attribute” on page 422 for more information about how this option
is used .
SIP Server obtains the value for this option in the following order:
1.
no-answer-timeout if defined at a DN level of type
Extension
.
2.
extn-no-answer-timeout if defined at a SIP Server
Application
level.
fast-busy-tone
Default Value: music/atb_5sec
Valid Values: Name and path of any valid audio file
Changes Take Effect: Immediately for all new calls
Specifies the audio file to be played for the
FastBusy
treatment.
fax-detected
Default Value: drop
Valid Values: drop connect
The call is released.
The connected call stays connected.
Changes Take Effect: Immediately
Related Feature: “Outbound IP Solution Integration” on page 317
Specifies the behavior of SIP Server where CPD is operating and a fax machine is detected on an outbound call. SIP Server provides the CPD result in
UserData
attached to the call as a key-value pair with key
AnswerClass containing the value
Fax
. This
UserData
in
EventRouteRequest
provides extra information to the strategy, so that the strategy can decide to drop the
Fax
call if required.
feature-code-park
Default Value:
10
Valid Values: A two-digit integer
Changes Take Effect: Immediately
Related Feature: “Call Park/Retrieve” on page 124
Specifies the number part of the star code used to initiate a transfer to the internal gcti::pbxpark
device, for PBX Call Park functionality. For example, if
472 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options you set this option to the default value of
10
, the agent will dial
*10 to park the current call at the internal gcti::pbxpark
device, in order to retrieve it later.
feature-code-pickup
Default Value:
12
Valid Values: A two-digit integer
Changes Take Effect: Immediately
Related Feature: “Call Pickup” on page 125
Specifies the number part of the star code to be dialed to pick up a call ringing at another device, for PBX Call Pickup functionality.
feature-code-retrieve
Default Value:
11
Valid Values: A two-digit integer
Changes Take Effect: Immediately
Related Feature: “Call Park/Retrieve” on page 124
Specifies the number part of the star code used to retrieve a parked call from the internal gcti::pbxpark
device. For example, if you set this option to the default value of
11
, and the DN from which the call was parked is
1001
, the agent will dial
*11
, plus the DN number
1001
to retrieve the call:
*11 1001
.
find-outbound-msml-by-location
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
When set to true,
SIP Server selects an MSML service for outbound calls based strictly on a call's geo-location. This option applies only to a call initiated by the
TMakePredictiveCall
request on behalf of the Routing Point
DN. When set to false, this feature is disabled.
find-trunk-by-location
Default Value: false
Valid Values: true
SIP Server considers the geo-location
option setting when prioritizing the selection of an outbound gateway or trunk.
When making a selection, SIP Server first narrows the pool of available in-service gateways or trunks based on the prefix match, then further narrows the pool by matching the value of the geolocation
option of the DN to the value of the geo-location
option for the
Trunk
device. If more than one matching trunk is found, SIP
Server can further narrow the selection by considering the value of the
option (if it is configured). If no matching trunk is found,
SIP Server selects a trunk as if find-trunk-by-location
is set to false
.
SIP Server—Deployment Guide 473
Chapter 7: SIP Server Configuration Options Application-Level Options false
SIP Server does not include the geo-location
option setting when prioritizing the selection of an outbound gateway or trunk.
SIP Server selects a gateway or trunk from the pool of all configured trunks that are in service based on the prefix match, disregarding the geo-location option (if the priority
option is configured, it will still be considered). If there is more than one trunk in the pool, SIP Server chooses the trunk in a round-robin algorithm that provides equal gateway load. However, if an external party is transferred to an outbound destination, the same gateway that connected the external party to the call is used for the outbound transfer.
Changes Take Effect: For the next call
Determines SIP Server behavior for choosing a gateway or trunk for the outbound call.
fmfm-confirmation-digit
Default Value:
0
Valid Values:
0-9
Changes Take Effect: For the next call
Related Feature: “Find Me Follow Me” on page 257
Specifies the digit that a caller must enter for call confirmation. This digit could be included in the prompt to be used for human recognition. If used, this digit must match the digit in the recorded prompt file. To use a different digit, you must record a new prompt and place the file in the
MCP folder/users folder on the Media Control Platform server host.
fmfm-confirmation-timeout
Default Value:
10
Valid Values: A positive number
Changes Take Effect: For the next call
Related Feature: “Find Me Follow Me” on page 257
Specifies the timeout value, in seconds, that SIP Server waits for a confirmation digit to be entered. Enter a number that includes playing time of the confirmation prompt and time for the confirmation digit to be entered.
Note:
A call is considered abandoned when: the caller hangs up, the entered digit does not match the value of the fmfm-confirmation-digit
option, or the call times out with no input at all.
fmfm-prompt-file
Default Value: Any empty string
Valid Values: A valid filename
Changes Take Effect: For the next call
Related Feature: “Find Me Follow Me” on page 257
Specifies the filename of the confirmation prompt. Must match the path and filename in the MCP folder/users folder on the Media Control Platform server
474 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options host. For example: for the file users/fmfm-confirmation-prompt-0.wav,
set fmfm-prompt-file
to fmfm-confirmation-prompt.
fmfm-trunk-group
Default Value: An empty string
Valid Values: A valid Trunk Group DN name
Changes Take Effect: For the next call
Related Feature: “Find Me Follow Me” on page 257
Specifies the Trunk Group DN where events are generated, when each destination leg connects to Media Server. Enter a Trunk Group DN name that represents Media Server. SIP Server uses that DN to play ringback, and for all outbound calls to Find Me Follow Me destinations.
forced-notready
Default Value: true
Valid Values: true false
The desktop is forced into the
Not Ready
state.
The desktop is not forced into the
Not Ready
state.
Changes Take Effect: Immediately for all future calls
Determines whether the desktop is forced into a
Not Ready
state when it does not respond after a
Preview Interaction
dialog box has been displayed on the desktop.
Note:
This option works with the
options to determine what action to take when a desktop does not respond to a preview interaction before the time expires.
force-p-early-media
Default Value: true
Valid Values: true, false
Changes Take Effect: Immediately
Specifies whether SIP Server adds the
P-Early-Media
header into requests and responses, even if the
P-Early-Media
header with the supported value is not present in the initial
INVITE
message.
Note:
SIP Server supports the
P-Early-Media header in the following messages:
18x
,
200
,
INVITE
,
PRACK
, and
UPDATE
.
graceful-shutdown-sip-timeout
Default Value:
4
Valid Values:
0
–
32
Changes Take Effect: Immediately
Specifies the timeout, in seconds, during which SIP Server re-transmits the
BYE requests that were not confirmed with
200 OK
responses. The timeout starts as
SIP Server—Deployment Guide 475
Chapter 7: SIP Server Configuration Options Application-Level Options soon as the last call is ended. If set to
0
(zero), no
BYE
requests are retransmitted. The timeout applies only when SIP Server processes the graceful shutdown.
greeting-after-merge
Default Value: false
Valid Values: false, true
Changes Take Effect: Immediately
Related Feature: “Personal Greetings” on page 330
If this option is set to false
, a greeting will not be played to an agent or customer when a transfer or conference is completed (8.0.2 backward compatibility support). If the option is set to true
, a greeting will be played to an agent or customer when a transfer or conference is completed.
greeting-call-type-filter
Default Value: No default value
Valid Values: internal, consult, outbound
Changes Take Effect: Immediately
Related Feature: “Personal Greetings” on page 330
Specifies—using a space-, comma-, or semicolon-separated list—the types of calls to which a greeting will not be played. By default (the option has no value), a greeting will be played to all calls (for 8.0.2 backward compatibility).
If the option is set to internal, consult,
and/or outbound
, a greeting will not be played to internal, consultation, and/or outbound calls, respectively.
Note:
You can define this option at both the Application and the
Agent-Login level. The Agent-Login level option takes precedence.
greeting-delay-events
Default Value: false
Valid Values: false, true
Changes Take Effect: Immediately
Related Feature: “Personal Greetings” on page 330
Controls the distribution order of
EventOffHook
and
EventEstablished messages when an agent or customer greeting is played. If the option is set to false
, SIP Server sends
EventOffHook
and
EventEstablished
before the agent or customer greeting starts playing (8.0.2 backward compatibility support). If the option is set to true
, SIP Server sends
EventOffHook
and
EventEstablished when the agent or customer greeting ends. It might cause SIP Server to release
the call on an agent DN in the middle of the greeting if greeting-delay-events
is set to true.
See greeting-stops-no-answer-timeout
for more information.
476 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
greeting-notification
Default Value: An empty string
Valid Values: started
, complete
(one or both, in any order)
Changes Take Effect: Immediately
Related Feature: “Personal Greetings” on page 330
Specifies—using a space-, comma- or semicolon-separated list—whether SIP
Server sends notifications when a greeting starts or ends. The default value (an empty string) means that SIP Server will not send any notification when a greeting starts or ends. If the option is set to started
, SIP Server will send an
EventPrivateInfo
message with
AttributePrivateMsgID
set to
4012
when the greeting starts. If the option is set to complete
, SIP Server will send
EventPrivateInfo
with
AttributePrivateMsgID
set to
4013
when the greeting ends.
greeting-repeat-once-party
Default Value: agent
Valid Values: agent, customer
Changes Take Effect: Immediately
Related Feature: “Personal Greetings” on page 330
If this option is set to agent,
a customer greeting is played continuously until the agent greeting finishes playing (8.0.2 backward compatibility support). If the option is set to customer
, an agent greeting is played continuously until the customer greeting finishes playing.
greeting-stops-no-answer-timeout
Default Value: false
Valid Values: true, false
Changes Take Effect: For the next call
Related Feature: “Personal Greetings” on page 330
(Introduced in SIP Server 8.1.101.86) Set this option to true
in environments where both No-Answer Supervision and Personal Greeting functionality are configured. In this case, SIP Server stops the no-answer timer as soon as a
200
OK
SIP response is received, indicating that the destination party has answered the call. SIP Server does not apply the no-answer action and no-answer overflow to the call even if they are configured in the corresponding options.
The default value of false
is required to preserve the original SIP Server behavior and provide backward compatibility. In this case, SIP Server does not stop the no-answer timer until
EventEstablished
is generated for the destination party. It might cause SIP Server to release the call on an agent DN in the middle of the greeting if
is set to true
.
EventEstablished
on the agent DN is generated only when the greeting is finished.
SIP Server—Deployment Guide 477
Chapter 7: SIP Server Configuration Options Application-Level Options
hide-msml-location
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
When set to true,
SIP Server does not include
X-Genesys-geo-location
and
X-
Genesys-strict-location
headers in
INVITE
messages that it sends to GVP.
Removal of these headers allows SIP Server to stay in control of geo-location selection. This configuration option can be used when all MCPs controlled by
Resource Manager are deployed at the same location and Resource Manager does not need to consider geo-location in the MCP selection process.
When set to false, this feature is disabled.
http-port
Default Value: 0
Valid Values:
0, 1024
-
65535
Changes Take Effect: After SIP Server restart
Related Feature: “HTTP Monitoring Interface” on page 260
Specifies the HTTP interface port number. When set to
0
, the HTTP server is disabled. The port numbers in the range of
1 through
1023
are the system ports and must not be used.
ignore-presence-after-nas
Default Value: true
Valid Values: true, false
Changes Take Effect: At the next call
Specifies whether SIP Server processes or ignores presence SIP messages to change an agent state to
Ready if the no-answer action is set to notready
for an agent.
If set to true,
SIP Server ignores presence SIP messages if the no-answer action is set to notready
for an agent.
If set to false,
SIP Server processes presence SIP messages if the no-answer action is set to notready
for an agent.
Note:
You can define this option at both the Application and the DN levels.
The DN-level option takes precedence.
478 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
ims-3pcc-prefix
Default Value: No default value
Valid Values: A string
Changes Take Effect: Immediately
Notes:
• In order for this option to take effect, the following additional options must also be configured:
enable-ims
(set to true
) override-domain
• For alternative deployment with Mediation Proxy, the value of this option should be
3pcc.
(note the period at the end of this value).
If both ims-3pcc-prefix
and override-domain are configured, then for all 3pcc
INVITE
requests (
INVITE
requests resulting from 3pcc T-Library operations),
SIP Server will add the value of the
ims-3pcc-prefix
option after the user-part of the URI, but before the override-domain
.
For example, if override-domain
is set to genesys.com
, and ims-3pcc-prefix
is set to
3pcc
, then 1pcc calls will use the URI: [email protected]
while 3pcc calls will use the URI: sip:[email protected]
ims-default-orig-ioi ims-default-icid-prefix ims-default-icid-suffix
Default Value: No default value (empty string)
Valid Value: Any sub-string valid for this part of the
P-Charging-Vecto r
Changes Take Effect: Immediately
Specifies the values that SIP Server uses when generating the
P-Charging-
Vector
header for calls originated by SIP Server.
SIP Server uses these option settings to generate the value of the header as follows: icid-value="<ims-default-icid-prefix><uniq-value-generated-by-sipserver><ims-default-icid-suffix>"; orig-ioi=<ims-default-orig-ioi>
For example, the settings ims-default-orig-ioi=genesyslab.com
ims-default-icid-prefix= prefixims-default-icidsuffix=-suffix result in the following ICID value icid-value="prefix-23AAFD4901493123-suffix";orig-ioi=genesyslab.com
SIP Server—Deployment Guide 479
Chapter 7: SIP Server Configuration Options Application-Level Options
ims-propagate-pcvector
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Enables propagation of the
P-Charging-Vector
value. Set this option to true and SIP Server includes the value of the
P-Charging-Vector
from the main call in the private header of the
INVITE
that it sends to the consultation call. This option setting is used to provide a single consistent
P-Charging-Vector
for all legs involved in the consultation call.
For RFC 3455-compliant behavior (a unique ICID for each SIP dialog), set this option to false
. SIP Server will create a unique
P-Charging-Vector
value for the new dialog for the consultation call. This option setting is used for outbound calls, as well as inbound calls to IMS-registered agents. In addition to setting this option to false
, you must also configure the following additional options, which are used to generate the
P-Charging-Vector
value for calls originated by SIP Server:
•
ims-default-orig-ioi
•
ims-default-icid-suffix
•
ims-default-icid-prefix
ims-puid-domain
Default Value: No default value
Valid Values: A string containing a valid domain
Changes Take Effect: After restart
Specifies the domain for the IMS-enabled device that SIP Server uses to generate the PUID for the
P-Asserted-Identity
SIP header, in the case of 3pcc calls initiated on behalf of devices without 3rd party registration. The PUID for the
P-Asserted-Identity
header is formed using one of the following methods
(listed in order of highest to lowest priority):
•
For 1pcc calls, PUID is taken from the corresponding header of the incoming
INVITE
. Since this message contains the PUID of the caller, it is preserved regardless of the destination changes.
•
The option p-asserted-identity
is configured on the caller DN.
•
Address of Record (AOR) of the caller is taken from 3rd party registration
(not applicable to ItalTel).
•
Combination of caller’s DN digits and the value of the override-domain option. Included for backward compatibility. Not to be used for IMS deployments.
•
Combination of caller’s DN digits and the value of the
ims-puid-domain option.
480 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
ims-route
Default Value: No default value
Valid Value: Any valid SIP URI
Changes Take Effect: Immediately
Specifies the value of the
Route
header for calls to IMS destinations that are not registered with SIP Server.
ims-sip-domain
Default Value: No default value
Valid Values: A string containing a valid domain
Changes Take Effect: After restart
Specifies the domain for the IMS-enabled device that SIP Server uses in the
Request-URI
and standard SIP headers (
From
and
To
), when this information is unavailable in the initial
INVITE
or 3rd party registration. In addition, when
IMS changes the
Request-URI
in re-
INVITE
requests (changes upper-case letter in the URI to lower-case letters), SIP Server uses this modified re-
INVITE
.
The URI for standard SIP headers is formed using one of the following methods (listed in order of highest to lowest priority):
•
For 1pcc calls, URI is taken from
Request-URI
of the initial
INVITE
arriving at SIP Server (with user part optionally modified by the Dial Plan, if specified). Not applicable to calls routed or redirected to another device.
•
Combination of DN digits and the value set for the override-domain
option
(for the
Request-URI
and
To
fields) or override-domain-from
option (for the
From
field). Included for backward compatibility. Not to be used for IMS deployments.
•
Address of Record (AOR) taken from 3rd party registration (not applicable to ItalTel).
•
Combination of DN digits and the value of the ims-sip-domain
option.
ims-sip-params
Default Value: none
Valid Values: A string containing valid URI parameters
Changes Take Effect: After restart
Specifies a valid string of SIP URI parameters separated by a semicolon.
Parameters are added to the SIP URIs formed by the SIP Server as explained in the description of the ims-sip-domain option. Parameters specified in the imssip-params
option are only used for the devices where IMS is enabled.
SIP Server—Deployment Guide 481
Chapter 7: SIP Server Configuration Options Application-Level Options
ims-skip-ifc
Default Value: No default value
Valid Value: Any alphanumeric string
Changes Take Effect: Immediately
Specifies the value of the
X-Genesys-SkipFC
private header used to prevent
“double-dipping” for internal calls in an IMS environment. The value must match the condition configured in the Initial Filter Criteria (IFC) for Public IDs served by a particular SIP Server.
ims-use-term-legs-for-routing
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Related Feature: “Routed Calls as Originating or Terminating” on page 263
For use in IMS environments only. When set to true,
SIP Server uses a call-terminating leg to route calls on behalf of the Routing Point after a treatment is applied. When set to false,
SIP Server uses a call-originating leg to route calls after a treatment is applied.
inbound-bsns-calls
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Related Feature: “Business-Call Handling” on page 249
Specifies whether SIP Server considers all established inbound calls on an agent as business calls.
info-pass-through
Default Value: No default value
Valid Values:
*
Allows all
INFO
messages to be sent to the peer connection.
<list>
*,<list> connection.
Allows only those
INFO
messages specified in a commaseparated list of
Content-Type
values (used to define
INFO messages) to be sent to the peer connection.
Allows all
INFO
messages to be sent to the peer connection, except those included in a comma-separated list of
Content-
Type
values.
Changes Take Effect: Immediately
Specifies which SIP
INFO
messages SIP Server will pass to a remote device.
You can use this option to allow all
INFO
messages through to the peer connection, to disable all
INFO
messages from being sent to the peer
482 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options connection, or to specify only those
INFO
messages, as defined by the
Content-
Type
header, that SIP Server will allow. By default, this option is left undefined. In this case, SIP Server passes all
INFO
messages to the peer connection, except for the following:
•
application/vnd.radisys.msml+xml
•
application/x-www-form-urlencoded
•
application/x-detect
(not sent if predictive call is in progress, or if no
AudioCodes CPD result header is found)
•
application/dtmf-relay
(not sent if received from
Voice over IP Service
DNs with service-type
set to any of the following: mcu
, recorder
, moh
, music
, or treatment
.
Note:
You can define this option at both the Application and the DN levels.
The DN-level option takes precedence.
inherit-bsns-type
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Related Feature: “Business-Call Handling” on page 249
Determines whether a consultation call that is made from a business primary call contains the business call
attribute.
init-dnis-by-ruri
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
If this option is set to true
, SIP Server determines what value must be reported as the
DNIS
attribute in T-Library messages for inbound or 1pcc calls, in the following order:
1. A username from the Request-URI—if the extracted value is not empty or
“Anonymous” (case insensitive), then this value is used for the
DNIS attribute. If the value is empty or “Anonymous”, SIP Server goes to Step 2.
2. A username from the
To
header—if the extracted value is not empty or
“Anonymous” (case insensitive), then this value is used for the
DNIS attribute. If the value is empty or “Anonymous”, SIP Server goes to Step 3.
3. A DN name—the destination device that will be used by SIP Server to send an
INVITE
. It can be a DN name of the
Extension
if the destination device is resolved to an extension, or a DN name of the
Trunk
, if the destination device is behind the trunk.
If this option is set to false
(the default), SIP Server takes the username from the
To
header as a value for the
DNIS
attribute.
SIP Server—Deployment Guide 483
Chapter 7: SIP Server Configuration Options Application-Level Options
internal-bsns-calls
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Related Feature: “Business-Call Handling” on page 249
Determines whether SIP Server considers internal calls made to any agent as business calls.
internal-registrar-domains
Default Value:
NULL
Valid Values: Any valid computer names separated by a semicolon (;)
Changes Take Effect: Immediately. Existing subscriptions remain valid.
Specifies the list of logical computer names, registration subscriptions from the endpoints of which are handled by the internal registrar versus an external registrar. For example, if DN
4813
is configured, DN
4814
is not configured, the internal registrar is enabled, and internal-registrar-domains
is set to world, then:
•
REGISTER
from
4813@world
is accepted.
•
REGISTER
from
4813@galaxy is forwarded to the external registrar.
•
REGISTER
from
4814@world
is rejected with
404 Not Found.
internal-registrar-enabled
Default Value: true
Valid Values: true false
SIP Server’s internal registrar is enabled.
All registration subscriptions are proxied to external registrar
Changes Take Effect: Immediately. Existing subscriptions remain valid.
Specifies whether the internal registrar is enabled. When this option is set to false, a
503 Service Unavailable
error is returned for the
REGISTER method.
internal-registrar-persistent
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Enables SIP Server to update the DN attribute contact
in the configuration database. When an endpoint registers, SIP Server takes the contact information from the
REGISTER
request and updates or creates a key called contact
in the
Annex
tab of the corresponding DN.
Set this option to true
only if Hot Standby HA is not used in your environment.
484 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
Note:
SIP Server must have
Full Control
permission for the
DN
objects in order to update a configuration object. By default, it does not have this permission. You need to grant
Full Control
permission for the
System account for the all DNs on the corresponding Switch. It is done for all
DNs at once by changing the permissions for the
System
account on the
DN
folder in the
Switch
object. Or, you can start SIP Server under another account that has
Change
permission on the necessary DNs.
intrusion-enabled
Default Value: true
Valid Values: true false
SIP Server invites the supervisor to the current call.
SIP Server does not invite the supervisor to the current call.
Instead, SIP Server will wait for the next call on the monitored agent’s DN to invite the supervisor.
Changes Take Effect: Immediately
Related Feature: “Call Supervision” on page 143
Determines SIP Server behavior when a
TMonitorNextCall
request is submitted while the monitored agent is on a call.
keep-mute-after-conference
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
When this option is set to true
and a third member of the conference is released, the muted party of the call must use the
TSetMuteOff
request to restore the voice path with a caller. When this option is set to false,
the voice path with a caller is restored automatically when a third member of the conference is released.
legal-guard-time
Default Value:
0
Valid Value: Any integer from
0
–
30
Changes Take Effect: Immediately
Related Feature: “Emulated Agents” on page 248
Specifies a legal-guard time (in seconds) for agents to postpone the transition to the
Ready
state after a business call or after timed ACW. SIP Server always considers a routed call as a business call. The default value of
0
(zero) disables the functionality of this option.
SIP Server—Deployment Guide 485
Chapter 7: SIP Server Configuration Options Application-Level Options
logout-on-disconnect
Default Value: true
Valid Values: true false
The
EventLogout
message is distributed as soon as the client that requested the login disconnects from SIP Server or unregisters the DN in question. The
EventLogout
message is distributed when SIP Server distributes
EventOutOfService
.
The
EventLogout
message is not distributed.
Changes Take Effect: Immediately
Specifies how the
EventLogout
message is distributed.
Note:
This option is not applicable if the agent-logout-on-unreg
option is set to true
.
logout-on-out-of-service
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Specifies whether SIP Server sends
EventAgentLogout
when the agent device goes out of service. If set to true
, SIP Server sends an
EventAgentLogout
if the device on which the agent is logged in goes out of service. If set to false
, SIP
Server does not send the
EventAgentLogout
.
make-call-alert-info
Default Value:
NULL
Valid Value: Any string
Changes Take Effect: Immediately
The contents of this field are passed in the
Alert-Info
header of the
INVITE message sent to the origination party in response to any of the following requests:
•
TMakeCall
•
TInitiateTransfer
•
TInitiateConference
This is used to enable a distinctive ringtone or auto-answer on the originating party’s endpoint.
For example, setting this field to
<file://Bellcore-dr3>
turns on a triple ring on Cisco 7940 endpoints.
486 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
map-sip-errors
Default Value: true
Valid Values: t rue, false
Changes Take Effect: Immediately
Related Feature: “Control of SIP Response Code from within Routing
Specifies whether a T-Library or SIP error code is reported in the
ErrorCode attribute of an
EventError
message in response to a
TRouteCall
request. If set to false
, the SIP status code is reported instead of the T-Library error code.
For example, if routing is made to a busy destination, SIP Server will report the
ErrorCode
attribute of the
EventError
message as
486
.
max-legs-per-sm
Default Value:
0
Valid Values: Any integer from
0
–
65000
Changes Take Effect: Immediately for new legs. Previously created legs are not dropped.
Specifies the maximum number of legs that are created on each connected
Stream Manager. If all connected Stream Managers already have the specified number of legs, no new leg is created.
max-parking-time
Default Value:
0
Valid Values: Any positive integer
Changes Take Effect: Immediately
Related Feature: “Call Park/Retrieve” on page 124
Specifies the timeout, in seconds, after which a call parked on the gcti::pbxpark
device will return to the original DN. If you set this option to
0, no timers are started and calls will remain parked indefinitely.
monitor-consult-calls
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Related Feature: “Monitoring Consultation Calls” on page 146
Specifies whether SIP Server will monitor consultation calls. If you set this option to false
, SIP Server does not monitor consultation calls. This is default behavior. To enable monitoring of consultation calls, set this option to true
.
SIP Server will monitor all calls made to or from an agent under supervision.
SIP Server—Deployment Guide 487
Chapter 7: SIP Server Configuration Options
488
Application-Level Options
monitor-internal-calls
Default Value: true
Valid Values: true false
SIP Server starts monitoring sessions for all calls on the DN where call supervision subscription is active.
SIP Server starts monitoring sessions only if external parties participate in the call.
Changes Take Effect: Immediately
Related Feature: “Call Supervision” on page 143
Specifies SIP Server behavior to start monitoring sessions.
monitor-party-on-hold
Default Value: true
Valid Values: true, false
Changes Take Effect: After SIP Server restart
Related Feature: “Customer-on-Hold Privacy” on page 148
When this option is set to true
(the default), the supervisor in the Whisper or in the Silent mode might be able to hear the customer if the agent has put the call on hold and there are no other active participants in the call.
When this option is set to false
, the supervisor in the Whisper or Silent mode is not be able to hear the customer if the customer is an external party, the agent has put the call on hold, and there are no other active participants in the call.
msml-enable-record-extensions
Default Value: true
Valid Value: true, false
Changes Take Effect: Immediately
When this option is set to true,
SIP Server sends the recording parameters in the
INFO
message to Media Server while restarting recording for a particular
DN for which a
TPrivateService
request with recording parameters was issued earlier. When this option is set to false,
SIP Server does not send recording parameters when it restarts recording.
msml-location-alarm-timeout
Default Value:
0
Valid Values:
0-65535
Changes Take Effect: Immediately
Related Feature: “Geo-Location for MSML-Based Services: Strict Matching” on page 401
Enables a configurable alarm when a connection that involves an MSML DN and is restricted by geo-location, cannot be established. SIP Server maintains an alarm log of failed attempts and will display a
52052
message that lists those failures. The value of this option is the number of seconds between displays.
When the value is
0
or this option is not configured, no alarms are raised.
Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
msml-mute-type
Default Value:
1
Valid Values:
1, 2
Changes Take Effect: Immediately
Related Feature: “Muting/Unmuting a Party in a Conference” on page 173
Specifies the type for muting/unmuting a party in a conference. Type 1 is required to support remote mute functionality in SIP Server. Type 2 is for backward compatibility.
Warning!
Use this option only when requested by Genesys Customer Care.
msml-oos-recover-enabled
Default Value: false
Valid Value: true, false
Changes Take Effect: Immediately
Determines how SIP Server handles the scenario in which it detects a
Voice over IP Service
DN ( service-type=msml
) as out of service. If set to true,
SIP
Server re-connects the applied treatment, conference services, or music services—music on hold or music in queue—with an alternate
Voice over IP
Service
DN ( service-type=msml
). If set to false,
SIP Server does not reconnect the treatment, conference, or music services. This option takes effect only if Active Out-Of-Service Detection is enabled.
msml-record-support
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Related Feature: “Call Recording—MSML-Based” on page 130
Set this option to true
to enable MSML-based call recording. If using
NETANN service, set this option to false
.
Note:
Earlier versions of Genesys Media Server (prior to release 8.1.4) do not support MSML-based call recording. If msml-support
is set to true
, but NETANN is required for call recording services only, set msml-record-support
to false
. This allows NETANN for call recording and MSML for other media services.
msml-record-metadata-support
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Specifies whether SIP Server, while starting call recording, sends additional metadata in the
INFO
message to Genesys Media Server. If set to false
(the default), SIP Server does not include additional metadata in the
INFO
message.
SIP Server—Deployment Guide 489
Chapter 7: SIP Server Configuration Options Application-Level Options
If set to true
, SIP Server sends additional metadata to the Genesys Media
Server for use in Genesys Media Server file-based call recording.
msml-support
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Related Features: “Outbound IP Solution Integration” on page 317
Media Server Integration” on page 95
Enables SIP Server to engage Genesys Voice Platform (GVP) as a media server through the MSML protocol. Set this parameter to true
when integrating SIP Server into the Outbound IP Solution and/or when integrating with Genesys Media Server.
Outbound IP Integration. Set this option to true
when SIP Server is used as part of the Outbound IP Solution. In this mode SIP Server processes
TMakePredictiveCall
requests by engaging GVP configured as a
Voice over IP
Service
DN with service-type
set to msml
, or as a
Trunk Group DN
.
Genesys Media Server Integration. Set this option to true
to enable MSML service for all media services operations (treatments, music, greetings and conferences) using the Genesys Media Server. If set to true
, SIP Server engages the Genesys Media Server configured as a
Voice over IP Service
DN with service-type set to msml
. If using NETANN service through Stream
Manager, set this option to the default false
.
music-in-conference-file
Default Value: The value is taken from the default-music
Valid Values: A string containing the valid name of the music file
Changes Take Effect: Available for next 3pcc or 1pcc hold operation
Related Feature: “Silence Treatment in Conference” on page 171
Specifies the silent audio file to be played in applicable conferences (more than two active participants). If the conference has only two active participants, then the music file defined in the default-music
option will be played for the other party when the call is placed on hold. For conferences with more than two active participants, the music-in-conference-file
option is used for a silent MOH treatment instead. Recommended value is music/silence
.
For example, if a supervisor in silent monitoring mode listens to a call between a customer and an agent, the supervisor is not considered an active participant.
If the agent or customer places the call on hold, the remaining participants will hear the default-music MOH treatment. However, if the supervisor places the call on hold, the music/silence file is played instead, so the customer and agent can continue their conversation undisturbed.
490 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
music-in-queue-file
Default Value: No default value
Valid Value:
<default_music_directory>/<file_name>
Changes Take Effect: Immediately for all new calls
Related Feature: “Playing Music to Calls in Queue” on page 198
Specifies the file name of the music file to be played when a call is queued on a particular ACD Queue.
Notes:
This option is set at the SIP Server Application level. At the
Switch/DN level, the option default-music
is used instead to specify the file for music-in-queue. This default-music
setting at the DNlevel takes precedence over the Application-level music-in-queuefile
setting.
If there is no value specified for either option, the value of the Media
Server DN request-uri
option is used instead.
music-listen-disconnect
Default Value: music/on_hold
Valid Values: The path to any valid audio file
Changes Take Effect: For the next
TListenDisconnect
request
Related Feature: “Private Conversations During Conference” on page 172
Specifies the path to an audio file to be played to the temporary disconnected party from the conference.
music-on-pbxpark
Default Value: No default value
Valid Values: Path to a valid audio file
Changes Take Effect: Immediately
Related Feature: “Call Park/Retrieve” on page 124
Specifies the music file to be played to the remote party when a call is parked on the gcti::pbxpark
device.
mwi-agent-enable
Default Value: false
Valid Values: true false
MWI for the agent’s voice mail box is enabled.
MWI for the agent’s voice mail box is disabled.
Changes Take Effect: Immediately
Related Feature: “Message Waiting Indicator Functionality” on page 117
Enables or disables MWI for the agent’s voice mail box.
SIP Server—Deployment Guide 491
Chapter 7: SIP Server Configuration Options Application-Level Options
mwi-domain
Default Value: No default value
Valid Value: Any computer name
Changes Take Effect: During the next attempt to register for MWI
Related Feature: “Message Waiting Indicator Functionality” on page 117
Specifies the computer name in the URI of the
REGISTER
request. SIP Server sends this information to Asterisk in order to initiate MWI. The value of this option must be a computer name that is recognized by Asterisk.
mwi-extension-enable
Default Value: false
Valid Values: true false
MWI for the extension’s voice mail box is enabled.
MWI for the extension’s voice mail box is disabled.
Changes Take Effect: Immediately
Related Feature: “Message Waiting Indicator Functionality” on page 117
Enables or disables MWI for the extension’s voice mail box.
mwi-group-enable
Default Value: false
Valid Values: true false
MWI for the agent group’s voice mail box is enabled
MWI for the agent group’s voice mail box is disabled.
Changes Take Effect: Immediately
Related Feature: “Message Waiting Indicator Functionality” on page 117
Enables or disables MWI for the agent group’s voice mail box.
mwi-host
Default Value: No default value
Valid Values: Any host name or IP address
Changes Take Effect: During the next attempt to register for MWI
Related Feature: “Message Waiting Indicator Functionality” on page 117
Specifies the host name of the Voice Mail system to get MWI notification from the host where Asterisk is running. SIP Server will send a
REGISTER
request to mwi-host:mwi-port
to initiate MWI.
mwi-implicit-notify
Default Value: No default value
Valid Values: true, false
Changes Take Effect: Immediately
Specifies whether SIP
NOTIFY
requests are sent to an endpoint regardless of subscription, for integration with Genesys SIP Feature Server.
492 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
If set to true
, SIP Server sends the
NOTIFY
even if it has not received a
SUBSCRIBE
from the phone. If set to false
, SIP Server sends the
NOTIFY
to the phone only if it has subscribed for the event message-summary
.
If this option is not defined, SIP Server does not send any
NOTIFY
to the phone.
Note:
Genesys recommends that, if you require MWI but your phone does not send
SUBSCRIBE
, set this option to true.
For more information about integrating with SIP Feature Server, see
SIP Feature Server 8.1 Deployment Guide.
mwi-mode
Default Value:
SUBSCRIBE
Valid Values:
REGISTER, SUBSCRIBE
Changes Take Effect: After SIP Server restart
Related Feature: “Message Waiting Indicator Functionality” on page 117
When this option is set to
SUBSCRIBE,
SIP Server activates SIP subscriptions for all voice mail box owners as configured by other mwi-<>
options. If set to
REGISTER, the MWI functionality is enabled using the
REGISTER
SIP request method. For backward compatibility with the previous SIP Server releases, set this option to a value of
REGISTER
.
mwi-notify-unregistered-dn
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Specifies whether SIP
NOTIFY
requests are sent to an endpoint regardless of SIP registration. This setting is required for integration with Genesys SIP Feature
Server:
•
If set to true,
SIP Server sends the MWI
NOTIFY
to the phone even if the phone has not registered.
•
If set to false,
SIP Server sends the MWI
NOTIFY
to the phone only if the phone has registered with SIP Server.
Note:
The above functionality works with the option mwi-implicit-notify
.
The mwi-notify-unregistered-dn
option must to be set false
to support the above functionality.
SIP Server—Deployment Guide 493
Chapter 7: SIP Server Configuration Options Application-Level Options
mwi-port
Default Value: No default value
Valid Value: Any available port
Changes Take Effect: During the next attempt to register for MWI
Related Feature: “Message Waiting Indicator Functionality” on page 117
Specifies the port of the Voice Mail system to get MWI notification from the port where Asterisk is running. SIP Server will send a
REGISTER
request to mwi-host:mwi-port
to initiate MWI.
mwi-subscribe-vmb
Default Value: false
Valid Values: false, true
Changes Take Effect: Immediately
Related Options: mwi-implicit-notify ,
Specifies whether SIP Server accepts MWI subscriptions that are submitted for a voice mailbox. If set to true,
SIP Server accepts MWI subscriptions for voice mailbox numbers and for DNs. If set to false
(the default), SIP Server accepts MWI subscriptions for only DNs.
In addition, the mwi-implicit-notify
option must be set to false,
and the mwinotify-unregistered-dn
option must be set to true
to support this feature.
Note:
This feature requires SIP Feature Server version 8.1.2 or later.
nas-private
Default Value: false
Valid Values:
true, false
Changes Take Effect: Immediately
Related Feature: “No-Answer Supervision” on page 313
Specifies whether No-Answer Supervision is enabled for private calls.
You can set this option at the Application and Switch/Agent Login or
Switch/DN level (DN of type
Extension
). When set at the Application level, the option value is applied globally to all private calls. When set at the Switch level, the option value is applied to a particular DN or Agent Login.
Note:
The option setting at the Switch level takes precedence over the
Application level setting.
494 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
network-monitoring-timeout
Default Value:
1
Valid Values:
1-30
Changes Take Effect: Immediately
Dependent Options: sip-nic-address ,
,
Related Feature: See “Network Status Monitoring” in the
SIP Server 8.1 High-
Availability Deployment Guide.
Defines the time interval (in seconds) for which SIP Server checks the network status of:
•
The SIP NIC, if a dedicated NIC is used and the sip-nic-address
option is configured.
•
The T-Library NIC, if the value of the tlib-nic-monitoring
option is set to t rue.
•
The Virtual IP address for the IP Address Takeover configuration, if the value of the sip-iptakeover-monitoring
option is set to true.
observing-routing-point
Default Value: No default value
Valid Values: A
Routing Point
DN
Changes Take Effect: For the next call
Related Feature: “Remote Supervision” on page 158
Specifies the service observing Routing Point used for Multi-Site Supervision of the agents, whose endpoints are controlled by this SIP Server. This option must contain a number of a valid
Routing Point
DN in order for the Multi-Site
Supervision feature to work. No routing strategy is required to be loaded on the observing Routing Point.
operational-stat-timeout
Default Value:
10
Valid Values:
3-65535
Changes Take Effect: Immediately
Related Feature: “Call Recording—MSML-Based” on page 130 , “HTTP
Monitoring Interface” on page 260
Specifies how often, in seconds, a local LCA is queried for system information such as CPU and memory usage. This information is then written into the SIP
Server Operational Information log as defined in the SIP Server configuration.
Note:
This functionality requires Management Framework 8.1.2 or later.
SIP Server—Deployment Guide 495
Chapter 7: SIP Server Configuration Options Application-Level Options
outbound-bsns-calls
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Related Feature: “Business-Call Handling” on page 249
Specifies whether SIP Server considers all established outbound calls on an agent as business calls.
overflow-location-map
Default Value: No default value (empty string)
Valid Values: Any valid string with comma-separated elements
Changes Take Effect: On the next call
Related Feature: “Geo-Location for MSML-Based Services: Strict Matching” on page 401
This option creates an association between geo-location labels and overflowlocation labels, to support strict geo-location matching.
The format of the option is: geo-location label=overflow-location label
.
For example, in labelA=labelB,labelC=labelD
... labelA
and labelC
are geo-location labels; labelB
and labelD
are overflowlocation labels.
If services or resources that match the call by geo-location=labelA
are not available, SIP Server will try services or resources that matches the call by overflow-location=labelB
.
overload-ctrl-call-rate-capacity
Default Value:
200
Valid Values:
0-10000
Changes Take Effect: Immediately
Related Feature: “Overload Control” on page 324
Specifies the Call Rate (calls/sec) that SIP Server is able to maintain without performance degradation. For example, SIP Server instances deployed on host machines with a slower CPU would use a lesser option value. This capacity
must be set to a value at least 2 times higher than the overload-ctrl-threshold
(enforced by SIP Server). If you set this option to
0,
SIP Server does not monitor this load factor.
overload-ctrl-call-tapplytreatment-requests-rate
Default Value:
0
Valid Values:
0-1000
Changes Take Effect: Immediately
Related Feature: “Overload Control” on page 324
Specifies the
TApplyTreatment
request rate (T-Requests/sec) allowed for each call. If the T-Request rate for any particular call exceeds the configured value,
496 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
SIP Server first sends a warning and, if T-Requests continues to increase, SIP
Server rejects excessive
TApplyTreatment
requests for that particular call.
Setting the value of the option to
0
(zero) disables this functionality.
overload-ctrl-call-trequests-rate
Default Value:
0
Valid Values:
0-1000
Changes Take Effect: Immediately
Related Feature: “Overload Control” on page 324
Specifies the T-Request rate (T-Requests/sec) 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. Setting the value of the option to
0
(zero) disables this functionality.
overload-ctrl-call-tupdateuserdata-requests-rate
Default Value:
0
Valid Values:
0-1000
Changes Take Effect: Immediately
Related Feature: “Overload Control” on page 324
Specifies the User Data update T-Request (
TAttachUserData,
TUpdateUserData, TDeleteUserData, TDeletePair
) rate (T-Requests/sec) 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. Setting the value of the option to
0
(zero) disables this functionality.
overload-ctrl-dialog-rate-capacity
Default Value:
400
Valid Values:
0-10000
Changes Take Effect: Immediately
Related Feature: “Overload Control” on page 324
Specifies the SIP Dialog Rate (dialogs/sec) that SIP Server is able to maintain without performance degradation. For example, SIP Server instances deployed on host machines with a slower CPU would use a lesser option value. This
capacity must be set to a value at least 4 times higher than the overload-ctrlthreshold
(enforced by SIP Server). If you set this option to
0
, SIP Server does not monitor this load factor.
SIP Server—Deployment Guide 497
Chapter 7: SIP Server Configuration Options Application-Level Options
overload-ctrl-threshold
Default Value:
0
Valid Values:
0-65535
Changes Take Effect: Immediately
Related Feature: “Overload Control” on page 324
Specifies the call rate (calls/second) after which the Dialog Rate and Call Rate overload control mechanism becomes active. To disable the Dialog Rate and
Call Rate mechanism, set this option to the default (
0)
.
overload-ctrl-trequests-rate
Default Value:
0
Valid Values:
0-10000
Changes Take Effect: Immediately
Related Feature: “Overload Control” on page 324
Specifies the T-Request rate (T-Requests/sec) that SIP Server is able to maintain without performance degradation. For example, if SIP Server is deployed on host machines with a slow CPU, then set this option to a lesser value. If the T-Request rate exceeds a configured value, SIP Server first sends a warning and, if T-Requests continue to increase, SIP Server rejects excessive
T-Requests. Setting the value of the option to
0
(zero) disables this functionality.
override-to-on-divert
Default Value: false
Valid Values: true false
The username is equal to the destination DN.
The username is equal to the Routing Point or ACD Queue number.
Changes Take Effect: Immediately
Controls the username part of the
To
header URI for outgoing
INVITE
messages when a call is diverted from a Routing Point or an ACD Queue. This option setting also applies to 1pcc transfers (using the
REFER
method). If set to true,
SIP Server takes the value of the
REFER
-to DN as the username part of the
To header. If set to false,
SIP Sever takes the value of the
From
DN (originator of the
REFER
message) for the username part of the
To
header.
Note:
This option can also be configured at the DN level. The DN-level setting takes precedence over the Application-level setting.
498 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
p-asserted-identity
Default Value: No default value (empty string)
Valid Values: Any string in accordance with RFC 3325
Changes Take Effect: For the next call
Related Feature: “Network Asserted Identity” on page 303
Related Option: “privacy” on page 589
Specifies the preferred SIP URI or telephone number that SIP Server inserts in the
P-asserted-identity
header of
INVITE
messages, when required according
to the scenarios described in “Network Asserted Identity” on page 303 . If
enabled, SIP Server adds this value to the content of the
P-asserted-identity header for all dialogs—unless otherwise specified at the DN-level.
parking-music
Default value: music/silence
Valid Values:
Changes Takes Effect: For the next parked call
Related Feature: “Remote Supervision” on page 158
Specifies the music file, which is played to the remote party parked on the gcti::park
DN.
partition-id
Default Value: SIP Server default partition
Valid Values: Any string (the name of one partition)
Changes Take Effect: Immediately
Application-level: Specifies the default partition for the particular SIP Server application.
DN-level: Specifies the partition to which this DN belongs. If you leave the option undefined, SIP Server considers the DN as belonging to the default partition. You can only define this option on
Trunk
and
Voice over IP Service
type DNs.
SIP Server assigns a partition to each call based on the call origination device.
If the call origination device does not have a defined partition-id
parameter, the call is assigned to the default partition. SIP Server uses information about partition-id in two ways:
1. To select a
Voice over IP Servic e DN for a call.
2. To select a
Trunk
DN for the outbound call.
If multiple resources (
Voice over IP Service
DNs or
Trunk
DNs) are available for call processing, SIP Server selects one that belongs to a call partition.
SIP Server—Deployment Guide 499
Chapter 7: SIP Server Configuration Options Application-Level Options
posn-no-answer-overflow
Default Value: No default value.
Valid Values: none recall release
Any valid overflow destination
SIP Server does not attempt to overflow a call on a position when posn-no-answer-timeout
expires.
SIP Server returns the call to the last distribution device (the device reported in the
ThisQueue
attribute of the call) when posn-no-answer-timeout
expires.
SIP Server releases the call.
SIP Server returns the call to the specified destination when the value set for the posn-no-answer-timeout
Changes Take Effect: Immediately
Related Feature: “No-Answer Supervision” on page 313
option expires.
Specifies a sequence of overflow destinations (separated by comma) that SIP
Server attempts to overflow to when the time specified in option posn-no-answer-timeout expires. SIP Server attempts to overflow in the order specified in the list.
•
When all overflow attempts fail, SIP Server abandons overflow. See also extension
NO_ANSWER_OVERFLOW
.
•
When the list of overflow destinations contains the value recall
and the call was not distributed, SIP Server skips to the next destination in the list.
SIP Server obtains the value for this option in the following order of precedence:
1.
no-answer-overflow if defined at a DN level of type
ACD Position
.
2.
posn-no-answer-overflow if defined at a SIP Server Application level.
posn-no-answer-timeout
Default Value:
15
Valid Value: Any integer from
0
–
600
Changes Take Effect: Immediately
Related Feature: “No-Answer Supervision” on page 313
Defines the default no-answer timeout (in seconds) that SIP Server applies to any device of type position.
When the timeout ends, SIP Server executes the actions defined in option posn-no-answer-overflow.
If set to
0, the No Answer Supervision feature for
DN s of type
ACD Position
is disabled. See the
NO_ANSWER_TIMEOUT
extension in section “Using the
Extensions Attribute” on page 422 for more information about how this option
is used. SIP Server obtains the value for this option in the following order of precedence:
1.
no-answer-timeout if defined at a DN level of type
ACD Position
.
2.
posn-no-answer-timeout if defined at a SIP Server
Application
level.
500 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
predictive-call-router-timeout
Default Value:
0
Valid Value: Any non-negative integer
Changes Take Effect: After SIP Server restart
Related Option:
Specifies the maximum time (in seconds) that an answered predictive call can wait on a Routing Point DN for either: A) any Universal Routing Server (URS) request, or B) an agent to answer the call after a successful URS request. If no request is made during this timeout period, the call is dropped. This feature is intended as a clean-up mechanism for scenarios where URS becomes nonoperational or the agent does not answer the call.
SIP Server clears the timer after receiving the
TApplyTreament
, or if the routertimeout
is activated for any new request coming in for the call. For example, a
TRouteCall
request.
For Active Switching Matrix (ASM) and Proactive Notification modes, the timeout defines the maximum time that an answered predictive call will wait on a
Trunk Group
DN for a
TMergeCall
request from Outbound Contact Server
(OCS). If no request arrives during this time, SIP Server drops the call. SIP
Server clears the timer when the
Trunk Group
DN receives the
ApplyTreatment message, or if the router-timeout
is activated for any new request coming in for the call.
The default value of
0
(zero) disables the predictive-call-router-timeout functionality. If it is disabled, then
TMakePredictiveCall
requests are timed using the router-timeout option.
preview-expired
Default Value:
90
Valid Values: Any positive integer
Changes Take Effect: Immediately for future calls
Related Feature: “Preview Interactions” on page 348
Specifies the time (in seconds) that the
Preview Interaction
dialog box remains open on a desktop. After the time expires, the dialog box closes and the desktop changes to a Not Ready
state.
Note:
The preview-expired
option works with the
and
options to determine what action to take when a desktop does not respond to a preview interaction before the time expires.
SIP Server—Deployment Guide 501
Chapter 7: SIP Server Configuration Options Application-Level Options
privacy
Default Value: No default value (string is empty)
Valid Values: id
—as defined in RFC 3325: Private Extensions to the Session
Initiation Protocol (SIP) for Asserted Identity within Trusted Networks
Changes Take Effect: For the next call
Related Feature: “Network Asserted Identity” on page 303
Specifies the level of privacy requested by the DNs in this switch, as described by the Network Asserted Identity feature. If set to id,
SIP Server includes the
Privacy:id
header in SIP messaging. If not configured, SIP Server does not include the
Privacy:id header (privacy is not requested by the DNs for this switch, unless otherwise specified at the DN level).
reason-in-extension
Default Value: true
Valid Values: true, false
Changes Take Effect: Immediately
Specifies whether SIP Server includes the
ReasonCode
in either the
Extensions or
Reason
Attribute in
EventAgentNotReady
messages.
If set to true,
SIP Server includes the key-value pair
Reasoncode
with the value private-call
in the
Extensions
Attribute of the
EventAgentNotReady
message sent in response to a SIP
NOTIFY
message stating that there is an active call on the private line DN.
If set to false,
this key-value pair is included instead in the
Reason
Attribute of the
EventAgentNotReady
message.
record-after-merge
Default Value: false
Valid Values: false, true
Changes Take Effect: Immediately
If this option is set to false,
SIP Server will not start recording for agents who are moved from a consultation call to a main call when a transfer or conference is completed (8.0.2 backward compatibility support). If the option is set to true,
SIP Server will start the recording for agents who are moved from the consultation call to the main call after the transfer or conference is completed.
Note:
This option is not needed in a consultation-call-recording-enabled environment ( record-consult-calls=true
) and recording must be enabled on the agent to start the recording.
502 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
record-agent-greeting
Default Value: false
Valid Values: true, false
Changes Take Effect: For the next call
Specifies whether the agent greeting or the customer greeting must be recorded when both recording and greeting are enabled for the call.
If set to true,
the agent greeting is recorded.
If set to false,
the customer greeting is recorded.
record-consult-calls
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately (established connections remain unaffected)
Related Feature: “Call Recording—NETANN-Based” on page 126
Related Option:
Specifies whether consultation calls are eligible for regular call recording.
If set to false,
SIP Server does not allow recording for consultation calls even if one or more of the participating DNs are set for call recording ( record option on the DN is set to true,
or the DN is the party specified in the record extension of a TRouteCall
request).
If set to true,
SIP Server allows recording of consultation calls that include at least one appropriately set DN.
record-moh
Default Value: true
Valid Values: true, false
Changes Take Effect: Immediately
Related Feature: “Recording Calls Without Music-on-Hold Treatment” on page 133
Related Option:
Specifies whether the music-on-hold treatment is recorded during call recording.
If set to false,
SIP Server pauses the recording when the call is placed on hold and the music-on-hold treatment will not be recorded. SIP Server resumes the recording when the call is retrieved.
If set to true,
the music-on-hold treatment is always recorded during call recording.
Note:
This option is applicable only if
true
and the
MSML configuration is used for recording.
SIP Server—Deployment Guide 503
Chapter 7: SIP Server Configuration Options Application-Level Options
recording-failure-alarm-timeout
Default Value:
0
Valid Values:
0
–
65535
(seconds)
Changes Take Effect: Immediately
Related Feature: “Call Recording Alarms” on page 135
Enables call recording alarm notification. When this option is set to a value other than
0
(zero), and a call recording failure is detected, SIP Server generates a
52051
alarm message and starts the timer using the interval defined by this configuration option. 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. If the timer expires and no recording failures have been detected within the past interval, SIP Server does not generate an alarm message.
Setting this option to
0
(zero) disables the feature.
Note:
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.
recording-filename
Default Value:
NULL
Valid Values: Any valid file name using the variables specified below
Changes Take Effect: When the next call recording is initiated
Related Feature: “Call Recording—NETANN-Based” on page 126
Specifies the file name for call recording when call recording is initiated automatically, according to the SIP Server configuration. When this option contains a value, the generated file name is added as
UserData
to the call with the
GSIP_REC_FN
key. When this option does not contain a value, the file name is the
UUID
of the call.
The following variables are used when creating the file:
$ANI$
:
$DNIS$
:
$DATE$
:
$TIME$
:
$CONNID$
:
$UUID$
:
$AGENTID$
:
$AGENTDN$
:
The calling number.
The called number.
The current date (GMT) in the Y-M-D format.
The current time (GMT) in the H-M-S format.
The
The
UUID
of the call.
The
Connection ID
Agent Login
of the call.
ID, if the agent is logged in on the device where the call recording is initiated.
The
DN
where the call recording is initiated.
504 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
refer-enabled
Default Value: true
Valid Values:
true, false
Changes Take Effect: With the next new call
Specifies whether the
REFER
method is sent to an endpoint. If set to true, the
REFER
method is sent to:
•
The call party that originates a
TMakeCall
request.
•
The call party that initiates a consultation call.
•
The call party that is transferred to another destination during a single-step transfer.
If set to false,
SIP Server uses the re-
INVITE
method instead.
For IMS deployments: When integrated with an IMS environment, you must set this option to false
either globally on the Application, or individually on all
IMS-enabled DNs.
registrar-default-timeout
Default Value:
1800
Valid Values:
0-4294967295
Changes Take Effect: At the next
REGISTER
dialog
Specifies the expiration timeout for a
REGISTER
request as a value (in seconds) in the
200 OK
response that is sent by SIP Server to the SIP endpoint. When the option is set to
0,
or is not defined, the Expires header value from the
REGISTER request is used as the expiration timeout. If the option is set to any value other than
0,
the timeout is set to the lesser of the option value and the value specified by the client.
For IMS deployments: With SIP Server integrated into an IMS environment, you can either leave this option undefined (no timeout), or set this option to the maximum value (
3600
). A smaller number can result in the expiry of DN registrations in SIP Server, because IMS does not propagate SIP Server responses back to the endpoint, so it will not refresh the registration.
Note:
Genesys recommends that you do not set this option to a value less than 64 seconds. This guarantees that a new registration will not arrive within the SIP Server default interval of 32 seconds, which is the default value for keeping a non-responded SIP transaction alive.
releasing-party-report
Default Value: false
Valid Values:
true, false
Changes Take Effect: Immediately
Related Feature: “Call Release Tracking” on page 142
Specifies whether SIP Server reports the
Extensions
attribute key
ReleasingParty
in events
EventReleased and
EventAbandoned to indicate which party initiated the call release.
SIP Server—Deployment Guide 505
Chapter 7: SIP Server Configuration Options Application-Level Options
resolve-external-contact
Default Value: false
Valid Values: true, false
Changes Take Effect: For the next call
Specifies whether SIP Server resolves the contact as external if the internal resolution has failed. The value will be taken from the trunk which was the source of the OOSP-causing message, which is the trunk to the transfer initiator party.
This option affects only processing of the OOSP (Out Of Signaling Path) transfer SIP operations, specifically
REFER
requests or
302
responses. It applies only to DNs of type
Trunk.
SIP Server tries to find the destination device using the URI in the OOSP message, as follows:
•
Resolving the user part—SIP Server searches among locally configured and registered DNs and tries to match trunk prefixes.
•
If no matching DNs are found and if the resolve-external-contact
option is set to true,
SIP Server tries to find the destination trunk by matching the domain part of the received URI with the contact of the configured
Trunk
DNs.
Note:
This option can also be configured at the DN level. The DN-level setting takes precedence over the Application-level setting.
resolve-internal-rp-by-host
Default Value: false
Valid Values: false, true
Changes Take Effect: For next call
In Business Continuity deployments, SIP Server can correctly resolve where to send a request when two different sites have a Routing Point configured with the same DN number. When set to true
, SIP Server will include host information when resolving the internal Routing Point number.
When set to false
(the default), enables the previous behavior in SIP Server.
resolve-sip-address
Default Value: false
Valid Values: true, false
Changes Take Effect: After restart
If set to true, SIP Server will resolve the hostname in the
OtherDN
URI of the
RequestRouteCall
to its corresponding IPv4 address, which it then uses in the
302 Contact
message. Resolution through DNS is only done once, and will be stored in the internal server table. The corresponding IPv4 address will be extracted from this table for any similar subsequent
RequestRouteCall
. SIP
Server must be restarted for a new IP address to be assigned to an FQDN.
506 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
resource-management-by-RM
Default Value: true
Valid Values: true, false
Changes Take Effect: Immediately
Specifies whether SIP Server communicates with Genesys Media Server through the GVP Resource Manager, or with the media server directly. When integrating with Genesys Media Server, Genesys recommends that you include both Resource Manager (to handle media service distribution) and GVP Media
Control Platform (to provide the media service itself) in the deployment. This is the default ( true
) behavior. For direct integrations with the media server, set this option to false
.
restart-period
Default Value:
20
Valid Values:
0
–
600
Changes Take Effect: Immediately
Specifies the interval (in seconds) that SIP Server waits between attempts to reconnect to the switch when the link fails. A value of
0
(zero) means SIP
Server does not try to reconnect unless the link configuration is changed.
route-failure-alarm-high-wm
Default Value:
10
Valid Values: Positive integer for absolute value or floating point number followed by % (percent) symbol. For example—10%, 2.25%, 5E-2%.
Changes Take Effect: Immediately
Related Feature: See “Failed Route Notification” on page 256
Defines the high water mark which must be reached in order for a route failure alarm to be triggered, within the period configured in the route-failurealarm-period
configuration option.
route-failure-alarm-low-wm
Default Value:
1
Valid Values: Positive integer for absolute value or floating point number followed by % (percent) symbol. For example—10%, 2.25%, 5E-2%.
Changes Take Effect: Immediately
Related Feature: See “Failed Route Notification” on page 256
Defines the low water mark which must be reached, while under the route failure alarm condition, within the period configured in the route-failurealarm-period
configuration option.
Note:
This option also specifies the minimum time between alarm setting and alarm clearing.
SIP Server—Deployment Guide 507
Chapter 7: SIP Server Configuration Options Application-Level Options
route-failure-alarm-period
Default Value:
0
Valid Values: Positive integer
Changes Take Effect: Immediately
Related Feature: See “Failed Route Notification” on page 256
Defines the interval (in seconds) in which the number of failed route requests is totalled, in order to determine either a possible route failure alarm or the cancelation of an alarm, based on the failed route counter reaching the relevant high or low water mark.
ring-tone
Default Value: music/ring_back
Valid Values: Name and path of any valid audio file
Changes Take Effect: Immediately for all new calls
Specifies the audio file to be played for the
RingBack
treatment.
ringing-on-route-point
Default Value: true
Valid Values: true false
SIP Server responds with
a 180 Ringing message.
SIP Server does not respond with a
180 Ringing
message.
Changes Take Effect: Immediately
Specifies whether SIP Server responds with a
180 Ringing message when a call arrives at a Routing Point. It enables transfers for calls waiting at Routing
Points. The disadvantages are:
•
Possible undesirable ringback tone.
•
Multiple ringing messages delivered for the same call.
router-timeout
Default Value:
10
Valid Value: Any non-negative integer
Changes Take Effect: Immediately
Specifies the maximum time (in seconds) that a call remains on a Routing
Point without a treatment. If the timeout is triggered, the call is sent to the DN specified in
default-dn
.
508 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
rp-use-dial-plan
Default Value: default
Valid Values: default, full, partial, false
Changes Take Effect: Immediately
Related Feature: “Dial Plan” on page 210
Specifies how SIP Server applies the dial plan:
•
default
—For a SIP Server dial plan, the same as the false
value. For a
Feature Server dial plan, the same as the partial
value.
•
full
—The dial plan is applied to the destination of
TRouteCall
, including the digit translation and forwarding rules.
•
partial
—Only the digit translation is applied to a dial-plan target.
Forwarding rules, such as forwarding on no answer ( ontimeout
), forwarding on busy ( onbusy
), forwarding on DND ( ondnd
), forwarding on no response ( onunreach
), and forwarding on not SIP registered ( onnotreg
) are not applied. Valid for both SIP Server and SIP Feature Server dial plans.
•
false
—No dial plan is applied to the destination of
TRouteCall
.
Note:
If the SIP Server dial plan is used, SIP Server selects the dial plan assigned to the caller. This is the dial plan configured for the
DN/Agent Login of the DN for internal calls, or the Trunk DN for inbound calls, or the Application-level option if no DN/Agent-Loginlevel dial plan is configured.
send-200-on-clear-call
Default Value: true
Valid Values: true, false
Changes Take Effect: Immediately
When this option is set to true,
SIP Server, when executing a
TReleaseCall request for a non-established call, terminates the call leg in the dialing state by sending a
200 OK
message. When this option is set to false,
SIP Server sends a
404 Not Found
.
server-role
Default Value:
0
Valid Value:
0, 1
Changes Take Effect: After SIP Server restart
Specifies the role that SIP Server plays in the deployment scenario:
•
0
—SIP Server runs in a standalone deployment, where the server is not integrated into an IMS environment (DNs are registered or provisioned on
SIP Server).
•
1
—SIP Server runs as a SIP Application Server (SIP-AS) in an IMS deployment.
SIP Server—Deployment Guide 509
Chapter 7: SIP Server Configuration Options Application-Level Options
session-refresh-enforced
Default Value: true
Valid Values: true, false
Changes Take Effect: Immediately
Controls whether SIP Server activates the SIP Session timer within a SIP dialog. If set to false
, SIP Server activates the SIP Session timer only if both an initial
INVITE
and
200 OK
response to that
INVITE
contains the
Session-
Expires
header. If set to true
, SIP Server, while activating that timer, ignores the absence of the
Session-Expires
header in the response and starts the timer based on the header presence in the request. If an endpoint does not support the session refresh mechanism, set this option to false.
The option has an affect only when the session-refresh-interval
option is set to a non-zero value.
You can define this option at both the Application and the DN levels. The
DN-level setting takes precedence over the Application-level setting.
session-refresh-interval
Default Value:
1800
Valid Values:
0, 90
–
86400
Changes Take Effect: Immediately
Specifies (in seconds) how often active calls are checked to see if they are still active. A
0
(zero) value disables this feature (the session refresh mechanism is turned off). Values between
1
and
89 ( inclusive) are treated as value
90
.
This option is used to remove stuck calls that must accumulate if endpoints terminate calls without sending the appropriate SIP message.
Note:
In compliance with RFC 4028, Genesys recommends keeping the default setting of
1800
(30 minutes) for this option. Setting the session-refresh-interval
to a considerably lower number may cause conflicts with the session timer in some switches.
set-notready-on-busy
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
With this option set to true
, when a call is distributed to a ready agent (that is, the agent is not previously engaged in a call), and the agent endpoint responds to the
INVITE
with a
4xx
,
5xx
, or
6xx
message, SIP Server places the agent in the
Not Ready
state (an
EventAgentNotReady
message is distributed). In addition, a
ReasonCode
key with a value equal to a returned error will be reported in the
Extensions
attribute in the
EventAgentNotReady
message. If a call is distributed to an agent via an ACD queue, the agent is placed in the
Not Ready
state and the call is diverted to the same ACD queue (at the end of the queue).
510 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
shutdown-sip-reject-code
Default Value:
603
Valid Values:
300
–
603
Changes Take Effect: Immediately
Specifies the error response used for rejecting new
INVITE
messages received by the system that is in shutdown mode. If set to
300
,
301
, or
302
, SIP Server first checks to see if dr-peer-trunk
is configured, and if so, sends the contact of that
Trunk
DN in the
302
response.
Note:
If a PSTN provider has alternative paths for call delivery, such as via
Genesys SIP Server located at another site or through telephony infrastructure of a third party, set this option to a value of
503
.
silence-detected
Default Value: drop
Valid Values: drop connect
The call is released.
The connected call stays connected.
Changes Take Effect: Immediately
Related Feature: “Outbound IP Solution Integration” on page 317
Specifies the behavior of SIP Server where CPD is operating and silence is detected on the destination of a predictive call. SIP Server provides the CPD result in the following ways, depending on the value of the option and the type of call flow:
•
When silence-detecte d is set to drop,
SIP Server drops the call and generates an
EventReleased
with
CallState=CallStateSilenceDetected
.
•
When silence-detected
is set to connect,
and the
TMakePredictiveCall
is invoked for a Trunk Group-based call, SIP Server establishes the call and generates an
EventEstablished with
CallState=CallStateSilenceDetected
.
•
When silence-detected
is set to connect,
and the
TMakePredictiveCall
is invoked for a Routing Point-based call, SIP Server establishes the call and generates an
EventQueued
with
CallState=CallStateSilenceDetected
and
UserData
AnswerClass=SILENCE attached to the event.
silence-tone
Default Value: music/silence
Valid Values: Name and path of any valid audio file
Changes Take Effect: Immediately for all new calls
Specifies the audio file to be played for the
Silence
treatment.
SIP Server—Deployment Guide 511
Chapter 7: SIP Server Configuration Options Application-Level Options
sip-3pcc-from-pass-through
Default Value: false
Valid Values: true, false
Changes Take Effect: On the next call
Related Feature: “Dial Plan” on page 210
Specifies the value that SIP Server includes as the username part of the
From header in the
INVITE
message sent to the origination device. If set to true,
SIP
Server includes the
AttributeOtherDN
value from a
TMakeCall,
TInitiateTransfer,
or
TInitiateConference
3pcc request. If set to false
, SIP
Server includes the resulting digits when the dial plan is applied.
sip-491-passthrough
Default Value: false
Valid Values:
true, fals e
Changed Take Effect: Immediately
Specifies whether SIP Server will forward
491 Request Pending
messages sent in response to a re-
INVITE
request to the remote endpoint. This operation mode should be used in the environments where SIP message conflict resolution is preferred to be carried out by the endpoints and not by SIP Server.
sip-add-contact-early-dialog
Default Value: false
Valid Values: true, false
Changes Take Effect: For the next call
Specifies whether SIP Server adds the
Contact
header to unreliable
180
SIP messages. If set to true,
SIP Server adds the
Contact
header to unreliable
180
SIP messages. If set to
false,
SIP server does not add the
Contact
header to unreliable
1xx
SIP messages (to provide backward compatibility).
sip-add-local-contact-user
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
When set to true,
SIP Server takes the username from the URI of an incoming
INVITE
request and adds it to the local contact of the created SIP dialog. As a result, the SIP response that establishes the dialog (such as a
2xx
to
INVITE
) as well as consecutive responses and new requests within the dialog from SIP
Server will have that username inside the
Contact
header.
512 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
sip-address
Default Value:
NULL
Valid Values: Any valid IP address or host name
Changes Take Effect: After SIP Server restart
Specifies an IP address of the SIP Server interface. This option must be set when deploying SIP Server on a host with multiple network interfaces. SIP
Server uses this value to build the
Via
and the
Contact
headers in SIP messages. When this option is not set, SIP Server attempts to detect the IP address automatically.
sip-address-srv
Default Value: No default value
Valid Values: Valid Fully Qualified Domain Name (FQDN)
Changes Take Effect: After SIP Server restart
Related Feature: “DNS Name Resolution” on page 232
When specified, SIP Server can use this FQDN as its own contact for the DNS name resolution procedure.
Attention!
This value will be inserted in the
Contact
and
Via
header fields of all outgoing SIP messages.
sip-alert-info
Default Value: No default value
Valid Values: Any string
Changes Take Effect: Immediately
Related Feature: “Alternate Ringtones” on page 104
Specifies the content to be added to the
Alert-Info
header used to trigger alternate ringtones or auto-answer functionality in the destination endpoint.
If configured, SIP Server will include the
Alert-Info
header with the value of this option whenever it sends an
INVITE
to any
Extension
or
ACD Position
DN on the switch—unless a different value is configured at the DN-level, or in the
SIP_HEADERS
extension.
For example, the following value points the endpoint to a ringtone file that can be used for internal calls:
<http://www.provider.com/tones/internal_caller.pcm>
Note:
The URI must be enclosed in angle brackets.
If alternate ringtones are also configured for external or consultation calls
( sip-alert-info-external
or sip-alert-info-consult
), then that configuration takes precedence over sip-alert-info
.
SIP Server—Deployment Guide 513
Chapter 7: SIP Server Configuration Options Application-Level Options
sip-alert-info-external
Default Value: No default value
Valid Values: Any string
Changes Take Effect: Immediately
Related Feature: “Alternate Ringtones” on page 104
Specifies the content to be added to the
Alert-Info
header for inbound external calls. If configured, SIP Server will include the value of this option in the
Alert-Info
header of the
INVITE
messages that it sends for an external call to any
Extension
or
ACD Position
DNs in the switch—unless a different value is configured at the DN-level or in the
SIP_HEADERS
extension.
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>
Note:
The URI must be enclosed in angle brackets.
sip-alert-info-consult
Default Value: No default value
Valid Values: Any string
Changes Take Effect: Immediately
Related Feature: “Alternate Ringtones” on page 104
Specifies the content to be added to the
Alert-Info
header for consultation calls. If configured, SIP Server will include the value of this option in the
Alert-Info
header of the
INVITE
messages that it sends to establish a consultation call with any
Extension
or
ACD Position
DNs in the switch—unless a different value is configured at the DN-level or in the
SIP_HEADERS
extension.
For example, the following value points the endpoint to the ringtone file that will be used for external calls:
<http://www.provider.com/tones/consultation_call.pcm>>
Note:
The URI must be enclosed in angle brackets.
sip-answer-mode
Default Value: An empty string
Valid Values:
Auto
Changes Take Effect: Immediately
Specifies the content to be added to the
Answer-Mode
header that is used to trigger the auto-answer functionality in the destination endpoint. SIP Server sends this header regardless of whether an endpoint has advertised support for the “answermode” sip.extension in the contact of a
REGISTER
message. If this option is configured, SIP Server includes the
Answer-Mode
header with the value of this option whenever it sends an initial
INVITE
message.
514 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
Notes:
• This option can also be configured at the DN level. The DN-level setting takes precedence over the Application-level setting.
• Support of the
Answer-Mode
SIP header in
Auto
mode as described in
RFC 5373; compatible with Avaya 96xx phones. Avaya phones send
INVITE
messages without a
Referred-By
header in response to
REFER from SIP Server; therefore, the refer-enabled
configuration option must be set to false.
Also, for Avaya phones, the dual-dialogenabled
configuration option must be set to true
and the sip-cticontrol
configuration option should not be configured.
sip-block-headers
Default Value: An empty string
Valid Values: A comma-separated list of the headers to be filtered out during
INVITE
message propagation
Changes Take Effect: Immediately
Specifies a way to filter out headers during
INVITE
message propagation. With an empty string, no headers will be filtered out.
sip-disable-via-srv
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Related Feature: “SRV Address Support in Contact and Record-Route
When set to true
, SIP Server inserts a value of the sip-address option in the
Via header. This option applies when the sip-address-srv
option is configured.
sip-dtmf-send-rtp
Default Value: false
Valid Values: true false
SIP Server instructs Stream Manager to send DTMF tones to all call participants using one or both of the following DTMF generation methods: RTP packets with Named Telephone Event
(NTE) payload as specified by RFC 2833, and in-band audio tones according to ITU-T Recommendation Q.23.
The feature is disabled.
Changes Take Effect: Immediately
Related Feature: “DTMF Tones Generation” on page 236
Specifies whether SIP Server instructs Media Server to send DTMF tones when a T-Library client issues a
TSendDTMF
request.
SIP Server—Deployment Guide 515
Chapter 7: SIP Server Configuration Options Application-Level Options
sip-enable-aoc-after-established
Default Value: false
Valid Values: true, false
Changes Take Effect: For the next request
Related Feature: “Providing AoC Notifications for Established Calls” on page 104
When this option is set to true,
it enables the mode of providing Advice of
Charge (AoC) notifications for established calls. In particular, SIP Server accepts and processes
TPrivateService(3018)
AoC requests in which
AttributeThisDN
refers to a Routing Point DN that is not present in the call. At
extension key points to an existing
party in the established state. To successfully process this request, the Routing
Point DN referred by
AttributeThisDN
must also have the
option set to false.
When this option is set to false (for backward compatibility), SIP Server rejects an AoC
TPrivateService(3018)
request if
AttributeThisDN
refers to a
DN not present in the call.
sip-enable-call-info
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Related Features: “Providing Call Participant Info” on page 349
Between Supervision Modes” on page 147
If set to true
, SIP Server does the following:
•
Distributes information about call participants except their locations and the supervisor-related information (see the sip-enable-call-info-extended option) to logged-in agents by using the SIP
NOTIFY
method and
EventUserEvent
messages.
•
Distributes an
EventPrivateInfo(4024)
message, with the
MonitorMode
key in
AttributeExtensions
, to a supervisor and agent DNs indicating that the monitoring mode was changed.
If set to false
, SIP Server does not distribute an
EventPrivateInfo(4024) message when the monitoring mode changes.
sip-enable-call-info-extended
Default Value: true
Valid Values: true, false
Changes Take Effect: Immediately
Related Features: “Providing Call Participant Info” on page 349
This option applies only when sip-enable-call-info
is enabled. When this option is set to true,
SIP Server generates the supervisor information
(
LCTSupervisor<n>
key-value pairs) and the location of call participants
(
LCTParty<n>_location
) in
EventUserEvent
.
516 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
sip-enable-gdns
Default Value: true
Valid Values:
true, false
Changes Take Effect: After SIP Server restart
Related Feature: “DNS Name Resolution” on page 232
Specifies the DNS resolution mode. If you set this option to true
, SIP Server uses its internal DNS client to connect to a DNS server available on the network to use its conversion services.
If no DNS server is available, set this option to false
. In this case, SIP Server resolves the domain names using local operating system utilities.
If set to false
, SIP Server is unable to perform DNS resolution for SRV records with contacts that are missing port information (indicating the need to use SRV). Instead, ‘A’ record resolution and default ports will be used. The default port for UDP/TCP is
5060
, while the default for TLS is
5061
.
sip-enable-100rel
Default Value: true
Valid Values: true
SIP Server advertises support for
100rel
, and requires it whenever the other side indicates support.
SIP Server does not negotiate support for the reliability of false provisional responses.
Changes Take Effect: Immediately
If set to true
, SIP Server places the option tag
100Rel
inside the
Supported header of outgoing initial
INVITE
requests. This informs SIP clients that SIP
Server is able to process provisional responses reliably.
sip-enable-ivr-metadata
Default Value: No default value
Valid Values: true, false
Changes Take Effect: For the next call
This option is used for IVR recording call scenarios. Specifies whether SIP
Server passes its Application name in the initial
INVITE
message (in the
X-
Genesys-sipsAppName
header) to Media Server. If this option is set to true,
SIP
Server includes its Application name in the custom header of the
INVITE
that it sends to Media Server. It also enables the default behavior of the feature depending on the DN type, as follows:
•
Voice over IP Service (msml), Trunk Group,
and
Voice Treatment
Port
—SIP Server sends the custom header.
•
Trunk
—SIP Server does not send the custom header.
SIP Server—Deployment Guide 517
Chapter 7: SIP Server Configuration Options Application-Level Options
If this option is set to false,
SIP Server does not include its Application name in the initial
INVITE
sent to Media Server.
Notes:
• If the IVR recording feature is enabled, it is not required to explicitly enable recording by setting the record
option to true
on
DNs representing GVP, such as
Trunk, Trunk Group, or
Voice
Treatment Port.
Recording is started by the VXML application running on the Media Server.
• This option can also be configured at the DN level. The DN-level setting takes precedence over the Application-level setting.
sip-enable-moh
Default Value: false
Valid Value: true false
Music-on-hold is enabled.
Music-on-hold is disabled.
Changes Take Effect: At the next
Hold/THoldCall
operation
Related Feature: “Customizing Music on Hold and in Queue” on page 194
Enables or disables music-on-hold.
Note:
This option can also be configured at the DN level. The DN-level setting takes precedence over the Application-level setting.
sip-enable-rfc3263
Default Value: false
Valid Value: true, false
Changes Take Effect: After SIP Server restart
Related Feature: “DNS Name Resolution” on page 232
Specifies the DNS resolution mode.
If you set this option to true,
SIP Server includes priority and weight information from the Returned Record Set (resolved from the contact
option using the internal DNS) when it applies the destination selection procedure.
This is in accordance with RFC 3263 and RFC 2782. If set to true,
SIP Server ignores the values of the contacts-backup
option as redundant.
If you set this option to false,
SIP Server does not factor in priority or weight from the RR Set when applying the destination selection procedure (multiple active destinations are given equal ranking). The destinations in this case are taken from the URIs configured in the following DN options:
•
contact
•
contacts-backup
(can be several URIs in a comma-separated list)
The Active Out-of-Service Detection procedure uses DNS SRV/A Resource
Records resolution for composing a list of transports (protocol, IP address, port) for each contact’s URI. To use priority and weight, set this option to true
.
To treat all destinations as equal, set this option to false.
518 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
sip-enable-sdp-application-filter
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Specifies whether SIP Server modifies the SDP message body during SIP negotiation. When set to true,
SDP with media-type
(m=) “application”
will be filtered.
sip-enable-tcp-keep-alive
Default Value: false
Valid Values: true, false
Changes Take Effect: After restart
Related Feature: “Keep Alive for TCP Connections” on page 274
When set to true,
enables the TCP keep-alive mechanism for all SIP-related connections. Keep-alive timeouts are configured on the operating system level.
sip-enable-two-party-mute
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Related Feature: “Muting/Unmuting a Party in a Conference” on page 173
When set to true
, enables muting and unmuting parties in two-way calls via a
T-Library request; requires MSML to be enabled.
Note:
When set to
true,
two-party conferences are not be converted to direct calls.
sip-enable-x-genesys-route
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Related Feature: “SRV Address Support in Contact and Record-Route
Specifies if SIP Server adds the private
X-Genesys-Route
header to SIP messages when deployed with SIP Proxy. This is for backward compatibility to disable new functionality in old deployments.
SIP Server—Deployment Guide 519
Chapter 7: SIP Server Configuration Options Application-Level Options
sip-error-conversion
Default Value: No default value
Valid Values: A comma-separated list of value pairs:
<received error code>=<converted error code>,
0
=<converted error code>
(for example:
408=486
,
0=486
)
Changes Take Effect: Immediately
When this option is set to <received error code>=<converted error code>, SIP
Server converts the received error response code to the configured code and sends the converted SIP response code to the origination device. This setting affects the following:
•
How the SIP error code is processed by SIP Server.
For example, SIP error code
486 (Busy Here) means a destination is busy.
SIP error code
408
(
Request Timeout
) received for DNs located behind a softswitch places a DN in out-of-service state. If this option is set to
408=486 and the softswitch responds with the
408
error code, SIP Server will not place the DN in out-of-service state.
•
The
ErrorCode
that is returned in
EventError
to a routing application when a routing attempt is unsuccessful.
For example, when a routing destination responds to the
INVITE
message with code
484
(
Address Incomplete
), SIP Server sends
ErrorCode 231
(
DN is Busy
) to a routing application. If this option is set to
484=404,
SIP
Server returns
ErrorCode 71
(
Invalid Called DN
) to a routing application.
When this option is set to
0
=<converted error code>, SIP Server sends the converted SIP error code if one of the following occurs:
•
The destination device fails to respond to the incoming
INVITE
message.
•
No active DN is found for SIP Server to send a call.
Note:
If a destination DN of type
Extension
fails to respond to the incoming
INVITE
message, SIP Server places the
Extension
DN in out-of-service state regardless of the sip-error-conversion
setting.
The option can be configured at the following levels and in the following order of precedence:
•
DN level
•
Application level
520 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
sip-enable-sdp-codec-filter
Default Value: false
Valid Values: true false
SIP Server modifies the SDP message body during SIP renegotiation.
SIP Server does not modify the SDP message body.
Changes Take Effect: For the next call
Related Option:
Specifies whether SIP Server modifies the SDP message body during SIP renegotiation. All codecs that are not in the list of values for the
option are deleted from the SDP. As a result, all call center audio traffic is
established based on the codecs listed in the audio-codecs
You can also specify this option at the DN-level. If sip-enable-sdp-codecfilter
is set to true
in the DN configuration, SIP Server, as it propagates the
SDP to and from the device represented by this DN, will use as its list of available codecs the value configured in the audio-codecs
option on the DN rather than on the application. If sip-enable-sdp-codec-filter
is set to true
at both the application and the DN level, then the audio-codecs
configured in the
DN should contain a subset of the audio-codecs
configured in the application.
Note:
Currently, SIP Server does not support filtration of video codecs.
sip-enhance-diversion
Default Value: false
Valid Values: false, true
Changes take effect: For the next call
Related Feature: “Handling Call Forwarding Loop” in the 8.1 SIP Server
Integration Reference Manual
Specifies how SIP Server processes an
INVITE
message based on the value of the
Diversion
header. If the option is set to true
and the
Diversion
header references the call forwarding party, SIP Server rejects that
INVITE
, waits until that rejection is propagated by the PBX back to the SIP Server in the original
SIP dialog, and sends a new
INVITE
message to a forwarding destination.
SIP Server—Deployment Guide 521
Chapter 7: SIP Server Configuration Options Application-Level Options
sip-filter-media
Default Value: No default value
Valid Values: video
Changes Take Effect: Immediately
Related Feature: “Video Blocking” on page 389
When set to video
, SIP Server blocks video media streams in calls.
Note:
This option can also be configured at the DN level. The DN-level setting takes precedence over the Application-level setting.
sip-from-pass-through
Default Value: false
Valid Values: true, false
Changes Take Effect: For the next call
Specifies whether SIP Server will use the content of the
From
header from the original
INVITE
to generate the content for the
From
header in the outgoing
INVITE
message.
sip-fqdn-ip-version
Default Value:
4
Valid Values:
4, 6
Changes Take Effect: After restart
Related Feature: “IPv6 Support” on page 272
Specifies the IP protocol when the peer’s address is represented as an FQDN.
If, in the environment, all SIP devices use IPv4, set this option to
4
. If all SIP devices use IPv6, set this option to
6.
sip-hold-rfc3264
Default Value: false
Valid Value: true false
RFC3264-compliant implementation.
RFC2543-compliant implementation.
Changes Take Effect: For the next call
Specifies which implementation of hold media SDP is used by SIP Server for third-party call control (3pcc) hold operations.
Note:
This option can also be configured at the DN level. The DN-level setting takes precedence over the Application-level setting.
522 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
sip-invite-timeout
Default Value:
0
(in effect, 32 seconds)
Valid Values:
0
–
34
Changes Take Effect: Immediately
Specifies the number of seconds SIP Server waits for a response to the
INVITE message. The call times out if no response is received. If set to
0
, or if a value is not specified, then the default SIP call timeout of
32
seconds is used.
SIP Server uses different timeout options for regular devices and media service devices, in order to correctly process scenarios where only a provisional response is received after sending an
INVITE
to a device (without receiving a final response). SIP Server treats the expiry of either timeout setting the same way it does an expiry of SIP Timer B.
•
sip-invite-timeout
—For regular devices, used to specify the length of time that a SIP transaction can remain in the Proceeding state when the only provisional responses that it receives are
100 Trying
messages. Any other provisional message removes the timer, so that the regular device can remain in a ringing state until the peer's action causes SIP Server to cancel the
INVITE
request.
•
sip-invite-treatment-timeout
—For media service devices, used to specify the length of time to wait for a final or reliable provisional response. If this timeout expires, the media service device is considered to be out of service and SIP Server tries to use an alternative device to perform the required function.
sip-invite-treatment-timeout
Default Value:
0
(in effect, 32 seconds)
Valid Values:
0
–
34
Changes Take Effect: Immediately
Specifies the number of seconds SIP Server waits for a response to the
INVITE message for a treatment (such as an announcement or music-on-hold). The call times out if no response is received. If set to
0
, or if a value is not specified, then the default SIP call timeout of
32
seconds is used.
Note:
Setting this value to less than the session timer (Timer D - 32 seconds) allows a
MakeCall
operation to succeed when the ringtone is enabled
( ring-tone-on-make-call
set to true
) and the media server is unavailable. If the value is greater than or equal to the session timer
(or 0), then this scenario instead results in a failed call when the media server is unavailable.
SIP Server—Deployment Guide 523
Chapter 7: SIP Server Configuration Options Application-Level Options
sip-iptakeover-monitoring
Default Value: false
Valid Values: true, false
Changes Take Effect: After SIP Server restart
Dependent Option:
Related Feature: See “Network Status Monitoring” in the
SIP Server 8.1 High-
Availability Deployment Guide.
For the Hot Standby IP Address Takeover configuration. When set to true, this option enables the Virtual IP address status monitoring. The Virtual IP address is taken from the sip-address
option.
sip-ip-tos
Default Value:
256
Valid Values: Any integer from
0-256
, either in decimal format or in hexadecimal format with
0x
prefix
Changes Take Effect: Immediately
Related Feature: “Quality of Service” on page 354
Defines the value of the Type of Service (TOS) byte in the IP header of SIP messages that are sent by SIP Server (if undefined, the operating system TOS is used). The default value (
256
) disables this functionality.
Depending on the network configuration, the TOS byte is treated as one of the following:
•
3-bit IP precedence field, followed by a 4-bit type-of-service. The least significant bit (LSB) is unused and set to 0. (RFC 1349)
•
6-bit DiffServ, with the two least significant bits unused. (RFC 2474)
For example, the following values may be used to assign a higher priority to
SIP packets:
•
0x10—IPTOS_LOWDELAY, low-delay type of service
•
0x20—IPTOS_PREC_PRIORITY, priority precedence
•
0x40—IPTOS_PREC_CRITICAL, critical precedence
•
0xB8—DiffServ EF (Expedited Forward)
Notes:
On most operating systems, applications that are running on behalf of non-privileged 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, 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
Refer to operating system documentation for additional information.
524 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
sip-legacy-invite-retr-interval
Default Value: false
Valid Values: true, false
Changes Take Effect: After SIP Server restart
Enables
INVITE
retransmissions in accordance with RFC 3261 “SIP: Session
Initiation Protocol”. If you set this value to true
, SIP Server sends the
INVITE retransmissions in periods of 0.5 - 1 - 2 -4 -4 -4 - 4...seconds (legacy SIP
Server behavior). If set to false
, SIP Server sends the
INVITE
retransmissions in periods of 0.5 - 1 - 2 - 4 - 8 - 16... seconds, as per RFC 3261.
sip-link-type
Default Value:
0
Valid Values:
0,3,4
Changes Take Effect: After SIP Server restart
Related Feature: “Multi-Threaded Logging” on page 290
Specifies whether SIP Server will run in multi-threaded mode, or in singlethreaded mode for backward compatibility.
Configure the valid values for this option as follows:
0
(default) SIP Server runs in single-threaded mode, as in pre-8.0.3 releases, with the Main thread processing T-Library requests, distributing
1,2
Events, managing SIP calls, and processing SIP signaling
Reserved for debugging
3
Enables multi-threaded mode with the following threads:
•
T-Server thread—processes T-Library requests and distributes
Events
4
•
Call Manager thread—manages SIP calls and processes SIP signaling (except
OPTIONS
messages)
•
Service Checker thread— performs Active Out-of-Service
Detection (
OPTIONS
messages)
Enables multi-threaded mode designed for IMS double-dip deployments, with the following threads:
•
T-Server thread
•
16 Call Manager threads
•
Service Checker thread
•
Presence Manager thread
In both single-threaded and multi-threaded modes, SIP Server runs the following threads:
•
SIP transport layer thread to dispatch SIP messages
•
Operational Information thread to collect and report statistics; to perform
NIC monitoring
•
A number of auxiliary threads
Note:
For an HA configuration, this option must be configured with the same value in both primary and backup SIP Servers.
SIP Server—Deployment Guide 525
Chapter 7: SIP Server Configuration Options Application-Level Options
sip-max-uui-length
Default Value:
256
Valid Value:
0-8192
Changes Take Effect: Immediately
Related Feature: “User to User Information (UUI)” on page 387
Specifies the maximum number of characters by which SIP Server limits the length of the data included in the User-to-User Information (UUI) header. For example, with the default value of
256
, SIP Server will limit the length of UUI content, with hexadecimal encoding, to 128 bytes.
sip-max-retry-listen
Default Value:
15
Valid Values:
0
-
65535
Changes Take Effect: After SIP Server restart
Specifies the number of times SIP Server retries opening its listening port per time interval after the CTI link is disconnected. The time interval starts at 1 attempt per second, maximizing at 1 attempt every 30 seconds, after which SIP
Server continues retrying every 30 seconds indefinitely.
sip-nic-address
Default Value:
NULL
Valid Values: Any valid IP address or FQDN
Changes Take Effect: After SIP Server restart
Dependent Option:
Related Feature: See “Network Status Monitoring” in the
SIP Server 8.1 High-
Availability Deployment Guide.
This option can be set in deployments with dedicated SIP NICs (network interface cards) where the SIP traffic is separated from the T-Library network traffic. This option specifies the IP address of the NIC that belong to the host where the SIP Server runs and is used for SIP traffic. This IP address must always be present on this host regardless of the role of SIP Server (primary or backup). For the IP Address Takeover configuration, its unique IP address is associated with the SIP NIC, not the Virtual IP address.
sip-nic-monitoring
Default Value: false
Valid Values: true, false
Changes Take Effect: After SIP Server restart
Dependent Option:
Related Feature: See “Network Status Monitoring” in the
SIP Server 8.1 High-
Availability Deployment Guide.
When set to true,
this option enables the SIP NIC IP address status monitoring. The SIP IP address is taken from the sip-nic-address
option.
526 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
sip-outbound-proxy
Default Value: false
Valid Values: true, false
Changes Take Effect: After SIP Server restart
If set to true,
all SIP messages are sent through SIP Proxy. SIP Server looks for a VoIP Service DN with service-type=sip-outbound-proxy
. For each initial out-of-dialog outgoing SIP request, SIP Server inserts a
Route
header with the value of the DN contact.
Note:
SIP Server sends the
REGISTER
message directly to the
Trunk
DN configured with the
sip-pass-check
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Related Features: “Endpoint Service Monitoring” on page 253
When set to true,
enables tracking of SIP messages that reach the primary SIP
Server, including responses from SIP devices configured for Active Out-of-
Service Detection.
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. The period of time is calculated as the maximum of the sums of the oos-check
and oos-force option values configured for service DNs (if oos-force
is less than
5
,
5
is used).
When SIP Server reports the
SERVICE_UNAVAILABLE
status to LCA/SCS, SCS switches the primary SIP Server to the backup role, and SIP Server reports the
SERVICE_RUNNING
status to LCA/SCS. The backup SIP Server becomes the primary, and starts monitoring SIP traffic.
Note:
If both the primary and backup servers receive no SIP traffic, a switchover would occur each time the effective out-of-service timeout expires. To prevent frequent switchovers, SIP Server detects the
“double switchover” condition and doubles the effective out-ofservice timeout each time the double switchover happens, up to two times, or until one of the two servers detects SIP traffic. As soon as
SIP traffic is detected, the server that detected the traffic remains the primary SIP Server and continues normal operation.
SIP Server—Deployment Guide 527
Chapter 7: SIP Server Configuration Options Application-Level Options
sip-pass-from-parameters
Default Value: No default value
Valid Values: A comma-separated list of parameters, or *
Changes Take Effect: Immediately
Specifies which parameters in the
From
header SIP Server will pass through in the outgoing
INVITE
message—with the exception of the tag
parameter generated by SIP Server. To pass through all parameters, use the asterisk (
*
) value.
sip-pass-refer-headers
Default Value: No default value
Valid Values: A string of SIP headers separated by commas; may contain full header names or name parts with an asterisk representing a subset of headers
Changes Take Effect: At the next established call
When specified, SIP Server will pass custom SIP headers from a
REFER
request to an outgoing
INVITE
or
REFER
request.
For example:
If the sip-pass-refer-headers
option is set to
X-Tellme-*,X-Information
and the incoming REFER request contains the following headers:
•
X-Tellme-Session-ID
•
X-Tellme-Header
•
X-Information
Then SIP Server will include all three headers to an outgoing
INVITE
or
REFER request.
sip-port
Default Value:
5060
Valid Value: Any valid TCP/IP port
Changes Take Effect: After SIP Server restart
Specifies the port on which SIP Server listens for incoming SIP requests. The same port number is used for both TCP and UDP transports.
sip-port-tls
Default Value: No default value
Valid Values: Any valid port number
Changes Take Effect: After SIP Server restart
Related Feature: “Transport Layer Security for SIP Traffic” on page 374
Specifies the port on which SIP Server listens for incoming requests using TLS encryption. To disable TLS transport for SIP traffic altogether, set this option to
0
.
528 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
sip-preserve-contact
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Specifies whether SIP Server preserves session information (a cookie) that is appended to the user-info part of the
Contact
header in
REGISTER
requests. If you set this option to true
, SIP Server preserves the cookie from the
REGISTER request, and then includes the cookie in the
Request-URI
of the outgoing
INVITE request.
Note:
This option can also be configured at the DN level. The DN-level setting takes precedence over the Application-level setting.
sip-proxy-headers-enabled
Default Value: true
Valid Values: true, false
Changes Take Effect: Immediately
Specifies whether SIP Server will proxy the custom SIP headers or not. If set to true,
SIP Server will proxy the custom headers, when sending the message to other side. SIP Server will proxy the custom headers only in the following
SIP messages:
•
INVITE
•
REFER
•
200 OK
If set to false,
SIP Server will not proxy custom headers, when sending the message to other side. This parameter can be defined either at the application or a DN level with the DN-level parameter having a higher priority.
Note:
For integration with GVP, the Resource Manager must be configured as a Trunk for supporting the above option in the
REFER
message.
sip-recovery-allow-userdata
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Enables mapping of T-Library User Data into a SIP
INVITE
message which is sent to Media Server during recovery of the
PlayApplication
treatment.
If set to true
, during recovery after failure of the
PlayApplication
treatment
(an initial
INVITE
is rejected by a SIP error response), SIP Server does mapping of T-Library User Data into SIP INVITE message.
If set to false
, no user data is mapped in the
INVITE
message during recovery.
SIP Server—Deployment Guide 529
Chapter 7: SIP Server Configuration Options Application-Level Options
sip-referred-by-support
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Related Feature: “Referred-By Header Support” on page 177
If set to true,
SIP Server sends an identity of the party which has originated the transfer, in the SIP URI of the outgoing
REFER
request’s
Referred-By
header.
If the call is processed on the Routing Point and is routed using
TRouteCall
, then the Routing Point name is used as a userpart of the
Referred-By
SIP URI.
In addition, SIP Server can substitute the “hostport” component of the SIP URI in
Refer-To
and
Referred-By
headers of
REFER
messages with the values configured by a user. If set to false,
this feature is disabled.
sip-referxfer-bye-timeout
Default value:
0
Valid Values:
0
–
65535
Changes Take Effect: Immediately
Specifies the time interval, in milliseconds, SIP Server waits before releasing the initial dialog after a single-step transfer using the
REFER
method is completed.
sip-rel-200-retransmit
Default Value: false
Valid Values: false, true
Changes Take Effect: For the next call
Specifies if SIP Server retransmits
200 OK
in response to an
INVITE
message on reliable transports if
ACK
is not received for
200 OK
. (The default value of this option ( false
) enables the previous behavior in SIP Server.)
Note:
This option can also be configured at the DN level. The DN-level setting takes precedence over the Application-level setting.
sip-release-call-on-disable-dn
Default Values: false
Valid Values: true, false
Changes Take Effect: At the next call
Specifies whether SIP Server releases all calls for a DN that was disabled in the configuration environment. If set to true,
SIP Server releases both call’s dialogs (T-Library and SIP) for the disabled DN.
530 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
sip-remote-del-from-conf
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Related Feature: “Deleting Party From Conference in Multi-site Deployments” on page 171
Related Option:
In multi-site deployments, when this option is set to true,
SIP Server processes a
TDeleteFromConference
request to remove a remote party (specified in
OtherDN
) from a conference. The
OtherDN
attribute of the
TDeleteFromConference
request must contain the party ID received in the
LCTParty
list. When this option is set to false
, this feature is disabled.
sip-replaces-mode
Default Value:
0
Valid Values:
0, 1, 2, 3
Changes Take Effect: For the next call
Related Feature: “TCompleteTransfer using REFER or REFER with Replaces” on page 177
Specifies the SIP method used by SIP Server to complete a two-step transfer.
•
With a value of
0,
SIP Server uses the
REFER
method if the transfercomplete-by-refer option is set to true
.
•
With a value of
1,
SIP Server uses the
REFER
method with
Replaces
if the
Allow
header contains
REFER
as a supported method and the
Supported header contains
Replaces
. If
REFER
with
Replaces
is not supported by a device, then
TCompleteTransfer
will be performed using the
REFER
method.
If a device does not support the
REFER
method, then the transfer will be completed using the re-
INVITE
method.
•
With a value of
2,
SIP Server uses the
REFER
method with
Replaces
to process
TCompleteTransfer
. The
Allow
and
Supported
headers will not be analyzed.
•
With a value of
3,
when the DN-level sip-server-inter-trunk option is set to true
, SIP Server uses the re-
INVITE
method instead of the
REFER method for transfers and call routing.
Note:
For this functionality to work, the refer-enabled
option must be set to true
in the DN from which a call party is transferred to another destination during a two-step transfer.
SIP Server—Deployment Guide 531
Chapter 7: SIP Server Configuration Options Application-Level Options
sip-respect-privacy
Default Value: false
Valid Values: true, false
Changes Take Effect: For the next call
Specifies the content SIP Server will report in
AttributeANI
when an inbound
INVITE
message contains
P-Asserted-Identity
and
Privacy:id
headers. If this option is set to false
(the default), the content of the
P-Asserted-Identity header is ignored when determining
AttributeANI
. If this option is set to true, the content for
AttributeANI
is taken from the
P-Asserted-Identity
header. If the
P-Asserted-Identity
header is not present, then the content for
AttributeANI
is determined as follows:
•
From the user part of the
From
header, if present and not anonymous.
•
From the user part of the
Contact
header, if present and not anonymous.
•
From the matched origination device DN.
•
Set to anonymous in all other cases.
sip-retry-timeout
Default Value:
30
Valid Values:
1-3600
Changes Take Effect: Immediately
Specifies the time interval, in seconds, after which SIP Server initiates a new subscription if the previous
SUBSCRIBE
dialog is terminated.
sip-ring-tone-mode
Default Value:
0
Valid Values:
0,1
Changes Take Effect: Immediately
With the option set to
0,
SIP Server connects Media Server to a call to play an audio ringtone. With the option set to
1,
SIP Server waits for a response from the called device, then connects Media Server to a call to play an audio
532 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options ringtone, but only when the returned response cannot be used as the offer to a calling device.
Notes:
• SIP Server does not support internal ringtones in conference scenarios where the sip-ring-tone-mod e option is set to
1
. In this case, SIP Server provides a ringtone only if the endpoint returns an
SDP in the provisional message.
• This option can also be configured at the DN level. The DN-level setting takes precedence over the Application-level setting.
• To enable a ringback to be played to an external caller, set the following parameters in the
Trunk
DN:
ring-tone-on-make-call=true sip-ring-tone-mode=1 refer-enabled=false
•
Note: For an inbound call to a Routing Point, a ringback is played to an external caller only if a treatment was applied to the call at the Routing Point, and then the call is delivered to an available agent. If an agent was available immediately and the treatment was not applied to the call on the Routing Point, the ringback is not played to the caller on
180 Ringing
from the agent’s DN.
When sip-treatments-continuous
is set to true
and sip-ringtone-mode
is set as
0
or
1,
the ringtone is not played. For the ringtone to be played, set sip-treatments-continuous
to false.
sip-resubscribe-on-nonotify
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Specifies whether SIP Server, at startup or after a switchover, re-sends a
SUBSCRIBE
request to Resource Manager if it does not receive a
NOTIFY
message within a two-second timeout after a successful subscription. If set to true
and
SIP Server does not receive
NOTIFY
, it terminates the subscription and sends a new
SUBSCRIBE
request. SIP Server continues to re-subscribe until it receives
NOTIFY
. If set to false
(the default), SIP Server does not take any additional action
Note:
For SIP Server deployments using F5 Networks BIG-IP LTM, set sipresubscribe-on-nonotify
to true
.
SIP Server—Deployment Guide 533
Chapter 7: SIP Server Configuration Options Application-Level Options
sip-server-info
Default Value: No default value
Valid Values: A valid string or the special character
*
Changes Take Effect: For the next call
Related Feature: “Enabling Server and User-Agent Headers” on page 200
Specifies the value of the
Server
header that SIP Server includes in all reply messages that it sends. The value for this option can contain the following placeholders:
•
$VERSION$
= will be replaced with the current SIP Server build
•
$APP-NAME$
= will be replaced with the name of the application in the environment
You can also use the special value *, which is equivalent to
Genesys SIP
Server $VERSION$ ($APP-NAME$)
.
sip-timer-c-support
Default Value: false
Valid Values: true, false
Changes Take Effect: After restart
Controls Timer C functionality as described in RFC 3261. If enabled, SIP
Server applies the following logic to processing of the provisional responses it generates:
1. Start timer C when the first
1xx
(>
100
) response is sent out.
2. If timer activated, resend the last
1xx
response.
This functionality is disabled by default.
sip-tls-cert
Default Value: No default value
Valid Values: certificate thumbprint,
or valid path and filename
Changes Take Effect: After SIP Sever restart
Related Feature: “Transport Layer Security for SIP Traffic” on page 374
For Windows, set this to the thumbprint obtained from the user certificate generated for the host.
For Solaris, Linux, or AIX, set this option to the path and filename of the
.pem
encoded file that contains the host certificate.
534 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
sip-tls-cert-key
Default Value: No default value
Valid Values: A valid path and filename
Changes Take Effect: After SIP Sever restart
Related Feature: “Transport Layer Security for SIP Traffic” on page 374
For Solaris, Linux, or AIX, deployments only. Specifies the path and filename of the
.pem
encoded file that contains the host private key.
Note:
This option is only used when creating the initial connection. Changes to this option do not affect open connections (open connections are not closed).
sip-tls-cipher-list
Default Value: No default value
Valid Values: A colon-separated list of cipher suites, or cipher aliases, which includes the mandatory cipher suite
TLS_RSA_WITH_AES_128_CBC_SHA
Changes Take Effect: After SIP Server restart
Related Feature: “Transport Layer Security for SIP Traffic” on page 374
Specifies the list of preferred cipher suites to be used in TLS for SIP traffic.
SIP Server transfers the value of this option to the third-party software library that provides TLS. Configure the cipher list as a string of cipher operations, where each operation consists of an operator character (optional), followed by a name.
When creating the cipher list, you must follow these rules:
•
Use valid cipher names or cipher aliases. Valid names can contain the characters a-z
,
A-Z
,
0-9
, and a dash (
-
).
•
Separate names and aliases in the list with a colon (
:
).
•
Join multi-part names with the plus sign (
+
).
•
Use the exclamation character (
!
) immediately after a separating colon to indicate a kill operation. The cipher following this exclamation mark becomes unavailable.
•
Use the plus sign (
+
) immediately after the separating colon (
:
) to indicate an order operation. This moves the active cipher to the current position in the list of ciphers.
•
Use the minus sign (
-
) immediately after the separating colon (
:
) to indicate a delete operation. The cipher following a minus sign becomes inactive (though it remains available for further operations).
•
A non-operator character appearing immediately after a separating colon
(
:
) indicates an add operation. If the cipher following the character is not currently active, the cipher is added as an active cipher to the end of the list of available ciphers.
Table 105 lists the primary cipher aliases.
SIP Server—Deployment Guide 535
Chapter 7: SIP Server Configuration Options Application-Level Options
Table 105: Primary Cipher Aliases
Alias
kRSA, kDHr, kDHd and kEDH
Description
Key exchange types aRSA, aDSS, aNULL and aDH Authentication
DES, 3DES, RC4, RC2 and eNULL Ciphers
MD5 and SHA1 Message digests
Table 106 lists available cipher group aliases.
Table 106: Group Aliases
Alias
SSLv2
SSLv3
EXP
LOW
MEDIUM
HIGH
Description
All SSLv2 ciphers
All SSLv3 ciphers
All export ciphers
All low strength ciphers (no export ciphers, normally single DES)
128-bit encryption
Triple DES
Example: An example of a configured cipher list is as follows:
!ADH:RC4+RSA:HIGH:MEDIUM:LOW:EXP:+SSLv2:+EXP
In this example, the operator character and placement in the list instructs SIP
Server to interpret the cipher string using the following sequence:
1. Does not consider any ciphers that do not authenticate.
2. Uses ciphers RC4 and RSA
3. Includes HIGH, MEDIUM, and LOW security ciphers.
4. Adds all export ciphers.
5. Places all SSLv2 and export ciphers to the end of the list.
536 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
sip-tls-crl
Default Value: No default value
Valid Values: Valid file name
Changes Take Effect: After SIP Server restart
Related Feature: “Transport Layer Security for SIP Traffic” on page 374
Specifies the name of the file that contains one or more certificates in
PEM format, defining the Certificate Revocation List. As part of the authentication process, the system checks whether a presented certificate is included in this list of revoked certificates before completing authentication. This option applies only to UNIX operating systems.
sip-tls-sec-protocol
Default Value:
SSLv23
Valid Values:
SSLv23, SSLv3, TLSv1, TLSv11
Changes Take Effect: After SIP Server restart
Related Feature: “Transport Layer Security for SIP Traffic” on page 374
If configured, this option specifies the lowest version of TLS that SIP Server will use to send and accept secure connection requests with SIP devices.
This option can be used only on UNIX operating systems with Genesys
Security Pack on UNIX 8.5.100.09 or later. The option has no effect on
Windows. TLS versions are as follows:
•
SSLv23
—The highest TLS protocol version supported by Genesys Security
Pack 8.5.1. Currently, it is TLS version 1.2.
•
SSLv3
—SSL version 3.0.
•
TLSv1
—TLS version 1.0.
•
TLSv11
—TLS version 1.1.
If not configured or set to
SSLv23
(the default), SIP Server uses the highest TLS version supported by Genesys Security Pack 8.5.1. Currently, it is TLS 1.2.
sip-tls-mutual
Default Value: false
Valid Values: true, false
Changes Take Effect: After SIP Server restart
Related Feature: “Transport Layer Security for SIP Traffic” on page 374
Specifies whether SIP Server will request the client certificate and initiates a mutual TLS connection when SIP Server is in the TLS-Server role during authentication. To enable mutual TLS, set this option to true
.
SIP Server—Deployment Guide 537
Chapter 7: SIP Server Configuration Options Application-Level Options
sip-tls-target-name-check
Default Value: no
Valid Values: no
, host
Changes Take Effect: After SIP Server restart
Related Feature: “Transport Layer Security for SIP Traffic” on page 374
Specifies whether the host
field in the server certificate will be compared to the target host name during the authentication process. If you set the value for this option to host
, SIP Server tries to match the host field in the certificate with the target host name. If no match is found, the connection fails.
sip-tls-trusted-ca
Default Value: No default value
Valid Values: Valid path and filename
Changes Take Effect: After SIP Server restart
Related Feature: “Transport Layer Security for SIP Traffic” on page 374
For Solaris, Linux, or AIX, deployments only. Specifies the path and filename to a
.pem
encoded Certificate Authority (CA) file containing one or more certificates in PEM format.
Note:
This option is only used when creating the initial connection. Changes to this option do not affect open connections (open connections are not closed).
sip-treatments-continuous
Default Value:
false
Valid Values: true false
A routing strategy treatment is continuously played until the routing destination has answered the call.
A routing strategy treatment is not played continuously.
Changes Take Effect: Immediately for all new calls
Enables or disables a routing strategy treatment to be continuously played until the routing destination has answered the call.
Note:
When sip-treatments-continuous
is set to true
and sip-ring-tonemode
is set as
0
or
1,
the ringtone is not played. In order for the ringtone to be played, set sip-treatments-continuous
to false.
sip-treatment-dtmf-interruptable
Default Value: false
Valid Values: true, false
If set to true,
SIP Server stops playing all prompt elements while processing
RequestPlayAnnouncementAndDigits
treatments, as soon as the first DTMF digit is collected. If set to false,
SIP Server stops playing the current prompt, but then immediately after digit collection, starts playing the next prompt.
538 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
sip-user-agent
Default Value: No default value
Valid Values: A valid string or the special character
*
Changes Take Effect: For the next call
Related Feature: “Enabling Server and User-Agent Headers” on page 200
Specifies whether SIP Server includes the
User-Agent
header in all request messages that it sends. The value for this option can contain the following placeholders:
•
$VERSION$
= will be replaced with the current SIP Server build
•
$APP-NAME$
= will be replaced with the name of the application in the environment
You can also use the special value *, which is equivalent to
Genesys SIP
Server $VERSION$ ($APP-NAME$)
.
sip-vip-script-down
Default Value:
NULL
Valid Values: Valid name of the Application object
Changes Take Effect: After SIP Server restart
Dependent Option:
Related Feature: See the SIP Server 8.1 High-Availability Deployment Guide.
For the Hot Standby configuration, if the control-vip-scripts
option is set to true.
It specifies the name of the Application object representing the scripts that is used to disable the Virtual IP address (or the port for Windows NLB
Cluster) when SIP Server is switching to backup mode. The script must be configured as an Application object of type
Third Party Server.
For example, for a primary SIP Server, you will set the value of this option to
SIP_SERVER_PRIMARY_VIP_DOWN,
and for a backup SIP Server, you will set the value of this option to
SIP_SERVER_BACKUP_VIP_DOWN.
sip-vip-script-up
Default Value: NULL
Valid Values: Valid name of the Application object
Changes Take Effect: After SIP Server restart
Dependent Option:
Related Feature: See the SIP Server 8.1 High-Availability Deployment Guide.
For the Hot Standby configuration, if the control-vip-scripts
option is set to true.
It specifies the name of the Application object representing the script that is used to enable the Virtual IP address (or the port for Windows NLB
Cluster) when SIP Server is switching to primary mode. The script must be configured as an Application object of type
Third Party Server.
For example, for a primary SIP Server, you will set the value of this option to
SIP_SERVER_PRIMARY_VIP_UP
, and for a backup SIP Server, you will set the value of this option to
SIP_SERVER_BACKUP_VIP_UP.
SIP Server—Deployment Guide 539
Chapter 7: SIP Server Configuration Options Application-Level Options
stranded-calls-overflow
Default Value: No default value
Valid Values:
<destination_number>
, default
or
<empty string>
, recall
, release
, none
Changes Take Effect: Immediately
Related Feature: “Alternate Routing for Stranded Calls” on page 108
Related Option:
stranded-call-redirection-limit
Specifies a list of actions that SIP Server attempts to take for calls stranded on
ACD queues. You can configure these actions globally for all queues (at the
Application-level) or individually for a particular
ACD Queue
DN. Configure the actions using a comma-separated list of valid values; SIP Server tries to process each item in the list sequentially, moving to the next item if any action fails, and stopping after the first successful action begins (subsequent failure of the successful action does not restart the list).
Note:
For a description of the valid values and their related SIP Server
actions, see “Stranded Calls Overflow Valid Values” on page 109
.
stranded-on-arrival-calls-overflow
Default Value: No default value
Valid Values:
<destination_number>
, default
or
<empty string>
, recall
, release
, none
Changes Take Effect: Immediately
Related Feature: “Alternate Routing for Stranded Calls” on page 108
Related Option:
stranded-call-redirection-limit
Specifies a list of actions that SIP Server attempts to take for calls arriving on
ACD Queues with no logged-in agents. You can configure these actions globally for all queues (at the Application-level) or individually for a particular
ACD Queue
DN. Configure the actions using a comma-separated list of valid values; SIP Server tries to process each item in the list sequentially, moving to the next item if any action fails, and stopping after the first successful action begins (subsequent failure of the successful action does not restart the list).
Note:
For a description of the valid values and their related SIP Server
actions, see “Stranded Calls Overflow Valid Values” on page 109
.
stranded-call-redirection-limit
Default Value:
4
Valid Values:
0
–
15
Changes Take Effect: Immediately
Related Feature: “Alternate Routing for Stranded Calls” on page 108
Related Options: stranded-calls-overflow
and
stranded-on-arrival-callsoverflow
Limits the number of times that SIP Server tries to redirect a stranded call. Use this option to prevent infinite loops during stranded call redirection. SIP Server
540 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options stops trying to redirect the call after the configured number of attempts. The call remains waiting on the last attempted queue, regardless of its stranded state. As soon as a stranded call is successfully re-routed, the redirection-limit counter is reset.
subscription-delay
Default Value:
0
Valid Values:
0
–
10000
Changes Take Effect: Immediately
Specifies the time interval (in milliseconds) between the new individual
SUBSCRIBE
requests used to create new
SUBSCRIBE
dialogs that SIP Server sends if several
Voice over IP Service
DNs are configured with service-type
set to blf
.
Note:
Genesys recommends setting the option to a value in a range of
20
–
200
.
subscription-event-allowed
Default Value: No default value
Valid Values: String (‘*’, or name of package allowed)
Changes Take Effect: Immediately
Defines the Event packages allowed by SIP Server for integration with
Genesys SIP Feature Server. SIP Server rejects
SUBSCRIBE
messages for unsupported packages. The value asterisk (
*
) allows all subscriptions.
Notes:
Genesys recommends the setting
*
for this option. In this case, MWI uses the event message-summary
.
For more information about integrating with SIP Feature Server, see
SIP Feature Server 8.1 Deployment Guide.
subscription-timeout
Default Value:
180
Valid Values:
1
–
3600
Changes Take Effect: Immediately
Specifies the time interval (in seconds) in the
Expires
header of the
200 OK response to a
SUBSCRIBE
request only if the
Expires
header is missing in the
SUBSCRIBE
request.
summary-stat-timeout
Default Value:
60
Valid Values: Integer value
1
-
65535
Changes Take Effect: After SIP Server restart
Related Feature: “HTTP Monitoring Interface” on page 260
Specifies how often, in minutes, the summary statistics are calculated.
SIP Server—Deployment Guide 541
Chapter 7: SIP Server Configuration Options Application-Level Options
timed-acw-in-idle
Default Value: true
Valid Values: true, false
Changes Take Effect: Immediately
Related Feature: “Emulated Agents” on page 248
Specifies whether SIP Server applies the automatic wrap-up timer (using the wrap-up-time parameter) when an agent sends the
TAgentNotReady request while in idle state.
If set to false,
SIP Server does not automatically end manual wrap-up—the agent must return manually from ACW.
Note:
For compatibility with the previous SIP Server releases, you can use the name timed-cwk-in-idle for this option as an alias.
timeguard-reduction
Default Value:
0
Valid Values:
0
–
30000 ms
Changes Take Effect: Immediately
Related Feature: “Outbound IP Solution Integration” on page 317
Calculates the timer duration that SIP Server sends to Media Server to limit the time of the post-connect CPD detection. If the original post-connect CPD timeout value specified by the
option (in seconds) or
AttributeExtensions
is greater than zero (0), then the timeout value sent to Media Server is calculated as follows:
<original CPD post-connect timeout> - 'timeguard-reduction'
If the calculated value of the post-connect timeout to be sent to the Media
Server is less than 200 ms, then the timeguard-reduction
option is ignored and the original post-connect CPD timeout value is distributed.
This parameter can be used to improve the reliability of silence detection in the
Outbound Solution. A reduced post-connect CPD timeout in the Media Server should ensure the CPD result of silence is received by SIP Server before its own timer expires. A practical value of the timeguard-reduction
option can be slightly more than the round-trip time between SIP Server and Media Server.
An increased value of the timeguard-reduction
option improves the reliability of silence detection, but at the same time it shortens the time taken for the CPD post-connect detection for all scenarios. To avoid this, the value of the original
CPD post-connect timeout must also be increased when timeguard-timeout is defined. If millisecond precision is required for the definition of the postconnect CPD timeout in the Media Server, then the call_timeguard_timeout key in
AttributeExtensions
of
TMakePredictiveCall
must be used to define the original post-connect CPD timeout.
542 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
tlib-map-replace-dn
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Enables dynamic replacement of the
[dn]
pattern in SIP headers mapped from
T-Library attributes. If you set this option to true
, SIP Server replaces the [dn] pattern in mapped SIP messages with the digits of the DN where the SIP message is being sent. This applies to both
AttributeExtensions
mapping in
TRouteCall
, and
UserData
mapping as configured on a particular DN.
Note:
This
[dn]
pattern replacement functionality applies to SIP header mapping only, not to Request-URI parameters mapping.
tlib-nic-monitoring
Default Value: false
Valid Values: true, false
Changes Take Effect: After SIP Server restart
Related Feature: See “Network Status Monitoring” in the
SIP Server 8.1 High-
Availability Deployment Guide.
When set to true,
this option enables T-Library NIC IP status monitoring. The
T-Library IP address is taken from the
Host
object associated with the SIP
Server application. The Host object name is used to resolve the T-Library NIC
IP address.
unknown-bsns-calls
Default Value:
false
Valid Values: true, false
Changes Take Effect: Immediately
Related Feature: “Business-Call Handling” on page 249
Determines whether SIP Server considers unknown call types made from or to any agent, as business calls.
untimed-wrap-up-value
Default Value:
1000
Valid Value: Any nonzero positive integer
Changes Take Effect: Immediately
Related Feature: “Emulated Agents” on page 248
Specifies the threshold (in seconds) at which the timing of ACW stops and manual intervention is required (untimed ACW).
SIP Server—Deployment Guide 543
Chapter 7: SIP Server Configuration Options Application-Level Options
use-propagated-call-type
Default Value: never
Valid Values: never, monitor
Changes Take Effect: Immediately
Specifies whether SIP Server uses the call type as defined on the originating site for a multi-site consultation call. If this option is set to monitor,
SIP Server uses the call type defined at the origination site to identify whether to start monitoring. Genesys recommends using this option in environments where
Switch Partitioning functionality is enabled.
userdata-map-all-calls
Default Value: false
Valid Values: true, false
Changes take effect: Immediately
Specifies whether SIP headers are mapped for all calls. If you set this option to true, SIP Server maps the SIP headers to UserData (and/or Extensions) for all incoming calls, not just for the calls to a Routing Point. This functionality is required to extend the Network Asserted Identity mechanism from SIP
messages to T-Library events. For more details, see “Mapping SIP Headers and
and “Network Asserted Identity” on page 303 .
userdata-map-invite-after-refer
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
If this option is set to true
, SIP Server executes SIP-to-TLib mapping from the
SIP
INVITE
message received in response to a
REFER
request that SIP Server sent to an endpoint to transfer the request to a Routing Point. If this option is set to false
(the default), no mapping is performed from that
INVITE
.
Note:
If SIP-to-TLib mapping is configured for both
INVITE
and
REFER requests and the userdata-map-invite-after-refer
option is set to true
, then in cases where an unattended transfer is triggered by a 1pcc
REFER
, SIP Server maps data twice. First, SIP Server maps data from the received
REFER
, and then it maps data from the
INVITE
. If the same keys must be mapped from both
REFER
and
INVITE
(for example,
Call-
ID
), the keys from the
INVITE
take precedence.
userdata-map-trans-prefix
Default Value: No default value
Valid Values: A string
Changes Take Effect: Immediately
Related Feature: “Mapping SIP Headers and SDP Messages” on page 276
Contains a transport prefix to indicate what headers in the SIP message carry the mapped
UserData
. SIP Server adds this prefix to all data mapped to the
544 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options outgoing
INVITE
message. SIP Server scans incoming
INVITE
or
REFER messages used to place a call on the Routing Point for headers that start with this prefix, in addition to performing the normal mapping procedure. Also, SIP
Server scans mid-call messages
INFO
,
BYE
, and
UPDATE
for headers that start with this prefix and maps these to UserData.
If this option is not specified, no prefix is added to the transmitted data.
verify-sip-names
Default value: false
Valid Values: true, false
Changes Take Effect: Immediately
Enables forced verification of the dialed number, to ensure it contains only the following syntax:
•
characters
•
numbers
•
symbols:
-_.!~*'()&=+$,;?/
If set to true
, SIP Server analyses the user part and if it contains any unsupported syntax, SIP Server considers it invalid. For example, the space symbol is not supported—SIP Server will consider the user part to be invalid.
If set to false
, SIP Server does not enforce verification.
vip-state-change-timeout
Default Value:
10
Valid Values:
3-60
Changes Take Effect: Immediately
Related Feature: See the SIP Server 8.1 High-Availability Deployment Guide.
Defines the maximum time allotted (in seconds) for the Virtual IP control script to execute. If the script fails to change the Virtual IP state during this timeout, SIP Server executes the script again. After several unsuccessful attempts, SIP Server declares that the Virtual IP script failed. The same script is not executed after the timeout expires.
SIP Server—Deployment Guide 545
Chapter 7: SIP Server Configuration Options Application-Level Options
wrap-up-time
Default Value:
0
Valid Value: Any positive integer, untimed
0
Value greater than 0 but less than
Value equal to up-value untimed-wrap-
Value greater than untimed-
ACW is disabled.
The number of seconds of timed ACW, after which SIP Server returns the agent to the
Ready state.
ACW is untimed and the agent must manually return to the
Ready
state.
ACW is disabled.
wrap-up-value untimed
ACW is untimed and the agent must manually return to the
Ready
state.
Changes Take Effect: Immediately
Related Feature: “Emulated Agents” on page 248
Specifies the amount of ACW wrap-up time allocated to emulated agents at the end of a business call.
This option can be set in a number of places, and SIP Server processes it in the following order of precedence, highest first. If the value is not present at the higher level, SIP Server checks the next level, and so on.
SIP Server option priority processing:
1. In the call, in user data
WrapUpTime
(limited to ISCC scenarios).
2. In a
DN
configuration object of type
Routing Point
, in the
TServer
section.
3. In a
DN
configuration object of type
ACD Queue
, in the
TServer
section.
4. In the
TAgentLogin
request, in attribute extension
WrapUpTime
(applies to this agent only).
5. In an
Agent Login configuration object, in the
TServer
section.
6. In a
DN configuration object of type
Extension
, in the
TServer
section.
7. In a
DN
configuration object of type
ACD Queue
or
Routing Point that represents logged-in agents (
Agent Group
), in the
TServer
section.
8. In the SIP Server
Application object, on the
Options
tab in the
TServer section.
9. While in ACW, in the
TAgentNotReady
request with
WorkMode=ACW
(Extending ACW), in attribute extension
WrapUpTime
(applies to this agent only).
UPDATE, INVITE, INFO, and REFER Sections
The option names in this section are a combination of the
TEvent
attribute name ( extensions
or userdata
), a dash, then a numeric value.
546 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options
extensions-<n>
Default Value: No default value
Valid Values: A string containing any characters allowed in the header field name of a SIP message (according to RFC 3261) plus the colon character to address the parameter name of a header
Changes Take Effect: Immediately
Related Feature: “Mapping SIP Headers and SDP Messages” on page 276
The extension
prefix instructs SIP Server to put the SIP header (parameter) into the
Extensions attribute.
The value determines which header within the header parameter of the SIP message is processed. The value of the header/header parameter is added as a key-value pair into the attribute as follows:
<header_name>=<header_value>
You can use the colon character to address the parameter name of a header. For example, the extensions-8=From:tag
option puts the
From:tag=979E46B1-0FDF-
418F-BA3F-C03F95A4D6E0-2
key-value pair into the
Extensions attribute of the
EventRouteRequest
message.
userdata-<n>
Default Value: No default value
Valid Values: See description
Changes Take Effect: Immediately
Related Feature: “Mapping SIP Headers and SDP Messages” on page 276
The userdata
prefix instructs SIP Server to put the SIP header (parameter) in the
UserData attribute.
Log Section
There is one SIP Server-specific option available for the
Log
section. For the common
Log
options, see Chapter 10 on page 707 .
x-sip-log
Default Value: No default value
Valid Values: The file name
Changes Take Effect: After SIP Server restart
Related Feature: “Multi-Threaded Logging” on page 290
Related Option:
Specifies whether SIP Server creates a single log file for T-Library messages, or separate log files for other threads when operating in multi-threaded mode.
If this option is specified, SIP Server creates separate log files according to the
configuration option sip-link-type
. To configure this option, enter a path and file name where the log files will be created.
SIP Server—Deployment Guide 547
Chapter 7: SIP Server Configuration Options Application-Level Options
If this option does not exist in the configuration, SIP Server generates log files for all running threads. If this option is configured as an empty string, SIP
Server generates a single log file for only the main thread.
Note:
The SIP processing log file inherits only the following settings from the common log options: expire, segment, verbose.
x-sip-mask-sensitive-data
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Related Feature: “Masking Sensitive Data in SIP Messages” on page 286
Specifies whether SIP Server masks sensitive data in SIP messages contained in SIP Server logs.
If set to true
, SIP Server masks all private SIP header values and SIP message body content of all types, except for application/sdp
and application/vnd.radisys.msml+xml
. If the message contains application/vnd.radisys.msml+xml
, SIP Server masks it only when it contains user data.
If set to false
, SIP Server does not mask sensitive data in SIP messages contained in SIP Server logs.
Multi-Site Support Section
This section must be called extrouter
.
default-network-call-id-matching
Default Value: No default value
Valid Values: sip
Changes Take Effect: Immediately
When this option is set to sip,
SIP Server will use the content of the
X-ISCC-
CofId
header for the ISCC/COF call matching.
To activate this feature, the
true.
overload Section
This section must be called overload
.
log-reduce-cpu-threshold
Default Value:
0
Valid Values:
0
,
5-100
Changes Take Effect: Immediately
Related Feature: “CPU Usage Overload Control” on page 327
Specifies the CPU usage overload threshold in percent. When the SIP Server
CPU usage increases beyond the specified value, SIP Server is considered
548 Framework 8.1
Chapter 7: SIP Server Configuration Options Application-Level Options overloaded and the log level is decremented. The default value of
0
(zero) disables the dynamic overload control feature.
SIP Error Map Section
This section must be called
SipErrorMap
.
sip-<SIP_error_code>
Default Value: No default value
Valid Values:
399 < integer < 700
Changes Take Effect: For the next predictive call
Maps a particular 3-digit SIP error code (as defined in various SIP RFCs) with an integer that represents an
AttributeCallState
value included in the
TEvent response to a
TMakePredictiveCall
request. For the SIP error code variable
(
<SIP_error_code>
in the option name), use any integer value from
400
to
699
.
For example, sip-404
, sip-600
, and so on. For the value of this option, use the identifying number for the particular
TEvent
message that you want to map.
See Table 107 for a list of available
TEvent
messages and their corresponding identifying number.
Table 107: TEvent Identifiers
12
13
14
15
16
7
8
10
11
5
6
3
4
Identifying
Number
TEvent
CallStateGeneralError
CallStateSystemError
CallStateRemoteRelease
CallStateBusy
CallStateNoAnswer
CallStateSitDetected
CallStateAllTrunksBusy
CallStateSitInvalidnum
CallStateSitVacant
CallStateSitIntercept
CallStateSitUnknown
CallStateSitNocircuit
CallStateSitReorder
SIP Server—Deployment Guide 549
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
Table 107: TEvent Identifiers (Continued)
Identifying
Number
26
TEvent
CallStateDropped
27
28
CallStateDroppednoanswer
CallStateUnknown
Notes:
• Make sure that configured mapping does not inadvertently affect
OCS functionality. For example, the
CallStateBusy
message in
EventReleased
is only used in scenarios when the dialed endpoint is found to be busy—not in any other scenario.
• If the media gateway rejects the
INVITE
with an error code, SIP
Server checks to see if the Paraxip header
CPD-Result
is present in the response. If so, the value of this header is mapped to the call state. If not, the SIP error code is converted to the
CallState
in accordance with existing mapping.
Agent Login–Level and DN-Level Options
Set configuration options described in this section in the
TServer
section (or
AuthClient
section) of the relevant
Agent Login
or
DN
object in Configuration
Manager or Genesys Administrator.
Note:
For individual DNs configured behind a softswitch (the contact option is not configured), all DN-level option values are taken from the corresponding softswitch DN (
Voice over IP Service
DN with service-type
set to softswitch)
, and not from the settings on the individual DN. So in effect, all DNs configured behind a softswitch share identical DN-level values.
The one exception is the option sip-alert-info,
where the value is taken from the individual DN even if it is behind a softswitch.
AuthClient Section
The option names in this section are used to properly calculate authorization parameters used to prepare responses to
401
authorization challenges.
550 Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
password
Default Value: No default value
Valid Values: Any string
Changed Take Effect: Immediately
Related feature: “SIP Authentication” on page 360
Specifies the password to be included when generating the response to a Digest challenge on this outbound
Trunk
DN.
username
Default Value: No default value
Valid Values: Any string
Changed Take Effect: Immediately
Related feature: “SIP Authentication” on page 360
Specifies the username to be included when generating the response to a
Digest challenge on this outbound
Trunk
DN.
TServer Section
after-call-divert-destination
Default Value: No default value
Valid Value: Any valid DN
Changes Take Effect: Immediately
Related feature: “Call Divert Destination” on page 121
Specifies the destination DN where SIP Server will divert the call in cases where the caller remains on the line when all other parties have left. For example, use this feature to send callers to an after-call survey.
Note:
The after-call-divert-destination
option is supported only for inbound calls in single-site deployments.
agent-greeting
Default Value:
NULL
Valid Values: Any file name played to the agent
Changes Take Effect: For the next call
Related Feature: “Personal Greetings” on page 330
Specifies the media file name that will be used as a greeting for the agent.
Note:
When used in conjunction with customer-greeting
, if either the customer or agent greeting, for whatever reason, cannot be played,
SIP Server does not attempt to play another greeting, but immediately connects the customer and agent. No greetings are played.
SIP Server—Deployment Guide 551
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
agent-reject-route-point
Default Value: No default value
Valid Values: Any valid Routing Point
Changes Take Effect: Immediately
Related Feature: “VXML Support for Agent Greeting” on page 332
Specifies the Routing Point where a call is queued if an agent rejects the call.
This is used only in multi-site VXML greeting scenarios with the ISCC transaction type route
for determining if an agent is willing to accept the call.
URS can route the call from this Routing Point to the origination Routing Point at the origination SIP Server.
audio-codecs
Default Value: telephone-event, PCMU, PCMA, G723, G729, GSM
Valid Values: Any from the list of telephone-event, PCMU, PCMA, G723,
G729, and
GSM
words, delimited by commas. Unrecognized words are ignored.
Changes Take Effect: For the next call
Related Option:
For a description of this option, see the Application-level option “audiocodecs” on page 450 .
Note:
The audio-codecs
option takes effect for SDP renegotiation if the DN-
level sip-enable-sdp-codec-filter
true
.
authenticate-requests
Default Value: No default value
Valid Values: register
, invite
Changes Take Effect: Immediately
Determines if incoming SIP requests (
REGISTER
or
INVITE
) are treated with an authentication procedure when the following conditions are true:
•
The name of the incoming SIP message exits in the list of the authenticate-requests
parameter.
•
The option password
is configured on the same
DN
object.
Both authenticate-requests
and password
configuration options must be configured on the DN, otherwise no requests will be authenticated.
auto-answer-after
Default Value: No default value
Valid Values: Any valid number
Changes Take Effect: For the next call
Specifies the value that SIP Server adds to the answer-after
parameter in the
Call-Info
header of the
INVITE
message that it sends to a SIP Endpoint.
552 Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
auto-logout-ready
Default Value: false
Valid Values: true
, false
Changes Take Effect: Immediately
Related Feature: “Automatic Inactive Agent Logout” on page 119
Enables a stricter enforcement of the automatic agent-logout policy (as set in the related auto-logout-timeout
option). If this option is set to true
, SIP
Server will log out the agent regardless of agent state. If it is set to false
, SIP
Server will not log out agents in the following agent states:
Ready
,
NotReady/ACW
,
NotReady/AuxWork
,
NotReady/LegalGuard
.
You can configure this option in the
TServer
section of the following objects
(listed in order of precedence):
•
Agent Login
object (
Annex
tab)
•
DN object (
Annex
tab of the
ACD Position
or
Extension
DN) that represents the device to which the agent is logged in.
•
DN object (
Annex
tab of the
Routing Point or
ACD Queue
DN) that represents the queue to which the agent is logged in.
•
SIP Server
Application
object (
Options
tab), which specifies the serverwide default.
auto-logout-timeout
Default Value:
0
Valid Values:
0
, or any positive integer up to
35791
Changes Take Effect: Immediately
Related Feature: “Automatic Inactive Agent Logout” on page 119
Enables automatic agent logout and specifies the length of time after which the logout occurs (in minutes). To enable this feature, enter a value of
1
or greater; the agent is allowed to remain inactive for this length of time before having to be automatically logged out. To disable this feature, enter a value of
0
(default).
You can configure this option in the
TServer
section of the following objects
(listed in order of precedence):
•
Agent Login
object (
Annex
tab)
•
DN object (
Annex
tab of the
ACD Position
or
Extension
DN) that represents the device to which the agent is logged in.
•
DN object (
Annex
tab of the
Routing Point or
ACD Queue
DN) that represents the queue to which the agent is logged in.
•
SIP Server
Application
object, which specifies the server-wide default.
SIP Server—Deployment Guide 553
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
auto-redirect-enabled
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Enables direct routing to the target URI from a SIP
3xx
redirect response to an
INVITE
.
The following events describe the effect of this option:
•
SIP Server sends an
INVITE
request to another SIP device.
•
SIP Server receives a
3xx
response containing a new target Uniform
Resource Identifier (URI).
•
SIP Server generates a new
INVITE
as follows:
If auto-redirect=true
, SIP Server copies the new target URI to the request URI of the
INVITE
and sends the
INVITE
to the location specified in the host portion of the target URI.
If auto-redirect=false
, SIP Server determines the redirect target by processing the username portion of the returned target URI. The routing of the
INVITE
is determined by SIP Server configuration.
This option must be set in the
TServer
section on the
Trunk
DN.
beep-duration
Default Value:
2000
(milliseconds)
Valid Value: Up to a maximum of 10000 (milliseconds)
Changes Take Effect: Immediately
Specifies the length of time, in milliseconds, GVP Media Control Platform
(MCP) will play the beep tone if one is requested for the call. Configure this option on the Resource Manager
Trunk Group
DN. If the beep-duration timer expires before SIP Server receives a notification from GVP that the beep tone is finished, SIP Server proceeds with connecting the agent with the called customer.
blind-transfer-enabled
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Specifies whether SIP Server processes certain transfer requests while a consultation call is in the dialing state. If set to true,
SIP Server processes
TCompleteTransfer
requests or SIP
REFER
messages while a consultation call is
554 Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options in the dialing state. Otherwise, such requests are rejected. This option is configured on the transfer target DN.
Notes:
• This option can also be configured at the Application level. The option setting at the DN level takes precedence over the
Application level setting.
• This option is for blind transfers only. Blind conference calls are not supported.
capacity
Default Value:
0
Valid Values: Any positive integer
Changes Take Effect: Immediately
Related Feature: “Trunk Capacity Control” on page 379
Specifies how many calls can be handled by a specific Voice over IP device represented in the SIP Server configuration as either a
Trunk
DN, or a
Voice over IP Service
DN with service-type
set to softswitch
.
capacity-group
Default Value:
<DN name>
Valid Values: Any non-empty string
Changes Take Effect: Immediately
Related Feature: “Trunk Capacity Control” on page 379
Specifies the name of the group of DN objects of type
Trunk
or
Voice over IP
Service
( service-typ e set to softswitch
) with shared capacity. All DNs configured with the same capacity-group
share the device capacity defined in the
option.
Note:
The value of the capacity
option must be defined in only one
Trunk
or
Voice over IP Service
DN in any particular capacity-group
.
capacity-limit-inbound
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Related Feature: “Trunk Capacity Control” on page 379
When set to true,
enables rejection of incoming calls if a limit on the total
number of calls for a trunk (or trunks) specified by the capacity
option is reached. This option must be specified on the same
Trunk
DN where the capacity
option is defined.
SIP Server—Deployment Guide 555
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
charge-type
Default Value:
0
, Effect varies according to DN type
DN Type Default Effect
Voice over IP Service free
Trunk Group charged
Extension charged
Valid Values:
0
Default. Charge type is not set. Charging is based on DN type.
1
Free. Charge type is free (including an agent).
2
Charged. Charge type is charged (including IVR).
Changes Take Effect: Immediately (in some cases the change is not considered if the device is currently in a call)
Related Feature: “Early Media for Inbound Calls” on page 247
Related Trunk Options: “sip-early-dialog-mode” on page 603
and “sip-serverinter-trunk” on page 612
Specifies whether a charge will be incurred for services that are supplied by the
DN.
Early media audio treatments can be applied to a call by doing one of the following:
•
Setting charge-type
to
0
for
Voice over IP Service
DNs, when Media
Server is used.
•
Setting charge-type
to
1
for
Extension
or
Trunk Group
DNs when an external media server or IVR is used (for example,
Trunk Group
DNs that represent access numbers to connect the call to an external IVR/GVP by using its own IVR T-Server).
Notes:
• This option is currently supported on
Trunk Group
,
Extension
, and
Voice over IP Service
DNs only.
• Once the call is established (
200 Ok
is sent), no further early tollfree services are possible.
• In addition to the
and charge-type
options,
Genesys recommends that you also set the
option on the SIP Server
Application
object to false
.
556 Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
clamp-dtmf-enabled
Default Value: false
Valid Values: true, false
Changes Take Effect: For the next call
Related Feature: “DTMF Clamping in a Conference” on page 234
When set to true
on a
Trunk
or
Trunk Group
DN that is added to a conference, enables DTMF clamping for all parties except the DN where this option is configured.
When set to false,
disables DTMF clamping.
This option applies only to
Trunk
and
Trunk Group
DNs.
connect-nailedup-on-login
Default Value: An empty string
Valid Values: Routing Point number, gcti::park
Changes Take Effect: At the next agent login session
Related Feature: “Nailed-Up Connections” on page 298
Specifies SIP Server actions when receiving a
TAgentLogin
request from a DN with the configured nailed-up connection, as follows:
•
When this option is set to a DN of type
Routing Point,
SIP Server immediately establishes a nailed-up connection between an agent’s endpoint and the specified Routing Point. After processing the
TRouteCall request to the gcti::park
device, SIP Server parks the agent on gcti::park
, establishing the persistent SIP connection with the agent’s endpoint.
•
When this option is set to gcti::park,
SIP Server parks the agent on the gcti::park
device directly, establishing the persistent SIP connection with the agent’s endpoint.
•
When the value for this option is not specified (the default), SIP Server does not take any action.
At a DN level, this option must be set on an agent
Extension
DN, or, if this DN is located behind the softswitch on the respective softswitch DN.
Note:
This option can be configured at both Application and DN levels.
Setting at the DN level takes precedence over the Application level.
contact
Default Value: No default value
Valid Values Any alphanumeric string
Changes Take Effect: For the next call, except in Active-Active RM deployments in which the change takes effect only after SIP Server restart.
Contains the contact URI, specifying the device’s IP address, if this address is fixed. This option is necessary only for standalone configurations, and only if
SIP Server—Deployment Guide 557
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options the configured device does not register itself in the SIP Server registrar. It is part of the persistent registrar feature.
For example, if the SIP device sends a
REGISTER
request to SIP Server and this request is accepted, SIP Server uses the contact information from the
REGISTER request, and updates (or creates) in the Configuration Layer the option contact in the
TServer
section of the corresponding
DN
object.
The URI format is:
[sip:][number@]hostport[
; transport={tcp/udp}]
OR
[sip:][number@]srvFQDN[
; transport={tcp/udp}]
Where:
•
sip:
is an optional prefix.
•
number is the DN number. This is currently ignored.
•
hostport
is a host:port
pair, where host
is either a dotted IP address or a
DNS-resolvable hostname for the endpoint.
Note:
If the port number is not included (only the hostname is included), then SIP Server will try to resolve the hostname using DNS SRV
records. For more information, see “DNS Name Resolution” on page 232
.
•
srvFQDN is the SRV FQDN.
•
transport=tcp
or transport=udp
is used to select the network transport.
The default value is udp
.
Transport Layer Security (TLS). To enable TLS for SIP traffic sent to this device, append the value with the following parameter: transport=tls
.
In this case, the URI format is:
[sip:][number@]hostport;transport=tls
In this case, the same security certificate used for the SIP listening port as configured will be used for SIP traffic to this DN.
Note:
For SIP signaling over UDP, the size limit for an individual SIP message is 16 kilobytes. This allows the entire SIP message to fit within a single UDP packet.
558 Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
contact-list
Default Value: No default value
Valid Values: A comma-separated list of SIP URIs in the format given below
Changes Take Effect: After SIP Server restart
Specifies a list of SIP URIs to support multiple IP address features without
DNS. All URIs in the list must use the same transport (UDP/TCP/TLS).
Configure each URI using the following format:
[sip/sips:][number@]hostport[;transport=(tcp/udp/tls)] where:
•
sip/sip
is an optional prefix
•
number
is the DN number (currently ignored)
•
hostport
is the host:port pair, where the host is a dotted IP address for the endpoint
Note:
The contact-list
option is only applicable for Active-Active RM integration (and thus it only applies to a
Voice over IP Service
DN).
contacts-backup
Default Value: No default value
Valid Values: A comma-separated list of any valid SIP URI
Changes Take Effect: For the next call
Specifies a list of SIP URI addresses that supplement the SIP URI specified in the contact
option. All URIs in the complete list ( contact + contacts-backup
) are considered with the same priority and must use the same transport
( udp/tcp/tls
). You can apply this option to
Trunk
and
Voice over IP Service
DNs only. SIP Server uses the Active Out-of-Service Detection feature ( ooscheck
, oos-force
, and recovery-timeout
options) to determine which node in the cluster is currently available to handle SIP requests. Configure each URI using the following format:
[sip:][number@]hostport[;transport=(tcp/udp/tls)]
Note:
The same combination of IP/hostname, port, and protocol must not be used in more than one DN if Active Out-of-Service Detection is enabled. If an incorrect configuration is applied, SIP Server may incorrectly match SIP requests to DNs, or it may inadvertently switch a working DN to Out-of-Service, along with other possible errors.
For integration with Cisco Unified Communications Manager (UCM), you must configure this option on the
Trunk
DN used to control presence subscription, in cases where more than one Cisco SIP trunk is deployed.
SIP Server—Deployment Guide 559
Chapter 7: SIP Server Configuration Options
560
Agent Login–Level and DN-Level Options
cos
Default Value: No default value
Valid Values: Any COS
Voice over IP Service
DN ( service-type=cos
)
Changes Take Effect: For the next call
Related Feature: “Class of Service” on page 179
Specifies the Class Of Service (COS) DN assigned to this DN/Agent Login.
Class of Service (COS) is the functionality that defines telephony capabilities for a device or an agent. This option is used in both of the dial plan-related features supported by SIP Server: Class of Service and Dial Plan. For more information about how to use this option for either functionality, see the following:
•
“Class of Service” on page 179
•
cpn
Default Value: No default value
Valid Values: A name that will be used as the user part of the SIP URI
Changes Take Effect: For the next call
Specifies the user part to be included in the SIP URI. SIP Server handles this option differently depending on the following scenarios:
•
cpn
is configured on an
ACD Position or
Extension
DN.
•
cpn
is configured on a
Trunk
DN.
If configured on an
ACD Position
or
Extension
DN, SIP Server uses the value of this option as the user part of the SIP URI in the
From
header of the
INVITE message that it sends from this DN to the destination DN. Since this option is used to provide customized caller-ID information to the destination, this option must be configured in the originating DN.
If configured on a
Trunk
DN, SIP Server uses the value as the user part of the
SIP URI in the
From
header of the
INVITE
message it sends to the DN. This special case is used to provide customized caller-ID information for all calls routed through this Trunk (similar to the replace-prefix
option).
Note:
If the option is configured on both the
Extension
and
Trunk
DNs (or
ACD Position
and
Trunk
DNs), when a call is made from
Extension
to
Trunk
(or
ACD Position
to
Trunk
), the value from the option on the
Trunk
takes priority.
cpn-digits-to-both-legs
Default Value: false
Valid Values: true, false
Changes Take Effect: For the next call
Related Feature: “Modifying the From Header in SIP INVITE” on page 290
This option applies to a
TMakeCall
request containing the
CPNDigits
key-value pair in
AttributeExtensions
. If set to true,
SIP Server replaces the
User-Name
Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options in the
From
header of the
INVITE
message with the value of the
CPNDigits
, when sending the
INVITE messages to a call originator and a call destination.
cpn-dnis
Default Value: An empty string
Valid Values: Any string containing the name of the VoIP Service DN with service-type=dial-plan
Changes Take Effect: For the next call
Related Feature: “Modifying the From Header in SIP INVITE” on page 290
If configured, SIP Server replaces the
User-Name in the
From
header of the
INVITE
message with the value produced by applying dial-plan rules to the call
DNIS, when sending the
INVITE
to the device/DN where this option is specified. This option applies only to inbound calls.
cpn-self
Default Value: An empty string
Valid Values: Any string
Changes Take Effect: For the next call
Related Feature: “Modifying the From Header in SIP INVITE” on page 290
If configured, SIP Server replaces the
User-Name
in the
From
header of the
INVITE
message with the value of this option, when sending the
INVITE
to the device/DN where this option is specified. This option takes precedence over any other cpn
-controlling option and the
CPNDigits
key in
AttributeExtensions of a T-Library request.
cpd-capability
Default Value: No default value
Valid Values: audiocodes
, paraxip
, mediaserver
Changes Take Effect: Next
TMakePredictiveCall
request
Identifies a particular device as capable of performing call progress detection
(CPD). You can configure this option on
Trunk
DNs for media gateways, or on
Trunk Group
DNs for GVP Media Server functionality. For media gateways, you can set the value of this option to either of two supported CPD-capable gateways: paraxip
or audiocodes
. For CPD on the media server, you must set the cpd-capability
option on the Resource Manager
Trunk Group
DN to mediaserver
.
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).
SIP Server—Deployment Guide 561
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
customer-greeting
Default Value:
NULL
Valid Values: Any file name played to the customer
Changes Take Effect: For the next call
Related Feature: “Personal Greetings” on page 330
Specifies the media file name that will be used as a greeting for the customer.
The customer greeting plays continuously until the agent greeting finishes playing. The
agent-greeting
and customer-greeting option values are used as follows:
•
When both options contain different file name values, each file will be played to the customer and the agent as specified.
•
When only one option contains a value, the same file will be played to both the customer and the agent.
•
When neither option contains a value, no greeting will be played to either the customer or the agent.
Note:
When used with agent-greeting
, if either the customer or agent greeting, for whatever reason, cannot be played, SIP Server does not attempt to play the other greeting but immediately connects the customer and agent. No greetings are played.
default-dn
Default Value:
NULL
Valid Values: Any valid DN
Changes Take Effect: For the next call
This option can be configured only on DNs of type Routing Point. Specifies the DN to which calls are sent when URS is nonoperational, or when the timeout specified in the router-timeou t option expires. This option does not apply to calls that are delivered to an ACD Queue associated with the Routing
Point.
Note:
This option can also be configured at the Application level. The DNlevel setting takes precedence over the Application-level setting.
default-music
Default Value: No default value
Valid Value: Name and path of any valid audio file
Changes Take Effect: Immediately for all new calls
Related Feature: “Customizing Music on Hold and in Queue” on page 194
This option can be configured on an agent’s Extension DN, an Agent Login, and an ACD Queue DN. Specifies the name of the file that is played for the music-on-hold treatment to a caller when a respective agent places the call on hold or when the call is waiting on an ACD queue. The option applies to calls distributed to this agent, unless a call is passed through a Routing Point with
562 Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options the
option, or a call is distributed with the
TRouteCall
request that contains the
key in
AttributeExtensions
.
Note:
This option can also be configured at the Application level, the DN level, and the Agent Login level. The Agent-Login level setting takes precedence over the Application or DN level settings.
dial-plan
Default Value: No default value
Valid Values: Any dial-plan
Voice over IP Service
DN
Changes Take Effect: For next
INVITE
or 3pcc operation
Related Feature: “Dial Plan” on page 210
Specifies which dial-plan DN will be applied to calls. You can define the option on any of the following locations listed in order of priority:
•
Agent Login—Applies to calls made by a caller logged in under this
Agent
Login
ID.
•
DN-level—Applies to calls made from this DN (where
Agent Login
dialplan is undefined).
•
Application-level—Applies to all calls (where no
Agent Login
or DN dialplan is defined).
dial-plan-rule-<n>
Default Value: No default
Valid Values: A string in the following format pattern => digits;param1=value1;param2=value2 (etc...) # comment
Changes Take Effect: For the next call
Related Feature: “Dial Plan” on page 210
Defines the dial-plan rule. Each rule contains a pattern and an instruction. SIP
Server tries to match the dialed number against the patterns defined for all dialing rules on the dial-plan DN.
Each dial-plan rule is made up of the following parts: pattern => digits;
Specifies the pattern-matching syntax that is matched against the number that was dialed. SIP Server uses
the Asterisk format (see Table 53 on page 214
).
Specifies the digits SIP Server will use to make the call instead of the digits that were actually dialed.
These digits can be any alphanumeric string ending with a semicolon (;). The specific meaning is defined by the value of the type parameter.
You can also use the
{DIGITS}
variable—in the format
${DIGITS:X:Y}
—to further define how the dialed digits will be translated into the actual digits used to make the call.
SIP Server—Deployment Guide 563
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options parameters
( param1=value1
; ...)
Specifies a variety of parameters used to control SIP
Server actions when processing the dial-plan.
comments
(
[space]#)
A string. Any data after the # is ignored. You must include a space before the #, otherwise SIP Server interprets it as a regular character.
For a detailed description of the syntax required for this option, see the following sections:
•
“Pattern Matching” on page 214
•
“Digit Translation” on page 215
•
“Dial Plan Parameters” on page 216
disable-media-before-greeting
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Related Feature: “Disabling Media Before Greeting” on page 334
Specifies whether SIP Server establishes a call in hold state if greetings are configured to be played for a caller and an agent. If set to true,
SIP Server establishes a call in hold state (an SDP to the caller and the agent is placed on hold/inactive state). If the recording is enabled, the SDP to a recorder is also placed on hold before the greeting is played. If set to false,
SIP Server establishes the call in active state and the media is played before the greeting.
Note:
This option can be configured at both Application and DN levels.
Setting at the DN level takes precedence over the Application level. If this option is set at an Application level and if a particular DN does not support this functionality, this option must be explicitly set to false
for that DN. For a DN-level activation of this feature, this option must be set for both origination and destination DNs.
disconnect-nailedup-timeout
Default Value:
0
Valid Values: Any positive integer
Changes Take Effect: At the next nailed-up connection
Related Feature: “Nailed-Up Connections” on page 298
Specifies whether SIP Server terminates an agent’s nailed-up connection because of the agent’s inactivity. When set to a non-zero value, SIP Server waits this time interval, in seconds, before terminating the agent’s nailed-up connection. When set to
0
(the default), SIP Server does not terminate the agent connection.
Note:
This option can be configured at both Application and DN levels.
Setting at the DN level takes precedence over the Application level.
564 Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
display-name
Default Value: No default value
Valid Values: A string
Changes Take Effect: For the next call
Related Option:
Specifies the string that will be sent as a display name in the
From
header of the
INVITE
request. This option is supported for the following DN types:
•
Extension
•
ACD Position
•
Routing Point
•
Trunk Group
•
Trunk
When this option is configured on a
Trunk
DN, it is activated by the cpn
option.
If there is no cpn
option configured on the
Trunk
DN, SIP Server passes the
INVITE
through the trunk without modifying the display name. If the
Trunk
DN has the cpn
option configured, SIP Server replaces the display name in the
From header of the
INVITE
with the value of the display-name
option, if this option is configured. If the
Trunk
DN has the override-domain-from
option configured,
SIP Server does not populate the display name in the
From
header, even if the call origination DN has the display-name
option configured.
SIP Server obtains the display name it populates in the
From
header of the outgoing
INVITE
from the following source, in order of precedence:
1. The extension keys,
CPNDigits
and
DisplayName
, of T-Library requests.
2. The
Trunk
DN of the call destination.
3. DNs of type
Extension, ACD Position, Routing Point, and
Trunk Group
.
This option applies only if the use-display-name
configuration option is set to
true
(the default).
divert-on-ringing
Default Value: true
Valid Values: true false
SIP Server generates
EventRouteUsed
and
EventDiverted messages when any SIP
18x response (
180 Ringing
or
183
Session Progress
) arrives for the
INVITE
request at the routing destination.
SIP Server postpones
EventRouteUsed
and
EventDiverted messages until the call is answered by the routing destination with a SIP
200 OK
message. If the call is not answered within the value specified by the after-routing-timeout
option, the destination SIP dialog is canceled and an
EventError
message is generated.
Changes Take Effect: For the next call
SIP Server—Deployment Guide 565
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
Determines SIP Server behavior when routing calls. You can configure this option on Routing Point DNs only. You can also configure the divert-onringing
key in the
Extensions
Attribute for
TRouteCall
messages.
dr-forward
Default Value: off
Valid Values: off no-agent oos
DR forwarding to the peer switch is disabled. SIP Server delivers calls to a DN on the local switch.
SIP Server forwards the call to its DR peer when there is no agent logged into the DN.
SIP Server forwards the call to its DR peer if an endpoint is in an Out-Of-Service (OOS) state.
Note: Use this value if a SIP phone is configured to work in
Business Continuity mode with a single SIP registration.
Changes Take Effect: Immediately
Defines a system-wide mode of forwarding inbound and internal calls when
SIP Server is operating in Business Continuity mode. This option can also be set at the Application level. The setting at the DN level takes precedence.
dr-oosp-transfer-enabled
Default Value: true
Valid Values: true, false
Changes Take Effect: For the next call
In Business Continuity deployments, for special circumstances where an inbound call remains on the same site where it arrives and SIP Server puts itself Out of Signaling Path. This option is supported only for
Trunk
DNs pointing to external destinations. It must not be configured on the trunks between SIP Servers.
If set to false
on the
Trunk
DN from where an inbound
INVITE
is received, SIP
Server stays in the signaling path if the call, after being processed on the
Routing Point DN, is sent to the local
Extension
DN where the DR call forwarding procedure is applied to deliver the call to the corresponding DN on the peer SIP Server. If set to true (the default), SIP Server puts itself Out Of
Signaling Path.
dual-dialog-enabled
Default Value: true
566 Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
Valid Values: true false
Set the option to true
for endpoints that accept more than one
SIP dialog and can provide hold/retrieve control over SIP
(usually through SIP
NOTIFY
).
Set the option to false
for endpoints that can only accept one active SIP dialog and for endpoints that can accept more than one dialog but cannot provide hold/retrieve control over SIP
(usually through SIP
NOTIFY
).
Changes Take Effect: For the next call
Enables the SIP dialog functionality for making consultation calls according to the endpoint type. If the option is set to false,
SIP Server, while making a
3pcc consultation call, will not allocate a new dialog but uses the existing dialog to connect the DN to the destination (while the other party from the main call is on music). All operations—alternate, reconnect, hold, and retrieve—can be performed through the re-
INVITE
operation without the need for
NOTIFY
processing.
Note:
After a regular SIP phone allows the second SIP dialog, it blocks the first dialog from the attempt to re-
INVITE
. Only pushing a phone button (such as hold/retrieve) may unblock it. The alternate way to unblock the phone is through the SIP
NOTIFY
message with a special event—hold or talk—that does the same action as the corresponding phone buttons. (See the sip-cti-control
option values talk,hold
.)
Setting dual-dialog-enabled=false
means that either sip-cti-control is not configured or has only partial support such as sip-cticontrol=talk
(the phone that does allow answering the call through
“talk” but does not allow to retrieve it from hold).
emergency-backup
Default Value: No default value
Valid Value: A string
Changes Take Effect: Immediately
Related Feature: “E911 Emergency Gateway” on page 240
Specifies IP addresses, in a comma-separated list, of backup devices used for the Emergency Gateway (EGW) in integrations with the 911 Enable service.
The first entry in this list must be the address for the EGW; all other entries should represent any PSTN Trunks that could conduct Emergency Calls.
Note:
For the callback Trunk, this option must contain the single address of the backup EGW only.
SIP Server—Deployment Guide 567
Chapter 7: SIP Server Configuration Options
568
Agent Login–Level and DN-Level Options
emergency-callback-plan
Default Value: No default value
Valid Value: A string
Changes Take Effect: Immediately
Related Feature: “E911 Emergency Gateway” on page 240
Specifies the name of the
Voice over IP Service
dial-plan DN created for integration with the 911 Enable (E911) Emergency Gateway (EGW). For deployments that support Direct Inward Dialing (DID), you must:
1. Configure the dial plan itself so that its dialing rule converts the calling DN
(ANI) into a 10-digit call back number (CBN) that SIP Server will include in the P-Asserted-Identity header of INVITE requests it sends on behalf of registered DNs, when processing 911 calls.
2. On the
Trunk Group
DN representing the EGW, set the e mergencycallback-plan option to the name of the ANI-to-CBN dial-plan DN.
Note:
For deployments that do not support DID, do not configure this option. Instead, you must configure the
Trunk
DNs to represent the
EGW as described in Step 3 of the Table 60 on page 240 .
emergency-device
Default Value: false
Valid Value: true, false
Changes Take Effect: Immediately
Related Feature: “E911 Emergency Gateway” on page 240
If set to true,
enables this device to conduct emergency calls.
enable-agentlogin-presence
Default Value:
false
Valid Values: true false
This value must be used in deployments where agent desktops are not used and all information about agent states is determined by presence subscription. In this environment, SIP Server controls the agent state based on SIP-level information.
EventAgentLogin
and
EventAgentReady
messages are generated if an endpoint registers with
SIP Server using the
REGISTER
request, or if the endpoint submits the
PUBLISH
request with the presence content indicating an open
status. If the endpoint terminates the SIP registration or submits the
PUBLISH request indicating a closed
status, then SIP Server generates
EventAgentLogout.
All TEvents are generated on behalf of the agent with the Agent ID set to the same value as the DN name for which all
SIP messages are received.
This functionality is disabled.
Changes Take Effect: After endpoint re-registers
Enables an agent login using presence notification. See “Presence from
Switches and Endpoints” on page 336
for more information.
Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
Note:
You must enable the subscribe-presence
option before enabling this option.
enable-agentlogin-subscribe
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Enables SIP Server control over the state of an agent based on SIP messages that are received from the agent endpoint. SIP Server can log in or log out an agent in response to SIP
SUBSCRIBE
requests; it can also change the availability state for an agent in response to
NOTIFY
requests. To enable this functionality, set this option to true
. To disable the functionality, set this option to false
.
You must enable this option for any endpoint that supports ACD agent log in and log out, in deployments where Genesys Desktop is not used. When enabled, SIP Server generates
EventAgentLogin
and
EventAgentReady
messages in response to
SUBSCRIBE
requests from the endpoint after agent authentication.
If the endpoint terminates the subscription, SIP Server generates an
EventAgentLogout
message. SIP Server generates
EventAgentReady
messages in response to
NOTIFY
requests that have an open presence state, and
EventAgentNotReady
messages in response to
NOTIFY
requests that have a closed presence state.
If the agent state changed as a result of
TAgentReady
or
TAgentNotReady message, SIP Server notifies the agent endpoint by sending a
NOTIFY
request to update the agent status on the IP phone. All TEvents are generated on behalf of the agent with the Agent Login ID taken from the
Request-URI
in the
SUBSCRIBE request. The phone may prompt for both User ID and password. The User ID must correspond to the actual
Agent Login object configured in Configuration
Manager. The password is optional and can be left empty (user enters an empty password at the prompt). If a password is required, enter the password in the
Enter Password
field on the
Advanced
tab of the
Agent Login
object. This password must be used during the login.
enable-extension-headers
Default Values: predictive,routing
Valid Values: See value descriptions below
Changes Take Effect: At the next established call
Controls which SIP headers, specified as a value in
SIP_HEADERS
of
AttributeExtensions
in
TRouteCall
and/or
TMakePredictiveCall
requests, are blocked or mapped from these T-Library requests into an outgoing
INVITE
or
REFER
request, as follows:
•
predictive,routing
—Enables mapping of SIP headers from both
TRouteCall
and
TMakePredictiveCall
requests (the default behavior);
•
none
—Blocks mapping of SIP headers from both
TRouteCall
and
TMakePredictiveCall
requests;
SIP Server—Deployment Guide 569
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
•
predictive
—Enables mapping of SIP headers from TMakePredictiveCall requests only;
•
routing
—Enables mapping of SIP headers from
TRouteCall
requests only.
For example:
If the enable-extension-headers
option is set to routing
on a
Trunk
DN and the
TMakePredictiveCall
request contains the following values in
SIP_HEADERS
of
AttributeExtensions
:
AttributeExtensions
‘HEADER1’ ‘data1’
‘HEADER2’ ‘data2’
‘HEADER3’ ‘data3’
‘SIP_HEADERS’ ‘HEADER1,HEADER2,HEADER3’
Then SIP Server will block custom SIP headers
HEADER1
,
HEADER2
,
HEADER3 when generating an outgoing
INVITE
or
REFER
request to an external gateway.
In Out Of Signaling Path (OOSP) scenarios where the call goes through several Trunk devices, in order for SIP Server to control (or filter) the mapping of custom SIP headers from
TRouteCall
and/or
TMakePredictiveCall
requests to an outgoing
REFER
request, the enable-extension-headers
configuration option should be specified on the referred-by Trunk device.
enable-ims
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Specifies how SIP Server will handle
REGISTER
requests and populate SIP headers for this DN.
•
false
—For non-IMS endpoints (local to SIP Server) that are registered to
SIP Server. SIP Server will not include IMS-related headers in SIP messages sent to these DNs.
•
true
—For IMS endpoints registered to the IMS-CN (using
REGISTER requests through the third-party IMS registration). SIP Server communicates with these DNs through the S-CSCF, and adds IMS-specific headers to all SIP messages.
Note:
For IMS environments, this option must be set to true
for all IMS endpoints, as well as for the
Trunk
DN used for routing to IMS. You cannot disable this option on a per-DN basis if already enabled at the
Application-level.
570 Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
enable-direct-pickup
Default Value: true
Valid Values: true, false
Changes Take Effect: Immediately
Related Feature: “Call Pickup” on page 125
Specifies whether a direct call pickup feature is enabled for this DN.
enable-oosp-alarm
Default Value: true
Valid Values: true, false
Changes Take Effect: Immediately
Related Feature: “Using SIP Feature Server Dial Plan” on page 229
When set to true,
SIP Server generates alarms 52035 and 52056. When set to false
, SIP Server does not generate alarms 52035 and 52056.
enforce-privacy
Default Value: An empty string
Valid Values: id
Changes Take Effect: At the next call
Related Feature: “Network Asserted Identity” on page 303
Enforces privacy for an outbound
Trunk
DN or a destination DN of type
Extension, ACD Position,
or
Voice over IP Service.
When configured, this option provides the
Privacy
header value that SIP Server includes in
INVITE requests. In addition, SIP Server replaces the
From
part of the URI with anonymous content. The
P-Asserted-Identity
header will only be included if the enforce-p-asserted-identity
option is configured on the destination DN and only on a trusted destination.
enforce-p-asserted-identity
Default Value: An empty string
Valid Values: A string
Changes Take Effect: At the next call
Related Feature: “Network Asserted Identity” on page 303
Specifies the preferred SIP URI or the phone number that SIP Server inserts in the
P-Asserted-Identity
header of
INVITE
messages to the trusted destination or intrusted destination when privacy is not requested. This option can be configured on an outbound
Trunk
DN or a destination DN of type
Extension,
ACD Position,
or
Voice over IP Service.
If this option configured on the destination DN, it takes precedence over the value of the p-asserted-identity option configured on the origination DN, or it takes precedence over the value included with the origination
INVITE
request.
SIP Server—Deployment Guide 571
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
enforce-rfc3455
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
If set to true,
SIP Server does not propagate the
P-Called-Party-ID
header in outgoing
INVITE
messages in SIP environments where RFC 3455 is strictly enforced. If set to false,
SIP Server propagates the
P-Called-Party-ID
header in outgoing
INVITE
messages.
enforce-trusted
Default Value: Default is applied at the Application-level
Valid Values: true, false
Changes Take Effect: For the next call
Related Feature: “Network Asserted Identity” on page 303
Specifies whether a particular DN is considered as a “trusted” entity when handling the presentation of private information in the Network Asserted
Identity feature. If set to true
on a particular DN, SIP Server considers the DN trusted, and includes the
P-Asserted-Identity
header for the Contact associated with this DN. If set to false
, SIP Server considers the DN nontrusted and removes the
P-Asserted-Identity
header.
This option is also used to enable SIP Server to pass following private headers:
•
P-Early-Media
—See “Early Media Private Header” on page 208
.
•
P-Access-Network-Info
—See “P-Access-Network-Info Private Header” on page 330
.
Note:
This option can also be configured on the Application-level, for backwards compatibility with IMS deployments (where all entities are trusted by default).
force-register
Default Value:
NULL
Valid Values: Any SIP endpoint address
Changes Take Effect: Immediately
Enables trunk registration and used as the
From
header in the
REGISTER
request.
force-register-disable-totag
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Specifies whether SIP Server will suppress the
To-Tag
in the second
REGISTER message sent by SIP Server. If set to true,
SIP Server does not add the
To-Tag to the
REGISTER
messages it sends.
572 Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
fwd-privilege-level
Default Value: No default value
Valid Values:
X, Y, Z...
(each value must be a minimum of
1
, maximum of
10
)
Changes Take Effect: For the next call
Related Features: “Dial Plan” on page 210
Related Option:
Specifies a list of privileges assigned to a Class of Service DN. This option works similarly to the privilege-leve l option, except it is applied specifically to call forwarding operations. If you do not define this option for call forwarding, then the privilege-level option is used for all call models
(including call forwarding) instead.
The fwd-privilege-level
option applies to the following operations:
•
TSingleStepTransfer
•
TSingleStepConference
•
TRedirectCall
•
1pcc
302 (Moved Temporarily)
received from endpoint
•
1pcc
SingleStepTransfer
•
TCompleteTransfer
,
TCompleteConference
. In this case, the matching is applied at the endpoint where the transfer is completed. At least one of the calls must have been initiated by a user with this COS to the privilege number for this to be applicable.
geo-location
Default Value: No default value
Valid Value: Any alphanumeric string
Changes Take Effect: For the next call
Related Feature: “Working with Multiple Devices” on page 394
Specifies the geo-location
value for the DN that represents a particular SIP device or service. SIP Server includes the geo-location
attribute in the algorithm that it uses to select a particular service when multiple services are available. After narrowing the pool of currently available resources, SIP Server then matches the geo-location
value assigned for the call to the geo-location option configured on the DN. If more than one match is found, SIP Server can
further narrow the selection by considering the value of the priority
option (if it is configured).
Notes:
• For gateway
Trunk
DN selection, you must set
to true
to include the geo-location
option in the selection procedure.
• Virtual resources such as Routing Points or ACD Queues must not use this option.
SIP Server—Deployment Guide 573
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
Table 108 describes the possible DNs that can use this option:
Table 108: DN Configuration Objects
Device Type
Agent SIP endpoint
Media Gateway
Media Server
Music-on-hold or Music-inqueue server (such as Stream
Manager)
Voice Treatment Server (such as Stream Manager)
Voice Recorder (such as
Stream Manager)
Multipoint Conference Unit
(such as Stream Manager)
Genesys DN Type
Extension
Trunk
VoIP Service
with service-type=msml
VoIP Service
with service-type=music
VoIP Service
with service-type=treatment
VoIP Service
with service-type=recorder
VoIP Service
with service-type=mcu
greeting-call-type-filter
Default Value: No default value
Valid Values: none, internal, consult, outbound
Changes Take Effect: Immediately
Related Feature: “Personal Greetings” on page 330
Specifies—using a space-, comma-, or semicolon-separated list—the types of calls to which a greeting will not be played. By default (the option has no value), a greeting will be played to all calls (for 8.0.2 backward compatibility).
If the option is set to internal, consult,
and/or outbound
, a greeting will not be played to internal, consultation, and/or outbound calls, respectively.
If the option is set to none,
the greeting is played to the agent regardless of call type. The keyword none
cannot be used with other values or delimiters.
Note:
If this option is incorrectly configured at the Agent-Login level, SIP
Server disregards this option setting, using the Application-level option setting instead (if it is configured).
574 Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
hg-busy-timeout
Default Value:
0
Valid Values:
0
–
600
Changes Take Effect: For the next call
Related Feature: “Hunt Groups” on page 260
Specifies the period of time, in seconds, SIP Server waits before attempting to deliver a call to a destination that previously rejected the call distributed from this Hunt Group.
hg-members
Default Value: No default value
Valid Values: A string
Changes Take Effect: For the next call
Related Feature: “Hunt Groups” on page 260
Specifies a comma-separated list of DNs that comprise a particular Hunt
Group. This list may contain internal DNs (Extensions or ACD Positions).
hg-noanswer-timeout
Default Value:
0
Valid Values:
0
–
600
Changes Take Effect: For the next call
Related Feature: “Hunt Groups” on page 260
For a parallel call distribution, this option specifies a period of time, in seconds, an unanswered call remains in a Hunt Group before SIP Server either redirects the call to the default-dn
destination (if configured) or rejects it.
For a sequential call distribution, this option specifies a period of time, in seconds, that SIP Server allows for a Hunt Group member to answer a call before SIP Server redirects the call to another available Hunt Group member.
If the call is not answered, SIP Server either redirects the call to the default-dn destination (if configured) or rejects it.
If set to
0
, the call remains in ringing state until answered by the destination or dropped by the caller.
hg-preferred-site
Default Value: No default value
Valid Values: Any string value
Changes Take Effect: For next call distribution
Related Feature: See “Hunt Groups in Business Continuity” in the
SIP Server
8.1 High-Availability Deployment Guide.
Specifies the name of the SIP Server DR Peer application corresponding to the preferred Hunt Group site. If not set or set to an invalid application name, the preferred Hunt Group site cannot be determined, and inbound Hunt Group calls are processed at the site where they are received.
SIP Server—Deployment Guide 575
Chapter 7: SIP Server Configuration Options
576
Agent Login–Level and DN-Level Options
hg-queue-limit
Default Value:
0
Valid Values:
0
–
20
Changes Take Effect: For the next call
Related Feature: “Hunt Groups” on page 260
Specifies the maximum number of calls that can be queued at the Hunt Group.
When the limit is reached, a new call is either redirected to the default-dn destination (if configured) or rejected.
If set to
0
, the number of calls in the queue is unlimited.
hg-queue-timeout
Default Value:
30
Valid Values:
0
–
6000
Changes Take Effect: For the next call
Related Feature: “Hunt Groups” on page 260
Specifies the period of time, in seconds, that a call is queued on the Hunt
Group waiting for processing. When the time period is reached, the call is either redirected to the default-dn
destination (if configured) or rejected. If set to
0
, the call remains in the queue until all previous call processing is finished, or the call is dropped by the caller.
hg-type
Default Value: No default value
Valid Values: fork, linear, circular
Changes Take Effect: For next call distribution
Related Feature: “Hunt Groups” on page 260
Specifies the type of Hunt Group algorithm that is used to deliver calls to Hunt
Group members, as follows:
•
fork
–Parallel distribution strategy (forking)
•
linear
–Sequential distribution strategy, linear hunting
•
circular
–Sequential distribution strategy, circular hunting
ignore-presence-after-nas
Default Value: true
Valid Values: true, false
Changes Take Effect: At the next call
Specifies whether SIP Server processes or ignores presence SIP messages to change an agent state to
Ready if the no-answer action is set to notready
for an agent.
If set to true,
SIP Server ignores presence SIP messages.
If set to false,
SIP Server processes presence SIP messages.
Note:
You can define this option at both the Application and the DN levels.
The DN-level option takes precedence.
Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
include-dial-plan-<n>
Default Value: No default value
Valid Values: Any string that matches the name of another dial-plan
Voice over
IP Service
DN
Changes Take Effect: For the next call
Related Feature: “Dial Plan” on page 210
SIP Server will consider the dial-plan rules specified in this option. This option allows hierarchies of dial-plans to be created, if required.
Note:
SIP Server selects the dial-plan rule based purely on the number of specific digits matched. No preference is given to any rules in this dial-plan, or in the included dial-plan.
info-pass-through
Default Value: No default value
Valid Values:
*
Allows all
INFO
messages to be sent to the peer connection.
<list>
*,<list>
Allows only those
INFO
messages specified in a comma-separated list of
Content-Type
values (used to define
INFO
messages) to be sent to the peer connection.
Allows all
INFO
messages to be sent to the peer connection, except those included in a comma-separated list of
Content-Type
values.
Changes Take Effect: For the next call
Specifies which SIP
INFO
messages SIP Server will pass to a remote device.
You can use this option to allow all
INFO
messages through to the peer connection to disable all
INFO
messages from being sent to the peer connection, or to specify only those
INFO
messages, as defined by the
Content-Type
header, that SIP Server will allow. By default, this option is left undefined. In this case,
SIP Server passes all
INFO
messages to the peer connection, except for the following:
•
application/vnd.radisys.msml+xml
•
application/x-www-form-urlencoded
•
application/x-detect
(not sent if predictive call is in progress, or if no
AudioCodes CPD result header is found)
•
application/dtmf-relay
(not sent if received from
Voice over IP Service
DNs with service-type
set to any of the following: mcu
, recorder
, moh
, music
, or treatment
.
Note:
This option can also be configured at the Application level. The
DN-level setting takes precedence over the Application-level setting.
SIP Server—Deployment Guide 577
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
line-type
Default Value:
0
Valid Values:
0
,
1
Changes Take Effect: When an agent reconnects (when set to 1)
Specifies the line type for this DN as either a regular line (
0
) or a nailed-up line
(
1
). If set to
1
, when a call to this DN is released due to a 3pcc request
(
TReleaseCall
,
TSingleStepTransfer
, or
TCompleteTransfer
), SIP Server does not end the SIP session with this DN. Instead, SIP Server parks the nailed-up line on the gcti::park device
, where the SIP session is maintained and the DN is able to make 3pcc calls or receive new calls. This behavior is typically required for TDM DNs behind a media gateway, where the agent requires a dedicated connection to the contact center for the duration of a work session.
Note:
Nailed-up DNs must not be configured with the
option ( talk
, hold
). This option applies to SIP endpoints only (nailedup lines are typically TDM lines behind the media gateway).
In addition, for each nailed-up DN you must also configure the following options:
•
Set
to false
.
•
Set
to false
.
•
Set
true
(recommended, not mandatory)
make-call-rfc3725-flow
Default Value:
2
Valid Values:
1, 2
Changes Take Effect: Immediately
Controls which SIP call flow to choose when a call is initiated by a
TMakeCall request. The specified value is equal to the call flow number as described in
RFC 3725. Only flow 1 and flow 2 from RFC 3725 are currently supported.
Note:
This option is enabled only if the option refer-enabled
is set to false for that DN.
music-on-hold
Default Value: An empty string
Valid Values: The path and name of the audio file
Changes Take Effect: For the next call
Related Feature: “Playing Music to Calls on Hold” on page 194
Specifies the name of the file that is played for the music-on-hold treatment when one of the parties in the call is placed on hold. The option is configured on a Routing Point DN and applies to calls that are passed through this Routing
Point, unless a call is distributed with the
TRouteCall
request that contains the music-on-hold
key in
AttributeExtensions
.
578 Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
no-answer-action
Default Value: none
Valid Values: none notready logout
SIP Server takes no action on agents when business calls are not answered.
SIP Server sets agents to
NotReady
when business calls are not answered.
SIP Server automatically logs out agents when business calls are not answered.
Changes Take Effect: Immediately
Related Feature: “No-Answer Supervision” on page 313
Determines the action taken if the agent receives a SIP Server business call but fails to answer the call within the time defined in option
This option is defined on any
Agent Login object. When set, the value overrides the Application-level agent-no-answer-action
SIP Server configuration option for that agent.
Note:
If a call is abandoned before either the no-answer-timeout
option expires (depending on which timer is applicable), SIP
Server performs no action on this agent.
no-answer-overflow
Default Value: none
Valid Values: none recall
SIP Server does not attempt to overflow a call on an agent desktop when no-answer-timeout
expires.
SIP Server returns the call to the last distribution device (the device reported in the
ThisQueue
attribute of the call) when noanswer-timeout
expires.
SIP Server releases the call.
release default
Any valid overflow
SIP Server stops execution of the current overflow sequence and continues with the SIP Server default overflow sequence, as defined by the relevant overflow option at the Application level.
SIP Server returns the call to the specified destination when the value set for the
no-answer-timeout destination
Changes Take Effect: Immediately option expires.
Related Feature: “No-Answer Supervision” on page 313
Defines a sequence of overflow destinations (separated by comma) in the order listed:
1. When the first overflow destination fails, SIP Server attempts the next one in the list.
SIP Server—Deployment Guide 579
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
2. When all overflow destinations in the list fail, SIP Server abandons overflow. When the list of overflow destinations contains the value recall and the call is not distributed, SIP Server skips to the next destination in the list.
This option is defined in the
Switches
folder on any of the following objects:
•
Agent Login
•
DN
of type
Extension
•
DN
of type
ACD Position
When set, this option overrides any of the following SIP Server configuration options for the object where it has been set (depending on the configuration object type):
•
no-answer-overflow if defined for an
Agent Login
object.
•
no-answer-overflow
if defined for a
DN
of type
Extension
object.
•
no-answer-overflow if defined for a
DN
of type
ACD Position object.
no-answer-timeout
Default Value: Same value as corresponding global option
Valid Value: Any integer from
0
–
600
Changes Take Effect: Immediately
Related Feature: “No-Answer Supervision” on page 313
Defines the time (in seconds) SIP Server waits for a call that is ringing on a device in question to be answered.
When the timer expires, SIP Server applies the appropriate overflow, and, in the case of agents, the appropriate
Logout
or
Not Ready action.
This option is defined in the
Switches
folder on any of the following objects:
•
DN
of type
Extension
•
DN
of type
ACD Position
•
Agent Login
object
If set to
0,
the NoAnswer Supervision feature for this device is disabled. When set, this option overrides any of the following SIP Server configuration options for the object where it has been set (depending on the configuration object type):
•
no-answer-timeout
if defined for an
Agent Login object.
•
no-answer-timeout
if defined for a
DN
of type
Extension
object.
•
no-answer-timeout
if defined for a
DN
of type
ACD Position
object.
no-response-dn
Default Value: No default value
Valid Values: Any valid DN
Changes Take Effect: Immediately
Related Option: “sip-invite-timeout” on page 523
580 Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
Specifies the DN to which a call will be sent when the SIP endpoint fails to respond to the incoming
INVITE
message during the creation of a new call. You can configure this option only for DNs of type
Extension
or
ACD Position
.
ocs-dn
Default Value: No default value
Valid Values: A valid OCS 2007 DN name
Changes Take Effect: Immediately
Related Feature: “Presence Integration with Microsoft Office Communications
Specifies the Microsoft OCS 2007 user to be associated with the DN configured with this option. Required for presence monitoring of OCS users on
PSTN phones (and no Genesys client on which to log in) to map user status in the IM client to a Genesys agent state. For example, an online
status in
Microsoft Communicator maps to the Genesys agent state
Ready
.
oos-check
Default Value:
0
Valid Values:
0
–
300
Changes Take Effect: Immediately
Related Feature: “Active Out-of-Service Detection” on page 254
Traffic Monitoring” on page 363
Specifies how often (in seconds) SIP Server checks a device for out-of-service
status. This option can be used in conjunction with the oos-force
and
options, as follows:
•
When no response is received, and the
oos-force
option is configured, SIP
Server will mark a device as out of service when the oos-force
timeout expires.
•
When the recovery-timeout
option setting is less than the oos-check timeout, SIP Server will wait the amount of time specified as the recovery-timeout
value before checking the DN that was previously detected as out of service.
•
When the oos-check
option is set to
0,
the feature is disabled.
Note:
The oos-check option is only supported on the following DN types:
•
Voice over IP Service
•
Trunk
•
Trunk Group
The oos-check
option is not applicable to internal DNs (DNs of type
Extension
or
ACD Position
).
SIP Server—Deployment Guide 581
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
oos-error-check
Default Value: false
Valid Value: true, false
Changes Take Effect: Immediately
Related Feature: “Active Out-of-Service Detection” on page 254
Checks the response message received for the
OPTIONS
message sent by SIP
Server. If set to true,
if SIP Server receives any SIP error response (for example,
480 Temporarily Unavailable
or
503 Service Unavailable
) for the
OPTIONS
message, it places the DN in the out-of-service state. If set to false, then, if SIP Server receives an error response for the
OPTIONS
message, it leaves the DN in the in-service state.
Note:
This option must be used together with the
oos-check
option.
oos-force
Default Value:
0
Valid Values:
0
–
30
Changes Take Effect: Immediately
Related Feature: “Active Out-of-Service Detection” on page 254
Traffic Monitoring” on page 363
Specifies when SIP Server places a non-responding device into out-of-service
option is enabled, as follows:
•
When this option is set to 0 (the default), SIP Server waits 32 seconds before placing the device into out-of-service state.
•
When this option is set to a non-zero value, SIP Server waits that number of seconds before device into out-of-service state.
oos-options-max-forwards
Default Value:
0
Valid Values: Any positive integer from
0
to
70
Changes Take Effect: Next transaction
Related Feature: “Active Out-of-Service Detection” on page 254
Specifies the value to be used in the
Max-Forwards header of the
OPTIONS requests used for Active Out-of-Service Detection. A value greater than
0 allows a proxy device to forward the
OPTIONS
message to the monitored SIP device (for example, an
Extension
on a third-party switch).
582 Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
oosp-transfer-enabled
Default Value: false
Valid Values: true, false
Changes Take Effect: For the next call
If set to true,
SIP Server puts itself in the Out Of Signaling Path (OOSP) after the single-step transfer or routing to the external destination has been completed.
Notes:
• This option is configured for
Trunk
DNs only, and the caller DN or the
Trunk
DN must support the
REFER
method.
• To ensure that the
REFER
method for this
Trunk
DN is used only for
OOSP (single-step transfer) scenarios, set the
option on this Trunk to false
.
• For a detailed description about how refer-enabled
and oosptransfer-enabled
affect the SIP transfer methods, see “Controlling
Transfer Methods to External Destinations” on page 170 .
out-rule-<n>
Default Value: No default value
Valid Value: Any valid string in the following format: in-pattern=<input pattern value>;out-pattern=<output pattern value>
Changes Take Effect: Immediately
Related Feature: “Class of Service” on page 179
Defines a rule to be applied to an inbound number. The two parts of the option value describe the input and output patterns in the rule. When configuring the
pattern values, follow the syntax defined in “Dialing Rule Format” on page 180
. See “Examples” on page 184 for examples of these rules, as well as
detailed instructions for creating rules for your installation. For example, a value for this configuration option might look like this: out-rule-01 = in-pattern=0111#CABBB*ccD;out-patterned
override-call-type
Default Value:
0
Valid Values:
0 CallTypeUnknown
1 CallTypeInternal
2 CallTypeInbound
3 CallTypeOutbound
Changes Take Effect: For the next call
Determines the value SIP Server will use as the
CallType
attribute for internal calls made directly to a DN of type
Routing Point
. If set to
0,
SIP Server specifies the
CallType
attribute as
Internal
.
SIP Server—Deployment Guide 583
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
override-domain
Default Value:
NULL
Valid Values: Any computer name
Changes Take Effect: For the next call
Enables an override of the specified computer name in the SIP
To:
header for a
DN. It is used to contact a particular DN in a domain in the
To:
header that is different than the SIP Server internal registrar computer name.
Note:
This option must be specified for the DN that represents Microsoft
Office Communicator behind LCS.
In IMS environments, for IMS endpoints configured with enable-ims
set to true
, the value of the override-domain option is used to replace the IP address in the
Request-URI
of all SIP messages. For any IMS-related DN that does not register with SIP Server, this value must match the domain used in that particular IMS deployment.
override-domain-oosp
Default Value: No default value
Valid Values: Valid SIP URL
Changes Take Effect: For the next call
Enables an override of the domain name inside the request URI of the
Refer-To header in the
REFER
method, or the
Contact
header of
302 Moved Temporarily responses. If you leave this option empty, no override takes place. To enable the override, configure this option in the
Trunk
DN that is to be selected as the transfer (routing) destination.
This
Trunk
DN should also include the following configurations:
•
contact
—Set to the SIP URL (IP address or FQDN) of the external destination.
•
refer-enabled
—Set to false
to prevent
REFER
method for transfers to internal destinations.
•
oosp-transfer-enabled
—Set to true
to use
REFER
method for external transfers, where SIP Server leaves the signaling path. The value of this option takes precedence over the option override-domain
on the transferred party Trunk. This option does not play any role in how override-domainoosp
is configured on the transferred party Trunk.
Note:
If the override-domain-oosp
option is not configured for the DN, then the override-domain
option value applies in Out Of Signaling Path
(OOSP) scenarios.
584 Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
override-domain-from
Default Value:
NULL
Valid Values: Any computer name string
Changes Take Effect: For the next call
When set, SIP Server substitutes the computer name in the URI of the
From headers with the value of this option when it sends the initial
INVITE
message to a DN or
Trunk
DN.
override-domain-refer-to
Default Value:
NULL
Valid Values: Any computer name string
Changes Take Effect: For the next call
Related Feature: “Referred-By Header Support” on page 177
This option must be configured on a DN associated with the transferred/routed party where
REFER
is sent. If set, SIP Server substitutes the “hostport” component of the SIP URI passed in the
Refer-To
header of the outgoing
REFER request with the value of this option. Applies only if
is set to true.
override-domain-referred-by
Default Value:
NULL
Valid Values: Any computer name string
Changes Take Effect: For the next call
Related Feature: “Referred-By Header Support” on page 177
This option must be configured on a DN associated with the transferred/routed party where
REFER
is sent to. If set, SIP Server substitutes the “hostport” component of the SIP URI passed in the
Referred-By
header of the outgoing
REFER
request with the value of this option. Applies only if sip-referred-bysupport
is set to true.
override-from-on-conf
Default Value: false
Valid Values: true false
The username is equal to the conference initiator DN.
The username is equal to the conf=conf-id
or msml=conf-id number.
Changes Take Effect: Immediately
Controls the username part of the
From header URI for outgoing
INVITE messages to the new party DN added in the single-step conference.
If set to true,
SIP Server takes the value of the conference initiator DN as the username part of the
From
header. If set to
false,
SIP Sever takes the value of the conf=conf-id
or
msml=conf-id
for the username part of the
From
header.
This option is set on the new party DN added in the single-step conference.
SIP Server—Deployment Guide 585
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
override-to-on-divert
Default Value: false
Valid Values: true false
The username is equal to the destination DN.
The username is equal to the Routing Point or ACD Queue number.
Changes Take Effect: Immediately
Controls the username part of the
To
header URI for outgoing
INVITE
messages when a call is diverted from a Routing Point or an ACD Queue. This option setting also applies to 1pcc transfers (using the
REFER
method). If set to true
,
SIP Server takes the value of the
REFER
-to DN as the username part of the
To header. If set to false
, SIP Sever takes the value of the
From
DN (originator of the
REFER
message) for the username part of the
To
header.
Note:
This option can also be configured at the Application level. The DNlevel setting takes precedence over the Application-level setting.
p-asserted-identity
Default Value: No default value (empty string)
Valid Values: Any string in accordance with RFC 3325
Changes Take Effect: For the next call
Related Feature: “Network Asserted Identity” on page 303
Related Option: “privacy” on page 589
Specifies the preferred SIP URI or telephone number that SIP Server inserts in the
P-asserted-identity
header of
INVITE
messages, when required according
to the scenarios described in “Network Asserted Identity” on page 303 . If you
configure this option on an
Extension
DN, the value provides the content of the
P-asserted-identity
header for this particular DN.
partition-id
Default Value: SIP Server Default Partition
Valid Values: Any string (the name of one partition)
Changes Take Effect: Immediately
Application-level: Specifies the default partition for the SIP Server application.
DN-level: Specifies the partition to which this DN belongs. If you leave the option undefined, SIP Server considers the DN as belonging to the default partition. You can only define this option on
Trunk
and
Voice over IP Service type DNs.
SIP Server assigns a partition to each call based on the call origination device.
If the call origination device does not have a defined partition-id
parameter, the call is assigned to the default partition. SIP Server uses information about partition-id
in two ways:
1. To select a
Voice over IP Service
DN for a call.
2. To select a
Trunk
DN for the outbound call.
586 Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
If multiple resources (
Voice over IP Service
DNs or
Trunk
DNs) are available for call processing, SIP Server selects one that belongs to a call partition.
password
Default Value: No default value
Valid Values: Any alphanumeric string
Changes Take Effect: Immediately
Related Option: “authenticate-requests” on page 552
In the endpoint configuration: Specifies the password for the SIP endpoint registration with the local registrar. If it is present, registration attempts are challenged and the password is verified. If it is not present, the registration is not challenged. The realm for password authentication is configured globally; there is one realm per SIP Server. The authentication procedure can also be applied to
INVITE
requests, depending on the value of the authenticaterequests
option.
Note:
Both password and
must be configured for the authorization process to take place.
In the gateway configuration: Contains the password for gateway registration with the local registrar. This is used for incoming
REGISTER
requests, not for outgoing
INVITE
requests.
peer-proxy-contact
Default Value: No default value
Valid Values: A valid address
Changes Take Effect: Immediately
Specifies the address of the SIP Proxy pool that serves the remote SIP Server.
The value must be the same as the value of the external-contact
option of the sip-outbound-proxy
DN at the remote switch.
This option must be set on a
Trunk
DN that belongs to the remote SIP Server.
Its value is used only when sip-outbound-proxy
is set to true
.
The value of the peer-proxy-contact
option is used to override an FQDN during URI construction in OOSP transfer scenarios, where the transfer destination is the respective remote SIP Server and the transferred party is the external SIP device. If the option value is empty, then the URI is not changed.
This option is mandatory in Business Continuity (BC) deployments with SIP
Proxy on BC peers, and on DNs of type
Trunk
which are pointed to by the respective Application-level
option.
SIP Server—Deployment Guide 587
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
prefix
Default Value: No default value
Valid Values: A string containing any characters allowed in the user part of a
SIP URI (according to RFC 3261)
Changes Take Effect: Immediately
This option can be configured on a Trunk DN or Voice over IP Service DN with the service-type
option set to softswitch, msml,
or mcu
.
When configured on a Trunk DN, the value of this option is used by SIP Server to select the proper Trunk for an outgoing call. For each available Trunk, SIP
Server compares the value of this option with the initial characters of the call’s destination name; the Trunk with the longest possible match is selected.
When configured on a Voice over IP Service DN with service-type=softswitch,
the value of this option is used by SIP Server to select the proper softswitch for an outgoing call. For each available softswitch,
SIP Server compares the value of this option with the initial characters of the call’s destination name; the softswitch with the longest possible match is selected.
When configured on a Voice over IP Service DN with service-type
= msml,
the only supported value is msml=
. It must be configured if the deployment must support conferences.
When configured on a Voice over IP Service DN with service-type=mcu
(when msml-support=false
), the only supported value is conf=.
predictive-timerb-enabled
Default Value: true
Valid Values: true, false
Changes Take Effect: On the next call
Related Feature: “Increasing Ringing Period for Predictive Calls” on page 98
Enables or disables the timer that causes SIP Server to drop the call if an
ACK message is not sent to the Media Server within 32 seconds after the
200 OK
is received.
If set to true
, SIP Server uses the 32-second timer.
If set to false
, SIP Server disables this timer and instead times the call using the
AttributeTimeout
value included in the
TMakePredictiveCall
request. If this timeout expires before the call is answered, or if SIP Server receives a
BYE message from the Media Server, SIP Server terminates the call. Genesys recommends setting the
AttributeTimeout
to a value greater than zero (0) to prevent inadvertent call termination.
588 Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
preview-interaction
Default Value: false
Valid Values: none tlib chat
Disables the protocol.
Enables preview interaction through T-Library messaging.
Enables preview interaction through SIP Instant Messaging (IM).
Changes Take Effect: For the next call
Related Feature: “Preview Interactions” on page 348
Determines if the
Preview Interaction
protocol is enabled when incoming calls are diverted from a Routing Point.
To enable the preview mechanism for IM interactions, set this option to chat.
SIP Server sends a preview IM allowing the IM user to accept or reject the request before SIP Server starts the main IM dialog. If the IM user rejects the request, SIP Server returns the call to the routing point. For details about the
call flow, see “Preview Interaction” on page 266 .
Notes:
• This option works with the preview-expired
options to determine what action to take when a desktop does not respond to a preview interaction before the time expires.
• For backward compatibility, SIP Server also accepts the following valid values for this option:
True
—The protocol is enabled (equivalent to T-Library).
False
—The protocol is disabled (equivalent to none
).
priority
Default Value:
0
Valid Values: Any non-negative integer
Changes Take Effect: Immediately
Specifies the device priority for the device selection algorithm. A smaller value designates a higher priority. SIP Server will choose a device in round-robin fashion across all devices if more than one device with the same priority is configured. This option is used to control the device switchover during a failure and to provide lowest-cost routing.
privacy
Default Value: No default value (string is empty)
Valid Values: Valid Values: id
—as defined in RFC 3325: Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted
Networks
Changes Take Effect: For the next call
Related Feature: “Network Asserted Identity” on page 303
Specifies the level of privacy requested by this DN, as described by the
Network Asserted Identity feature. If set to id,
SIP Server includes the
Privacy:id
header in SIP messaging. If not configured, SIP Server does not include the
Privacy:id header (privacy is not requested by this DN).
SIP Server—Deployment Guide 589
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
private-line
Default Value: No default value
Valid Value: Any valid SIP user name
Changes Take Effect: Immediately
Related Feature: “Presence from Switches and Endpoints” on page 336
Specifies the value of the Private Line User Part ID for the Busy Lamp Field feature. When this option is configured on a particular DN, SIP Server creates an association between the value of this option and the name of the DN. When the softswitch sends a notification regarding the state of the Private Line, SIP
Server maps the User Part ID to the value of the private-line
option on the associated DN, and then issues an
EventAgentReady
/
EventAgentNotReady message for that DN.
privilege-level
Default Value: No default value
Valid Values:
X, Y, Z...
(each value must be a minimum of
1
, maximum of
10
)
Changes Take Effect: For the next call
Related Option:
Related Features: “Dial Plan” on page 210
Specifies a list of integers that define which dial-plan rules are available for outgoing calls made by the caller associated with this Class of Service (COS)
DN.
When a caller with this COS makes a call that matches a dial-plan rule, the privilege of that dial-plan rule must be included here, otherwise SIP Server will block the call. If the dial-plan rule does not define a privilege level (or defines a privilege-level of
0
), then the call is allowed regardless of the privilege levels defined here.
Applicable to the following 3pcc requests:
•
TMakeCall
•
TInitiateTransfer
•
TInitiateConference
•
TSingleStepTransfer
*
•
TSingleStepConference
*
•
TRedirectCall
*
SIP Server will also apply dial-plan logic to 1pcc
INVITE
,
REFER*
, and
302
(moved temporarily)*
operations.
* The fwd-privilege-level
option, if configured, overrides the privilegelevel
setting for these operations.
590 Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
public-contact
Default Value: No default value
Valid Value: Any alphanumeric string
Changes Take Effect: Immediately
Contains the public host:port
pair for a softswitch. This is the public IP address of the softswitch. SIP Server uses this address to fill the destination
(
Refer-To
) address in
REFER
requests. On some switches, this is the same as the contact
address; if this is the case, you do not need to specify this parameter.
record
Default Value: false
Valid Values: true, false
Changes Take Effect: When the next call is established on the DN
If set to true,
call recording begins automatically when the call is established on the DN. Call recording stops when the call is released on the DN.
recovery-timeout
Default Value:
0
Valid Values:
0
–
86400 seconds
Changes Take Effect: Immediately
Related Feature: “Passive Out-of-Service Detection” on page 254
Related Options: sip-oos-enabled on page 608
Controls whether a device is taken out of service when an error is encountered, and if so for how long. If set to
0,
setting the DN to out-of-service due to SIP failure is disabled for DNs of type
Trunk
or
Voice over IP Service
. For DNs of type
Extension
(ACD Position), the zero value does not have any affect.
SIP Server supports this option on the following DN types:
•
Voice over IP Service
•
Trunk
•
Extension
•
ACD Position
•
Voice Treatment Port
SIP Server—Deployment Guide 591
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
Note:
Genesys recommends that you disable the
when using Active Out-of-Service Detection. Recovery-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
option is configured to a value less than the
value, SIP Server will wait the amount of time that
is specified in the recovery-timeout
option before it checks to see if the device is back in service.
For more information about active out-of-service-detection, see
“Active Out-of-Service Detection” on page 254
.
rfc-2976-dtmf
Default Value: false
Valid Values: true, false
Changes Take Effect: For the next call
When this option is set to true
in a particular DN (type of
Trunk
or
Extension
) configuration, SIP Server will send DTMF tones in the RFC 2976 format to that device using the
INFO
request method when an agent issues a
TSendDTMF request.
Note:
If a
TSendDTMF
request contains a string with multiple digits (for example,
12345#
), SIP Server issues multiple
INFO
requests (one per digit).
If a
TSendDTMF
request contains a string with multiple digits, and there are unsupported DTMF tones in this string (for example,
123a67
), SIP
Server still attempts to send the
INFO
request for each digit contained in the string, ignoring possible error responses from a gateway, and continuing to send subsequent digits.
refer-enabled
Default Value: true
Valid Values:
true, false
Changes Take Effect: With the next new call on this DN
Specifies whether the
REFER
method is sent to an endpoint. If set to
true, the
REFER
method is sent to:
•
The call party that originates a
TMakeCall
request.
•
The call party that initiates a consultation call.
•
The call party that is transferred to another destination during a single-step transfer.
If set to false,
SIP Server uses the re-
INVITE
method instead.
592 Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
For IMS deployments: When integrated with an IMS environment, you must set this option to false
on all IMS-enabled DNs.
Notes:
To control the SIP messaging (
REFER
or re-
INVITE
) that SIP Server uses to initiate transfers or routing to an external DN, configure the outbound
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
.
For a table describing how these two options control the SIP methods
used, see “Controlling Transfer Methods to External Destinations” on page 170 .
reinvite-requires-hold
Default Value: false
Valid Values: true, false
Changes Take Effect: For the next call
If set to true,
this option instructs SIP Server to always precede a re-
INVITE request to an endpoint with a special re-
INVITE
containing hold SDP and
0 audio port.
Note:
This option must be enabled (set to true
) only for Microsoft RTCbased devices. In this case, the option prevents an audio delay during
3pcc (third-party call control) conferencing with the RTC-based endpoint.
In all other cases, consult Genesys Customer Care for recommendations about enabling this option.
reject-call-incall
Default Value: false
Valid Values: true, false
Changes Take Effect: For the next call
If set to true,
SIP Server rejects a call attempt to a DN that is already on a call, and generates an
EventError
message with the reason code
Destination
Invalid State (93)
. When rejecting 1pcc calls, SIP Server generates a SIP
603
Decline
error response.
reject-call-notready
Default Value: false
Valid Values: true, false
Changes Take Effect: For the next call
If set to true,
SIP Server rejects a call attempt to a DN at which an agent is in a
Logout
,
NotReady, or
AfterCallWork
state; and generates an
EventError
SIP Server—Deployment Guide 593
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options message with the reason code
Destination Invalid State (93)
. When rejecting 1pcc calls, SIP Server generates a SIP
603 Decline
error response.
Note:
The reject-call-incall
and reject-call-notready
options must be configured on destination DNs and not on origination DNs. These options are applicable to the following T-Library requests:
•
TMakeCall
•
TInitiateTransfer
•
TInitiateConference
•
TSingleStepTransfer
•
TSingleStepConference
replace-prefix
Default Value: No default value
Valid Values: A string containing any characters allowed in the user part of a
SIP URI (according to RFC 3261), or empty
Changes Take Effect: Immediately
This option can be configured on a Trunk DN or Voice over IP Service DN with the service-type
option set to softswitch
, under a condition that the option
is also configured on these DNs.
When a device with both prefix
and replace-prefix
options is selected to conduct the call, initial characters of the call’s destination name that match the prefix will be substituted with the value of replace-prefix
. If this option contains an empty value, the call’s destination name will be stripped of initial characters matching the value of the prefix.
replace-uri-contact
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Related Feature: “DNS Name Resolution” on page 232
Specifies whether SIP Server replaces the IP address and port in the SIP URI with the address and port of the active destination, as determined by resolving the contact or contacts-backup option to DNS records, using Active Out-of-
Service Detection that factors in DNS priority and weight values.
request-uri
Default Value: No default value
Valid Values: Any SIP URI
Changes Take Effect: Immediately
Specifies the value of the
Request-URI
address inside the
INVITE
message that is different from the address to which the message will be sent—for example, if a service that is provided by a particular application/server requires a different URI from the Contact URI for that application/server.
594 Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
In a video support configuration, this option creates a template for specifying the source of the video stream as the value of the
Request-URI
parameter in the
INVITE
message: annc@<stream_manager_hostport>;play=<file>
Note:
For moh
, treatment
, or mcu
services provided by Genesys Stream
Manager, do not configure the request-uri
option. Configuring this option can improperly override media-related options in the SIP
Server Application. Specifically, if the play parameter in the
Request-
URI
from a
Voice over IP Service
DN with a service-type of moh contains a value, this value overrides the
option as specified in the SIP Server Application.
resolve-external-contact
Default Value: false
Valid Values: true, false
Changes Take Effect: For the next call
Specifies whether SIP Server resolves the contact as external if the internal resolution has failed. The value will be taken from the trunk which was the source of the OOSP-causing message, which is the trunk to the transfer initiator party.
This option affects only processing of the OOSP (Out Of Signaling Path) transfer SIP operations, specifically
REFER
requests or
302
responses. It applies only to DNs of type
Trunk.
SIP Server tries to find the destination device using the URI in the OOSP message, as follows:
•
Resolving the user part—SIP Server searches among locally configured and registered DNs and tries to match trunk prefixes.
•
If no matching DNs are found and if the resolve-external-contact
option is set to true,
SIP Server tries to find the destination trunk by matching the domain part and transport protocol of the received URI with the contact of the configured
Trunk
DNs.
Note:
This option can also be configured at the Application level. The
DN-level setting takes precedence over the Application-level setting.
reuse-sdp-on-reinvite
Default Value: false
Valid Values: true, false
Changes Take Effect: For the next call
When a call is routed to an endpoint, and this option is set to true in the destination endpoint configuration, SIP Server generates an offer by sending a re-
INVITE
message to the origination party (or to the MCU). When the origination party answers the offer, SIP Server sends the
INVITE
message with
SDP information to the destination.
SIP Server—Deployment Guide 595
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
This option was introduced to handle obsolete devices that do not work properly with empty
INVITE
requests.
Notes:
• The value must be set to true
when using EyeBeam version 1.1.
• If one of the DNs has this option set to true
and the other DN has this option set to false,
or not configured, SIP Server will not start renegotiating with the DN that has the option value set to true
.
Therefore, the empty
INVITE
will never be sent to that DN. If both
DNs have this option set to true,
one of the DNs will receive an empty
INVITE
.
SIP Server sends a re-
INVITE
for SDP re-negotiation first to the device configured with reuse-sdp-on-reinvite=false
(or if the option is not configured).
ring-tone-on-make-call
Default Value: true
Valid Values: true, false
Changes Take Effect: Immediately
Affects the
TMakeCall
request when using the re-
INVITE
procedure.
If set to true,
SIP Server connects the caller with an audio ringtone from
Stream Manager when the destination endpoint responds with a
180 Ringing message. In addition, the following options must also be configured for these scenarios:
•
The calling DN initiates a
TMakeCall
request must be configured with the following options:
false
1
•
The calling DN initiates a consultation call must be configured with the following option:
false
When the ring-tone-on-make-call
option is set to false,
there is no ringtone.
Notes:
• SIP Server does not support internal ringtones in conference scenarios where the sip-ring-tone-mod e option is set to
1
. In this case, SIP Server provides a ringtone only if the endpoint returns an
SDP in the provisional message.
• SIP Server plays internal ringtones based on the
ring-tone-onmake-call
configuration option when the sip-ring-tone-mode option is set to
0
.
596 Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
sca-preferred-site
Default Value: No default value
Valid Values: Any string value
Changes Take Effect: For the next call
Related Feature: See “Shared Call Appearance in Business Continuity” in the
SIP Server 8.1 High-Availability Deployment Guide.
Specifies the name of the SIP Server DR Peer application corresponding to the preferred SCA site. If not set or set to an invalid application name, the preferred SCA site cannot be determined, and inbound SCA calls are processed at the site where they are received. The option can be configured only for the
Primary shared line DN, where the shared-line
option is set to true
.
service-type
Default Value: No default value
Valid Values: Any string
Changes Take Effect: Immediately
Specifies the configured SIP device type or service (see
Chapter 4, “SIP Devices Support,” on page 73 for more information on using
this option. For more information about configuring a Class of Service DN, see
“Class of Service” on page 179 . For more information about configuring a
dial-plan DN, see “Dial Plan” on page 210
.
Table 109: Service-Type Settings for SIP Devices
SIP Device Type or
Service
Conference Server/MCU
Softswitch
Music-on-Hold servers
Treatment service
Recording service
Application service
Class of service
Dial plan
Genesys DN Type
Voice over IP Service
Voice over IP Service
Voice over IP Service
Voice over IP Service
Voice over IP Service
Voice over IP Service
Voice over IP Service
Voice over IP Service
Service-Type
Setting
mcu softswitch music or moh treatment recorder application cos dial-plan
SIP Server—Deployment Guide 597
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
session-refresh-enforced
Default Value: true
Valid Values: true, false
Changes Take Effect: Immediately
Controls whether SIP Server activates the SIP Session timer within a SIP dialog. If set to false
, SIP Server activates the SIP Session timer only if both an initial
INVITE
and
200 OK
response to that
INVITE
contains the
Session-
Expires
header. If set to true
, SIP Server, while activating that timer, ignores the absence of the
Session-Expires
header in the response and starts the timer based on the header presence in the request. If an endpoint does not support the session refresh mechanism, set this option to false.
The option has an affect only when the
option is set to a non-zero value.
You can define this option at both the Application and the DN level. The DNlevel setting takes precedence over the Application-level setting.
shared-line
Default Value: false
Valid Values: true, false
Changes Take Effect: For the next call
Related Feature: “Shared Call Appearance” on page 365
Indicates if this DN is used as a Primary shared line number.
shared-line-capacity
Default Value:
2147483646
Valid Values: Integer in the range
1-2147483646
Changes Take Effect: For the next call
Related Feature: “Shared Call Appearance” on page 365
Specifies the maximum number of line appearances (or simultaneous calls) for a Primary shared line DN. These calls are distributed among shared line users and one user can handle only one call at a time. This option can be configured only for a Primary shared line DN ( shared-line=true
). The default value means that the number of simultaneous calls is (almost) unlimited.
shared-line-number
Default Value: No default value
Valid Values: Primary shared line DN
Changes Take Effect: For the next call
Related Feature: “Shared Call Appearance” on page 365
Specifies the Primary shared line DN to be used by the Secondary shared line
DN to receive incoming calls and make outgoing calls.
598 Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
sip-accept-body
Default Value: An empty string
Valid Values: cid
or empty
Changes Take Effect: For the next call
Related Feature: “Caller Information Delivery Content for AT&T Trunks” on page 122
Specifies content types that SIP Server retrieves from the incoming
INVITE with a multipart body received from an origination DN.
•
If set to an empty string (default), SIP Server ignores the multipart body of an
INVITE
.
•
If set to cid,
SIP Server extracts the CID body from the
INVITE
and stores it as the caller's property.
This option:
•
...does not affect SDP.
•
...is supported only on
Trunk
DNs, ignored by all other DN types.
sip-alert-info
Default Value: No default value
Valid Values: Any string
Changes Take Effect: Immediately
Related Feature: “Alternate Ringtones” on page 104
Specifies the content to be added to the
Alert-Info
header, used to trigger alternate ringtones or auto-answer functionality in the destination endpoint.
If configured, SIP Server includes the
Alert-Info
header with the value of this option whenever it sends an
INVITE
to this
Extension
or
ACD Position
DN—unless a different value is configured in the
SIP_HEADERS
extension of the initiating T-Library request.
For example, the following value points the endpoint to a ringtone file that can be used for internal calls:
<http://www.provider.com/tones/internal_caller.pcm>
Note:
The URI must be enclosed in angle brackets.
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
.
Note:
The value of the option in all cases, regardless of whether this DN is configured behind a softswitch.
sip-alert-info
applies to the individual DN
SIP Server—Deployment Guide 599
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
sip-alert-info-external
Default Value: No default value
Valid Values: Any string
Changes Take Effect: Immediately
Related Feature: “Alternate Ringtones” on page 104
Specifies the content to be added to the
Alert-Info
header for inbound external calls. If configured, SIP Server will include the value of this option in the
Alert-Info
header of the
INVITE
messages that it sends for an external call to this
Extension
or
ACD Position
DN—unless a different value is configured in the
SIP_HEADERS
extension of the initiating T-Library request.
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>
Notes:
• The URI must be enclosed in angle brackets.
• This option is not supported on a
Voice over IP Service
DN with service-type
set to softswitch
.
sip-alert-info-consult
Default Value: No default value
Valid Values: Any string
Changes Take Effect: Immediately
Related Feature: “Alternate Ringtones” on page 104
Specifies the content to be added to the
Alert-Info
header for consultation calls. If configured, SIP Server will include the value of this option in the
Alert-Info
header of the
INVITE
messages that it sends to establish a consultation call with this
Extension
or
ACD Position
DN—unless a different value is configured in the
SIP_HEADERS
extension of the initiating T-Library request.
For example, the following value points the endpoint to the ringtone file that will be used for external calls:
<http://www.provider.com/tones/consultation_call.pcm>
Notes:
• The URI must be enclosed in angle brackets.
• This option is not supported on a
Voice over IP Service
DN with service-type
set to softswitch
.
sip-answer-mode
Default Value: An empty string
Valid Values:
Auto
Changes Take Effect: Immediately
Specifies the content to be added to the
Answer-Mode
header used to trigger the auto-answer functionality in the destination endpoint. SIP Server sends this header regardless of whether an endpoint has advertised support for the
600 Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
“answermode” sip.extension in the contact of a
REGISTER
message. If this option is configured, SIP Server includes the
Answer-Mode
header with the value of this option whenever it sends an initial
INVITE
message.
Notes:
• The sip-answer-mode
option can be set at both DN and Application levels. Setting at a DN level takes precedence over Applicationlevel setting.
• Support of the
Answer-Mode
SIP header in
Auto
mode as described in RFC 5373 is compatible with Avaya 96xx phones. Avaya phones send
INVITE
messages without a
Referred-By
header in response to
REFER
from SIP Server; therefore, the refer-enabled
configuration option must be set to false.
Also, for Avaya phones, the dualdialog-enabled
configuration option must be set to true
and the sip-cti-control
configuration option should not be configured.
sip-busy-type
Default Value:
0
Valid Values:
0, 1, 2
Changes Take Effect: Immediately
When this option is set to
0
(the default), a busy tone is always played. When this option is set to
1
, a busy tone is played for a calling party only if a treatment is previously applied to a call or a call is originated by a 3pcc make
call operation, and the refer-enabled
option is set to false
. Otherwise, the rejected response is sent back to the calling party. When this option is set to
2
, a busy tone is not applied, and if SIP Server does not accept an
INVITE
session from a calling party, the rejected response is sent back to the calling party.
sip-chat-format
Default Value: text
Valid Values: text
, html
Changes Take Effect: Immediately
Related Feature: “Instant Messaging” on page 265
Specifies the format of the UserData IM content when different SIP endpoints support different IM formats.
If you set this option to text
, the UserData content in the IM is encoded in text
(text/plain) format. You must use this value for Microsoft Office
Communicator endpoints.
If you set this option to html
, the UserData content in the IM is encoded in html (text/html) format. You must use this value for Eyebeam SIP endpoints.
SIP Server—Deployment Guide 601
Chapter 7: SIP Server Configuration Options
Endpoint
Genesys SIP
Endpoint
BroadSoft SIP
Endpoint
Agent Login–Level and DN-Level Options
sip-cti-control
Default Value: No default value
Valid Values: beep, dtmf, talk, hold
(See Table below)
Value Description
beep Enables SIP Server to remotely control the playing of beep tones during call recording on a SIP endpoint built on the Genesys SIP
Endpoint SDK 8.0.
dtmf talk hold talk hold
Enables SIP Server to remotely control DTMF generation on SIP endpoint built on the Genesys SIP Endpoint SDK 8.0.
The
TAnswerCall
request is issued against the DN, which means that the call is answered remotely by a T-Library client. The SIP method
NOTIFY (event talk)
is used. Otherwise, the
TAnswerCall
request is not supported.
The
THoldCall
request is processed by a
NOTIFY
( event hold
) message. The
TRetrieveCall
request is processed by a
NOTIFY
(event talk) message.
The
TAnswerCall
request is issued against the DN, which means that the call is answered remotely by a T-Library client. The SIP method
NOTIFY (event talk)
is used. Otherwise, the
TAnswerCall
request is not supported.
The
THoldCall
request is processed by a
NOTIFY
( event hold
) message. The
TRetrieveCall
request is processed by a
NOTIFY
(event talk) message.
Changes Take Effect: For the next call
Related Feature (for values beep
and dtmf
): “Remote Media on Genesys SIP
Specifies the behavior of a DN that represents either of the following types of
SIP endpoints:
•
SIP endpoint built on the Genesys SIP Endpoint SDK 8.0, using proprietary SIP extensions. For this endpoint, you can configure this option with the values both beep
and dtmf
. For more information, see the SIP
Endpoint SDK 8.x API Reference.
•
SIP endpoint which supports the BroadSoft SIP Extension Event Package.
For this endpoint, you can configured this option with the values talk
and hold
.
Note:
For either SIP endpoint, the two supported values for that endpoint can be used simultaneously as a list of comma-separated values.
602 Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
sip-disable-greeting
Default Value: false
Valid Values: true, false
Changes Take Effect: At the next call
If set to true
on a
Trunk
DN and SIP Server sends an outgoing
INVITE
message to this trunk, the greeting is not started and the extension’s greeting parameters are added to the outgoing
INVITE
in a specific header. If set to false,
SIP
Server behavior is not changed.
sip-early-dialog-mode
Default Value:
0
Valid Values:
0
,
1
Changes Take Effect: At the next incoming dialog
Related Feature: “Early Media for Inbound Calls” on page 247
and
For devices that support an offer/answer exchange using the
UPDATE
method,
SIP Server will send the
UPDATE
to the called device if the
Trunk
DN is configured with sip-early-dialog-mode set to
1
. If set to
0
, this functionality is disabled.
The following scenarios are supported:
•
Transfer is completed to a ringing destination.
•
Conference is completed to a ringing destination.
•
Alternate call when destination is ringing.
•
SendDTMF
,
Hold
, or
Retrieve
on the calling party.
Note:
For compatibility reasons, DNs with the option sip-server-intertrunk
set to
1
also support early media, if support for early media
(
PRACK
) is reported in the
Allow
header.
sip-enable-100rel
Default Value: true
Valid Values: true false
SIP Server advertises support for
100rel
, and requires it whenever the other side indicates support.
SIP Server does not negotiate support for the reliability of provisional responses.
Changes Take Effect: Immediately
If set to true
, SIP Server places the option tag
100Rel
inside the
Supported header of outgoing initial
INVITE
requests. This informs SIP clients that SIP
Server is able to process provisional responses reliably.
SIP Server—Deployment Guide 603
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
sip-enable-diversion
Default Value: false
Valid Values: true, false
Changes Take Effect: Next request
Related Feature: “Diversion Header” on page 203
For call forwarding or call redirection through 3pcc request, this option specifies whether the
Diversion
header will be included in
INVITE
sent to the destination DN. If this option is set to true
on the destination DN, then SIP
Server includes the
Diversion
header. Similarly, when SIP Server receives a
302 Moved Temporarily
response that includes the
Diversion
header, this option controls whether SIP Server will forward the
Diversion
header in the resulting
INVITE
message.
sip-enable-ivr-metadata
Default Value: No default value
Valid Values: true, false
Changes Take Effect: For the next call
This option is used for IVR recording call scenarios. Specifies whether SIP
Server passes its Application name in the initial
INVITE
message (in the
X-
Genesys-sipsAppName
header) to Media Server. If this option is set to true,
SIP
Server includes its Application name in the custom header of the
INVITE
that it sends to Media Server. If this option is set to false,
SIP Server does not include its Application name in the initial
INVITE
sent to Media Server. This option applies to DNs of type
Trunk, Voice over IP Service (msml), Trunk
Group,
and
Voice Treatment Port.
Notes:
• If the IVR recording feature is enabled, then it is not required to explicitly enable recording by setting the record
option to true
on
DNs representing GVP, such as
Trunk, Trunk Group,
or
Voice
Treatment Port.
Recording is started by the VXML application running on the Media Server.
• This option can also be configured at the Application level. The
DN-level setting takes precedence over the Application-level setting.
sip-enable-moh
Default Value: No default value
Valid Value: true, false, na
Changes Take Effect: For the next call (if value is empty, changes do not take effect until after application restart)
Related Feature: “Customizing Music on Hold and in Queue” on page 194
Set this option to true
to enable music-on-hold for any party engaged with this device in the call.
If this option is set to false
in the device configuration, it disables the musicon-hold treatment
for any party that is engaged with this device in the call,
604 Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options even if the device sends an
INVITE
request containing a hold SDP. If you set this option to na (non-applicable), SIP Server processes an
INVITE
with a hold
SDP as a regular
INVITE
, by simply propagating that
INVITE
to the opposite party without attempting to apply music.
Genesys recommends setting this option to either false
or na
on
Trunk
DNs that represent gateways. This ensures that
INVITE
requests containing hold
SDPs sent from these gateways will not trigger music-on-hold to be played on agent DNs.
The na
value can be used on
Trunk
DNs only.
Note:
This option can also be configured at the Application level. The
DN-level setting takes precedence over the Application-level setting.
sip-enable-sdp-codec-filter
Default Value: false
Valid Values: true false
SIP Server modifies the SDP message body during SIP renegotiation.
SIP Server does not modify the SDP message body.
Changes Take Effect: For the next call
Related Option:
Specifies whether SIP Server modifies the SDP message body during SIP renegotiation. All codecs that are not in the list of values for the
option are deleted from the SDP. As a result, all call center audio traffic is
established based on the codecs listed in the audio-codecs
If sip-enable-sdp-codec-filter
is set to true
in the DN configuration, SIP
Server, as it propagates the SDP to and from the device represented by this
DN, will use as its list of available codecs the value configured in the audiocodecs
option on the DN rather than on the application. If sip-enable-sdpcodec-filter
is set to true
at both the Application and the DN level, then the audio-codecs
configured in the DN should contain a subset of the audiocodecs
configured in the Application.
Note:
Currently, SIP Server does not support filtration of video codecs.
Set on Destination
DN only
sip-error-conversion
Default Value: No default value
Valid Values: A comma-separated list of value pairs:
<received error code>=<converted error code> (for example,
480=486
,
500=486
), or
0
=<converted error code> (for example,
0=486
)
Changes Take Effect: Immediately
When this option is set to <received error code>=<converted error code> on the destination DN, SIP Server converts the received error response code to the
SIP Server—Deployment Guide 605
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
Set on Origination
DN only
Set on both
Destination and
Origination DNs
configured code and sends the converted SIP response code to the origination device. This setting affects the following:
•
How the SIP error code is processed by SIP Server.
For example, SIP error code
486 (Busy Here) means a destination is busy.
SIP error code
408
(
Request Timeout
) received for a DN places a DN in out-of-service state. If this option is set to
408=486 and the DN responds with the
408
error code, SIP Server will not place the DN in out-of-service state.
•
The
ErrorCode
that is returned in
EventError
to a routing application when a routing attempt is unsuccessful.
For example, when a routing destination responds to the
INVITE
message with code
486
(
Busy Here
), SIP Server sends
ErrorCode 231
(
DN is Busy
) to a routing application. If this option is set to
486=404,
SIP Server returns
ErrorCode 71
(
Invalid Called DN
) to a routing application.
When this option is set to
0
=<converted error code> on an origination DN, SIP
Server sends the converted SIP error code if one of the following occurs:
•
The destination device fails to respond to the incoming
INVITE
message.
•
No active DN is found for SIP Server to send a call.
Note:
If a destination DN of type
Extension
fails to respond to the incoming
INVITE
message, SIP Server places the
Extension
DN in out-of-service state regardless of the sip-error-conversion
setting.
The sip-error-conversion
option can be configured on both destination and origination DNs at the same time. If an error message is received from a destination device, the option value of the destination device will be used. If no response is received from the destination device or no active DN is found, SIP
Server will use the option value configured on the origination device.
The option can be configured on the following levels and in the following order of precedence:
•
DN level
•
Application level
The option can be configured for the following DN types:
•
Trunk
, including GVP Trunk
• Trunk Group
•
Extension
•
V oice over IP Service
with service-type=softswitch
•
Voice Treatment Port
606 Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
sip-error-overflow
Default Value: An empty string
Valid Values: A string
Changes Take Effect: Immediately
Specifies the destination number to which SIP Server will forward a call if this device responds with a failure (error) to a SIP
INVITE
.
Notes:
• If an outbound call is made from the DN where the
sip-erroroverflow
option is defined and an error response is received from the external destination, the outbound call is transferred to the overflow DN.
• Forwarding using the Dial Plan functionality will take priority over the sip-error-overflow
configuration option.
configuration option is not applicable if
siperror-overflow
is configured, because the device can no longer be busy (it will forward to the sip-error-overflow
destination instead).
• Setting sip-error-overflow=gcti:voicemail
is not supported.
sip-filter-media
Default Value: No default value
Valid Values: none, video
Changes Take Effect: Immediately
Related Feature: “Video Blocking” on page 389
When set to video
, SIP Server blocks video media streams in calls coming to or originating from this DN. When set to none,
SIP Server does not block video media streams, even if the
option is enabled at the
Application level. The option can be configured on DNs of type
Extension,
Trunk, Trunk Group,
or
Voice over IP Service
.
Note:
This option can also be configured at the Application level. The
DN-level setting takes precedence over the Application-level setting.
sip-from-pass-through
Default Value: false
Valid Values: true, false
Changes Take Effect: For the next call
Specifies whether SIP Server will use the content of the
From
header from the original
INVITE
to generate the content for the
From
header in the outgoing
INVITE
message.
SIP Server—Deployment Guide 607
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
sip-hold-rfc3264
Default Value: false
Valid Values: true false passthrough
RFC3264-compliant implementation.
RFC2543-compliant implementation.
Prevents SIP Server from changing sendonly
and recvonly
SDP attributes to inactive in the answering SDP; in other words, SIP Server simply passes these attributes through unchanged.
Changes Take Effect: For the next call
Specifies which implementation of hold media SDP is used by SIP Server for hold operations.
Note:
This option can also be configured at the Application level. The
DN-level setting takes precedence over the Application-level setting.
sip-oos-enabled
Default Value: true
Valid Value: true, false
Related Feature: “Passive Out-of-Service Detection” on page 254
Related Option:
Specifies whether a DN can be placed into the out-of-service state in case of
SIP failure. DNs can be placed in this state by default. If set to false,
setting to the out-of-service state is disabled for this DN.
sip-pass-body
Default Value: An empty string
Valid Values: cid
Changes Take Effect: For the next call
Related Feature: “Caller Information Delivery Content for AT&T Trunks” on page 122
Specifies the content type that should be passed in the multipart body of the origination
INVITE
to this device, if that content type is received from the caller.
•
If set to an empty string (default), SIP Server does not send any special content types.
•
If set to cid,
SIP Server sends the CID body to the DN.
This option...
•
...does not affect SDP.
•
...is supported on
Trunk
DNs,
Trunk Group
DNs, and
VoIP Service
DNs with service-type
set to msml
and voicemail
.
608 Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
sip-pass-xfer-params-enabled
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
If set to true
, SIP Server passes Request-URI parameters received in the
Refer-To
header of the incoming
REFER
request to the Request-URI of the outgoing
INVITE
request.
If set to false
, SIP Server does not pass Request-URI parameters received in the
Refer-To
header of the
REFER
request to the outgoing
INVITE
request.
This option can be applied to a DN object that is the target of the
REFER-INVITE transfer.
sip-preserve-contact
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Specifies whether SIP Server preserves session information (a cookie) that is appended to the user-info part of the
Contact
header in
REGISTER
requests. If you set this option to true
, SIP Server preserves the cookie from the
REGISTER request, and then includes the cookie in the
Request-URI
of the outgoing
INVITE request.
Note:
This option can also be configured at the Application level. The
DN-level setting takes precedence over the Application-level setting.
sip-proxy-uri-parameters
Default Value: false
Valid Values: true, false
Changes Take Effect: For the next call
Specifies whether SIP Server will forward URI parameters from an incoming
INVITE
request to an outgoing
INVITE
. If you set this option to true, SIP Server will forward all
Request-URI
parameters from the incoming
INVITE
request to the outgoing
INVITE
message.
For example, you can use this option to enable network requests for media
services provided by Genesys Media Server. For details, see Table 13:
Enabling Network Requests for Media Services, on page 97 .
SIP Server—Deployment Guide 609
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
sip-rel-200-retransmit
Default Value: false
Valid Values: false, true
Changes Take Effect: For the next call
Specifies if SIP Server retransmits
200 OK
in response to an
INVITE
message on reliable transports if
ACK
is not received for
200 OK
. (The default value of this option ( false
) enables the previous behavior in SIP Server.)
Note:
This option can also be configured at the Application level. The
DN-level setting takes precedence over the Application-level setting.
sip-replaces-mode
Default Value:
0
Valid Values:
0, 1, 2, 3
Changes Take Effect: For the next call
Related Feature: “TCompleteTransfer using REFER or REFER with Replaces” on page 177
Specifies the SIP method used by SIP Server to complete a two-step transfer.
•
With a value of
0
, SIP Server uses the
REFER
method if the transfercomplete-by-refer option is set to true
.
•
With a value of
1
, SIP Server uses the
REFER
method with
Replaces
if the
Allow
header contains
REFER
as a supported method and the
Supported header contains
Replaces
. If
REFER
with
Replaces
is not supported by a device, then
TCompleteTransfer
will be performed using the
REFER
method.
If a device does not support the
REFER
method, then the transfer will be completed using the re-
INVITE
method.
•
With a value of
2,
SIP Server uses the
REFER
method with
Replaces
to process
TCompleteTransfer
. The
Allow
and
Supported
headers will not be analyzed.
•
With a value of
3,
when the DN-level sip-server-inter-trunk option is set to true
, SIP Server uses the re-
INVITE
method instead of the
REFER method for transfers and call routing.
Note:
For this functionality to work, the refer-enabled
option must be set to true
in the DN from which a call party is transferred to another destination during a two-step transfer.
610 Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
sip-request-oos-timeout
Default Value:
0
Valid Values:
0-31
(seconds)
Changes Take Effect: Immediately
Related Feature: “DNS Name Resolution” on page 232
Controls the length of time, in seconds, SIP Server continues trying requests for a new SIP transaction. After the timeout expires, SIP Server considers the transport as failed, and will instead try the next transport type.
If the value is set to
0,
or no value is specified, SIP Server does not start this timer.
If the value is set to any number higher than
0,
SIP Server will continue retrying a transaction for the specified length of time; after the timer expires,
SIP Server will instead try the next active destination, for the next SIP transaction.
Note:
Genesys recommends setting this timeout to a shorter length than the default SIP timeout (32 seconds), or the value of the sip-invitetimeout
and sip-invite-treatment-timeout
options.
sip-response-msml-oos
Default Value: An empty string
Valid Values: Valid SIP response code between 400 and 699, inclusive
Changes Take Effect: For the next call
Specifies the SIP response code that SIP Server sends in response to an incoming
INVITE
. This option takes effect only for inbound calls received when the MSML DN is out of service. It is supported on Trunk DNs only. It must be set on the inbound trunk and applies to calls for which this trunk is used as an origination device. If the option is not set, or set to an invalid value, this feature is disabled.
The sip-response-msml-oos
option can be configured with the existing DNlevel option sip-error-conversion
, when the MSML service is available but a response to an
INVITE
requires a SIP response code. For example, if sipresponse-msml-oos = 503
, sip-error-conversion = 404=603
, and a call is made to an unknown DN, SIP Server will respond to an incoming
INVITE
with the
603 SIP message.
sip-ring-tone-mode
Default Value:
0
Valid Values:
0,1
Changes Take Effect: Immediately
With the option set to
0,
SIP Server connects Stream Manager to a call to play an audio ringtone. With the option set to
1,
SIP Server waits for a response from the called device, and connects Stream Manager to a call to play an audio
SIP Server—Deployment Guide 611
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options ringtone, only when the returned response cannot be used as the offer to a calling device.
Notes:
• SIP Server does not support internal ringtones in conference scenarios where the sip-ring-tone-mod e option is set to
1
. In this case, SIP Server provides a ringtoneonly if the endpoint returns an
SDP in the provisional message.
• This option can be set at both the SIP Server Application level and at the Switch/DN level. The setting at the Switch/DN level takes precedence over the Application-level setting.
sip-route
Default Value: No default value
Valid Values: Any valid SIP URI
Changes Take Effect: Immediately
Specifies the default SIP URI SIP Server uses to route SIP messages involving this DN, which should be registered in IMS (and so configured with enableims set to true
).
sip-route-active-transport
Default Value: false
Valid Values: true, false
Changes Take Effect: For the next call
When set to true,
SIP Server updates the
Route
header with the active
Resource Manager (RM) contact. This option must be set to true
on all DNs that are configured to point to the RM pair:
•
Trunk
•
Trunk Group
•
Voice Treatment Port
•
Voice over IP service DN with service-type=msml
•
Voice over IP service DN with service-type=voicemail
sip-server-inter-trunk
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Related Features: “Trunk Optimization for Multi-Site Transfers” on page 383
and “Early Media for Inbound Calls” on page 247
Related Options: “charge-type” on page 556
and “sip-early-dialog-mode” on page 603
When this option set to true
, depending on the scenario, SIP Server determines whether to complete the transfer operation using the
REFER
or
INVITE
request with the
Replaces
header.
612 Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
sip-signaling-chat
Default Value: session
Valid Values: session, none
Changes Take Effect: Immediately
Related Feature: “Instant Messaging” on page 265
Specifies the chat mode for the Instant Messaging (IM) DN on which this option is configured.
If you set this option to session
, when the first SIP dialog containing an IM
SDP is created, the
MESSAGE
requests are exchanged only in this dialog. You must use this value for Microsoft Office Communicator endpoints.
If you set this option to none
, SIP Server does not send a SIP
MESSAGE
to a SIP
Endpoint during IM. Chat communication (IM) will be provided to the agent desktop by only the T-Library protocol.
sip-to-pass-through
Default Value: false
Valid Values: true, false
Changes Take Effect: For the next call
Specifies whether SIP Server uses the content of the
To
header from the original
INVITE
request, in cases where SIP Server passes through the call.
Note:
This option does not work when enabled (set to true
) on the destination agent for a two-step transfer initiated by another agent with dual-dialog-enabled
set to false
.
sip-transfer-complete-message
Default Value: An empty string
Valid Values:
1XX, 18X, 180, 183
Changes Take Effect: Immediately
Defined for a DN through which SIP Server sends a
REFER
request, this option specifies on which message SIP Server completes
REFER
-based transfers. When this option is set to:
•
An empty string (no value is specified)—SIP Server completes the
REFER
based transfer after receiving a
200 OK
message within the
NOTIFY
request
(the default behavior).
•
1XX
—SIP Server completes the
REFER
-based transfer after receiving any provisional response within the
NOTIFY
request.
•
18X
—SIP Server completes the
REFER
-based transfer after receiving a
180 or
183
provisional response within the
NOTIFY
request.
•
180
—SIP Server completes the
REFER
-based transfer after receiving a
180
Ringing
provisional response within the
NOTIFY
request.
•
183
—SIP Server completes the
REFER
-based transfer after receiving a
183
Session Progress
provisional response within the
NOTIFY
request.
SIP Server—Deployment Guide 613
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
sip-trying-timeout
Default Value: An empty string
Valid Values:
0-256
Changes Take Effect: For the next call
Related Feature: “Setting SIP INVITE Timeout for Individual DNs” on page 110
Specifies the period of time (in seconds) that a SIP call remains in an active 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 no-responsedn
option, or is released if that option is not configured. If the
sip-tryingtimeout
option is not specified, the value of the Application-level option sipinvite-timeout
sip-invite-timeout
option is set to
0
, the default value of
32
seconds is used.
The sip-trying-timeout
option can be set on the following DN types:
•
Extension
•
Trunk
•
Voice over IP Service
with service-type=softswitch
sip-uri-params
Default Value: No default value
Valid Values: A string that contains valid URI parameters
Changes Take Effect: For the next call
Related Feature: “Enabling Additional Parameters in Request-URI” on page 198
Specifies which URI parameters SIP Server will add to the initial
INVITE request to start a dialog with this DN. If configured, SIP Server sends the specified parameters in the initial
INVITE
to this DN. To include multiple parameters, enter in a semicolon separated list.
sip-user-agent
Default Value: No default value
Valid Values: A valid string or the special character
*
Changes Take Effect: For the next call
Specifies whether SIP Server includes the
User-Agent
header in all request messages that it sends. The value for this option can contain the following placeholders:
•
$VERSION$
= will be replaced with the current SIP Server build
•
$APP-NAME$
= will be replaced with the name of the application in the environment
You can also use the special value *, which is equivalent to
Genesys SIP
Server $VERSION$ ($APP-NAME$)
.
614 Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
stranded-calls-overflow
Default Value: No default value
Valid Values:
<destination_number>
, default
or
<empty string>
, recall
, release
, none
Changes Take Effect: Immediately
Related Feature: “Alternate Routing for Stranded Calls” on page 108
Related Option:
stranded-call-redirection-limit
Specifies a list of actions that SIP Server attempts to take for calls stranded on
ACD Queues. You can configure these actions globally for all queues (at the
Application-level) or individually for a particular
ACD Queue
DN. Configure the actions using a comma-separated list of valid values; SIP Server tries to process each item in the list sequentially, moving on to the next item if any action fails, and stopping after the first successful action begins (subsequent failure of the successful action does not restart the list).
Note:
For a description of the valid values and their related SIP Server
actions, see “Stranded Calls Overflow Valid Values” on page 109
.
stranded-on-arrival-calls-overflow
Default Value: No default value
Valid Values:
<destination_number>
, default
or
<empty string>
, recall
, release
, none
Changes Take Effect: Immediately
Related Feature: “Alternate Routing for Stranded Calls” on page 108
Related Option:
stranded-call-redirection-limit
Specifies a list of actions that SIP Server attempts to take for calls arriving on
ACD Queues that have no logged-in agents. You can configure these actions globally for all queues (at the Application-level) or individually for a particular
ACD Queue
DN. Configure the actions using a comma-separated list of valid values; SIP Server tries to process each item in the list sequentially, moving to the next item if any action fails, and stopping after the first successful action begins (subsequent failure of the successful action does not restart the list).
Note:
For a description of the valid values and their related SIP Server
actions, see “Stranded Calls Overflow Valid Values” on page 109
.
subscription-id
Default Value: No default value
Valid Values: Any valid string
Changes Take Effect: Immediately
This parameter is required for SIP Server integration with GVP.
For GVP 7.6, if the GVP Resource Manager (RM) is configured as a redirection server, you must configure the subscription-id
option on all DNs representing GVP media servers (or ports). Set the value of this parameter to
GVP
. In this configuration, GVP Resource Manager subscribes to notifications
SIP Server—Deployment Guide 615
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options about the call status at SIP Server, which works as a notification provider. SIP
Server sends a SIP
NOTIFY
message to the GVP RM at the end of every call, supporting GVP resource management functionality.
In 8.0, GVP can be integrated with SIP Server using MSML protocol. In this case, the GVP RM is represented in the Configuration Layer as a
Trunk
DN with the required option s ubscription-id
properly configured. You must set the value of this option to msml
. In this configuration, SIP Server works as a subscribing client—it activates a subscription to the GVP Resource Manager, and then receives notifications whenever a media server goes out of service, so that SIP Server can perform a recovery for any ongoing media sessions
(restarting on remaining active media server instances).
Notes:
• For the Outbound IP Solution, you must not set the value of this option to
GVP
. This value is reserved for GVP 7.6 integrations. If you set the subscription-id
on a
Trunk Group
DN to this value,
SIP Server will not activate the subscription required for the
Outbound IP Solution. See Table 75 on page 322
for configuration details.
• You can configure multiple Resource Manager
Trunk Group
DNs on the same tenant as the SIP Server switch. However, Genesys recommends that you plan deployment to use a minimal number of
Trunk Group
DNs for a single tenant—ideally, one per tenant—because SIP Server activates a separate subscription for every
Trunk Group
DN configured for subscription-id
, which can affect system performance due to the large number of
NOTIFY messages exchanged between the GVP RM and SIP Server.
subscribe-presence-domain
Default Value:
NULL
Valid Values: Any valid computer name on the softswitch
Changes Take Effect: Immediately
Related Feature: “Presence from Switches and Endpoints” on page 336
Specifies the subscription domain information for the
Trunk
DN. This option value will be used with the DN name to form the
SUBSCRIBE
request
URI
and the
To
header.
subscribe-presence-from
Default Value:
NULL
Valid Values: Any valid SIP URI
Changes Take Effect: Immediately
Related Feature: “Presence from Switches and Endpoints” on page 336
Specifies the subscription endpoint information. This option value will be used to form the
From:
header in the
SUBSCRIBE
request to the softswitch.
Note:
For softswitches such as Microsoft LCS and Asterisk, the username part of this SIP URI must not be configured in the softswitch.
616 Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
subscribe-presence-expire
Default Value:
1800
Valid Values: Any valid positive integer from
10 to 259200
(from 10 seconds to
72 hours)
Changes Take Effect: Immediately
Related Feature: “Presence from Switches and Endpoints” on page 336
Specifies the subscription renewal interval (in seconds).
subscribe-presence
Default Value:
NULL
Valid Values: publish
, or the name of the
Trunk
DN representing the softswitch
Changes Take Effect: Immediately
Related Feature: “Presence from Switches and Endpoints” on page 336
Enables presence subscription and mapping of a presence state to an agent state:
•
If set to publish,
SIP Server uses presence updates from a
PUBLISH
SIP request sent by a SIP Endpoint, and maps the presence state from the
PUBLISH
request to the agent state.
•
If set to the name of a
Trunk
DN that contains the subscription parameters is specified, the enable-agentlogin-presence
also be configured for the same
Trunk
DN.
transfer-complete-by-refer
Default Value: false
Valid Values: true, false
Changes Take Effect: For the next call
Related Feature: “TCompleteTransfer using REFER or REFER with Replaces” on page 177
If set to true
, this option enables SIP Server to complete a two-step transfer by sending a
REFER
message to the party in the primary call. SIP Server uses the same content as in the
REFER
message that is sent for a single-step transfer. For this option to work, you must configure refer-enabled
on the
Trunk
DN to true
.
Limitations for this option include the following:
•
REFER
is not used if the primary party on the consultation call is involved in a conference.
•
REFER
is not used if the call is currently being recorded.
•
This option is not supported on
Trunk
DNs that are configured between different SIP Server instances, and it is ignored on
Trunk
DNs where the
true
.
SIP Server—Deployment Guide 617
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
use-contact-as-dn
Default Value: false
Valid Values: true, false
Changes Take Effect: For the next call
Specifies whether SIP Server will use the username of the
Contact
header as attribute
ThisDN
.
use-display-name
Default Value: true
Valid Values: true, false
Changes Take Effect: For the next call
Specifies whether SIP Server takes any action to populate the
Display-Name
of a call originator in the
From
header of an outgoing
INVITE
message with the
•
If set to false,
SIP Server does not take any action.
•
If set to true,
SIP Server uses the value of the
configuration option.
user-data-im-enabled
Default Value: false
Valid Values: true
, false
Related Feature: “Instant Messaging” on page 265
Enables the
UserData
content in the Instant Messaging (IM) for a DN.
Note:
Only a subset of the
UserData
is sent through IM (whatever is contained in the
IMDelivery
sublist in the
KVList
in the
UserData
). In addition to this option, you must also configure the routing strategy so it includes the
IMDelivery
sub-list in attached
UserData
.
T-Library clients (for example, Genesys Agent Desktop) are able to see all of the attached
UserData
.
userdata-map-filter
Default Value: No default value
Valid Values:
*
All data is mapped.
A list of prefixes
A comma-separated list of prefixes that must match the initial characters of the key in the
UserData
key-value pair.
If the list of prefixes contains an * (asterisk), then the * will be processed as a prefix.
Changes Take Effect: Immediately
Related Feature: “Mapping SIP Headers and SDP Messages” on page 276
618 Framework 8.1
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
Specifies a prefix (or a list of prefixes) that must match the initial characters of the key in the
UserData
key-value pair. When the initial characters match, then
SIP Server maps the
UserData
key-value pair into SIP messages.
For example, if userdata-map-filter=test
and
AttributeUserData
contains
'test'='value1'
,
'testlocal'= 'value2
', and ' generaltest'='value3'
, only key-value pairs
'test'='value1'
and
'testlocal'= 'value2'
will be mapped.
The
'generaltest'='value3
' will be ignored because its initial characters do not match the prefix “test”.
If this option is not specified, no data will be mapped.
userdata-map-format
Default Value: sip-headers
Valid Values: sip-headers, sip-headers-encoded
Changes Take Effect: For the next request
If set to sip-headers,
the userdata is passed as a SIP header to the GVP.
If set to sip-headers-encoded,
the userdata containing special characters—such as a comma (,), percentage (%), and/or a semicolon (;)—sent to the Media Server will be encoded (escaped) and decoded when it is received.
use-register-for-service-state
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Determines the
Extension
DN service state after it has been unregistered with
SIP Server.
•
If set to true
, the DN is set to the
Out of Service
state in the following scenarios:
The SIP
REGISTER
request contains an
Expires
header value equal to
0
.
The SIP registration timer has expired.
An
EventDNOutOfService
message is generated to indicate the DN is currently out of service.
Note:
If the client sending the
REGISTER
request with an
Expires
header of
0
was not previously registered with SIP Server, SIP Server generates a
403 Forbidden
response.
•
If set to false
(or not configured), the DN service state is not set to the
Out of Service
state when it has been unregistered with SIP Server.
SIP Server—Deployment Guide 619
Chapter 7: SIP Server Configuration Options Agent Login–Level and DN-Level Options
voicemail-pattern-<n>
Default Value: No default value
Valid Values: A string pattern in the Asterisk format
Changes Take Effect: At the next established call
Specifies the pattern SIP Server looks for in the redirectNumber
header of
181
Call Is Being Forwarded messages received in response to an
INVITE triggered by a
TMakePredictiveCall
. If SIP Server matches the pattern in the header to the pattern configured in this option, it cancels the call, mapping the reason for the redirection to a Genesys CallState. If SIP Server does not make a match between the header and this option, the call proceeds as normal.
The redirectNumber
header arrives in the format:
XYYYYYYYYYYYY where
X
provides the reason for the redirection, and
YYYYYYYYYYYY
provides the number where the call is being redirected. SIP Server matches X to the corresponding Genesys
CallState
as follows:
Code Reason
x=1 Call forward; line busy x=2 Call forward; no reply x=3 Call forward; unconditional x=4 Call forward; not reachable/Other
Genesys CallState
Busy
NoAnswer
AnsweringMachineDetected
AnsweringMachineDetected
SIP Server uses the Asterisk pattern-matching format to match the value of the header to the value of this option. For a full description of Asterisk pattern-
matching syntax, see Table 53, “Asterisk Dial Plan Syntax for Pattern
.
620 Framework 8.1
Chapter 7: SIP Server Configuration Options GVP Integration Options
GVP Integration Options
This section describes a configuration option specific to the Genesys Voice
Platform (GVP) functionality with SIP Server. Configure this option in the extrouter
section of the SIP Server
Application
object.
handle-vsp
Default Value: no
Valid Values: requests events all no
The ISCC component of SIP Server will attempt to translate requests related to this DN before submitting them to the service provider.
The ISCC component of SIP Server will attempt to process events received from the service provider before distributing them to SIP Server clients.
The ISCC component of SIP Server will handle both the events and requests.
No processing will take place.
Changes Take Effect: Immediately
Specifies the way SIP Server will handle events from, and requests to, an external service provider registered for a DN using the
AddressType
attribute set to
VSP
.
Reserved Options
Warning!
The options documented in this section are reserved for Genesys
Engineering and their values cannot be changed.
Table 110: Reserved Configuration Options
Option Name
accept-dn-type backup-mode call-max-outstanding call-rq-gap clid-withheld-name correct-rqid
Option Section
Application level >
TServer
section
Application level >
TServer
section
Application level >
TServer
section
Application level >
TServer
section
Application level >
TServer
section
Application level >
TServer
section
SIP Server—Deployment Guide 621
Chapter 7: SIP Server Configuration Options Reserved Options
Table 110: Reserved Configuration Options (Continued)
Option Name
default-dn-type device-rq-gap dn-del-mode emulate-login expire-call-tout kpl-interval kpl-loss-rate kpl-tolerance max-pred-req-delay nas-indication override-switch-acw prd-dist-call-ans-time quiet-cleanup quiet-startup recall-no-answer-timeout reg-delay reg-interval reg-silent rq-conflict-check sync-emu-agent unknown-xfer-merge-udata wrap-up-threshold
Option Section
Application level >
TServer
section
Application level >
TServer
section
Application level >
TServer
section
Application level >
TServer
section
Application level >
TServer
section
Application level >
TServer
section
Application level >
TServer
section
Application level >
TServer
section
Application level >
TServer
section
Application level >
TServer
section
Application level >
TServer
section
Application level >
TServer
section
Application level >
TServer
section
Application level >
TServer
section
Application level >
TServer
section
Application level > link-control
section
Application level >
TServer
section
Application level > link-control
section
Application level >
TServer
section
Application level >
TServer
section
Application level >
TServer
section
Application level >
TServer
section
622 Framework 8.1
Chapter 7: SIP Server Configuration Options Changes from Release 8.0 to Release 8.1
Changes from Release 8.0 to Release 8.1
Table 111 lists the configuration options that:
•
Are new or changed in the 8.1 release of SIP Server
•
Have been added or changed since the most recent 8.0 release of this document
If a configuration option has been replaced with another that enables the same functionality, the new option name and its location in this chapter are noted.
Note:
Starting in Deployment Guide version 8.1.101.35,
longer updated. For new and updated options, see “Document Change
Table 111: Option Changes from Release 8.0 to Release 8.1
Option Name
agent-emu-login-on-call agent-logout-on-unreg agent-logout-reassoc alternate-route-profile bsns-call-dev-types call-monitor-acw call-observer-with-hold cancel-monitor-on-unpark capacity-sip-error-code capacity-tlib-error-code clamp-dtmf-allowed connect-nailedup-on-login control-remote-vip-scripts control-vip-scripts
Option
Values
Type of
Change
Details
Application Level > TServer Section
true, false New in 8.1.0
See the option description on
.
true, false, emu-only
New in 8.1.0
See the option description on
.
true, false New in 8.1.0
See the option description on
.
String
String
New in 8.1.1
See the option description on
.
New in 8.1.0
See the option description on
.
String New in 8.1.1
See the option description on
.
true, false New in 8.1.0
See the option description on
.
true, false New in 8.1.0
See the option description on
.
400–699 New in 8.1.1
See the option description on
.
Integer New in 8.1.1
See the option description on
.
true, false New in 8.1.1
See the option description on
.
String
String
String
New in 8.1.1
See the option description on
.
New in 8.1.1
See the option description on
.
New in 8.1.1
See the option description on
.
SIP Server—Deployment Guide 623
Chapter 7: SIP Server Configuration Options Changes from Release 8.0 to Release 8.1
Table 111: Option Changes from Release 8.0 to Release 8.1 (Continued)
Option Name
default-route-point-order disable-media-before-greeting disconnect-nailedup-timeout drop-nailedup-on-logout dr-forward dr-peer-location dr-peer-trunk enable-busy-on-routed-calls enable-ims enable-strict-location-match feature-code-park feature-code-pickup feature-code-retrieve fmfm-confirmation-digit fmfm-confirmation-timeout fmfm-prompt-file fmfm-trunk-group
Option
Values
String true, false
String
String
Integer true, false true, false
Integer
Integer
Integer
Integer
String
String
Type of
Change
Details
New in 8.1.1
See the option description on
.
true, false New in 8.1.1
See the option description on
.
Integer New in 8.1.1
See the option description on
.
New in 8.1.0
New in 8.1.0
New in 8.1.1
See the option description on
.
New in 8.1.0
See the option description on
.
New in 8.1.0
New in 8.1.0
See the option description on
See the option description on
See the option description on
See the option description on
true, false New in 8.1.1
See the option description on
.
Integer New in 8.1.1
See the option description on
.
New in 8.1.1
New in 8.1.1
New in 8.1.1
New in 8.1.1
New in 8.1.1
New in 8.1.1
See the option description on
See the option description on
See the option description on
See the option description on
See the option description on
See the option description on
force-p-early-media true, false New in 8.1.0
See the option description on
.
graceful-shutdown-sip-timeout String New in 8.1.1
See the option description on
.
.
.
.
.
.
.
.
.
.
.
ims-puid-domain String ims-sip-domain String ims-sip-params String ims-use-term-legs-for-routing String
New
New
New
New in 8.1.1
See the option description on
init-dnis-by-ruri true, See the option description on
.
keep-mute-after-conference true, false New in 8.1.0
See the option description on
.
.
.
.
.
624 Framework 8.1
Chapter 7: SIP Server Configuration Options Changes from Release 8.0 to Release 8.1
Table 111: Option Changes from Release 8.0 to Release 8.1 (Continued)
Option Name Option
Values
Integer
Type of
Change
Details
New in 8.1.1
See the option description on
.
max-parking-time monitor-consult-calls monitor-party-on-hold msml-location-alarm-timeout msml-record-support music-listen-disconnect music-on-pbxpark mwi-implicit-notify mwi-subscribe-vmb network-monitoring-timeout operational-stat-timeout overflow-location-map overload-ctrl-calltapplytreatment-requests-rate overload-ctrl-calltupdateuserdata-requests-rate
String New in 8.1.0
See the option description on
.
true, false New in 8.1.1
See the option description on
.
String true, false
String
String true, false true, false
Integer New in 8.1.1
See the option description on
.
true, false New in 8.1.1
See the option description on
.
String
Integer overload-ctrl-call-trequests-rate Integer
Integer
New in 8.1.1
New in 8.1.0
New in 8.1.0
New in 8.1.1
New in 8.1.1
See the option description on
.
New in 8.1.1
See the option description on
.
New in 8.1.1
See the option description on
See the option description on
See the option description on
See the option description on
See the option description on
New in 8.1.1
See the option description on
.
New in 8.1.1
See the option description on
.
New in 8.1.1
See the option description on
.
.
.
.
.
.
overload-ctrl-trequests-rate Integer p-asserted-identity String
New in 8.1.1
See the option description on
New
privacy String reason-in-extension true, false
New
New in 8.1.0
See the option description on
.
.
.
.
record-after-merge record-moh true, false New in 8.1.0
See the option description on
.
true, false New in 8.1.1
See the option description on
.
recording-failure-alarm-timeout Integer New in 8.1.1
See the option description on
.
refer-enabled true, See the option description on
.
SIP Server—Deployment Guide 625
Chapter 7: SIP Server Configuration Options Changes from Release 8.0 to Release 8.1
Table 111: Option Changes from Release 8.0 to Release 8.1 (Continued)
Option Name Option
Values
Type of
Change
Details
registrar-default-timeout Integer releasing-party-report
Changed
.
8.1.0
true, false New in 8.1.0
See the option description on
.
resolve-external-contact resolve-internal-rp-by-host resolve-sip-address resource-management-by-RM restart-period route-failure-alarm-high-wm route-failure-alarm-low-wm route-failure-alarm-period true, false New in 8.1.1
See the option description on
.
true, false New in 8.1.1
See the option description on
.
true, false New in 8.1.0
See the option description on
.
true, false New in 8.1.0
See the option description on
.
Integer
Integer
Integer
Integer
New in 8.1.0
New in 8.1.0
New in 8.1.0
New in 8.1.0
See the option description on
See the option description on
See the option description on
See the option description on
.
.
.
.
send-200-on-clear-call shutdown-sip-reject-code session-refresh-enforced silence-detected sip-3pcc-from-pass-through sip-491-passthrough sip-add-contact-early-dialog sip-address-srv sip-alert-info sip-alert-info-external sip-alert-info-consult sip-answer-mode sip-enable-call-info-extended sip-enable-gdns true, false New in 8.1.0
See the option description on
.
Integer New in 8.1.0
See the option description on
true, false New in 8.1.1
See the option description on
.
String New in 8.1.0
See the option description on
true, false New in 8.1.1
See the option description on
.
true, false New in 8.1.0
See the option description on
.
true, false New in 8.1.0
See the option description on
.
String New in 8.1.0
See the option description on
.
String
String
String
Auto
New in 8.1.0
New in 8.1.0
New in 8.1.0
New in 8.1.0
See the option description on
See the option description on
See the option description on
See the option description on
true, false New in 8.1.1
See the option description on
.
true, false New in 8.1.0
See the option description on
.
.
.
.
.
626 Framework 8.1
Chapter 7: SIP Server Configuration Options Changes from Release 8.0 to Release 8.1
Table 111: Option Changes from Release 8.0 to Release 8.1 (Continued)
Option Name
sip-enable-rfc3263 sip-enable-tcp-keep-alive sip-filter-media sip-from-pass-through sip-iptakeover-monitoring sip-link-type
Option
Values
Type of
Change
Details
true, false New in 8.1.0
See the option description on
.
true, false New in 8.1.1
See the option description on
.
true, false New in 8.1.1
See the option description on
.
true, false New in 8.1.0
See the option description on
.
true, false New in 8.1.1
See the option description on
.
Integer Changed in
8.1.0
See the option description on
.
sip-max-uui-length sip-max-retry-listen sip-nic-address sip-nic-monitoring
Integer
Integer
New in 8.1.0
See the option description on
.
New in 8.1.0
See the option description on
.
String New in 8.1.1
See the option description on
.
true, false New in 8.1.1
See the option description on
.
sip-replaces-mode Integer sip-pass-from-parameters String sip-pass-refer-headers sip-release-call-on-disable-dn
String
New
New in 8.1.0
See the option description on
New in 8.1.0
See the option description on
.
true, false New in 8.1.1
See the option description on
.
.
.
sip-referred-by-support sip-referxfer-bye-timeout sip-rel-200-retransmit sip-remote-del-from-conf true, false New in 8.1.1
See the option description on
.
Integer New in 8.1.0
See the option description on
.
true, false New in 8.1.1
See the option description on
.
true, false New in 8.1.1
See the option description on
.
sip-resubscribe-on-nonotify sip-timer-c-support true, false New in 8.1.1
See the option description on
.
true, false New in 8.1.0
See the option description on
.
sip-treatment-dtmf-interruptable true, false New in 8.1.0
See the option description on
.
sip-vip-script-down String New in 8.1.1
See the option description on
.
sip-vip-script-up subscription-event-allowed
String
String
New in 8.1.1
See the option description on
.
New in 8.1.0
See the option description on
.
SIP Server—Deployment Guide 627
Chapter 7: SIP Server Configuration Options Changes from Release 8.0 to Release 8.1
Table 111: Option Changes from Release 8.0 to Release 8.1 (Continued)
Option Name
timeguard-reduction tlib-nic-monitoring use-propagated-call-type user-data-im-enabled userdata-map-all-calls true, false New in 8.1.0
See the option description on
.
userdata-map-invite-after-refer true, false New in 8.1.1
See the option description on
.
vip-state-change-timeout Integer New in 8.1.1
See the option description on
.
DN Level > AuthClient Section (New in 8.1.0)
password username
String
String
New in 8.1.0
New in 8.1.0
See the option description on
See the option description on
DN Level > TServer Section
.
.
after-call-divert-destination agent-reject-route-point auto-answer-after capacity-limit-inbound clamp-dtmf-enabled connect-nailedup-on-login contact-list disable-media-before-greeting disconnect-nailedup-timeout dr-oosp-transfer-enabled emergency-backup emergency-callback-plan
Option
Values
Integer
Type of
Change
Details
New in 8.1.1
See the option description on
true, false New in 8.1.1
See the option description on
.
String New in 8.1.0
See the option description on
.
true, false Moved to
DN-level
See the option description on
.
String
String
String true, false New in 8.1.1
See the option description on
.
true, false New in 8.1.1
See the option description on
.
String
String
New in 8.1.1
New in 8.1.1
See the option description on
See the option description on
.
.
true, false
Integer
String
String
New in 8.1.0
See the option description on
.
New in 8.1.1
See the option description on
.
Not documented previously
See the option description on
.
New in 8.1.1
New in 8.1.1
New in 8.1.0
New in 8.1.0
See the option description on
See the option description on
See the option description on
See the option description on
true, false New in 8.1.1
See the option description on
.
.
.
.
.
628 Framework 8.1
Chapter 7: SIP Server Configuration Options Changes from Release 8.0 to Release 8.1
Table 111: Option Changes from Release 8.0 to Release 8.1 (Continued)
Option Name Option
Values
String
Type of
Change
Details
New in 8.1.0
See the option description on
.
emergency-device enable-extension-headers enable-direct-pickup enforce-privacy enforce-p-asserted-identity force-register-disable-totag hg-busy-timeout
String New in 8.1.0
See the option description on
.
true, false New in 8.1.1
See the option description on
.
id
String hg-members String hg-noanswer-timeout Integer
New in 8.1.0
New in 8.1.0
New in 8.1.1
See the option description on
See the option description on
See the option description on
New
true, false New in 8.1.0
See the option description on
.
Integer New in 8.1.1
See the option description on
.
.
.
.
.
hg-preferred-site hg-queue-limit hg-queue-timeout hg-type
Integer
Integer
Integer fork
New in 8.1.1
New in 8.1.1
New in 8.1.1
New in 8.1.1
See the option description on
See the option description on
See the option description on
See the option description on
.
.
.
.
oos-error-check override-domain-oosp override-domain-refer-to override-domain-referred-by override-from-on-conf peer-proxy-contact predictive-timerb-enabled replace-uri-contact sca-preferred-site session-refresh-enforced shared-line shared-line-capacity true, false New in 8.1.1
See the option description on
.
String
String
String
String true, false true, false
Integer
New in 8.1.0
New in 8.1.1
New in 8.1.1
New in 8.1.1
New in 8.1.1
New in 8.1.1
New in 8.1.1
See the option description on
See the option description on
See the option description on
See the option description on
See the option description on
See the option description on
See the option description on
true, false New in 8.1.1
See the option description on
.
String New in 8.1.1
See the option description on
.
true, false New in 8.0.3
See the option description on
.
true, false New in 8.1.0
See the option description on
.
.
.
.
.
.
.
.
SIP Server—Deployment Guide 629
Chapter 7: SIP Server Configuration Options Changes from Release 8.0 to Release 8.1
Table 111: Option Changes from Release 8.0 to Release 8.1 (Continued)
Option Name
shared-line-number sip-accept-body sip-alert-info sip-alert-info-external sip-answer-mode sip-disable-greeting sip-enable-diversion sip-error-overflow sip-filter-media sip-from-pass-through sip-pass-xfer-params-enabled sip-proxy-uri-parameters sip-rel-200-retransmit sip-request-oos-timeout sip-to-pass-through user-data-im-enabled userdata-map-format voicemail-pattern-<n>
Option
Values
String
String
String
String
Auto true, false New in 8.1.0
See the option description on
.
true, false New in 8.1.0
See the option description on
.
String true, false true, false New in 8.1.0
See the option description on
.
true, false New in 8.1.0
See the option description on
.
true, false true, false sip-transfer-complete-message String sip-uri-params String
String
Type of
Change
Details
New in 8.1.1
See the option description on
.
New in 8.1.1
New in 8.1.0
New in 8.1.0
New in 8.1.0
New in 8.1.1
New in 8.1.1
New in 8.1.0
New in 8.1.1
New in 8.1.0
New in 8.1.0
New in 8.1.0
See the option description on
See the option description on
See the option description on
See the option description on
See the option description on
See the option description on
See the option description on
See the option description on
See the option description on
See the option description on
See the option description on
Integer New in 8.1.0
See the option description on
true, false New in 8.1.0
See the option description on
.
true, false Moved from
Applicationlevel
String
See the option description on
New in 8.1.1
See the option description on
.
.
.
.
.
.
.
.
.
.
.
.
.
630 Framework 8.1
Part
2
T-Server Common
Functions and Procedures
Part Two of this SIP Server Deployment Guide familiarizes the reader with
T-Server in general. It addresses architectural, functional, and procedural information common to all T-Servers.
The information in Part Two is divided into the following chapters:
•
Chapter 8, “T-Server Fundamentals,” on page 633 , describes T-Server, its
place in the Framework 7 architecture, T-Server redundancy, and multi-site issues. It does not, however, provide configuration and installation information.
•
Chapter 9, “Multi-Site Support,” on page 647 , describes the variations
available for T-Server implementations across geographical locations.
•
Chapter 10, “Common Configuration Options,” on page 707
, describes log configuration options common to all Genesys server applications.
•
Chapter 11, “T-Server Common Configuration Options,” on page 729 ,
describes configuration options common to all T-Server types including options for multi-site configuration.
New for All T-Servers in 8.1
The following general changes that have been implemented in the 8.1 release of T-Server:
•
T-Server no longer connects to applications that have disabled status in the configuration environment.
•
The default value of the background-processing
configuration option has been changed to true.
See “background-processing” on page 730
for details.
SIP Server—Deployment Guide 631
Part 2: T-Server Common Functions and Procedures New for All T-Servers in 8.1
•
T-Server now supports the Unresponsive Process Detection feature. The following configuration options enable this feature:
“heartbeat-period” on page 725
For more information, refer to the Framework 8.1 Management Layer
User’s Guide.
•
T-Server now supports IPv6. For more information, refer to the Framework
8.1 Deployment Guide.
•
T-Server now supports vSphere 4 Hypervisor.
•
T-Server now supports Acresso FLEXNet Publisher v11.9 license manager
Note:
• Configuration option changes common to all T-Servers are
described in “Changes from Release 8.0 to 8.1” on page 755 .
632 Framework 8.1
Chapter
8
T-Server Fundamentals
This chapter provides general information about T-Server features and functionality and about its configuration and installation.
This chapter is divided into the following sections:
Learning About T-Server, page 633
Advanced Disconnect Detection Protocol, page 639
Learning About T-Server
The Framework 8.1 Deployment Guide provides you with a high-level introduction to the role that T-Server plays in the Genesys Framework. If you have already looked through that guide, you may recall that T-Server is the most important component of the Framework Media Layer (the other two components are Load Distribution Server (LDS) and HA Proxy). The Media
Layer enables Genesys solutions to communicate with various media, including traditional telephony systems, voice over IP (VoIP), e-mail, and the
Web. This layer also provides the mechanism for distributing interaction-related business data, also referred to as attached data, within and across solutions.
Framework and Media Layer Architecture
illustrates the position Framework holds in a Genesys solution.
SIP Server—Deployment Guide 633
Chapter 8: T-Server Fundamentals Learning About T-Server
Agent
Desktop
IVR
Genesys
Framework
Genesys
Applications
Switch
Figure 46: Framework in a Genesys Solution
Moving a bit deeper,
presents the various layers of the Framework architecture.
Framework
Services Layer
Management
Layer
Configuration
Layer
Media Layer
(including
T-Server)
Routing
Services
Reporting
Services
Figure 47: The Media Layer in the Framework Architecture
T-Server is the heart of the Media Layer—translating the information of the media-device realm into information that Genesys solutions can use. It enables your contact center to handle the computer-based form of the interactions that arrive and it translates the information surrounding a customer contact into reportable and actionable data.
presents the generalized architecture of the Media Layer.
634 Framework 8.1
Chapter 8: T-Server Fundamentals Learning About T-Server
Internet
Media
Interaction
Server
Traditional
Telephony
VoIP
Telephony
T-Servers
T-Servers for
IP Solutions
SOLUTIONS
Figure 48: Media Layer Architecture
In addition to being the most important component of the Media Layer,
T-Server plays the most significant role in making information about telephony traffic and its data available to Framework as a whole.
One or more components in practically every solution are T-Server clients.
Solutions comprise a number of different Genesys software packages, from collections of components for various types of routing to those that allow for outbound dialing to still others. Framework in general, and T-Server in particular, enable these solutions to function in your enterprise.
T-Server has several typical clients: Stat Server, Interaction Concentrator,
Universal Routing Server, and agent desktop applications. T-Server gets the information it needs about the enterprise from Configuration Server.
Additionally, if you use the Management Layer, T-Server provides its ongoing status and various other log messages to server components of the
Management Layer (for instance, allowing you to set alarms).
T-Server Requests and Events
This section outlines the roles that T-Server plays in a contact center. While it is possible to describe roles for all T-Servers, at a detailed level, T-Server’s functionality depends on the hardware to which it is connected. (For example, when connected to a traditional switch, it performs CTI functions, but when connected to a VOIP-based telephony device, it controls IP traffic.) The CTI connection is only for the switch.
Details of T-Server Functionality
T-Server is a TCP/IP server that enables intelligent communication between media-specific protocols (such as the various CTI protocols, including CSTA and ASAI) and TCP/IP-based clients of T-Server. Applications that are clients
SIP Server—Deployment Guide 635
Chapter 8: T-Server Fundamentals Learning About T-Server to T-Server use the T-Library format to transmit requests to T-Server through a
TCP/IP socket. T-Server can then either translate those requests to CTI protocol for switch use or relay them directly to other TCP/IP clients.
T-Server performs three general functions in the contact center: Bridging,
Messaging, and Interaction Tracking.
Bridging
T-Server acts as a platform-independent interface between media devices and business applications. In the case of a telephony device, for instance, it receives messages from and sends commands to the telephony equipment using either CTI links provided by the switch manufacturer or interface protocols provided by telephony network vendors.
On the client-application end, T-Server offers three models (call model, agent model, and device model) unified for all switches. The core functionality (such as processing an inbound call, an agent login, or a call-forwarding request) translates into a unified application programming interface (API) called
T-Library, so that applications do not need to know what specific switch model they are dealing with. On the other hand, T-Library accommodates many functions that are unique to a specific switch, so that client applications are able to derive the maximum functionality offered by a particular switch.
Refer to the Genesys Events and Models Reference Manual for complete information on all T-Server events and call models and to the
TServer.Requests
portion of the Platform SDK 8.x .NET (or Java) API
Reference for technical details of T-Library functions.
Messaging
In addition to translating requests and events for the client application involved in an interaction, T-Server:
•
Provides a subscription mechanism that applications can use to receive notifications about interaction-related and non-interaction-related events within the contact center.
•
•
Broadcasts messages of major importance (such as a notification that the link is down) to all clients.
B
roadcasts messages originated by
a T-Server
client to other T-Server clients.
The subscription mechanism consists of two parts, the DN subscription and event-type masking. Applications must register for a DN or a set of DNs to receive notifications about all events that occur in association with each registered DN. For example, when two softphone applications are registered for the same DN, and the first application initiates a call from the DN,
T-Server notifies both applications that the call is initiated from the DN.
Client applications can also specify one or more types of events, and T-Server will filter out events of the non-specified types and only send events of the
636 Framework 8.1
Chapter 8: T-Server Fundamentals Learning About T-Server requested types. For example, if agent supervisors are interested in receiving agent-related events, such as
AgentLogin
and
AgentLogout,
they have to mask
EventAgentLogin
and
EventAgentLogout,
provided that a particular T-Server supports these events.
The combination of each client’s subscription for DNs and masking of event types defines what messages T-Server distributes to what client.
Interaction Tracking
T-Server maintains call information for the life of the call (or other
T-Server-supported media type) and enables client applications to attach user data to the call. Call information includes:
•
A unique identifier, connection ID, that T-Server assigns when creating the call.
•
Automatic Number Identification (
ANI
) and Dialed Number Identification
Service (
DNIS
), if reported by the CTI link.
•
User data that a client application (such as an Interactive Voice Response unit or Genesys Universal Routing Server) provides.
Difference and Likeness Across T-Servers
Although Figure 48 on page 635
(and other figures) depicts T-Server that works with telephony systems as a single product, this is a simplification.
Because almost every traditional telephony device has its own characteristics and communication protocols, Genesys makes different T-Servers for different telephony systems. (That means your T-Server will not work with another switch.) Thus, all T-Servers play a common role in the architecture, but their specific features differ from implementation to implementation, based on the media device in use.
Despite their switch-based differences, T-Servers for telephony systems are similar to one another in at least one important respect: they are all built with a certain amount of shared software code. This shared code is rolled into a single unit and is called T-Server Common Part (TSCP). TSCP is the central, common component for all T-Servers and has its own Release Note, which is accessible via a hyperlink from your T-Server’s Release Note.
Note:
This document separates common-code features based on TSCP into separate sections and chapters, such as the “T-Server Common
Configuration Options” chapter. These are the options for all
T-Servers that TSCP makes available for configuration.
T-Server Functional Steps During a Sample Call
The following example, Figure 49 , outlines some basic steps that T-Server
might take when a call arrives from outside the contact center. In this scenario,
SIP Server—Deployment Guide 637
Chapter 8: T-Server Fundamentals Learning About T-Server
T-Server starts tracking the call even before it is delivered to the agent.
T-Server then informs the selected agent that a call has arrived. When the switch delivers the call to the agent’s extension, T-Server presents account information, collected at an Interactive Voice Response (IVR) unit, to the agent at the agent desktop application.
1. Switch notifies
T-Server of call arrival. T-Server assigns ConnID.
2. Switch delivers a call to
IVR for automated service.
T-Server
6. T-Server notifies the agent application of the call.
7. T-Server delivers the call data to the desktop.
Agent Desktop
Application
3. IVR asks T-Server to attach the account number to the call.
4. IVR sends the call to an ACD queue.
IVR
5. ACD diverts the call to an agent DN.
Switch
Agent DN
Figure 49: Functional T-Server Steps
Step 1
When the call arrives at the switch, T-Server creates a call in its internal structure. T-Server assigns the call a unique identifier, connection ID.
Step 2
The switch delivers the call to an Interactive Voice Response (IVR) unit, which begins automated interactions with the caller.
Step 3
IVR acquires user information from the caller through prompts and requests
T-Server to attach that information to the call. T-Server updates the call with the user information.
Step 4
IVR sends the call to an ACD (Automated Call Distribution) queue.
Step 5
The ACD unit distributes the call to an available agent logged in to a particular
DN (directory number).
638 Framework 8.1
Chapter 8: T-Server Fundamentals Advanced Disconnect Detection Protocol
Step 6
T-Server notifies the agent desktop application that the call is ringing on the agent DN. The notification event contains call data including
ANI, DNIS,
and account information that the IVR has collected.
Step 7
The agent desktop application presents the account information, including the name of the person whose account this is, on the agent’s screen, so that the agent answering the call has all the relevant information.
These seven steps illustrate just a small part of T-Server’s bridging, messaging, and interaction-processing capabilities.
Advanced Disconnect Detection Protocol
Since the 6.0 release of T-Server, the Advanced Disconnect Detection Protocol
(ADDP) has replaced the Keep-Alive Protocol (KPL) as the method to detect failures for certain T-Server connections, including connections between two
T-Servers and between a T-Server and its clients.
Notes:
Starting with release 7.5, the KPL backward-compatibility feature is no longer supported.
ADDP applies only to connections between Genesys software components.
With ADDP, protocol activation and initialization is made on the client’s side and you can change these parameters. No additional messages are sent when there is existing activity over the connection. T-Server client applications and the remote T-Server (if any) must be listening to the socket and respond promptly to the polling signal for the connection to be preserved.
If you are going to enable ADDP, you must do it using the
,
and
configuration options.
When configuring a timeout, consider the following issues:
•
The configured timeout must be at least twice as long as the maximum network latency.
•
There may be an interval when T-Server does not check for network activity.
•
If the link connection fails but the client is not notified (for example, because the host is turned off, or because a network cable is unplugged), the maximum reaction time to a link-connection failure is equal to double the configured timeout plus the established network latency.
Also keep in mind that the T-Server receiving the polling signal may not respond immediately, and that a delay occurs after the polling signal, while the
SIP Server—Deployment Guide 639
Chapter 8: T-Server Fundamentals Redundant T-Servers response travels from one T-Server to another. If you do not account for these contingencies when configuring a timeout, the connection that ADDP is monitoring will be dropped periodically.
Redundant T-Servers
T-Servers can operate in a high-availability (HA) configuration, providing you with redundant systems. The basics of each T-Server’s redundant capabilities differ from T-Server to T-Server. One basic principle of redundant T-Servers is the standby redundancy type, which dictates how quickly a backup T-Server steps in when the primary T-Server goes down.
The Framework Management Layer currently supports two types of redundant configurations: warm standby
and hot standby
. All T-Servers offer the warm standby
redundancy type and, starting with release 7.1, the hot standby redundancy type is implemented in T-Servers for most types of switches. (See
.)
Note:
IVR Server and some Network T-Servers can be configured for load sharing or warm
or hot standby; however, they do not support any combination of these redundancy types.
Support for Hot Standby Redundancy in Various T-Servers
Use
to determine whether your T-Server supports the hot standby redundancy type. The table also indicates whether HA Proxy components are required for this support, and, if so, how many are required per pair of redundant T-Servers (or per link if so noted).
only summarizes hot standby
redundancy support in various
T-Servers. For detailed, up-to-date information on the subject, see the
Genesys
Supported Media Interfaces Reference Manual
.
Table 112: T-Server Support of the Hot Standby Redundancy Type
T-Server Type
Aastra MXONE CSTA I
Alcatel A4200/OXO
Alcatel A4400/OXE
Aspect ACD
Hot Standby
Supported
Yes
Yes
Yes
Yes
HA Proxy
Required
No
No
No
No
Number of HA
Proxy Components
—
—
—
—
640 Framework 8.1
Chapter 8: T-Server Fundamentals Redundant T-Servers
Table 112: T-Server Support of the Hot Standby Redundancy Type (Continued)
T-Server Type
Avaya Communication Manager
Avaya INDeX
Avaya TSAPI
Cisco UCCE
Cisco Unified Communications Manager
DataVoice Dharma
Digitro AXS/20
EADS Intecom
M6880
EADS Telecom M6500 eOn eQueue
Fujitsu F9600
Huawei C&C08
Huawei NGN
Mitel MiTAI
NEC NEAX/APEX
Nortel Communication Server 2000/2100
Nortel Communication Server 1000 with
SCCS/MLS
Philips Sopho iS3000
Radvision iContact
Samsung IP-PCX IAP
Siemens Hicom 300/HiPath 4000 CSTA I
Siemens HiPath 3000
Siemens HiPath 4000 CSTA III
Siemens HiPath DX
Yes
Yes
Yes
Yes
Yes
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Hot Standby
Supported
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
No
No
No
No d
—
No
No
No
No
No
No
No
No
No
Yes b
, No c
No
HA Proxy
Required
No a
No
No
No
No
No
No
Number of HA
Proxy Components
—
—
—
—
—
—
—
—
—
—
—
—
—
—
—
1 per link
—
—
—
—
—
1
—
—
SIP Server—Deployment Guide 641
Chapter 8: T-Server Fundamentals Redundant T-Servers
Table 112: T-Server Support of the Hot Standby Redundancy Type (Continued)
T-Server Type
SIP Server
Spectrum
Tadiran Coral
Teltronics 20-20
Tenovis Integral 33/55
AT&T
Concert
CRSP
DTAG
GenSpec
ISCP
IVR Server, using network configuration
KPN
MCI
NGSN
Network SIP Server
Sprint
Hot Standby
Supported
Yes
Yes
Yes
Yes
Yes
Network T-Servers e
No
HA Proxy
Required
No
No
No
Yes
No
No
No
No
No
No
Yes
No
No
No
No
No
—
—
—
—
—
—
—
—
—
—
—
—
SR3511
Stentor
No
No
—
—
Number of HA
Proxy Components
—
—
—
1
—
—
—
—
—
—
—
—
—
—
—
—
—
—
— a. With release 7.1, T-Server for Avaya Communication Manager no longer uses HA Proxy for its support of hot standby
. Earlier releases of this T-Server require two HA Proxies to support hot standby
.
b. For T-Server for Nortel Communication Server 2000/2100 in high-availability ( hot standby
) configuration,
Genesys recommends that you use link version SCAI14 or above with call-progress and noncontroller-released messages enabled. See the switch-specific information in Part 2 of this Deployment Guide for additional information on HA configurations.
642 Framework 8.1
Chapter 8: T-Server Fundamentals Multi-Site Support c. Starting with release 7.5, T-Server for Nortel Communication Server 2000/2100 supports HA without HA
Proxy when operating in Dual CTI Links mode. d.
Starting with release 6.5.3, T-Server for Philips Sopho iS3000 supports HA both with and without HA
Proxy.
e. Although they do not support high availability per se, Network T-Servers do support a load-sharing schema.
Multi-Site Support
Multi-site configuration implies the existence of two or more switches that belong to the same enterprise or service provider, and that share the Genesys
Configuration Database. (In some cases this may include isolated partitions on a given switch served by different T-Servers.) The main goal of T-Server support for multi-site operations is to maintain critical information about a call as it travels from one switch to another.
For instructions on installing and configuring a multi-site environment, including information on the Inter Server Call Control (ISCC) features, please
see Chapter 9, “Multi-Site Support,” on page 647 .
Agent Reservation
T-Server provides support for clients to invoke the agent reservation function,
TReserveAgent().
This function allows a server application that is a client of
T-Server to reserve a DN along with an agent, a
Place,
or both, so that no other T-Server client can route calls to it during a specified reservation
interval. Alternatively, when clients use the ISCC feature (see “ISCC Call Data
), they can use an agent reservation embedded in an ISCC request. (To do so, clients have to specify a certain
Extensions
attribute in an ISCC request when initiating an ISCC transaction. See page 656
for the list of ISCC requests.)
The reservation does not currently prevent the reserved objects from receiving direct calls or calls distributed from ACD Queues; agent reservation is intended as a way of synchronizing the operation of several clients. See
RequestReserveAgent
in the Platform SDK 8.x .NET (or Java) API Reference for more details on this function from the client’s point of view.
In addition to invoking the
TReserveAgent
function, you can customize the
Agent Reservation feature by configuring options in the T-Server
Application
object. See“agent-reservation Section” on page 738 in the “T-Server Common
Configuration Options” chapter for more details.
Starting with version 8.1, T-Server supports Agent Reservation failure optimization, to ensure that only agent reservation requests of the highest priority are collected. T-Server responds immediately with the
EventError message to existing or new reservation requests of a lower priority while
SIP Server—Deployment Guide 643
Chapter 8: T-Server Fundamentals Client Connections collecting the agent reservation requests of the highest priority only. This functionality is controlled with the collect-lower-priority-requests
configuration option (see page 738 ).
Client Connections
The number of connections T-Server and SIP Server can accept from its clients depend on the operating system that T-Server runs.
lists the number of client connections that T-Server supports for
specific operating systems. Table 114 lists the number of client connections
that SIP Server supports for Windows and Linux operating systems.
Table 113: Number of T-Server’s Client Connections
Operating System
AIX 32-bit mode (versions 5.3)
AIX 64-bit mode (versions 5.3, 6.1, 7.1)
HP-UX 32-bit mode (versions 11.11)
HP-UX 64-bit mode
(versions 11.11, 11i v2, 11i v3)
HP-UX Itanium (version 11i v3)
Linux 32-bit mode (version 5.0)
Linux 64-bit mode (version 5.0)
Solaris 32-bit mode (version 9)
Solaris 64-bit mode (versions 9, 10)
Windows Server 2003, 2008
Number of Connections
32767
32767
2048
2048
2048
32768
32768
4096
65536
4096
644 Framework 8.1
Chapter 8: T-Server Fundamentals Client Connections
Table 114: Number of SIP Server’s Client Connections
Operating System
Linux 32-bit mode
(version RHEL 5.0)
Number of Connections
10000 registered agents (aggregated
T-Library client connection) or
4,000 registered agents (direct
T-Library connections)
Linux 64-bit mode
(version RHEL 5.0)
15,000 registered agents (direct or aggregated T-Library client connections)
Windows Server 2003, 2008 32-bit mode 10000 registered agents (aggregated
T-Library client connections) or
4,000 registered agents (direct
T-Library connections)
Windows 2008 64-bit 15,000 registered agents (direct or aggregated T-Library client connections)
SIP Server—Deployment Guide 645
Chapter 8: T-Server Fundamentals Client Connections
646 Framework 8.1
Chapter
9
Multi-Site Support
This chapter contains general information about multi-site environments, as well as information on deploying a multi-site environment for your T-Server.
This chapter is divided into the following sections:
Multi-Site Fundamentals, page 648
ISCC Call Data Transfer Service, page 649
ISCC/Call Overflow Feature, page 668
Number Translation Feature, page 672
Network Attended Transfer/Conference Feature, page 681
Event Propagation Feature, page 683
ISCC Transaction Monitoring Feature, page 691
Configuring Multi-Site Support, page 691
Note:
Each switch/T-Server combination offers different multi-site options.
For details describing your specific switch/T-Server environment,
refer to Chapter 11, “T-Server Common Configuration Options,” on page 729
.
The following instructions apply to both local and remote switches and
T-Servers. Because different vendor switches can be installed at the local and remote locations, this chapter covers several, but not all, possible configurations. To help determine which sections of this chapter apply to your
situation, refer to Table 115 on page 664
SIP Server—Deployment Guide 647
Chapter 9: Multi-Site Support Multi-Site Fundamentals
Multi-Site Fundamentals
A multi-site configuration has two or more switches that belong to the same enterprise or service provider and that share the Genesys Configuration
Database. (In some cases, this may include isolated partitions on a given switch served by different T-Servers.) The main goal of T-Server support for multi-site operations is to maintain critical information about a call as it travels from one switch to another.
T-Server supports multi-site operations using its Inter Server Call Control
(ISCC; formerly called External Routing), which supports the following functions:
•
Call matching—To link instances of a call distributed across multiple sites and to re-attach essential data associated with the call (
ConnID, UserData,
CallType,
and
CallHistory
). The following T-Server features support this capability:
ISCC Call Data Transfer Service (active external routing)—when requested by a T-Server client by specifying the desired destination in the location parameter, and also with various ISCC strategies performed by direct dial or by using the Transfer Connect Service. See
“ISCC Transaction Types” on page 656
.
Inter Server Call Control/Call Overflow (ISCC/COF) feature (passive external routing)—applicable when calls are overflowed to another site
either directly or manually (see page 668
).
Number Translation feature (see
).
Network Attended Transfer/Conference (NAT/C) feature (see
).
Note:
When ISCC detects call instance reappearance on a given site, the call is assigned a unique
ConnID
and the user data is synchronized with the previous call instances. This ensures that
ConnID s assigned to different instances of the same call on a given site are unique.
•
Call data synchronization between associated call instances (ISCC
Event Propagation)—To provide the most current data to call instances residing on remote T-Servers. The following T-Server features support this capability:
User Data propagation (see page 683 )
Party Events propagation (see page 684 )
Note:
ISCC automatically detects topology loops and prevents continuous updates.
648 Framework 8.1
Chapter 9: Multi-Site Support ISCC Call Data Transfer Service
Note:
In distributed networks, Genesys recommends using call flows that prevent call topology loops and multiple reappearances of the same call instance. This approach ensures that all T-Servers involved with the call report the same
ConnID
, and also optimizes telephony trunk allocation by preventing trunk tromboning.
The T-Server configuration contains information about other T-Servers with which it will communicate. T-Server uses this information to connect with the other T-Servers. During this “handshake” process, T-Servers exchange information about the following parameters:
•
Protocol type
•
Switch type
•
Server name
•
Location name (switch name)
•
T-Server role (primary or backup)
To complete the handshake process, T-Servers exchange messages about the current condition of the links to their switches. After the handshake process is complete, T-Server is ready to support a multi-site operation.
ISCC Call Data Transfer Service
Because ISCC supports active external routing, T-Servers that serve different switches (usually on different sites) can exchange call data when a call is passed from one switch to another. With this functionality, T-Server provides its clients with the following additional information about each call received from another switch:
•
The connection identifier of the call (attribute
ConnID
).
•
Updates to user data attached to the call at the previous site (attribute
UserData
).
•
The call type of the call (attribute
CallType
)—In multi-site environments the
CallType
of the call may be different for each of its different legs. For example, one T-Server may report a call as an
Outbound
or
Consult
call, but on the receiving end this call may be reported as
Inbound.
•
The call history (attribute
CallHistory
)—Information about transferring/routing of the call through a multi-site contact center network.
Note:
Load-sharing IVR Servers and Network T-Servers cannot be designated as the destination location for ISCC, except when cast-type
is set to dnis-pool.
Consult the Universal Routing 8.1
Deployment Guide for specific configuration details.
SIP Server—Deployment Guide 649
Chapter 9: Multi-Site Support ISCC Call Data Transfer Service
shows the steps that occur during a typical external routing (ISCC) transaction. Note that the location where a call is initially processed is called the origination location, and the location to which the call is passed is called the destination location.
Origination
Location
Origination Switch
6. Call
Passing
Destination Switch
7. Alerting event processing
5. Telephony
Request to move a call to a destination location
T-Server
1. T-Library request for ISCC routing
T-Server
Client
10. EventRemote-
Connection -
Success/Failure
2. Routing service availability request
4. Routing service availability response
9. Processing result notification
T-Server
Destination
Location
3. Routing service availability check
8. Call arrival processing
Figure 50: Steps in the ISCC Process
ISCC Call Flows
The following section identifies the steps (shown in
) that occur during an ISCC transfer of a call.
Step 1
A client connected to the T-Server at the origination location requests this
T-Server to pass a call with call data to another location. For this purpose, the client must specify the location
parameter (Attribute
Location
) when calling a corresponding T-Library function. ISCC processes the following T-Library requests:
•
TInitiateConference
•
TInitiateTransfer
•
TMakeCall
•
TMuteTransfer
•
TRouteCall
•
TSingleStepTransfer
650 Framework 8.1
Chapter 9: Multi-Site Support ISCC Call Data Transfer Service
Step 2
Upon receiving a client’s request, the origination T-Server checks that the:
1. Connection to the destination T-Server is configured in the origination
T-Server
Properties
dialog box.
2. The connection to the destination T-Server is active.
3. The destination T-Server is connected to its link.
4. The origination T-Server is connected to its link.
If these four conditions are met, the origination T-Server determines the transaction type that will be used for passing call data to another location in this transaction. The following possibilities exist:
•
The client can request what ISCC transaction type (or simply transaction
type) to use by specifying an appropriate key-value pair in the
Extensions attribute of the request. The key-value pair must have a key equal to iscc-xaction-type
and either an integer value as specified in the
TXRouteType
enumeration (see the Platform SDK 8.x .NET (or Java) API
Reference) or a string value equal to one of the following: default, route, direct
(or direct-callid
), direct-network-callid, direct-notoken, direct-ani, direct-uui, direct-digits, reroute, dnis-pool, pullback, or route-uui.
•
If the client does not specify the transaction type in the request or specifies the default
transaction type, T-Server checks the Switch configuration for the transaction type configured in the
Access Code
(or
Default Access
Code
) properties:
If the
Route Type
property of the
Access Code
is set to any value other than default,
T-Server uses the specified value as the transaction type.
If the
Route Type
property of the
Access Code
is set to the default value, T-Server uses the first value from the list specified in the
configuration option configured for the destination T-Server.
If no value has been specified for the cast-type
value of route
is used as the transaction type.
Note:
For more information on Access Codes and Default Access Code,
see “Switches and Access Codes” on page 693 .
After the origination T-Server determines the requested transaction type, it determines if the destination T-Server supports this transaction type.
You must list the transaction types T-Server supports in the
configuration option.
The origination T-Server issues a request for routing service availability and sends it to the destination T-Server. The T-Server request contains data that should be passed along with the call to the destination location. This data includes the transaction type,
ConnID, UserData, CallType,
and
CallHistory.
SIP Server—Deployment Guide 651
Chapter 9: Multi-Site Support ISCC Call Data Transfer Service
The timer specified by the
configuration option is set when the
origination T-Server sends the request. If either the specified timeout expires or the call is abandoned before the origination T-Server receives a response from the destination T-Server, the operation is considered failed. In this scenario, the origination T-Server:
1. Generates a request to the destination T-Server to cancel the request for routing service.
2. Sends
EventError
to the client that requested the service.
3. Deletes information about the request.
Step 3
The destination T-Server receives the request for routing service availability and checks the requested type of routing. Depending on the ISCC transaction type, it stores the request information and, when appropriate, allocates access resources for the coming call. For example, an External Routing Point is allocated when the transaction type is route,
and an Access Resource of type dnis
is allocated when the transaction type is dnis-pool
.
Note:
The
and
configuration options determine how resources are allocated. For
option descriptions, refer to Chapter 11, “T-Server Common
Configuration Options,” on page 729 for option descriptions.
If resources are unavailable, the request is queued at the destination location until a resource is free or the origination T-Server cancels the request. If the request is canceled, the destination T-Server deletes all information about the request.
If resources are unavailable because of incorrect configuration, the destination
T-Server returns an error event to the origination T-Server.
Step 4
If resources are available, the destination T-Server generates a positive response and the timer is started for the interval specified by the
configuration option of the destination T-Server.
Step 5
If the origination T-Server receives a negative response, it sends an
EventError message to the client and clears all data about the request.
If the origination T-Server receives the confirmation about routing service availability, it processes the client’s request and sends a corresponding message to the switch. The timer on the origination T-Server is also started for
the interval specified by the timeout
configuration option of the destination
T-Server.
652 Framework 8.1
Chapter 9: Multi-Site Support ISCC Call Data Transfer Service
Step 6
The origination switch processes the T-Server request and passes the call to the destination switch.
Step 7
If the call arrives at the destination switch, the switch generates an alerting event.
The destination T-Server waits for the call no longer than the interval specified by the timeout configured on the destination T-Server. If the call is not received at the destination location within this interval, the destination
T-Server issues a failure notification to the origination T-Server, deletes all data about the request, and, when appropriate, frees the resources previously allocated for the request.
If either the specified timeout expires or the call is abandoned before the origination T-Server receives a response from the destination T-Server, the operation is considered failed. In this case, the origination T-Server:
1. Generates a request to the destination T-Server to cancel the request for routing service.
2. Responds to the client that requested the service in one of the following ways:
If the origination T-Server has already sent a response to the request the client sent in Step 1, the origination T-Server supplements its response with
EventRemoteConnectionFailed
.
If the origination T-Server has not yet sent a response to the client, the origination T-Server sends
EventError
.
3. Deletes information about the request.
Step 8
If the destination T-Server matches the arrived call, it updates the
ConnID,
UserData, CallType,
and
CallHistory
attributes with the data received in the request for routing service availability. The connection ID is updated as follows:
The arrived call is assigned the
ConnID
that is specified in the request for routing service availability, but only if this
ConnID
does not coincide with the
ConnID
of a call that has existed at the destination site. If two such
ConnID s are identical, the arrived call is assigned a new unique
ConnID
.
For direct-*
transaction types (where the asterisk stands for a callid
, uui
, ani
, or digits
extension), the call reaches the destination DN directly.
For the transaction types route and
route-uui
, the call first arrives at an
External Routing Point from which it is routed to the destination DN. The call info is updated when the call reaches the External Routing Point. An External
Routing Point is considered free when the first alerting event (
EventQueued
or
EventRouteRequest
) is distributed.
SIP Server—Deployment Guide 653
Chapter 9: Multi-Site Support ISCC Call Data Transfer Service
Please keep the following issues in mind when using the ISCC feature:
•
If routing from a dedicated External Routing Point to the destination DN fails, T-Server considers the transaction failed. However, the
ConnID,
UserData, CallType,
and
CallHistory
attributes are updated. Then,
T-Server attempts to route the call to one of the Default DNs configured for this External Routing Point.
•
If the destination T-Server did not receive a request for routing service availability, but a call arrives at an External Routing Point, T-Server considers the call to be unexpected and routes the call to the DN specified by the
configuration option. When no alternative
targets are defined, the call remains at the External Routing Point until diverted by the switch or abandoned by the caller.
For reroute
and pullback
transaction types, the call returns to the network location. For the dnis-pool
transaction type, the call reaches the destination
DN directly.
Step 9
If, in Step 8, the call does not arrive within the configured timeout, or the transaction fails, the destination T-Server sends a notification of failure to the origination T-Server.
Otherwise, the destination T-Server notifies the origination T-Server that the routing service was successful and deletes all information about the request.
Step 10
The origination T-Server notifies the client that the routing service was successful (or failed) and deletes all information about the request.
Client-Controlled ISCC Call Flow
The following section identifies the steps that occur during a client-controlled
ISCC transfer of a call.
Step 1
A client, such as Universal Routing Server (URS), that is connected to the
T-Server at the origination location detects a call to be delivered to another destination location.
Step 2
The client chooses a destination location and the target DN for the call. Then, it sends the
TGetAccessNumber request to the destination T-Server for routing service availability, indicating the target DN and other call context (
ConnID,
UserData,
and
CallHistory
attributes).
654 Framework 8.1
Chapter 9: Multi-Site Support ISCC Call Data Transfer Service
Step 3
The destination T-Server receives the request for routing service availability.
Depending on the ISCC transaction type, it stores the request information, including the call context. When appropriate, it allocates access resources for the coming call, such as External Routing Point.
If resources are unavailable, the request is queued at the destination T-Server until an appropriate ISCC resource is free or the client cancels the request. If the request is canceled, the destination T-Server deletes all information about the request.
If resources are unavailable because of incorrect configuration, the destination
T-Server returns an
EventError
message to the client.
Step 4
The destination T-Server replies to the client with the
EventAnswerAccessNumber
message, which contains the allocated ISCC resource.
Step 5
The client requests that the origination T-Server delivers the call to the destination location using the allocated access resource.
Step 6
The origination T-Server receives and processes the client’s request, and then sends a corresponding message to the switch.
Step 7
The call arrives at the destination switch and is reported to the destination
T-Server via CTI. The call is matched by means of ISCC, based on the specified cast-type
setting and allocated resource, and then the call is assigned a requested call context (such as
ConnID
or call data). Upon successful transaction completion, the destination T-Server notifies the client by sending
EventRemoteConnectionSuccess.
The destination T-Server waits for the call no longer than the interval specified by the timeout that is configured on the destination T-Server. If the call is not received at the destination location within this interval, the destination
T-Server issues a failure notification to the client by sending
EventRemoteConnectionFailed,
deletes all data about the request, and, when appropriate, frees the resources previously allocated for the request.
The destination T-Server notifies the client whether the routing service succeeded or failed by sending either the
EventRemoteConnectionSuccess
or
EventRemoteConnectionFailure,
respectively.
SIP Server—Deployment Guide 655
Chapter 9: Multi-Site Support ISCC Call Data Transfer Service
ISCC Transaction Types
As switches of different types provide calls with different sets of information parameters, a single mechanism for passing call data between the switches is not feasible in some cases. Therefore, the ISCC feature supports a number of mechanisms for passing call data along with calls between locations. This section describes ISCC transaction type principles, identifies which transaction types are supported for each T-Server, and defines each transaction type
(beginning with “direct-ani” on page 657
).
It is important to distinguish the two roles that T-Servers play in an external routing (ISCC) transaction—namely origination T-Server and destination
T-Server.
•
The origination T-Server initiates an ISCC transaction. It prepares to send the call to another T-Server and coordinates the process.
•
The destination T-Server receives call data from an origination T-Server and matches this data to a call that will arrive at some time in the future.
The distinction between these roles is important because the range of telephony-hardware functionality often requires T-Servers to support two entirely different sets of ISCC transactions based on which of the two roles they play. For instance, it is very common for a particular T-Server to support many types of ISCC transactions when it takes on the origination role, but fewer when it takes on the role of a destination T-Server.
The ISCC transaction type reroute
is a good example. Most T-Servers support
Reroute
as origination T-Servers, but very few support
Reroute
as destination
T-Servers.
656
Determining and Configuring Transaction Type
Support
You can find descriptions of these transaction types starting on page 657
. Use
Table 115 on page 664 to identify the transaction types your destination
T-Server supports. A blank table cell indicates that T-Server does not support a certain transaction type.
You can configure the transaction types specific to your T-Server as values of the
configuration option specified in the ISCC configuration section
extrouter
ISCC Transaction Type General Principles
Generally, since most of the ISCC implementation is done at the T-Server
Common Part (TSCP) code level, all T-Servers support certain ISCC transaction types. Any T-Server can act as the origination T-Server for the following transaction types:
•
direct-ani
,
•
direct-notoken
Framework 8.1
Chapter 9: Multi-Site Support ISCC Call Data Transfer Service
•
dnis-pool
•
pullback
•
reroute
,
•
route
(aliased as route-notoken
), the default transaction type,
The following transaction types are unevenly supported for both the origination and destination T-Server roles:
•
direct-callid
(aliased as direct
),
•
direct-digits
(reserved for Genesys Engineering)
•
direct-network-callid
,
•
direct-uui
,
•
route-uui
,
The
reroute
and pullback
transaction types are supported only for selected
T-Servers in the destination role. However, if you implement this support, other transaction types require additional configuration and testing—even those that would normally be supported by default.
direct-ani
With the transaction type direct-ani
, the
ANI
call attribute is taken as the parameter for call matching. Properly configured switches and trunks can keep the
ANI
attribute when a call is transferred over the network. T-Server can use this network feature for call matching.
Warning!
Depending on the switch platform, it may be possible to inherit the
ANI
attribute after routing a call to a remote destination, and after performing a single-step transfer and other telephone actions.
However, ISCC only works properly in scenarios where the
ANI attribute on the destination T-Server is represented by exactly the same digit string as on the origination T-Server.
Typically, the
ANI
attribute represents the original call identifier
(customer phone number), which guarantees that the attribute remains unique. However, you can use the non-unique-ani resource type to block ISCC from matching calls based on an ANI
that is known to be non-unique. (See “Configuring access resources for non-unique ANI” on page 703
for details.)
direct-callid
With the transaction type direct-callid,
the call reaches the destination DN directly from another location, and the
CallID
of the call is taken as the attribute for call matching. When a call arrives at the final destination, the destination T-Server identifies its
CallID,
and updates the call info if the
CallID
matches.
SIP Server—Deployment Guide 657
Chapter 9: Multi-Site Support ISCC Call Data Transfer Service
Use this transaction type when the destination switch has the capability to assign to an incoming call the same network-wide unique
CallID
that the origination switch has already assigned to that call.
Notes:
The direct-callid
transaction type is used only in conjunction with the
TRouteCall
and
TSingleStepTransfer
function calls. It is applied only to the call that is in progress, and does not apply to functions that involve in the creation of a new call, such as
TMakeCall
.
For T-Server for Nortel Communication Server 2000/2100, the direct-callid
transaction type is also applied to the
TMuteTransfer function.
direct-network-callid
With the transaction type direct-network-callid
, the call reaches the destination DN directly from another location, and the
NetworkCallID
of the call is taken as the attribute for call matching. When a call arrives at the final destination, the destination T-Server identifies its
NetworkCallID
, and updates the call info if the
NetworkCallID
matches.
Use this transaction type when the destination switch has the capability to assign to an incoming call the same network-wide unique
NetworkCallID
that the origination switch has already assigned to that call.
Note:
To support this transaction type, you must configure
Target Type
and
ISCC Protocol Parameters
fields of the corresponding
Switch Access
Code
in the Configuration Layer.
direct-uui
With the transaction type direct-uui,
so-called user-to-user information (UUI) is taken as the attribute for call matching. Some switches make it possible to send a small data packet along with a call. T-Server can use this data to recognize a call passed from one switch to another. The destination T-Server generates a local unique value for
UUI,
and then notifies the origination
T-Server .
The origination T-Server uses a provided value to mark the call coming from the origination location. The destination T-Server receives a call and checks whether it is marked with an exact
UUI
value. If so, the call is considered to be matched.
On the Avaya Communication Manager and the Aspect ACD, UUI is referred to as “user-to-user information.” On the Siemens Hicom 300 switch with
658 Framework 8.1
Chapter 9: Multi-Site Support ISCC Call Data Transfer Service
CallBridge, UUI is referred to as “Private User Data.” On the Alcatel
A4400/OXE switch, UUI is referred to as “correlator data.”
Note:
To support this transaction type, you must configure your switches to pass the UUI provided by your T-Server. You must also ensure that the trunks involved do not drop this data.
direct-notoken
With the transaction type direct-notoken
, T-Server expects a call to arrive from another location to the destination DN specified in the request for routing service availability. When a call reaches the specified DN, T-Server processes the call as the expected externally-routed call.
Notes:
This matching criterion is weak because any call that reaches the specified DN is considered to be the expected call. Genesys recommends that you use this transaction type only in a contact center subdivision that can only be reached from within the contact center (such as the second line of support, which customers cannot contact directly).
When using direct
transaction types, Network T-Servers and load-sharing IVR Servers are not meant to act as destination
T-Servers for call routing. Using Network T-Server with these transaction types requires special architecture.
dnis-pool
With the dnis-pool
transaction type, T-Server reserves one of its DNIS access resources and waits for the call that has the same
DNIS
attribute as the name of the reserved DNIS access resource.
If the arrived call is matched successfully, the destination T-Server may update the value of the
DNIS
attribute of the call (along with
ConnID, UserData,
CallType,
and
CallHistory
) with the value of the
DNIS
attribute of the original call. This occurs when the value of the
DNIS
attribute of the original call is specified as a value of the key-value pair
_ISCC_TRACKING_NUMBER_
in the
Extensions
attribute of the original client request.
The DNIS matching can be based on any number of digits out of all the digits that comprise the
DNIS
attribute. The number of digits that T-Server should use for DNIS matching is specified for the destination switch as the
ISCC Protocol
Parameters
property of the Switch Access Code. The value syntax should be as follows: dnis-tail=<number-of-digits>
For example, if this property is set to the dnis-tail=7
value, ISCC matches only the last seven digits of a
DNIS.
SIP Server—Deployment Guide 659
Chapter 9: Multi-Site Support ISCC Call Data Transfer Service
You must configure DNIS access resources in the switch; otherwise, ISCC fails to use this transaction type and sends
EventError
in response to the client application request.
Note:
The dnis-pool
transaction type is typically used for networks that employ a “behind the SCP” architecture, such as network IVR.
Network T-Server for GenSpec and IServer are two examples of this, but other Network T-Servers might also be used in this architecture.
In Load-Balancing Mode
When T-Server uses load balancing for call routing with the dnis-pool transaction type, the following processes occur:
1. A client of the origination T-Server sends a request to pass a call to the location with a DNIS access resource specified in the key-value pair iscc-selected-dnis.
2. The origination T-Server distributes the request for a routing service to all destination T-Servers.
3. The destination T-Servers receive the request and check that the specified
DNIS is not being used by another routing service request.
4. The origination T-Server expects to receive a positive response from each destination T-Server. If the origination T-Server receives a negative response from at least one T-Server, it sends an
EventError
to the client and clears all data about the request. If the origination T-Server receives the confirmation about routing service availability from all destination
T-Servers, it processes the client’s request and sends a corresponding message to the switch.
5. The origination switch processes the T-Server request and passes the call to the destination switch.
6. The call arrives at the destination switch, which generates an alerting event to one of the corresponding load-balanced destination T-Servers.
7. That destination T-Server processes the call and notifies the origination
T-Server that the routing service was successful and deletes all information about the request.
8. The origination T-Server sends a routing service request cancellation to all other destination T-Servers.
9. The origination T-Server notifies the client that the routing service has been successful and deletes all information about the request.
pullback
Pullback
is used in the following scenario, for those T-Servers that support it:
1. A call arrives at Site A served by a Network T-Server.
660 Framework 8.1
Chapter 9: Multi-Site Support ISCC Call Data Transfer Service
2. At Site A, a Network T-Server client requests to pass the call by means of
ISCC routing to Site B served by a premise T-Server. Any transaction type except reroute
or pullback
can be specified in this request.
3. The call arrives at Site B and is either answered by an agent or delivered to a routing point.
4. A client of the premise T-Server at Site B sends a
TRouteCall or
TSingleStepTransfer
request to transfer the call to the network.
5. The Site B premise T-Server notifies the Network T-Server about this request.
6. The Network T-Server receives the notification and issues an
EventRouteRequest
to obtain a new destination.
7. After receiving the new destination information, the Network T-Server disconnects the call from its current premise location at Site B and attempts to route the call to the new destination.
8. The Site B premise T-Server stops tracking the call, which has disconnected from the premise’s agent DN or routing point and is delivered to the network.
9. The Network T-Server completes routing the call to its new destination.
Note:
The transaction type pullback
can only be used between SIP Servers or to return a call from a premise T-Server to the Network T-Server that serves the site from which the call was previously transferred.
reroute
Reroute
is used in the following scenario, for those T-Servers that support it:
1. A call arrives at Site A served by a Network T-Server.
2. At Site A, a Network T-Server client requests to pass the call by means of
ISCC to Site B served by a premise T-Server. Any transaction type except reroute
or pullback
can be specified in this request.
3. An agent at Site B answers the call.
4. A client of the premise T-Server at Site B sends a
TSingleStepTransfer
or
TRouteCall
request to transfer the call elsewhere (to a PSTN, to an agent, or to a routing point).
5. The Site B premise T-Server notifies the Network T-Server about this request and releases the call leg that resides at the agent’s phone (using
TReleaseCall
) or at the Routing Point (using
TRouteCall
with the parameter
RouteTypeCallDisconnect
).
6. The Network T-Server receives the notification and reroutes the call to the requested destination by sending
EventRouteRequest
and attaching the call’s user data.
SIP Server—Deployment Guide 661
Chapter 9: Multi-Site Support ISCC Call Data Transfer Service
Notes:
The transaction type reroute
can only be used to return a call from a premise T-Server to the Network T-Server that serves the site from which the call was previously transferred.
To perform multi-site operations that are initiated with
TRouteCall and for which the reroute
transaction type is requested, the origination T-Server must support the
RouteTypeCallDisconnect subtype of
TRouteCall
.
route
With the transaction type route
(aliased as route-notoken
), a call from the origination location reaches a dedicated External Routing Point, and from there, it is routed to a destination DN.
To control configured External Routing Points, T-Server must register these
DNs with the switch. Failure to register implies that the External Routing Point is not available for ISCC purposes. Client applications can register External
Routing Points via T-Server for monitoring purposes only.
Point-to-Point (One-to-One)
In the Point-to-Point access mode, only one trunk line is used to access an
External Routing Point (for example, VDN, CDN) at the destination site. See
.
Trunk Line 1
Trunk Line 2
Trunk Line 3
External Routing Point 1
External Routing Point 2
External Routing Point 3
Figure 51: Point-to-Point Trunk Configuration
Note:
Dedicated DNs of the
External Routing Point
type must be configured
in a switch. See “Configuring Multi-Site Support” on page 691
.
Multiple-to-Point (Multiple-to-One)
In the Multiple-to-Point access mode, trunk lines are assigned to the destination switch’s trunk group, from which calls are routed to the final
662 Framework 8.1
Chapter 9: Multi-Site Support ISCC Call Data Transfer Service
Trunk Line 1
Trunk Line 2
External Routing Point
Trunk Line 3
Figure 52: Multiple-to-Point Trunk Configuration
With this configuration, all calls reach the same External Routing Point. The
DNIS
attribute of a specific call differs from that of other calls and uniquely identifies the trunk from which the call arrived.
Note:
To switch to this operating mode, you must configure the route-dn
configuration option for T-Server.
route-uui
The route-uui transaction type employs the dedicated External Routing Point feature of the route
transaction type (
page 662 ) and the UUI matching feature
of the direct-uui
transaction type ( page 658 ). This transaction type
accommodates those switches that require a designated External Routing Point even though they use UUI for tracking.
Note:
To support this transaction type, you must configure your switches to pass the UUI provided by your T-Server. You must also ensure that the trunks involved do not drop this data.
T-Server Transaction Type Support
shows which transaction types are supported by a specific T-Server.
Use this table to determine the transaction types that are available for use with
your T-Server. This applies both to the cast-type
configuration options for your T-Server, and to any client-designated route-type requests specified for transfers of calls. A blank table cell indicates that T-Server does not support a certain transaction type.
SIP Server—Deployment Guide 663
Chapter 9: Multi-Site Support ISCC Call Data Transfer Service
Table 115: T-Server Support of Transaction Types
T-Server
Type
Aastra
MXONE
CSTA I
Alcatel
A4200/OXO
Alcatel
A4400/OXE
Yes
Yes
Aspect ACD
Avaya
Communica- tion Manager
Yes
Yes
Avaya INDeX Yes
Avaya TSAPI Yes
Yes
Yes
Cisco UCCE
Cisco Unified
Communica- tions Manager
DataVoice
Dharma
Digitro
AXS/20
Yes
Yes
EADS Intecom
M6880
EADS
Telecom
M6500 eOn eQueue
Fujitsu F9600
Yes
Yes
Yes
Yes
Transaction Type route one-toone multipleto-one reroute
Yes
directcallid
directuui / routeuui directnotoken directani directdigits directnetworkcallid
Yes Yes
dnispool pullback
Yes
Yes
Yes a,b,c
Yes c
Yes
Yes
Yes
Yes
Yes
Yes
Yes d
Yes
Yes
Yes
Yes f
Yes
Yes
Yes Yes
Yes Yes b
Yes Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes e
664 Framework 8.1
Chapter 9: Multi-Site Support ISCC Call Data Transfer Service
Table 115: T-Server Support of Transaction Types (Continued)
T-Server
Type
Philips Sopho iS3000
Radvision iContact
Samsung
IP-PCX IAP
Siemens
Hicom
300/HiPath
4000 CSTA I
Siemens
HiPath 3000
Siemens
HiPath 4000
CSTA III
Huawei
C&C08
Huawei NGN
Mitel MiTAI
NEC
NEAX/APEX
Nortel
Communica- tion Server
2000/2100
Nortel
Communica- tion Server
1000 with
SCCS/MLS
Transaction Type route one-toone multipleto-one reroute
Yes
directcallid directuui / routeuui directnotoken directani directdigits directnetworkcallid dnispool
Yes
pullback
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes g
Yes
Yes
SIP Server—Deployment Guide 665
Chapter 9: Multi-Site Support ISCC Call Data Transfer Service
AT&T
Concert
CRSP
DTAG
GenSpec
IVR Server, using network configuration
KPN
ISCP
MCI
NGSN
Network SIP
Server
Sprint
Table 115: T-Server Support of Transaction Types (Continued)
T-Server
Type
Transaction Type route one-toone multipleto-one reroute
Yes
directcallid directuui / routeuui directnotoken directani directdigits directnetworkcallid
Yes h
Yes Yes i
dnispool pullback
Siemens
HiPath DX
SIP Cluster
SIP Server
Spectrum
Tadiran Coral
Teltronics
20-20
Tenovis
Integral 33/55
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes j
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes Yes
Yes k
Network T-Servers
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes Yes
Yes
Yes Yes
Yes
Yes
Yes
666 Framework 8.1
Chapter 9: Multi-Site Support ISCC Call Data Transfer Service
Table 115: T-Server Support of Transaction Types (Continued)
T-Server
Type
Transaction Type route one-toone multipleto-one reroute directcallid directuui / routeuui directnotoken directani directdigits directnetworkcallid dnispool pullback
SR-3511
Stentor a. Not supported in the case of function
TRouteCall
on a Virtual Routing Point: a Routing Point can be simulated using a hunt group with calls being deflected or transferred from the hunt-group member when routing. When a two-step (typically mute) transfer is used on such a hunt-group member,
CallID
and
ANI
usually change; thus, the direct-callid
and direct-ani
types do not work.
b. Not supported in the case of function
TSingleStepTransfer
when the T-Server service is simulated using a two-step transfer to the switch. In this case,
CallID
and
ANI
change; thus, the direct-callid
and direct-ani
types do not work.
c. Not supported if two T-Servers are connected to different nodes.
d. There are some switch-specific limitations when assigning CSTA correlator data UUI to a call.
e. Supported only on ABCF trunks (Alcatel internal network).
f. To use this transaction type, you must select the
Use Override
check box on the
Advanced
tab of the DN
Properties
dialog box.
g. Supported only for
TRouteCall
requests made from a Native Routing Point.
h. Not supported if a
TMakeCall
request is made.
i. Not supported if a
TInitiateTransfer
or
TInitiateConference
request is made from an outgoing call on a device.
j. SIP Server supports the direct-uui
type.
k. If the pullback
transaction does not explicitly include the destination DN, SIP Server supports the transfer only to a DN contained in the
FirstTransferOriginationLocationDN
attribute. If this attribute is empty (for example, if the first transfer transaction was ISCC/Call Overflow (COF), SIP Server fails the pullback
transaction.
Transfer Connect Service Feature
The Transfer Connect Service (TCS) feature supports transfer connect services available on some telephony networks. When this feature is enabled, ISCC passes user data to remote locations to which calls are transferred or conferenced using transfer connect services.
SIP Server—Deployment Guide 667
Chapter 9: Multi-Site Support ISCC/Call Overflow Feature
Procedure:
Activating Transfer Connect Service
Start of procedure
1. Open the T-Server
Application’s Properties
dialog box.
2. Click the
Options
tab.
always.
configuration option to the number of a DN on the origination switch.
ISCC uses this DN as an intermediate step when sending calls to the remote location. The DN that is configured as tcs-queue
receives attached data indicating the Feature Access Code (FAC) needed to reach the remote site. After a call is directed to the DN with data, a monitoring application takes the data and generates the required DTMF (dual-tone multifrequency) tones to redirect the call through the network to the remote location.
5. When you are finished, click
Apply
.
6. Click
OK
to save your changes and exit the
Properties
dialog box.
End of procedure
Note:
With T-Server for Avaya Communication Manager, you can use
RequestRouteCall
with
RouteTypeOverwriteDNIS
to initiate the playing of DTMF tones. This is done through the use of another intermediate
DN (typically, an announcement port configured to give the silent treatment), to which the call is routed. When the call is established on this DN, T-Server requests that the digits sent in the
DNIS
field of the
TRequestRouteCall
be played by using the
ASAI-send-DTMF-single procedure.
ISCC/Call Overflow Feature
The Inter Server Call Control/Call Overflow (ISCC/COF) feature of T-Server, that supports passive external routing, is specifically designed to handle calls delivered between sites without an explicitly defined destination location. Such scenarios include contact center overflows and manual call transfers.
An overflow situation occurs when a call comes into a contact center where all agents are currently busy. In this situation, the switch can transfer (overflow) the incoming call to another site where there is an available agent.
668 Framework 8.1
Chapter 9: Multi-Site Support ISCC/Call Overflow Feature
T-Server uses two methods to handle call overflow and manual transfer scenarios. The first method is based on
NetworkCallID
matching and the second method is based on
ANI/OtherDN
matching.
When connected to each other via switch-specific networks, switches of some types can pass additional information along with transferred calls. This information may contain the
NetworkCallID
of a call, which is a network-wide unique identifier of the call.
When connected via a regular PSTN, switches of all types can send the
ANI and/or
OtherDN
attributes to the destination switch during any call transfer operation.
While all T-Servers support the ISCC/COF feature using the
ANI
and/or
OtherDN
attributes, only a few support this feature using the
NetworkCallID
attribute. Table 116 shows the T-Server types that provide the
NetworkCallID
of a call.
Table 116: T-Server Support of NetworkCallID for ISCC/COF
Feature
T
-
Server Type
Alcatel A4400/OXE a
Aspect ACD
Avaya Communication Manager a,b
Avaya TSAPI a,b
Yes
Yes
Yes
Cisco UCCE
Mitel MiTAI a
Yes
Yes
Nortel Communication Server 2000/2100 a
Yes
Nortel Communication Server 1000 with
SCCS/MLS a
SIP Server a
Spectrum
Supported NetworkCallID
Attribute
Yes
Yes
Yes
Yes a.
NetworkCallID
is supported only if the match-flexible
configuration parameter is used.
b. ISCC/COF is cross-compatible between T-Server for Avaya Communication Manager and T-Server for Avaya TSAPI.
Note:
SIP Server supports ANI matching in ISCC COF scenarios.
SIP Server—Deployment Guide 669
Chapter 9: Multi-Site Support ISCC/Call Overflow Feature
The ISCC/COF feature can use any of the three attributes (
NetworkCallID,
ANI,
or
OtherDN
) as criteria for matching the arriving call with an existing call at another location. Consequently, the attribute that is used determines what
ConnID, UserData, CallType,
and
CallHistory
are received for the matched call from the call’s previous location.
Warning!
Depending on the switch platform, it may be possible to inherit the
ANI
attribute after routing a call to a remote destination, and after performing a single-step transfer and other telephone actions.
However, ISCC/COF works properly only in scenarios where the
ANI
attribute on the destination T-Server is represented by exactly the same unique digit string as on the origination T-Server.
Typically, the
ANI
attribute represents the original call identifier
(customer phone number), which guarantees that the attribute remains unique.
Note:
When the ISCC/COF feature is in use, the Number Translation feature becomes active. For more information on feature configuration, see
“Number Translation Feature” on page 672
.
Site A
ISCC/COF Call Flow
shows the sequence of steps that occur in an ISCC/COF scenario when a call is made or transferred by an agent at Site A to a DN at Site B, or when a call is overflowed from Site A to Site B.
Origination Switch Destination Switch
Site B
2. Call passing
Agent
1. Call made/ transferred to another location
T-Server
4. Call data request
6. Call data passing
3. Arrived call notification
8. Event distribution
T-Server
T-Server
Client
5. Call data waiting
7. Call data update
9. Info clearing
Figure 53: Steps in the ISCC/COF Process
670 Framework 8.1
Chapter 9: Multi-Site Support ISCC/Call Overflow Feature
Step 1
An agent makes or transfers a call manually to another location or a call is overflowed from Site A (origination location) to Site B (destination location).
Step 2
Switch A (the origination switch) passes the call to Switch B (the destination switch).
Step 3
The call reaches the destination switch, which notifies the destination T-Server about the arrived call.
Step 4
The destination T-Server verifies with remote locations whether the call overflowed at any of them.
To determine which calls to check as possibly having overflowed, T-Server relies on the
Switch
object and the presence of DNs on the
Switch
configured as the
Access Resource
type with the
Resource Type
set either to cof-in
(COF-IN DNs) or to cof-not-in
(COF-NOT-IN DNs):
T-Server skips an arriving call when one of following conditions is met:
•
The call arrives at a DN configured as an Enabled COF-NOT-IN DN.
•
COF-IN DNs are configured, but the call arrives at a DN other than one of the configured COF-IN DNs or to a COF-IN DN which is Disabled.
In all other cases, the call is checked for overflow.
To determine which location the call arrived from, T-Server checks the call type and checks whether the call has the
NetworkCallID, ANI,
or
OtherDN attribute:
•
If the call is not an inbound call, the request for call data is sent to all remote locations except those whose Switch Access Code has the ISCC
Call Overflow
Parameters
property set to inbound-only=true
.
•
If the call of any type has the
NetworkCallID
attribute, the destination
T-Server sends a request for call data to the remote locations of the same switch type as the destination location if their Switch Access Codes have the ISCC Call Overflow
Parameters
property set to match-callid
.
•
If the call of any type has the
ANI
or
OtherDN
attribute, the request for call data is sent to remote locations whose Switch Access Code has the ISCC
Call Overflow
Parameters
property set to match-ani
.
Step 5
The destination T-Server waits (suspending events related to that call) for the call data from the remote T-Server for the time interval specified in the
configuration option. Within this interval, T-Server holds any
SIP Server—Deployment Guide 671
Chapter 9: Multi-Site Support Number Translation Feature events related to the call. In addition, the
option on the origination T-Server establishes the time interval only after which that
T-Server deletes the call information. And the
,
if set to true, forces the origination T-Server to wait for responses related to possible call overflow situations before updating call data.
Step 6
The T-Server at the location from which the call was transferred or overflowed sends call data to the requesting T-Server.
Step 7
If a positive response to the call-data request is received, T-Server updates
ConnID, UserData, CallType,
and
CallHistory,
distributes all suspended events related to that call, and deletes all information regarding the transaction
(Step 9).
Step 8
If the timeout set by
expires, T-Server distributes all
suspended events, and starts the timeout specified by the cof-rci-tout
If a positive response is received within the timeout set by cof-rci-tout ,
T-Server updates the
ConnID, UserData, CallType,
and
CallHistory,
and notifies client applications by distributing
EventPartyChanged.
Step 9
T-Server deletes all information regarding the transaction when one of these results occurs:
•
The first positive response to the call-data request is received.
•
Negative responses from all queried locations are received.
•
The timeout specified by the cof-rci-tout
Note:
For information about configuring the ISCC/Call Overflow feature,
see “Configuring Multi-Site Support” on page 691
“Target Type: ISCC Call Overflow Parameters,” on page 697
.
Number Translation Feature
The Number Translation feature of T-Server extends the ISCC/COF and direct-ani
transaction type functions to provide more flexibility for handling calls distributed across multiple sites. T-Server translates the input string (ANI string) into a number defined by the translation rules. This processing is called
672 Framework 8.1
Chapter 9: Multi-Site Support Number Translation Feature number translation. T-Servers participating in handling calls at multiple sites exchange the translated numbers in order to match the call instances.
The translation process involves two algorithms, one for rule selection and the other for the actual translation. Through the first algorithm, T-Server selects a rule that will be used for number translation. Through the second algorithm,
T-Server translates the number according to the selected rule definition. See
“Number Translation Rules” on page 673
for more information on configuring rules for your environment.
Number translation occurs as follows:
1. The switch reports a number, typically via
AttributeANI
.
2. T-Server evaluates all configured inbound rules to determine which one is the best fit for the received number. The best fit is determined by comparing the length of, and the specific digits in, the input number with
the inbound pattern of each configured rule. See “Rule Examples” on page 678
for specific examples.
3. T-Server translates the number according to the selected rule.
To enable T-Server to translate numbers, you must perform specific
configuration tasks that are associated with translation. See “Configuring
Number Translation” on page 680 .
Number Translation Rules
T-Server uses the number translation rules that you define in the T-Server configuration object in two ways:
•
Rule selection—To determine which rule should be used for number translation
•
Number translation—To transform the number according to the selected rule
Using ABNF for Rules
The number translation rules must conform to the following syntax, represented using Augmented Backus-Naur Form (ABNF) notation. For more information about ABNF, see RFC 2234, “Augmented BNF for Syntax
Specifications: ABNF.”
Note:
The following notation explanations begin with the highest level notation. Each explanation includes the name of a component notation and a basic definition of each component that it contains. Some components require more detailed definitions, which are included later in this section.
SIP Server—Deployment Guide 673
Chapter 9: Multi-Site Support Number Translation Feature
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 = *dialing-plan-rule
where: dialing-plan-rule
represents the name of the rule. Each rule must have a unique name. There are no other naming restrictions, and you do not need to model your names according to the examples in this chapter.
The rules are represented as separate options in the configuration. Also, fields from a rule are represented as parameters in a single option string.
•
rule = [name] in-pattern [out-pattern]
where:
[name]
is the name for 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 T-Server, a name is required.
in-pattern
is the part of the rule to which T-Server looks when attempting to match the input number.
[out-pattern]
is the part of the rule that instructs T-Server on 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 out-pattern
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. T-Server uses this when selecting the most appropriate rule from the entire dialing plan.
674 Framework 8.1
Chapter 9: Multi-Site Support Number Translation Feature
abstract-group
represents one or more letters with each letter representing one or more numbers. T-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
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 phone-context.
Reminder: 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 T-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.
SIP Server—Deployment Guide 675
Chapter 9: Multi-Site Support Number Translation Feature
•
sequence = "[" 1*(digits [","] ) "]" group-identifier
where:
"
[" 1*(digits [","] ) "]"
represents a sequence of digits, separated by commas, and bracketed. T-Server requires that each digit set have the same number of digits. For example, in
[415,650]
the sets have three digits.
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 T-Server evaluates the rule to determine if it matches the number, it examines whether the three digits
( group-identifier A
) following the 1 in the number are
415 or
650.
•
abstract-group = fixed-length-group / flexible-length-group / entity
where: fixed-length-group
specifies a group composed of a specific number of digits and determined by how many 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 T-Server how many digits belong in that group. For example, rule-04
(see
) 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.
entity
represents digits defined for a specific purpose, for example, country code.
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.
•
entity = “#” entity-identifier group-identifier
where:
“#”
indicates the start of a Country Code entity-identifier
.
entity-identifier
must be the letter
C
which represents Country Code when preceded by a pound symbol (
#
)
.
Any other letter following the # causes an error.
group-identifier
represents the Country Code group when preceded by
#C.
676 Framework 8.1
Chapter 9: Multi-Site Support Number Translation Feature
The entity
component is a special group that assumes some kind of predefined processing, such as the Country Code detection.
•
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”
refers to 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.
•
group-identifier = ALPHA
•
entity-identifier = ALPHA
•
digits = 1*DIGIT
•
symbols = 1*(“-” / “+” / “)” / “(“/ “.”)
Recommendations for Rule Configuration
The configuration of rules for inbound numbers usually depends on the settings in the corresponding PBX. These settings often define the form in which the PBX notifies its client applications about the number from which an inbound call is coming.
As a general guideline, configure rules that define how to process calls from:
•
Internal numbers.
•
External numbers within the same local dialing area.
•
External numbers within the same country.
•
International numbers.
Rules for inbound numbers, typically for North American locations, might look like this:
1. Two rules to transform internal numbers (extensions): name=rule-01;in-pattern=[1-9]ABBB;out-pattern=AB name=rule-02;in-pattern=[1-9]ABBBB;out-pattern=AB
2. A rule to transform local area code numbers (in
333-1234
format in this example): name=rule-03;in-pattern=[1-9]ABBBBBB;out-pattern=+1222AB
SIP Server—Deployment Guide 677
Chapter 9: Multi-Site Support Number Translation Feature
3. A rule to transform U.S. numbers (in
+1(222)333-4444
format): name=rule-04;in-pattern=1AAAAAAAAAA;out-pattern=+1A
4. A rule to transform U.S. numbers without the
+1
prefix (in
(222)333-4444 format): name=rule-05;in-pattern=[2-9]ABBBBBBBBB;out-pattern=+1AB
5. A rule to transform U.S. numbers with an outside prefix (in
9
+1(222)333-4444
format): name=rule-06;in-pattern=91AAAAAAAAAA;out-pattern=+1A
6. A rule to transform international numbers with an IDD (international dialing digits) prefix (in
011 +44(111)222-3333
format): name=rule-07;in-pattern=011*A;out-pattern=+A
7. A rule to transform international numbers without an IDD prefix (in
+44(111)222-3333
format): name=rule-08;in-pattern=[2-9]A*B;out-pattern=+AB
Rule Examples
This section provides examples of six rules that are configured as options in the Genesys Configuration Database. It also provides examples of how
T-Server applies rules to various input numbers.
rule-01 rule-02 rule-03 rule-04 rule-05 rule-06
Rules
in-pattern=[1-8]ABBB;out-pattern=AB in-pattern=AAAA;out-pattern=A in-pattern=1[415,650]A*B;out-pattern=B in-pattern=1AAABBBCCCC;out-pattern=91ABC in-pattern=*A913BBBB;out-pattern=80407913B in-pattern=011#CA*B;out-pattern=9011AB
Example 1
Examples
Here are examples of how T-Server applies configured above rules to various input numbers.
T-Server receives input number
2326.
As a result of the rule selection process, T-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, T-Server detects two groups: Group
A = 2 and Group
B = 326.
678 Framework 8.1
Chapter 9: Multi-Site Support Number Translation Feature
Example 2
Example 3
Example 4
Example 5
Example 6
T-Server formats the output string as
2326.
T-Server receives input number
9122.
As a result of the rule selection process, T-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, T-Server detects one group: Group
A =
9122.
T-Server formats the output string as
9122.
T-Server receives input number
16503222332.
As a result of the rule selection process, T-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, T-Server detects two groups: Group
A = 650 and Group
B = 3222332.
T-Server formats the output string as
3222332.
T-Server receives input number
19253227676.
As a result of the rule selection process, T-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.
As a result of parsing process, T-Server detects three groups: Group
A = 925,
Group
B = 322,
and Group
C = 7676.
T-Server formats the output string as
919253227676.
T-Server receives input number
4089137676.
As a result of rule selection process, T-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, T-Server detects two groups: Group
A = 408 and Group
B = 7676.
T-Server formats the output string as
804079137676.
T-Server receives input number
011441112223333.
SIP Server—Deployment Guide 679
Chapter 9: Multi-Site Support Number Translation Feature
As a result of the rule selection process, T-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, T-Server detects two groups: Group
A = 44 and Group
B = 1112223333.
T-Server formats the output string as
9011441112223333.
Procedure:
Configuring Number Translation
Purpose: To configure the Number Translation feature in T-Server to provide more flexibility for handling calls distributed across multiple sites.
Overview
•
The Number Translation feature becomes active when the ISCC/COF feature and/or the direct-ani
transaction type are used.
•
This configuration procedure must be completed within the T-Server
Application
object corresponding to your T-Server.
Start of procedure
1. Open the T-Server
Application’s
Properties dialog box.
2. Click the
Options
tab.
3. Create a new section called extrouter
or open an existing section with this name.
4. Create a new option called
This option points to another section that describes the translation rules for inbound numbers.
5. In this section, create one configuration option for each rule. Specify the rule name as the option name. The values of these options are the rules for the number translation.
For the option description and its valid values, see Chapter 11, “T-Server
Common Configuration Options,” on page 729
.
6. When you are finished, click
Apply
.
7. Click
OK
to save your changes and exit the
Properties
dialog box.
End of procedure
680 Framework 8.1
Chapter 9: Multi-Site Support Network Attended Transfer/Conference Feature
Network Attended
Transfer/Conference Feature
The Network Attended Transfer/Conference (NAT/C) feature is designed to enable agents working in multi-site contact centers to consult with each other before making call transfers or conferences, regardless of whether both agents work at the same or different sites. It also enables the agent who requests a consultation to maintain his or her conversation with the customer while the system is looking for an available agent and setting up the consultation call.
The NAT/C feature does not rely on the call transfer capabilities of the local switch.
There are two modes in which the network attended transfer/conference can be performed: direct and URS-controlled.
shows the sequence of steps that occur in URS-controlled mode, when Agent A, who is handling a customer call, requests a consultation with another agent, and URS (Universal Routing
Server) selects Agent B, who is working at another site. The direct mode is similar to the URS-controlled mode, with the difference that URS is not involved in the process (Step 2 and Step 3 are omitted).
5. Consultation request and confirmation
SCP
URS
2. EventRoute-
Request
3. Routing call to
Agent B
Network T-Server
4. Call data passing
Site A
1. TNetworkConsult request
Agent A
T-Server A
Switch A
T-Server B
Switch B
Site B
6. Consultation with Agent B
Agent B
Figure 54: Steps in the NAT/C Process in URS-Controlled Mode
Step 1
Agent A makes a request for a consultation with another agent. A
TNetworkConsult
request is relayed to the Network T-Server. Depending on the parameter settings of the
TNetworkConsult
request, the NAT/C feature will operate in either direct or URS-controlled mode. For more information, see the
Platform SDK 8.x .NET (or Java) API Reference.
SIP Server—Deployment Guide 681
Chapter 9: Multi-Site Support Network Attended Transfer/Conference Feature
Step 2
(URS-controlled mode only.) The Network T-Server sends
EventRouteRequest to URS.
Step 3
(URS-controlled mode only.) URS locates an available agent at Site B and instructs the Network T-Server to route the call to Agent B. The Network
T-Server confirms the initiation of the network transfer by sending
EventNetworkCallStatus
to T-Server A, which then relays it to Agent A.
Step 4
The Network T-Server proceeds to obtain the access number from T-Server B,
Step 5
The Network T-Server instructs the Service Control Point (SCP) to initiate a new voice path with Agent B. Once the connection is confirmed, the Network
T-Server distributes
EventNetworkCallStatus
to both T-Server A and T-Server
B, which then relay it to Agent A and Agent B respectively, to indicate that the consultation call is being established.
The Network T-Server also distributes
EventRouteUsed
to URS to confirm successful routing of the call to the selected agent.
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
•
Set up a conference call with Agent B and the customer
•
Transfer the customer call to Agent B
Note:
All T-Servers support NAT/C requests with
AttributeHomeLocation provided that this attribute identifies a network location that is capable of processing such requests. Refer to the Network T-Server
Deployment Guides to determine whether a specific Network T-Server can process these requests.
682 Framework 8.1
Chapter 9: Multi-Site Support Event Propagation Feature
Event Propagation Feature
The Event Propagation feature complements the ISCC and ISCC/COF features by distributing updated user data and party-related events to remote T-Servers.
This feature is used when a call is being made, transferred, or conferenced to another location, and when, as a result, one or more instances of the call reside at one location while other call instances reside at another location. In this scenario, when a client at one location makes changes to user data, updated user data is passed (propagated) to T-Servers at other locations.
The Event Propagation feature consists of User Data update propagation and
Party Events propagation.
User Data Propagation
User data propagation takes place when a client at one location makes changes to user data associated with a call that was made, transferred, conferenced, or routed to other locations. The remote clients involved with the call are notified about the changes with
EventAttachedDataChanged
.
When T-Server receives a local update to user data (that is, when a client of this T-Server has changed the call’s user data), T-Server determines if parties at remote locations are involved with the call and, if so, sends (propagates) the updated user data to the T-Servers at remote locations.
When T-Server receives a remote update to user data (that is, when a client of a remote T-Server has changed the call’s user data and the remote T-Server has used the Event Propagation feature to send the updated user data), T-Server:
1. Updates the user data of the corresponding local call.
2. Determines if parties at other remote locations are involved with the call and, if so, propagates the updated user data to T-Servers at other remote locations.
The locations to which user data is propagated are selected based on a call distribution topology. That is, the updated user data is passed directly to the location to which a call was sent and to the location from which the call was received, excluding the location from which the update was received.
For example, consider a call made from location A to location B, and then conferenced from location B to location C. The three instances of the call reside at different locations: the first instance is at location A, the second instance is at location B, and the third instance is at location C. The Event
Propagation feature is employed in the following scenarios:
•
When T-Server at location A receives a local update to user data, it notifies
T-Server at location B (to which it sent the call) about changes to the call’s user data. Thus, T-Server at location B receives a remote update to user data and, in turn, notifies T-Server at location C (to which it sent the call) about these changes.
SIP Server—Deployment Guide 683
Chapter 9: Multi-Site Support Event Propagation Feature
Although T-Server at location C receives a remote update to user data, it does not pass the notification to any other T-Servers, because it did not send the call to any other locations. As mentioned earlier, T-Servers at locations B and C update the user data of the corresponding local calls and notify their clients about the changes with
EventAttachedDataChanged
.
•
When T-Server at location B receives a local update to user data, it notifies
T-Server at location C (to which it sent the call) and T-Server at location A
(from which it received the call) about changes to the call’s user data.
Thus, T-Servers at locations C and A receive a remote update to user data.
Because T-Server at location C did not send the call to any other locations, and T-Server at location A originated the call, neither of these T-Servers passes the notification to any other T-Servers. T-Servers at locations C and
A update the user data of the corresponding local calls and notify their clients about the changes with
EventAttachedDataChanged
.
•
When T-Server at location C receives a local update to user data, it notifies
T-Server at location B (from which it received the call) about changes to the call’s user data. Thus, T-Server at location B receives a remote update to user data and, in turn, notifies T-Server at location A (from which it received the call) about these changes.
Although T-Server at location A receives a remote update to user data, it does not pass the notification to any other T-Servers, because it originated the call. T-Servers at locations B and A update the user data of the corresponding local calls and notify their clients about the changes with
EventAttachedDataChanged
.
When a call is distributed between location A and location C using location B, and is then deleted on location B, propagation between locations A and C still occurs through the transit node at location B.
Party Events Propagation
Party events propagation takes place when a transfer or a conference is completed for a call that was made to or from one or more remote locations, or when a conference party is removed from the conference.
In these cases, the Event Propagation feature distributes party events, such as
EventPartyChanged, EventPartyAdded,
and
EventPartyDeleted,
to remote locations involved with the call, according to appropriate call model scenarios.
For example, consider a call made from DN 1 to DN 2 on location A. A
TInitiateConference
request is then issued for DN 2 to transfer the call to external DN 3 on location B. That transfer is made by means of ISCC routing.
When this conference is completed on location A, the Event Propagation feature sends
EventPartyChanged
to location B and distributes this event to involved client applications that are connected to location B and registered for
DN 3. After that, if a party of the conference is removed from the conference
(for example, a party on DN 2), the Event Propagation feature sends
EventPartyDeleted
to location B and distributes this event to client applications registered for DN 3.
684 Framework 8.1
Chapter 9: Multi-Site Support Event Propagation Feature
If a call involved in the propagation has no local parties but has two or more remote parties, the party events propagation is processed in the same manner as the propagation of user data updates.
For a complete event flow in such scenarios, refer to the Genesys Events and
Models Reference Manual.
Switch Partitioning
A multi-site environment with switch partitioning or intelligent trunks can be defined as a configuration of multiple virtual switches (or
Switch
objects) that are defined in Configuration Manager under a single
Switching Office object representing a physical switch. Each
Switch
object has its own instance of a
T-Server application. All T-Server applications connect to the switch via the
same or different CTI link or a gateway. (See Figure 55 .)
When the Event Propagation feature is active, updated user data and party-related events—
EventPartyChanged, EventPartyDeleted,
and
EventPartyAdded
—are propagated to T-Servers that are involved in call transactions, such as transfer or conference. However, with switch partitioning, the call instances may reside at one partition or at different partitions.
Site A
T-Server
T-Server
Client
T-Server
T-Server
Client
Switch
Figure 55: Switch Partitioning Architecture
Starting with version 8.0, in addition to
ConnID s and
UserData,
T-Server can synchronize the
CallType
attribute. Each T-Server is required to register all
DNs it monitors. In a multi-partitioned environment, when configured, calls between partitions are reported as internal
(CallTypeInternal).
In a non-partitioned environment, such calls are reported as inbound
(CallTypeInbound)
and/or outbound
(CallTypeOutbound)
, depending on the direction of a call. In order for T-Servers to report calls between specified partitions as internal, registered DNs of these partitions must be assigned to a
Switch (T-Server), Switching Office, or Tenant, using the dn-scope
configuration option. If DNs that are involved in calls are not in the T-Server scope, those DNs will be reported as inbound or outbound.
SIP Server—Deployment Guide 685
Chapter 9: Multi-Site Support Event Propagation Feature
In addition, T-Server supports
LocalCallType
and
PropagatedCallType attributes, which depend on the
configuration option setting for reporting. See the option description on page 734
.
To control race conditions that may occur in the switch-partitioned
environment, use the epp-tout configuration option (see page 749
).
Notes:
Because of possible delays in TCP/IP connections, a sequence of events sent for the same call by two or more T-Servers to clients may appear in an unexpected order. For example, in a simple call scenario with two partitions,
EventRinging
and
EventEstablished
messages may both arrive before
EventDialing
.
Genesys switch partitioning does not apply to hardware partitioning functionality that is supported on some switches.
shows the T-Server types that support switch partitioning.
Table 117: T-Server Support for Switch Partitioning
T
-
Server Type
Alcatel A4400/OXE
Avaya Communication Manager
Avaya TSAPI
Cisco Unified Communications Manager
SIP Server
Supported
Yes
Yes
Yes
Yes
Yes
ISCC Path Optimization
The ISCC event propagation distributes events between call parties and is carried through an ISCC connection between SIP Severs. The ISCC signaling path might not precisely coincide with the SIP signaling path.
illustrates a two-server multi-site call topology. The ISCC event propagation triggered by party A is delivered to party C by transiting SIP
Server 2
.
686 Framework 8.1
Chapter 9: Multi-Site Support Event Propagation Feature
Figure 56: Multi-Site Consultation Call Loop
For trunk optimization, when party B completes a transfer, SIP Server 2 goes
out of the SIP signaling path (see “Trunk Optimization for Multi-Site
). Even though SIP Server 2 exited the SIP signaling path, without ISCC path optimization, event propagation is still carried
through SIP Server 2. (See Figure 57 .)
Figure 57: Multi-Site Transfer Without ISCC Path Optimization
The ISCC path optimization feature optimizes the ISCC signaling path by
dropping transit sites from the path. Figure 58
illustrates the ISCC path after optimization.
SIP Server—Deployment Guide 687
Chapter 9: Multi-Site Support Event Propagation Feature
Figure 58: Multi-Site Transfer With ISCC Path Optimization
The ISCC Path Optimization feature is controlled by the path-optimization parameter that must be configured in the
ISCC Protocol Parameters
field of the
Switch Access Code
. See Procedure: Configuring Access Codes, on page 695 .
This feature applies only to two-site configurations.
Note:
The ISCC Path Optimization feature is supported only between SIP
Servers. It is not currently supported in other Genesys T-Servers.
Event Propagation Configuration
The basic Event Propagation feature configuration includes a setting of specific configuration options at a T-Server
Application
level. The advanced feature configuration allows you to customize the feature at a
Switch
level.
When determining whether to notify other T-Servers of changes to user data, or to distribute party events, T-Server checks:
1. Call topology (what location a call came from and to what location the call was then transferred or conferenced).
2. Outbound parameters of the
Switch
this T-Server relates to (whether propagation parameters are configured for the access codes this switch uses to reach the switch at the location a call came from and the switch at the location to which the call was then transferred or conferenced).
Warning!
The direction of user-data or party-events propagation does not necessarily match the direction of call distribution. Therefore, the access code used to deliver the call can differ from the access code used for the purpose of Event Propagation.
688 Framework 8.1
Chapter 9: Multi-Site Support Event Propagation Feature
If one of the T-Servers along the call distribution path has the Event
Propagation feature disabled, that T-Server does not distribute events to remote locations.
Procedure:
Activating Event Propagation: basic configuration
Purpose: To activate the Event Propagation feature for User Data updates and call-party–associated events (Party Events) distribution.
Start of procedure
1. Open the T-Server
Application’s Properties
dialog box.
2. Click the
Options
tab.
3. Open the extrouter
section.
option to the list
value.
This setting enables User Data propagation. If you need to enable Party
Events propagation, perform Step 5.
current
value.
This setting enables Party Events propagation.
For the option description and its valid values, see Chapter 11, “T-Server
Common Configuration Options,” on page 729
.
6. When you are finished, click
Apply
.
7. Click
OK
to save your changes and exit the
Properties
dialog box.
End of procedure
Next Steps
•
For advanced feature configuration, do the following procedure:
Procedure: Modifying Event Propagation: advanced configuration, on page 689
Procedure:
Modifying Event Propagation: advanced configuration
Purpose: To modify access codes for advanced Event Propagation configuration.
Prerequisites
•
Procedure: Activating Event Propagation: basic configuration, on page 689
SIP Server—Deployment Guide 689
Chapter 9: Multi-Site Support Event Propagation Feature
Overview
You can set Event Propagation parameters using:
•
The
Default Access Code
properties of the
Switch
that receives an
ISCC-routed call (the destination switch).
•
The
Access Code
properties of the
Switch
that passes an ISCC-routed call
(the origination switch).
If you do not set up Event Propagation parameters for a given
Access Code,
T-Server uses corresponding settings configured for the
Default Access Code of the destination switch.
The procedures for modifying
Default Access Codes
and
Access Codes
are very similar to each other.
Start of procedure
1. Among configured
Switches,
select the
Switch
that the configured
T-Server relates to.
2. Open the
Switch’s Properties
dialog box and click either the
Default
Access Codes
tab or the
Access Codes
tab.
3. Select a configured
Default Access Code
or configured
Access Code
and click
Edit.
Note:
If no
Default Access Code
is configured, see
instructions. If no
Access Codes
are configured, see page 695 for
instructions.
4. In the
Switch Access Code Properties
dialog box that opens, specify a value for the
ISCC Protocol Parameters
field as follows:
To enable distribution of both user data associated with the call and call-party–associated events
2
, type:
propagate=yes which is the default value.
To enable distribution of user data associated with the call and disable distribution of call-party–associated events, type:
propagate=udata
To disable distribution of user data associated with the call and enable distribution of call-party–associated events, type: propagate=party
To disable distribution of both user data associated with the call and call-party–associated events, type:
2. The following are call-party–associated events:
EventPartyChanged
,
EventPartyDeleted
, and
EventPartyAdded.
690 Framework 8.1
Chapter 9: Multi-Site Support ISCC Transaction Monitoring Feature
propagate=no
To enable the ISCC Call Optimization feature, configure this parameter: path-optimization=<cpo, true, false>
See
Procedure: Configuring Access Codes, on page 695
.
5. Click
OK
to save configuration updates and close the
Switch Access Code
Properties
dialog box.
6. Click
Apply
and
OK
to save configuration updates and close the
Switch
Properties
dialog box.
End of procedure
ISCC Transaction Monitoring Feature
This feature allows T-Server clients to monitor ISCC transactions that occur during the call data transfer between T-Servers in a multi-site environment.
In order to be able to monitor ISCC messaging, a T-Server client must subscribe to the ISCC Transaction Monitoring. Once a subscription request is confirmed, a client will receive updates about all multi-site operations of this
T-Server.
The
TTransactionMonitoring
request is used to instruct T-Server to start, stop, or modify a client’s subscription to Transaction Monitoring feature notifications by setting the
TSubscriptionOperationType
parameter to
SubscriptionStart, SubscriptionStop,
or
SubscriptionModify respectively.
The transaction status is reported in
EventTransactionStatus
messages to the subscribed clients.
To determine whether the Transaction Monitoring feature is supported by a specific T-Server, a T-Server client may query T-Server’s capabilities. For more information about support of this feature, see Genesys Events and Models
Reference Manual and Platform SDK 8.x .NET (or Java) API Reference.
Configuring Multi-Site Support
Prior to configuring T-Server to support multi-site operation, you must read the
“Licensing Requirements” on page 52 , as well as previous sections of this
chapter on multi-site deployment. In particular, Table 115 on page 664
shows
which transaction types are supported by a specific T-Server, while Table 116 on page 669
shows whether your T-Server supports the
NetworkCallID
attribute
SIP Server—Deployment Guide 691
Chapter 9: Multi-Site Support Configuring Multi-Site Support for the ISCC/COF feature. Use this information as you follow the instructions in this chapter.
Note:
Before attempting to configure a multi-site environment, Genesys recommends that you plan the changes you want to make to your existing contact centers. You should then gather the configuration information you will need (such as the name of each T-Server application, port assignments, and switch names), and use
Configuration Manager to create and partially configure each T-Server
object. Review multi-site option values in the “extrouter Section” on page 739
and determine what these values need to be, based on your network topology.
For T-Server to support multi-site operation, you must create and configure three types of objects in the Configuration Layer:
1. Applications
2.
Switches,
including
Access Codes
3.
DNs
You must configure these objects for origination and destination locations.
Multi-site support features activate automatically at T-Server startup. See
for details.
Applications
Ensure that T-Server
Application
objects, and their corresponding
Host objects, exist and are configured for origination and destination locations.
Once you’ve done that, use Configuration Manager to add this configuration to a T-Server
Application.
Procedure:
Configuring T-Server Applications
Purpose: To configure T-Server
Application
objects for multi-site operation support.
Start of procedure
1. Open the T-Server
Application’s Properties
dialog box.
2. Click the
Connections
tab and click
Add
to add a connection to the appropriate T-Server. The
Connection Info Properties
dialog box displays.
3. Use the
Browse
button to search for the T-Server you want to connect to, and fill in the following values:
Port ID
692 Framework 8.1
Chapter 9: Multi-Site Support Configuring Multi-Site Support
Connection Protocol
Local Timeout
Remote Timeout
Trace Mode
4. Click the
Options
tab. Create a new section called extrouter
or open an existing section with this name.
Note:
If you do not create the extrouter
section, T-Server uses the default values of the corresponding configuration options.
5. Open the extrouter
section. Configure the options used for multi-site support.
Note:
For a list of options and valid values, see “extrouter Section” on page 739
, in the “T-Server Common Configuration Options” chapter.
6. When you are finished, click
Apply
.
7. Repeat this procedure for all T-Servers for origination and destination locations that are used for multi-site operations.
End of procedure
Next Steps
•
See
Switches and Access Codes
Ensure that
Switching Office
and
Switch
objects are configured for both origination and destination locations.
You configure
Access Codes
to a destination switch in the origination
Switch’s
Properties
dialog box. The only exception is the
Default Access Code,
which is configured at the destination
Switch’s Properties
dialog box.
You can configure two types of switch
Access Codes
in the
Switch’s
Properties
dialog box:
•
A
Default Access Code
(for inbound calls)—Specifies the access code that other switches can use to access this switch when they originate a multi-site transaction.
•
An
Access Code
(for outbound calls)—Specifies the access code that this switch can use when it originates a multi-site transaction to access another switch.
SIP Server—Deployment Guide 693
Chapter 9: Multi-Site Support Configuring Multi-Site Support
When the origination T-Server processes a multi-site transaction, it looks for an access code to the destination switch. First, T-Server checks the
Access
Code
of the origination
Switch
:
•
If an access code to the destination switch is configured with the target type
Target ISCC
and with any transaction type except
Forbidden
, T-Server uses this access code to dial the destination switch.
•
If the access code to the destination switch is not configured on the
Access
Code
tab of the origination switch, the origination T-Server checks the
Default Access Code
tab of the destination switch. If an access code is configured there with the target type
Target ISCC
and with any transaction type except
Forbidden
, T-Server uses this access code to dial the destination switch.
•
If no access code with the required properties is found, T-Server rejects the transaction.
Note:
When migrating from previous releases of T-Servers to 8.1, or when using T-Servers of different releases (including 8.1) in the same
environment, see “Compatibility Notes” on page 699.
Procedure:
Configuring Default Access Codes
Purpose: To configure the
Default Access Codes
(one per
Switch
object) to be used by other switches to access this switch when they originate a multi-site transaction.
Prerequisites
•
Ensure that
Switching Office
and
Switch
objects are configured for both origination and destination locations.
Start of procedure
1. Among configured
Switches
, select the
Switch
that the configured T-Server relates to.
2. Open the
Switch Properties
dialog box and click the
Default Access Codes tab.
3. Click
Add
to open the
Access Code Properties
dialog box.
694 Framework 8.1
Chapter 9: Multi-Site Support Configuring Multi-Site Support
4. In the
Code
field, specify the access code used by remote switches to reach a DN at this switch. An access code is used as a prefix to the remote switch numbers.
Note:
If no prefix is needed to dial to the configured switch, you can leave the
Code
field blank.
5. In the
Target Type
field, select
Target ISCC
.
6. In the
Route Type
field, select a value corresponding to the transaction type you want to use (given that it is supported for your switch type).
7. When you are finished, click
Apply
.
End of procedure
Next Steps
•
See
Procedure:
Configuring Access Codes
Purpose: To configure the
Access Codes
(one or more per
Switch
object) that this switch can use when it originates a multi-site transaction to access another switch.
Prerequisites
•
Ensure that
Switching Office
and
Switch
objects are configured for both origination and destination locations.
Start of procedure
1. Among configured
Switches
, select the
Switch
that the configured T-Server relates to.
2. Open the
Switch Properties
dialog box and click the
Access Codes
tab.
3. Click
Add
to open the
Access Code Properties
dialog box.
4. In the
Switch
field, specify the switch that this switch can reach using this access code. Use the
Browse
button to locate the remote switch.
SIP Server—Deployment Guide 695
Chapter 9: Multi-Site Support Configuring Multi-Site Support
5. In the
Code
field, specify the access code used to reach a DN at the remote switch from this switch. An access code is used as a prefix to the remote switch numbers.
Note:
If no prefix is needed to dial from one switch to another, you can leave the
Code
field blank.
6. In the
Target Type
field, select
Target ISCC
.
When you select
Target ISCC as your target type, the
Properties
dialog box changes its lower pane to the
Sources
pane. It is here that you enter the extended parameters for your access codes, by specifying the
ISCC
Protocol
and
ISCC Call Overflow Parameters.
To set these parameters, locate the two drop-down boxes that appear below the
Target Type field in the
Sources
pane of that
Properties
dialog box.
a. In the
ISCC Protocol Parameters
drop-down box, enter the appropriate
ISCC Protocol parameter, as a comma-separated list of one or more of the following items shown in
Table 118: Target Type: ISCC Protocol Parameters
ISCC Protocol Parameters Description
dnis-tail=<number-of-digits
> Where
number-of-digits
is the number of significant DNIS digits (last digits) used for call matching.
0
(zero) matches all digits.
propagate=<yes
, udata
, party
, no> direct-network-callid=<>
Default is
yes
. For more information, see “Modifying Event
Propagation: advanced configuration” on page 689 .
Use Table 116 on page 669 to determine if your T-Server
supports the direct-network-callid
transaction type.
696 Framework 8.1
Chapter 9: Multi-Site Support Configuring Multi-Site Support
Table 118: Target Type: ISCC Protocol Parameters (Continued)
ISCC Protocol Parameters Description
path-optimization=<cpo, true, false>
Default is cpo
. When set to false,
ISCC does not optimize the Event Propagation path (backward-compatible behavior).
When set to
cpo,
SIP Server aligns the ISCC call path with the SIP signaling path. For example, if SIP Server gets out of the SIP signaling path, so does ISCC. If this parameter is set to true,
ISCC makes a decision to optimize the call path based on its internal analysis and without direct relation to the SIP signaling path.
Note: There can be two
Switch Access Codes
for any pair of switches. One
Switch Access Code
is for transfers from switch A to switch B, and the other one for transfers from switch B to switch A. When those
Switch Access Codes contain different values of the path-optimization parameter, the effective value is the weaker of the two values. Therefore, if one of them is set to false
, the effective value is false
; if one of them is set to cpo
, the effective value is cpo
. Otherwise, the effective value is true
.
See “ISCC Path Optimization” on page 686 for details.
alternate-route-cof=<true, false>
SIP Server-specific. When set to true,
SIP Server uses the
ISCC Call Overflow (COF) feature for alternate routing.
“Alternate Routing for Unresponsive URS/ORS” on page 111 .
b. In the
ISCC Call Overflow Parameters
drop-down box, enter call overflow parameters, as a comma-separated list of one or more of the following items shown in
:
Table 119: Target Type: ISCC Call Overflow Parameters
ISCC Call Overflow Parameters
match-callid match-ani
Description
Matches calls using network
CallID
.
Matches calls using ANI.
Note: When using match-ani,
the match-flexible parameter must be set to false.
SIP Server—Deployment Guide 697
Chapter 9: Multi-Site Support Configuring Multi-Site Support
Table 119: Target Type: ISCC Call Overflow Parameters
ISCC Call Overflow Parameters
match-flexible inbound-only=<boolean>
Description
Supports flexible call matching based on the following values:
Default Value:
true
Valid Values: true, false, and
[matching-context-type], where
[matching-context-type]
is the switch-specific value, which must be the same as the value of the
default-network-call-id-matching
the corresponding T-Server.
Default is
true.
Setting
inbound-only
to true disables
COF on consultation and outbound calls.
7. In the
Route Type
field, select a value corresponding to the transaction type you want to use (given that it is supported for your switch type).
contains cross-reference information on transaction types that the
Configuration Layer and T-Server use.
Table 120: Route Type and ISCC Transaction Type
Cross-Reference
Route Type Field Value
Default
Direct
Direct ANI
Direct Digits
Direct DNIS and ANI
Direct Network Call ID
Direct No Token
Direct UUI
DNIS Pooling
Forbidden
ISCC defined protocol
PullBack
ISCC Transaction Type
The first value from the list of values specified in the cast-type
option for the
T-Server at the destination site direct-callid direct-ani direct-digits
Reserved direct-network-callid direct-notoken direct-uui dnis-pooling
External routing to this destination is not allowed
Reserved pullback
698 Framework 8.1
Chapter 9: Multi-Site Support Configuring Multi-Site Support
Table 120: Route Type and ISCC Transaction Type
Cross-Reference (Continued)
Route Type Field Value
Re-Route
Route
ISCC Transaction Type
reroute route
8. When you are finished, click
Apply
.
End of procedure
Next Steps
•
After configuring a switch for multi-site support, proceed with the configuration of DNs assigned to this switch.
Compatibility Notes
When migrating from previous releases of T-Servers to 8.1, or when using
T-Servers of different releases (including 8.1) in the same environment, keep in mind the following compatibility issues:
•
The
Target External Routing Point
value of the
Target Type
field is obsolete and provided only for backward compatibility with T-Servers of releases 5.1 and 6.0. When two access codes for the same switch are configured, one with the
Target ISCC
target type and the other with the
Target External Routing Point
target type, T-Servers of releases 8.x, 7.x,
6.5, and 6.1:
Use the
Target ISCC
access code for transactions with T-Servers of releases 8.x, 7.x, 6.5, and 6.1.
Use the
Target External Routing Point
access code for transactions with T-Servers of releases 5.1 and 6.0.
When the only access code configured for a switch has the
Target External
Routing Point
target type, T-Server uses this access code for all transactions.
•
When the
Target External Routing Point
value of the
Target Type
field is configured, you must set the
Route Type
field to one of the following:
Default
to enable the route
transaction type
Label
to enable the direct-ani
transaction type
Direct
to enable the direct
transaction type
Note:
The direct
transaction type in releases 5.1 and 6.0 corresponds to the direct-callid
transaction type in releases 6.1 and later.
SIP Server—Deployment Guide 699
Chapter 9: Multi-Site Support Configuring Multi-Site Support
UseExtProtocol
to enable the direct-uui
transaction type
PostFeature
to enable the reroute
transaction type
These values are fully compatible with the transaction types supported in
T-Server release 5.1.
•
For successful multi-site operations between any two locations served by release 5.1 T-Servers, identical
Route Type
values must be set in the
Switch’s Access Code Properties
dialog boxes for both the origination and destination switches.
DNs
Use the procedures from this section to configure access resources for various transaction types.
Procedure:
Configuring access resources for the route transaction type
Purpose: To configure dedicated DNs required for the route transaction type.
Prerequisites
•
Ensure that
Switching Office
and
Switch
objects are configured for both origination and destination locations.
Start of procedure
1. Under a configured
Switch
, select the
DNs
folder. From the main menu, select
File > New > DN
to create a new
DN
object.
2. On the
General
tab of the DN’s
Properties
dialog box, specify the number of the configured DN as the value of the
Number
field. This value must correspond to the Routing Point number on the switch.
3. Select
External Routing Point
as the value of the
Type
field.
4. If a dialable number for that Routing Point is different from its DN name, specify the number in the
Association
field.
5. Click the
Access Numbers
tab. Click
Add
and specify these access number parameters:
Origination switch.
Access number that must be dialed to reach this DN from the origination switch.
In determining an access number for the Routing Point, T-Server composes it of the values of the following properties (in the order listed):
a. Access number (if specified).
700 Framework 8.1
Chapter 9: Multi-Site Support Configuring Multi-Site Support
b. Switch access code from the switch of the origination party to the switch to which the Routing Point belongs, concatenated with its
Association
(if the
Association
value is specified).
c. Switch access code from the switch of the origination party to the switch to which the Routing Point belongs, concatenated with the number for the DN.
d. Default access code of the switch to which the Routing Point belongs, concatenated with its
Association
(if the
Association
value is specified).
e. Default access code of the switch to which the Routing Point belongs, concatenated with the number for the DN.
Note:
If option
is set to true,
the access number composed of switch access code and DN can be used for external transfers of calls originating at switches for which an access number is not specified.
6. When you are finished, click
Apply.
End of procedure
Procedure:
Configuring access resources for the dnis-pool transaction type
Purpose: To configure dedicated DNs required for the dnis-pool transaction type.
Start of procedure
1. Under a configured
Switch
, select the
DNs
folder. From the main menu, select
File > New > DN
to create a new
DN
object.
2. On the
General
tab of the DN’s
Properties
dialog box, specify the number of the configured DN as the value of the
Number
field. This value must be a dialable number on the switch.
3. Select
Access Resource
as the
Type
field and type dnis
as the value of the
Resource Type
field on the
Advanced
tab.
4. Click the
Access Numbers
tab. Click
Add
and specify these
Access Number parameters:
Origination switch.
SIP Server—Deployment Guide 701
Chapter 9: Multi-Site Support Configuring Multi-Site Support
Access number that must be dialed to reach this DN from the origination switch.
An access number for the access resource is determined in the same manner as for the route
access resource.
5. When you are finished, click
Apply
.
End of procedure
Procedure:
Configuring access resources for direct-* transaction types
Start of procedure
You can use any configured DN as an access resource for the direct-* transaction types. (The
*
symbol stands for any of the following: callid, uui, notoken, ani,
or digits.
)
You can select the
Use Override
check box on the
Advanced
tab to indicate whether the override value should be used instead of the number value to dial to the DN. You must specify this value if the DN has a different DN name and dialable number. In fact, this value is required for T-Servers for some switch types—such as Aspect ACD, Nortel Communication Server 2000/2100, and
Spectrum.
End of procedure
Procedure:
Configuring access resources for ISCC/COF
Purpose: To configure dedicated DNs required for the ISCC/COF feature.
Note:
Use Table 116 on page 669 to determine if your T-Server supports the
ISCC/COF feature.
Start of procedure
1. Under a configured
Switch
, select the
DNs
folder. From the main menu, select
File > New > DN
to create a new
DN
object.
702 Framework 8.1
Chapter 9: Multi-Site Support Configuring Multi-Site Support
2. On the
General
tab of the DN
Properties
dialog box, enter the name of the configured DN in the
Number
field.
Note:
The name of a DN of type
Access Resource
must match the name of a DN in your configuration environment (typically, a DN of type
Routing Point
or
ACD Queue
), so T-Server can determine whether the calls arriving at this DN are overflowed calls.
3. Select
Access Resource
as the value for the
Type
field.
4. On the
Advanced
tab, type cof-in or cof-not-in
as the value for the
Resource Type
field.
Note:
Calls coming to DNs with the cof-not-in
value for the
Resource
Type
are never considered to be overflowed.
5. When you are finished, click
Apply
.
End of procedure
Procedure:
Configuring access resources for non-unique ANI
Purpose: To configure dedicated DNs required for the non-unique-ani resource type.
The non-unique-ani
resource type is used to block direct-ani
and
COF/ani from relaying on ANI when it matches configured/enabled resource digits.
Using non-unique-ani,
T-Server checks every ANI against a list of non-unique-ani
resources.
Start of procedure
1. Under a configured
Switch
, select the
DNs
folder. From the main menu, select
File > New > DN
to create a new
DN
object.
2. On the
General
tab of the DN
Properties
dialog box, specify the ANI digits that need to be excluded from normal processing.
3. Select
Access Resource
as the value for the
Type
field.
4. On the
Advanced
tab, specify the
Resource Type field as non-unique-ani
.
5. When you are finished, click
Apply
.
End of procedure
SIP Server—Deployment Guide 703
Chapter 9: Multi-Site Support Configuring Multi-Site Support
Procedure:
Modifying DNs for isolated switch partitioning
Purpose: To modify DNs that belong to a particular partition where switch partitioning is used.
This configuration instructs T-Server to select an External Routing Point that has the same partition as the requested destination DN.
Note:
When a target DN is not configured or has no configured partition name, T-Server allocates a DN of the
External Routing Point
type that belongs to any partition.
Start of procedure
1. Under a
Switch
object, select the
DNs
folder.
2. Open the
Properties
dialog box of a particular
DN
.
3. Click the
Annex
tab.
4. Create a new section named
TServer
.
5. Within that section, create a new option named epn.
Set the option value to the partition name to which the DN belongs.
6. Repeat Steps 1–5 for all DNs, including DNs of the
External Routing Point type, that belong to the same switch partition.
7. When you are finished, click
Apply.
End of procedure
Configuration Examples
This section provides two configuration examples and describes how the configuration settings affect T-Server’s behavior.
Multiple Transaction Types
This example demonstrates the difference in how ISCC directs a call when you specify two different transaction types
(route
and direct-ani)
. In this example, you configure an origination and a destination switch for as described
in “Switches and Access Codes” on page 693
.
1. Among configured
Switches
, select the origination
Switch
.
2. Open the
Switch Properties
dialog box and click the
Default Access Codes tab.
3. Click
Add
to open the
Access Code Properties
dialog box.
704 Framework 8.1
Chapter 9: Multi-Site Support Configuring Multi-Site Support
4. Set the
Access Code
field to
9.
5. When you are finished, click
Apply
.
6. Among configured
Switches
, select the destination
Switch
.
7. Under the destination
Switch, configure a DN as described in
“Configuring access resources for the route transaction type” on page 700 .
8. Set the DN
Number
field to
5001234567.
9. Click the
Advanced
tab of this DN’s
Properties
dialog box.
10. Select the
Use Override
check box and enter
1234567
in the
Use Override field.
11. When you are finished, click
Apply
or
Save
.
12. Use a T-Server client application to register for this new DN with the destination T-Server and, therefore, with the switch.
13. Request to route a call from any DN at the origination switch to the destination DN you have just configured:
If you are using the route
ISCC transaction type, the client requests that T-Server deliver a call to a destination location using the DN number
5001234567.
ISCC requests that the switch dial one of the external routing points at the destination location, using the value either of the
Access Number
field or of the
Access Code
field, which is
9, concatenated with the external routing point at the destination location.
The call is routed to the DN number
5001234567
.
If you are using the direct-ani
ISCC transaction type, the client requests that T-Server deliver a call to a destination location using the
DN number
1234567
, which is the
Use Override
value. ISCC requests that the switch dial
91234567,
which is a combination of the
Switch
Access Code
value and the
Use Override
value. The destination T-Server is waiting for the call to directly arrive at DN number
5001234567.
Call Overflow Methods
This section demonstrates how to indicate which overflow methods a switch supports.
In this example, for T-Server to use ANI/OtherDN matching in call overflow and manual transfer scenarios, set the
ISCC Call Overflow Parameters
to: match-ani, inbound-only=true when configuring
Switch Access Codes
as described on
.
With this setting, the switch’s location is queried for call data each time the destination T-Server receives an inbound call with the
ANI
or
OtherDN
attribute.
For T-Server to use
NetworkCallID
matching in call overflow and manual transfer scenarios, set the
ISCC Call Overflow Parameters
to (for example): match-callid, inbound-only=false
SIP Server—Deployment Guide 705
Chapter 9: Multi-Site Support Configuring Multi-Site Support when configuring
Switch Access Codes
With this setting, the switch’s location is queried for call data each time the destination T-Server receives a call of any type (including inbound) with the
NetworkCallID
attribute.
706 Framework 8.1
Chapter
10
Common Configuration
Options
Unless otherwise noted, the common configuration options that this chapter describes are common to all Genesys server applications and applicable to any
Framework server component. This chapter includes the following sections:
Setting Configuration Options, page 707
Mandatory Options, page 708 log Section, page 708
log-extended Section, page 722
log-filter Section, page 724 log-filter-data Section, page 724
security Section, page 725 sml Section, page 725
Note:
Some server applications also support log options that are unique to them. For descriptions of a particular application’s unique log options, refer to the chapter/document about that application.
Setting Configuration Options
Unless specified otherwise, set common configuration options in the
Options of the
Application
object, using one of the following navigation paths:
•
In Genesys Administrator—
Application
object >
Options
tab >
Advanced
View (Options)
•
In Configuration Manager—
Application
object >
Properties
dialog box >
Options tab
SIP Server—Deployment Guide 707
Chapter 10: Common Configuration Options Mandatory Options
Warning!
Configuration section names, configuration option names, and predefined option values are case-sensitive. Type them in Genesys
Administrator or Configuration Manager exactly as they are documented in this chapter.
Mandatory Options
You do not have to configure any common options to start Server applications.
log Section
This section must be called log.
verbose
Default Value: all
Valid Values: all debug trace interaction standard none
All log events (that is, log events of the Standard, Trace,
Interaction, and Debug levels) are generated.
The same as all.
Log events of the Trace level and higher (that is, log events of the Standard, Interaction, and Trace levels) are generated, but log events of the Debug level are not generated.
Log events of the Interaction level and higher (that is, log events of the Standard and Interaction levels) are generated, but log events of the Trace and Debug levels are not generated.
Log events of the Standard level are generated, but log events of the Interaction, Trace, and Debug levels are not generated.
No output is produced.
Changes Take Effect: Immediately
Determines whether a log output is created. If it is, specifies the minimum level of log events generated. The log events levels, starting with the highest
priority level, are Standard, Interaction, Trace, and Debug. See also “Log
Note:
For definitions of the Standard, Interaction, Trace, and Debug log levels, refer to the Framework 8.1 Management Layer User’s Guide,
Framework 8.1 Genesys Administrator Help, or to Framework 8.1
Solution Control Interface Help.
708 Framework 8.1
Chapter 10: Common Configuration Options log Section
buffering
Default Value: true
Valid Values: true false
Enables buffering.
Disables buffering.
Changes Take Effect: Immediately
Turns on/off operating system file buffering. The option is applicable only to the stderr
and stdout
output (see
page 714 ). Setting this option to
true increases the output performance.
Note:
When buffering is enabled, there might be a delay before log messages appear at the console.
segment
Default Value: false
Valid Values: false
<number> KB or
<number>
<number> MB
<number> hr
No segmentation is allowed.
Sets the maximum segment size, in kilobytes. The minimum segment size is
100 KB
.
Sets the maximum segment size, in megabytes.
Sets the number of hours for the segment to stay open. The minimum number is
1
hour.
Changes Take Effect: Immediately
Specifies whether there is a segmentation limit for a log file. If there is, sets the mode of measurement, along with the maximum size. If the current log segment exceeds the size set by this option, the file is closed and a new one is created. This option is ignored if log output is not configured to be sent to a log file.
expire
Default Value: false
Valid Values: false
<number> file or
<number>
<number> day
No expiration; all generated segments are stored.
Sets the maximum number of log files to store. Specify a number from
1
–
1000.
Sets the maximum number of days before log files are deleted. Specify a number from
1
–
100.
Changes Take Effect: Immediately
Determines whether log files expire. If they do, sets the measurement for determining when they expire, along with the maximum number of files
(segments) or days before the files are removed. This option is ignored if log output is not configured to be sent to a log file.
SIP Server—Deployment Guide 709
Chapter 10: Common Configuration Options log Section
Note:
If an option’s value is set incorrectly—out of the range of valid values— it will be automatically reset to
10.
keep-startup-file
Default Value: true
Valid Values: false true
<number> KB
<number> MB
No startup segment of the log is kept.
A startup segment of the log is kept. The size of the segment equals the value of the segment
option.
Sets the maximum size, in kilobytes, for a startup segment of the log.
Sets the maximum size, in megabytes, for a startup segment of the log.
Changes Take Effect: After restart
Specifies whether a startup segment of the log, containing the initial T-Server configuration, is to be kept. If it is, this option can be set to true
or to a specific size. If set to true
, the size of the initial segment will be equal to the size of the regular log segment defined by the segment
option. The value of this option will be ignored if segmentation is turned off (that is, if the segment
option set to false
).
Note:
In SIP Server multi-threaded logging, the default value of true
applies only to the T-Server thread log file, and is not reflected in other logs that are generated by running threads.
messagefile
Default Value: As specified by a particular application
Valid Values:
<string>.lms
(message file name)
Changes Take Effect: Immediately, if an application cannot find its
*.lms
file at startup
Specifies the file name for application-specific log events. The name must be valid for the operating system on which the application is running. The option value can also contain the absolute path to the application-specific
*.lms
file.
Otherwise, an application looks for the file in its working directory.
Warning!
An application that does not find its
*.lms
file at startup cannot generate application-specific log events and send them to Message
Server.
710 Framework 8.1
Chapter 10: Common Configuration Options log Section
message_format
Default Value: short
Valid Values: short full
An application uses compressed headers when writing log records in its log file.
An application uses complete headers when writing log records in its log file.
Changes Take Effect: Immediately
Specifies the format of log record headers that an application uses when writing logs in the log file. Using compressed log record headers improves application performance and reduces the log file’s size.
With the value set to short
:
•
A header of the log file or the log file segment contains information about the application (such as the application name, application type, host type, and time zone), whereas single log records within the file or segment omit this information.
•
A log message priority is abbreviated to
Std
,
Int
,
Trc
, or
Dbg
, for Standard,
Interaction, Trace, or Debug messages, respectively.
•
The message ID does not contain the prefix
GCTI
or the application type
ID.
A log record in the full format looks like this:
2002-05-07T18:11:38.196 Standard localhost cfg_dbserver GCTI-00-05060
Application started
A log record in the short format looks like this:
2002-05-07T18:15:33.952 Std 05060 Application started
Note:
Whether the full or short format is used, time is printed in the format
option.
time_convert
Default Value:
Local
Valid Values: local utc
The time of log record generation is expressed as a local time, based on the time zone and any seasonal adjustments. Time zone information of the application’s host computer is used.
The time of log record generation is expressed as Coordinated
Universal Time (UTC).
Changes Take Effect: Immediately
Specifies the system in which an application calculates the log record time when generating a log file. The time is converted from the time in seconds since the Epoch (00:00:00 UTC, January 1, 1970).
SIP Server—Deployment Guide 711
Chapter 10: Common Configuration Options log Section
time_format
Default Value: time
Valid Values: time locale
ISO8601
The time string is formatted according to the
HH:MM:SS.sss
(hours, minutes, seconds, and milliseconds) format.
The time string is formatted according to the system’s locale.
The date in the time string is formatted according to the ISO 8601 format. Fractional seconds are given in milliseconds.
Changes Take Effect: Immediately
Specifies how to represent, in a log file, the time when an application generates log records.
A log record’s time field in the ISO 8601 format looks like this:
2001-07-24T04:58:10.123
print-attributes
Default Value: false
Valid Values: true false
Attaches extended attributes, if any exist, to a log event sent to log output.
Does not attach extended attributes to a log event sent to log output.
Changes Take Effect: Immediately
Specifies whether the application attaches extended attributes, if any exist, to a log event that it sends to log output. Typically, log events of the Interaction log level and Audit-related log events contain extended attributes. Setting this option to true
enables audit capabilities, but negatively affects performance.
Genesys recommends enabling this option for Solution Control Server and
Configuration Server when using audit tracking. For other applications, refer to Genesys 8.1 Combined Log Events Help to find out whether an application generates Interaction-level and Audit-related log events; if it does, enable the option only when testing new interaction scenarios.
check-point
Default Value:
1
Valid Values:
0
–
24
Changes Take Effect: Immediately
Specifies, in hours, how often the application generates a check point
log event, to divide the log into sections of equal time. By default, the application generates this log event every hour. Setting the option to
0
prevents the generation of check-point
events.
712 Framework 8.1
Chapter 10: Common Configuration Options log Section
memory
Default Value: No default value
Valid Values:
<string>
(memory file name)
Changes Take Effect: Immediately
Specifies the name of the file to which the application regularly prints a
snapshot of the memory output, if it is configured to do this (see “Log Output
). The new snapshot overwrites the previously written data. If the application terminates abnormally, this file will contain the latest log messages. Memory output is not recommended for processors with a CPU frequency lower than 600 MHz.
Note:
If the file specified as the memory
file is located on a network drive, an application does not create a snapshot file (with the extension
*.memory.log
).
memory-storage-size
Default Value:
2 MB
Valid Values:
<number> KB or
<number>
The size of the memory output, in kilobytes.
The minimum value is
128 KB.
<number> MB
The size of the memory output, in megabytes.
The maximum value is
64 MB.
Changes Take Effect: When memory output is created
Specifies the buffer size for log output to the memory, if configured. See also
“Log Output Options” on page 714
.
no-memory-mapping
Default Value:
0
Valid Values:
0, 1
Changes Take Effect: At restart
Specifies if a
.snapshot.log
file is disabled. By default, SIP Server generates a
.snapshot.log
file. It is recommended to set this option to
1
if log files are generated in network storage rather than on the local disk.
spool
Default Value: The application’s working directory
Valid Values:
<path>
(the folder, with the full path to it)
Changes Take Effect: Immediately
Specifies the folder, including full path to it, in which an application creates temporary files related to network log output. If you change the option value while the application is running, the change does not affect the currently open network output.
SIP Server—Deployment Guide 713
Chapter 10: Common Configuration Options log Section
compatible-output-priority
Default Value: false
Valid Values: true false
The log of the level specified by
“Log Output Options” is sent to the
specified output.
The log of the level specified by
“Log Output Options” and higher
levels is sent to the specified output.
Changes Take Effect: Immediately
Specifies whether the application uses 6.x output logic. For example, you configure the following options in the log
section for a 6.x application and for a 7.x application:
[log] verbose = all debug = file1 standard = file2
The log file content of a 6.x application is as follows:
•
file1
contains Debug messages only.
•
file2
contains Standard messages only.
The log file content of a 7.x application is as follows:
•
file1
contains Debug, Trace, Interaction, and Standard messages.
•
file2
contains Standard messages only.
If you set compatible-output-priority
to true
in the 7.x application, its log file content will be the same as for the 6.x application.
Warning!
Genesys does not recommend changing the default value of this option unless you have specific reasons to use the 6.x log output logic—that is, to mimic the output priority as implemented in releases 6.x. Setting this option to true
affects log consistency.
Log Output Options
To configure log outputs, set log level options ( all
,
,
,
and/or
) to the desired types of log output (
stdout, stderr, network, memory,
and/or
[filename]
, for log file output).
You can use:
•
One log level option to specify different log outputs.
•
One log output type for different log levels.
•
Several log output types simultaneously, to log events of the same or different log levels.
714 Framework 8.1
Chapter 10: Common Configuration Options log Section
You must separate the log output types by a comma when you are configuring
more than one output for the same log level. See “Examples” on page 719 .
Warnings!
• If you direct log output to a file on the network drive, an application does not create a snapshot log file (with the extension
*.snapshot.log
) in case it terminates abnormally.
• Directing log output to the console (by using the stdout
or stderr
settings) can affect application performance. Avoid using these log output settings in a production environment.
Note:
The log output options are activated according to the setting of the
configuration option.
all
Default Value: No default value
Valid Values (log output types): stdout stderr network
Log events are sent to the Standard output ( stdout
).
Log events are sent to the Standard error output ( stderr
).
Log events are sent to Message Server, which can reside anywhere on the network. Message Server stores the log events in the Log Database.
memory
[filename]
Setting the all
log level option to the network
output enables an application to send log events of the
Standard, Interaction, and
Trace
levels to Message Server.
Debug
-level log events are neither sent to Message Server nor stored in the Log Database.
Log events are sent to the memory output on the local disk. This is the safest output in terms of the application performance.
Log events are stored in a file with the specified name. If a path is not specified, the file is created in the application’s working directory.
Changes Take Effect: Immediately
Specifies the outputs to which an application sends all log events. The log output types must be separated by a comma when more than one output is configured. For example: all = stdout, logfile
Note:
To ease the troubleshooting process, consider using unique names for log files that different applications generate.
SIP Server—Deployment Guide 715
Chapter 10: Common Configuration Options log Section
alarm
Default Value: No default value
Valid Values (log output types): stdout stderr network memory
[filename]
Log events are sent to the Standard output ( stdout
).
Log events are sent to the Standard error output ( stderr
).
Log events are sent to Message Server, which resides anywhere on the network, and Message Server stores the log events in the
Log Database.
Log events are sent to the memory output on the local disk. This is the safest output in terms of the application performance.
Log events are stored in a file with the specified name. If a path is not specified, the file is created in the application’s working directory.
Changes Take Effect: Immediately
Specifies the outputs to which an application sends the log events of the Alarm level. The log output types must be separated by a comma when more than one output is configured. For example: standard = stderr, network
standard
Default Value: No default value
Valid Values (log output types): stdout stderr network memory
[filename]
Log events are sent to the Standard output ( stdout
).
Log events are sent to the Standard error output ( stderr
).
Log events are sent to Message Server, which can reside anywhere on the network. Message Server stores the log events in the Log Database.
Log events are sent to the memory output on the local disk. This is the safest output in terms of the application performance.
Log events are stored in a file with the specified name. If a path is not specified, the file is created in the application’s working directory.
Changes Take Effect: Immediately
Specifies the outputs to which an application sends the log events of the
Standard
level. The log output types must be separated by a comma when more than one output is configured. For example: standard = stderr, network
716 Framework 8.1
Chapter 10: Common Configuration Options log Section
interaction
Default Value: No default value
Valid Values (log output types): stdout stderr network memory
[filename]
Log events are sent to the Standard output ( stdout
).
Log events are sent to the Standard error output ( stderr
).
Log events are sent to Message Server, which can reside anywhere on the network. Message Server stores the log events in the Log Database.
Log events are sent to the memory output on the local disk. This is the safest output in terms of the application performance.
Log events are stored in a file with the specified name. If a path is not specified, the file is created in the application’s working directory.
Changes Take Effect: Immediately
Specifies the outputs to which an application sends the log events of the
Interaction
level and higher (that is, log events of the
Standard
and
Interaction
levels). The log outputs must be separated by a comma when more than one output is configured. For example: interaction = stderr, network
trace
Default Value: No default value
Valid Values (log output types): stdout stderr network memory
[filename]
Log events are sent to the Standard output ( stdout
).
Log events are sent to the Standard error output ( stderr
).
Log events are sent to Message Server, which can reside anywhere on the network. Message Server stores the log events in the Log Database.
Log events are sent to the memory output on the local disk. This is the safest output in terms of the application performance.
Log events are stored in a file with the specified name. If a path is not specified, the file is created in the application’s working directory.
Changes Take Effect: Immediately
Specifies the outputs to which an application sends the log events of the
Trace level and higher (that is, log events of the
Standard
,
Interaction
, and
Trace levels). The log outputs must be separated by a comma when more than one output is configured. For example: trace = stderr, network
SIP Server—Deployment Guide 717
Chapter 10: Common Configuration Options log Section
debug
Default Value: No default value
Valid Values (log output types): stdout stderr memory
[filename]
Log events are sent to the Standard output ( stdout
).
Log events are sent to the Standard error output ( stderr
).
Log events are sent to the memory output on the local disk. This is the safest output in terms of the application performance.
Log events are stored in a file with the specified name. If a path is not specified, the file is created in the application’s working directory.
Changes Take Effect: Immediately
Specifies the outputs to which an application sends the log events of the
Debug level and higher (that is, log events of the
Standard
,
Interaction
,
Trace
, and
Debug
levels). The log output types must be separated by a comma when more than one output is configured—for example: debug = stderr, /usr/local/genesys/logfile
Note:
Debug
-level log events are never sent to Message Server or stored in the Log Database.
Log File Extensions
You can use the following file extensions to identify log files that an application creates for various types of output:
•
*.log
—Assigned to log files when you configure output to a log file. For example, if you set standard = confservlog
for Configuration Server, it prints log messages into a text file called confservlog.<time_stamp>.log.
•
*.qsp
—Assigned to temporary (spool) files when you configure output to the network but the network is temporarily unavailable. For example, if you set standard = network
for Configuration Server, it prints log messages into a file called confserv.<time_stamp>.qsp
during the time the network is not available.
•
*.snapshot.log
—Assigned to files that contain the output snapshot when you configure output to a log file. The file contains the last log messages that an application generates before it terminates abnormally. For example, if you set standard = confservlog
for Configuration Server, it prints the last log message into a file called confserv.<time_stamp>.snapshot.log
in case of failure.
Note:
Provide
*.snapshot.log
files to Genesys Customer Care when reporting a problem.
718 Framework 8.1
Chapter 10: Common Configuration Options log Section
•
*.memory.log
—Assigned to log files that contain the memory output snapshot when you configure output to memory and redirect the most recent memory output to a file. For example, if you set standard = memory and memory = confserv
for Configuration Server, it prints the latest memory output to a file called confserv.<time_stamp>.memory.log
.
Examples
This section presents examples of a log
section that you might configure for an application when that application is operating in production mode and in two lab modes, debugging and troubleshooting.
Production Mode Log Section
[log] verbose = standard standard = network, logfile
With this configuration, an application only generates the log events of the
Standard
level and sends them to Message Server, and to a file named logfile
, which the application creates in its working directory. Genesys recommends that you use this or a similar configuration in a production environment.
Warning!
Directing log output to the console (by using the stdout
or stderr settings) can affect application performance. Avoid using these log output settings in a production environment.
Lab Mode Log Section
[log] verbose = all all = stdout, /usr/local/genesys/logfile trace = network
With this configuration, an application generates log events of the
Standard
,
Interaction
,
Trace
, and
Debug
levels, and sends them to the standard output and to a file named logfile
, which the application creates in the
/usr/local/genesys/
directory. In addition, the application sends log events of the
Standard
,
Interaction
, and
Trace
levels to Message Server. Use this configuration to test new interaction scenarios in a lab environment.
Failure-Troubleshooting Log Section
[log] verbose = all standard = network all = memory
SIP Server—Deployment Guide 719
Chapter 10: Common Configuration Options log Section memory = logfile memory-storage-size = 32 MB
With this configuration, an application generates log events of the
Standard level and sends them to Message Server. It also generates log events of the
Standard
,
Interaction
,
Trace
, and
Debug
levels, and sends them to the memory output. The most current log is stored to a file named logfile,
which the application creates in its working directory. Increased memory storage allows an application to save more of the log information generated before a failure.
Note:
If you are running an application on UNIX, and you do not specify any files in which to store the memory output snapshot, a core file that the application produces before terminating contains the most current application log. Provide the application’s core file to Genesys
Customer Care when reporting a problem.
Debug Log Options
The options in this section enable you to generate
Debug logs containing information about specific operations of an application.
x-conn-debug-open
Default Value:
0
Valid Values:
0
1
Log records are not generated.
Log records are generated.
Changes Take Effect: After restart
Generates
Debug log records about “open connection” operations of the application.
Warning!
Use this option only when requested by Genesys Customer Care.
x-conn-debug-select
Default Value:
0
Valid Values:
0
1
Log records are not generated.
Log records are generated.
Changes Take Effect: After restart
Generates
Debug log records about “socket select” operations of the application.
Warning!
Use this option only when requested by Genesys Customer Care.
720 Framework 8.1
Chapter 10: Common Configuration Options log Section
x-conn-debug-timers
Default Value:
0
Valid Values:
0
1
Log records are not generated.
Log records are generated.
Changes Take Effect: After restart
Generates
Debug log records about the timer creation and deletion operations of the application.
Warning!
Use this option only when requested by Genesys Customer Care.
x-conn-debug-write
Default Value:
0
Valid Values:
0
1
Log records are not generated.
Log records are generated.
Changes Take Effect: After restart
Generates
Debug log records about “write” operations of the application.
Warning!
Use this option only when requested by Genesys Customer Care.
x-conn-debug-security
Default Value:
0
Valid Values:
0
1
Log records are not generated.
Log records are generated.
Changes Take Effect: After restart
Generates
Debug log records about security-related operations, such as
Transport Layer Security and security certificates.
Warning!
Use this option only when requested by Genesys Customer Care.
x-conn-debug-api
Default Value:
0
Valid Values:
0
1
Log records are not generated.
Log records are generated.
Changes Take Effect: After restart
Generates
Debug log records about connection library function calls.
Warning!
Use this option only when requested by Genesys Customer Care.
SIP Server—Deployment Guide 721
Chapter 10: Common Configuration Options log-extended Section
x-conn-debug-dns
Default Value:
0
Valid Values:
0
1
Log records are not generated.
Log records are generated.
Changes Take Effect: After restart
Generates
Debug log records about DNS operations.
Warning!
Use this option only when requested by Genesys Customer Care.
x-conn-debug-all
Default Value:
0
Valid Values:
0
1
Log records are not generated.
Log records are generated.
Changes Take Effect: After restart
Generates
Debug log records about open connection, socket select, timer creation and deletion, write, security-related, and DNS operations, and connection library function calls. This option is the same as enabling or disabling all of the previous x-conn-debug-<op type>
options.
Warning!
Use this option only when requested by Genesys Customer Care.
log-extended Section
This section must be called log-extended.
level-reassign-<eventID>
Default Value: Default value of log event
<eventID>
Valid Values: alarm standard interaction trace debug none
The log level of log event
<eventID>
is set to
Alarm.
The log level of log event
<eventID>
is set to
Standard.
The log level of log event
<eventID>
is set to
Interaction.
The log level of log event
<eventID>
is set to
Trace.
The log level of log event
<eventID>
is set to
Debug.
Log event
<eventID>
is not recorded in a log.
Changes Take Effect: Immediately
Specifies a log level for log event
<eventID>
that is different than its default level, or disables log event
<eventID>
completely. If no value is specified, the log event retains its default level. This option is useful when you want to customize the log level for selected log events.
722 Framework 8.1
Chapter 10: Common Configuration Options log-extended Section
These options can be deactivated with the option level-reassign-disable
Warning!
Use caution when making these changes in a production environment.
Depending on the log configuration, changing the log level to a higher priority may cause the log event to be logged more often or to a greater number of outputs. This could affect system performance.
Likewise, changing the log level to a lower priority may cause the log event to be not logged at all, or to be not logged to specific outputs, thereby losing important information. The same applies to any alarms associated with that log event.
In addition to the preceding warning, take note of the following:
•
Logs can be customized only by release 7.6 or later applications.
•
When the log level of a log event is changed to any level except none
, it is subject to the other settings in the
[log]
section at its new level. If set to none
, it is not logged and is therefore not subject to any log configuration.
•
Using this feature to change the log level of a log changes only its priority; it does not change how that log is treated by the system. For example, increasing the priority of a log to
Alarm
level does not mean that an alarm will be associated with it.
•
Each application in a High Availability (HA) pair can define its own unique set of log customizations, but the two sets are not synchronized with each other. This can result in different log behavior depending on which application is currently in primary mode.
•
This feature is not the same as a similar feature in Universal Routing
Server (URS) release 7.2 or later. In this Framework feature, the priority of log events are customized. In the URS feature, the priority of debug messages only are customized. Refer to the Universal Routing Reference
Manual for more information about the URS feature.
•
You cannot customize any log event that is not in the unified log record format. Log events of the
Alarm, Standard, Interaction,
and
Trace
levels feature the same unified log record format.
Example
This is an example of using customized log level settings, subject to the following log configuration:
[log] verbose=interaction all=stderr interaction=log_file standard=network
SIP Server—Deployment Guide 723
Chapter 10: Common Configuration Options log-filter Section
Before the log levels of the log are changed:
•
Log event 1020, with default level standard, is output to stderr
and log_file,
and sent to Message Server.
•
Log event 2020, with default level standard, is output to stderr
and log_file,
and sent to Message Server.
•
Log event 3020, with default level trace, is output to stderr.
•
Log event 4020, with default level debug, is output to stderr.
Extended log configuration section:
[log-extended] level-reassign-1020=none level-reassign-2020=interaction level-reassign-3020=interaction level-reassign-4020=standard
After the log levels are changed:
•
Log event 1020 is disabled and not logged.
•
Log event 2020 is output to stderr
and log_file.
•
Log event 3020 is output to stderr
and log_file.
•
Log event 4020 is output to stderr
and log_file,
and sent to Message
Server.
level-reassign-disable
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
When this option is set to true
, the original (default) log level of all log events in the
[log-extended]
section are restored. This option is useful when you want to use the default levels, but not delete the customization statements.
log-filter Section
The log-filter
section contains configuration options used to define the default treatment of filtering data in log output. This section contains one configuration option, default-filter-type.
Refer to the chapter “Hide
Selected Data in Logs” in the Genesys 8.1 Security Deployment Guide for complete information about this option.
log-filter-data Section
The log-filter-data
section contains configuration options used to define the treatment of filtering data in log output on a key-by-key basis. This section contains one configuration option in the form of
<key name>
. Refer to the
724 Framework 8.1
Chapter 10: Common Configuration Options security Section chapter “Hide Selected Data in Logs” in the Genesys 8.1 Security Deployment
Guide for complete information about this option.
security Section
The security section contains configuration options used to specify security elements for your system. In addition to other options that may be required by your application, this section contains the configuration option disable-rbac
, which is used to enable or disable Role-Based Access Control for an application. Refer to the chapter “Role-Based Access Control” in the Genesys
8.1 Security Deployment Guide for complete information about this option.
sml Section
This section must be called sml
.
Options in this section are defined in the
Annex
of the
Application
object, as follows:
•
in Genesys Administrator—
Application
object >
Options
tab >
Advanced
View (Annex)
•
in Configuration Manager—
Application
object >
Properties
dialog box >
Annex
tab
Warning!
Use the first three options in this section (
,
heartbeat-period-thread-class-<n>
great care, and only with those applications of which support for this functionality has been announced. Failure to use these options properly could result in unexpected behavior, from ignoring the options to an unexpected restart of the application.
heartbeat-period
Default Value: None
Valid Values:
0
3-604800
This method of detecting an unresponsive application is not used by this application.
Length of timeout, in seconds; equivalent to 3 seconds–7 days.
Changes Take Effect: Immediately
Specifies the maximum amount of time, in seconds, in which heartbeat messages are expected from an application. If Local Control Agent (LCA) does not receive a heartbeat message from the application within this period, it assumes the application is not responding and carries out corrective action.
SIP Server—Deployment Guide 725
Chapter 10: Common Configuration Options sml Section
This option can also be used to specify the maximum heartbeat interval for threads registered with class zero (0). This thread class is reserved for use by the Management Layer only.
If this option is not configured or is set to zero (
0
), heartbeat detection is not used by this application.
heartbeat-period-thread-class-<n>
Default Value: None
Valid Values:
0
3-604800
Value specified by heartbeat-period
Length of timeout, in seconds; equivalent to 3 seconds–7 days.
Changes Take Effect: Immediately
Specifies the maximum amount of time, in seconds, in which heartbeat messages are expected from a thread of class < n
> registered by an application.
If a heartbeat message from the thread is not received within this period, the thread is assumed to be not responding, and therefore, the application is unable to provide service.
If this option is not configured or is set to zero (
0
), but the application has registered one or more threads of class < n
>, the value specified by the value of
for the application will also be applied to these threads.
Refer to application-specific documentation to determine what thread classes, if any, are used.
hangup-restart
Default Value: true
Valid Values: true
, false
Changes Take Effect: Immediately
If set to true
(the default), specifies that LCA is to restart the unresponsive application immediately, without any further interaction from Solution Control
Server.
If set to false,
specifies that LCA is only to generate a notification that the application has stopped responding.
suspending-wait-timeout
Default Value:
10
Valid Values:
5-600
Changes Take Effect: Immediately
Specifies a timeout (in seconds) after the Stop Graceful command is issued to an application during which the status of the application should change to
Suspending
if the application supports graceful shutdown. If the status of the application does not change to
Suspending
before the timeout expires, it is assumed that the application does not support graceful shutdown, and it is stopped ungracefully.
726 Framework 8.1
Chapter 10: Common Configuration Options common Section
Use this option if you are unsure whether the Application supports graceful shutdown.
Note:
Genesys recommends that you do not set this option for any
Management Layer component (Configuration Server, Message
Server, Solution Control Server, or SNMP Master Agent) or any DB
Server. These components by definition do not support graceful shutdown, so this option is not required.
common Section
This section must be called common.
enable-async-dns
Default Value:
0
Valid Values:
0
1
Disables asynchronous processing of DNS requests.
Enables asynchronous processing of DNS requests.
Changes Take Effect: Immediately
Enables the asynchronous processing of DNS requests such as, for example, host-name resolution.
Warnings!
• Use this option only when requested by Genesys Customer
Care.
• Use this option only with T-Servers.
rebind-delay
Default Value:
10
Valid Values:
0
–
600
Changes Take Effect: After restart
Specifies the delay, in seconds, between socket-bind operations that are being executed by the server. Use this option if the server has not been able to successfully occupy a configured port.
Warning!
Use this option only when requested by Genesys Customer Care.
SIP Server—Deployment Guide 727
Chapter 10: Common Configuration Options common Section
728 Framework 8.1
Chapter
11
T-Server Common
Configuration Options
This chapter describes the configuration options that are generally common to all T-Server types, with some exceptions noted. It contains the following sections:
Setting Configuration Options, page 729
agent-reservation Section, page 738
call-cleanup Section, page 752
Translation Rules Section, page 753
Timeout Value Format, page 754
Changes from Release 8.0 to 8.1, page 755
T-Server also supports common log options described in Chapter 10,
“Common Configuration Options,” on page 707 .
Setting Configuration Options
Unless specified otherwise, set T-Server common configuration options in the
Options
of the
Application
object, using one of the following navigation paths:
•
In Genesys Administrator—
Application
object >
Options
tab >
Advanced
View (Options)
•
In Configuration Manager—
Application
object >
Properties
dialog box >
Options tab
SIP Server—Deployment Guide 729
Chapter 11: T-Server Common Configuration Options Mandatory Options
Mandatory Options
Except as noted for certain environments, the configuration of common options is not required for basic T-Server operation.
TServer Section
The
TServer
section contains the configuration options that are used to support the core features common to all T-Servers.
This section must be called
TServer.
ani-distribution
Default Value: inbound-calls-only
Valid Values: inbound-calls-only, all-calls, suppressed
Changes Take Effect: Immediately
Controls the distribution of the ANI information in
TEvent
messages. When this option is set to all-calls,
the
ANI
attribute will be reported for all calls for which it is available. When this option is set to suppressed,
the
ANI
attribute will not be reported for any calls. When this option is set to inbound-calls-only,
the
ANI
attribute will be reported for inbound calls only.
background-processing
Default Value:
true
Valid Values:
true, false
Changes Take Effect: Immediately
When set to true,
T-Server processes all client requests in the background, giving higher priority to the rest of the messages. This ensures that it processes these messages without any significant delay.
With Background Processing functionality enabled, T-Server processes all switch messages immediately and waits until there are no switch messages before processing the message queue associated with T-Server client requests.
T-Server reads all connection sockets immediately and places client requests in the input buffer, which prevents T-Server clients from disconnecting because of configured timeouts.
When T-Server processes client requests from the message queue, requests are processed in the order in which T-Server received them.
When set to false,
T-Server processes multiple requests from one T-Server client before proceeding to the requests from another T-Server client, and so on.
730 Framework 8.1
Chapter 11: T-Server Common Configuration Options TServer Section
background-timeout
Default Value:
60 msec
Valid Values: See “Timeout Value Format” on page 754 .
Changes Take Effect: Immediately
Specifies the time interval that T-Server waits before processing client requests in background mode. You must set the
background-processing option to
true in order for this option to take effect.
check-tenant-profile
Default Value:
false
Valid Values:
true, false
Changes Take Effect: For the next connected client
When set to true,
T-Server only allows a client to register if the client provides the correct name and password of a T-Server Tenant. If the client provides the Tenant name concatenated with a slash (/) and the Tenant password for the Tenant to which T-Server belongs as the value of
AttributeApplicationPassword
in the
TRegisterClient
request, T-Server allows that client to register DNs that are included in the switch configuration in the Configuration Database, but it does not allow the client to register DNs that are not included in the switch configuration.
consult-user-data
Default Value:
separate
Valid Values: separate inherited joint
Stores user data for original and consultation calls in separate structures. The data attached to the original call is available for review or changes only to the parties of that call. The data attached to the consultation call is available only to the parties of the consultation call.
Copies user data from an original call to a consultation call when the consultation call is created; thereafter, stores user data separately for the original and the consultation call. Changes to the original call’s user data are not available to the parties of the consultation call, and vice versa.
Stores user data for an original call and a consultation call in one structure. The user data structure is associated with the original call, but the parties of both the original and consultation calls can see and make changes to the common user data.
Changes Take Effect: For the next consultation call created
Specifies the method for handling user data in a consultation call.
SIP Server—Deployment Guide 731
Chapter 11: T-Server Common Configuration Options TServer Section
Note:
A T-Server client can also specify the
consult-user-data mode in the
Extensions attribute
ConsultUserData key for a conference or transfer request. If it is specified, the method of handling user data is based on the value of the
ConsultUserData key-value pair of the request and takes precedence over the T-Server
consult-user-data option. If it is not specified in the client request, the value specified in the
consult-user-data option applies.
customer-id
Default Value: No default value. (A value must be specified for a multi-tenant environment.)
Valid Values: Any character string
Changes Take Effect: Immediately
Identifies the T-Server customer. You must set this option to the name of the tenant that is using this T-Server. You must specify a value for this option if you are working in a multi-tenant environment.
Note:
Do not configure the
customer-id option for single-tenant environments.
dn-scope
Default Value: undefined
Valid Values: undefined, switch, office, tenant
Changes Take Effect: Immediately
Related Feature: “Switch Partitioning” on page 685
Specifies whether DNs associated with the
Switch, Switching Office,
or
Tenant
objects will be considered in the T-Server monitoring scope, enabling
T-Server to report calls to or from those DNs as internal.
With a value of tenant,
all DNs associated with the switches that are within the
Tenant
will be in the T-Server monitoring scope. With a value of office, all DNs associated with the switches that are within the
Switching Office
will be in the T-Server monitoring scope. With a value of switch,
all DNs associated with the
Switch
will be in the T-Server monitoring scope.
With a value of undefined
(the default), pre-8.x T-Server behavior applies and the switch partitioning is not turned on.
Note:
Setting the option to a value of office
or tenant,
which requires
T-Server to monitor a large set of configuration data, may negatively affect T-Server performance.
732 Framework 8.1
Chapter 11: T-Server Common Configuration Options TServer Section
log-trace-flags
Default Value:
+iscc, +cfg$dn, -cfgserv, +passwd, +udata, -devlink, -sw,
-req, -callops, -conn, -client
Valid Values (in any combination):
+/-iscc
+/-cfg$dn
+/-cfgserv
+/-passwd
+/-udata
+/-devlink
+/-sw
+/-req
+/-callops
+/-conn
+/-client
Turns on/off the writing of information about Inter Server Call
Control (ISCC) transactions.
Turns on/off the writing of information about DN configuration.
Turns on/off the writing of messages from Configuration
Server.
Turns on/off the writing of
AttributePassword
in TEvents.
Turns on/off the writing of attached data.
Turns on/off the writing of information about the link used to send CTI messages to the switch (for multilink environments).
Reserved by Genesys Engineering.
Reserved by Genesys Engineering.
Reserved by Genesys Engineering.
Reserved by Genesys Engineering.
Turns on/off the writing of additional information about the client’s connection.
Changes Take Effect: Immediately
Specifies—using a space-, comma- or semicolon-separated list—the types of information that are written to the log files.
management-port
Default Value:
0
Valid Values:
0 or any valid TCP/IP port
Changes Take Effect: After T-Server is restarted
Specifies the TCP/IP port that management agents use to communicate with
T-Server. If set to
0
(zero), this port is not used.
merged-user-data
Default Value:
main-only
Valid Values: main-only merged-only merged-over-main main-over-merged
T-Server attaches user data from the remaining call only.
T-Server attaches user data from the merging call.
T-Server attaches user data from the remaining and the merging call. In the event of equal keys, T-Server uses data from the merging call.
T-Server attaches data from the remaining and the merging call. In the event of equal keys, T-Server uses data from the remaining call.
Changes Take Effect: Immediately
SIP Server—Deployment Guide 733
Chapter 11: T-Server Common Configuration Options TServer Section
Specifies the data that is attached to the resulting call after a call transfer, conference, or merge completion.
Note:
The option setting does not affect the resulting data for merging calls if the
consult-user-data
option is set to
joint.
(See
“consult-user-data” on page 731 .)
propagated-call-type
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Related Feature: “Switch Partitioning” on page 685
Determines what T-Server reports as the value of the
CallType
attribute in events related to calls that have been synchronized with another site via ISCC, as follows:
•
When set to false,
T-Server reports in events related to calls that have been synchronized with another site via ISCC the same value for the
CallType
attribute as it did in pre-8.0 releases and adds the new
PropagatedCallType
attribute with the value of the
CallType
attribute at the origination site. This provides backward compatibility with existing
T-Server clients.
When set to true,
T-Server reports in events related to calls that have been synchronized with another site via ISCC the same value for the
CallType attribute as at the origination site, and adds the new
LocalCallType
attribute with the same value as
CallType
in pre-8.0 releases.
server-id
Default Value: An integer equal to the value
ApplicationDBID
as reported by
Configuration Server
Valid Values: Any integer from
0
–
16383
Changes Take Effect: Immediately
Specifies the
Server ID
that T-Server uses to generate
Connection ID s and other unique identifiers. In a multi-site environment, you must assign each
T-Server a unique
Server ID,
in order to avoid confusion in reporting applications and T-Server behavior.
Configuration of this option is necessary for Framework environments in which there are two or more instances of the Configuration Database.
Note:
If you do not specify a value for this option, T-Server populates it with the
ApplicationDBID as reported by Configuration Server. Each data object in the Configuration Database is assigned a separate DBID that maintains a unique Server ID for each T-Server configured in the database.
734 Framework 8.1
Chapter 11: T-Server Common Configuration Options license Section
Warning!
Genesys does not recommend using multiple instances of the
Configuration Database.
user-data-limit
Default Value:
16000
Valid Values:
0
–
65535
Changes Take Effect: Immediately
Specifies the maximum size (in bytes) of user data in a packed format.
Note:
When T-Server works in mixed 8.x/7.x/6.x environment, the value of this option must not exceed the default value of
16000
bytes; otherwise, 6.x T-Server clients might fail.
license Section
The License section contains the configuration options that are used to configure T-Server licenses. They set the upper limit of the seat-related DN licenses
(tserver_sdn)
that T-Server tries to check out from a license file. See
“License Checkout” on page 736
.
This section must be called
license.
Notes:
• T-Server also supports the
license-file option described in the
Genesys Licensing Guide.
• The license
section is not applicable to Network T-Server for
DTAG.
• On selected platforms, the limitation of 9999 licenses may no longer apply. Use values greater than 9999 only when instructed by
Genesys Customer Care.
If you use two or more T-Servers, and they share licenses, you must configure the following options in the license
section of the T-Servers.
num-of-licenses
Default Value:
0 or
max
(all available licenses)
Valid Values: String
max or any integer from
0
–
9999
Changes Take Effect: Immediately
Specifies how many DN licenses T-Server checks out. T-Server treats a value of
0
(zero) the same as it treats
max
—that is, it checks out all available licenses.
The sum of all
num-of-licenses values for all concurrently deployed
T-Servers must not exceed the number of seat-related DN licenses
( tserver_sdn
) in the corresponding license file. The primary and backup
SIP Server—Deployment Guide 735
Chapter 11: T-Server Common Configuration Options license Section
T-Servers share the same licenses, and therefore they need to be counted only once. T-Server checks out the number of licenses indicated by the value for this option, regardless of the number actually in use.
num-sdn-licenses
Default Value:
0 or
max
(all DN licenses are seat-related)
Valid Values: String
max
(equal to the value of num-of-licenses
), or any integer from
0
–
9999
Changes Take Effect: Immediately
Specifies how many seat-related licenses T-Server checks out. A value of
0
(zero) means that T-Server does not grant control of seat-related DNs to any client, and it does not look for seat-related DN licenses at all.
The sum of all
num-sdn-licenses values for all concurrently deployed
T-Servers must not exceed the number of seat-related DN licenses
( tserver_sdn
) in the corresponding license file. The primary and backup
T-Servers share the same licenses, and therefore they need to be counted only once. T-Server checks out the number of licenses indicated by the value for this option, regardless of the number actually in use.
Notes:
• For Network T-Servers, Genesys recommends setting this option to
0.
• Be sure to configure in the Configuration Database all the DNs that agents use (Extensions and ACD Positions) and that T-Server should control.
License Checkout
Table 121 shows how to determine the number of seat-related DN licenses that
T-Server attempts to check out. See the examples on
.
Table 121: License Checkout Rules
Options Settings a num-of-licenses num-sdn-licenses
max (or 0) max (or 0) max (or 0) x x x max x
0 max y
0
License Checkout b
Seat-related DN licenses
all available x
0 x min (y, x)
0
736 Framework 8.1
Chapter 11: T-Server Common Configuration Options license Section a. In this table, the following conventions are used: x
and y
- are positive integers; max
is the maximum number of licenses that T-Server can check out; min (y, x) is the lesser of the two values defined by y
and x
, respectively.
b. The License Checkout column shows the number of licenses that T-Server attempts to check out. The actual number of licenses will depend on the licenses’ availability at the time of checkout, and it is limited to 9999.
Examples
This section presents examples of option settings in the license
section.
Table 122: Example 1
If...
Options Settings
num-of-licenses = max num-sdn-licenses = max
Then...
License File Settings License Checkout
tserver_sdn = 500 500 seat-related DNs
Table 123: Example 2
If...
Options Settings
num-of-licenses = 1000 num-sdn-licenses = max
Then...
License File Settings License Checkout
tserver_sdn = 500 500 seat-related DNs
Table 124: Example 3
If...
Options Settings
num-of-licenses = 1000 num-sdn-licenses = 400
Then...
License File Settings License Checkout
tserver_sdn = 600 400 seat-related DNs
SIP Server—Deployment Guide 737
Chapter 11: T-Server Common Configuration Options agent-reservation Section
Table 125: Example 4
If...
Options Settings
num-of-licenses = max num-sdn-licenses = 1000
Then...
License File Settings License Checkout
tserver_sdn = 5000 1000 seat-related DNs
agent-reservation Section
The agent-reservation section contains the configuration options that are
used to customize the T-Server Agent Reservation feature. See “Agent
section for details on this feature.
This section must be called
agent-reservation.
Note:
The Agent Reservation functionality is currently a software-only feature that is used to coordinate multiple client applications. This feature does not apply to multiple direct or ACD-distributed calls.
collect-lower-priority-requests
Default Value:
true
Valid Values:
true, false
Changes Take Effect: Immediately
Specifies whether an agent reservation request is collected, depending on its priority during the time interval specified by the request-collection-time configuration option. When set to false,
during the request-collection-time interval T-Server collects reservation requests of the highest priority only, rejecting newly submitted requests that have a lower priority or rejecting all previously submitted requests if a request with a higher priority arrives. When set to true
(the default), agent reservation requests are collected as they were in pre-8.x releases.
reject-subsequent-request
Default Value:
true
Valid Values: true false
T-Server rejects subsequent requests.
A subsequent request prolongs the current reservation made by the same client application for the same agent.
Changes Take Effect: Immediately
738 Framework 8.1
Chapter 11: T-Server Common Configuration Options extrouter Section
Specifies whether T-Server rejects subsequent requests from the same client application, for an agent reservation for the same
Agent
object that is currently reserved.
Note:
Genesys does not recommend setting this option to
false in a multi-site environment in which remote locations use the
Agent-Reservation feature.
request-collection-time
Default Value:
100 msec
Valid Values: See “Timeout Value Format” on page 754 .
Changes Take Effect: Immediately
Specifies the interval that agent reservation requests are collected before a reservation is granted. During this interval, agent reservation requests are delayed, in order to balance successful reservations between client applications
(for example, Universal Routing Servers).
reservation-time
Default Value:
10000 msec
Valid Values: See “Timeout Value Format” on page 754 .
Changes Take Effect: Immediately
Specifies the default interval for which a an Agent DN is reserved. During this interval, the agent cannot be reserved again.
extrouter Section
The extrouter section contains the configuration options that are used to support multi-site environments with the Inter Server Call Control (ISCC) feature. The configuration options in this section of the document are grouped with related options that support the same functionality, as follows:
ISCC Transaction Options, page 741
Transfer Connect Service Options, page 746
Event Propagation Options, page 749
Number Translation Option, page 750
GVP Integration Option, page 750
This configuration section must be called
extrouter.
SIP Server—Deployment Guide 739
Chapter 11: T-Server Common Configuration Options extrouter Section
For a description of the ways in which T-Server supports multi-site configurations and for an explanation of the configuration possibilities for a
multi-site operation, see the “Multi-Site Support”
chapter.
Note:
In a multi-site environment, you must configure the
,
and
options with the same value for both the primary and backup T-Servers. If you do not do this, the value specified for the backup T-Server overrides the value specified for the primary T-Server.
match-call-once
Default Value:
true
Valid Values: true false
ISCC does not process (match) an inbound call that has already been processed (matched).
ISCC processes (attempts to match) a call as many times as it arrives at an ISCC resource or multi-site-transfer target.
Changes Take Effect: Immediately
Specifies how many times ISCC processes an inbound call when it arrives at an ISCC resource. When set to false,
ISCC processes (attempts to match) the call even if it has already been processed.
Note:
To support multi-site tromboning scenarios, this option can be set to false
. Contact Genesys Customer Care to confirm the option setting.
reconnect-tout
Default Value:
5 sec
Valid Values: See “Timeout Value Format” on page 754 .
Changes Take Effect: At the next reconnection attempt
Specifies the time interval after which a remote T-Server attempts to connect to this T-Server after an unsuccessful attempt or a lost connection. The number of attempts is unlimited. At startup, T-Server immediately attempts the first connection, without this timeout.
report-connid-changes
Default Value:
false
Valid Values: true false
EventPartyChanged is generated.
EventPartyChanged is not generated.
Changes Take Effect: Immediately
Specifies whether the destination T-Server generates
EventPartyChanged for the incoming call when the resulting
ConnID attribute is different from the
ConnID attribute of an instance of the same call at the origination location.
740 Framework 8.1
Chapter 11: T-Server Common Configuration Options extrouter Section
use-data-from
Default Value:
current
Valid Values: active original active-dataoriginal-call current
The values of
UserData
and
ConnID
attributes are taken from the consultation call.
The values of
UserData
and
ConnID
attributes are taken from the original call.
The value of the
UserData
attribute is taken from the consultation call and the value of
ConnID
attribute is taken from the original call.
If the value of current
is specified, the following occurs:
• Before the transfer or conference is completed, the
UserData and
ConnID
attributes are taken from the consultation call.
• After the transfer or conference is completed,
EventPartyChanged
is generated, and the
UserData
and
ConnID are taken from the original call.
Changes Take Effect: Immediately
Specifies the call from which the values for the
UserData and
ConnID attributes are taken for a consultation call that is routed or transferred to a remote location.
Note:
For compatibility with the previous T-Server releases, you can use the values
consult, main,
and
consult-user-data for this option. These are aliases for
active, original,
and
current,
respectively.
ISCC Transaction Options
cast-type
Default Value: route, route-uui, reroute, direct-callid, direct-uui, direct-network-callid, direct-notoken, direct-digits, direct-ani, dnis-pool, pullback
Valid Values: route, route-uui, reroute, direct-callid, direct-uui, direct-network-callid, direct-notoken, direct-digits, direct-ani, dnis-pool, pullback
Changes Take Effect: For the next request for the remote service
Specifies—using a space-, comma- or semicolon-separated list—the routing types that can be performed for this T-Server.
The valid values provide for a range of mechanisms that the ISCC feature can support with various T-Servers, in order to pass call data along with calls between locations.
Because switches of different types provide calls with different sets of information parameters, some values might not work with your T-Server. See
Table 115 on page 664 for information about supported transaction types by a
SIP Server—Deployment Guide 741
Chapter 11: T-Server Common Configuration Options extrouter Section specific T-Server. The
chapter also provides detailed descriptions of all transaction types.
Notes:
For compatibility with the previous T-Server releases, you can use the direct
value for this option. This is an alias for direct-callid.
An alias, route-notoken,
has been added to the
route value.
default-dn
Default Value: No default value
Valid Values: Any DN
Changes Take Effect: For the next request for the remote service
Specifies the DN to which a call is routed when a Destination DN
(
AttributeOtherDN
) is not specified in the client’s request for routing. If neither this option nor the client’s request contains the destination DN, the client receives
EventError
.
Note:
This option is used only for requests with route types
route, route-uui, direct-callid, direct-network-callid, direct-uui, direct-notoken, direct-digits,
and
direct-ani.
direct-digits-key
Default Value:
CDT_Track_Num
Valid Values: Any valid key name of a key-value pair from the
UserData attribute
Changes Take Effect: For the next request for the remote service
Specifies the name of a key from the
UserData attribute that contains a string of digits that are used as matching criteria for remote service requests with the direct-digits routing type.
Note:
For compatibility with the previous T-Server releases, this configuration option has an alias value of cdt-udata-key.
742 Framework 8.1
Chapter 11: T-Server Common Configuration Options extrouter Section
dn-for-unexpected-calls
Default Value: No default value
Valid Values: Any DN
Changes Take Effect: Immediately
Specifies a default DN for unexpected calls arriving on an External Routing
Point.
network-request-timeout
Default Value:
20 sec
Valid Values: See “Timeout Value Format” on page 754 .
Changes Take Effect: For the next network request
For a premise T-Server, this option specifies the time interval that the premise
T-Server waits for a response, after relaying a
TNetwork<...>
request to the
Network T-Server. For a Network T-Server, this option specifies the time interval that the Network T-Server waits for a response from an SCP (Service
Control Point), after initiating the processing of the request by the SCP.
When the allowed time expires, the T-Server cancels further processing of the request and generates
EventError
.
register-attempts
Default Value:
5
Valid Values: Any positive integer
Changes Take Effect: For the next registration
Specifies the number of attempts that T-Server makes to register a dedicated
External Routing Point.
register-tout
Default Value:
2 sec
Valid Values: See “Timeout Value Format” on page 754 .
Changes Take Effect: For the next registration
Specifies the time interval after which T-Server attempts to register a dedicated
External Routing Point. Counting starts when the attempt to register a Routing
Point fails.
request-tout
Default Value:
20 sec
Valid Values: See “Timeout Value Format” on page 754 .
Changes Take Effect: For the next request for remote service
Specifies the time interval that a T-Server at the origination location waits for a notification of routing service availability from the destination location.
Counting starts when the T-Server sends a request for remote service to the destination site.
SIP Server—Deployment Guide 743
Chapter 11: T-Server Common Configuration Options extrouter Section
resource-allocation-mode
Default Value:
circular
Valid Values: home circular
T-Server takes an alphabetized (or numerically sequential) list of configured DNs and reserves the first available DN from the top of the list for each new request. For example, if the first DN is not available, the second DN is allocated for a new request. If the first
DN is freed by the time the next request comes, the first DN is allocated for this next request.
T-Server takes the same list of configured DNs, but reserves a subsequent DN for each subsequent request. For example, when the first request comes, T-Server allocates the first DN; when the second request comes, T-Server allocates the second DN; and so on.
T-Server does not reuse the first DN until reaching the end of the DN list.
Changes Take Effect: Immediately
Specifies the manner in which T-Server allocates resources (that is, DNs of the
External Routing Point type and Access Resources with the
Resource Type set to dnis
) for multi-site transaction requests.
resource-load-maximum
Default Value:
0
Valid Values: Any positive integer
Changes Take Effect: Immediately
Specifies the maximum number of ISCC routing transactions that can be concurrently processed at a single DN of the
External Routing Point route type. After a number of outstanding transactions at a particular DN of the
External Routing Point type reaches the specified number, T-Server considers the DN not available. Any subsequent request for this DN is queued until the number of outstanding transactions decreases. A value of
0
(zero) means that no limitation is set to the number of concurrent transactions at a single External Routing Point. In addition, the
0 value enables T-Server to perform load balancing of all incoming requests among all available External
Routing Points, in order to minimize the load on each DN.
route-dn
Default Value: No default value
Valid Values: Any DN
Changes Take Effect: Immediately
Specifies the DN that serves as a Routing Point for the route transaction type in the multiple-to-one access mode.
744 Framework 8.1
Chapter 11: T-Server Common Configuration Options extrouter Section
timeout
Default Value:
60 sec
Valid Values: See “Timeout Value Format” on page 754 .
Changes Take Effect: For the next request for remote service
Specifies the time interval that the destination T-Server waits for a call routed from the origination location. Counting starts when this T-Server notifies the requesting T-Server about routing service availability. The timeout must be long enough to account for possible network delays in call arrival.
transaction-state
Default Value: default
Valid Values: default, by-islink
Changes Take Effect: On the next ISCC origination transaction
Enables improved historical reporting of data for multi-site scenarios where a call is successfully delivered to the destination site but is not answered by the target agent.
•
The default
value supports backward compatibility when T-Server reports the origination transaction and the IS-Link as unsuccessful, and stops event propagation (if configured). As a result, in most cases, historical reporting applications do not take into account the calls on different sites that are part of the same interaction.
•
The by-islink
value forces T-Server to report both the transaction and the
IS-Link as successful and to maintain event propagation in those multi-site scenarios.
Keep this option’s value consistent between all T-Servers participating in multi-site transactions.
Limitation: If No-Answer Supervision is used, the agent-no-answer timeout must not exceed the value of the timeout
option in the extrouter
section (the default
value of this option is
60 sec
).
use-implicit-access-numbers
Default Value:
false
Valid Values:
true, false
Changes Take Effect: After T-Server is restarted
Determines whether an External Routing Point in which at least one access number is specified is eligible for use as a resource for calls coming from switches for which an access number is not specified in the External Routing
Point. If this option is set to false,
the External Routing Point is not eligible for use as a resource for calls coming from such switches. If this option is set to true,
an implicit access number for the External Routing Point, composed of the switch access code and the DN number of the External Routing Point, will be used.
Note:
If an External Routing Point does not have an access number specified, this option will not affect its use.
SIP Server—Deployment Guide 745
Chapter 11: T-Server Common Configuration Options extrouter Section
Transfer Connect Service Options
tcs-queue
Default Value: No default value
Valid Values: Any valid DN number
Changes Take Effect: For the next request for the remote service
Specifies the TCS DN number to which a call, processed by the TCS feature, is dialed after the originating external router obtains an access number. This option applies only if the
option is activated.
tcs-use
Default Value:
never
Valid Values: never always app-defined
The TCS feature is not used.
The TCS feature is used for every call.
In order to use the TCS feature for a multi-site call transfer request, a client application must add a key-value pair with a
TC-type
key and a nonempty string value to either the
UserData or Extensions attribute of the request.
Changes Take Effect: Immediately
Specifies whether the Transfer Connect Service (TCS) feature is used.
Note:
For compatibility with the previous T-Server releases, you can use the value up-app-depended for this option. This is an alias for app-defined.
ISCC/COF Options
cof-ci-defer-create
Default Value:
0
Valid Values: See “Timeout Value Format” on page 754 .
Changes Take Effect: Immediately
Specifies the time interval that T-Server waits for call data from the switch before generating a negative response for a call data request from a remote
T-Server. If T-Server detects the matching call before this timeout expires, it sends the requested data. This option applies only if the
option is set to true.
746 Framework 8.1
Chapter 11: T-Server Common Configuration Options extrouter Section
cof-ci-defer-delete
Default Value:
0
Valid Values: See “Timeout Value Format” on page 754 .
Changes Take Effect: Immediately
Specifies the time interval that T-Server waits before deleting call data that might be overflowed. If set to
0,
deletion deferring is disabled. This option applies only if the
option is set to true.
cof-ci-req-tout
Default Value:
500 msec
Valid Values: See “Timeout Value Format” on page 754 .
Changes Take Effect: For the next COF operation
Specifies the time interval during which T-Server will wait for call data requested with respect to a call originated at another site. After T-Server sends the call data request to remote T-Servers, all events related to this call will be suspended until either the requested call data is received or the specified timeout expires. This option applies only if the
option is set to true.
cof-ci-wait-all
Default Value:
false
Valid Values: true false
T-Server waits for responses from all T-Servers that might have the requested call data before updating the call data with the latest information.
T-Server updates the call data with the information received from the first positive response.
Changes Take Effect: Immediately
Specifies whether T-Server, after sending a request for matching call data, waits for responses from other T-Servers before updating the call data (such as
CallHistory
,
ConnID
, and
UserData
) for a potentially overflowed call. The waiting period is specified by the
and
options.
This option applies only if the
true.
cof-feature
Default Value:
false
Valid Values:
true, false
Changes Take Effect: Immediately
Enables or disables the Inter Server Call Control/Call Overflow (ISCC/COF) feature.
SIP Server—Deployment Guide 747
Chapter 11: T-Server Common Configuration Options extrouter Section
cof-rci-tout
Default Value:
10 sec
Valid Values: See “Timeout Value Format” on page 754 .
Changes Take Effect: For the next COF operation
Specifies the time interval that T-Server waits for call data from other
T-Servers’ transactions. Counting starts when
expires. This option applies only if the
true.
local-node-id
Default Value:
0
Valid Values:
0 or any positive integer
Changes Take Effect: Immediately
This option, if enabled, checks all networked calls against the specified
NetworkNodeID
(the identity of the switch to which the call initially arrived). If the
NetworkNodeID is the same as the value of this option, the request for call information is not sent. The default value of
0 disables the functionality of this option. To establish an appropriate
NetworkNodeID,
specify a value other than the default. This option applies only if the
option is set to true
.
Note:
This option applies only to T-Server for Nortel Communication Server
2000/2100.
default-network-call-id-matching
Default Value: No default value
Valid Values: See the “T-Server-Specific Configuration Options” chapter for an option description for your T-Server
Changes Take Effect: Immediately
When a value for this option is specified, T-Server uses the
NetworkCallID attribute for the ISCC/COF call matching.
To activate this feature, the
true.
Note:
SIP Server and several T-Servers support the
NetworkCallID
attribute for the ISCC/COF call matching in a way that requires setting this option to a specific value. For information about the option value that is specific for your T-Server, see the “T-Server-Specific Configuration
Options” chapter of your T-Server Deployment Guide.
748 Framework 8.1
Chapter 11: T-Server Common Configuration Options extrouter Section
Event Propagation Options
compound-dn-representation
Default Value: true
Valid Values: true, false
Changes Take Effect: Immediately
Specifies which format T-Server uses to represent a DN when reporting an
OtherDN
or
ThirdPartyDN
attribute in event propagation messages.
When set to true, the
<switch>::DN
(compound) format is used. This option value supports backward compatibility for pre-8.x T-Server ISCC/EPP functionality and is provided for multi-site deployments where the same DNs are configured under several switches.
When set to false,
the
DN
(non-compound) format is used. This option value ensures more transparent reporting of
OtherDN
or
ThirdPartyDN
attributes and is recommended for all single-site deployments, as well as for multi-site deployments that do not have the same DNs configured under several switches.
This option applies only if the
list
.
Note:
Local DNs are always represented in the non-compound
(DN)
form.
epp-tout
Default Value:
0
Valid Values: See “Timeout Value Format” on page 754 .
Changes Take Effect: Immediately
Specifies the time interval, in seconds, during which T-Server attempts to resolve race conditions that may occur in deployments that use switch partitioning or intelligent trunks. This option applies only if the
list
.
Note:
If the time interval is not long enough to account for possible network switching delays, T-Server may produce duplicated events, such as events that are propagated by the ISCC and generated locally.
event-propagation
Default Value:
list
Valid Values: list off
Changes in user data and party events are propagated to remote locations through call distribution topology.
The feature is disabled. Changes in user data and party events are not propagated to remote locations.
Changes Take Effect: Immediately
Specifies whether the Event Propagation feature is enabled.
SIP Server—Deployment Guide 749
Chapter 11: T-Server Common Configuration Options backup-sync Section
Number Translation Option
inbound-translator-<n>
Default Value: No default value
Valid Value: Any valid name
Changes Take Effect: Immediately
Specifies the name of another configuration section as the value for the inbound-translator
option. For example, inbound-translator-1 = ani-translator where ani-translator
is the name of the configuration that describes the translation rules for inbound numbers.
GVP Integration Option
handle-vsp
Default Value: no
Valid Values: requests events all no
ISCC will process and adjust requests related to this DN and containing a
Location
attribute before submitting them to the service provider.
ISCC will process and adjust events received from the service provider and containing a
Location
attribute before distributing them to T-Server clients.
ISCC will process and adjust both events and requests.
No ISCC processing of such requests and events takes place.
Changes Take Effect: Immediately
Specifies the way ISCC handles events from, and requests to, an external service provider registered for a DN using the
AddressType
attribute set to
VSP.
backup-sync Section
The backup-synchronization section contains the configuration options that are used to support a high-availability ( hot standby redundancy type) configuration.
This section must be called
backup-sync.
Note:
These options apply only to T-Servers that support the
hot standby redundancy type.
750 Framework 8.1
Chapter 11: T-Server Common Configuration Options backup-sync Section
addp-remote-timeout
Default Value:
0
Valid Values: Any integer from
0
–
3600
Changes Take Effect: Immediately
Specifies the time interval, in seconds, that the redundant T-Server waits for a response from this T-Server after sending a polling signal. The default value of
0
(zero) disables the functionality of this option. To establish an appropriate timeout, specify a value other than the default. This option applies only if the
option is set to addp.
addp-timeout
Default Value:
0
Valid Values: Any integer from
0
–
3600
Changes Take Effect: Immediately
Specifies the time interval, in seconds, that this T-Server waits for a response from another T-Server after sending a polling signal. The default value of
0
(zero) disables the functionality of this option. To establish an appropriate timeout, specify a value other than the default. This option applies only if the
addp.
addp-trace
Default Value:
off
Valid Values: off, false, no
No trace (default).
local, on, true, yes
Trace on this T-Server side only.
remote full, both
Trace on the redundant T-Server side only.
Full trace (on both sides).
Changes Take Effect: Immediately
Specifies whether addp
messages are traced in a log file, to what level the trace is performed, and in which direction. This option applies only if the
option is set to addp
.
protocol
Default Value:
default
Valid Values: default addp
The ADDP feature is not active.
Activates the Advanced Disconnect Detection Protocol.
Changes Take Effect: When the next connection is established
Specifies the name of the method used to detect connection failures. If you specify the
addp
value, you must also specify a value for the addp-timeout , addp-remote-timeout ,
and
For secure TLS connections, you must set this option to addp
.
SIP Server—Deployment Guide 751
Chapter 11: T-Server Common Configuration Options call-cleanup Section
sync-reconnect-tout
Default Value:
20 sec
Valid Values: See “Timeout Value Format” on page 754 .
Changes Take Effect: Immediately
Specifies the time interval after which the backup T-Server attempts to reconnect to the primary server (for a synchronized link).
call-cleanup Section
The call-cleanup section contains the configuration options that are used to control detection and cleanup of stuck calls in T-Server. For more information on stuck call handling, refer to the “Stuck Call Management” chapter in the
Framework 8.1 Management Layer User’s Guide.
This section must be called
call-cleanup.
cleanup-idle-tout
Default Value:
0
Valid Values: See “Timeout Value Format” on page 754 .
Changes Take Effect: Immediately
Specifies the time interval, in seconds, that T-Server waits for a call to be updated from its last update. After this time elapses, if no new events about the call are received, T-Server clears this call as a stuck call, either by querying the switch (if a CTI link provides such capabilities) or by deleting the call information from memory unconditionally. The default value of
0 disables the stuck calls cleanup.
Note:
If the call-cleanup functionality is enabled in T-Server for Avaya
Communication Manager, the UCID (Universal Call ID) feature must be enabled on the switch as well. This allows the UCID to be generated and passed to T-Server.
notify-idle-tout
Default Value:
0
Valid Values: See “Timeout Value Format” on page 754
Changes Take Effect: Immediately
Specifies the time interval, in seconds, that T-Server waits for a call to be updated from its last update. After this time elapses, if no new events about the call are received, T-Server reports this call as a stuck call. The default value of
0 disables the stuck calls notification.
752 Framework 8.1
Chapter 11: T-Server Common Configuration Options Translation Rules Section
periodic-check-tout
Default Value:
10 min
Valid Values: See “Timeout Value Format” on page 754
Changes Take Effect: Immediately
Specifies the time interval for periodic checks for stuck calls. These checks affect both notification and cleanup functionality, and are made by checking the T-Server’s own call information with call information available in the switch. For performance reasons, T-Server does not verify whether the notify-idle-tout or
cleanup-idle-tout option has expired before performing this check.
Note:
Setting this option to a value of less than a few seconds can affect
T-Server performance.
Examples
This section presents examples of option settings in the call-cleanup
section.
Example 1
cleanup-idle-tout = 0 notify-idle-tout = 0 periodic-check-tout = 10
With these settings, T-Server will not perform any checks for stuck calls.
Example 2
cleanup-idle-tout = 0 notify-idle-tout = 5 min periodic-check-tout = 10 min
With these settings, T-Server performs checks every 10 minutes and sends notifications about all calls that have been idle for at least 5 minutes.
Example 3
cleanup-idle-tout = 20 min notify-idle-tout = 5 min periodic-check-tout = 10 min
With these settings, T-Server performs checks every 10 minutes, sends notifications about all calls that have been idle for at least 5 minutes, and attempts to clean up all calls that have been idle for more than 20 minutes.
Translation Rules Section
The section name is specified by the inbound-translator-< n >
option. It contains options that define translation rules for inbound numbers.
You can choose any name for this section, provided that it matches the value of the section. Every option in this section corresponds to a rule and must conform to the format described below. You can configure as many rules as necessary to accommodate your business needs.
SIP Server—Deployment Guide 753
Chapter 11: T-Server Common Configuration Options security Section
rule-<n>
Default Value: No default value
Valid Value: Any valid string in the following format: in-pattern=<input pattern value>;out-pattern=<output pattern value>
Changes Take Effect: Immediately
Defines a rule to be applied to an inbound number. The two parts of the option value describe the input and output patterns in the rule. When configuring the
pattern values, follow the syntax defined in “Using ABNF for Rules” on page 673
. See “Configuring Number Translation” on page 680
for examples of these rules as well as detailed instructions for creating rules for your installation. For example, a value for this configuration option might look like this: rule-01 = in-pattern=0111#CABBB*ccD;out-pattern=ABD
security Section
The security
section contains the configuration options that are used to configure secure data exchange between T-Servers and other Genesys components. Refer to the Genesys 8.1 Security Deployment Guide for complete information on the security configuration.
Timeout Value Format
This section of the document describes the values to use for those T-Server common options that set various timeouts. The current format allows you to use fractional values and various time units for timeout settings.
For timeout-related options, you can specify any value that represents a time interval, provided that it is specified in one of the following formats:
[[[
hours
:]
minutes
:]
seconds
][
milliseconds
] or
[
hours hr][
minutes min][
seconds sec][
milliseconds msec]
Where a time unit name in italic (such as hours) is to be replaced by an integer value for this time unit.
Integer values with no measuring units are still supported, for compatibility with previous releases of T-Server. When you do not specify any measuring units, the units of the default value apply. For example, if the default value equals
60 sec
, specifying the value of
30 sets the option to
30
seconds.
754 Framework 8.1
Chapter 11: T-Server Common Configuration Options Changes from Release 8.0 to 8.1
Example 1
The following settings result in a value of 1 second, 250 milliseconds: sync-reconnect-tout = 1.25
sync-reconnect-tout = 1 sec 250 msec
Example 2
The following settings result in a value of 1 minute, 30 seconds: timeout = 1:30 timeout = 1 min 30 sec
Changes from Release 8.0 to 8.1
Table 126 lists the configuration options that:
•
Are new or changed in the 8.1 release of T-Server
•
Have been added or changed since the most recent 8.0 release of this document
If a configuration option has been replaced with another that enables the same functionality, the new option name and its location in this chapter are noted.
Table 126: Option Changes from Release 8.0 to 8.1
Option Name Option Values Type of
Change
TServer Section
background-processing true, false
See Details
Details
Default value changed to true.
See the option description on
SIP Server—Deployment Guide 755
Chapter 11: T-Server Common Configuration Options Changes from Release 8.0 to 8.1
756 Framework 8.1
Supplements
Related Documentation
Resources
The following resources provide additional information that is relevant to this software. Consult these additional resources as necessary.
SIP Server Solution
•
The SIP Server 8.1 High-Availability Deployment Guide , which contains reference information related to SIP Server high-availability deployment options, workflows, and deployment procedures for each supported operating system.
•
The
SIP Server 8.1 Integration Reference Manual
, which contains reference information related to integrating SIP Server with SIP softswitches and gateways.
•
The
Genesys Media Server Deployment Guide
, which will help you configure, install, and use Genesys Media Server.
•
The
Framework 7.6 Stream Manager Deployment Guide
, which will help you configure, install, and use Stream Manager.
•
Release Notes and Product Advisories for this product, which are available on the Genesys Documentation website .
Management Framework
•
The
Framework 8.1 Deployment Guide
, which will help you configure, install, start, and stop Framework components.
•
The Framework 8.1 Configuration Options Reference Manual, which will provide you with descriptions of configuration options for other
Framework components.
•
The Framework 8.1 Configuration Manager Help, which will help you use
Configuration Manager.
SIP Server—Deployment Guide 757
Related Documentation Resources
Genesys
•
The
Genesys Events and Models Reference Manual
, which contains the
T-Library API, information on
TEvents,
and an extensive collection of call models.
•
Genesys Technical Publications Glossary
, which provides a comprehensive list of the Genesys and computer-telephony integration
(CTI) terminology and acronyms used in this document.
•
Genesys Migration Guide
, which provides documented migration strategies for Genesys product releases. Contact Genesys Customer Care for more information.
Information about supported operating systems and third-party software is available on the Genesys Documentation website in the following documents:
•
Genesys Supported Operating Environment Reference Guide
•
Genesys Supported Media Interfaces Reference Manual
Consult the following additional resources as necessary:
•
Genesys Hardware Sizing Guide
, which provides information about
Genesys hardware sizing guidelines for the Genesys 8.x releases.
•
Genesys Interoperability Guide
, which provides information on the compatibility of Genesys products with various Configuration Layer
Environments; Interoperability of Reporting Templates and Solutions; and
Gplus Adapters Interoperability.
•
Genesys Licensing Guide
, which introduces you to the concepts, terminology, and procedures that are relevant to the Genesys licensing system.
•
Genesys Database Sizing Estimator 8.x Worksheets
, which provides a range of expected database sizes for various Genesys products.
For additional system-wide planning tools and information, see the releasespecific listings of System-Level Documents on the Genesys Documentation website .
Genesys product documentation is available on the:
•
Genesys Customer Care website .
•
Genesys Documentation website .
•
Genesys Documentation Library DVD, which you can order by e-mail from Genesys Order Management at [email protected]
.
758 Framework 8.1
Document Conventions
Document Conventions
This document uses certain stylistic and typographical conventions—introduced here—that serve as shorthands for particular kinds of information.
Document Version Number
A version number appears at the bottom of the inside front cover of this document. Version numbers change as new information is added to this document. Here is a sample version number:
80fr_ref_06-2008_v8.0.001.00
You will need this number when you are talking with Genesys Customer Care about this product.
Screen Captures Used in This Document
Screen captures from the product graphical user interface (GUI), as used in this document, may sometimes contain minor spelling, capitalization, or grammatical errors. The text accompanying and explaining the screen captures corrects such errors except when such a correction would prevent you from installing, configuring, or successfully using the product. For example, if the name of an option contains a usage error, the name would be presented exactly as it appears in the product GUI; the error would not be corrected in any accompanying text.
Type Styles
Table 127 describes and illustrates the type conventions that are used in this
document.
SIP Server—Deployment Guide 759
Document Conventions
Table 127: Type Styles
Type Style Used For Examples
Italic • Document titles
• Emphasis
• Definitions of (or first references to) unfamiliar terms
• Mathematical variables
Also used to indicate placeholder text within code samples or commands, in the special case where angle brackets are a required part of the syntax (see the note about angle brackets on
).
Please consult the Genesys Migration
Guide for more information.
Do not use this value for this option.
A customary and usual practice is one that is widely accepted and used within a particular industry or profession.
The formula, x +1 = 7 where x stands for . . .
Monospace font
(Looks like teletype
or typewriter text
)
All programming identifiers and GUI elements. This convention includes:
• The names of directories, files, folders, configuration objects, paths, scripts, dialog boxes, options, fields, text and list boxes, operational modes, all buttons (including radio buttons), check boxes, commands, tabs, CTI events, and error messages.
• The values of options.
• Logical arguments and command syntax.
• Code samples.
Also used for any text that users must manually enter during a configuration or installation procedure, or on a command line.
Select the
Show variables on screen check box.
In the
Operand
text box, enter your formula.
Click
OK
to exit the
Properties
dialog box.
T-Server distributes the error messages in
EventError
events.
If you select true
for the inbound-bsnscalls
option, all established inbound calls on a local agent are considered business calls.
Enter exit
on the command line.
Square brackets ([ ])
A particular parameter or value that is optional within a logical argument, a command, or some programming syntax. That is, the presence of the parameter or value is not required to resolve the argument, command, or block of code. The user decides whether to include this optional information.
smcp_server -host [/flags]
Angle brackets
(< >)
A placeholder for a value that the user must specify. This might be a DN or a port number specific to your enterprise.
Note: In some cases, angle brackets are required characters in code syntax (for example, in XML schemas). In these cases, italic text is used for placeholder values.
smcp_server -host <confighost>
760 Framework 8.1
X
Index
Symbols
[] (square brackets)
. . . . . . . . . . . . . . 760
< > (angle brackets)
<key name> common log option
Numerics
1pcc transfer
. . . . . . . . . . . . . . . . . 167
3pcc transfer
. . . . . . . . . . . . . . . . . 167
3rd-party known limitations
A accept-dn-type configuration option
Access Code configuration
. . . . . . . . . . . . . . . . 695
defined
. . . . . . . . . . . . . . . . . 58
acw-in-idle-force-ready configuration option
acw-persistent-reasons configuration option
addp-remote-timeout configuration option
addp-timeout configuration option
addp-trace configuration option
Advanced Disconnect Detection Protocol
after-call-divert-destination configuration option
Extension key
. . . . . . . . . . . . . . . 422
after-routing-timeout configuration option
Extension key
. . . . . . . . . . . . . . . 431
after-routing-timeout-action configuration option
Agent agent-greeting
. . . . . . . . . . . . . . . 551
agent-no-answer-action
agent-no-answer-overflow
agent-no-answer-timeout
agent-strict-id
. . . . . . . . . . . . . . . 449
Agent Login objects
agent reservation defined
. . . . . . . . . . . . . . . . . . 643
agent-dn
Extension key
. . . . . . . . . . . . . . . 434
agent-emu-login-on-call configuration option
agent-greeting configuration option
Extension key
. . . . . . . . . . . . . . . 429
agent-greeting-type
Extension key
. . . . . . . . . . . . . . . 429
agent-group configuration option
emulated agent options
agent-logout-on-unreg configuration option
AgentLogoutOnUnregister
Extension key
. . . . . . . . . . . . . . . 428
agent-logout-reassoc configuration option
agent-no-answer-action configuration option
agent-no-answer-overflow configuration option
agent-no-answer-timeout configuration option
agent-reject-route-point configuration option
agent-reservation section configuration options
–
agent-strict-id configuration option
AgentVideo
Extension key
. . . . . . . . . . . . . . . 437
alarm common log option
Alert-Info header
. . . . . . . . . . . . . . . 104
SIP Server—Deployment Guide 761
Index all common log option
alternate gateway selection
alternate ringtones
. . . . . . . . . . . . . . 104
alternate-route-cof (ISCC protocol parameter)
. . . . . . . . . . . . . . 697
alternate-route-profile configuration option
am-detected configuration option
angle brackets
. . . . . . . . . . . . . . . . 760
ANI
. . . . . . . . . . . . . . . . . . . . . . 657
ani-distribution configuration option
AnsMachine
Extension key
. . . . . . . . . . . . . . . 422
AOC-Destination-DN
Extension key
. . . . . . . . . . . . . . . 422
app command line parameter
Application objects multi-site operation
application server mode
AssistMode
Extension key
. . . . . . . . . . . . . . . 425
associating ACD Queue with Routing Point
Asterisk-based Voice Mail agent group registration
agent login registration
extension registration
feature configuration
Genesys voice mail configuration adapter
message waiting indicator
overview
. . . . . . . . . . . . . . . . . . 116
AttributeExtensions after-call-divert-destination
after-routing-timeout
agent-dn
. . . . . . . . . . . . . . . . . . 434
agent-greeting
. . . . . . . . . . . . . . . 429
agent-greeting-type
AgentLogoutOnUnregister
AgentVideo
. . . . . . . . . . . . . . . . 437
AnsMachine
. . . . . . . . . . . . . . . . 422
AOC-Destination-DN
AssistMode
. . . . . . . . . . . . . . . . 425
busy-on-reject
. . . . . . . . . . . . . . . 435
call_timeguard_timeout
charge-type
. . . . . . . . . . . . . . . . 428
connect-nailedup-on-login
ConvertOtherDN
. . . . . . . . . . . . . . 435
CPNDigits
. . . . . . . . . . . . . . . . . 433
customer-greeting
Dest-Capacity
. . . . . . . . . . . . . . . 436
DisplayName
. . . . . . . . . . . . . . . 433
divert-on-ringing
. . . . . . . . . . . . . . 427
dn
. . . . . . . . . . . . . . . . . . . . . 434
DNIS_OVER
. . . . . . . . . . . . . . . . 426
FaxDest
. . . . . . . . . . . . . . . . . . 422
762 feature
. . . . . . . . . . . . . . . . . . 434
Geolocation
. . . . . . . . . . . . . . . . 436
geo-location
. . . . . . . . . . . . . . . . 435
LCTPartiesLength
LCTParty<n>
. . . . . . . . . . . . . . . 432
LCTParty<n>_location
LCTSupervisor<n>
LCTSupervisor<n>_location
LCTSupervisor<n>_mode
LCTSupervisor<n>_monitoredDN
login-id
. . . . . . . . . . . . . . . . . . 434
MonitorMode
. . . . . . . . . . . . . . . 424
MonitorScope
. . . . . . . . . . . . . . . 424
monitor-type
. . . . . . . . . . . . . . . . 434
music
. . . . . . . . . . . . . . . . . . . 429
music-on-hold
. . . . . . . . . . . . . . . 429
NO_ANSWER_ACTION
NO_ANSWER_OVERFLOW
NO_ANSWER_TIMEOUT
original-dialplan-digits
overflow-location
password
. . . . . . . . . . . . . . . . . 434
post-feature-dn
. . . . . . . . . . . . . . 434
ReasonCode
record
. . . . . . . . . . . . . . . . . 423
record-agent-greeting
sdn-licenses-available
sdn-licenses-in-use
sdp-c-host
. . . . . . . . . . . . . . . . . 427
sdp-m-port-high
. . . . . . . . . . . . . . 428
sdp-m-port-low
. . . . . . . . . . . . . . 427
SilenceDest
. . . . . . . . . . . . . . . . 423
SIP_MIME_HEADERS
Transfer-Type
. . . . . . . . . . . . . . . 425
UseDialPlan
. . . . . . . . . . . . . . . . 426
User-Agent
. . . . . . . . . . . . . . . . 436
VideoFile
. . . . . . . . . . . . . . . . . 437
audio-codecs configuration option
audio-codecs (DN level) configuration option
authenticate-requests configuration option
auto-answer
. . . . . . . . . . . . . . . . . 106
auto-answer-after (DN level) configuration option
auto-logout-ready (Application level) configuration option
auto-logout-ready (DN level) configuration option
auto-logout-timeout (Application level) configuration option
auto-logout-timeout (DN level) configuration option
auto-redirect-enabled configuration option
Framework 8.1
Index
B background-processing configuration option
background-timeout configuration option
Back-to-Back User Agent
backup-mode configuration option
backup-sync section configuration options
–
backwds-compat-acw-behavior configuration option
bandwidth requirements
beep-duration configuration option
blind-transfer-enabled configuration option
brackets angle
. . . . . . . . . . . . . . . . . . . . 760
square
. . . . . . . . . . . . . . . . . . . 760
bsns-call-dev-types configuration option
buffering common log option
busy-on-reject
Extension key
. . . . . . . . . . . . . . . 435
busy-tone configuration option
busy-tone-duration configuration option
C
Call Recording emergency
. . . . . . . . . . . . . . . . . 129
feature configuration
overview
. . . . . . . . . . . . . . . . . . 126
Call Supervision assistance request
configuration options
feature configuration
feature limitations
hiding supervisor presence
intrusion
. . . . . . . . . . . . . . . . . . 146
monitoring session
multi-site supervision
scopes
. . . . . . . . . . . . . . . . . . . 144
supervisor auto-release
types
. . . . . . . . . . . . . . . . . . . . 145
call_timeguard_timeout
Extension key
. . . . . . . . . . . . . . . 433
call-cleanup section configuration options
–
call-max-outstanding configuration option
SIP Server—Deployment Guide call-monitor-acw configuration option
call-observer-with-hold configuration option
call-rq-gap configuration option
Calls Outside the Premise find-trunk-by-location
cancel-monitor-on-disconnect configuration option
cancel-monitor-on-unpark configuration option
capacity configuration option
capacity-group configuration option
capacity-sip-error-code configuration option
capacity-tlib-error-code configuration option
cast-type configuration option
CDN
. . . . . . . . . . . . . . . . . . . . . 662
changes from 8.0 to 8.1
SIP Server configuration options
T-Server common configuration options
charge-type configuration option
Extension key
. . . . . . . . . . . . . . . 428
check-point common log option
check-tenant-profile configuration option
cid-enable-on-vtp configuration option
clamp-dtmf-allowed configuration option
clamp-dtmf-enabled configuration option
Class of Service
–
dialing rule format
feature configuration
outbound dialing rules
ring-through rules
transformation
. . . . . . . . . . . . . . . 184
cleanup-idle-tout configuration option
clid-withheld-name configuration option
Code property
cof-ci-defer-create configuration option
cof-ci-defer-delete configuration option
cof-ci-req-tout configuration option
cof-ci-wait-all configuration option
763
Index cof-feature configuration option
cof-rci-tout configuration option
collect-lower-priority-requests configuration option
collect-tone configuration option
command line parameters
app
. . . . . . . . . . . . . . . . . . . . . 65
host
. . . . . . . . . . . . . . . . . . . . . 65
l
. . . . . . . . . . . . . . . . . . . . . . . 66
lmspath
. . . . . . . . . . . . . . . . . . . 66
nco X/Y
. . . . . . . . . . . . . . . . . . . 66
port
. . . . . . . . . . . . . . . . . . . . . 65
V
. . . . . . . . . . . . . . . . . . . . . . . 66
commenting on this document
common configuration options
–
common section
. . . . . . . . . . . . . . 727
disable-rbac
. . . . . . . . . . . . . . . . 725
enable-async-dns
hangup-restart
. . . . . . . . . . . . . . . 726
heartbeat-period
. . . . . . . . . . . . . . 725
heartbeat-period-thread-class-<n>
log section
. . . . . . . . . . . . . . .708
–
log-extended section
–
log-filter section
. . . . . . . . . . . . . . 724
log-filter-data section
–
mandatory
. . . . . . . . . . . . . . . . . 708
rebind-delay
. . . . . . . . . . . . . . . . 727
security section
. . . . . . . . . . . . . . 725
setting
. . . . . . . . . . . . . . . . . . . 707
sml section
. . . . . . . . . . . . . .725
–
suspending-wait-timeout
common log options
–
<key name>
. . . . . . . . . . . . . . . . 724
alarm
. . . . . . . . . . . . . . . . . . . 716
all
. . . . . . . . . . . . . . . . . . . . . 715
buffering
. . . . . . . . . . . . . . . . . . 709
check-point
. . . . . . . . . . . . . . . . 712
compatible-output-priority
debug
. . . . . . . . . . . . . . . . . . . 718
default-filter-type
. . . . . . . . . . . . . . 724
expire
. . . . . . . . . . . . . . . . . . . 709
interaction
. . . . . . . . . . . . . . . . . 717
keep-startup-file
. . . . . . . . . . . . . . 710
level-reassign-<eventID>
level-reassign-disable
log section
. . . . . . . . . . . . . . .708
–
log-extended section
–
log-filter section
. . . . . . . . . . . . . . 724
log-filter-data section
–
mandatory options
memory
. . . . . . . . . . . . . . . . . . 713
memory-storage-size
message_format
. . . . . . . . . . . . . . 711
messagefile
. . . . . . . . . . . . . . . . 710
no-memory-mapping
764 print-attributes
. . . . . . . . . . . . . . . 712
segment
. . . . . . . . . . . . . . . . . . 709
setting
. . . . . . . . . . . . . . . . . . . 707
spool
. . . . . . . . . . . . . . . . . . . 713
standard
. . . . . . . . . . . . . . . . . . 716
time_convert
. . . . . . . . . . . . . . . 711
time_format
. . . . . . . . . . . . . . . . 712
trace
. . . . . . . . . . . . . . . . . . . . 717
verbose
. . . . . . . . . . . . . . . . . . 708
x-conn-debug-all
x-conn-debug-api
x-conn-debug-dns
x-conn-debug-open
x-conn-debug-security
x-conn-debug-select
x-conn-debug-timers
x-conn-debug-write
common options common log options
–
common section
mandatory options
sml section
. . . . . . . . . . . . . . 725
–
common section common options
compatible-output-priority common log option
compound-dn-representation configuration option
Configuration Manager configuring SIP Server
configuration options accept-dn-type
. . . . . . . . . . . . . . 621
acw-in-idle-force-ready
acw-persistent-reasons
addp-remote-timeout
addp-timeout
. . . . . . . . . . . . . . . 751
addp-trace
. . . . . . . . . . . . . . . . . 751
after-call-divert-destination
after-routing-timeout
after-routing-timeout-action
agent-emu-login-on-call
agent-greeting
. . . . . . . . . . . . . . 551
agent-group
. . . . . . . . . . . . . . . . 446
agent-logout-on-unreg
agent-logout-reassoc
agent-no-answer-action
agent-no-answer-overflow
agent-no-answer-timeout
agent-reject-route-point
agent-reservation section
–
agent-strict-id
. . . . . . . . . . . . . . . 449
alternate-route-profile
am-detected
. . . . . . . . . . . . . . . . 449
ani-distribution
. . . . . . . . . . . . . . 730
audio-codecs
. . . . . . . . . . . . . . . 450
audio-codecs (DN level)
authenticate-requests
auto-answer-after (DN level)
Framework 8.1
Index auto-logout-ready (Application level)
auto-logout-ready (DN level)
auto-logout-timeout (Application level)
auto-logout-timeout (DN level)
auto-redirect-enabled
background-processing
background-timeout
backup-mode
. . . . . . . . . . . . . . . 621
backup-sync section
–
backwds-compat-acw-behavior
beep-duration
. . . . . . . . . . . . . . . 554
blind-transfer-enabled
bsns-call-dev-types
busy-tone
. . . . . . . . . . . . . . . . . 453
busy-tone-duration
call-cleanup section
–
call-max-outstanding
call-monitor-acw
. . . . . . . . . . . . . . 453
call-observer-with-hold
call-rq-gap
. . . . . . . . . . . . . . . . . 621
cancel-monitor-on-disconnect
cancel-monitor-on-unpark
capacity
. . . . . . . . . . . . . . . . . . 555
capacity-group
. . . . . . . . . . . . . . . 555
capacity-sip-error-code
capacity-tlib-error-code
cast-type
. . . . . . . . . . . . . . . . . . 741
changes from 8.0 to 8.1
charge-type
. . . . . . . . . . . . . . . . 556
check-tenant-profile
cid-enable-on-vtp
clamp-dtmf-allowed
clamp-dtmf-enabled
cleanup-idle-tout
. . . . . . . . . . . . . . 752
clid-withheld-name
cof-ci-defer-create
cof-ci-defer-delete
cof-ci-req-tout
. . . . . . . . . . . . . . . 747
cof-ci-wait-all
. . . . . . . . . . . . . . . 747
cof-feature
. . . . . . . . . . . . . . . . . 747
cof-rci-tout
. . . . . . . . . . . . . . . . . 748
collect-lower-priority-requests
collect-tone
. . . . . . . . . . . . . . . . 455
common log options
–
common options
–
compound-dn-representation
connect-nailedup-on-login (Application level)
. . . . . . . . . . . . . . . . . . . 456
connect-nailedup-on-login (DN level)
consult-user-data
contact
. . . . . . . . . . . . . . . . . . . 557
contact-list
. . . . . . . . . . . . . . . . . 559
contacts-backup
. . . . . . . . . . . . . . 559
control-remote-vip-scripts
control-vip-scripts
correct-rqid
. . . . . . . . . . . . . . . . 621
cos
. . . . . . . . . . . . . . . . . . . . . 560
cpd-capability
. . . . . . . . . . . . . . . 561
SIP Server—Deployment Guide cpd-info-timeout
. . . . . . . . . . . . . . 458
cpn
. . . . . . . . . . . . . . . . . . . . 560
cpn-digits-to-both-legs
cpn-dnis
. . . . . . . . . . . . . . . . . . 561
cpn-self
. . . . . . . . . . . . . . . . . . 561
customer-greeting
customer-id
. . . . . . . . . . . . . . . . 732
default-dn
. . . . . . . . . . . . . . . . . 742
default-dn (Application level)
default-dn (DN level)
default-dn-type
. . . . . . . . . . . . . . 622
default-monitor-mode
default-monitor-scope
default-music (Application level)
default-music (DN level)
default-network-call-id-matching
default-route-point-order
default-video-file
device-rq-gap
. . . . . . . . . . . . . . . 622
dial-plan (Application level)
dial-plan (DN level)
direct-digits-key
. . . . . . . . . . . . . . 742
disable-media-before-greeting
disconnect-nailedup-timeout (Application level)
. . . . . . . . . . . . . . . . . . 462
disconnect-nailedup-timeout (DN level)
display-name
. . . . . . . . . . . . . . . 565
divert-on-ringing
dn-del-mode
. . . . . . . . . . . . . . . 622
dn-for-unexpected-calls
dn-scope
. . . . . . . . . . . . . . . 685
dr-forward
. . . . . . . . . . . . . . . . . 463
dr-forward (DN level)
dr-oosp-transfer-enabled
dr-peer-trunk
. . . . . . . . . . . . . . . 464
dtmf-payload
. . . . . . . . . . . . . . . 464
dual-dialog-enabled
emergency-backup
emergency-callback-plan
emergency-device
emergency-recording-cleanup-enabled
emergency-recording-filename
emulated-login-state
emulate-login
. . . . . . . . . . . . . . . 622
enable-agentlogin-presence
enable-agentlogin-subscribe (DN level)
enable-busy-on-routed-calls
enable-direct-pickup
enable-extension-headers
enable-ims
. . . . . . . . . . . . . . 466
enable-iscc-dial-plan
enable-legacy-reporting
enable-oosp-alarm
enable-strict-location-match
enable-unknown-gateway
encoding
. . . . . . . . . . . . . . . . . 469
enforce-external-domains
enforce-p-asserted-identity
765
Index enforce-privacy
. . . . . . . . . . . . . . 571
enforce-rfc3455
. . . . . . . . . . . . . . 572
enforce-trusted
epp-tout
. . . . . . . . . . . . . . . .686
event-propagation
event-ringing-on-100trying
expire-call-tout
. . . . . . . . . . . . . . . 622
extensions-<n>
external-registrar
extn-no-answer-overflow
ext-no-answer-timeout
extrouter section
–
fast-busy-tone
. . . . . . . . . . . . . . . 472
fax-detected
. . . . . . . . . . . . . . . . 472
feature-code-park
feature-code-pickup
feature-code-retrieve
find-outbound-msml-by-location
find-trunk-by-location
fmfm-confirmation-digit
fmfm-confirmation-timeout
fmfm-prompt-file
. . . . . . . . . . . . . . 474
fmfm-trunk-group
forced-notready
. . . . . . . . . . . . . . 475
force-p-early-media
force-register
. . . . . . . . . . . . . . . 572
force-register-disable-totag
geo-location
. . . . . . . . . . . . . . . . 573
graceful-shutdown-sip-timeout
greeting-after-merge
greeting-call-type-filter (Agent-Login level)
greeting-call-type-filter (Application level)
greeting-delay-events
greeting-notification
greeting-repeat-once-party
greeting-stops-no-answer-timeout
handle-vsp
. . . . . . . . . . . . . . .621
hg-busy-timeout
. . . . . . . . . . . . . . 575
hg-members
. . . . . . . . . . . . . . . . 575
hg-noanswer-timeout
hg-preferred-site
. . . . . . . . . . . . . . 575
hg-queue-limit
. . . . . . . . . . . . . . . 576
hg-queue-timeout
hg-type
. . . . . . . . . . . . . . . . . . 576
hide-msml-location
http-port
. . . . . . . . . . . . . . . . . . 478
ignore-presence-after-nas (Application level)
. . . . . . . . . . . . . . . . . . . 478
ignore-presence-after-nas (DN level)
ims-3pcc-prefix
. . . . . . . . . . . . . . 479
ims-default-icid-prefix
ims-default-icid-suffix
ims-default-orig-ioi
ims-propagate-pcvector
ims-puid-domain
. . . . . . . . . . . . . . 480
ims-route
. . . . . . . . . . . . . . . . . 481
ims-sip-domain
. . . . . . . . . . . . . . 481
ims-sip-params
. . . . . . . . . . . . . . 481
766 ims-skip-ifc
. . . . . . . . . . . . . . . . 482
ims-use-term-legs-for-routing
inbound-bsns-calls
inbound-translator-<n>
include-dial-plan-
info-pass-through (Application level)
info-pass-through (DN level)
inherit-bsns-type
init-dnis-by-ruri
. . . . . . . . . . . . . . 483
internal-bsns-calls
internal-registrar-domains
internal-registrar-enabled
internal-registrar-persistent
intrusion-enabled
keep-mute-after-conference
kpl-interval
. . . . . . . . . . . . . . . . 622
kpl-loss-rate
. . . . . . . . . . . . . . . . 622
kpl-tolerance
. . . . . . . . . . . . . . . 622
legal-guard-time
. . . . . . . . . . . . . . 485
license section
–
local-node-id
. . . . . . . . . . . . . . . 748
logout-on-disconnect
logout-on-out-of-service
log-reduce-cpu-threshold
log-trace-flags
. . . . . . . . . . . . . . . 733
make-call-alert-info
make-call-rfc3725-flow
management-port
mandatory options
map-sip-errors
. . . . . . . . . . . . . . 487
match-call-once
. . . . . . . . . . . . . . 740
max-legs-per-sm
max-parking-time
max-pred-req-delay
merged-user-data
monitor-internal-calls
monitor-party-on-hold
msml-enable-record-extensions
msml-location-alarm-timeout
msml-mute-type
. . . . . . . . . . . . . . 489
msml-oos-recover-enabled
msml-record-metadata-support
msml-record-support
msml-support
. . . . . . . . . . . . . . . 490
music-in-conference-file
music-in-queue-file
music-listen-disconnect
music-on-hold
. . . . . . . . . . . . . . . 578
music-on-pbxpark
mwi-agent-enable
mwi-domain
. . . . . . . . . . . . . . . . 492
mwi-extension-enable
mwi-group-enable
mwi-host
. . . . . . . . . . . . . . . . . 492
mwi-implicit-notify
mwi-mode
. . . . . . . . . . . . . . . . . 493
mwi-notify-unregistered-dn
mwi-port
. . . . . . . . . . . . . . . . . . 494
Framework 8.1
Index nas-indication
. . . . . . . . . . . . . . . 622
nas-private
. . . . . . . . . . . . . . . . . 494
network-monitoring-timeout
network-request-timeout
no-answer-action
no-answer-overflow
no-answer-timeout
no-response-dn
. . . . . . . . . . . . . . 580
notify-idle-tout
. . . . . . . . . . . . . . . 752
num-of-licenses
. . . . . . . . . . . . . . 735
num-sdn-licenses
observing-routing-point
ocs-dn
. . . . . . . . . . . . . . . . . . . 581
oos-check
. . . . . . . . . . . . . . . . . 581
oos-error-check
. . . . . . . . . . . . . . 582
oos-force
. . . . . . . . . . . . . . . . . 582
oos-options-max-forwards
oosp-transfer-enabled
operational-stat-timeout
outbound-bsns-calls
out-rule-<n>
. . . . . . . . . . . . . . . . 583
overflow-location-map
overload-ctrl-call-rate-capacity
overload-ctrl-call-tapplytreatmentrequests-rate
. . . . . . . . . . . . . . 496
overload-ctrl-call-trequests-rate
overload-ctrl-call-tupdateuserdatarequests-rate
. . . . . . . . . . . . . . 497
overload-ctrl-dialog-rate-capacity
overload-ctrl-threshold
overload-ctrl-trequests-rate
override-call-type
override-domain
. . . . . . . . . . . . . . 584
override-domain-from
override-domain-referred-by
override-domain-refer-to
override-from-on-conf
override-switch-acw
override-to-on-divert (Application level)
override-to-on-divert (DN level)
parking-music
. . . . . . . . . . . . . . . 499
partition-id (Application level)
partition-id (DN level)
p-asserted-identity
password
. . . . . . . . . . . . . . .551
peer-proxy-contact
periodic-check-tout
posn-no-answer-overflow
posn-no-answer-timeout
prd-dist-call-ans-time
predictive-call-router-timeout
predictive-timerb-enabled
prefix
. . . . . . . . . . . . . . . . . . . . 588
preview-expired
. . . . . . . . . . . . . . 501
preview-interaction
priority
. . . . . . . . . . . . . . . . . . . 589
privacy
. . . . . . . . . . . . . . . . .502
private-line
. . . . . . . . . . . . . . . . . 590
SIP Server—Deployment Guide privilege-level
. . . . . . . . . . . . . . . 590
propagated-call-type
protocol
. . . . . . . . . . . . . . . . . . 751
public-contact
. . . . . . . . . . . . . . . 591
quiet-cleanup
. . . . . . . . . . . . . . . 622
quiet-startup
. . . . . . . . . . . . . . . . 622
reason-in-extension
recall-no-answer-timeout
reconnect-tout
. . . . . . . . . . . . . . . 740
record
. . . . . . . . . . . . . . . . . . . 591
record-agent-greeting
record-consult-calls
recording-failure-alarm-timeout
recording-filename
record-moh
. . . . . . . . . . . . . . . . 503
recovery-timeout
refer-enabled
reg-delay
. . . . . . . . . . . . . . . . . 622
reg-interval
. . . . . . . . . . . . . . . . 622
register-attempts
register-tout
. . . . . . . . . . . . . . . . 743
registrar-default-timeout
reg-silent
. . . . . . . . . . . . . . . . . 622
reinvite-requires-hold
reject-call-incall
. . . . . . . . . . . . . . 593
reject-call-notready
reject-subsequent-request
releasing-party-report
replace-prefix
. . . . . . . . . . . . . . . 594
report-connid-changes
request-collection-time
request-tout
. . . . . . . . . . . . . . . . 743
request-uri
. . . . . . . . . . . . . . . . 594
reservation-time
. . . . . . . . . . . . . . 739
resolve-external-contact (Application level)
resolve-external-contact (DN level)
resolve-internal-rp-by-host
resolve-sip-address
resource-allocation-mode
resource-load-maximum
resource-management-by-RM
restart-period
. . . . . . . . . . . . . . . 507
restricted
. . . . . . . . . . . . . . . . . 621
reuse-sdp-on-reinvite
rfc-2976-dtmf
. . . . . . . . . . . . . . . 592
ringing-on-route-point
ring-tone
. . . . . . . . . . . . . . . . . 508
ring-tone-on-make-call
route-dn
. . . . . . . . . . . . . . . . . . 744
route-failure-alarm-high-wm
route-failure-alarm-low-wm
route-failure-alarm-period
router-timeout
. . . . . . . . . . . . . . . 508
rp-use-dial-plan
. . . . . . . . . . . . . . 509
rq-conflict-check
rule-<n>
. . . . . . . . . . . . . . . . . . 754
sca-preferred-site
security section
. . . . . . . . . . . . . . 754
767
Index send-200-on-clear-call
server-id
. . . . . . . . . . . . . . . . . . 734
server-role
. . . . . . . . . . . . . . . . . 509
service-type
. . . . . . . . . . . . . . . . 597
session-refresh-enforced (Application level)
. . . . . . . . . . . . . . . . . . . 510
session-refresh-enforced (DN level)
session-refresh-interval
set-notready-on-busy
setting
. . . . . . . . . . . . . . . . . . . 729
common
. . . . . . . . . . . . . . . . 707
shared-line
. . . . . . . . . . . . . . . . . 598
shared-line-capacity
shared-line-number
shutdown-sip-reject-code
silence-detected
. . . . . . . . . . . . . . 511
silence-tone
. . . . . . . . . . . . . . . . 511
sip-3pcc-from-pass-through
sip-491-passthrough
sip-accept-body
. . . . . . . . . . . . . . 599
sip-add-contact-early-dialog
sip-add-local-contact-user
sip-address
. . . . . . . . . . . . . . . . 513
sip-address-srv
. . . . . . . . . . . . . . 513
sip-alert-info (Application level)
sip-alert-info (DN level)
sip-alert-info-consult (Application level)
sip-alert-info-consult (DN level)
sip-alert-info-external (Application level)
sip-alert-info-external (DN level)
sip-answer-mode (Application level)
sip-answer-mode (DN level)
sip-block-headers
sip-busy-type
. . . . . . . . . . . . . . . 601
sip-chat-format
. . . . . . . . . . . . . . 601
sip-cti-control
. . . . . . . . . . . . . . . 602
sip-disable-greeting
sip-disable-via-srv
sip-dtmf-send-rtp
sip-early-dialog-mode
sip-enable-100rel (Application level)
sip-enable-100rel (DN level)
sip-enable-aoc-after-established
sip-enable-call-info
sip-enable-call-info-extended
sip-enable-diversion
sip-enable-gdns
. . . . . . . . . . . . . . 517
sip-enable-ivr-metadata (Application level)
sip-enable-ivr-metadata (DN level)
sip-enable-moh (Application level)
sip-enable-moh (DN level)
sip-enable-rfc3263
sip-enable-sdp-codec-filter (Application level)
. . . . . . . . . . . . . . . . . . . 521
sip-enable-sdp-codec-filter (DN level)
sip-enable-tcp-keep-alive
sip-enable-two-party-mute
sip-enable-x-genesys-route
768 sip-enhance-diversion
sip-error-conversion (Application level)
sip-error-conversion (DN level)
sip-filter-media (Application level)
sip-filter-media (DN level)
sip-fqdn-ip-version
sip-from-pass-through (Application level)
sip-from-pass-through (DN level)
sip-hold-rfc3264 (Application level)
sip-hold-rfc3264 (DN level)
sip-invite-timeout
sip-invite-treatment-timeout
sip-iptakeover-monitoring
sip-ip-tos
. . . . . . . . . . . . . . . . . 524
sip-max-retry-listen
sip-nic-address
. . . . . . . . . . . . . . 526
sip-nic-monitoring
sip-outbound-proxy
sip-pass-body
. . . . . . . . . . . . . . . 608
sip-pass-check
. . . . . . . . . . . . . . 527
sip-pass-from-parameters
sip-pass-refer-headers
sip-pass-xfer-params-enabled (DN level)
sip-port
. . . . . . . . . . . . . . . . . . 528
sip-port-tls
. . . . . . . . . . . . . . . . . 528
sip-preserve-contact (Application level)
sip-preserve-contact (DN level)
sip-proxy-headers-enabled
sip-proxy-uri-parameters
sip-recovery-allow-userdata
sip-referred-by-support
sip-referxfer-bye-timeout
sip-rel-200-retransmit (Application level)
sip-rel-200-retransmit (DN level)
sip-release-call-on-disable-dn
sip-remote-del-from-conf
sip-replaces-mode (Application level)
sip-replaces-mode (DN level)
sip-request-oos-timeout
sip-respect-privacy
sip-response-msml-oos (DN level)
sip-resubscribe-on-nonotify
sip-retry-timeout
. . . . . . . . . . . . . . 532
sip-ring-tone-mode (Application level)
sip-ring-tone-mode (DN level)
sip-route (DN level)
sip-route-active-transport
sip-server-info
. . . . . . . . . . . . . . . 534
sip-server-inter-trunk
sip-signaling-chat
sip-timer-c-support
sip-tls-cert
. . . . . . . . . . . . . . . . . 534
sip-tls-cert-key
. . . . . . . . . . . . . . 535
sip-tls-cipher-list
. . . . . . . . . . . . . . 535
sip-tls-crl
. . . . . . . . . . . . . . . . . 537
sip-tls-mutual
. . . . . . . . . . . . . . . 537
sip-tls-target-name-check
sip-tls-trusted-ca
Framework 8.1
Index sip-to-pass-through
sip-treatment-dtmf-interruptable
sip-treatments-continuous
sip-trying-timeout
sip-uri-params
. . . . . . . . . . . . . . . 614
sip-user-agent (Application level)
sip-user-agent (DN level)
sip-vip-script-down
sip-vip-script-up
. . . . . . . . . . . . . . 539
stranded -calls-overflow
stranded-call-redirection-limit (Application level)
. . . . . . . . . . . . . . . . . . . 540
stranded-calls-overflow (DN level)
stranded-on-arrival-calls-overflow
(Application level)
stranded-on-arrival-calls-overflow
(DN level)
. . . . . . . . . . . . . . . . 615
subscribe-presence
subscribe-presence-domain
subscribe-presence-expire
subscribe-presence-from
subscription-delay
subscription-event-allowed
subscription-id
. . . . . . . . . . . . . . . 615
subscription-timeout
summary-stat-timeout
sync-emu-agent
. . . . . . . . . . . . . . 622
sync-reconnect-tout
tcs-queue
. . . . . . . . . . . . . . . . . 746
tcs-use
. . . . . . . . . . . . . . . . . . . 746
timed-acw-in-idle
timeguard-reduction
timeout
. . . . . . . . . . . . . . . . . . . 745
timeout value format
–
tlib-map-replace-dn
tlib-nic-monitoring
transaction-state
. . . . . . . . . . . . . . 745
transfer-complete-by-refer
Translation Rules section
TServer section
–
unknown-bsns-calls
unknown-xfer-merge-udata
untimed-wrap-up-value
use-contact-as-dn
use-data-from
. . . . . . . . . . . . . . . 741
use-display-name
use-implicit-access-numbers
use-propagated-call-type
userdata-<n>
. . . . . . . . . . . . . . . 547
user-data-im-enabled
user-data-limit
. . . . . . . . . . . . . . . 735
userdata-map-all-calls
userdata-map-filter
userdata-map-invite-after-refer
userdata-map-trans-prefix
use-register-for-service-state
username
. . . . . . . . . . . . . . . . . 551
verify-sip-names
. . . . . . . . . . . . . . 545
SIP Server—Deployment Guide vip-state-change-timeout
wrap-up-threshold
wrap-up-time
. . . . . . . . . . . . . . . 546
x-sip-log
. . . . . . . . . . . . . . . . . . 547
x-sip-mask-sensitive-data
configuring
ACD Queue
. . . . . . . . . . . . . . . . . 77
Agent Login options
application service
device types
. . . . . . . . . . . . . . . . . 74
devices and services
DN options
. . . . . . . . . . . . . . . . 550
emergency recording
endpoints
. . . . . . . . . . . . . . . . . . 78
external music servers
gateway
. . . . . . . . . . . . . . . . . . . 81
INFO
. . . . . . . . . . . . . . . . . . . 546
INVITE
. . . . . . . . . . . . . . . . . . 546
MCU
. . . . . . . . . . . . . . . . . . . . 77
multi-site operation
–
recorder servers
. . . . . . . . . . . . . . 88
Routing Points
. . . . . . . . . . . . . . . 85
SIP Server
. . . . . . . . . . . . . . . . . 60
softswitches
. . . . . . . . . . . . . . . . . 85
Stream Manager
. . . . . . . . . . . . . . 92
treatment service
. . . . . . . . . . . . . . 90
TServer section
. . . . . . . . . . . . . . 443
UPDATE
. . . . . . . . . . . . . . . . . 546
connect-nailedup-on-login configuration option (Application level)
configuration option (DN level)
Extension key
. . . . . . . . . . . . . . . 430
consult-user-data configuration option
contact configuration option
contact-list configuration option
contacts-backup configuration option
control-remote-vip-scripts configuration option
control-vip-scripts configuration option
conventions in document
. . . . . . . . . . . . . . . . 759
type styles
. . . . . . . . . . . . . . . . . 760
ConvertOtherDN
Extension key
. . . . . . . . . . . . . . . 435
correct-rqid configuration option
cos configuration option
cpd-capability configuration option
cpd-info-timeout configuration option
769
Index cpn configuration option
CPNDigits
Extension key
. . . . . . . . . . . . . . . 433
cpn-digits-to-both-legs configuration option
cpn-dnis configuration option
cpn-self configuration option
customer-greeting configuration option
Extension key
. . . . . . . . . . . . . . . 429
customer-id configuration option
customer-side proxy mode
customized music files
D debug common log option
Default Access Code configuration
. . . . . . . . . . . . . . . . 694
defined
. . . . . . . . . . . . . . . . . . . 693
default-dn common configuration option
configuration option (Application level)
configuration option (DN level)
default-dn-type configuration option
default-filter-type common log option
default-monitor-mode configuration option
default-monitor-scope configuration option
default-music configuration option (DN level)
default-music (Application level) configuration option
default-network-call-id-matching configuration option
default-route-point-order configuration option
default-video-file configuration option
Dest-Capacity
Extension key
. . . . . . . . . . . . . . . 436
destination location
. . . . . . . . . . . . . . 650
destination T-Server
device-rq-gap configuration option
dial-plan configuration option (Application level)
configuration option (DN level)
direct-ani
ISCC transaction type
770 direct-callid
ISCC transaction type
direct-digits transaction type
. . . . . . . . . . . . . . 664
direct-digits-key configuration option
direct-network-callid
ISCC transaction type
direct-network-callid (ISCC protocol parameter)
direct-notoken
ISCC transaction type
direct-uui
ISCC transaction type
disable-media-before-greeting configuration option
disable-rbac common configuration option
disconnect-nailedup-timeout configuration option (Application level)
configuration option (DN level)
DisplayName
Extension key
. . . . . . . . . . . . . . . 433
display-name configuration option
distinctive ringtones
divert-on-ringing configuration option
dn
Extension key
. . . . . . . . . . . . . . . 427
Extension key
. . . . . . . . . . . . . . . 434
DN objects
. . . . . . . . . . . . . . . . . . .59
dn-del-mode configuration option
dn-for-unexpected-calls configuration option
DNIS_OVER
Extension key
. . . . . . . . . . . . . . . 426
dnis-pool in load-balancing mode
ISCC transaction type
dnis-tail (ISCC protocol parameter)
DNs configuring for multi-sites
dn-scope configuration option
document change history
. . . . . . . . . . . . . . . 19
conventions
. . . . . . . . . . . . . . . . 759
errors, commenting on
version number
. . . . . . . . . . . . . . 759
dr-forward configuration option
configuration option (DN level)
dr-oosp-transfer-enabled configuration option
dr-peer-trunk configuration option
Framework 8.1
Index dtmf-payload configuration option
dual-dialog-enabled configuration option
E emergency-backup configuration option
emergency-callback-plan configuration option
emergency-device configuration option
emergency-recording-cleanup-enabled configuration option
emergency-recording-filename configuration option
emulated agent options agent-group
. . . . . . . . . . . . . . . . 446
untimed-wrap-up-value
Emulated Agents
–
emulated agents timed-acw-in-idle
emulated-login-state configuration option
emulate-login configuration option
enable-agentlogin-presence configuration option
enable-agentlogin-subscribe configuration option (DN level)
enable-async-dns common configuration option
enable-busy-on-routed-calls configuration option
enable-direct-pickup configuration option
enable-extension-headers configuration option
enable-ims configuration option
enable-iscc-dial-plan configuration option
enable-legacy-reporting configuration option
enable-oosp-alarm configuration option
enable-strict-location-match configuration option
enable-unknown-gateway configuration option
encoding configuration option
endpoint monitoring
enforce-external-domains configuration option
enforce-p-asserted-identity configuration option
enforce-privacy configuration option
enforce-rfc3455 configuration option
enforce-trusted configuration option
epp-tout configuration option
error messages
. . . . . . . . . . . . . . . 437
Event Propagation defined
. . . . . . . . . . . . . . . . . . 683
EventAttachedDataChanged
event-propagation configuration option
event-ringing-on-100trying configuration option
expire common log option
expire-call-tout configuration option
extension-<n> configuration option
Extensions attribute
external-registrar configuration option
extn-no-answer-overflow configuration option
ext-no-answer-timeout configuration option
extrouter section configuration options
–
configuring for multi-site operation
configuring Number Translation
configuring party events propagation
F fast-busy-tone configuration option
FaxDest
Extension key
. . . . . . . . . . . . . . . 422
fax-detected configuration option
feature
Extension key
. . . . . . . . . . . . . . . 434
feature-code-park configuration option
feature-code-pickup configuration option
feature-code-retrieve configuration option
find-outbound-msml-by-location configuration option
find-trunk-by-location configuration option
SIP Server—Deployment Guide 771
Index first-party call control transfer
fmfm-confirmation-digit configuration option
fmfm-confirmation-timeout configuration option
fmfm-prompt-file configuration option
fmfm-trunk-group configuration option
font styles italic
. . . . . . . . . . . . . . . . . . . . 760
monospace
. . . . . . . . . . . . . . . . 760
forced-notready configuration option
force-p-early-media configuration option
force-register configuration option
force-register-disable-totag configuration option
G
Geolocation
Extension key
. . . . . . . . . . . . . . . 436
geo-location configuration option
Extension key
. . . . . . . . . . . . . . . 435
graceful-shutdown-sip-timeout configuration option
greeting-after-merge configuration option
greeting-call-type-filter configuration option (Agent-Login level)
configuration option (Application level)
greeting-delay-events configuration option
greeting-notification configuration option
greeting-repeat-once-party configuration option
greetings
VXML support
. . . . . . . . . . . . . . . 332
greeting-stops-no-answer-timeout configuration option
gvm_group_mailbox
GVP integration
H handle-vsp configuration option
hangup-restart common configuration option
heartbeat-period common configuration option
heartbeat-period-thread-class-<n> common configuration option
772 hg-busy-timeout configuration option
hg-members configuration option
hg-noanswer-timeout configuration option
hg-preferred-site configuration option
hg-queue-limit configuration option
hg-queue-timeout configuration option
hg-type configuration option
hide-msml-location configuration option
high availability
. . . . . . . . . . . . . . . . .44
host command line parameter
hot standby
. . . . . . . . . . . . . . . 44
defined
. . . . . . . . . . . . . . . . . . 640
http-port configuration option
I ignore-presence-after-nas configuration option (Application level)
configuration option (DN level)
IM-related options sip-chat-format
. . . . . . . . . . . . . . 601
sip-signaling-chat
ims-3pcc-prefix configuration option
ims-default-icid-prefix configuration option
ims-default-icid-suffix configuration option
ims-default-orig-ioi configuration option
ims-propagate-pcvector configuration option
ims-puid-domain configuration option
IMS-related options enable-ims
. . . . . . . . . . . . . . 466
ims-3pcc-prefix
. . . . . . . . . . . . . . 479
ims-default-icid-prefix
ims-default-icid-suffix
ims-default-orig-ioi
ims-propagate-pcvector
ims-puid-domain
ims-route
. . . . . . . . . . . . . . . . . 481
ims-sip-domain
. . . . . . . . . . . . . . 481
ims-sip-params
. . . . . . . . . . . . . . 481
ims-skip-ifc
. . . . . . . . . . . . . . . . 482
ims-use-term-legs-for-routing
override-domain
. . . . . . . . . . . . . . 584
Framework 8.1
Index refer-enabled
registrar-default-timeout
server-role
. . . . . . . . . . . . . . . . . 509
sip-route (DN level)
ims-route configuration option
ims-sip-domain configuration option
ims-sip-params configuration option
ims-skip-ifc configuration option
ims-use-term-legs-for-routing configuration option
inbound-bsns-calls configuration option
inbound-translator-<n> configuration option
include-dial-planconfiguration option
info-pass-through (Application level) configuration option
info-pass-through (DN level) configuration option
inherit-bsns-type configuration option
init-dnis-by-ruri configuration option
Instant Messaging feature configuration
overview
. . . . . . . . . . . . . . . . . . 265
supported call operations
transcript
. . . . . . . . . . . . . . . . . . 265
treatments
. . . . . . . . . . . . . . . . . 268
Inter Server Call Control
–
Inter Server Call Control/Call Overflow
–
interaction common log option
internal-bsns-calls configuration option
internal-registrar-domains configuration option
internal-registrar-enabled configuration option
internal-registrar-persistent configuration option
intrusion-enabled configuration option
ISCC
. . . . . . . . . . . . . . . . . . . . . 46
destination T-Server
origination T-Server
ISCC transaction types
direct-ani
. . . . . . . . . . . . . . . .657
direct-callid
. . . . . . . . . . . . . .657
direct-digits
. . . . . . . . . . . . . . . . 664
direct-network-callid
direct-notoken
direct-uui
. . . . . . . . . . . . . . . .658
SIP Server—Deployment Guide dnis-pool
. . . . . . . . . . . . . . . 659
in load-balancing mode
pullback
. . . . . . . . . . . . . . . . 660
reroute
. . . . . . . . . . . . . . . . 661
route
. . . . . . . . . . . . . . . . . 662
route-uui
. . . . . . . . . . . . . . . . . 663
supported
. . . . . . . . . . . . . . . . . 664
ISCC/COF supported
. . . . . . . . . . . . . . . . . 669
iscc-xaction-type
. . . . . . . . . . . . . . . 651
italics
. . . . . . . . . . . . . . . . . . . . . 760
K keep-mute-after-conference configuration option
keep-startup-file common log option
known limitations
. . . . . . . . . . . . . . . 441
kpl-interval configuration option
kpl-loss-rate configuration option
kpl-tolerance configuration option
L l command line parameter
LCTPartiesLength
Extension key
. . . . . . . . . . . . . . . 432
LCTParty<n>
Extension key
. . . . . . . . . . . . . . . 432
LCTParty<n>_location
Extension key
. . . . . . . . . . . . . . . 432
LCTSupervisor<n>
Extension key
. . . . . . . . . . . . . . . 432
LCTSupervisor<n>_location
Extension key
. . . . . . . . . . . . . . . 433
LCTSupervisor<n>_mode
Extension key
. . . . . . . . . . . . . . . 433
LCTSupervisor<n>_monitoredDN
Extension key
. . . . . . . . . . . . . . . 433
legal-guard-time configuration option
level-reassign-<eventID> common log option
level-reassign-disable common log option
license section configuration options
–
lmspath command line parameter
Load Balancing
. . . . . . . . . . . . . . . .44
local-node-id configuration option
773
Index location parameter
. . . . . . . . . . . . . . 650
log configuration options
–
log section common log options
–
log-extended section common log options
–
log-filter section common log options
log-filter-data section common log options
–
login-id
Extension key
. . . . . . . . . . . . . . . 434
logout-on-disconnect configuration option
logout-on-out-of-service configuration option
log-reduce-cpu-threshold configuration option
log-trace-flags configuration option
M make-call-alert-info configuration option
make-call-rfc3725-flow configuration option
Management Layer
. . . . . . . . . . . . . . 57
management-port configuration option
mandatory options configuration options
mapping extract data from INVITE message
line in SDP message body
SIP headers
. . . . . . . . . . . . . . . . 276
whole SDP message body
map-sip-errors configuration option
match-call-once configuration option
max-legs-per-sm configuration option
max-parking-time configuration option
max-pred-req-delay configuration option
media files, playing multiple
memory common log option
memory-storage-size common log option
merged-user-data configuration option
Message Waiting Indicator mwi-agent-enable
mwi-domain
. . . . . . . . . . . . . . . . 492
mwi-extension-enable
774 mwi-group-enable
mwi-host
. . . . . . . . . . . . . . . . . 492
mwi-mode
. . . . . . . . . . . . . . . . . 493
mwi-notify-unregistered-dn
mwi-port
. . . . . . . . . . . . . . . . . . 494
message_format common log option
messagefile common log option
mode application server
. . . . . . . . . . . . . . 42
customer-side proxy
stand-alone
. . . . . . . . . . . . . . . . . 41
monitor-internal-calls configuration option
MonitorMode
Extension key
. . . . . . . . . . . . . . . 424
monitor-party-on-hold configuration option
MonitorScope
Extension key
. . . . . . . . . . . . . . . 424
monitor-type
Extension key
. . . . . . . . . . . . . . . 434
monospace font
. . . . . . . . . . . . . . . 760
msml-enable-record-extensions configuration option
msml-location-alarm-timeout configuration option
msml-mute-type configuration option
msml-oos-recover-enabled configuration option
msml-record-metadata-support configuration option
msml-record-support configuration option
msml-support configuration option
Multiple-to-One mode
Multiple-to-Point mode
multi-site supervision
music
Extension key
. . . . . . . . . . . . . . . 429
Music and Announcements announcement treatments
music treatments
music-in-queue-file
other treatments
. . . . . . . . . . . . . . 297
overview
. . . . . . . . . . . . . . . . . 293
music-in-conference-file configuration option
music-in-queue-file configuration option
music-listen-disconnect configuration option
music-on-hold configuration option
Extension key
. . . . . . . . . . . . . . . 429
Framework 8.1
Index music-on-pbxpark configuration option
mwi-agent-enable configuration option
mwi-domain configuration option
mwi-extension-enable configuration option
mwi-group-enable configuration option
mwi-host configuration option
mwi-implicit-notify configuration option
mwi-mode configuration option
mwi-notify-unregistered-dn configuration option
mwi-port configuration option
N nas-indication configuration option
nas-private configuration option
NAT/C feature
. . . . . . . . . . . . . . . . 681
nco X/Y command line parameter
Network architecture
. . . . . . . . . . . . . . . . . 40
Network Asserted Identity
network attended transfer/conference
Network Considerations bandwidth requirements
firewalls
. . . . . . . . . . . . . . . . . . . 56
remote agents
. . . . . . . . . . . . . . . . 56
tuning
. . . . . . . . . . . . . . . . . . . . 56
voice quality
. . . . . . . . . . . . . . . . . 55
network considerations
network objects
. . . . . . . . . . . . . . . . 57
network-monitoring-timeout configuration option
network-request-timeout configuration option
NO_ANSWER_ACTION
Extension key
. . . . . . . . . . . . . . . 431
NO_ANSWER_OVERFLOW
Extension key
. . . . . . . . . . . . . . . 432
NO_ANSWER_TIMEOUT
Extension key
. . . . . . . . . . . . . . . 432
No-Answer Supervision
ACD Position
. . . . . . . . . . . . . . . 315
agent configuration
agents
. . . . . . . . . . . . . . . . . . . 313
extension configuration
position configuration
SIP Server—Deployment Guide no-answer-action configuration option
no-answer-overflow configuration option
no-answer-timeout configuration option
no-memory-mapping common log option
no-response-dn configuration option
notify-idle-tout configuration option
Number Translation feature
–
number translation rules
num-of-licenses configuration option
num-sdn-licenses configuration option
O objects
Agent Logins
. . . . . . . . . . . . . . . . 59
DNs
. . . . . . . . . . . . . . . . . . . . . 59
network
. . . . . . . . . . . . . . . . . . . 57
Switches
. . . . . . . . . . . . . . . . . . 58
Switching Offices
. . . . . . . . . . . . . . 58
observing-routing-point configuration option
ocs-dn configuration option
One-to-One mode
. . . . . . . . . . . . . . 662
oos
. . . . . . . . . . . . . . . . . . . . . . 582
oos-check configuration option
oos-error-check configuration option
oos-force configuration option
oos-options-max-forwards configuration option
oosp-transfer-enabled configuration option
operational-stat-timeout configuration option
original-dialplan-digits
Extension key
. . . . . . . . . . . . . . . 425
origination location
. . . . . . . . . . . . . . 650
origination T-Server
Out Of Signaling Path oosp-transfer-enabled
outbound-bsns-calls configuration option
Out-of-Service oos-check
. . . . . . . . . . . . . . . . . 581
oos-error-check
. . . . . . . . . . . . . . 582
oos-force
. . . . . . . . . . . . . . . . . 582
oos-options-max-forwards
775
Index out-rule-<n> configuration option
overflow-location
Extension key
. . . . . . . . . . . . . . . 435
overflow-location-map configuration option
overload-ctrl-call-rate-capacity configuration option
overload-ctrl-call-tapplytreatment-requests-rate configuration option
overload-ctrl-call-trequests-rate configuration option
overload-ctrl-call-tupdateuserdata-requests-rate configuration option
overload-ctrl-dialog-rate-capacity configuration option
overload-ctrl-threshold configuration option
overload-ctrl-trequests-rate configuration option
override-call-type configuration option
override-domain configuration option
override-domain-from configuration option
override-domain-referred-by configuration option
override-domain-refer-to configuration option
override-from-on-conf configuration option
override-switch-acw configuration option
override-to-on-divert configuration option (Application level)
configuration option (DN level)
P parking-music configuration option
partition-id (Application level) configuration option
partition-id (DN level) configuration option
p-asserted-identity configuration option
password configuration option
Extension key
. . . . . . . . . . . . . . . 434
path-optimization (ISCC protocol parameter)
peer-proxy-contact configuration option
periodic-check-tout configuration option
Personal greeting feature configuration
overview
. . . . . . . . . . . . . . . . . 330
Personal Greeting-related options greeting-after-merge
greeting-call-type-filter (Agent-Login level)
greeting-call-type-filter (Application level)
greeting-delay-events
greeting-notification
greeting-repeat-once-party
playapplication, parameters
GSIP_APP_ID
. . . . . . . . . . . . . . 237
GSIP_DTMF_DURATION
GSIP_DTMF_TO_DIAL
Point-to-Point mode
port command line parameter
posn-no-answer-overflow configuration option
posn-no-answer-timeout configuration option
post-feature-dn
Extension key
. . . . . . . . . . . . . . . 434
prd-dist-call-ans-time configuration option
predictive-call-router-timeout configuration option
predictive-timerb-enabled configuration option
prefix configuration option
Presence Subscription
LCS
. . . . . . . . . . . . . . . . . . . . 337
overview
. . . . . . . . . . . . . . . . . 336
processing userdata
PUBLISH request
subscribe-presence
subscribe-presence-domain
subscribe-presence-expire
subscribe-presence-from
subscription-id
. . . . . . . . . . . . . . 615
subscription-timeout
updating agent state
Preview interactions
preview-expired configuration option
preview-interaction configuration option
print-attributes common log option
priority configuration option
privacy configuration option
privacy mechanism
private-line configuration option
776 Framework 8.1
Index privilege-level configuration option
propagate (ISCC protocol parameter)
propagated-call-type configuration option
protocol configuration option
Providing a caller ID
public-contact configuration option
pullback
ISCC transaction type
Q quiet-cleanup configuration option
quiet-startup configuration option
R
ReasonCode
Extension key
reason-in-extension configuration option
rebind-delay common configuration option
recall-no-answer-timeout configuration option
reconnect-tout configuration option
record configuration option
Extension key
record-agent-greeting configuration option
Extension key
. . . . . . . . . . . . . . . 429
record-consult-calls configuration option
recording-failure-alarm-timeout configuration option
recording-filename configuration option
record-moh configuration option
recovery-timeout configuration option
redundancy hot standby
. . . . . . . . . . . . . . 44
warm standby
redundancy types hot standby
. . . . . . . . . . . . . . . . 640
refer-enabled configuration option
Referred-By header
reg-delay configuration option
reg-interval configuration option
register-attempts configuration option
register-tout configuration option
registrar-default-timeout configuration option
reg-silent configuration option
reinvite-requires-hold configuration option
reject-call-incall configuration option
reject-call-notready configuration option
reject-subsequent-request configuration option
releasing-party-report configuration option
remote agents
. . . . . . . . . . . . . . 56
Remote Server Registration
Remote Supervision feature configuration
feature limitations
overview
. . . . . . . . . . . . . . . . . 158
use of Extensions attribute
Remote Talk
. . . . . . . . . . . . . . . . . 357
replace-prefix configuration option
report-connid-changes configuration option
request-collection-time configuration option
request-tout configuration option
request-uri configuration option
reroute
ISCC transaction type
reservation-time configuration option
resolve-external-contact configuration option (Application level)
configuration option (DN level)
resolve-internal-rp-by-host configuration option
resolve-sip-address configuration option
resource-allocation-mode configuration option
resource-load-maximum configuration option
resource-management-by-RM configuration option
SIP Server—Deployment Guide 777
Index restart-period configuration option
restricted options configuration options
reuse-sdp-on-reinvite configuration option
rfc-2976-dtmf configuration option
ringing-on-route-point configuration option
ring-tone configuration option
ring-tone-on-make-call configuration option
route
ISCC transaction type
route-dn configuration option
route-failure-alarm-high-wm configuration option
route-failure-alarm-low-wm configuration option
route-failure-alarm-period configuration option
router-timeout configuration option
route-uui
ISCC transaction type
routing
Inter Server Call Control
–
rp-use-dial-plan configuration option
rq-conflict-check configuration option
rule-<n> configuration option
run.bat
. . . . . . . . . . . . . . . . . . . . 69
run.sh
. . . . . . . . . . . . . . . . . . . . . 68
S sca-preferred-site configuration option
sdn-licenses-available
Extension key
. . . . . . . . . . . . . . . 436
sdn-licenses-in-use
Extension key
. . . . . . . . . . . . . . . 436
sdp-c-host
Extension key
. . . . . . . . . . . . . . . 427
sdp-m-port-high
Extension key
. . . . . . . . . . . . . . . 428
sdp-m-port-low
Extension key
. . . . . . . . . . . . . . . 427
security section common configuration options
segment common log option
selecting an alternate gateway
778 send-200-on-clear-call configuration option
server-id configuration option
server-role configuration option
service-type configuration option
session-refresh-enforced configuration option (Application level)
configuration option (DN level)
session-refresh-interval configuration option
set-notready-on-busy configuration option
setting configuration options common
. . . . . . . . . . . . . . . . . . 707
shared-line configuration option
shared-line-capacity configuration option
shared-line-number configuration option
shutdown-sip-reject-code configuration option
SilenceDest
Extension key
. . . . . . . . . . . . . . . 423
silence-detected configuration option
silence-tone configuration option
SIP devices configuration
SIP Server starting
. . . . . . . . . . . . . . . . . . . 70
using Configuration Manager
SIP Server configuration options changes from 8.0 to 8.1
SIP_MIME_HEADERS
Extension key
. . . . . . . . . . . . . . . 436
sip-<SIP_error_code>
sip-3pcc-from-pass-through configuration option
sip-491-passthrough configuration option
sip-accept-body configuration option
sip-add-contact-early-dialog configuration option
sip-add-local-contact-user configuration option
sip-address configuration option
sip-address-srv configuration option
sip-alert-info configuration option (Application level)
configuration option (DN level)
Framework 8.1
Index sip-alert-info-consult configuration option (Application level)
configuration option (DN level)
sip-alert-info-external configuration option (Application level)
configuration option (DN level)
sip-answer-mode configuration option (Application level)
configuration option (DN level)
sip-block-headers configuration option
sip-busy-type configuration option
sip-chat-format configuration option
sip-cti-control configuration option
sip-disable-greeting configuration option
sip-disable-via-srv configuration option
sip-dtmf-send-rtp configuration option
sip-early-dialog-mode configuration option
sip-enable-100rel configuration option (Application level)
configuration option (DN level)
sip-enable-aoc-after-established configuration option
sip-enable-call-info configuration option
sip-enable-call-info-extended configuration option
sip-enable-diversion configuration option
sip-enable-gdns configuration option
sip-enable-ivr-metadata configuration option (Application level)
configuration option (DN level)
sip-enable-moh configuration option (Application level)
configuration option (DN level)
sip-enable-rfc3263 configuration option
sip-enable-sdp-codec-filter configuration option (Application level)
configuration option (DN level)
sip-enable-tcp-keep-alive configuration option
sip-enable-two-party-mute configuration option
sip-enable-x-genesys-route configuration option
sip-enhance-diversion configuration option
sip-error-conversion configuration option (Application level)
configuration option (DN level)
sip-filter-media configuration option (Application level)
configuration option (DN level)
sip-fqdn-ip-version configuration option
sip-from-pass-through configuration option (Application level)
configuration option (DN level)
sip-hold-rfc3264 configuration option (Application level)
configuration option (DN level)
sip-invite-timeout configuration option
sip-invite-treatment-timeout configuration option
sip-iptakeover-monitoring configuration option
sip-ip-tos configuration option
sip-max-retry-listen configuration option
sip-nic-address configuration option
sip-nic-monitoring configuration option
sip-outbound-proxy configuration option
sip-pass-body configuration option
sip-pass-check configuration option
sip-pass-from-parameters configuration option
sip-pass-refer-headers configuration option
sip-pass-xfer-params-enabled configuration option (DN level)
sip-port configuration option
sip-port-tls configuration option
sip-preserve-contact configuration option (Application level)
configuration option (DN level)
sip-proxy-headers-enabled configuration option
sip-proxy-uri-parameters configuration option
sip-recovery-allow-userdata configuration option
sip-referred-by-support configuration option
sip-referxfer-bye-timeout configuration option
SIP Server—Deployment Guide 779
Index sip-rel-200-retransmit configuration option (Application level)
configuration option (DN level)
sip-release-call-on-disable-dn configuration option
sip-remote-del-from-conf configuration option
sip-replaces-mode configuration option (Application level)
configuration option (DN level)
sip-request-oos-timeout configuration option
sip-respect-privacy configuration option
sip-response-msml-oos configuration option (DN level)
sip-resubscribe-on-nonotify configuration option
sip-retry-timeout configuration option
sip-ring-tone-mode configuration option (Application level)
configuration option (DN level)
sip-route (DN level) configuration option
sip-route-active-transport configuration option
sip-server-info configuration option
sip-server-inter-trunk configuration option
sip-signaling-chat configuration option
sip-timer-c-support configuration option
sip-tls-cert configuration option
sip-tls-cert-key configuration option
sip-tls-cipher-list configuration option
sip-tls-crl configuration option
sip-tls-mutual configuration option
sip-tls-sec-protocol
. . . . . . . . . . . . . . 537
configuration option
sip-tls-target-name-check configuration option
sip-tls-trusted-ca configuration option
sip-to-pass-through configuration option
sip-treatment-dtmf-interruptable configuration option
sip-treatments-continuous configuration option
sip-trying-timeout configuration option
sip-uri-params configuration option
sip-user-agent (Application level) configuration option
sip-user-agent (DN level) configuration option
sip-vip-script-down configuration option
sip-vip-script-up configuration option
sml section common options
–
spool common log option
square brackets
. . . . . . . . . . . . . . . 760
stand-alone mode
. . . . . . . . . . . . . . .41
standard common log option
stranded-call-redirection-limit configuration option (Application level)
stranded-calls-overflow configuration option
stranded-calls-overflow (DN level) configuration option
stranded-on-arrival-calls-overflow configuration option (Application level)
configuration option (DN level)
Stream Manager appropriate codec format
audio files
. . . . . . . . . . . . . . . . . . 93
defined
. . . . . . . . . . . . . . . . . . . 92
Multipoint Conference Unit
Music-on-Hold (MoH) server
subscribe-presence configuration option
subscribe-presence-domain configuration option
subscribe-presence-expire configuration option
subscribe-presence-from configuration option
subscription-delay configuration option
subscription-event-allowed configuration option
subscription-id configuration option
subscription-timeout configuration option
summary-stat-timeout configuration option
suspending-wait-timeout common configuration option
Switch objects
. . . . . . . . . . . . . . . . .58
multi-site operation
780 Framework 8.1
Index switch partitioning defined
. . . . . . . . . . . . . . . . . . . 685
T-Server support
. . . . . . . . . . . . . . 686
Switching Office objects
multi-site operation
sync-emu-agent configuration option
sync-reconnect-tout configuration option
T
Target ISCC
Access Code configuration
Default Access Code configuration
tcs-queue configuration option
tcs-use configuration option
third-party known limitations
Music-on-Hold server architecture
third-party call control transfer
time_convert common log option
time_format common log option
timed-acw-in-idle configuration options
emulated agents
. . . . . . . . . . . . . . 542
timeguard-reduction configuration option
timeout configuration option
timeout value format configuration options
–
TInitiateConference
TInitiateTransfer
. . . . . . . . . . . . . . . 650
tlib-map-replace-dn configuration option
tlib-nic-monitoring configuration option
T-Library supported functionality table
–
TLS-related options sip-port-tls
. . . . . . . . . . . . . . . . . 528
sip-tls-cert
. . . . . . . . . . . . . . . . . 534
sip-tls-cert-key
. . . . . . . . . . . . . . . 535
sip-tls-cipher-list
. . . . . . . . . . . . . . 535
sip-tls-crl
. . . . . . . . . . . . . . . . . . 537
sip-tls-mutual
. . . . . . . . . . . . . . . 537
sip-tls-target-name-check
sip-tls-trusted-ca
. . . . . . . . . . . . . . 538
TMakeCall
. . . . . . . . . . . . . . . . . . 650
TMuteTransfer
. . . . . . . . . . . . . . . . 650
trace common log option
transaction types (ISCC)
supported
. . . . . . . . . . . . . . . . . 664
transaction-state configuration option
transfer connect service
transfer-complete-by-refer configuration option
Transfer-Type
Extension key
. . . . . . . . . . . . . . . 425
Translation Rules section configuration option
treatments
Instant Messaging
TRouteCall
. . . . . . . . . . . . . . . . . . 650
keys
. . . . . . . . . . . . . . . . . . . . 432
trunk lines
. . . . . . . . . . . . . . . . . . 662
trunk versus trunk group, differences
T-Server configuring Application objects for multi-sites
multi-site operation
–
TServer section configuration options
–
TSingleStepTransfer
TXRouteType
. . . . . . . . . . . . . . . . 651
type styles conventions
. . . . . . . . . . . . . . . . 760
italic
. . . . . . . . . . . . . . . . . . . . 760
monospace
. . . . . . . . . . . . . . . . 760
typical SIP Server network
typographical styles
U
UDP
SIP message size limit
SIP signaling port
transport selection
UNIX installing SIP Server
starting applications
starting SIP Server
starting with run.sh
unknown-bsns-calls configuration option
unknown-xfer-merge-udata configuration option
untimed-wrap-up-value configuration option
emulated agent options
use-contact-as-dn configuration option
use-data-from configuration option
UseDialPlan
Extension key
. . . . . . . . . . . . . . . 426
use-display-name configuration option
SIP Server—Deployment Guide 781
Index use-implicit-access-numbers configuration option
use-propagated-call-type configuration option
user data propagation
User-Agent
Extension key
. . . . . . . . . . . . . . . 436
userdata-<n> configuration option
user-data-im-enabled configuration option
user-data-limit configuration option
userdata-map-all-calls configuration option
userdata-map-filter configuration option
userdata-map-invite-after-refer configuration option
userdata-map-trans-prefix configuration option
use-register-for-service-state configuration option
username configuration option
V
V command line parameters
VDN
. . . . . . . . . . . . . . . . . . . . . 662
verbose common log option
verify-sip-names configuration option
version numbering, document
Via header geo-location labeling
Video feature configuration
Push Video
. . . . . . . . . . . . . . . . 390
start
. . . . . . . . . . . . . . . . . . . . 390
stop
. . . . . . . . . . . . . . . . . . . . 391
VideoFile
Extension key
. . . . . . . . . . . . . . . 437
vip-state-change-timeout configuration option
voice quality
. . . . . . . . . . . . . . . . . 55
VXML greeting feature configuration
VXML support for agent greeting
W warm standby
. . . . . . . . . . . . . . 44
Windows starting applications
782 starting SIP Server
starting with run.bat
wrap-up-threshold configuration option
wrap-up-time configuration option
X x-conn-debug-all common log option
x-conn-debug-api common log option
x-conn-debug-dns common log option
x-conn-debug-open common log option
x-conn-debug-security common log option
x-conn-debug-select common log option
x-conn-debug-timers common log option
x-conn-debug-write common log option
x-sip-log configuration option
x-sip-mask-sensitive-data configuration option
Framework 8.1
Descarcă
Link public actualizat
Linkul public către chat-ul tău a fost actualizat. You may view and manage your chat links after registration here.
Link public document
Publicitate
