Now let's take a look at a way to integrate on-premises Lync / Skype for Business with CMS via Expressway: the dual-home conference. This integration method provides the best end user experience because all participants, regardless of platform, will retain their native client experience. To Skype users, all participants will look like Skype users; and to users attending via the CMS meeting, everyone will appear as individual CMS meeting participants. A dual-homed conference is called such because for each meeting, a conference exists both in the Skype infrastructure side as well as on CMS. It is possible to integrate CMS directly with on-prem Skype for Business and the methods are similar, although that integration would only support audio/video. If you have an on-premises IM/P server, then you'll need to use Expressway.
Before you started, review the three domains in use:
Integrating either CMS or Expressway with Skype for Business Front End servers presents some additional certificate requirements. First, each Front End server must have the root CA that signed the Expressway-C and the CMS server certificates installed in its Local Machine Trusted Root Certification Authorities store. Having the same root CA certificate for all of these servers makes this step unnecessary.
Additionally, the Expressway-C's server certificate, when in a cluster, must be created such that there is a cluster FQDN as the Common Name and each cluster member as a SAN entry in the certificate. For non-clustered Expressways, the CN can simply be the FQDN of the server. Note that when integrating CMS directly to Skype for Business, this certificate requirement is the same, in that each CMS' cluster node would need to have a cluster FQDN as the CN and the cluster members in the SAN.
Skype for Business must trust the Expressway Server(s) and needs to be configured with a route to specify what domains should be sent to CMS via Expressway. To do this, first add a Trusted Application Pool matching the Expressway FQDN (this is the part that must match the Expressway server certificate's CN field). If this were an Expressway cluster, the Application Pool would specify the Expressway cluster FQDN Identity and the first member's FQDN as a ComputerFqdn. Then other cluster members would be associated to this Trusted Application Pool using the New-CsTrustedApplicationComputer command. Additionally, Skype for Business must trust the CMS nodes themselves, as they will be configured with a service account in order to look up Skype for Business meetings.
Next we configured a Trusted Application, which will map to this application pool:
Finally, we added the routes, assigning them to variables: one for the route to the CMS domain and the other for the domain matching the Unified CM endpoints, such as Jabber. These routes are then added to the global configuration (in most larger deployments, you may have a FEP-specific route that you assign this to). In our case, the routes will all point to Expressway. The topology change is then applied as shown below:
For a complete dual-home experience, CMS needs to be able to resolve Lync meetings and to do that it needs to register as a real S4B client. For this we need to create one or more accounts for each CMS cluster node on the Skype for Business server. For this purpose, we have created nine accounts on the S4B server (3 accounts for each CMS node), pod8cms1aedge[1-3]@s4b.cms.lab, pod8cms1bedge[1-3]@s4b.cms.lab, and pod8cms1cedge[1-3]@s4b.cms.lab, which will be used for this purpose.
As mentioned, this has already been configured, so it's time to move on to the Expressway configuration.
On Our Expressway-C, we need to identify how to handle the s4b.cms.lab domain. Any MSSIP variant matching that domain should be routed directly to the Microsoft Front End servers. Anything destined to that domain that is standards-based SIP must first go to CMS. And with that, we need to have three separate rules, one for each CMS cluster member zone.
First we will create the Search rule to route MSSIP calls to the S4B domain Front End.
Parameter | Value |
---|---|
Rule Name | |
Priority | 100 |
Protocol | SIP |
SIP Variant | Microsoft Variants |
Source | Any |
Mode | Alias pattern match |
Pattern type | Regex |
Pattern string | |
Pattern behavior | Leave |
On successful match | Stop |
Target | S4B Zone |
Now we can create the Search rule to route standards-based SIP calls for the S4B domain to CMS1a, CMS1b, and CMS1c in order to be transcoded. We will start with CMS1a.
Parameter | Value |
---|---|
Rule Name | |
Priority | 100 |
Protocol | SIP |
SIP Variant | Standards-based |
Source | Any |
Mode | Alias pattern match |
Pattern type | Regex |
Pattern string | |
Pattern behavior | Leave |
On successful match | Continue |
Target | CMS1a Zone |
Click HERE to configure the Search rule for CMS1b and CMS1c or configure it manually by expanding the detailed steps. This rule will be nearly identical to the one just configured.
As before, we must consider the failover scenarios and add the same rules for CMS1b and CMS1c. The easiest way to do this is to clone the previous rule. First for CMS1b:
And finally a search rule for CMS1c. This one will no longer continue hunting, if there is a failure. So the match behavior will be set to Stop
NOTE: If you completed the Expressway Edge with Skype for Business Gateway calls section, then the following Search Rules, which route MSSIP-type calls for the UC domain to CMS, will already be present: UC domain MSSIP to CMS1a, UC domain MSSIP to CMS1b, and UC domain MSSIP to CMS1c. On the Expressway-C, navigate to Configuration > Dial Plan > Search rules and verify that you have these 3 rules. Otherwise, expand the MSSIP for UC domain to CMS button below and configure them.
Parameter | Value |
---|---|
Rule Name | |
Priority | 100 |
Protocol | SIP |
SIP Variant | Microsoft AV & Share |
Source | Any |
Mode | Alias pattern match |
Pattern type | Regex |
Pattern string | |
Pattern behavior | Leave |
On successful match | Continue |
Target | CMS1a Zone |
Click HERE to configure the Search rule for CMS1b and CMS1c or configure it manually by expanding the detailed steps. This rule will be identical to the one just configured, except for the name, priority, and in the case of the last rule, the match behavior will be to Stop
As before, we must consider the failover scenarios and add the same rules for CMS1b and CMS1c. First for CMS1b:
And finally a search rule for CMS1c. This one will no be set to Stop routing if it cannot accept the call.
In CMS, we will now receive calls to the S4B domain that are standards-based SIP. We need to accept the calls, forward them and route them back out as Lync-type trunks to Expressway. In doing so, we need to make sure the calls are handled properly such that S4B users can perform call backs and that the call signalling is properly routed to the CMS cluster node from where it originated.
You have CMS rules for accepting calls inbound as well as routing calls outbound. The one piece that is needed to allow CMS to accept a call inbound and immediately send it back out to an outbound destination is a forwarding rule. At a minimum, you need to allow CMS to forward calls to the Unified CM domain (pod8.cms.lab) as well as to the Skype for Business domain (s4b.cms.lab). You could configure these individually, but for now we'll show how to set this up to allow all calls to be forwarded unchanged.
Note: Depending on the sections you completed, you may see additional routes to these added.
Our CMS deployment already has an outbound route to the CUCM domain, but in order for calls to be routed to the Skype for Business domain, s4b.cms.lab, another route is required. Then a rule is required in order for calls to target that domain and allow for conference resolution.
Now you can configure the required outbound rules and inbound rules as follows.
You have previously configured inbound and outbound CMS routing rules before using the GUI. Do the same via the API as follows (and we will note the equivalent GUI and API parameters):
GUI Parameter | API Parameter | Value |
---|---|---|
Domain | domain |
s4b.cms.lab Our Skype for Business domain. |
SIP proxy to use | sipProxy | expc1a.pod8.cms.lab |
Local contact domain | localContactDomain |
cms1a.pod8.cms.lab The CMS1a FQDN. |
Trunk type | trunkType | Lync |
Behavior | failureAction | Stop |
Priority | priority | 90 |
Encryption | sipControlEncryption | Encrypted |
Call Bridge Scope | scope | callBridge |
Call Bridge Scope | callbridge | ###_CB_cms1a_callBridge_ID_### |
In Postman, the following parameter pairs can be pasted in to the bulk entry window:
GUI Parameter | API Parameter | Value |
---|---|---|
Domain name | domain | s4b.cms.lab |
Priority | priority | 40 |
Targets spaces | resolveTocoSpaces | No |
Targets users | resolveToUsers | No |
Targets IVRs | resolveToIvrs | No |
Targets Lync | resolveToLyncConferences | Yes |
If you also required numeric dialing of Skype for Business meetings from Unified CM you could have also set Targets Lync to Yes on each of the three existing rules that map to the CMS FQDNs for calls matching the CMS domain. In this lab, you won't use that so we will skip that optional step.
In order for CMS to join Dual Home meetings via the PSTN Dialin number or use Skype for Business Edge TURN services, each CMS node must be configured with one or more service accounts. Lync allows up to 12 TURN allocations per login, so we may need more than one per server. This configuration should be done via the GUI of each meeting server.
In Dual Home Conferences, the key is for CMS to be able to resolve Skype for Business meeting information.
Normally you would have Outlook to schedule a new meeting. To speed things up, we have set up a conference already and will test joining it to illustrate the process of CMS lookup up and joining a Skype for Business meeting.
Here is the meeting information:
We see there is a meeting URL, which Skype for Business clients would click, and a conference ID, which is not the what CMS will need to resolve to a URI in order to join the meeting. To the standards-based SIP users, they will simply need to dial the conferenceID@skypedomain and CMS will handle the rest.
This concludes the on-prem Skype for Business integration example. If you are interested in external Edge connectivity for WebRTC clients or the Cisco Meeting Management (CMM) product and have not yet completed those sections, feel free to work on them now.
 
You've finished this portion of the lab. We have multiple other optional lab sections, depending on your time and interest, to continue on.