Dual Homed Conferences

Dual Homed Conferencing Overview

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:

  • pod2.cms.lab - the Unified CM domain (i.e. all Jabber endpoints have this as their host portion)
  • conf.pod2.cms.lab - the CMS domain, containing all user's CMS Spaces
  • s4b.cms.lab - the Skype for Business domain

Certificate Requirements

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 / Lync Server Configuration

NOTE: These Skype For Business Server commands have already been configured on our system. We are including them purely for reference.

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.

New-CsTrustedApplicationPool -Identity expc1a.pod2.cms.lab -Registrar s4b-fe.cms.lab -site 1 -RequiresReplication $false -ThrottleAsServer $true -TreatAsAuthenticated $true
New-CsTrustedApplicationPool -Identity cms1.pod2.cms.lab -ComputerFqdn cms1a.pod2.cms.lab -Registrar s4b-fe.cms.lab -site 1 -RequiresReplication $false -ThrottleAsServer $true -TreatAsAuthenticated $true New-CsTrustedApplicationComputer –Identity cms1b.pod2.cms.lab –Pool cms1.pod2.cms.lab New-CsTrustedApplicationComputer –Identity cms1c.pod2.cms.lab –Pool cms1.pod2.cms.lab

Next we configured a Trusted Application, which will map to this application pool:

New-CsTrustedApplication -ApplicationId Pod2-Expressway-C -TrustedApplicationPoolFqdn expc1a.pod2.cms.lab -Port 5061
New-CsTrustedApplication -ApplicationId Pod2-CMS1-Group -TrustedApplicationPoolFqdn cms1.pod2.cms.lab -Port 5061

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:

$Route1 = New-CsStaticRoute -TLSRoute -Destination expc1a.pod2.cms.lab -MatchUri pod2.cms.lab -Port 5061 -UseDefaultCertificate $true $Route2 = New-CsStaticRoute -TLSRoute -Destination expc1a.pod2.cms.lab -MatchUri conf.pod2.cms.lab -Port 5061 Set-CsStaticRoutingConfiguration -Route @{Add=$Route1} Set-CsStaticRoutingConfiguration -Route @{Add=$Route2} Enable-CsTopology

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), pod2cms1aedge[1-3]@s4b.cms.lab, pod2cms1bedge[1-3]@s4b.cms.lab, and pod2cms1cedge[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.

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.

  1. Log in to the Expressway-C at https://expc1a.pod2.cms.lab (username: admin and password: c1sco123)
  2. Navigate to Configuration > Dial plan > Search rules and click New
  3. Configure the following to route MSSIP traffic to the S4B Zone:

    Parameter Value
    Rule Name S4B domain MSSIP to S4BFE
    Priority 100
    Protocol SIP
    SIP Variant Microsoft Variants
    Source Any
    Mode Alias pattern match
    Pattern type Regex
    Pattern string .*@s4b\.cms\.lab.*
    Pattern behavior Leave
    On successful match Stop
    Target S4B Zone
  4. Click Create search rule.

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.

  1. Navigate to Configuration > Dial plan > Search rules on Expresssway-C. Click New
  2. Configure the following:

    Parameter Value
    Rule Name S4B domain StdSIP to CMS1a
    Priority 100
    Protocol SIP
    SIP Variant Standards-based
    Source Any
    Mode Alias pattern match
    Pattern type Regex
    Pattern string .*@s4b\.cms\.lab.*
    Pattern behavior Leave
    On successful match Continue
    Target CMS1a Zone
  3. Click Create search rule.

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:

  1. Find the rule just created called S4B domain StdSIP to CMS1a and at the right of the row, click Clone.
  2. Change the Rule Name to S4B domain StdSIP to CMS1b
  3. Change the Priority to 101
  4. Change the Target to CMS1b Zone
  5. Click Create search rule.

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

  1. Find the rule just created called S4B domain StdSIP to CMS1b and at the right of the row, click Clone.
  2. Change the Rule Name to S4B domain StdSIP to CMS1c
  3. Change the Priority to 102
  4. Change the On successful match to Stop
  5. Change the Target to CMS1c Zone
  6. Click Create search rule.

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.

  1. Log in to the Expressway-C at https://expc1a.pod2.cms.lab (username: admin and password: c1sco123)
  2. Navigate to Configuration > Dial plan > Search rules on Expresssway-C. Click New
  3. Configure the following:

    Parameter Value
    Rule Name UC domain MSSIP to CMS1a
    Priority 100
    Protocol SIP
    SIP Variant Microsoft AV & Share
    Source Any
    Mode Alias pattern match
    Pattern type Regex
    Pattern string .*@pod2\.cms\.lab.*
    Pattern behavior Leave
    On successful match Continue
    Target CMS1a Zone
  4. Click Create search rule.

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:

  1. Find the rule just created called UC domain MSSIP to CMS1a and at the right of that row, click Clone.
  2. Change the Rule Name to UC domain MSSIP to CMS1b
  3. Change the Priority to 101
  4. Change the Target to CMS1b Zone
  5. Click Create search rule.

And finally a search rule for CMS1c. This one will no be set to Stop routing if it cannot accept the call.

  1. Find the rule just created called UC domain MSSIP to CMS1b and at the right of that row, click Clone.
  2. Change the Rule Name to UC domain MSSIP to CMS1c
  3. Change the Priority to 102
  4. Change the Target to CMS1c Zone
  5. Change the On successful match setting to Stop
  6. Click Create search rule.

CMS Configuration

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.

CMS Forwarding Rules

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 (pod2.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.

  1. Access CMS admin for CMS1a: https://cms1a.pod2.cms.lab:8443/incoming_calls.html.
  2. Navigate to Configuration > Incoming calls
  3. Add a rule for the local UC domain. This rule may already be present if you configured the Expressway Edge section:
    1. Under Call forwarding, in the first blank row, under Domain matching pattern, enter pod2.cms.lab
    2. Set the Priority to 1
    3. Change the Forward setting to forward
    4. Set the Caller ID setting to pass through, because we want these to be completely unchanged for anything that's not a Microsoft destination.
    5. Click Add New
  4. Add a default rule for the Skype for business domain:
    1. Under Domain matching pattern, enter s4b.cms.lab
    2. Set the Priority to 1
    3. Change the Forward setting to forward
    4. Set the Caller ID setting to pass through
    5. Click Add New

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.

CMS Outbound Rules for Skype for Business

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):

  1. Launch Postman
  2. Specify the POST verb, in order to add a new rule.
  3. Change the URL to https://cms1a.pod2.cms.lab:8443/api/v1/OutboundDialPlanRules
  4. Click on the Body tab below the URL.
  5. If not already selected, select the x-www-form-urlencoded radio button.
  6. If necessary, click on the Bulk Edit selection at the right of the Key/Value headers, then get rid of any old data.
  7. The following parameters need to be configured, listed here as shown in the GUI as well as the corresponding API parameter:

    GUI Parameter API Parameter Value
    Domain domain s4b.cms.lab
    Our Skype for Business domain.
    SIP proxy to use sipProxy expc1a.pod2.cms.lab
    Local contact domain localContactDomain cms1a.pod2.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:

    domain:s4b.cms.lab sipProxy:expc1a.pod2.cms.lab localContactDomain:cms1a.pod2.cms.lab trunkType:lync failureAction:Stop priority:90 sipControlEncryption:encrypted scope:callBridge callbridge:###_CB_cms1a_callBridge_ID_###
  8. Click Send

    NOTE: Be careful to only press the Send button once. There is nothing to prevent you from adding multiple rules that are exactly the same. This may not cause issues initially, but certainly will cause confusion.
  9. You only need to repeat this for cms1b and cms1c, changing only the localContactDomain parameter. For cms1b paste the following into the Postman bulk edit window and click Send:
    domain:s4b.cms.lab sipProxy:expc1a.pod2.cms.lab localContactDomain:cms1b.pod2.cms.lab trunkType:lync failureAction:Stop priority:90 sipControlEncryption:encrypted scope:callBridge callbridge:###_CB_cms1b_callBridge_ID_###
  10. Lastly, for cms1c paste this into the bulk edit window of Postman and click Send:
    domain:s4b.cms.lab sipProxy:expc1a.pod2.cms.lab localContactDomain:cms1c.pod2.cms.lab trunkType:lync failureAction:Stop priority:90 sipControlEncryption:encrypted scope:callBridge callbridge:###_CB_cms1c_callBridge_ID_###
  11. Examine the Outbound rules from the CMS GUI. Log in to https://cms1a.pod2.cms.lab:8443/outbound_calls.html (Username: admin, Password: c1sco123)
  12. You should see the three new rules that have been created in addition to the first two you already had. Make sure the Local contact domain entry is for the same server specified in the Call Bridge Scope

CMS Inbound Rules for Skype for Business

  1. Navigate to Configuration > Incoming Calls, or https://cms1a.pod2.cms.lab:8443/incoming_calls.html.
  2. Add a domain with the following parameters in the Call matching section:

    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
    As performed earlier, you could have sent a POST to the /inboundDialPlanRules node.
  3. Click Add New

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.

CMS Lync Edge Service Accounts

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.

  1. First, CMS1a:
    1. Navigate to Configuration > General, or https://cms1a.pod2.cms.lab:8443/config.html (Username: admin, Password: c1sco123)
    2. In the Lync Edge settings section, for Server address, enter s4b-fe.cms.lab
    3. Below that line, for Username, enter pod1cms2aedge@s4b.cms.lab
    4. For Number of registrations, enter 3
    5. At the bottom of the page, click Submit
    6. Now check to see if things are properly registered. Navigate to Status > General and observe that the Lync Edge registrations should show "3 configured, 3 completed successfully", instead of just in progress or another status.
  2. Next, we'll repeat for CMS1b:
    1. Navigate to Configuration > General, or https://cms1b.pod2.cms.lab:8443/config.html (Username: admin, Password: c1sco123)
    2. In the Lync Edge settings section, for Server address, enter s4b-fe.cms.lab
    3. Below that line, for Username, enter pod1cms2bedge@s4b.cms.lab
    4. For Number of registrations, enter 3
    5. At the bottom of the page, click Submit
    6. Check to see if things are properly registered. Navigate to Status > General and observe that the Lync Edge registrations should show "3 configured, 3 completed successfully"
  3. And finally for CMS1c:
    1. Navigate to Configuration > General, or https://cms1c.pod2.cms.lab:8443/config.html (Username: admin, Password: c1sco123)
    2. In the Lync Edge settings section, for Server address, enter s4b-fe.cms.lab
    3. Below that line, for Username, enter pod1cms2cedge@s4b.cms.lab
    4. For Number of registrations, enter 3
    5. At the bottom of the page, click Submit
    6. Check to see if things are properly registered. Navigate to Status > General and observe that the Lync Edge registrations should show "3 configured, 3 completed successfully"

Testing Dual Home Conferences

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 forder 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.

  1. Access PC1
  2. From the Desktop, double-click on the S4B Dual Home Conf icon. This opens up the URL to https://meet.s4b.cms.lab/s4b1pod31/CLJ753MV, which will trigger the Skype for Business client to dial into the meeting.
    Alternatively, open Chrome and paste the following URL in the address bar: https://meet.s4b.cms.lab/s4b1pod31/CLJ753MV (the meeting URL from the invite above).
  3. The browser may require confirmation to open Skype (Open URL:lync15 Protocol). Click Open
  4. You may also be asked to confirm that you'd like to Use Skype for Business (full audio and video experience). Simply click Ok
  5. You are now in the meeting. There will likely be at least one other participant in this meeting already. Click the Video Camera icon and then Start My Video.
  6. Now join this conference from Jabber. Place a call to the URI 29905@s4b.cms.lab. This will force CMS to look up the URI for the Skype for Business meeting with conference ID 29905 on the Front End server before setting up a CMS meeting and joining.
  7. When finished please disconnect the call from PC1 and the laptop.

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.

 


SECTION COMPLETE!

You've finished this portion of the lab. We have multiple other optional lab sections, depending on your time and interest, to continue on.