Hi,
I am currently experimenting with the presence module (openser v1.2.1). It seems to work really fine. I only encountered a small problem.
When my client unsubscribes from the presence event by sending a SUBSCRIBE request with expires=0, then openser responds with a 200 OK. After the 200 OK, I expect to receive a NOTIFY message, but openser never sends this NOTIFY. It is this NOTIFY that should terminate the subscription dialog through its Subscription-State header set to "terminated".
RFC 3856 states this:
The subscriber can terminate the subscription by sending a SUBSCRIBE, within the dialog, with an Expires header field (which indicates duration of the subscription) value of zero. This causes an immediate termination of the subscription. A NOTIFY request is then generated by the presence agent with the most recent state.
This behavior is based on the general requirements for event handling as defined in RFC 3265.
Is this a bug or is there some configuration stuff that enables/disables the NOTIFY for a SUBSCRIBE with epxpires=0.
A SUBSCRIBE with expires=0 can also arrive as the initial and final SUBSCRIBE for a subscription. In that case it will be fetching the presence information only once. Without the NOTIFY, a fetch does not work.
Cheers, Michel
Hello,
Indeed the module did not sent Notify messages when unsubscribing. It did, however, sent them when an initial Subscribe with expires 0 was received. I have fixed that in the latest commit. Thanks for reporting.
Best regards,
Anca Vamanu
Michel de Boer wrote:
Hi,
I am currently experimenting with the presence module (openser v1.2.1). It seems to work really fine. I only encountered a small problem.
When my client unsubscribes from the presence event by sending a SUBSCRIBE request with expires=0, then openser responds with a 200 OK. After the 200 OK, I expect to receive a NOTIFY message, but openser never sends this NOTIFY. It is this NOTIFY that should terminate the subscription dialog through its Subscription-State header set to "terminated".
RFC 3856 states this:
The subscriber can terminate the subscription by sending a SUBSCRIBE, within the dialog, with an Expires header field (which indicates duration of the subscription) value of zero. This causes an immediate termination of the subscription. A NOTIFY request is then generated by the presence agent with the most recent state.
This behavior is based on the general requirements for event handling as defined in RFC 3265.
Is this a bug or is there some configuration stuff that enables/disables the NOTIFY for a SUBSCRIBE with epxpires=0.
A SUBSCRIBE with expires=0 can also arrive as the initial and final SUBSCRIBE for a subscription. In that case it will be fetching the presence information only once. Without the NOTIFY, a fetch does not work.
Cheers, Michel
Hi,
I just checked out the sources from the trunk. And the presence module does not seem to work anymore :(
On the SUBSCRIBE (Event header set to "presence") I send, I get a 489 Bad Event response. The SUBSCRIBE is exactly the same as the SUBSCRIBE I used with version 1.2.1. There it worked.
Furthermore, the 489 reponse is malformed. The mandatory Allow-Events header is missing.
This is what I see in the error logging:
7(16680) parse_headers: flags=ffffffffffffffff 7(16680) PRESENCE: handle_subscribe:Missing or unsupported event header field value
Regards, Michel
Anca-Maria Vamanu wrote:
Hello,
Indeed the module did not sent Notify messages when unsubscribing. It did, however, sent them when an initial Subscribe with expires 0 was received. I have fixed that in the latest commit. Thanks for reporting.
Best regards,
Anca Vamanu
Michel de Boer wrote:
Hi,
I am currently experimenting with the presence module (openser v1.2.1). It seems to work really fine. I only encountered a small problem.
When my client unsubscribes from the presence event by sending a SUBSCRIBE request with expires=0, then openser responds with a 200 OK. After the 200 OK, I expect to receive a NOTIFY message, but openser never sends this NOTIFY. It is this NOTIFY that should terminate the subscription dialog through its Subscription-State header set to "terminated".
RFC 3856 states this:
The subscriber can terminate the subscription by sending a SUBSCRIBE, within the dialog, with an Expires header field (which indicates duration of the subscription) value of zero. This causes an immediate termination of the subscription. A NOTIFY request is then generated by the presence agent with the most recent state.
This behavior is based on the general requirements for event handling as defined in RFC 3265.
Is this a bug or is there some configuration stuff that enables/disables the NOTIFY for a SUBSCRIBE with epxpires=0.
A SUBSCRIBE with expires=0 can also arrive as the initial and final SUBSCRIBE for a subscription. In that case it will be fetching the presence information only once. Without the NOTIFY, a fetch does not work.
Cheers, Michel
Hello,
There has been a reorganization in the trunk version for the presence modules. You need to load also presence_xml. You have to make the following changes. Insert ' loadmodule "presence_xml.so" '. If you have set force_active , then replace the line modparam("presence", "force_active", 1) with modparam("presence_xml", "force_active", 1). However, the reply is indeed malformed . I will fix that. Thanks.
regards,
Anca Vamanu
Michel de Boer wrote:
Hi,
I just checked out the sources from the trunk. And the presence module does not seem to work anymore :(
On the SUBSCRIBE (Event header set to "presence") I send, I get a 489 Bad Event response. The SUBSCRIBE is exactly the same as the SUBSCRIBE I used with version 1.2.1. There it worked.
Furthermore, the 489 reponse is malformed. The mandatory Allow-Events header is missing.
This is what I see in the error logging:
7(16680) parse_headers: flags=ffffffffffffffff 7(16680) PRESENCE: handle_subscribe:Missing or unsupported event header field value
Regards, Michel
Anca-Maria Vamanu wrote:
Hello,
Indeed the module did not sent Notify messages when unsubscribing. It did, however, sent them when an initial Subscribe with expires 0 was received. I have fixed that in the latest commit. Thanks for reporting.
Best regards,
Anca Vamanu
Michel de Boer wrote:
Hi,
I am currently experimenting with the presence module (openser v1.2.1). It seems to work really fine. I only encountered a small problem.
When my client unsubscribes from the presence event by sending a SUBSCRIBE request with expires=0, then openser responds with a 200 OK. After the 200 OK, I expect to receive a NOTIFY message, but openser never sends this NOTIFY. It is this NOTIFY that should terminate the subscription dialog through its Subscription-State header set to "terminated".
RFC 3856 states this:
The subscriber can terminate the subscription by sending a SUBSCRIBE, within the dialog, with an Expires header field (which indicates duration of the subscription) value of zero. This causes an immediate termination of the subscription. A NOTIFY request is then generated by the presence agent with the most recent state.
This behavior is based on the general requirements for event handling as defined in RFC 3265.
Is this a bug or is there some configuration stuff that enables/disables the NOTIFY for a SUBSCRIBE with epxpires=0.
A SUBSCRIBE with expires=0 can also arrive as the initial and final SUBSCRIBE for a subscription. In that case it will be fetching the presence information only once. Without the NOTIFY, a fetch does not work.
Cheers, Michel
Hi Anca,
Thanks for your help. I didn't realize the presence module was reorganized. It's working now again.
And openser indeed sends a NOTIFY after a SUBCRIBE with expires = 0. :)
However, the Subscription-State in the NOTIFY is incorrect :( Openser sends this Subscription-State header:
Subscription-State: active;expires=0
RFC 3265 section 3.3.6 states:
Note that the NOTIFY messages triggered by SUBSCRIBE messages with "Expires" headers of 0 will contain a "Subscription-State" value of "terminated", and a "reason" parameter of "timeout".
So I expect the following header:
Subscription-State: terminated;reason=timeout
I hope I am not too much of a pain :)
Cheers, Michel
Anca-Maria Vamanu wrote:
Hello,
There has been a reorganization in the trunk version for the presence modules. You need to load also presence_xml. You have to make the following changes. Insert ' loadmodule "presence_xml.so" '. If you have set force_active , then replace the line modparam("presence", "force_active", 1) with modparam("presence_xml", "force_active", 1). However, the reply is indeed malformed . I will fix that. Thanks.
regards,
Anca Vamanu
Michel de Boer wrote:
Hi,
I just checked out the sources from the trunk. And the presence module does not seem to work anymore :(
On the SUBSCRIBE (Event header set to "presence") I send, I get a 489 Bad Event response. The SUBSCRIBE is exactly the same as the SUBSCRIBE I used with version 1.2.1. There it worked.
Furthermore, the 489 reponse is malformed. The mandatory Allow-Events header is missing.
This is what I see in the error logging:
7(16680) parse_headers: flags=ffffffffffffffff 7(16680) PRESENCE: handle_subscribe:Missing or unsupported event header field value
Regards, Michel
Anca-Maria Vamanu wrote:
Hello,
Indeed the module did not sent Notify messages when unsubscribing. It did, however, sent them when an initial Subscribe with expires 0 was received. I have fixed that in the latest commit. Thanks for reporting.
Best regards,
Anca Vamanu
Michel de Boer wrote:
Hi,
I am currently experimenting with the presence module (openser v1.2.1). It seems to work really fine. I only encountered a small problem.
When my client unsubscribes from the presence event by sending a SUBSCRIBE request with expires=0, then openser responds with a 200 OK. After the 200 OK, I expect to receive a NOTIFY message, but openser never sends this NOTIFY. It is this NOTIFY that should terminate the subscription dialog through its Subscription-State header set to "terminated".
RFC 3856 states this:
The subscriber can terminate the subscription by sending a SUBSCRIBE, within the dialog, with an Expires header field (which indicates duration of the subscription) value of zero. This causes an immediate termination of the subscription. A NOTIFY request is then generated by the presence agent with the most recent state.
This behavior is based on the general requirements for event handling as defined in RFC 3265.
Is this a bug or is there some configuration stuff that enables/disables the NOTIFY for a SUBSCRIBE with epxpires=0.
A SUBSCRIBE with expires=0 can also arrive as the initial and final SUBSCRIBE for a subscription. In that case it will be fetching the presence information only once. Without the NOTIFY, a fetch does not work.
Cheers, Michel
Hello,
I fixed that with the last commit. Thanks for the reports.
regards,
Anca
Michel de Boer wrote:
Hi Anca,
Thanks for your help. I didn't realize the presence module was reorganized. It's working now again.
And openser indeed sends a NOTIFY after a SUBCRIBE with expires = 0. :)
However, the Subscription-State in the NOTIFY is incorrect :( Openser sends this Subscription-State header:
Subscription-State: active;expires=0
RFC 3265 section 3.3.6 states:
Note that the NOTIFY messages triggered by SUBSCRIBE messages with "Expires" headers of 0 will contain a "Subscription-State" value of "terminated", and a "reason" parameter of "timeout".
So I expect the following header:
Subscription-State: terminated;reason=timeout
I hope I am not too much of a pain :)
Cheers, Michel
Anca-Maria Vamanu wrote:
Hello,
There has been a reorganization in the trunk version for the presence modules. You need to load also presence_xml. You have to make the following changes. Insert ' loadmodule "presence_xml.so" '. If you have set force_active , then replace the line modparam("presence", "force_active", 1) with modparam("presence_xml", "force_active", 1). However, the reply is indeed malformed . I will fix that. Thanks.
regards,
Anca Vamanu
Michel de Boer wrote:
Hi,
I just checked out the sources from the trunk. And the presence module does not seem to work anymore :(
On the SUBSCRIBE (Event header set to "presence") I send, I get a 489 Bad Event response. The SUBSCRIBE is exactly the same as the SUBSCRIBE I used with version 1.2.1. There it worked.
Furthermore, the 489 reponse is malformed. The mandatory Allow-Events header is missing.
This is what I see in the error logging:
7(16680) parse_headers: flags=ffffffffffffffff 7(16680) PRESENCE: handle_subscribe:Missing or unsupported event header field value
Regards, Michel
Anca-Maria Vamanu wrote:
Hello,
Indeed the module did not sent Notify messages when unsubscribing. It did, however, sent them when an initial Subscribe with expires 0 was received. I have fixed that in the latest commit. Thanks for reporting.
Best regards,
Anca Vamanu
Michel de Boer wrote:
Hi,
I am currently experimenting with the presence module (openser v1.2.1). It seems to work really fine. I only encountered a small problem.
When my client unsubscribes from the presence event by sending a SUBSCRIBE request with expires=0, then openser responds with a 200 OK. After the 200 OK, I expect to receive a NOTIFY message, but openser never sends this NOTIFY. It is this NOTIFY that should terminate the subscription dialog through its Subscription-State header set to "terminated".
RFC 3856 states this:
The subscriber can terminate the subscription by sending a SUBSCRIBE, within the dialog, with an Expires header field (which indicates duration of the subscription) value of zero. This causes an immediate termination of the subscription. A NOTIFY request is then generated by the presence agent with the most recent state.
This behavior is based on the general requirements for event handling as defined in RFC 3265.
Is this a bug or is there some configuration stuff that enables/disables the NOTIFY for a SUBSCRIBE with epxpires=0.
A SUBSCRIBE with expires=0 can also arrive as the initial and final SUBSCRIBE for a subscription. In that case it will be fetching the presence information only once. Without the NOTIFY, a fetch does not work.
Cheers, Michel
Hi, nice to here that, but is there any documentation about the trunk version beyond the change list?
Regards Klaus
Anca-Maria Vamanu wrote:
Hello,
There has been a reorganization in the trunk version for the presence modules. You need to load also presence_xml. You have to make the following changes. Insert ' loadmodule "presence_xml.so" '. If you have set force_active , then replace the line modparam("presence", "force_active", 1) with modparam("presence_xml", "force_active", 1). However, the reply is indeed malformed . I will fix that. Thanks.
regards,
Anca Vamanu
Michel de Boer wrote:
Hi,
I just checked out the sources from the trunk. And the presence module does not seem to work anymore :(
On the SUBSCRIBE (Event header set to "presence") I send, I get a 489 Bad Event response. The SUBSCRIBE is exactly the same as the SUBSCRIBE I used with version 1.2.1. There it worked.
Furthermore, the 489 reponse is malformed. The mandatory Allow-Events header is missing.
This is what I see in the error logging:
7(16680) parse_headers: flags=ffffffffffffffff 7(16680) PRESENCE: handle_subscribe:Missing or unsupported event header field value
Regards, Michel
Anca-Maria Vamanu wrote:
Hello,
Indeed the module did not sent Notify messages when unsubscribing. It did, however, sent them when an initial Subscribe with expires 0 was received. I have fixed that in the latest commit. Thanks for reporting.
Best regards,
Anca Vamanu
Michel de Boer wrote:
Hi,
I am currently experimenting with the presence module (openser v1.2.1). It seems to work really fine. I only encountered a small problem.
When my client unsubscribes from the presence event by sending a SUBSCRIBE request with expires=0, then openser responds with a 200 OK. After the 200 OK, I expect to receive a NOTIFY message, but openser never sends this NOTIFY. It is this NOTIFY that should terminate the subscription dialog through its Subscription-State header set to "terminated".
RFC 3856 states this:
The subscriber can terminate the subscription by sending a SUBSCRIBE, within the dialog, with an Expires header field (which indicates duration of the subscription) value of zero. This causes an immediate termination of the subscription. A NOTIFY request is then generated by the presence agent with the most recent state.
This behavior is based on the general requirements for event handling as defined in RFC 3265.
Is this a bug or is there some configuration stuff that enables/disables the NOTIFY for a SUBSCRIBE with epxpires=0.
A SUBSCRIBE with expires=0 can also arrive as the initial and final SUBSCRIBE for a subscription. In that case it will be fetching the presence information only once. Without the NOTIFY, a fetch does not work.
Cheers, Michel
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hello,
The documentation for the modules have been appropriately updated, so you can find in the README files info about this reorganization.
regards,
Anca
Klaus Fleischmann wrote:
Hi, nice to here that, but is there any documentation about the trunk version beyond the change list?
Regards Klaus
Anca-Maria Vamanu wrote:
Hello,
There has been a reorganization in the trunk version for the presence modules. You need to load also presence_xml. You have to make the following changes. Insert ' loadmodule "presence_xml.so" '. If you have set force_active , then replace the line modparam("presence", "force_active", 1) with modparam("presence_xml", "force_active", 1). However, the reply is indeed malformed . I will fix that. Thanks.
regards,
Anca Vamanu
Michel de Boer wrote:
Hi,
I just checked out the sources from the trunk. And the presence module does not seem to work anymore :(
On the SUBSCRIBE (Event header set to "presence") I send, I get a 489 Bad Event response. The SUBSCRIBE is exactly the same as the SUBSCRIBE I used with version 1.2.1. There it worked.
Furthermore, the 489 reponse is malformed. The mandatory Allow-Events header is missing.
This is what I see in the error logging:
7(16680) parse_headers: flags=ffffffffffffffff 7(16680) PRESENCE: handle_subscribe:Missing or unsupported event header field value
Regards, Michel
Anca-Maria Vamanu wrote:
Hello,
Indeed the module did not sent Notify messages when unsubscribing. It did, however, sent them when an initial Subscribe with expires 0 was received. I have fixed that in the latest commit. Thanks for reporting.
Best regards,
Anca Vamanu
Michel de Boer wrote:
Hi,
I am currently experimenting with the presence module (openser v1.2.1). It seems to work really fine. I only encountered a small problem.
When my client unsubscribes from the presence event by sending a SUBSCRIBE request with expires=0, then openser responds with a 200 OK. After the 200 OK, I expect to receive a NOTIFY message, but openser never sends this NOTIFY. It is this NOTIFY that should terminate the subscription dialog through its Subscription-State header set to "terminated".
RFC 3856 states this:
The subscriber can terminate the subscription by sending a SUBSCRIBE, within the dialog, with an Expires header field (which indicates duration of the subscription) value of zero. This causes an immediate termination of the subscription. A NOTIFY request is then generated by the presence agent with the most recent state.
This behavior is based on the general requirements for event handling as defined in RFC 3265.
Is this a bug or is there some configuration stuff that enables/disables the NOTIFY for a SUBSCRIBE with epxpires=0.
A SUBSCRIBE with expires=0 can also arrive as the initial and final SUBSCRIBE for a subscription. In that case it will be fetching the presence information only once. Without the NOTIFY, a fetch does not work.
Cheers, Michel
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
-
Anca-Maria Vamanu -
kgfleischmann＠t-online.de -
Michel de Boer