Multiway & CUCM

[Justin Ferello]

Hey all, here is what I am testing with.

CUCM v9.1

VCS-C x8.1.1

Multiway configured and working fine on VCS side with Conductor x2.3 and TelePresence servers on v4.0

SIP trunk between CUCM & VCS-C working great, video/audio in both directions

Here is the problem, I am trying to get (2) 7962 phones into a Multiway with an SX20 on the VCSC.

From the SX20, which is registered on the VCS, I call phone A.  Phone picks up fine and we get audio in both directions.  I then make a second call from SX20 to phone B and I get a good call.  I then press the merge button and I see the TelePresence server screen that says I am the only participant for a few seconds and then it hangs up and says merge failed.

I am then back to my SX20 on one audio call and the other is on hold.

What am I missing here?  Right now the 7962s are running SCCP, do they need to be running SIP to work?

Thanks,

Justin

[Nick Halbert-Lillyman]

Justin,

I had almost the exact same setup and had a similar issue, but I was using CUCM 8.6/VCS 7.2.

A couple of things that I had to do to get it working (and yes it's working with SCCP phones):

First of all, make sure your phones can manually dial into the multiway alias you are "merging" the call into. The guide says to use SIP domain based multiway alias's, but I used a numeric alias instead, then put a tansform on VCS e.g. change 1234 to 1234@mydomain.  This way I can just use standard CUCM route patterns, which was a requirement for me as I can't point a SIP route pattern to a route group (this may be changed in CUCM 9+).

In addition (and I haven't seen this documented anywhere) for some reason when the phone recieves the SIP refer to dial my multiway alias, it doesn't seem to respect calling search spaces or partitions.  The only way I could get it to work was if I had a route pattern with no partition at all, even though the phones themselves could manually dial into the multiway alias just fine.

Lastly, there's a number of settings you need to configure on the VCS neighbour zone and CUCM SIP trunk profiles - these are in the CUCM to VCS integration guide - there's a multiway specific section of that guide that should outline what you need.

[Justin Ferello]

Nick,

Thanks for the information.  The documentation for Multiway & CUCM is lame.  I was using multiway@domain.com for my MW address, there is nothing that states that a phone cannot dial a URI on the backend, I know I cannot dial a URI from the keypad, obviously :)

Anyway, I changed the MW address to a number now and have calls passing, however they fail to connect to the TelePresence server.

The only error I see is for both phones on the TelePresence server, they generate this error:
Closing call due to failed reINVITE

Any idea what would cause this?

Thanks,
Justin

[Nick Halbert-Lillyman]

Have you got Active Control enabled in the conference template?  When I had it enabled, the calls from CUCM failed.

I also had some better luck when I had "media termination point required" on the SIP trunk.

[Justin Ferello]

Nick,

I disabled Active Control on the conference template, still failed.  Then I enabled "media termination point required" on the CUCM trunk and it still failed.  Same message still.

Thanks,
Justin

[Nick Halbert-Lillyman]

Justin,

I'm running out of ideas... the other thing to try is disabling resource optimisation as well as multi-screen endpoints on the template (which sort of defeats the purpose of Conductor :P).  I eventually got these settings working but they did cause me some issues initially.  Strangely enough, I actually had some more success when I bounced the call off another VCS control before sending it to Conductor.

Can you manually dial into the alias? This could at least help you narrow it down to something on TP server/conductor or if it's an issue with the SIP invite/

I agree about the multiway documentation - doesn't seem like much attention is paid to mixed CUCM/VCS environments (which in my experience is pretty common) - they expect you to be fully VCS or CUCM when using Conductor.

 

[Justin Ferello]

Nick,

Thank you so much for the help so far.

I am able to dial into the conductor conference from any phone manually, with or without any of those settings on or off, like multi-screen, optimize etc.

I guess I need to turn this into a service request since Cisco is not responding at all :(

Thanks for the help Nick

[Nick Halbert-Lillyman]

No worries Justin, good luck.

One last thing to try (if you haven't already) is to upgrade TP server to the latest version of 4.0 released a couple of weeks ago - this fixed a different multiway related issue for me, even though there was nothing in the release notes about it (specifically it was voice switching sensitivity).

[Justin Ferello]

Nick,

I am going to upgrade my TSes next and see if that helps, will let you know.

Thanks,
Justin

EDIT:
Just upgraded the TSes to 4.0(2.8) and still get the same issue :(

Thanks,
Justin

[petark]

Hi, 

Did you solve this problem?

Regards,

Petar

[Nick Halbert-Lillyman]

I ended up experiencing something similar - it was to do with the "IX" protocol.  Either turn if off on Conductor, or apply IX filter on your VCS neighbour zone custom parameters.

[Nick Halbert-Lillyman]

Justin - I was reading the VCS 8.2.1 release notes and noticed this bug fix:

CSCup29484
Symptoms: For re-INVITE process, VCS B2BUA reuse Max-Forwards value that it stored at the call establishment, therefore may see Max-Forward parameter reduced to an unexpected level.
Conditions: Re-INVITE and call go through VCS B2BUA application.
Workaround: None.

I know your TP server was reporting a failed re-INVITE so maybe a VCS upgrade is worth trying...

[Justin Ferello]

Nick,

Nice catch on this, did not see that.  I just upgraded all the VCSes and still having the same issue though :(

Thanks,
Justin