-----Original Message----- From: Craig Southeren [mailto:craig@southeren.com] Sent: Monday, 6 June 2011 7:22 AM

> To resume: What does SIP standard say about this NOTIFY with empty > body? Does this mean that the user xyz is offline?

Here is my understanding. If the NOTIFY is the first NOTIFY sent in response to the SUBSCRIBE, then the NOTIFY should be ignored. Opal should be doing this. if the NOTIFY is *not* the first NOTIFY, i.e. there was a previous NOTIFY that contains a valid presence status, then the previous status should be used.

No idea? On 05/06/11 22:31, Eugen Dedu wrote: _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Thank you very much for your answer. Do you confirm that for kamailio, when a user has not been online since a long time ago, (1) it answers with an empty body notify (and not with a body with Offline status), and more importantly (2) that this means the user is offline? I ask this because this seems contradictory to what SIP standard says (see below): it does not say that empty body means offline, but just does not have "meaningful state". In fact, opal (SIP library among others) developers (in CC) consider that empty body means no information (which is different than offline!), while kamailio uses it for offline!

On 09/06/11 13:10, Daniel-Constantin Mierla wrote: > Hello, > > the notify is sent to inform about the state of the subscription, which > is active in this case. If it would the first subscription to that user > and force_active will not be set, then should be subscription state > pending, iirc. > > The empty body does not change anything to the phone information about > the watched presentity, which was known to be offline. > > Cheers, > Daniel > > On 6/8/11 10:06 PM, Eugen Dedu wrote: >> No idea? >> >> On 05/06/11 22:31, Eugen Dedu wrote: >>> Hi, >>> >>> ekiga.net registrar uses kamailio 1.5.3 (yes, a bit old...) and for >>> users who are not registered an empty NOTIFY body is returned when >>> asked >>> by a SUBSCRIBE. What does this mean from SIP standard point of >>> view, and >>> from kamailio point of view (are they identical?) I see in >>> RFC3265/3.1.6.2: >>> .... If the resource >>> has no meaningful state at the time that the SUBSCRIBE message is >>> processed, this NOTIFY message MAY contain an empty or neutral body >>> but is difficult for me to interpret what it means. >>> >>> Example: I ask the presence for a user xyz who registered and quit >>> application long time ago: >>> >>> SUBSCRIBE sip:xyz@ekiga.net SIP/2.0 >>> CSeq: 1 SUBSCRIBE >>> Via: SIP/2.0/UDP >>> 82.238.108.175:5060;branch=z9hG4bKdabe824f-1a8e-e011-9efc-0024d693d8e8;rport >>> >>> >>> >>> User-Agent: Ekiga/3.3.1 >>> From: >>> <sip:eugen.dedu@ekiga.net>;tag=4888824f-1a8e-e011-9efc-0024d693d8e8 >>> Call-ID: f602824f-1a8e-e011-9efc-0024d693d8e8@snoopy >>> Supported: eventlist >>> To: <sip:xyz@ekiga.net> >>> Accept: application/pidf+xml >>> Accept: multipart/related >>> Accept: application/rlmi+xml >>> Contact: <sip:eugen.dedu@82.238.108.175:5060> >>> Allow: >>> INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING,PRACK >>> >>> >>> >>> Expires: 300 >>> Event: presence >>> Content-Length: 0 >>> Max-Forwards: 70 >>> >>> I receive the following answer: >>> >>> NOTIFY sip:eugen.dedu@82.238.108.175:5060 SIP/2.0 >>> CSeq: 1 NOTIFY >>> Via: SIP/2.0/UDP 86.64.162.35;branch=z9hG4bK2a99.b8a72c47.0 >>> User-Agent: Kamailio (1.5.3-notls (i386/linux)) >>> From: sip:xyz@ekiga.net;tag=f85b0bd16aaafa8479586ac9f88b3198-10a0 >>> Call-ID: f602824f-1a8e-e011-9efc-0024d693d8e8@snoopy >>> To: sip:eugen.dedu@ekiga.net;tag=4888824f-1a8e-e011-9efc-0024d693d8e8 >>> Contact: <sip:86.64.162.35:5060> >>> Subscription-State: active;expires=370 >>> Event: presence >>> Content-Length: 0 >>> Max-Forwards: 70 >>> >>> To resume: What does SIP standard say about this NOTIFY with empty >>> body? >>> Does this mean that the user xyz is offline? >>> >>> Or does this mean that user's status has not changed? In fact, the >>> NOTIFY with empty body (as shown above) is the first one sent by >>> kamailio, so there is no "previous" state of that user, hence >>> "unchanged" status has no meaning. >>> >>> Thank you,

On 10/06/11 12:18, Daniel-Constantin Mierla wrote: 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?

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.

_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

On 10/06/2011 3:49 AM, Daniel-Constantin Mierla wrote: ..deleted 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?

On 10/06/11 12:18, Daniel-Constantin Mierla wrote: 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?

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.

>> On 09/06/11 13:10, Daniel-Constantin Mierla wrote: >>> Hello, >>> >>> the notify is sent to inform about the state of the subscription, which >>> is active in this case. If it would the first subscription to that user >>> and force_active will not be set, then should be subscription state >>> pending, iirc. >>> >>> The empty body does not change anything to the phone information about >>> the watched presentity, which was known to be offline. >>> >>> Cheers, >>> Daniel >>> >>> On 6/8/11 10:06 PM, Eugen Dedu wrote: >>>> No idea? >>>> >>>> On 05/06/11 22:31, Eugen Dedu wrote: >>>>> Hi, >>>>> >>>>> ekiga.net registrar uses kamailio 1.5.3 (yes, a bit old...) and for >>>>> users who are not registered an empty NOTIFY body is returned when >>>>> asked >>>>> by a SUBSCRIBE. What does this mean from SIP standard point of >>>>> view, and >>>>> from kamailio point of view (are they identical?) I see in >>>>> RFC3265/3.1.6.2: >>>>> .... If the resource >>>>> has no meaningful state at the time that the SUBSCRIBE message is >>>>> processed, this NOTIFY message MAY contain an empty or neutral body >>>>> but is difficult for me to interpret what it means. >>>>> >>>>> Example: I ask the presence for a user xyz who registered and quit >>>>> application long time ago: >>>>> >>>>> SUBSCRIBE sip:xyz@ekiga.net SIP/2.0 >>>>> CSeq: 1 SUBSCRIBE >>>>> Via: SIP/2.0/UDP >>>>> 82.238.108.175:5060;branch=z9hG4bKdabe824f-1a8e-e011-9efc-0024d693d8e8;rport >>>>> >>>>> >>>>> >>>>> User-Agent: Ekiga/3.3.1 >>>>> From: >>>>> <sip:eugen.dedu@ekiga.net>;tag=4888824f-1a8e-e011-9efc-0024d693d8e8 >>>>> Call-ID: f602824f-1a8e-e011-9efc-0024d693d8e8@snoopy >>>>> Supported: eventlist >>>>> To: <sip:xyz@ekiga.net> >>>>> Accept: application/pidf+xml >>>>> Accept: multipart/related >>>>> Accept: application/rlmi+xml >>>>> Contact: <sip:eugen.dedu@82.238.108.175:5060> >>>>> Allow: >>>>> INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING,PRACK >>>>> >>>>> >>>>> >>>>> Expires: 300 >>>>> Event: presence >>>>> Content-Length: 0 >>>>> Max-Forwards: 70 >>>>> >>>>> I receive the following answer: >>>>> >>>>> NOTIFY sip:eugen.dedu@82.238.108.175:5060 SIP/2.0 >>>>> CSeq: 1 NOTIFY >>>>> Via: SIP/2.0/UDP 86.64.162.35;branch=z9hG4bK2a99.b8a72c47.0 >>>>> User-Agent: Kamailio (1.5.3-notls (i386/linux)) >>>>> From: sip:xyz@ekiga.net;tag=f85b0bd16aaafa8479586ac9f88b3198-10a0 >>>>> Call-ID: f602824f-1a8e-e011-9efc-0024d693d8e8@snoopy >>>>> To: sip:eugen.dedu@ekiga.net;tag=4888824f-1a8e-e011-9efc-0024d693d8e8 >>>>> Contact: <sip:86.64.162.35:5060> >>>>> Subscription-State: active;expires=370 >>>>> Event: presence >>>>> Content-Length: 0 >>>>> Max-Forwards: 70 >>>>> >>>>> To resume: What does SIP standard say about this NOTIFY with empty >>>>> body? >>>>> Does this mean that the user xyz is offline? >>>>> >>>>> Or does this mean that user's status has not changed? In fact, the >>>>> NOTIFY with empty body (as shown above) is the first one sent by >>>>> kamailio, so there is no "previous" state of that user, hence >>>>> "unchanged" status has no meaning. >>>>> >>>>> Thank you, >

[...] If the application starts by putting each contact as offline, there will be no difference between no information known (while waiting a notify) and offline. Moreover, no reply to subscribe could be another status: presence error. So I would say the right thing is to have three statuses: - no info known - presence error - offline To make things simple, I will put everyone in my application as offline at the beginning, and the user will have to wait a few seconds (how many?) to discover if some contact is really offline or still waiting a notify. Thank you so far for your explanations.

On 10/06/2011 11:20 AM, Daniel-Constantin Mierla wrote: ...deleted I know there is an XCAP verb to do this. Also, you might like to look at "RFC 4481 - Timed Presence Extensions to the Presence Information Data Format". This allows a client to specify status for a future time period when other status may not be available. Specifically, the RFC says: "During composition, a presence agent (PA) may encounter a stored <timed-status> element that covers the present time. The PA MAY either discard that element or MAY convert it to a regular <status> element if it considers that information more credible." So, if a client uploads a presence document that contains a <timed-status> element, that element could be sent by the PA when the client goes offline, rather than the entire document being discarded (which is what I suspect is happening now).

2011/6/10 Daniel-Constantin Mierla&lt;miconda(a)gmail.com&gt;om>: That is anohter hyper-exotic and ugly SIMPLE-Presence feature.

Right. The presence server must never generate a pidf document in behalf of the user.