4

we've got an XMPP server (OpenFire) and a custom client based on the Java Smack XMPP stack. We're using manual subscription acceptance, so clients have to exchange subscribe and subscribed presences.

As noted in the RFC, subscribe presences ("I want to subscribe to your presences") are stored by the server and resent every time the user logs in until he answers them. Unfortunately, the same does not seem to be true for the answers ("subscribed" or "unsubscribed"). If the original requester if offline when the other users answers the subscription request, he does not receive the answer. I could not find anything in the XMPP RFC about expected behaviour of the server.

What can I do? Is there something I might have missed? Or is there a standard way to implement this use case?

This OpenFire forum post suggests that the behaviour I'm experiencing is the desired one...

Thanks for all pointers, Florian

Andreas Dolk
  • 113,398
  • 19
  • 180
  • 268
Florian Thiel
  • 497
  • 4
  • 10
  • 1
    Ok, one possible solution (and the one I used) is checking the Roster on connection and "repairing" all one-way subscriptions at that point by automatically establishing the other way. – Florian Thiel Jan 05 '11 at 11:29

2 Answers2

1

You have two means at your disposal for determining the state of the subscription:

  1. Check the roster of the requesting user. If the roster contains a item for the entity in question with a subscription attribute of "to" or "both" then you are subscribed.
  2. Second option is to send another subscribe packet to the server; the server should respond immediately with a subscribed on behalf of the other user if they have already accepted the presence request.
alexwen
  • 1,128
  • 7
  • 16
0

So Alice wants to subscribe to Bobs presence information and sends subscription request. The server will send notifications to Bob until he answers with yes or no. And your problem now is, that the server will not notify Alice, if she's offline, while Bob reacts on the request. So Alice will get Bobs answer just by chance.

If Bob agrees to exchange presence information, Alice will notice this on her roster - she'll see Bobs presence (away, idle, ...). Otherwise, she won't know, if the request is still pending or if Bob rejected her request.

It is possible to change this behaviour by implementing and adding a custom module to your openfire server. Openfire has an API for this.

This module will react on confirmation messages and could send a status message for all pending or recently confirmed subscription messages to the subscriber (on every logon). Your client code can handle those messages and present this status in an appropriate way to the subscriber.

Andreas Dolk
  • 113,398
  • 19
  • 180
  • 268