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 5/06/2011 1:31 PM, 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:
..deleted
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.
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.
Craig
-----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?
The specification gives no meaning to an empty body. "No meaning" does not mean "offline". Offline means something!
The only purpose of sending a NOTIFY with an empty body, as per the specification, is to finalise the establishment of a subscription when you do not yet have any state information. Any other use is "undocumented", so there had better be a large body of evidence that "everyone does it that way" before we use any semantics.
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.
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.
Interestingly, I was doing some Googling on this and it appears that the first notify, when it is empty, is supposed to have a Subscription-State header field value of "pending". Again the specification is not clear but there were some discussion groups that mentioned this.
Unfortunately, Kamailio does not do this. So we could not even use this as a discriminator.
Robert Jongbloed OPAL/OpenH323/PTLib Architect and Co-founder.
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,
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,
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@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,
Hello,
On 6/10/11 12:04 PM, Eugen Dedu wrote:
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!
it is not for online, it is like the others understood -- an empty body does not change anything. Because of that I said that if the UA knew the user is offline, it stays offline. When a UA has a user with online state, if it is a notify with empty body, stays like that, nothing changes.
Cheers, Daniel
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:
Hello,
On 6/10/11 12:04 PM, Eugen Dedu wrote:
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!
it is not for online, it is like the others understood -- an empty body does not change anything. Because of that I said that if the UA knew the user is offline, it stays offline. When a UA has a user with online state, if it is a notify with empty body, stays like that, nothing changes.
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,
On 6/10/11 12:27 PM, Eugen Dedu wrote:
On 10/06/11 12:18, Daniel-Constantin Mierla wrote:
Hello,
On 6/10/11 12:04 PM, Eugen Dedu wrote:
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!
it is not for online, it is like the others understood -- an empty body does not change anything. Because of that I said that if the UA knew the user is offline, it stays offline. When a UA has a user with online state, if it is a notify with empty body, stays like that, nothing changes.
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.
Cheers, Daniel
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,
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@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
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?
Craig
--
----------------------------------------------------------------------- Craig Southeren Post Increment – VoIP Consulting and Software craigs@postincrement.com.au www.postincrement.com.au
Phone: +61 243654666 ICQ: #86852844 Fax: +61 243656905 MSN: craig_southeren@hotmail.com Mobile: +61 417231046 Jabber: craigs@jabber.org
"Science is the poetry of reality." Richard Dawkins
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
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,
On Jun 10, 2011, at 12:27 PM, Eugen Dedu Eugen.Dedu@pu-pm.univ-fcomte.fr wrote:
On 10/06/11 12:18, Daniel-Constantin Mierla wrote:
Hello,
On 6/10/11 12:04 PM, Eugen Dedu wrote:
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!
it is not for online, it is like the others understood -- an empty body does not change anything. Because of that I said that if the UA knew the user is offline, it stays offline. When a UA has a user with online state, if it is a notify with empty body, stays like that, nothing changes.
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?
What happens if there is no reply to subscribe and no notify? Is it considered offline? If yes, then probably should stay the same for first notify with empty body.
Iirc it is a must to send a body to tell the subscription state.
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 presence server sends notifications with documents published by phones. If there is no such document, I see no reason to build one, unless the user demanded that via some preferences - it would be xcap - I haven't searched the specs, just my expectation based on simple presence architecture.
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 16:07, Daniel-Constantine Mierla wrote:
On Jun 10, 2011, at 12:27 PM, Eugen DeduEugen.Dedu@pu-pm.univ-fcomte.fr wrote:
On 10/06/11 12:18, Daniel-Constantin Mierla wrote:
Hello,
On 6/10/11 12:04 PM, Eugen Dedu wrote:
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!
it is not for online, it is like the others understood -- an empty body does not change anything. Because of that I said that if the UA knew the user is offline, it stays offline. When a UA has a user with online state, if it is a notify with empty body, stays like that, nothing changes.
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?
What happens if there is no reply to subscribe and no notify? Is it
considered offline? If yes, then probably should stay the same for first notify with empty body.
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.
Iirc it is a must to send a body to tell the subscription state.
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 presence server sends notifications with documents published by phones. If there is no such document, I see no reason to build one, unless the user demanded that via some preferences - it would be xcap - I haven't searched the specs, just my expectation based on simple presence architecture.
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 6/10/11 7:58 PM, Eugen Dedu wrote:
[...]
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.
have you spotted in SIP/SIMPLE specs what has to be sent when the presentity is offline? My quick google was not that succesful. Maybe Inaki has the specs more fresh indexed in memory and can help.
I based my assumption that the sip/simple presence server should not generate itself a presence/pidf document with status closed/offline since the pidf has a <tuple id="..."> node that is generated by presentity device.
Cheers, Daniel
On 10/06/2011 11:20 AM, Daniel-Constantin Mierla wrote:
...deleted
Thank you so far for your explanations.
have you spotted in SIP/SIMPLE specs what has to be sent when the presentity is offline? My quick google was not that succesful. Maybe Inaki has the specs more fresh indexed in memory and can help.
I based my assumption that the sip/simple presence server should not generate itself a presence/pidf document with status closed/offline since the pidf has a <tuple id="..."> node that is generated by presentity device.
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).
Craig
On 6/10/11 8:49 PM, Craig Southeren wrote:
On 10/06/2011 11:20 AM, Daniel-Constantin Mierla wrote:
...deleted
Thank you so far for your explanations.
have you spotted in SIP/SIMPLE specs what has to be sent when the presentity is offline? My quick google was not that succesful. Maybe Inaki has the specs more fresh indexed in memory and can help.
I based my assumption that the sip/simple presence server should not generate itself a presence/pidf document with status closed/offline since the pidf has a <tuple id="..."> node that is generated by presentity device.
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).
we don't have this rfc implemented in kamailio at this time. Is any UA you know doing this kind of thing?
Cheers, Daniel
2011/6/10 Daniel-Constantin Mierla miconda@gmail.com:
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).
we don't have this rfc implemented in kamailio at this time. Is any UA you know doing this kind of thing?
That is anohter hyper-exotic and ugly SIMPLE-Presence feature.
On 10/06/2011 9:55 PM, Iñaki Baz Castillo wrote:
2011/6/10 Daniel-Constantin Mierlamiconda@gmail.com:
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).
we don't have this rfc implemented in kamailio at this time. Is any UA you know doing this kind of thing?
That is anohter hyper-exotic and ugly SIMPLE-Presence feature.
I agree :)
2011/6/10 Daniel-Constantin Mierla miconda@gmail.com:
have you spotted in SIP/SIMPLE specs what has to be sent when the presentity is offline? My quick google was not that succesful. Maybe Inaki has the specs more fresh indexed in memory and can help.
If the user has not published a "offline" presentity, then the server must not generate one. Sending an empty NOTIFY is the correct behaviour, which means "unknown state" (most of the subscribers should interpret it as "offline").
What is the purpose of publishing a presentity with "offline" status? Well, as most of the SIMPLE presence stuff, it's just a way to make things hyper-complex.
There is however an exception: RFC 4827. The client goes on holidays for long time and decides to upload,, via *XCAP* a *permanent* (non expirable as a PUBLISH publication) pidf document in which it set the info it desires (maybe a status "offline" with a message "I'm on holiday until June 20").
I based my assumption that the sip/simple presence server should not generate itself a presence/pidf document with status closed/offline since the pidf has a <tuple id="..."> node that is generated by presentity device.
Right. The presence server must never generate a pidf document in behalf of the user.
On 11/06/2011, at 2:54 PM, Iñaki Baz Castillo wrote:
I based my assumption that the sip/simple presence server should not generate itself a presence/pidf document with status closed/offline since the pidf has a <tuple id="..."> node that is generated by presentity device.
Right. The presence server must never generate a pidf document in behalf of the user.
Fair enough.
There were some hints in the RFC that the clients should detect "stale" presence themselves. Certainly would not be the purview of the PA.
One thing though, other than immediately after a SUBSCRIBE, will Kamailio ever send an empty NOTiFY? If so, what would trigger it?
-------- Robert Jongbloed Vox Lucida Pty. Ltd.
Hello,
On 6/11/11 6:54 AM, Iñaki Baz Castillo wrote:
2011/6/10 Daniel-Constantin Mierlamiconda@gmail.com:
have you spotted in SIP/SIMPLE specs what has to be sent when the presentity is offline? My quick google was not that succesful. Maybe Inaki has the specs more fresh indexed in memory and can help.
If the user has not published a "offline" presentity, then the server must not generate one. Sending an empty NOTIFY is the correct behaviour, which means "unknown state" (most of the subscribers should interpret it as "offline").
What is the purpose of publishing a presentity with "offline" status? Well, as most of the SIMPLE presence stuff, it's just a way to make things hyper-complex.
There is however an exception: RFC 4827. The client goes on holidays for long time and decides to upload,, via *XCAP* a *permanent* (non expirable as a PUBLISH publication) pidf document in which it set the info it desires (maybe a status "offline" with a message "I'm on holiday until June 20").
right, it was the rfc i wanted to search for -- this features in kamailio presence implementation, can be controlled via module parameter pidf_manipulation , see: http://kamailio.org/docs/modules/stable/modules_k/presence_xml.html#id294072...
Cheers, Daniel
-
Craig Southeren -
Daniel-Constantin Mierla -
Daniel-Constantine Mierla
-
Eugen Dedu -
Iñaki Baz Castillo -
Robert Jongbloed