I presume you read this here:
TLS i'm not so bothered about as all communication will be internal, i know the client will want call scheduling and BFCP for content sharing though.
I was referring to different doc.but anyways that doesn't matter..
Cisco TelePresence MCU
Cisco TelePresence MCU is a set of hardware conference bridges for Cisco Unified Communications Manager.
The Cisco TelePresence MCU is a high-definition (HD) multipoint video conferencing bridge. It delivers up to 1080p at 30 frames per second, full continuous presence for all conferences, full transcoding, and is ideal for mixed HD endpoint environments.
The Cisco TelePresence MCU supports SIP as the signaling call control protocol. It has a built in Web Server that allows for complete configuration, control, and monitoring of the system and conferences. The Cisco TelePresence MCU provides XML management API over HTTP.
Cisco TelePresence MCU allows both ad hoc and meet-me voice and video conferencing. Each conference bridge can host several simultaneous, multiparty conferences.
Cisco TelePresence MCU must be configured in Port Reservation mode. For more information, consult the Cisco TelePresence MCU Configuration Guide.
Note Cisco TelePresence MCU does not support a common out-of-band DTMF method. Under the default setting, Cisco Unified Communications Manager will not require an MTP. However, if the Media Termination Point Required check box is checked, Cisco Unified Communications Manager will allocate an MTP and the SIP trunk will negotiate DTMF according to RFC 2833.
Note BFCP is not supported when used between Cisco Unified Communications Manager and Cisco TelePresence MCU.
Note TLS is not supported with Cisco TelePresence MCU.
However if you registered the MCU as conf bridge under the conf bridge resources then it can be invoked in a ad-hoc manner creating a conf on the mcu..i was doing a testing couple of days before only..
check this thread
However if you check the SRND 8.x you will find that it does talks about two different ways of it.
H.323 and SIP MCU Resources
When configured in H.323 or SIP mode, the MCU provides the MC function and behaves like an H.323
or SIP peer to Unified CM. Because of SIP features available in the current release of Unified CM, SIP
is the preferred choice for integration of MCUs. Cisco recommends registering H.323 MCU resources
to a Cisco VCS and using its H.323-SIP interworking capabilities to peer it with Unified CM through a
H.323 and SIP MCU conferences can be invoked in a number of different ways, but they all fall into two
A scheduled conference uses a scheduling application to reserve the MCU resources in advance of the
call. The scheduling function typically is provided through a web-based user interface such as
Cisco Unified MeetingPlace, or Cisco Unified Video Conferencing Manager. The scheduling
application usually generates an invitation that provides the user with the date and time of the
conference, the number of ports reserved for the conference, and the dial-in information. Alternatively,
the scheduling system can be configured to dial out to some or all of the participants at the beginning of
For a reservationless conference, the MCU has a certain number of resources that are available on
demand. To create a conference, a user simply dials into the MCU at any time. If that user is the first
participant to dial in, the MCU dynamically creates a new conference using the settings defined in the
service template. Subsequent users who dial into the same conference number are joined to that
I think for schedule meetings you can create conf rooms and using route pattern you can route those calls to MCU. however then you won't be having MCU under hardware conf bridge on the CUCM.
Let me test this in my lab when i would be in office. I will share the result.
Thanks for the response, the thread you pointed me at was useful.
I don't suppose you would know if call scheduling will be possible from Cisco TMS in the future?, as opposed to MeetingPlace or Videoconferencing Manager.
For this scenario reservationless conferences from Jabber for Windows clients will be the primary method, with scheduled being an option for larger conferences if required.
today i perform some test with the setup in my lab and i can initiate a adhoc conference on a fly that is performing conf call on a fly + dialing to a MCU schedule conference.
however doing this i am having a challenge that CUCM doesn't allow me to put the same ip-address in the hardware conference bridge and sip trunk, but for dialing to schedule conferences i used mcu as h.323 gateway on cucm and i was able to perform dial into the conference.
i got some workaround to have a dialout from the MCU to cucm endpoints but i don't like it and i am still looking how to achieve this part properly!!
i think atleast now you have two things..one you can have the conf calls on fly and seconds you can dial into mcu schedule conferences.
will update the thread if i get a good solution for dialout conf from MCU using some scheduling
Am i correct in thinking, once you add the MCU in CUCM as a 'conference bridge', endpoints or jabber for windows clients registered to CUCM escalate a point to point call to a multipoint, based on a specific SIP signalling message from CUCM to MCU? This way the MCU does not require a number range as these conferences would just be provisioned on the fly.
I'm not sure the workaround your looking at would provide a seamless method of mcu call escalation (i may be wrong), as the majority of calls into this MCU will be from Jabber for windows clients registered to CUCM.
I appreciate your time on this!
In one way what you say is right. Although its not the same as multiway escalation but i guess the backend task would be simillar.
In this case what you need to ensure is that whoever is the conference initiator is should have the MRGL allocated MCU as conf bridge. this way he should be able to create on the fly conf using CUCM to send commands to MCU.
for e.g. endpoint A is on call with endpoint and now endpoint A wants to take endpoint c in conf. so he just press the conf key and initiate a conf with A,B & C all are conf. Once he press the conf necessary API commands would be sent an on the fly conf gets created on the MCU.
you can also allow the users to dial in the schedule conferences on the MCU at the same time, but as i said after adding the conf bridge it doesn't allows me to create SIP trunk to same ip-address. so i used H.323 gateway for dialing into schedule conferences.
for e.g. i have conf 3000 on the MCU. i will just create a route pattern and then point it to h.323 gateway which is going to MCU. this way cucm endpoints can dial into the the MCU schedule conf.
i am currently checking how effective i can make a dialout conf from MCU to endpoint on CUCM.
I see where you are coming from now, so i could set up the MCU as a conference bridge and use the call escalation (similar to multiway) for Jabber for Windows Clients, as well as setting up a H323 gateway for pre-defined conferences.
It will be interesting to see what results you come back with!
Thats right Simon..I tested it and works fine..i am currently testing with MCU dialout.
in my view what customer wants with CUCM and MCU are following:
- on the fly conf with video participants (tested and working)
- dialing to conf scheduled on MCU (tested and working)
- MCU dial out to CUCM endpoints ( tricky and currently testing with it,i can make a workaround for it but i don't like it)
Can you help me with the following question:
The BFCP for content sharing is supported in this deployment modelo? have you tried it?
Thanks a lot.
Found this thread as I was working through a few issues and think I might be able to help with a couple of the outstanding questions.
1) I was able to get the MCU registered as an ad-hoc resource and SIP trunk at the same time. The 'trick' was to change the CM SIP Port to something other than 5060 (I used 5061) on the CFB in CUCM. This removed the conflict and I reason that since the CFB is only used for ad-hoc calling, so the MCU should never be dialing back in on that particular device...therefore that port shouldn't matter. It seems to work just fine, but if you are aware of a limitation or something this might break, please let me know.
2) The presentation sharing seems to work just fine with the endpoints and MCU all using CUCM (8.6.2). I'm not really sure which protocol it's using, but it does work as advertised when using voice switched, continuous presence and enhanced cp.
3) I was able to add my CM registered endpoints (SX and EX series) into the MCU using SIP URIs and then schedule a conference directly on the MCU and it dialed out and worked just fine. Of course, the TMS scheduling and integration is better, especially when integrated with Exchange, but this definitely works.
Hope this helps!
Regarding to presentation function, presentation by using BFCP works with CUCM 8.6.2 or newer release.
Make sure ticking “Allow Presentation Sharing using BFCP ” parameter in SIP profile configuration on CUCM which assigned to devices for conference with presentation.
This is a great question and I could take a stab at it, but would really like someone from Cisco to confirm. If you register the MCU using H.323 to a VCS Control, and register the same MCU to CUCM using SIP, you should be able to use the MCU for both your VCS and your CUCM registered endpoints. The MCU will need to be in port reservation mode, which means it is going to be a scheduled resource. I would think that you could schedule conferences on this MCU using TMS for video endpoints registered to the VCS Control...and that you could also have ad-hoc conferencing capability for Jabber for Windows clients (which would be registered to CUCM). I am not sure of caveats and have not seen a document that spells out the process and any complications or best practices for using the MCU in this scenario.