Conductor create no conference on MCU

[thorstenn]

Deployment:

CUCM 10.5
MCU5310 4.5
Conductor XC3.0.2

I have a CUCM - Conductor - MCU deployment and i try to set up Rendezvous Conference. I can call from Endpoint to Conference bridge and here a busy and on Conductor i see the following:

2015-03-02T17:27:02+01:00    conferencefactory.controller: Level="INFO" Event="An incoming call request has been rejected because the conference is not present." Conference_name="991115.my.meeting.alias" Destination-alias="991115@10.10.10.106" Detail="Can not create a scheduled conference. Scheduler must create conference before it can be used" Requester_(VCS/Unified_CM/client)_address="10.10.10.6" Source_protocol="SIP" Unauthenticated_source_aliases="[3564@fqdn.of.cucm]" UTCTime="2015-03-02 16:27:02,99" 

On Call History i see

B2BUA rejected call on the Ingress with 486 Busy Here (Policy lookup response)

On MCU log and SIP Traces i see nothing incoming, but on the Conductor the Conference bridge Status is fine

MCU (No description available); TelePresence MCU Enabled, Active. Utilisation: 0%

Any idea what could be wrong? i thing from Conductor to MCU something is not good.

[Patrick Sparkman · Accepted solution]

Your question would be better placed in the TelePresence section of the forums where these devices are more actively discussed than in the Conferencing section you've posted in.  You can move your discussion by editing your post and changing the categories at the bottom.

It looks like you have either the conference alias or template set to not allow incoming calls to create the conference, meaning that only a scheduling application such as TMS can create the conferencing using the Conductor API.

Check the following in Conductor

• Conference templates > [template] > Scheduled conference
• Conference aliases > [alias] > Allow conference to be created

Also, sometimes people forget to have the encryption enabled on the MCU, and configured the MCU in Conductor to use port 5061.  That can also cause the conference to fail.

[thorstenn]

i followed the guide "Cisco Collaboration Meeting Rooms(CMR) Hybrid" and there the conference template setting "Scheduled conference" is set to "Yes". That was the problem. For testing if the conference is working i tried to dial from an endpoint directly. If i set to "No" its working fine.

Thx Patrick.

[filiberto.aguirre]

Hi thorsten,

You are right  !!!, I have spent many hours trying to set a conference.

after setting to NO I could.

regards

[mayank.sharma]

Just to share...

I got this message as well On Call History

"B2BUA rejected call on the Ingress with 486 Busy Here (Policy lookup response)"

Upon looking at Conductor Logs>Event Logs> All Events I spotted the follwing..

Level="WARNING" Event="A request arrived on an IP address that is not configured as either a rendezvous or ad hoc IP address."

Then I realized that I had missed out Creating a Location for Rendezvous tied to the Rendezvous IP address.

Once I added that. Then Rendezvous conference worked fine : )

[MBO46]

Hi Patrick,

When you speak about port 5061, between what server ? 

For now i use, 

         CUCM:5061 <>Conductor:5061

         Conductor <> MCU4205:5061

I try to use a MCU 4205 behind a conductor for adhoc video conference and i have an error on the MCU : "Internal server error 500"

And,

"Error     Remote peer does not possess a valid certificate for the domain X.X.X.X, terminating TLS connection"

Certificate on MCU is signed by my CA, Conductor and CallManager too

Could you help me ?

Best regards

Matthieu

[Patrick Sparkman]

Have you configured your CUCM and Conductor per the Conductor with Cisco Unified CM Deployment Guide (XC4.1)?

[MBO46]

Yes exaclty ! 

And i found some mistakes in this document... 

I use the FQDN of my Conductor(Adhoc IP) on the SIP trunk 

I add the FQDN of my conductor in the SIP security profile at the field X.509 subject name.

And it is not enought 

[MBO46]

I found !!

I see this error on the MCU logs (SIP)

 "Error     TLS Handshake failed to complete"

And i changed on the MCU the verification seetings (Network > SSL certificates)

Now it's OK !! :)