Remote Agents Support
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.
[TBD] SIP Server supports the following functionality for remote agents:
- Agents with nailed-up connections
- Multi-site supervision (refer to the the SIP Server Deployment Guide)
- Remote agents with non-provisioned DNs
- Remote agents and calls on hold
Configuring remote agents
Depending on remote agent locations, the following configurations are supported (or covered in this topic?):
- Remote agents located behind the Softswitch
- Remote agents with nailed-up connections located behind the Softswitch
- Remote agents without provisioning of remote phone numbers
[I am converting to tables. Does it look better?]
Configuring remote agents located behind the Softswitch
| Remote agent location/scenario | VOIP Service DN: Softswitch | Extension DNs |
|---|---|---|
| Behind the Softswtich | [TServer]
contact = <the contact URI that SIP Server uses for communication with the softswitch> |
[TServer]
<no options> |
| Nailed-up connections behind the Softswitch | [TServer]
|
[TServer]
|
- Configure a Voice over IP Service DN with the following minimum options in the [TServer] section:
- contact = <the contact URI that SIP Server uses for communication with the softswitch>
- prefix= <the initial characters of the number that must match a particular softswitch for that softswitch to be selected>
- service-type = softswitch
- refer-enabled = false
- dual-dialog-enabled = false
- reject-call-notready = true (recommended, not mandatory)
- sip-cti-control = <ensure that this option is not configured>
- Configure an Extension DN for a remote agent with the Number and Type properties. Do not add any options.
Remote agents with nailed-up connections located behind the Softswitch
- Configure a Voice over IP Service DN with the following minimum options in the [TServer] section:
- contact = <the contact URI that SIP Server uses for communication with the softswitch>
- prefix= <the initial characters of the number that must match a particular softswitch for that softswitch to be selected>
- service-type = softswitch
- refer-enabled = false
- dual-dialog-enabled = false
- reject-call-notready = true (recommended, not mandatory)
- sip-cti-control = <ensure that this option is not configured>
- Configure an Extension DN for a remote agent:
- line-type= 1
Configuring remote agents located behind the SBC/gateway
| Remote agent location/scenario | Extension DNs |
|---|---|
| Behind the SBC/gateway |
Must be configured with the PSTN number—for example, +1 555 123 1111, and the following options:
|
| Nailed-up connections behind the SBC/gateway |
Must be configured with the PSTN number—for example, +1 555 123 1111, and the following options:
|
- Configure an Extension DN for each remote agent with the PSTN number—for example, +1 555 123 1111. Configure the following options:
- contact = <the contact URI of the PSTN SBC/gateway, depending on the agent location>
- refer-enabled = false
- dual-dialog-enabled = false
- reject-call-notready = true (recommended, not mandatory)
- sip-cti-control = <ensure that this option is not configured>
Remote agents with nailed-up connections located behind the SBC/gateway
- Configure an Extension DN for each remote agent with the PSTN number—for example, +1 555 123 1111. Configure the following options:
- contact = <the contact URI of the PSTN gateway/SBC, depending on the agent location>
- refer-enabled = false
- dual-dialog-enabled = false
- reject-call-notready = true (recommended, not mandatory)
- sip-cti-control = <ensure that this option is not configured>
- line-type= 1
To learn about benefits of nailed-up connections and how to configure them, refer to the Nailed-Up Connections for Agents topic.
To reconfigure office-based agents to their remote home-based locations, refer to the Enabling office-based agents to work from home topic.
For general information about creating endpoints, refer to the Configuring Endpoints section in the SIP Server Deployment Guide.
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.
- 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.
Remote agents with non-provisioned phone numbers
[FDS: https://intranet.genesys.com/display/RDSIPS/%5BFDS%5D+Remote+agent+with+non-provisioned+number]
Starting with version 8.1.102.93, SIP Server improves provisioning of remote agent DNs in the Configuration Database. It is no longer required to provision external phone numbers (for example, agent’s PSTN numbers) in the Configuration Database. You must create an Extension DN for each agent where a DN number can be a primary office DN number or any other number if an agent doesn't have a primary office DN.
The external numbers are used to reach the agent during the agent session only, thereby limiting the lifetime of the external numbers to a particular agent session. In other words, after the agent is logged out, any associations with that external number are removed.
This feature requires Workspace Web Edition (WWE) version 8.5.201.95 or later.
[Do we need this statement?]The phone number to be used for the agent session is passed to SIP Server in the TAgentLogin request in AttributeExtensions as the agent-phone key. AttributeThisDN of that request points to the DN assigned to the agent.
Configuring remote agents with non-provisioned numbers
| Remote agent location/scenario | VOIP Service DN: Softswitch | Extension DNs |
|---|---|---|
| Behind the Softswtich | [TServer]
contact = <the contact URI that SIP Server uses for communication with the softswitch> |
[TServer]
|
| Nailed-up connections behind the Softswitch | [TServer]
|
[TServer]
|
- Configure a Voice over IP Service DN with the following minimum options in the [TServer] section:
- contact = <the contact URI that SIP Server uses for communication with the softswitch>
- prefix= <the initial characters of the number that must match a particular softswitch for that softswitch to be selected>
- service-type = softswitch
- Configure a physical (default?) DN for a remote agent or an agent with a nailed-up connection with the following properties:
- Number—The physical DN number (must start with the softswitch prefix). If an agent does not have a primary office DN, use a unique fake number. (Make sure no configured internal DNs must be used.)
- Type—Extension
- In the DNs/Annex > TServer section, configure the following options:
- contact = (empty)
- voice = true
- line-type= 1 - (Optional) Only for an agent with a nailed-up connection.
- connect-nailedup-on-login= gcti::park - (Optional) Only for an agent with a nailed-up connection. See nailed-up connections for details.
- Create a Default Place containing this DN.
- Create an agent login for this agent.
- Create a new Person object for this agent and assign the Default Place and the agent login to this Person object.
Configure a Person object for each agent and assign to it the Default Place, which must have a DN. The DN can be a primary office DN. If an agent does not have a primary office DN, then a fake DN or an external number can be used. Do not configure any number different from the default DN that the agent can use during the agent session as an internal DN on the SIP Server switch. Internal DNs include Extension DNs, Routing Point DNs, Trunk Group DNs, ACD Position DNs, ACD Queue DNs, and External Routing Point DNs.
#If an agent with a nailed-up connection must use a dynamically configured external number, configure the following:
- Set the line-type option to 1 in the [TServer] section of the agent's Extension DN.
- (Optional) Set the connect-nailedup-on-login option to gcti::park in the [TServer] section of the agent's Extension DN.
Configure other configuration options for a nailed-up agent configuration on the softswitch DN as needed.
AttributeExtensions
[We can remove it from here. We have it in the SIPS DG.]
Key: agent-phone
Type: String
Request: TAgentLogin
Specifies the phone number to be used for the agent session.
Limitations
- If a dynamically defined number is used for the agent session, the agent can only initiate calls using the agent desktop. 1pcc calls originated from the dynamically defined number are not supported.
- Any number different from the default DN that an agent can use during the agent session must not be configured as an internal DN on the SIP Server switch.
- For agents with nailed-up connections that use a dynamically defined number for the agent session, an establishment of the nailed-up connection by calling into a contact center Routing Point is not supported.
- Hunt Groups in Business Continuity (BC) functionality are not supported by this feature. That is, in the BC deployment, agent logging with a dynamically configured external number to a DN that is a member of the Hunt Group is not supported.
Remote Agents and Calls on Hold
Introduced in 8.1.103.73. In a scenario where a remote agent located behind a PSTN trunk places a call on hold, SIP Server can connect the on-hold party to a media service with a silent treatment to prevent disconnection of the call by the trunk. Previously, the connection was dropped because the inactivity timeout set by the trunk expired. This SIP Server behavior affects only 3pcc Hold requests and cannot be applied to devices with dual dialog support.
To enable this feature, set the dual-dialog-enabled DN-level configuration option to a value of single-dialog-rtp-on-hold. In this case, SIP Server does not send an inactive SDP to the party during the hold operation. Instead, it connects the on-hold party to a media service with a silent treatment. A dual dialog is not allowed on that DN, only a single dialog is allowed, and it works the same as the option value of false.