This article describes the call routing logic of the Cisco Meeting Server using the incoming call rules, outbound call rules and forwarding call rules.
Components Used
The article is based on Cisco Meeting Server version 3.0.0.
The call routing on CMS involves a three call routing different tables.
Order of call processing
- 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.
Below the chart flow.
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 meet@demystify.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 jdoe@mylab.local 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 CMS-A.
In the SIP Trace of CMS-A, we can see that since the call did not match any incoming rule with domain name mylab.local. The CMS-A 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. CMS-A 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 jdoe@lab.local jabber client will ring, the domain dialed mylab.local must be changed to lab.local.
Let’s try another call from jsmith jabber client to jdoe@lab.local by dialing jdoe@mylab.com.
The SIP Trace shown that an inbound call with domain mylab.com is received from jsmith@lab.local to jdoe@mylab.local but without a match on the incoming call table (either on spaces, users, IVR or Skype conferences), next the CMS-A 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 CMS-A 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 jdoe@lab.local is registered using Cisco Jabber to HQ-CUCM.
- Active Directory is integrated to CMS Cisco Meeting Server and the user jdoe@lab.local is NOT imported into CMS.
- Another user join a conference using a web browser.
- An administrator tries to add the user jdoe@lab.local 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 user jdoe@lab.local is registered and the Client Jabber rings.
Therefore to allow the CMS-A 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.
Let’s try another call from jsmith jabber client to jdoe@lab.local by dialing jdoe@mylab.com..
The SIP Trace shown that after a non-matching in the Incoming Calls Table, the CMS-A 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 jdoe@mylab.local, 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 header jsmith@10.1.5.20 (IP of the CallBridge) with Caller ID set to Dial Plan. The Contact header jsmith@10.1.5.20 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 below jsmith@lab.local. The Contact header is still set to jsmith@10.1.5.20 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 jsmith@redouane.com and Contact header jsmith@meddane.com 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.
Notice the change on From header jsmith@redouane.com and Contact header jsmith@meddane.com of the outbound SIP INVITE as shown below.
The Local From Domain at the Call Outbound Rule can be changed only when you use the dial plan as the Caller ID in the Incoming Call Rule since the pass through option does not modify the From header of the outbound SIP INVITE which is still jsmith@lab.local as shown below with pass through.
Finally the jdoe@lab.local rings by dialing the URI jdoe@mylab.local.
If there is no entry in the Outgoing Call table, the Cisco CMS can route the call out by resolving on DNS SRV records (_sips._tcp / _sip._tcp / _sip._udp) for that particular domain, lab.local in this example. If the table is not empty, but there is no match for the dialed domain then the same DNS lookup logic is performed.
Let's remove the Outgoing Call Rule for lab.local that points to HQ-CUCM 10.1.5.15.
On the DNS Server 10.1.5.19, let's add a DNS SRV Record _sip._tcp that resolve to the FQDN hq-cucm.lab.local, a A record is already added to resolve the FQDN to the IP address 10.1.5.15.
From jsmith@lab.local client jabber, dials jdoe@mylab.local, after the rewriting of the domain mylab.local to lab.local on the incoming call forwarding table, with DNS tracing and SIP tracing show us the DNS SRV Record _sip._tcp is sent to the DNS Server 10.1.5.19 and retrieves the SIP Server's IP address 10.1.5.15 to extend an outgoing call to jdoe@lab.local.
Finally the jdoe@lab.local rings.
