cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1719
Views
9
Helpful
5
Replies

Movi Presence with VCS X6.1

Andrew Vasel
Level 1
Level 1

We recently upgraded our VCS to X6.1.

With Movi 4.1, when logging in, the presence defaults to 'appear offline' when logging in no matter what 'sign me in as' is set to. I can change the presence status without getting any error messages, but the updated presence is not picking up when searching for that user's presence from another Movi log-in. All zones and subzones are set to 'treat as authenticated'.

With Movi 4.2, none of the issues listed above are happening.

Any suggestions (besides upgrading our 1,500 users to 4.2)? Would the Subscription expiration time and Publication expiration time settings have any relevance?

5 Replies 5

Andrew Vasel
Level 1
Level 1

I did find (under advisement) in the release notes that the log-in presence issue is to be expected in Movi 4.1 and earlier.

"Note that if TMS Agent (rather than the Cisco VCS) challenges for authentication of provisioning data, the initial presence publication by Movi (if running Movi version 4.1 or earlier) will fail; to publish Movi presence, users must manually set their presence status after logging in."

I have, btw, escalated this up through TAC, and they are continuing to analyze the issue as the presence is occasionally publishing but mostly not.

Hehe, just was going to answer you, but after the login your message was already there,

self solving problems are always the best :-)

I am not sure how many VCSs you have. In general you should only have one (cluster counts as one) with

the "SIP SIMPLE Presence Server".  All can have an activated "SIP SIMPLE Presence User Agent".

Maybe it is dependent on some of your search rules or where the client is registered, ...

Did you also see the last answer here:

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

It might be worth reviewing your setup with your Cisco partner and check if there is something

which can be done regarding improving the authentication.

Btw. even if this does not seem to be the case here, if using new TMS / Movi versions its also worth checking that

you have uploaded the proper xml provisioning templates in place.

Please remember to rate helpful responses and identify

Hi Martin,

Thanks for the response. In this case, we have 3 VCS's (1 that lives in a completely independent CAT environment, and 2 production VCS controls that are for the time being independent of each other - 1 is predominantly used, and the other is not really used as they will be clustered soon). Each has SIMPLE presence server and presence user agent turned on although the presentity of the predominant prod VCS is only used by Movi users. That being said, by manually provisioning Movi users to any of these VCS's, the same issue can be recreated... and incidentally enough by my Cisco partner as well with 4.1 and 4.2.

Just checked and I do have the 4.1 XML template uploaded to TMS.

Also, I did review the thread that you referenced, and it was not as directly applicable as hoped. That user was running into the issue of presence updates fail visually... I was able to actually recreate his issue when troubleshooting mine.

Having multiple VCS (I count a cluster as one) which share the same sip domain shall only have one SIP SIMPLE presence Server. If you have non overlapping sip domains it would be ok to have enabled on both, if at least

one domain is shared it would be not.

From the online help:

VCS neighbors: if you have a deployment with two or more VCSs  neighbored together, you are recommended to enable only one presence  server per domain. This will ensure a central source of information for  all presentities in your network.

How do you handle zones and authentication?

Do you also register movi users via a VCS-E (reg on vcs-e or proxied to vcs-c) or is it an internal only network?

Any updates from you tac case?

Please remember to rate helpful responses and identify

Martin

I understand what you are saying, but the 2 VCS's are not neighbored - they are completely independent as 1 is really just a back-up until we get them clustered.

Still trying to recreate the issue with Wireshark running as well generate a log file from the VCS.