Hi Anca

Thank you. I will test your bug fixing tomorrow morning and will let you know the results ASAP.

Could you please point out where you found the last NOTIFY should have a body, please ?

Do you have any data to share with me regarding the stability of presence module (memory leak, thread leak, CPU, etc.). Is it stable over time ?

Regards, Pascal

On Nov 13, 2007 3:56 PM, Anca Vamanu anca@voice-system.ro wrote:

Hello,

When dealing with the problem you reported I found that it might be that a body is required in Notifies following an unsubscribe message. I have made the changes to include this and also fixed the problem with the bad status. Please test and provide feedback.

Thanks and regards, Anca Vamanu

Pascal Maugeri wrote:

...

Hi

I'm doing stability testing against presence module and after "several" requests an un-subscribe request (SUBSCRIBE with Expires=0) triggers a NOTIFY with a payload and the following Subscription-State header value:

Subscription-State: active;expires=0

In my humble opinion this is incorrect as the RFC 3265 section says in section 3.3.6:

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".

Ref.: http://tools.ietf.org/html/rfc3265#section-3.3.6

Best regards, Pascal

---

Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users

Hello Pascal,

Pascal Maugeri wrote:

Anca

I've updated my source (svn update of 1.2) and it seems that the problem does not appear anymore: I've run 64 iterations of subscribe and un-subscribe.

Glad to hear that.

I rewrite my questions of yesterday (very interested to hear from you about those):

...

Could you please point out where you found the last NOTIFY should have a body, please ?

As I have mentioned in the commit log, the RFC 3256 does is not very clear whether the Notify with Subscription-State:terminated;reason=timeout , should contain a body(of course, the question is only when the subscription was until then in active state). However, it does mention the possibility to fetch state with an initial Subscription with Expires:0.

3.3.6. Polling Resource State

A natural consequence of the behavior described in the preceding sections is that an immediate fetch without a persistent subscription may be effected by sending a SUBSCRIBE with an "Expires" of 0.

This says that the Notify following a Subscribe with Expires:0 does carry presence info. So, it is sort of like a deduction in the absence of a clear specification.

...

Do you have any data to share with me regarding the stability of presence module (memory leak, thread leak, CPU, etc.). Is it stable over time ?

There is no other problem with the presence modules known to us at this time. The community has given positive feedback of its stability and it has been tested against memory leak.

Thanks to you also, Anca

Once again, many thanks for your fast responses and your help Anca ! -pascal

On Nov 13, 2007 8:46 PM, Pascal Maugeri pascal.maugeri1@gmail.com wrote:

...

Hi Anca

Thank you. I will test your bug fixing tomorrow morning and will let you know the results ASAP.

Could you please point out where you found the last NOTIFY should have a body, please ?

Do you have any data to share with me regarding the stability of presence module (memory leak, thread leak, CPU, etc.). Is it stable over time ?

Regards, Pascal

On Nov 13, 2007 3:56 PM, Anca Vamanu anca@voice-system.ro wrote:

...

Hello,

When dealing with the problem you reported I found that it might be that a body is required in Notifies following an unsubscribe message. I have made the changes to include this and also fixed the problem with the bad status. Please test and provide feedback.

Thanks and regards, Anca Vamanu

Pascal Maugeri wrote:

...

Hi

I'm doing stability testing against presence module and after "several" requests an un-subscribe request (SUBSCRIBE with Expires=0) triggers a NOTIFY with a payload and the following Subscription-State header value:

Subscription-State: active;expires=0

In my humble opinion this is incorrect as the RFC 3265 section says in section 3.3.6:

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".

Ref.: http://tools.ietf.org/html/rfc3265#section-3.3.6

Best regards, Pascal

---

Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users