Known Limitations and Workarounds
The following known limitations apply to the Multimedia Connector for Skype for Business version 9.0.x:
|Microsoft||Skype for Business Server
|See software requirements, minimum versions.|
|Genesys||Genesys 8.x suite||See prerequisites for Workspace Plugin for Skype for Business. See Multimedia Connector sellable item and prerequisites.|
|Performance||1,000 concurrent sessions||See hardware sizing guidelines.|
|Genesys High Availability:
||See HA architecture, including:|
|Partitioning||Only one T-Server is supported per Skype for Business deployment. It is not possible to make calls between devices that are controlled by different T-Servers connected to the same Skype for Business deployment.|
|Multiple Front End Pools||
|Front End Pool Pairing||
Front End Pool Pairing is supported for agent pools only. Agents will experience a service interruption while an agent pool failover/failback is executed. Front End Pool Pairing is not supported for any Front End pool that is hosting Connectors. See Paired Front End Pools.
|Skype for Business Federation||See Federation Platform with Microsoft Office 365 Cloud.|
|Skype for Business SBA/SBC||See SBA/SBS support.|
|Collocated Mediation Servers||Not supported in production environments in the Front End Pool that is hosting Genesys UCMA Connector applications. A dedicated Mediation Server Pool must be used.|
|Multi-site support||Multi-site support||Multi-site support with SIP Server and other T-Servers, but no support with other instances of T-Server for Skype for Business. See multi-site support.|
|Skype for Business client
||No Skype consumer.
|Channel – IM||Routing
|See the following topics:
Note that a Skype for Business agent cannot be configured to handle both Skype for Business IM interactions and Genesys eServices chat at the same time. See IM Suppression for more information.
|Channel - Voice||Routing
|See the following topics:|
|Multimodal||Escalation||See the following topics:|
|Desktop||Workspace Desktop Edition||
|Presence propagation||Direction configurable||See Presence.|
|Tel URIs||Not supported||See Configuring Skype for Business User Endpoints.|
|Genesys applications support||Framework||Genesys TLib applications: URS, Stat Server, ICON…|
|GVP||SIP in-front architecture.
||See SIP Server in Front.|
|Recording||Genesys Interaction Recording|
|Outbound||SIP in-front architecture—all dialing modes||See Trusted Application Endpoints for conference services.|
|Voicemail||SIP in-front architecture||No Message Waiting Indicator.|
|Skype for Business application support||Voice Response Group||Support was provided for Response Groups with the introduction of the B2B feature in version 8.5.001.63. Not supported for earlier versions.||For versions earlier than 8.5.001.63, Skype for Business does not allow a call that is monitored by Genesys to be delivered to a Voice Response Group. Possible workarounds:|
|Voicemail||Not supported||Skype for Business does not allow a call that is monitored by Genesys to be delivered to Voicemail. Only direct calls that are not managed by Connector will reach such destinations.|
|Forwarded extensions/Simultaneous ringing||Support is provided for Forwarding/Simultaneous Ringing with the introduction of the B2B feature in version 8.5.001.63. Not supported for earlier versions.||For versions earlier than 8.5.001.63, Skype for Business does not allow a call that is monitored by Genesys to be delivered to another Skype for Business user with Forwarding or Simultaneous riging activated. Only direct calls that are not managed by Connector will reach such destinations.|
Skype For Business Front End Server Maintenance
If a Front End Server is stopped or failover is invoked, the remaining Skype for Business Front End Servers initiate actions to redistribute the roles of the stopped Front End Server between themselves. In this instance the following applies:
- If the Front End Server is stopped (for example, by rebooting the server or invoking Stop-CsWindowsService), it will take at least 5 minutes before the remaining Front End Servers have completely synchronized. If the stopped Front End Server is restarted before the synchronization between the remaining Front End Servers is completed, it can lead to de-synchronization between the UCMA Connectors and the Front End Servers. There must be at least 5 minute delay before restarting a stopped Front End Server.
- If the Invoke-CsComputerFailOver command is issued while UCMA Connector is running, it can take up to 20 minutes or longer for the failover to successfully complete. This means the Invoke-CsComputerFailBack command should not be invoked for at least 20 minutes.
- Active calls that are being managed by the Front End Server being stopped or failed over may be reported as released by T-Server.
- T-Server may reject call related requests for calls for that were managed by the stopped Front End Server until all states have been redistributed and re-synchronized.
Recommended Workarounds: Working with Workspace Intercommunication Options
There are several limitations that cannot be managed directly by the Multimedia Connector for Skype for Business. To properly manage these, it is necessary to work with the routing-based calling feature using the intercommunication options in Workspace Desktop Edition (WDE). See this topic for details.
These limitations include the following:
- Inability to manage the CLID for outbound calls: Calls made from a T-Server monitored user to either a non-monitored Skype for Business user or to an external user using PSTN will arrive at the destination with the CLID of the internal resource used by the Multimedia Connector to manage this call, instead of the CLID of the actual caller.
- Inability to cancel an outbound call before it has been answered: Skype for Business does not allow Multimedia Connector to cancel an outbound call before it rings.
- Inability to make calls to Skype for Business Response Groups: Skype for Business will block any attempt to establish a call between 2 conference resources. Because both Multimedia Connector and Response Groups rely on conferencing resources, it is not possible for a Genesys agent to directly call a Response Group.
Using this Workspace feature, it is possible to make use of the Genesys SIP Server to work around these missing capabilities. The basic call flow will be as follows:
- An agent initiates an outbound call using Genesys Workspace.
- Workspace sends this call to a designated Routing Point on Skype for Business. The actual intended final destination is attached as user data in the key IW_RoutingBasedTargetId.
- At this Routing Point, a strategy is loaded that routes the call to a designated Routing Point on SIP Server.
- From this SIP Server Routing Point, it is possible to use the capabilities of SIP Server to manage the call.
The following procedure enables the basic capability to enable a routing-based calling feature in Workspace to work in a Skype for Business environment.
- Deploy SIP Server and create a Trunk DN to enable calls between Skype for Business and SIP Server. Ensure calls can be passed between Skype for Business and SIP Server.
- Configure ISCC between SIP Server and T-Server for Skype for Business as described in Chapter 9, Multi-Site Support, of the SIP Server Deployment Guide. Note that T-Server for Skype for Business supports only cast-type=route.
- Configure a dedicated Routing Point on the Switch object assigned to SIP Server.
- Configure a dedicated Routing Point on the Switch object assigned to T-Server for Skype for Business. On the Annex tab of this Routing Point, in the [TServer] section, create the override-call-type option and set it to 3.
- Configure the following Workspace options:
- contact.ucs-interaction.voice.use-dialed-phone-number = true
- intercommunication.voice.routing-points = <Skype for Business Routing Point from Step 4>
- intercommunication.voice.routing-based-targets = TypeDestination,Contact
- intercommunication.voice.routing-based-actions = MakeCall,OneStepConference,InitConference,OneStepTransfer,InitTransfer
Managing CLID for outbound calls
When the call initiated using the routing-based calling feature arrives at SIP Server, it will have the following user data keys:
- IW_RoutingBasedTargetId: Provides the original called target
This information can be used in a routing strategy loaded on the SIP Server Routing Point to adjust the CLID according to requirements and route the call to the final destination provided in IW_RoutingBasedTargetId.
Enabling cancellation of outbound calls
Skype for Business requires that an outbound call be established before it can be abandoned or cancelled. To enable outbound calls to be cancelled when there is no answer at the destination, the routing strategy loaded on the SIP Server Routing Point must apply a silence treatment and then immediately route the call to the final destination provided in the user data key IW_RoutingBasedTargetId. This silence treatment will establish the call before it is routed to the final destination so that T-Server is able to cancel this call.
Calling Skype for Business Response Groups
If the Response Group (RG) is a vital part of your business process, you can utilize a workaround architecture, taking into account the following limitations:
- An agent (a user registered in the configuration environment) cannot accept a call from the RG. Only unmonitored Skype for Business users can be RG members.
- The RG can accept only direct calls from the client or from the trunk. Dialing out from the conference and conference invitation are rejected.
- The RG member (an unmonitored Skype for Business user) who answers a call from the RG cannot invite a monitored agent into this conference.
To allow calls to be made from a Genesys controlled agent to a Skype for Business Response Group, the call must be passed via SIP Server. This means that when the call arrives at the Response Group, it is coming from SIP Server rather than from another conference resource that was blocked by Skype for Business.
All Response Groups that are accessible for a Genesys agent must be configured in the places described below. This example assumes that agents are able to call Response Group email@example.com:
- Ensure that the Workspace option intercommunication.voice.routing-based-targets contains the additional value ACD Queue.
- Create a DN with the number sip:firstname.lastname@example.org of type ACD Queue under the T-Server for Skype for Business DNs. This DN must have the register flag set to False.
- Create a SIP Server dial plan entry that sends calls to this group back to Skype for Business using the SIP Server Trunk DN pointing at Skype for Business and the TEL number of the group.
For example: dial-plan-rule-N: sip:email@example.com=>99+123456789
- Create a routing strategy loaded on the SIP Server Routing Point:
- Set the extension UseDialPlan=full.
- Route a call to the target provided in the User Data key IW_RoutingBasedTargetId.
- If pass-through calls are not allowed, ISCC must be configured between T-Server for Skype for Business and SIP Server, and the allow-pass-through-calls option must be set to iscc for the Routing Point on Skype for Business. Otherwise, calls routed or transferred to Response Groups might be dropped.
To make a call to a Response Group, an agent searches for the group in the Workspace contacts. This search might return two results, one for the actual Skype for Business Response Group contact and the other for the corresponding ACD Queue configured in Step 1. The agent must select the entry corresponding to this ACD Queue for the call to be successful.