[sip-comm-dev] [gsoc] SIMPLE - first try


#1

Hey guys,

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
contact.

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.

cheers,
Ben

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Hello Ben,

Thanks for your update. I am really glad that we are finally going to
have real SIMPLE support in SIP Communicator.

(more inline)

Benoit Pradelle wrote:

Hey guys,

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 contact.

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)

This was already being handled in the previous version of SIP
Communicator (I think I've given you a copy of it a month or so ago).
IIRC we were using java.util.Timer-s to handle this.

- 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

Same story. And by the way why is this case different from the above?
Shouldn't it be handled by the same Timer/Thread? Isn't this explicitly
defined in 3265?

- 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.

If we have received a message from the client then it was most probably
a NOTIFY sent in response to one of our previous subscribes. Do we
really need to send a new SUBSCRIBE?

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.

Right.

- 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)

Well, we don't really connect since we are only sending datagrams ... or
did you mean that there's a way to group multiple SUBCRIBE-s in a single
request? I think we'd need to go on sending SUBSCRIBE-s for every single
contact even if they are all on the same server.

(it may be possible to handle every time related tasks in the same
thread).

Yes, that's how it would be if we used java.util.Timer-s with a
TimerTask per subscription.

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.

Actually, isn't this supposed to be the same as your registrar/sip
proxy? Otherwise we'd need to modify our sip account creation wizard and
add an extra line that allows to enter a presence server ... or we could
add this as one of the "advanced" fields and assume that by default it's
the same as the registrar.

Oh and by the way, are you aware of any servers that can act as a
presence agent? I guess we'll need to install one so that we could run
the cruise control builds against it.

In term of presence state, I'm thinking on proposing the same state
as with MSN which is, I think, really enough.

Agreed. Though we need to be prepared to handle NOTIFY-s giving us status-es that match none of our own since, as far as I know, SIMPLE does not define an exhaustive set of states and allows clients to define their own.

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.

That too was handled in the old version. Let me know if you don't have
it and I'll try to dig out a copy for you.

I'd like to know what you think about it ? Does it seems correct to
you ? Do I forget some cases ?

It sounds very reasonable, so keep up the good work!

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.

Isn't this also specified by 3265? I guess if the client doesn't support
presence then you'd simply receive an error response to your SUBSCRIBE
request.

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.

Or we could add an extra status called something like UNKNOWN. WDYT?

Emil

···

cheers, Ben

---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscribe@sip-communicator.dev.java.net For additional
commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hi Emil,

Emil Ivov a �crit :

Hello Ben,

Thanks for your update. I am really glad that we are finally going to
have real SIMPLE support in SIP Communicator.

(more inline)

Benoit Pradelle wrote:

Hey guys,

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 contact.

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)

This was already being handled in the previous version of SIP
Communicator (I think I've given you a copy of it a month or so ago).
IIRC we were using java.util.Timer-s to handle this.

I have a copy of the previous version of SC, and I've seen the work done with it, I just wanted to mark this point as a probably difficult point in the implementation.

- 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

Same story. And by the way why is this case different from the above?
Shouldn't it be handled by the same Timer/Thread? Isn't this explicitly
defined in 3265?

It's not different ant it will be handled in the same Timer/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.

If we have received a message from the client then it was most probably
a NOTIFY sent in response to one of our previous subscribes. Do we
really need to send a new SUBSCRIBE?

I mean we got to immediately subscribe to him if we receive a message which is not a notify (new call, MESSAGE request, ...) to maintain the presence status up to date sooner as possible (without waiting the next periodic SUBSCRIBE)

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.

Right.

- 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)

Well, we don't really connect since we are only sending datagrams ... or
did you mean that there's a way to group multiple SUBCRIBE-s in a single
request? I think we'd need to go on sending SUBSCRIBE-s for every single
contact even if they are all on the same server.

Yes of course, my bad.

(it may be possible to handle every time related tasks in the same
thread).

Yes, that's how it would be if we used java.util.Timer-s with a
TimerTask per subscription.

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.

Actually, isn't this supposed to be the same as your registrar/sip
proxy? Otherwise we'd need to modify our sip account creation wizard and
add an extra line that allows to enter a presence server ... or we could
add this as one of the "advanced" fields and assume that by default it's
the same as the registrar.

Yes it's what I want to do: change the account wizard to allow the user to choose another presence server.

Oh and by the way, are you aware of any servers that can act as a
presence agent? I guess we'll need to install one so that we could run
the cruise control builds against it.

OpenSER can do so : http://www.iptel.org/presence/ and http://www.iptel.org/~vku/presence_handbook/index.html

In term of presence state, I'm thinking on proposing the same state
as with MSN which is, I think, really enough.

Agreed. Though we need to be prepared to handle NOTIFY-s giving us status-es that match none of our own since, as far as I know, SIMPLE does not define an exhaustive set of states and allows clients to define their own.

Yes it's true, we got to take care of this.

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.

That too was handled in the old version. Let me know if you don't have
it and I'll try to dig out a copy for you.

I'll inspire myself with what as been done in the previous version

I'd like to know what you think about it ? Does it seems correct to
you ? Do I forget some cases ?

It sounds very reasonable, so keep up the good work!

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.

Isn't this also specified by 3265? I guess if the client doesn't support
presence then you'd simply receive an error response to your SUBSCRIBE
request.

Yes but I just wanted to say that I think that the principle of sending periodic SUBSCRIBE seems not really network friendly as it will imply a lot of traffic load for nothing.

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.

Or we could add an extra status called something like UNKNOWN. WDYT?

Yes it's also a possibility, when I've written this mail it appears to me as a little bit disturbing (as a normal IM user) to have an "unknown" state for my contacts but with SIMPLE it really take sense and for SIMPLE users it'll probably be ok.

Ben

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net