cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
1836
Views
0
Helpful
10
Replies
Highlighted
Enthusiast

XMPP Federation Jabber "STATUS" not working all the time

Hi,

i have now some Expressway Installations up and running at customer site and mostly all have the same behavior regarding XMPP Federation. Its working fine but for any reason some users see the status as "available" first if they chat each other. It looks like a keepalive and i dont know. It seems its also different if its a MAC to WIN or a MAC to MAC or WIN to WIN Federation.

Maybe someone have the same behavior and can give a suggestion what to do.

If its working for some federations it seems its not a firewall issue. For Example:

Company X user MAC to Company Y MAC -> Working fine, all the time a status in jabber

Company X user WIN to Company Y MAC -> They need to chat each other to see status, but only for WIN client. MAC see the status of WIN Federation all the time

Any idea ?

Cheers 

10 REPLIES 10
Highlighted
Cisco Employee

It may be privacy policy on Jabber client specifics. There is no difference between how Jabber for Win vs Mac processes the federation IM/status request.

Bascially, in all cases (win or mac) both federation end will be prompted to add the far end user at the very first initiation of presence subscription (default privacy policy in Jabber).

Once the subscription accepted, the presence, IM should work in both ways flawlessly. Most of the times, if TLS is not fully established stange one-way presence issue is seen.

Most likely this is not a port level issue (5269 Tcp from both server end) since this is intermittent.

Please check if the TLS on IM&P is set to "TLS option" with "Required client side certificate" unchecked. Or even try "No TLS" options. "XCP Router" restart will be needed (Downtime necessary for IM&P). XCP Router restart is a major service impacting process, please consider extra time on hand.

Highlighted
Participant

Hello Thorstenn

I notice a similar behaviour with my Expressway customers. I use Jabber Cloud and usually I have no issues seeing the status of my customers that are behind Expressway but some only see me when I send them a Chat, after they login and logout the presence doesn't come back until we repeat the process. Port 5269 is open in both directions. This doesn't occur to all contacts in my customers list it only happens to some.

Ryan

Highlighted
Beginner

We see the same issue with federation contacts using a private circuit to connect to.  User presence seems to timeout and will only come back once you send them an IM and they respond.  We are set to no TLS and all services were restarted.

Highlighted
Hall of Fame Cisco Employee

You actually get a warning on that under XMPP federated connections in EXP-E

There are currently no federated connections
Federation connections are closed after 10 minutes of inactivity. Federation connections may be only one way.

I had a federated chat in my lab, now the users see each other as offline, and I no longer see any active connections in either of the EXP-E I'm using.

HTH

java

if this helps, please rate
Highlighted

Hi Jaime,

 

Means it that it is not possible to see the availability of any federated users after 10 minutes of the last activity?

 

We work with users in diferent geographic timezones, so it is not easy to know who are available and who not due to the shifts each one works to.

 

We have a xmpp federation in which it seems this behavior is taking place, but we also have a xmpp federation in which it seems it is not taking place and we are able to see the presence status of all these users all the time.

 

Could you clarify it a bit more, please?

 

Regards,

Pablo 

 

Highlighted

All sites using Jabber IDs or Email Addresses? How many external domains do you connect to? All of them go through the Expressways? Check the prerequisites, limitations/restrictions, etc. for XMPP Federation via Expressways.

Highlighted

Hi Mark,

Thank you very much for your time in answering me.

We are in a site in Spain. In our site we have two XMPP Federations with two other sites:

1- a XMPP Federation between the Spanish site and a germany site.

2- a XMPP Federation between the Spanish site and a mexican site.

 

The XMPP federation with germany works ok

 

Our XMPP federation with Mexico has issues with the presence status visibility between the sites. When there are chats in progress each one can see the presence status of the other party, but when there is no chats in progress, we cannot see the presence status of the other site users.

 

I understand it is an issue that we need to troubleshoot. I think it shouldn't work in this way, but I was surprised by the explanation of Jaime Valencia telling us that there is a timer that disconnects the XMPP federation connections after 10 minutes of inactivity, so he considers a normal behavior that the users at one site don't see the presence status of the users at the other site after 10 minutes inactivity.

In addition, in the Germany and Mexican sites are using Expressways for the XMPP Federation. In the Spanish site we are not using expressways for that (we use them for MRA and other video purposes, but not for XMPP federation).

 

Thanks again,

Pablo

Highlighted

Jaime's correct. The connection is closed after 10 minutes of inactivity, see page 23;

https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/expressway/config_guide/X8-11/Chat-and-Presence-Federation-with-Cisco-Expressway-X8-11-4.pdf 

I believe, activity includes messages sent/received as well as presence updates. If you have dozens and dozens of active connections, then you shouldn't run into this problem. Do you have more users at one site versus another site? If not, then perhaps the different timezones doesn't allow the bulk of the workforce at Mexico (GMT -7) to be online at the same time as Spain (GMT 0) and/or Germany (GMT +1). I assume XMPP Federation Connection Manager service has been disabled on CUP at Mexico and Germany since XMPP is running on the Expressways?

Highlighted

Hi Mark,

 

Maybe the problem here is my understanding on how this timer works and what happens once this timer reaches the 10 minutes of inactivity.

 

In the example with our XMPP federation with Germany:

Our XMPP federation with Germany is used by a lot of users on both sides, hundreds. Both Spain and Germany are in the same timezone (CET). I'm sure there are a lot of activity during the usual working hours, but what happens at the night? I'm pretty sure that along all the night there should be several inactivity periods longer tan 10 minutes. It does not cause that at the next day no one could see the presence status of the others. We have no issues here.

 

In the example with our XMPP federation with Mexico:

Our XMPP federation with Mexico is used by a very few users, maybe 20 or 30 as máximum at each side. In addition, we have a difference of 8 hours between our local hour and theirs. Our working hours do not match hardly ever with theirs. The sum of this two facts, few users and timezone differences, surely cause a lot of inactivity periods longer tan 10 minutes. But if is it the reason, there is no solution. The XMPP federation using expressway is not useful in this scenario in my view.

 

Thank you a lot,

Pablo

  

 

 

  

Highlighted

Do you really need the Expressways? Try this...

Login to CUP Admin > Presence > Inter-Domain Federation > XMPP Federation

You will find two options; Settings and Policy

Settings

XMPP Federation Node Status = On

Under the Security Settings, all of the settings should match each site (i.e. Spain, Mexico and Germany) but there's a few exceptions. If you're using TLS, Cisco recommends, the same Certificate Authority (CA) should sign your Tomcat, CUP, CUP-XMPP and CUP-XMPP-s2s certificates.

Policy

The XMPP Federation Default Policy is Allow. If you're going to federate freely with users on countless domains, then leave this settings alone. Change this setting to Deny if you want to restrict which domains connect to your domain. Click Add New and enter the Domain Name of the external domain, such as, example.com and click All Federated Packets... and then, click Save. You would perform the same procedures on the other clusters.

XMPP Federation between CUP and CUP is easier to configure and maintain, not to mention, the timeout for idle connection policy is better. By default, the timeout policy is 3600 seconds. The max value is 7200 seconds. If presence is very important, you can maintain unused (idled) connections via KeepAlive. By default, this setting is disabled (Off). You can enable this setting and adjust how often KeepAlives will be sent, however, please mindful how many users have external contacts because you may notice slightly more traffic (i.e. keepalive) than usual throughout the day. Nothing major but you don't want your firewall team to flag this type of traffic as malicious.