On 6/10/11 8:17 PM, Craig Southeren wrote:
On 10/06/2011 3:49 AM, Daniel-Constantin Mierla wrote:
..deleted
Ok. But this happens when I start my application, so it does not know anything about the contacts, and it receives empty body. So, even after this notify, it still does not know anything about that contact, is that right?
Any application (or those I used so far), they show the contacts offline at startup, this is the initial state. Kamailio notifies with presence states when there is a PUBLISH by the presentity. The notification with the empty body give the state of the subscription, not the state of contact -- see the subscription-state header in notify.
Also, as the user is offline (not connected since long time ago), why then kamailio sends an empty body for him instead of sending Offline status? This would allow the application to correctly show him as offline, instead of "nothing known". I noticed that even after several minutes no Offline status is sent by kamailio.
The sip presence server sends in notify only the presence documents published by a user agent. If there is no such document, the sip server has nothing to send. I think there are some specs that allow a user to set default state, probably via xcap -- but I am not sure and I haven't searched ietf for it.
I agree that an application should assume a contact is offline at the time of the initial SUBSCRIBE. Any subsequent NOTIFYs will modify that status.
If an empty NOTIFY is send as the first NOTIFY after a SUBSCRIBE, then this means the server has no presence document for the subscribed entity. This will occur when when entity is offline.
If the entity is online, then the first NOTIFY may still be empty, but there should be a subsequent NOTIFY containing the current presence document.
Hopefully, this second NOTIFY is sent as soon as possible after the SUBSCRIBE, and is not deferrred to when the second party refreshes it's presence document, which could be minutes or even hours later (depending on the presence timeout)
Daniel - can you confirn this?
yes, this is how I thought it should be.
Cheers, Daniel