S4B Gateway Calls

External Microsoft Federation Overview

Now you're ready to add B2B capabilities with federation to external Microsoft Office 365/Skype for Business users. For the rendezvous-type calls, all the work is already done. The Expressway-C is already routing calls for the CMS domain (conf.pod7.cms.lab) to the CMS servers (cms1a, cms1b, cms1c) and these servers are perfectly capable of handling Microsoft SIP-based calls.

The other call flow is a gateway call, where you allow direct point-to-point calls between standards-based SIP endpoints and external Skype clients, utilizing CMS as a transcoder, without the end-user having to do anything other than dial the destination's URI. Inbound calls are fairly straightforward. A call to the UC domain that is of the Microsoft variant should first go through CMS before being sent to the Unified CM. Outbound calling is more complex. While it is easy to configure when the external domains involved are known, for this lab we will configure an open federation, where any external domain can be called without knowing in advance if it supports standards-based video or is a Microsoft SIP-based destination. Essentially, we will try standards-based SIP and if that fails, we will route the call through CMS and re-attempt as Microsoft SIP.

Beginning with the X8.9.1 release, Cisco Expressway has a feature where it can distinguish between standards-based SIP calls and various Microsoft SIP variants based on the headers present. If, for example, an inbound call arrives from a Skype for Business user destined for a standards-based Unified CM endpoint, the Expressway-C can send the call to CMS. The CMS can perform the interworking and send the call back to Expressway-C as a standards-based SIP call, which can be routed to the Unified CM.

Consider the two call scenarios:

  • External Skype for Business caller (skype7@ms.com) calls a standards-based user on the UC domain (pod7user4@pod7.cms.lab). For this call flow:
    1. The Expressway-E will recognize the UC domain and route it via the Traversal Zone to the Expressway-C.
    2. From there, the Expressway-C will have a search rule for the MSSIP calls to the UC domain to route to CMS.
    3. CMS will have a forwarding rule for the UC domain as well as an outbound rule for the same domain, routing the call back to the Expressway-C as a standards-based SIP call.
    4. Expressway-C now routes the standards-based SIP call to the UC domain to CUCM where the endpoint can answer the call.
  • Standards-based user on the UC domain (pod7user4@pod7.cms.lab) calls an external Skype for Business user (skype7@ms.com. This is the call flow in the case of an open federation:
    1. The Unified CM, just like any other B2B call, will route the call to the Expressway-C.
    2. Similarly, Expressway-C routes the call to Expressway-E
    3. Expressway-E will attempt to use its DNS Zone by querying for standards-based public DNS SRV records. These will fail and a 404 Not Found will be returned to Expressway-C
    4. Expressway-C will now Continue to route the call to CMS
    5. CMS will have a forwarding rule for all domains, as well as an outbound rule for all domains as a Lync-type call back to Expressway-C
    6. Expressway-C, just as with the original call, will route the call outbound to the Expressway-E
    7. The Expressway-E will again use its DNS zone, but given the presence of Microsoft SIP variants, will perform DNS queries for the Microsoft SRV records (_sipfederationtls._tcp.ms.com). This will succeed and the call can complete
NOTE: Having an open federation by definition requires the CMS to have outbound default routes for all domains. Extreme care must be taken to avoid routing loops in this situation as CMS itself provides little protection in that regard.

Expressway-C Search Rules

Remember the goal of this interoperability with Skype for Business is to send Skype calls through the CMS server so they can be converted to Standards-based SIP. Consider each call flow, starting with a call from an external Skype for Business user dialing a user in the Enterprise (e.g. a Jabber user).

Inbound Skype for Business Calls

Any external Skype for Business / O365 site will use DNS to locate the Expressway-E, which will send the call to the Expressway-C.

For an external Microsoft Edge server to locate your network, the public DNS server requires the SRV record _sipfederationtls._tcp.pod7.cms.lab configured to resolve to the Expressway-E's external facing IP address. This SRV record is already set up in our lab's public DNS server. When a Skype for Business user places a call, the Microsoft Edge server looks for this DNS record for the domain being called and routes the call to the address it finds, thinking that it is communicating with another Microsoft Edge server. The Skype for Business call arrives at the Expressway-E which sends the call via the Traversal zone to the Expressway-C because the destination domain is our UC domain, pod7.cms.lab. Once the call arrives on the Expressway-C, that server needs to identify that the call contains the Microsoft SIP call variant and route the call to CMS. The CMS, in turn, receives the call and, recognizing that the destination domain is pod7.cms.lab, forwards it and, using an outbound rule, sends the call back to the Expressway-C as a standards-based SIP call. The CMS then anchors the call, performing the Microsoft-to-standards-based SIP interop. The Expressway-C, using Search rules already configured, can send the now-standard SIP call to Unified CM.

First add a rule to Expressway-C that will accept calls that have the Microsoft SIP variants and route them to CMS. As before, since we have a cluster, we must route the calls sequentially through each CMS node, each rule having a higher priority, and then stopping after the final CMS node is attempted.

  1. Log in to the Expressway-C at https://expc1a.pod7.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 .*@pod7\.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.

Now inbound Skype for Business calls to the UC domain are sent to the CMS where it will accept the call and then forward it back to the Expressway-C as a standards-based SIP call because of the outbound rule configured for pod7.cms.lab as Standards-based SIP. Expressway-C already has a rule that matches standards-based SIP calls destined to this local UC domain, and routes them to the Unified CM (the UC domain StdSIP to CUCM rule). Inbound calls should work now. But what about outbound calls?

Outbound Skype for Business Calls

We already have a generic outbound B2B Search Rule in the Expressway-C. As we have seen, we can make successful outbound B2B calls. If you recall, this Rule ("Outbound Zone"), had a pattern behavior of Continue. This is because we need the subsequent Rules for when those calls fail because the domains are not registered as standards-based SIP domain in the public DNS. Instead, we will need to route those calls to CMS, which will then send them back as Lync-type calls, which will then be handled by the Expressway-E and routed to a Microsoft domain.

Consider a call from an internal endpoint destined to the URI bgates@microsoft.com. Unified CM and Expressway have no idea if this is a call destined to a Skype for Business user or a Standards-based SIP endpoint. Expressway will initially think this call is to a Standards-based SIP endpoint. Looking at the rules you have configured so far on the Expressway-C, the Outbound Zone rule will be matched to send the call to the Traversal Zone. You should note that this rule has the On successful match parameter set to Continue. You will see why that is important in a moment.

The call is extended to the Expressway-E. Expressway-E then matches its rule that routes the call to the DNS Zone, as it is to a non-local domain. Since this call still contains none of the Microsoft-specific headers, this is assumed to be a standards-based SIP call. Therefore, Expressway-E when routing to the DNS Zone, the Expressway will ONLY send a standards-based SIP SRV request to the public DNS server, in the case of this example, _sip._tcp.microsoft.com or _sips._tcp.microsoft.com. If the destination is a Skype for Business / Office365 site, they should not be advertising those DNS SRV records (otherwise they have the responsibility to actually support standards-based SIP calls). This means these SRV lookups will fail. As a result, Expressway-E rejects the call that came from Expressway-C with a 404 Not Found message.

Remember that the Outbound Zone search rule initially matched on the Expressway-C was set to Continue? This parameter tells Expressway-C to continue searching through the rules if there was no successful call completion. So what we can do at this point is insert a new rule to send calls for a non-local domain to the CMS. The CMS should route the call back to the Expressway-C, but this time with the Microsoft variants included. This new call matches another new rule, which will state that calls from the CMS with Microsoft SIP variants should route through the traversal zone to the Expressway-E. There it matches the same rule for the outbound DNS Zone, however, now the call actually has a Microsoft variant, which means that the Expressway-E will automatically issue DNS requests for _sipfederationtls._tcp.microsoft.com. This will resolve to the IP address of an external Microsoft Edge server and the call can proceed, all the while being anchored at the CMS for interoperability between the SIP variants.

To summarize, the way outbound calls work is Expressway first attempts to route the call directly using the Standard SIP variant and if that fails, it tries sending the call through CMS so that it can attempt the call as a Microsoft-variant call.

You just need to add a few more rules to the Expressway-C to implement the above requirements. The first is to match calls to non-local domains and send them to the CMS, but at a lower priority (higher priority value) than the existing Outbound Zone rule (with priority 150) so that it only applies if the standards-based call fails.

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

    Parameter Value
    Rule Name Non-Local domains to CMS1a
    Priority 151
    Protocol SIP
    SIP Variant Standards-Based
    Mode Alias pattern match
    Pattern type Regex
    Pattern string (?!.*@(conf\.)?pod7\.cms\.lab).*
    Pattern behavior Leave
    On successful match Continue
    Target CMS1a Zone

  5. Click Create search rule.

Now we add the same rule for CMS1b.

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

Now we add the same rule for CMS1b:

  1. Find the rule just created called Non-Local domains to CMS1a and at the right of that row, click Clone.
  2. Change the Rule Name to Non-Local domains to CMS1b
  3. Change the Priority to 152
  4. Change the Target to CMS1b Zone
  5. Click Create search rule.

And finally we add the rule for CMS1c:

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

Expressway Loop Prevention

One of the challenges with this dial plan, is that it can be prone to routing loops if care is not taken. Specifically, CMS will be configured to forward all domains and then have multiple default routes, because a call may be destined to an unknown domain that is either standards-based or Microsoft SIP. The way we prevent loops here is by adding rules for calls originating from any of the CMS zones destined to unknown domains to route to the Traversal Zone (the Expressway-E) but then stopping.

Part of the complexities of this lab is that between an open federation model and support for numeric dialing from CMS, requires the CMS to have have a rule that forwards calls for all domains and then multiple default routes, since the outbound calls could be destined to Microsoft or standards-based SIP destinations. Basically, anything sent to CMS that is not destined to CMS will be returned as one form of SIP or another. Since Expressway has Search Rules that attempt an external call, then one of the CMS (then another, then the other), there is a huge risk for routing loops.

To mitigate this, we will add a Search rule that takes priority over the other outbound Search rules, such that calls originating from the CMS zones can try the Outbound Zone but will then Stop (as opposed to being sent back to potentially a different CMS).

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

    Parameter Value
    Rule Name Outbound Zone from CMS1a
    Priority 140
    Protocol SIP
    Source Named
    Source name CMS1a Zone
    Mode Alias pattern match
    Pattern type Regex
    Pattern string (?!.*@(conf\.)?pod7\.cms\.lab).*
    Pattern behavior Leave
    On successful match Stop
    Target Traversal Zone

  5. Click Create search rule.

Now we add the same rules for traffic originating from CMS1b and CMS1c.

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 and source Zone

Now we add the same rule for CMS1b:

  1. Find the rule just created called Outbound Zone from CMS1a and at the right of that row, click Clone.
  2. Change the Rule Name to Outbound Zone from CMS1b
  3. Change the Source name to CMS1b Zone
  4. Click Create search rule.

And finally we add the rule for CMS1c:

  1. Find the rule just created called Outbound Zone from CMS1b and at the right of that row, click Clone.
  2. Change the Rule Name to Outbound Zone from CMS1c
  3. Change the Source name to CMS1c Zone
  4. Click Create search rule.

CMS Call Routing

CMS Incoming Calls

From the CMS point of view, any call it receives that is destined to the UC local domain should be forwarded, then sent outbound using standards-based SIP trunk type. Any calls that arrive destined to a non-local/unknown domain should be forwarded and sent as a Lync trunk type. Also, any call that arrives using any of the CMS' FQDN's should be forwarded as well. This is important because Skype for Business users will perform callbacks to the CMS' FQDN domain, a limitation of us anchoring the call at CMS.

The Incoming call portion can be configured from the Web Admin GUI of CMS. Recall that CMS first consults the Call matching rules to see if the domain is to be treated as something that has a CMS-based Space, user, or IVR. If that doesn't match, it looks at the Call forwarding rules to see which domains should be forwarded, which means then that they would be subject to the Outbound calls rules. We want that to happen for every domain.

  1. Access CMS admin for the CMS: https://cms1a.pod7.cms.lab:8443/
  2. Navigate to Configuration > Incoming calls
  3. Add a rule for the local UC domain:
    1. Under Call forwarding, in the first blank row, under Domain matching pattern, enter pod7.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 unknown destinations:
    1. Under Domain matching pattern, enter *
    2. Set the Priority to 0
    3. Change the Forward setting to forward
    4. Set the Caller ID setting to use dial plan. This will cause the From portion to be overwritten later in the Outbound rules, which is needed for Lync/Skype destinations when using a CMS cluster. As a rule of thumb, when forwarding Skype calls, select use dial plan, otherwise select passthrough.
    5. Click Add New

That's it. Everything that doesn't match the CMS domain gets forwarded. Now you must configure the Outbound calls rules.

CMS Outbound Calls

For Lync-type calls in a clustered CMS environment, there is another consideration. For outbound calls from CMS, the Local contact domain must be set to the FQDN of the CMS server from which it originated. By default, the Local contact domain will also be used in the From field as long as "use dial plan" is configured in the forwarding rules for that domain. The From value, in turn, will be used by the S4B destination for callbacks and content sharing. How do we ensure that the outbound rule will fill in all this based on the specific CMS server that it is using? This is done via Call Bridge Scoping.

An example will make this clearer. Because we require Call Bridge scopes, we will need to configure the outbound rules via the API.

  1. Launch Postman and change the verb type to POST
  2. Change the URL field to https://cms1a.pod7.cms.lab:8443/api/v1/outboundDialPlanRules
  3. Click on the Body tab below the URL.
  4. If not already selected, select the x-www-form-urlencoded radio button.
  5. Remove any previously configured parameters
  6. We'll list the necessary parameters, however it is strongly recommended to use Bulk Edit entry mode (using the right column):

    Parameter / Key Value
    domain Left blank, which defaults to "<match all domains>"
    sipProxy expc1a.pod7.cms.lab
    trunkType lync
    failureAction continue
    There will now be multiple default routes, the first will try Lync, the last will try standards-based, which is necessary for numeric dialing from CMS.
    priority 2
    sipControlEncryption encrypted
    Skype/Lync trunks must always be fully encrypted
    localContactDomain
    This will enable the remote clients to be able to call back or share with the call.     		cms1a.pod7.cms.lab
    localFromDomain
    This will make the call as it arrives at the remote end appear as originating from the UC domain.     		pod7.cms.lab
    scope callBridge
    callbridge This will be the callBridge ID value for CB_cms1a obtained from the GET /callBridges

    Paste the following into the Bulk Edit window:

    domain: sipProxy:expc1a.pod7.cms.lab trunkType:lync failureAction:continue priority:2 sipControlEncryption:encrypted localContactDomain:cms1a.pod7.cms.lab localFromDomain:pod7.cms.lab scope:callBridge callbridge:###_Replace_with_CMS1a_callBridge_ID_###
  7. Click Send. Your inputs and the result should look like this (with a different callBridge ID):

  8. Of course, we need to repeat this with CMS1b and CMS1c. We can use the previous POST message. In the Bulk Edit portion, simply replace the localContactDomain line with: localContactDomain:cms1b.pod7.cms.lab and on the callbridge line, replace the callBridgeID with that of the callBridgeID of CB_cms1b (obtained from GET /callBridges
  9. Hit Send
  10. Finally we repeat the steps for CMS1c. Use the previous POST. In the Bulk Edit portion, replace the localContactDomain line with: localContactDomain:cms1c.pod7.cms.lab and on the callbridge line, replace the callBridgeID with that of the callBridgeID of CB_cms1c (from GET /callBridges)
  11. Click Send

If we navigate to CMS1a Outbound Rules (admin / c1sco123), we note the following added rules:

You'll notice the Call Bridge Scope at right has been set and should match the CMS server's fully qualified domain name in the Local contact domain column. Since we were querying CMS1a, the Call Bridge Scope for CB_cms1a shows "<local>"

Test Skype for Business Calls

Now that you have B2B configured and CMS is ready, you should try three different call types:

  • A call from both the Skype and Jabber users directly into a Space.
  • A direct URI call (gateway call) from Jabber to an external Skype user
  • A direct URI call (gateway call) from a Skype user to Jabber

First try calling into a Space. You will need to initiate a call from each of the clients.

  1. Access PC3, your "outside" client. Make sure Chrome is quit
  2. Open up the Skype for Business client. In the FAVORITES folder, find the pod7user4.space@conf.pod7.cms.lab Contact
  3. Right-click on the contact
  4. Click Start a Video Call. The call will be auto-answered and you will be in User4's meeting Space
  5. From Jabber on your laptop, dial pod7user4.space@conf.pod7.cms.lab

You should now be in the same Space with the Lync user. Feel free to call that same URI from the other Jabber users on PC1 and PC2. You can also try application sharing. This sets up an additional call for the Skype for Business user. You can monitor this on the CMS. Once finished, disconnect all call legs.

Now try calling from Jabber to the Skype for Business user at skype7@ms.lab. Be sure to access PC3 and answer this call with video, as there is no auto-answer.


         Skype for Business
User Answers 		    

You should now have an established call between Jabber and Skype for Business.

    
Jabber
Skype For Business
 		    

Next, reverse the call flow and call from Skype for Business to Jabber. The Skype client must call pod7user4@pod7.cms.lab, the URI of User4 on your laptop. You should find this in the Favorites folder of the Skype for Business client.

  1. Disconnect the previous call.
  2. On PC3, in the FAVORITES folder of the Skype for Business client, find the pod7user4@pod7.cms.lab
  3. Right-click on the contact
  4. Click Start a Video Call
  5. On your laptop, answer the call on Jabber

You should now have the same call up as before, but initiated from Skype for Business. When done, disconnect the call from all endpoints.

 

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.