VCS- C cluster and VCS-E Cluster with Movi 4.6 register and call interruption

[rasimyigit]

Hi all,

We have VCS- C cluster and VCS-E Cluster with Movi 4.6 register and call interruptions. The point is, if the call or registering comes from the Internet . We have the sip proxied model vcse--> vcs-c registering. The strange point is, if we run non clustering mode with only 1 vcs- c, then the call works fine or hold more then 1 minute. We have also findme . The internal call from locally registered (VCSc) works also fine) the case pops up if the VCS-c cluster active and the movi was registered on the traversal subzone of the VCS-c
The VCS versions are x.7.2.2 and tms 14.2.2
Thx for your feedback

Sent from Cisco Technical Support iPhone App

[Nick Halbert-Lillyman]

I'm running single VCS-E to 2 x clustered VCS-C OK.

Sounds like there could be an issue between one VCS-C and one VCS-E....

I'd try shutting down certain VCS's to confirm the following:

VCS-E #1 + VCS-C #1 works

VCS-E #2 + VCS-C #1 works

And so on, until you've tested every possible combination of VCS-E to VCS-C.  Does each node in the cluster use the same firewall, or are they working behind different firewalls?  If they are on different firewalls, try monitoring both firewall's, filtering for the IP addresses of all VCS devices.  Make a call and see if you get any "Deny" messages in the firewall logs.

[rasimyigit]

The strange point is that the call about the jabbertablet is stable. About the movi 4.6 we lose the registration . Try I with movi 4.4 or 4.5 the call or registration interrupt much faster.

Sent from Cisco Technical Support iPhone App

[Paulo Souza · Accepted solution]

Hi Friend,

This problem you are facing is a known limitation of Jabber for Telepresence. It happens when the device registration is proxied to the VCS Control, where the VCS Controls are clusters. Probably this is happening:

- Jabber client registers through the Expressway to a Control that in the Expressway traversal zone.

- The registration requires authentication

- When the client re-registers each minute (normal SIP (re)registration process), the registration request is sent to one of the other Controls in the cluster.

- The client then ends the current registration and re-authenticates to the other Control

- The client (Jabber) will tear down the active call when it need to re-authenticate the registration

This issue is resolved in the current version for Jabber for iPad. The current version of Jabber for TelePresence still has this issue. Defect : CSCud17952

Another user reported the same problem. See this topic:

https://supportforums.cisco.com/message/3967325#3967325

Zachary Colton provided the answer. I simply copied his explanation and pasted it here.

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

[Paulo Souza]

If you can, get a IPad and try to test the problem using Jabber for IPad, if the problem does not occur with IPad, then you can come to conclusion that this strange behavior really refers to the bug I mentioned above.

Regards,

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

[rasimyigit]

Hi Paolo,

the point is, that a other customer have the same structure withoun any DNS clusternames onyl IP Adresses.

He has no problems interruptions.

That is bad? CHange the Registration Model from Proxied VCS-C registrations to Registation to the VCS-E Cluster or it is not depend from the DNSSettings/Firewall?

[Paulo Souza]

Hi,

If you read the description I posted above, you will realize that the problem occurs when the registration is proxied to VCSc in cluster, because VCSc requires authentication on the zone where by provisioning requests are received, when Jabber is trying to re-authenticate, it disconnects the call to re-register to the other peer in the cluster, then the bug occurs.

So, if you register your jabber directly to VCSe cluster and there is no device authentication enable on VCSe cluster, theorically it is suposed to work, because the problem only occurs with cluster of VCSs with authentication enable.

However, The Device Provisioning Guide says you have to set "check credential" in all the zones where by provisioning requests are received, that included the zone on VCSe if you are registering your jabber to it. I have tried to register jabber to VCSe without enabling device authentication, it worked. However, you must to be aware that device authentication is very important for safety reasons.

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

[rasimyigit]

HI Paulo,

of course is the auhentication very important. We must leave everything to check credentials. These are the specifications. we would leave the movis on the VCSE, then we must do everything " do not check credednetials" That is not so nice.

When do you expect the BUG fix?

[Paulo Souza]

rWhen do you expect the BUG fix?

Unfortunately, I don't know when this bug is going to be fixed! Probably soon, because it was fixed in Jabber for IPad.

Let me take the oportunity to add a mark about proxied registration through VCSe to VCSc. Read this:

Problem with proxied registration

It impacts your license consumption on VCSe! For example: You have two jabber clients register to VCSc from internet through proxied registration in VCSe. When these jabber clients call each other, the call comes from VCSe, then it goes to VCS Control and then comes back to VCSe. In this scenario, one single call takes two traversall call licenses on VCSe! Two! Because it passes two times in VCSe!

I tested it some weeks ago. I was using proxied registration to VCS Control through VCS Expressway because I had many call policies created on VCS Control and I didn't want to have to create the same policies on VCSe (it's hard to manage). Then I moved all devices to register to VCS Control. But when I realized that behavior related to license consumption, I moved all back to VCSe.

Do the test and take your own conclusion.

Regards

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

[Paulo Souza]

we would leave the movis on the VCSE, then we must do everything " do not check credednetials" That is not so nice.

If you register the clients directly to VCSe, if you set all the zones on VCSe to "check credentials", you are going to have another problem . Read this:

Problem with registration to VCSe with athentication enable

If you set check credentials in all the zones on VCSe, VCSe will challenge the client to authenticate regardless of the provisioning authentication on VCSc/TMS. We will have two authentication:

- Jabber clients send provisioning requests to VCSe; VCSe sends it to VCSc

- VCSc requires authentication in order to provide provisioning information

- The jabber client sends the authentication and sucessfull receives provisioning data

- Now jabber clients will try to register to VCSe using the configuration received from provisioning

- When the jabber tryies to regsiter to VCSe, VCSe requires authentication again (because you set "check credential"), then VCSe will challenge the client for authentication. This will be a problem, because VCSe will look on its local database to verify the credential, then authentication will fail and the client will fail to register!

I know that this behavior of double authentication is a "no smart" behavior of the VCS. The point is: Although VCSc marks the SIP messages from jabber client as "authenticated" after provisioning occurs, the REGISTER message the comes from the client to VCSe is not marked as "authenticated", then VCSe tryies to authenticate the client once again using its local database as source.

How do you resolve that problem? Two options:

1. Create the users twice; create them on VCSe and TMS (that is horrible!)
2. Enable Device Provisioning on VCSe. This will allow TMS to replicate users to VCSe (the security team won't like it!). VCSe from X7 has support to authenticate any client using its local database and provisioning database received from TMS. By doing this way, we just have to create the users on TMS, then the "double register" behavior won't be a problem and you will have all devices from internet registered to VCSe with authentication.

But be aware that, if you have VCSe cluster with authentication enable and register jabber to it, you will probably have the same problem you are having now, unexpected disconnection, because of the bug we are talking about.

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

[Paulo Souza]

Well, I gave you two problems regarding proxied registration and registration directly to VCSe. Do the tests and choose what is better for you.

Regards,

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

[rasimyigit]

i tested the device provisioning on the VCS-E that is the better way but , that dont fix my problem with the Cluster :-)

I think the best way to to ist the proxied registration to the vcs. I have not double work and all check credntials zone is more important on the vcs-c.I will look.

Its depend from some cases

THX

[Paulo Souza]

Hi,

In general, proxied registration is good option, but pay atention to the license consumption problem I mentioned above. It may be a problem if you have many jabbers from internet making point to point call to each other.

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

[rasimyigit]

The Important point is the bug in the movi client . How did the others to work with the VCS-c cluster and movi. Defiantly with this bug in the movi client, you can't use it

Sent from Cisco Technical Support iPhone App

[Nick Halbert-Lillyman]

As a workaround, would it be possible to block one of the VCS-C's off from the VCS-E at the firewall so that Movi can only register to one of them but maintain clustering functionality for internal endpoints?

We are getting ready to deploy proxied Movi registrations, but we only have 1 x VCS-E for proxying registrations anyway whereas our secondary VCS-C is in another data centre, so we wouldn't lose out too much if we could only register to one VCS-C as long as it fixed the issue.  Would calls still work to proxied Movi clients even if they came via the blocked off VCS-C?