Unity Connection Transfer to Meet Me after recording name

[joeharb]

We are utilizing Connection to record users name before being transferred into the meetme.  This seems to function fine if the users dial in one at a time.  If we have several users trying to join the meeting @ the same time, the user that dials in last gets a message that the Call Handler's line is busy and then is asked to hold.  The Unity Connection server has plenty of open ports, is there a limitation to the number of outbound calls that system can place?  All the ports are in the same outgoing port group.

Thanks,

Joe 

[joeharb]

Still having issues with this...not sure why Connection wouldn't be able to transfer the call....Anyone have any suggestions on where to to look for the root cause of the caller being placed on Hold by Connection?  If the calls come in slowly everything works fine but if more than 2 calls are being transfered into the MeetMe Unity connection doesn't allow the call to be placed.  The caller is put on hold and has to wait for Connection to try the call again.  Is there a setting that I could have missed that would prevent Connection from transfering more than one call @ a time?

Thanks,

Joe

[lr.moore]

Have you looked at the busy trigger setting of the line appearance of the phone that initiated the Meetme? It is 2 by default. That phone will have to put the conference on hold to answer the greeting, and the next caller will get busy trigger. Increase Max # of calls and Busy trigger on the line appearance.

[joeharb]

Thanks for the the response, I havent notice that the initiator of the meetme has to do anything after they establish the meet me session.  From what I expected this would be no different from the person initiating the meeting. A normal meetme, if reachable from a phone has no other dependency on that phone, is this not correct. 

Thanks,

Joe

[lr.moore]

Someone has to answer the call from Connection to accept the caller into the conference, so it only makes sense that is another call on the meetme initatiators phone. If busy trigger is set to 2, then the first transfer is accepted, and calls that come in slowly work fine because there is time between them to complete the accept on each one without hitting 2.  It's a simple test to just increase the busy trigger and see if that fixes your problem.

[joeharb]

I am not sure i understand the logic, lets say 5 people dial into a normal meetme at the same time, does them being allowed into the conference have anything to do with the initiator's phone?  Unity Connection is simply transferring the call to the meet me number, which is a conference held by the CCM, at no time are we actually calling/dialing the ext of the initator.  All documents I have found for utilizing Connection to announce the Caller into the meetme, have no reference to adjusting the initiators busy trigger. 

I do appreciate the responses, but if it is a limitation of the person starting the conference then I would expect we would have received busy signals for every meetme we have put in place.  We allow 15 users in a meetme and all phones are set the standard 4 2 trigger.

From everything I understand, and I understand I could be wrong, but once the meetme is established, that call is handled by CCM and has no bearing on the user that started the meetme.

I hope that someone can respond to verify or correct me so I can understand how the meetme actually functions.

Joe

[Jaime Valencia]

You're right, what lr.moore suggest is wrong, as you correctly point, CUC is transferring to the meet-me DN, not to the initiator's DN, you'll get the prompts to grant/deny access while you're already in the meet-me. The busy trigger/maximum number of calls from any phone that is in the meet-me, have no bearing on what you're seeing with that call flow.

What lr.moore suggests would only make sense if the call flow was from CUC to the initiator's DN, and then you transfer them to the meet-me DN. But that's not the call flow we're talking about.

You should be able to transfer as many calls as outbound ports configured in CUC, I suggest you use the port status monitor to see the reason for the transfer failure.