Conductor: Conference template setting causes a warning

Hello all,

In the company I work for we are starting to use the TelePresence Conductor.

We use a custom build application for managing the conductor and dialling participants into virtual meetingrooms.

Also it still should be possible for video endpoints to dial into the rooms themself.

In the conference template there is a setting called Scheduled conference.

When Scheduled conference is set to Yes video participants will rejected unless a room is created.

We have set this value to No as it always should be possible to dial the room.

Now the Conductor generates warnings when the room gets created by api:

vcamscond01 conferencefactory.controller: Level="WARNING" Event="An API request was made to create a conference using a non-scheduled conference template; the factory.conferencecreate request may fail if the conference has already started." Conference_template_name="<conference name>" UTCTime="2014-03-16 17:12:07,523"

These warnings are actually polluting our monitoring reports.

Basically the setting "Scheduled conference" means if the room is allowed to be created by dialing into it.

That seems to be similar to the setting "Allow conference to be created" in a Conference alias.

Why is there a need of this redundancy in settings?

Why does it need to generate the warning stated above?

Hi Raymond,

  CAn you please check in B2BUA and make sure you have nothing left in Settings-SIP-SIP Call Settings-SIP proxy address.

Ref- Telepresence Conductor auto dial problem

Thanks and Regards,

Geevarghese

Hallo Geevarghese,

Thank you for your answer.

The Conductor is not deployed in B2BUA but deployed with a VCS.

In the current configuration there are no SIP settings possible on the Conductor as a device. The only SIP setting I could find is the SIP port for a conference bridge.

Hi Raymond,

  I would request you to refer the Cisco TelePresence Conductor XC2.2 Release Notes for related information.

Thanks and Regards,

Geevarghese

Raymond Ng wrote:

 

Basically the setting "Scheduled conference" means if the room is allowed to be created by dialing into it.

That seems to be similar to the setting "Allow conference to be created" in a Conference alias.

 

Why is there a need of this redundancy in settings?

Hello Raymond -

The way I see it is, the settings are there if you'd want to limit the use of a specific alias you can, and limit the use of a specific template.  For example, an alias could be meant for scheduling via TMS in this example only, one wouldn't want anyone to connect using that alias into a conference early.  If you limit the use of a template, then one could prevent someone from starting a conference, ie: a conference that might be configured to dial out to many other participants or recording servers for example via Conductor's auto dialed participants feature.  These two features can be used separately or together to create combinations of what is allowed or not allowed via an alias or template.

Hope this helps.

Patrick

Hello Patrick,

In your explanation a room is only used in 2 ways.

People dial in or a conference is scheduled by a scheduling application like TMS.

This does not fit in the business case of VisionsConnected.

The rooms we use can be used for both ways.

A room can be dialled into manually and it can be scheduled by a third party application we develop our self.

Why do we do this?

We sell fixed meetingrooms. So when a customer buys our service we sell besides vcs registrations, installation and service also x virtual rooms. They can use those rooms however they want. So there is no limitation on using it for just a quick meeting or scheduling a meeting using the application we call MeetingSuite. Yes conflicting use of the room can occur, but that is also the business case by selling them more virtual rooms.

So basically we use the virtual rooms just like physical rooms. The rooms are not locked and anyone can go and sit in such a room. If a scheduled meeting will start, those that does not belong to the meeting just have to leave the room. If they don't want to leave they can be kicked out with a little 'force'.

So a warning is generate every time a room is created by api while that is exactly what we want.