[SR-Users] Meaning of empty body in NOTIFY

[Eugen Dedu]

On 10/06/11 21:58, Daniel-Constantin Mierla wrote:
>
>
> 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.

It seems logical to me too.

Thank you, Daniel,
-- 
Eugen