Ad Hoc Conferencing

In traditional Unified CM telephony, ad-hoc conferencing is a call by which two participants are talking directly to one another when one party (using a device registered to the Unified CM) presses the Conference button, calls a different person, and after talking to that 3rd party, presses the Conference button again to join everyone into a 3-party conference. The exact steps may vary depending on the endpoint (e.g. Jabber vs. a physical phone endpoint), but it is always a non-scheduled escalation of a point-to-point call to a multi-party conference.

What makes this feature different than a scheduled or permanent conference is that an adhoc conference is not simply a SIP call to the CMS, as you will see from the configuration on the Unified CM. When the conference initiator presses the Conference button the second time to bring everyone into the same meeting, Unified CM must make an API call to CMS to create a conference on the fly, to which all the calls are then transferred. All this happens transparently to the participants.

This means that Unified CM needs to have the API credentials and Web Admin address/port configured, as well as a SIP trunk directly to the CMS server in in order to extend the call.

When required, CUCM can then dynamically create a Space on CMS, so that each call can be extended directly to CMS and match an Incoming call rule that targets Spaces. Therefore direct SIP trunks to each CMS node in the cluster are required on the Unfied CM. This is required for any Unified CM Integration.

CMS Incoming Call Rules

1. Log into the CMS admin for cms1a: https://cms1a.pod8.cms.lab:8443 (Username admin and Password c1sco123)
2. Navigate to Configuration > Incoming calls
3. Under Call matching, in the Domain name field, enter cms1a.pod8.cms.lab
4. For the Priority enter 50.
5. Click Add New
6. Now add another rule for domain name cms1b.pod8.cms.lab
7. Finally, add a rule for domain name cms1c.pod8.cms.lab

You should see:

Note that the domain portion of the Request-URI in the SIP INVITE to a Call Bridge must match one of the configured inbound rules. In this lab, you configured the SIP Trunk Destination on the Unified CM server with the FQDN of the CMS server, cms1a.pod8.cms.lab for the case of cms1a. If the SIP trunk were configured with an IP address, for example, then you would need to add the IP addresses of your CMS servers to the list of domains in the Call matching rules and make sure Target Spaces is set to Yes.

In order to configure the Conference Bridge, a SIP trunk to CMS must exist. We'll configure that first.

SIP Trunk Security Profile

For a secure SIP trunk, you first need to create a SIP Trunk Security Profile that allows for encrypted calls.

1. Access the Unified CM at https://cucm1a.pod8.cms.lab/ccmadmin/showHome.do
2. Log in with username admin and password c1sco123.
3. Navigate to System > Security > SIP Trunk Security Profile
4. Click Add New
5. Fill in name: Encrypted SIP Trunk Profile for CMS1
6. In the Device Security Mode pull-down, choose Encrypted. That should change the Incoming and Outgoing Transport Type to TLS.
7. In the X.509 Subject Name field, enter: cms1a.pod8.cms.lab,cms1b.pod8.cms.lab,cms1c.pod8.cms.lab. These are from the SubjectAlternateNames that were specified in the Call Bridge certificates (which you could double-check from the CMS MMP with the pki inspect certname.cer command). We put all of them in there so we can use a single SIP Trunk Security profile on all of the SIP Trunks to each CMS.
8. The Incoming Port should be 5061
9. Select the Accept replaces header checkbox. CMS can use the REPLACES method in SIP to redirect calls from one CMS to another to optimize usage. This will be discussed in additional detail when we discuss Call Bridge Groups later in the lab.
10. Press Save.

SIP Trunk Configuration

Now you can configure the SIP trunks from the UCM cluster to each of the CMS servers.

Add Trunk for CMS1a

1. In Unified CM, navigate to Device > Trunk.
2. Click Add New
3. For Trunk Type, select SIP Trunk
4. Click Next
5. Configure the following parameters:
   
   

   Parameter	Value
   Device Name	CMS1A-SIP-TRUNK
   Device Pool	Default
   SRTP Allowed	Checked
   Run On All Active Unified CM Nodes	Checked
   Calling Search Space (under the Inbound Calls section)	CSS_INBOUND_CMS This Calling Search Space is used to limit the calls that can originate from CMS. CMS should be able to call other video endpoints, but should not have PSTN access in this deployment to avoid any potential toll-fraud issues.
   Calling and Connected Party Info Format	Deliver URI and DN in connected party, if available
   Destination	cms1a.pod8.cms.lab NOTE: You will only configure one destination per trunk. This is because later on, for the ad-hoc conferencing feature, Unified CM needs the ability to send an API message to a specific Call Bridge server and then use a SIP trunk that can only reach that specific server. Also, if for some reason you see 16 blank lines for entering a destination, this is a browser problem (there should only be 1 shown by default). Use the '-' button to remove the lines 2 through 16 before saving the SIP trunk.
   Destination Port	5061
   SIP Trunk Security Profile	Encrypted SIP Trunk Profile for CMS1
   Rerouting Calling Search Space	CSS_CMS_REROUTING Note: This parameter is needed for Call Bridge Groups, to be discussed later.
   SIP Profile	LTRCOL-2250 SIP Profile
   Normalization Script	cisco-meeting-server-interop Note that this is Unified CM 11.5. In older versions of Unified CM, the cisco-meeting-server-interop script did not exist, but could be manually uploaded or you could use the older conductor-interop script that existed in older versions of UCM.


 

 

 

 
6. Click Save
7. Click OK on the popup
8. Click Reset. This step is extremely important for the changes to take effect.
9. On the Device Reset popup click Reset
10. Click Close
    
    

You should now have three SIP trunks configured. If you navigate to Device > Trunk in Unified CM Administration and click Find, you should see the trunks go in service as the SIP OPTIONS messages are answered. This can take a couple of minutes. Sometimes the admin page will report that SIP OPTIONS are not enabled until it goes to Full Service.

Adhoc Conference Bridge Configuration for cms1a

Start by configuring a conference bridge resource on the Unified CM cluster pointing to cms1a by following these steps:

1. Access the Unified CM at https://cucm1a.pod8.cms.lab
2. Log in with username admin and password c1sco123
3. Navigate to Media Resources > Conference Bridge
4. Click Add New
5. For Conference Bridge Type, select Cisco Meeting Server
6. In the Conference Bridge Name field, enter CFB_CMS1A
7. The Conference Bridge Prefix use a value of 1001.
   The Conference Bridge Prefix is a prefix that Unified CM uses when creating the Spaces for adhoc conferences on CMS. The Unified CM will create a randomly generated meeting number for each adhoc conference; however if you have multiple Unified CM clusters using the same CMS for ad-hoc conferences, there's a possibility two clusters could choose the same ID. To ensure this does not happen the value specified in this parameter is prefixed to the randomly generated number and the resulting value is used to generate the meeting ID on CMS.
   Best practice is to use a globally unique value for each conference bridge resource you create. Having a unique value also can aid in troubleshooting because it allows you to easily identify which Unified CM cluster created a particular conference when you observe it in CMS.
8. For the SIP Trunk, choose CMS1A-SIP-TRUNK
   By default, this setting determines not just the SIP trunk that will be used to route the SIP calls to CMS, but also the destination for API messages as well. Whatever is configured as the destination address on the SIP trunk will be used as the HTTPS destination for API messages.
9. Check the Allow Conference Bridge Control of the Call Security Icon. This helps participants know whether or not all participants in a conference are using media encryption.
10. The HTTPS Interface Info section allows you to configure the authentication and port information for the API. In the Username field, enter apiadmin
11. Set the Password to c1sco123
12. Set the Confirm Password to c1sco123
13. The HTTPS Port must match the CMS Web Admin listening port, which is 8443
    Note: You CANNOT use HTTP for this. All communications must be over HTTPS, which means that the CMS certificates must be loaded on the Unified CM so that Unified CM trusts the certificates presented by CMS. The CMS certificates have already been pre-loaded onto the Unified CM cluster for you.
14. Click Save

15. Click the Reset button
16. In the pop-up, click the Reset button again.
17. Click the Close button.

If you reload the web page after a few seconds, the status of Conference Bridge device should eventually indicate it is registered. You may have wait up to 30 seconds and reload the page for the status to update.

The registration status only indicates the health of the API connectivity between Unified CM and the CMS server. The status does not have anything to do with the status of the SIP trunk. To become registered, the Unified CM connects to the CMS using the address, port, and credentials supplied. It then sends a GET request to the destination configured on the SIP trunk on the configured port, to check the CMS' system status. For the conference resource you just configured, this would be: https://cms1a.pod8.cms.lab:8443/api/v1/system/status. If you like, you can check this status from your browser using the GET /system/status (username: admin with password: c1sco123) request. The results will something like this:

If there is no response, or the Call Bridge isn't active, or any other error is returned, the conference bridge resource will not show as being registered. There is also one other important consideration: Remember that this connection always uses HTTPS. For that reason, the Unified CM MUST trust the certificate, specifically the Web Admin certificate, that the CMS presents when Unified CM connects to it.

Adhoc Conference Bridge Configuration for cms1b

If you go back to Media Resources > Conference Bridge, and click the Find button, you should see that all three conference bridges are registered. If you don't the the last one you just configured registered yet, wait a few seconds and click Find again. Ignore the two devices named CFB_2 and CFB_3. These are software conference resources that are not being used.

Media Resource Group / List

Now that you have configured the Conference Bridge resources, you must configure Unified CM to make them available to users. By default, any device not assigned to a Media Resource Group is available to any user, however it is best practice to assign media resources to a Media Resource Group (MRG) and Media Resource Group List (MRGL) and then use the list to control how those resources are used.

Start by following these steps to add the Media Resource Group:

1. In Unified CM, navigate to Media Resources > Media Resource Group
2. Click Add New
3. In the Name field, enter MRG_CMS1
4. In the Available Media Resources box, select CFB_CMS1A, then the down arrow to move it into the Selected Media Resources section.
5. Repeat this process to move CFB_CMS1B, into the Selected Media Resources section.
6. And finally click on CFB_CMS1C to move it down to the Selected Media Resources
7. Click Save

Now that you have created the Media Resource Group, proceed to create the Media Resource Group List by following these steps:

1. On Unified CM, navigate to Media Resources > Media Resource Group List
2. Click Add New
3. In the Name field, enter MRGL_CMS1
4. In the Available Media Resource Groups box, select MRG_CMS1, then the down arrow to move it into the Selected Media Resources section.
5. Click Save

The last step is to assign the MRGL to devices that are allowed to use it. You could apply this MRGL to a device directly, however in most cases, it is best to assign the MRGL to a Device Pool to make it available to all the devices in the Device Pool. Follow these steps to add the MRGL you created to the Default Device Pool that is being used by your devices.

1. On Unified CM, navigate to System > Device Pool
2. Click Find
3. Click on the Default Device Pool
4. On the Media Resource Group List field, select MRGL_CMS1
5. Click Save
6. The devices must be reset for this change to take effect. Click Reset
7. In the pop-up window, click Reset
8. Then click Close to close the window

Test Adhoc Conferencing

Now that you have everything configured, you can test making an adhoc conference call. From the Jabber endpoint on your laptop (Pod8 User4), you will place a call to Pod8 User1 by dialing +19195080001. This is a Jabber client on one of your Remote Desktop sessions (PC1). After the call is connected, you will then call Pod8 User2 (Remote Desktop session to PC2) and join the two calls into a conference. There are a few ways to perform this task this in Jabber, but you'll use the way that most closely replicates the sequence you would use on a physical phone endpoint.

1. From your laptop's Jabber client, click to call +19195080001, which is Pod8 User1.
   The call will be auto-answered.

   Pod8 User1 Auto-Answers



NOTE: If at any point the remote side does not answer, this usually means Jabber on PC1 or PC2 is either not launched or still on an active call. Access PC1 or PC2 via the Remote Desktop shortcuts on your desktop. Then disconnect/restart Jabber.
2. Once the call is active, press the button to mute your audio just to avoid any feedback.
3. Now press the symbol for additional options, when you hover the mouse over the Jabber call window (Chuck's video)
4. Next, click the Conference selection
   
   
   
   
5. Dial Pod8 User2 by pasting +19195080002 into the Invite Participants search field and then hit enter
   
   
   
   
6. You now have a direct call between your laptop and User 2 (Amy) while the call to User 1 (Chuck) is on hold. Join the three calls by clicking on the green button and you should be in a meeting with everyone.
   
7. And now we're in a secure CMS conference with all three participants. From here you can change your layout, mute and remove remote participants
   
   
   
   
8. When finished, disconnect the remote callers first. Hover over each user in the participant list, right-click and select the Expel option.
9. Once all remote callers have been disconnected, hang up yourself by hovering over the video window and clicking on the button

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.

• Understand other CMS features, such as:
  • Spaces, to understand more about how Spaces are organized and configured.
  • CallBridge Groups for load balancing calls
  • Branding, for a more customized deployment.
• Explore Cisco Single Edge with Cisco Expressway and CMS:
  • Learn about deploying the external WebRTC Web App using Cisco Expressway, to provide external users the same Web Bridge capability.
  • Configure advanced Business-to-business calling with Skype for Business gateway calling.
• Investigate a Microsoft on-premise integration example, where you will learn about what is needed to configure a dual-home conferencing experience.
• Experience Cisco Meeting Management (CMM), our free product to allow video conference administrators to provide white-glove conferencing services.