Now that you have configured Spaces that contain the user portion of the URI, you still need to configure the
domains for which this Space applies. You do that via Incoming Call matching rules.
To determine how a call is handled, CMS only looks
at the domain in the SIP Request-URI field. So if the SIP INVITE is destined to
sip:user@domain.com, CMS only cares about the domain.com.
CMS follows these rules for determining where to route a call:
CMS tries to match the SIP domain to those configured on the Incoming call matching rules. Those
calls can then be routed to any configured Spaces, logged-in users, internal IVRs, or to look up a
conference on a Microsoft Lync / Skype for Business (S4B) / O365 integration.
If there is no match on the Incoming call matching rules, CMS will try to match a domain
configured in the Call forwarding table. If a match is made, the rule can explicitly reject a call or
forward a call. At that time, CMS can re-write the domain, which is sometimes useful for calls to Lync
domains. You can also choose to pass through the call, meaning that none of the fields will be further
modified, or to use the internal CMS dial plan. If there is no match in the Call forwarding rules,
the default behavior is to reject the call. Keep in mind that forwarding will still anchor the call
at CMS, so you're essentially placing CMS in the middle of the call flow.
Only forwarded calls are then subject to the Outbound call rules. These settings define the destinations
where to send the calls, the trunk type (whether or not the new call will be Lync or standard SIP),
and any transformations that may be performed, if pass-through is not selected in the call forwarding rule.
Incoming Call Rules
Configuring Incoming Call Settings is required to be able to receive a call on CMS. In this lab, you want all
Spaces to have a dedicated domain, conf.pod8.cms.lab. So at minimum, you want calls to that domain to target
the Spaces.
Follow these steps to configure the Incoming Call Settings on your CMS cluster:
Under Call matching, in the Domain name field, enter
conf.pod8.cms.lab
For the Priority enter
100. This will make this rule
the highest priority on the list. Unlike other products, such as the VCS / Expressway, CMS uses the
highest value to indicate the highest priority.
Click Add New
Notice that there are currently no forwarding rules configured and that the catch-all rule is set to reject calls.
Allow Media Encryption
Aside from the inbound/outbound calling parameters, there is one SIP setting in CMS that need to be
configured to allow for encrypted calls. Configure that by following these steps:
For SIP media encryption, select allowed from the drop-down
Click Submit at the bottom
We've done all we needed to do on the Cisco Meeting Server to accept calls. Next we will quickly take a look
at outbound calling and then configure the Unified CM and Expressway-C to route calls to CMS.
LTRCOL-2250 - Multiparty Conferencing for Audio, Video and Web Collaboration using Cisco Meeting Server
This lab provides participants hands-on experience with design and implementation fundamentals
of the Cisco Meeting Server (CMS), bringing premises-based multiparty conferencing of video,
audio, and web collaboration together in one platform.
Students will learn to configure CMS
and deploy a secure, scalable, and resilient collaboration solution following Cisco's Preferred
Architecture including the ability to extend the platform beyond the corporate firewall and
allow external Internet participants. The lab will allow students to configure the various
components of CMS, such as Call Bridge, Web Bridge, and XMPP server. These systems will be
integrated with Cisco Unified CM for call control, an LDAP server for authentication and
directory services, and Cisco Expressway for firewall traversal, TURN server and Web Proxy
capabilities to enable secure access for external, WebRTC-enabled browser clients.
Third-party integrations, such as Skype for Business, are explored as well.