Telepresence MCU - Port reservation vs Adhoc Conferencing

[emresumengen]

Hi all,

I was wondering why is the MCU software disabling creation of adhoc conferences for unknown calls, when media port reservation is turned on.

Is there a way to make multiway work on an mcu, which has port reservation turned on?

Thanks all,

Emre       

[Paulo Souza · Accepted solution]

Hi,

Do you want to know why MCU works this way? That is simple, because this the only behavior that makes sense for "reservation" concept. Consider the follow example:

You have scheduled a conference in MCU to tomorrow morning starting 10 AM. You have a MCU 4510 with 20 HD ports available, and you have selected 18 participants for this particular conference, and you are using port reservation, which means you want MCU to make sure that these ports will be available to host this conference. Right. Then, tomorrow morning, right before the scheduled conference starts, some users start a adhoc multipoint meeting using multiway and get 4 video ports of your MCU. Then, when the scheduled conference starts, MCU won't have ports available to host your scheduled conference, once your users are using the resources for adhoc purposes.

Do you see? Port reservation is a concept where MCU must to make sure that you will have resource available for that particular conference, therefore, the only way to achieve this goal is by totally disabling non-scheduled conferences (adhoc conferences), so that MCU will be able to control all the meeting and know when its resources will be available or not, either using MCU for scheduling or TMS.

In another words, if MCU allowed you to create conferences every time you want via adhoc, then the reservation concept is totally broken, you wouldn't have any guarantee that your resources are really reserved.

Therefore, if you need to have scheduled and adhoc conferences going on in the same MCU, disable reservation and control your resources availability manually. If you need to have port reservation and at the same time adhoc conferences, there is no way except placing another MCU in your enviroment, so you will use one MCU for scheduling with reservation and another for adhoc conferences.

I hope this help.

Paulo Souza

Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

[emresumengen]

Hi Paulo,

Thanks for taking your time to explain the reasoning behind this limitation.

But, although your explanation has a point, it definitely is not the best solution out there.

Let us discuss the situation further on example... Let's assume we have the 4510 with 20 HD ports. When we create a meeting (let's call it MEETING-A) with 15 participants and port reservation, we still can create other meetings (let's call a second meeting, MEETING-FREE) on the MCU without setting port reservation (ie. putting 0 to reserved port counts).

Now, the MCU would act as a 5 port device for MEETING-FREE, until MEETING-A ends. It is clever enough for that.

(Otherwise, even the auto-attendants can create a problem, not only adhoc conferences. So, disabling adhoc is not a solution.)

The same could apply to adhoc as well. If implemented that way, the MCU could host port-reserved meetings and still be able to create adhoc conferences. I still see no valid technical reason behind this limitation.

But, I also understand that, having a better solution topology in thought was and will never be a reason for Cisco to implement it that way, unfortunately.

I was aiming to confirm this limitation and with the possible reason behind it, and thank you for sharing your insight on the issue. I guess we'll have to think about a workaround (like getting another MCU for the client, for port-reserved meetings) for this issue.

Emre

Sent from Cisco Technical Support iPad App

[Paulo Souza]

emresumengen escreveu:
Hi Paulo,

Thanks for taking your time to explain the reasoning behind this limitation.

But, although your explanation has a point, it definitely is not the best solution out there.

Let us discuss the situation further on example... Let's assume we have the 4510 with 20 HD ports. When we create a meeting (let's call it MEETING-A) with 15 participants and port reservation, we still can create other meetings (let's call a second meeting, MEETING-FREE) on the MCU without setting port reservation (ie. putting 0 to reserved port counts).

Now, the MCU would act as a 5 port device for MEETING-FREE, until MEETING-A ends. It is clever enough for that.

(Otherwise, even the auto-attendants can create a problem, not only adhoc conferences. So, disabling adhoc is not a solution.)

The same could apply to adhoc as well. If implemented that way, the MCU could host port-reserved meetings and still be able to create adhoc conferences. I still see no valid technical reason behind this limitation.

Nice! But you forgot an important point. You are saying that MCU should act as a 5 port device while the conference MEETING-A is going on. That is fine. Following your reservation logic, MCU should not reserve 15 ports until the conference get started, and should set the 15 ports free when the conference ends, so that you can use remaining ports for adhoc. However, what happens if another users with adhoc use ports of the MCU before MEETING-A starts? For example, UserA makes an adhoc multipoint conference and invite 6 participants to it before MEETING-A starts, then, when the meeting starts, MCU won't have resource enough to connect the 15 scheduled participants (unless MCU disconnected the adhoc participants to host the scheduled meeting, what would be a stupid behavior).

Maybe you think, "Well Paulo, but I am aware that I have only 5 ports remaining in that day and I will instruct the users to do not use more than 5 ports because of this conference with 15 participants". Yeah! But do you realize that by doing this way you are manually controlling the resources of your MCU? So why using port reservation? Go ahead and manage your resource manually if you can have a good control over it.

I am not sure if you got my logic here, but I can say with great assurance, adhoc feature on MCU may totally break the reservation concept, bacause with adhoc enabled, you totally open situations where MCU cannot make sure that there will be ports available to host scheduled conferences with reservation, so you will have a "fake reservation" applied, which is not real reservation at all. That is the point!

For me, this logic of the MCU is simply brilliant. The engineers did a great job.   =)

Regards

Paulo Souza

Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

[emresumengen]

Well, the correct behavior would be to allocate those ports as soon as the conference is scheduled/reserved, not only when the conference is running.

The other way around would not be appropriate.

Anyways, I can't for the life of me agree that this is the brilliant way, but I (should) agree that this is the way I (and our client) should cope with.

Sent from Cisco Technical Support iPhone App

[emresumengen]

And, even if this was the best way, it's still missing the point then. I guess you've missed my point... Adhoc is not the only way to break things. You can still create rooms which don't have reserved ports, and that basically means any number of participants may join, up to available maximum.

If the mcu doesn't already reserve ports as soon as the meeting is configured, participants to other meetings can flood the mcu before your reservation-meeting starts.

Same result, without Adhoc. So, what I'm saying is, even if this limitation may have an aim associated with it, it's still missing the result...

Thus, absurd IMO.

Sent from Cisco Technical Support iPhone App

[Paulo Souza]

emresumengen wrote:
Well, the correct behavior would be to allocate those ports as soon as the conference is scheduled/reserved, not only when the conference is running.

Are you saying that MCU should reserve the ports from the moment that the conferences are scheduled? That makes no sense. What happens if you schedule a conference do next week, for example? Should MCU keep those ports reserved one whole week simply to make sure that there will be ports available? What about tomorrow? I will have less ports available in my MCU because of a conference that won't even start tomorrow!?

emresumengen wrote:
And, even if this was the best way, it's still missing the point then. I guess you've missed my point... Adhoc is not the only way to break things. You can still create rooms which don't have reserved ports, and that basically means any number of participants may join, up to available maximum.

If the mcu doesn't already reserve ports as soon as the meeting is configured, participants to other meetings can flood the mcu before your reservation-meeting starts.

Same result, without Adhoc. So, what I'm saying is, even if this limitation may have an aim associated with it, it's still missing the result...

Wel, I guess I got your point very well. In fact, you are misunderstanding how media port reservation feature of MCU works. Let's take as example what you pointed out above, you are saying that it is possible to break reserved ports. I will explain you why I said that MCU uses a briliant behavior.  =)

Let's say I have a MCU 4510 with 20 ports and I have scheduled two conference to tomorning with reservation enabled:

MEETING A

Start time: 10:00h

End Time: 13:00h

Video port reserved: 5

MEETING B

Start time: 12:00h

End Time: 18:00h

Video port reserved: 15

Well, based upon what you described, you are saying that, more than 5 participants would be able to join MEETING A, like 8 participants for example, then, when MEETING B starts, there will not be ports enough to join the 15 participants. This is what you mean, right? You missed an important point, the parameter "video port reserved" also is used as "maximum video ports" value. Therefore, if you reserved 5 port for MEETING  A, only 5 endpoints can join the conference.

In addition, to make sure that ports reserved are indeed reserved and guaranteed, MCU applies some other restrictions:

• No adhoc conference creation: You can't use multiway
• Auto attendant meeting creation: This is not allowed as well. Also, when configuring new or existing auto attendants via the web interface, the Creation of new conferences parameter will not be available.
• Auto attendant connection: The auto attendant connection effectively "borrows" a media port from those not currently in use. However, this borrowed media port has a lower priority than a media port used by a conference participant, and if the auto attendant connection "borrows" the last remaining media port, then that connection will be dropped if another endpoint connects directly to a conference and requires a reserved media port.

Do you see my point now? That's why in my poor opinion, I really think this behavior of MCU is simply brilliant, because this is indeed the only way to honor media reserved ports.

You can get further information on reservation on the admin guide, starting on page 58:

http://www.cisco.com/en/US/docs/telepresence/infrastructure/mcu/admin_guide/Cisco_TelePresence_MCU_4-4_Product_administration_guide.pdf

If this "reservation behavior" doesn't achieve your need, I suggest you to disable reservation and control your resource manually, or consider the possibility of having a second MCU.

I hope this clarify.

Regards

Paulo Souza

Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

[emresumengen]

Ok, you are right about the fact that this implementation is effective in blocking conference resource clashing (my mistake in the previous post), but it really would be much better for us if the software handled adhoc conferences just like auto-attendant "borrowed" ports, rather than disabling them all.

[Paulo Souza]

Your suggestion would be a possibility, of course. However, when MCU borrows ports for auto attendant connection, there is an important point to consider: The scheduled conferences will have priority over the participants connected to auto attendant, that means, if conference starts and there is no video ports available, the endpoint from the auto attendant will be disconnected without any advise, because MCU needs to take the port back to host the scheduled conference.

So, try to imagine MCU disconnecting adhoc participants because the ports being used are borrowed from reserved conferences and now MCU needs to take the ports back to host the scheduled conferences. That would be bad in my opinion, because Borrowed ports can be retrieved anytime without any advise, so that the participants would have to be disconnected from adhoc conferences suddenly.

But of course, it would be a possibility so far.

Paulo Souza

Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

[Oleksandr Yurchenko]

Hi emresumengen

In some cases TMS can help to resolve your issue.

"Option to limit MCU conference size in Cisco TMS

Cisco TMS can now (14.2) limit conference size on Cisco TelePresence MCUs and TelePresence Servers even if

they are not in Port Reservation mode. A new setting has been added in Systems > Navigator > select an

MCU > Extended Settings > Limit Ports to Number of Scheduled Participants. If port reservation mode

is enabled for this MCU, this setting will be set to Yes and grayed out. If port reservation is not enabled for the

MCU, you can use this setting to choose whether you want to limit the number of ports used to the number of

scheduled participants."

br Oleksandr

[emresumengen]

Hi Oleksandr,

Thanks for the info... This, in effect, puts a limit to scheduled conferences on the MCU, so that only pre-configured participants may join, is that right? (Haven't had the chance to review the admin guide yet.)

Multiway will still be a problem I guess, but its good to know. We are working with the customer on additional MCUs and conductor. This may also be a good time to add TMS to the list as well.

Sent from Cisco Technical Support iPad App

[azeem.haider]

Hi Paulo,

I have added MCU as a Media Resource in CUCM. I am using MCU 5310.

I want to use Ad hoc Video conference on Cisco Jabber Clients.

But when i put 3 jabber Clients in a Conference, It automatically becomes an Audio Conference instead of Video. Below is the Error i got in MCU Logs..

  537 2014/08/31 16:08:25.641 API                                  Info      conference "002035010001" created by "admin"
538 2014/08/31 16:08:25.641 CONFERENCE              Info      starting up scheduled conference "002035010001"
      539 2014/08/31 16:08:25.645 CONFERENCE        Info      activating H.239 channel for "002035010001"
      540 2014/08/31 16:08:25.951 API                               Info      conference "002035010001" destroyed by "admin"
      541 2014/08/31 16:08:25.952 CONFERENCE         Info      deactivated H.239 channel for "002035010001"
      542 2014/08/31 16:08:25.953 CONFERENCE         Info      destroyed conference "002035010001"

I have 5 port License on MCU..

Can you Please Help.. what is the Issue.How to Solve it

Do i have to get more Licenses on MCU...?

[Martin Koch]

Yes, I agree with Paulo. There are always features which should or shall not be combined.

Maybe looking into the Conductor can be a solution.

Please remember to rate helpful responses and identify helpful or correct answers.

[emresumengen]

Hi Martin,

We can easily overcome this situation with a dedicated MCU for reserved and non-reserved meeting, conductor would be overkill at least for now.

But this, even without conductor, is not the best utilization of resources. Unfortunately, I guess, it is the only possible solution at this time.

Thanks,
Emre

[Paulo Souza]

Hi,

Regarding Conductor, Martin has placed a good sugestion. I am aware that you can overcome your issue by putting another MCU. However, with Conductor, you can take more advantage of your resources usage.

For example, if you put a second MCU without Conductor, you will probably use one for scheduling with port reservation and another for Adhoc. But you can have situations where the resources won't be avalied well. For example, let's say your "Adhoc MCU" has not ports available and you need more ports to host a conference, and your "scheduling MCU" does have many ports available in the moment, so why not use its ports to cover this lack? With Conductor it is possible and may happen dinamically, without any manual intervention of the administrators.

With Conductor you will be able to use one MCU for scheduling purposes and keep another for Adhoc, and use both MCUs as fallback when you need more ports or when one MCU goes down, considering that you also have automatic MCU cascade feature to expand conference capacity.

Conductor is a "plus" and may be really helpfull in many environments.

Regards

Paulo Souza

Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".