[SR-Users] Meaning of empty body in NOTIFY

[Daniel-Constantin Mierla]

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

-- 
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda