I'm working for an implementation of the SIMPLE protocol for my GSoC. So here is a first prevision of the work I'll do which need some expert point of view :).
(when I'm speaking about RFCs, I'm speaking about RFC3261, RFC3265, RFC3856 and RFC3903)
Yesterday I finalized and summarized all I know from the RFCs and I wanted to make some packet capture using SIMPLE (sadly neither pidgin, open wengo or kphone worked).
Even if I don't have any really good dump, I studied every interesting
RFCs and here is a basic description of how I understand my work.
we have to distinguish two major situations :
first situation, the user hasn't access to any presence server and SC
has to act as a presence server.
second situation, the user want to publish his presence status to a
distant computer which will act as a presence server.
first situation : no presence server :
In this case we will receive some SUBSCRIBE requests and we will send
NOTIFY responses to these clients. This is the normal behavior.
second situation : a distant presence server :
We will simply send to this server a PUBLISH message each time our
presence status changes. This way, the server will always be able to
know our presence status and send it to subscribed clients.
In every case when we want to know the presence status of a contact, if
we know the address of a presence server he uses, we communicate with
this server, if we don't have any presence uri of a such server (or if
the server uri isn't working), we communicate directly with the contact.
The presence server uri will be a new parameter associated with any sip
In this situation, we will handle the SUBSCRIBE requests as if we were
in the first situation to handle the case of a contact non aware of our
deported presence server.
Here are some difficulties :
- When we act as a presence server, we must handle properly the expire
date of subscriptions (use a separate thread for wait a delay to be 0
and close every elapsed subscription)
- In all case, we must keep all our subscriptions up to date (send some
keep alive packets), this could also be done in a separate thread
- If the presence server of a contact is physically disconnected (not
just offline) we must send some new SUBSCRIBE messages to him (let's say
every minute) until he appear to be back. This can also mean a new
thread. If we receive any message from him, we can consider him as
online and we can immediately try to send a SUBSCRIBE message.
This will also handle the case of an unimplemented presence protocol but
in this case we will stop to send SUBSCRIBE messages when we know that
this user is physically connected.
- We may avoid to connect multiple times to the same server (for example
if the same presence server is used by more than one contact)
(it may be possible to handle every time related tasks in the same thread).
The choice between these two situations will depend on if the user enter
an uri for a presence server when he creates a new SIP account.
In term of presence state, I'm thinking on proposing the same state as
with MSN which is, I think, really enough. I don't know for the moment
what to use to build the xml presence document but I'm sure that java
has a lot of powerful tools to work with xml documents.
I'd like to know what you think about it ? Does it seems correct to you
? Do I forget some cases ?
I still have a little doubt on how to handle the clients which don't
implement the presence I propose here to test if they are present on the
network by tranforming SUBSCRIBE requests in a sort of ping but I
understand that this solution is really not efficient. It could also be
possible to consider them as always online since we know that they are
present on the network. Considering them as always offline will imply
some problem for the IM but it's also possible.