topic Re: Tandberg Movi Presence problem. in Collaboration Applications

Tandberg Movi Presence problem.

VC VEGA — Sun, 17 Mar 2019 21:12:05 GMT

Our client found their movi account show incorrect presence information in their Tandberg infrasturture.

For example,

In the movi account, a tandberg MXP-1700 unit shows offline, however, it shows idle in the TMS page.

But it works fine in presence status with other tandberg unit (non-presence-enable client).

As we known, all the presence state is relied on the VCS presence database.(even it is deployed with neighboring zone or expressway).

Can anyone suggest some idea for the above case?

Moreover, we would like ask any maximum number of presence in the VCS?

Thanks,

Ben

Tandberg Movi Presence problem.

awinter2 — Mon, 19 Dec 2011 14:52:35 GMT

Hi,

how many VCS's are involved in this scenario? Is the 1700 MXP system registered to the same VCS acting as the presence server?

Have you made sure to check that the presence server is only enabled on one of the VCS's, and that the presence user agent is enabled on all VCS's?

- Andreas

Tandberg Movi Presence problem.

Arbenjamin — Mon, 19 Dec 2011 16:14:18 GMT

hi Andreas,

I am belong to VE VEGA as well.

We have involved more than one VCS in this sceario, and the 1700 MXP is not register to the same VCS as presence server.

I am going to check that presence server configuration in the VCS's group, can we have more information in configuration?

Thank ,

Ben

Vega

Tandberg Movi Presence problem.

awinter2 — Mon, 19 Dec 2011 19:56:39 GMT

Hi Vega,

if more than one VCS is involved, what you have to make sure of is that the neighbor zone between these two VCS's is configured in such a way that when the VCS holding the registration for the MXP sends a presence PUBLISH towards the VCS hosting the presence server, that this PUBLISH is authenticated.

This can for example be done by configuring the neighbor zone on the VCS hosting the presence server with an authentication setting of 'Treat as authenticated', You should also make sure to set SIP Trust Mode to 'On' on this neigbor zone, so that any existing 'P-Asserted-Identity'-header present in the PUBLISH is preserved.

Please note that before making these changes, make sure to calculate what impact these will have to your video environment as a whole, since you might not want to tag all incoming traffic on this neigbhor zone as authenticated (For example provisioning requests from Movi.

As of X7.0.2, the Presence User Agent (PUA) on each VCS should inject a 'P-Asserted-Identity' header in the PUBLISH itself, meaning that the neighbor zone on the receiving side (VCS hosting presence server) does not need the zone authentication to be set to 'Treat as authenticated', although it must have SIP Trust mode set to 'On' in order for the PUBLISH to be accepted by the presence server.

Hope this helps,

Andreas

Tandberg Movi Presence problem.

mguguvcevski — Tue, 17 Jan 2012 17:41:26 GMT

I have to say that I have the same problem with the VCS Control and all endpoints on the system, Cisco Jabber Video for TP, E20 and C series endpoints.

I have all these registered on the VCS, the VCS is configured with Check Credentials on the Local Zone, and Threat as Authenticated on the Default Subzone due to provisioning.

VCS version is X7.0.2 and TMS 13.0. I am also planning to upgrade the TMS to 13.1.2

Jabber Video endpoints do not receive any presence information, although they are properly provisioned with presence@domain.com

The same goes for the E20 phones, where PresenceSubscribe is set to On, but no presence status is shown whatsoever.

The E20 is also on the newest sw version TE4.1

The Presence Server and User Agent are configured as On the VCS.

Tandberg Movi Presence problem.

Martin Koch — Tue, 17 Jan 2012 19:52:09 GMT

Hi Andreas! Is there a way to simply disable the authentication request just for the presence server, like you can do it for the provisioning server. If I see it right presence is handled in the main application and uses por 2664?

But I did not find a config option for it (ok als did not search for it till now).

Martin

Tandberg Movi Presence problem.

Martin Koch — Tue, 17 Jan 2012 20:29:38 GMT

Hi mguguvcevski!

To test I would suggest that you set all auth settings to "treat as authenticated".

(default subzone, local subzones which match and your default zone)

With this (and a single vcs) you should see the presence coming up. If not you

have to recheck your provisioning and your vcs presence config.

It depends on your deployment and authentication needs what the best setup would be.

Re: Tandberg Movi Presence problem.

mguguvcevski — Wed, 18 Jan 2012 09:51:36 GMT

Hello Martin,

All these settings were already tested before without any results. I configured the Default Subzone, Deafult Zone and Movi registrations Subzone with Threat as authenticated but Presence statuses are not showing up.

I also upgraded the TMS to 13.1.2, checked the provisioning and SIP SIMPLE Presence Server and User Agent settings.

Everything is configured as it should be.

When I change the SIP Network Log level to DEBUG I get an interesting error:

SIPMSG:

|SIP/2.0 404 Not found

Via: SIP/2.0/TCP 127.0.0.1:5060;branch=z9hG4bK30ba4fbc707a97bad20d502cbe4afd7f1445035;received=127.0.0.1;rport=25000;ingress-zone=DefaultZone

Call-ID:

c3917650d44b2414@192.168.226.100

CSeq: 474997920 NOTIFY

From: <>xxxxxxxx@domain.com>;tag=6ea8d6397a1c4517

To: <>mguguvcevski@domain.com>;tag=936c5724229b8c73

Server: TANDBERG/4102 (X7.0.2)

Warning: 399 127.0.0.1:5060 "Policy Response"

Content-Length: 0

SIPMSG:
|NOTIFY sip:mguguvcevski@domain.com;gr=urn:uuid:0b109443-d3d5-54af-a4fa-7189f86fe6e0 SIP/2.0
Via: SIP/2.0/TCP 127.0.0.1:5060;branch=z9hG4bK30ba4fbc707a97bad20d502cbe4afd7f1445035;received=127.0.0.1;rport=25000
Call-ID: c3917650d44b2414@192.168.226.100
CSeq: 474997920 NOTIFY
Contact: <>XXXXXXX@domain.com>
From: <>XXXXXXXX@domain.com>;tag=6ea8d6397a1c4517
To: <>mguguvcevski@domain.com>;tag=936c5724229b8c73
Route: <127.0.0.1:5060>
Route: <192.168.230.8:5061>
User-Agent: TANDBERG/4102 (X7.0.2)
Event: presence
P-Asserted-Identity: <>XXXXXXX@domain.com>
Subscription-State: active;expires=2880
Content-Type: application/pidf+xml
Content-Length: 569

    xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
    xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
    entity="sip:XXXXXXXXX@domain.com">

    open


    sip:XXXXXXXXX@domain.com





|

Tandberg Movi Presence problem.

awinter2 — Wed, 18 Jan 2012 10:50:27 GMT

mguguvcevski,

is 'domain.com' the actual SIP domain you are using for this deployment? Has this domain been added to the SIP domains on this VCS?

Are there any additional VCS's in this deployment at all? Where was the user 'mguguvcevski@domain.com' registered at when you took the trace shown above?

Do you have any transforms,search rules or CPL which modifies URI's at any point?

To answer Martin's question about disabling authentication challenges for the presence server, the answer is that presence PUBLISH messages do have to be authenticated as they are sent to the presence server application, otherwise these will be rejected with a '403 forbidden'.

The authentication portion is however done by the VCS main application, which is where you configure zone authentication, and using this you can manipulate authentication behaviour (Although not solely for presence related SIP messaging).

- Andreas

Tandberg Movi Presence problem.

mguguvcevski — Wed, 18 Jan 2012 11:17:57 GMT

Hi Andreas,

yes it is an actual SIP domain, I just deleted the details from the trace, given the fact it is a production system, and that this is a publicly accesible forum.

There is one VCS Control and one VCS Expressway in the system.

The user mguguvcevski is registered to the VCS Control as is the other user, xxxxxxxx@domain.com

Both of them are registering to a Cisco Jabber Video (Movi) specific Subzone on the VCS.

The only transformations that are in place have to do with the trunk between the VCS and CUCM and they are all in the form of:

(90\d{1})@VCSsIPAddress((:|;).*)? to mguguvcevski@domain.com for example

due to the fact that CUCM 8.6(2) does not support SIP URI dialing (yet).

I do not utilize CPLs.

Search rules are quite straightforward,

([5-9]\d{2,3})@domain.com(.*) sending calls to CUCM

.+@(domain.com|domain1.com|domain2.com|....|domainX.com) LocalZoneMatch

Search Rule for Multiway Conference Factory

(90[1-9])@%ip%(:.*)? CUCM to Locally registered devices search rule

And I also have the typical Traversal Search Rules for non local domains and unknown IP address.

Best regards,

Mihail

Re: Tandberg Movi Presence problem.

awinter2 — Wed, 18 Jan 2012 12:16:18 GMT

Mihail,

I see that you wrote in an earlier post that the VCS has presence server and presence user agent enabled, can you please verify that the presence server and PUA is enabled on the VCS-C and that only the PUA is enabled on the VCS-E?

The presence server should normally only be enabled on one of the VCS's, whereas the presence user agent should be enabled on all VCS's.

To me it sounds like the presence server is disabled on the VCS Control, or that somehow the Local Zone search rule on your VCS-C has some issues causing it not to match the recipient mguguvcevski@domain.com.

Could you try adding an 'AnyAlias' search rule to your Local Zone to see if that makes any difference?

Regards

Andreas

Message was edited by: Andreas Nervik Wintervold

Tandberg Movi Presence problem.

mguguvcevski — Wed, 18 Jan 2012 12:43:49 GMT

Hi Andreas,

Adding another LocalZoneMatch rule with Any Alias solved the issue.

I have to say I am still puzzled as to why a more typical Search Rule

.+@(domain.com|domain1.com|domain2.com|....|domainX.com)

with the domains I host on the VCS did not do the proper job.

I also have to add, that this worked properly with Movi 4.2 and older than TE4.0 versions for the E20.

On the strange side, I also had to select some of the favourites I have in Cisco Jabber for Video, click Edit Favourite and then just click Save again to get the Presence status updated.

Thank you and best regards,

Mihail

Tandberg Movi Presence problem.

awinter2 — Wed, 18 Jan 2012 13:01:05 GMT

Mihail,

I would be surprised if the software version of your E20/Movi devices would make any difference in this matter, since the problem seems to lie with the search rule on the VCS.

If domain.com, domain1.com,...,domainX.com all exists as SIP domains on your VCS, you might want to replace your existing search rule with

.+@%localdomains%.*

instead, as %localdomains% is a variable which contains all local SIP domains. Using this variable means that you don't have to modify the search rule each time a SIP domain is added or removed.

In cases such as these it is also advisable to utilize the locate tool on the VCS to verify that your search rules are working as expected, especially when you see '404 Not Found' when you are expecting to see something different.

Regards

Andreas

Tandberg Movi Presence problem.

mguguvcevski — Wed, 18 Jan 2012 13:36:09 GMT

Hi Andreas,

Exactly the search rule check was the problem.

Calls were successfully sent in and out of the VCS, and the check pattern with the domains listed also worked well. So, I supposed presence subscriptions should also work well too.

Why it did not consider the same Search Rule for Presence notifications is still unknown for me.

Anyway, it works now thanks to your help.

Thank you for the hints.

Regards,

Mihail

Tandberg Movi Presence problem.

awinter2 — Thu, 19 Jan 2012 08:27:30 GMT

Mihail,

in fact, I think the reason why the search rule was not working in this case while it may have worked before is that with the X7 software for the VCS, GRUU (Part of RFC 5627) was implemented as a new feature.

When using GRUU (Global Routable User agent URIs), a tag is appended after the SIP AOR, which means that if you register with Movi using the alias sip:mguguvcevski@domain.com on an X7 VCS, that user would be reachable as

sip:mguguvcevski@domain.com;gr=urn:uuid:0b109443-d3d5-54af-a4fa-7189f86fe6e0, whereas on X6 or older, you would be reachable as the alias you registered with, sip:mguguvcevski@domain.com.

This affects your search rules, since the routable alias also changes.

For example, if you have a Local Zone search rule matching the regex

.+@domain\.com

this will match mguguvcevski@domain.com, but not mguguvcevski@domain.com;gr=urn:uuid:0b109443-d3d5-54af-a4fa-7189f86fe6e0. This latter alias is the recipient of the presence NOTIFY which you pasted in an earlier post, which explains why the issue was resolved by adding an 'AnyAlias' search rule for your Local Zone.

If you modify the regex slightly, by adding a .* (. = Any character, * = 0 or more times) at the end, so that it looks like

.+@domain\.com.*

means that this regex will both match mguguvcevski@domain.com as well as

mguguvcevski@domain.com;gr=urn:uuid:0b109443-d3d5-54af-a4fa-7189f86fe6e0.

Hope this helps in clarifying things a bit.

- Andreas

Tandberg Movi Presence problem.

mguguvcevski — Tue, 21 Feb 2012 17:28:08 GMT

Hello Andreas,

I have to say that your answers are excellent and very technically sound.

I am encountering another Presence issue on the Control and Expressway setup, where presence status is not present when a Jabber client is outside the firewall registered with the Expressway.

From the debug SIP logs it seems that the SUBSCRIBE message sent from the Jabber client ends up with a SIP 482 Loop Detected.

Here is the debug, when a Jabber client with SIP AOR mguguvcevski@domain.com, a Jabber client sends a SUBSCRIBE for another system janezgruden@domain.com

The debug is from the Exppressway.

Feb 21 16:31:02 tvcs: UTCTime="2012-02-21 15:31:02,222" Module="network.sip" Level="DEBUG": Src-ip="193.110.145.227" Src-port="5061"

SIPMSG:

|SIP/2.0 482 Loop Detected

Via: SIP/2.0/TLS 193.110.145.227:5061;egress-

zone=DNSZone;branch=z9hG4bK3a48dbe7c7138ed38e9db679199f77151702866.2d8764708773594ea15025775a3afbc1;proxy-call-id=0fa9a3fe-5ca1-11e1-bd9d-

0010f31d189a;received=193.110.145.227;rport=26417;ingress-zone=DefaultZone

Via: SIP/2.0/TLS 192.168.196.165:65257;branch=z9hG4bK9cbf028715f6e8e39fc476f963b7602d.1;received=192.168.196.165;rport=65257;ingress-

zone=DefaultZone

Call-ID: ec990bd5a0e4f152@192.168.196.165

CSeq: 1903 SUBSCRIBE

From: <>mguguvcevski@domain.com>;tag=85d2129a84f51ddd

To: <>janezgruden@domain.com>;tag=b4e962b3628e16d5

Server: TANDBERG/4102 (X7.0.2)

Warning: 399 193.110.145.227:5061 "Loop Detected"

Content-Length: 0

Tandberg Movi Presence problem.

awinter2 — Tue, 21 Feb 2012 21:32:25 GMT

Mihail,

assuming that the presence server is located on the VCS Control, you have to make sure that you have a search rule from the VCS-E towards VCS-E which will match the address janesgruden@domain.com.

The log which you have provided indicate that the SUBSCRIBE request is sent out the DNS zone of the Expressway and therefore loops back to the VCS-E itself, rather than being sent towards the VCS-C.

Therefore please check your search rules and priorities so that requests sent to the 'domain.com' domain are proxied from VCS-E to VCS-C before optionally being sent out your DNS zone. Normally, the DNS zone search rule should be the 'last resort' for all searches performed on a VCS-E.

Ideally, the VCS-E should not use the DNS zone at all for local SIP domains where the DNS SRV records for said domains point back to this VCS-E, since that will create a loop regardless (and consume unnecessary search resources).

Please look at my first post in the following discussion for instructions on how to achieve this:

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

Regards

Andreas