We have definitely had Conferencing working in the past.  This is a recent change.

The option to start conferencing again is grayed out.  Is there a CLI method to do this or should I open a TAC case?

Thanks,

Seth

Would you mind posting your config?  Be sure to remove passwords.

There are CLI ways to turn it on, but I am curious as to what the current config is and why it will not allow more conferencing.

Even though its greyed out, can you try clicking the enable button.   I found that it does turn on, even though it presents as greyed out.

Hi Steve,

Just tried your suggestion, but no luck.  The item is grayed out, and it will not allow be to check the box in any way.  In the past month or so, I have done the following.  Perhaps one of these could have resulted in the problem that we are seeing now?

1. Added a SIP trunk and configured the UC520 to use G.729 for all SIP calls.

2. Enabled SNR for specific employees employing the SIP trunk as a test of the functionality

3. Disabled SNR by unchecking the box in CCA.

All configuration, other than the configuration for G.729, was done via CCA or the CUE web interface.  There are a few commands that were issued in the CLI for teh SIP trunking form the SIP Wiki.  Here is my config w/o passwords and IPs.

Thanks,

Seth

Did you create the transcoding profiles, or did someone else do it?  I see the transcoding profiles in there, but no conferencing.

Also, when conferencing was working, are you sure hardware conferencing was configured?  Can you conference by calling only internally?  Forcing the SIP trunk to be G729 probably is what broke this.

Hi Steven,

I created the transcoding profiles by follow the SIP Trunk Wiki that is published elsewhere on this website.

Originally, hardware conferencing was configured and working.  Now here's the strange part.  Yesterday when I originally posted this, and Sunday night when I had an internal conference call with a couple of business partners, conferencing would not work.  We were all remote - all working on the VPN, and all on CIPCs.  I tested the same thing internally from my desk phone with the same result - conferencing was not working.

At your prompt, Steven, I went ahead and checked internal conferencing between three extensions a few minutes ago.  Today it worked.

Then I tried two extensions and a PSTN line (dial 9).  Also worked.

Then I tried one extension and two PSTN lines (dialed 9 for each).  Worked.

Then I tried two extensions and one SIP line (dial 8).  Worked.

Then I tried one extension, one SIP line, and one PSTN line.  Also worked.

Could it be something in our VPN config?  I'm going to head offsite to run a few errands in a couple of hours and will try it again remotely, but if you have seen anything like this or understand from my description what might be happening, please let me know.

Thanks,

Seth

On the CIPC, anyone have the optimize for low bandwidth checked?  I believe that forces G729.  On the hardware phones, I am know that the phone can bridge a connection with its DSP's to have a 3 person conference.  I doubt you can have a 4 person conference right now.  I don't remember if CIPC can do that or not. 

We do have "optimized for low bandwidth" checked on our CIPCs.  I forgot to mention that the tests mentioned above were completed both using my CIPC and my desk phone.  Both worked flawlessly today.

I got to be honest.  I'm scratching my head on this one.  I'll try to VPN when I get out of the office today.

Did you try starting the conference from the CIPC phones?  I think there might be an issue with that.  I don't believe it can start a conference without the hardware conferencing enabled.

Yeah, I sure did, and it seems to be working perfectly right now from my CIPC.

I actually did it exactly as I did when I was working from home on Sunday night.  The only difference that I can see is that I'm onsite and not using the VPN.  When I was having trouble this past weekend, I was initiating the conference from my CIPC and calling other CIPCs or cell phones (I tried it several ways).  I would initiate in the normal way - call one number and get the party on the line, push the conference button, call the second number and get that part on the line, then push the conference button again.  At the time "Cannot complete conference" or some message like it would come up on the CIPC screen.  Now, the conference works.

Another strange thing, however, is that we no longer hear the audible tones telling you that you are in a conference.  All three parties are joined into the conference, but there are no tones announcing this any longer.

I have not tried four parties yet from the CIPC or desk phone.  Let me know if you'd like me to try that.

Seth

Okay, so this keeps getting more interesting.  Today, a coworker mentioned that he couldn't get conferencing to work properly.  Looks like the problem that I was seeing earlier has reappeared.  I'm on the road and doing demos.  I configured a UC540 in the same way that our UC520 is configured at work - forcing the G.729 codec to maximize bandwidth on low bandwidth circuits.  Conferencing is officially broken on this site also.  Our clientele really needs to operate on the smallest codecs possible to conserve bandwidth while still maintaining all functionality.  I have posted my test config and would really appreciate any insight that anybody might have into this problem.  The following actions were completed (mostly using CLI) on the UC540 where this configuration comes from:

1. SIP trunking setup (CCA)

2. Incoming dial plan changed to point specific traffic to specific users/groups (CCA)

3. UC540 configured to reuse port 5060 for all incoming and outgoing SIP requests (CLI)

4. "no voice source-group CCA_SIP_SOURCE_GROUP" issued to solve inbound SIP call bug

5. G.729 is setup as preference 1 for UC540, no codec setup as preference 2

6. Configured transcoder for G.729 calls so that VM and AA work properly

Another idea that I have had would be to force only the SIP trunks to use G.729.  This might unbreak my conferencing, but I'm not sure what I would need to do to force only the SIP trunks to use G.729.  Any thoughts?

Thanks in advance,

Seth

Here is the config of the new test UC540

Looks like you are missing something in your config.

sccp ccm group 1

associate ccm 1 priority 1

associate profile 2 register mtp00260b358742

associate profile 1 register                <------ missing line

hi Steven,

Thanks for the reply.  I did locate that in my config.  So would I issue the command:

associate profile 1 register mtp00260b358742

or

associate profile 1 register conference

Thanks in advance,

Seth