When we talk about Collaboration, the most important component that comes is the Call Routing or the Call Flow, on Cisco Meeting Server, the server that brings audio, video and web conferencing has an interesting Call Routing Logic based on three tables, like with Cisco Unified Communication Manager as a Call Processing server, understanding this Call Routing Logic is essential for any engineer in order to be comfortable when implementing, troubleshooting and analysing call issues and even when explaining Cisco Meeting Server in training and stuff like that. If you are able to differentiate between these three tables and understand the call routing flow, then the rest is just simple implementation you can find in any Cisco DOC.
How Cisco CMS processes and handles incoming and outgoing calls?
See below with amazing calls with domain that does not exist and how CMS processes the call in action with SIP Trace and to make the call routed out successfully by CMS so that you will demystify the most important component in Cisco CMS.
This is the order of call route process within Cisco Meeting Server:
- Incoming Call Matching Table
- Incoming Call Forwarding Table
- Outbound Call Table
The only exception would be for CMS initiated calls (either CMS directly for TelePresence Management Suite (TMS) scheduled outbound calls or CMA client calls out) in which the call forwarding table is bypassed.
Incoming Call Table
This is the first step in the process in which CMS determines whether the inbound call is destined for the Cisco Meeting Server itself and would need to process on it further or whether it is a call destined for a different system in which CMS is the agent that interworks the call and handles both the media and signaling (f.e. Skype gateway calls to Standard SIP endpoints or vice versa).
It checks if the domain part of the incoming URI matches the incoming matching table or not. If it does match, it is able to route the call to space, user, IVR or do a Lync conference lookup.
For example. When a user registered to HQ-CUCM wants to join this meeting, he dials email@example.com, the call is sent to the call control HQ-CUCM, a SIP route pattern with domain routing demystify.com should be configured on HQ-CUCM that points to the SIP Trunk to CMS Cluster (the configuration will be done later), the CMS lookup the host portion @demystify.com for a matching in the Incoming Calls Table and a Domain name demystify.com exists, then the CMS lookup the User portion meet@ to find a matching in the Spaces Table and a space with User Portion URI exists, finally the user joins the meeting named Demystifying Everything Meeting.
To understand how Cisco Meeting Server processes the calls through the three tables. Let’s dial firstname.lastname@example.org from jsmith jabber client, the call is sent to the HQ-CUCM, the call control HQ-CUCM has a SIP Route Pattern with domain routing mylab.local that points to HQ-CMS.
In the SIP Trace of HQ-CMS, we can see that since the call did not match any incoming rule with domain name mylab.local. The HQ-CMS goes to the Call Forwarding Table.
The Forwarding Table does not have any rule or a reject rule, then the event log does not explicitly show this. HQ-CMS just informs us that the call did not match a Destination URI in other words any space, user, IVR or Lync meeting.
Incoming Call Forwarding Table
If the call did not match any of the rules on the incoming call matching table, it goes through the second table called the call forwarding table. This is domain based only, you can block calls to certain domains or allow calls to certain domains.
Let’s configure a Call Forwarding Rule with the Domain matching pattern mylab.local. The Rewrite Domain option allows you to rewrite the domain of the inbound call to a different one and changes the To header of the SIP message as well. To ensure that the email@example.com jabber client will ring, the domain dialed mylab.local must be changed to lab.local.
The SIP Trace shown that an inbound call with domain mylab.com is received from firstname.lastname@example.org to email@example.com but without a match on the incoming call table (either on spaces, users, IVR or Skype conferences), next the HQ-CMS lookup the Call Forwarding Table.
A match is found with the domain matching pattern mylab.local to process the call.
In the SIP Trace, the Forwarding Call line shows the modification of the domain. It displays the modification of mylab.local domain to lab.local domain.
But when the HQ-CMS lookup the Outbound Calls Table, there is no match and the outgoing call fails.
Outbound Call Table
This is the last table in the call routing logic of Cisco Meeting Server that makes the call out to different server. In other words CMS will use an outbound rule to send the call to another call control for example Cisco Unified Communication Manager or Cisco Expressway-C.
To better understand let’s take another scenario:
- User firstname.lastname@example.org is registered using Cisco Jabber to HQ-CUCM.
- Active Directory is integrated to CMS Cisco Meeting Server and the user email@example.com is NOT imported into CMS.
- Another user join a conference using a web browser.
- An administrator tries to add the user firstname.lastname@example.org to meeting using the “Add Participant” option in Cisco Meeting Management CMM.
- The CMS will try to find an Outbound Call Rule with Domain lab.local and the SIP Proxy to use (in this case 10.1.5.15) to route out the call, an Outbound Call Rule is similar to SIP Route Pattern on CUCM.
- The HQ-CUCM will receive the call and find that the email@example.com is registered and the Client Jabber rings.
Therefore to allow the HQ-CMS to route out or to send a call to any domain for example lab.local, the Outbound Calls Table is there to accomplish this task after the Incoming Calls Table and Call Forwarding Table checked respectively.
In case you match a rule with the Behavior set to Stop, the call does not go through the rest of the table after that match and the call has failed if that SIP Proxy failed to route the call for example. When that setting would be set to Continue, you could allow for a fallback to a different route or different node in the cluster.
Let’s add Outbound Call Rule, in the Domain, enter lab.local, in the SIP proxy to use, enter the IP address of HQ-CUCM 10.1.5.15, we can use hq-cucm.lab.local. The CMS will query the internal DNS Server to resolve the IP address of HQ-CUCM.
The SIP Trace shown that after a non-matching in the Incoming Calls Table, the HQ-CMS lookup in the Call Forwarding Table and find a match for mylab.local, it applies the transformation of the Host part of the URI of the destination firstname.lastname@example.org, from mylab.local to lab.local. Caller ID of the Call Forwarding Rule is set to use Dial Plan option. There are two options here that can be set on the forwarding rules. Either it is set to pass through and then no modification is made on domain of the outbound INVITEs or it is set to use dial plan which allows the system to modify the domain of the inbound call to a different one as per the Outbound Calls rules, in this case the Call Forwarding Rule with Caller ID set to Dial Plan will modify the destination domain mylab.local to lab.local in order to match the Outbound Call Rule configured with a domain lab.local.
The outgoing connection successful line confirms that a match is found in the Outbound Calls table.
As mentioned for Call Forwarding Table, for Caller ID field, there are two options here that can be set on the forwarding rules. Either it is set to pass through and then no modification is made on the From header of the outbound INVITEs or it is set to use dial plan which allows the system to modify the From header as per the outbound rules.
Below there is an outbound dial plan rule to lab.local (as after the rewrite domain on the call forwarding table). Notice the From email@example.com (IP of the CallBridge) with Caller ID set to Dial Plan. The Contact header firstname.lastname@example.org is always adapted as CMS CallBridge.
Let’s change the Caller ID in the Call Forwarding Rule to pass through. With pass through, there would not be any modification on the From header as shown email@example.com. The Contact header is still set to firstname.lastname@example.org as CMS starts a new callLeg and thus must add in a Contact header to itself.
The Local From Domain and Local Contact Domain in the Call Outbound rule can be filled in to point to another domain redouane.com and meddane.com respectively. This then reflects the change on From email@example.com and Contact header firstname.lastname@example.org of the outbound SIP INVITE.
Let’s modify the Caller ID of the Incoming Call Rule to use dial plan.
Edit the Outbound Call Rule and modify the Local contact domain to redouane.com and Local from domain to meddane.com.
The Local From Domain at the Call Outbound Rule can be changed only when you use the dial plan as the Caller ID inthe Incoming Call Rule since the pass through option does not modify the From header of the outbound SIP INVITE which is still email@example.com as shown below with pass through.