Hi,
we're testing openser 1.3.0 on a linux server with presence module. I'm using the provided configuration file with the following modifications:
- loaded the modules mysql, presence, presence_xml - set the following parameters for these modules: modparam("presence|presence_xml", "db_url", "mysql://openser:[secret]@localhost/openser") modparam("presence_xml", "force_active", 1) modparam("presence", "server_address", "sip:[ip]:5060") modparam("presence_xml","integrated_xcap_server", 1) - uncommented the code to handle PUBLISH/SUBSCRIBE requests to the presence module
I also configured the mi_datagram module, to receive mi commands.
I discovered the following issues. In the main route block, the second if test checks if the request has a to-tag. If the request does not contain a Route header a 404 Not Here response is sent to the request.
When a client subscribes for presence, a 202 OK response is received from the presence module, without Record-Route(s). This means future in-dialog requests won't contain the Route header. It also means that for example an un-SUBSCRIBE request is rejected with a 404 Not Here. I worked around this by removing the has_totag () check and not sending a 404 Not Here response when loose_route () returns false.
Furthermore I noticed that sometimes, the presence NOTIFY requests do not contain a body. I checked the database, and there was data in the body column in the presentity table for the presence resource. The value in the status column of the watchers/active_watchers table is 1. When I restart openser, the presence descriptions are added to the NOTIFY requests again (the entry in the database did not change).
I have to say that we insert some presence states directly in the database via another process. But this is nothing more than an INSERT or UPDATE statement on the presentity table.
Do you have any idea why a NOTIFY without body is sent? Do i need to configure something extra? And why does it seem to work after openser has restarted?
kind regards,
Sigrid
El Thursday 14 February 2008 11:22:54 Sigrid Thijs escribió:
When a client subscribes for presence, a 202 OK response is received from the presence module, without Record-Route(s). This means future in-dialog requests won't contain the Route header. It also means that for example an un-SUBSCRIBE request is rejected with a 404 Not Here. I worked around this by removing the has_totag () check and not sending a 404 Not Here response when loose_route () returns false
You could test if the method is SUBSCRIBE in order to avoid the "has_totag()".
Anyway this could be done in the default openser.cfg script.
Sigrid Thijs wrote:
Hi,
we're testing openser 1.3.0 on a linux server with presence module. I'm using the provided configuration file with the following modifications:
- loaded the modules mysql, presence, presence_xml
- set the following parameters for these modules: modparam("presence|presence_xml", "db_url", "mysql://openser:[secret]@localhost/openser") modparam("presence_xml", "force_active", 1) modparam("presence", "server_address", "sip:[ip]:5060") modparam("presence_xml","integrated_xcap_server", 1)
- uncommented the code to handle PUBLISH/SUBSCRIBE requests to the
presence module
...
Furthermore I noticed that sometimes, the presence NOTIFY requests do not contain a body. I checked the database, and there was data in the body column in the presentity table for the presence resource. The value in the status column of the watchers/active_watchers table is
- When I restart openser, the presence descriptions are added to the
NOTIFY requests again (the entry in the database did not change).
I have to say that we insert some presence states directly in the database via another process. But this is nothing more than an INSERT or UPDATE statement on the presentity table.
Do you have any idea why a NOTIFY without body is sent? Do i need to configure something extra? And why does it seem to work after openser has restarted?
Here's a scenario in which this happened again. The presence of user1@domain.com was inserted into the database by an external process.
user2@domain.com subscribes to the presence of user1@domain.com. A 202 OK to the SUBSCRIBE request is received, followed by a NOTIFY without a body in the NOTIFY request.
I checked the tables in the database: - there's an entry for user1@domain.com in the presentity table (with the presence description in the body column):
| 21 | user1 | domain.com | presence | w.1203078663.80 | 1203078963 | 1203078663 | <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:ep="urn:ietf:params:xml:ns:pidf:status:rpid-status" xmlns:et="urn:ietf:params:xml:ns:pidf:rpid-tuple" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" entity="user1"> <tuple id="446678912"> <status> <basic>open</basic> </status> </tuple> </presence> |
- the watchers table contains the following entry: | 12 | sip:user1@domain.com | user2 | domain.com | presence | 1 | NULL | 1203078715 |
- the active_watchers table does not contain an entry for presentity_uri 'sip:user1@domain.com'
After a while (a few minutes ?), the active_watchers table *does* contain an entry for the presentity_uri:
| 23 | sip:user1@domain.com | user2 | domain.com | user1 | domain.com | presence | | 10.31030.1203078715.1 | 3757768384 | 1688817425@172.17.10.21 | 1 | 1 | sip:user1@172.17.10.21:5061 | | 1203082315 | 1 | | 1 | udp:172.17.10.86:5070 | sip:172.17.10.86:5070 |
When the client un-SUBSCRIBEs from the presence of user1@domain.com, and subscribes again, the NOTIFY still does not contain a body.
When I restart openser, and the client SUBSCRIBES to the presence of user1@domain.com, the NOTIFY does contain a body.
I guess it has something to do with openser not knowing that the entry has been added to the database. Is there some configuration option or mi command I can use to resolve this behavior?
kind regards,
Sigrid
El Jueves, 14 de Febrero de 2008, Sigrid Thijs escribió:
Furthermore I noticed that sometimes, the presence NOTIFY requests do not contain a body. [...] Do you have any idea why a NOTIFY without body is sent?
RFC 3265:
3.1.6. Notifier SUBSCRIBE Behavior
3.1.6.1. Initial SUBSCRIBE Transaction Processing [...] If the notifier cannot immediately create the subscription (e.g., it needs to wait for user input for authorization, or is acting for another node which is not currently reachable), or wishes to mask authorization policy, it will return a "202 Accepted" response. This response indicates that the request has been received and understood, but does not necessarily imply that the subscription has been authorized yet.
3.1.6.2. Confirmation of Subscription Creation/Refreshing [...] Upon successfully accepting or refreshing a subscription, notifiers MUST send a NOTIFY message immediately to communicate the current resource state to the subscriber. This NOTIFY message is sent on the same dialog as created by the SUBSCRIBE response. 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. See section 3.2.2. for further details on NOTIFY message generation.
Sigrid Thijs wrote:
Furthermore I noticed that sometimes, the presence NOTIFY requests do not contain a body. I checked the database, and there was data in the body column in the presentity table for the presence resource. The value in the status column of the watchers/active_watchers table is
- When I restart openser, the presence descriptions are added to the
NOTIFY requests again (the entry in the database did not change).
I have to say that we insert some presence states directly in the database via another process. But this is nothing more than an INSERT or UPDATE statement on the presentity table.
Do you have any idea why a NOTIFY without body is sent? Do i need to configure something extra? And why does it seem to work after openser has restarted?
Apparently there's a configuration option "fallback2db" in the presence module. When I set this value to 1, the problem is solved.
kind regards,
Sigrid
Hi Sigrid,
First, a Notify with no body is sent in two cases: 1. the status of the subscription is 'pending' or 'rejected' 2. the server has no published information made by the user the subscription is addressed to (for example, if a user subscribes to 5, from which only one is registered at the time, he will receive Notifies with no body for the other four ) .
Second, the presence server works by default in a cache mode with periodical updated in database. If a fallback to database is desired for any storing or querying operation, then the "fallback2db" parameter should be set. It useful only in the case of using more presence servers that share the same database. In this situation it is possible not to have a required info in cache, but it might have been processed by another server and might be present in database. I think it is a wrong observation that there are no more Notifies with no body if this parameter is set. The real determinant factor is whether the buddies have issued a Publish before the Subscription arrives at the server. But, if you do see a record in 'presentity' table for a user and a corresponding Notify, having in its From header the uri of the presentity, with no body, then there might be a bug there. I have to mention that I have tested this scenario right now and it works for me.
Regards, Anca Vamanu
Sigrid Thijs wrote:
Sigrid Thijs wrote:
Furthermore I noticed that sometimes, the presence NOTIFY requests do not contain a body. I checked the database, and there was data in the body column in the presentity table for the presence resource. The value in the status column of the watchers/active_watchers table is
- When I restart openser, the presence descriptions are added to the
NOTIFY requests again (the entry in the database did not change).
I have to say that we insert some presence states directly in the database via another process. But this is nothing more than an INSERT or UPDATE statement on the presentity table.
Do you have any idea why a NOTIFY without body is sent? Do i need to configure something extra? And why does it seem to work after openser has restarted?
Apparently there's a configuration option "fallback2db" in the presence module. When I set this value to 1, the problem is solved.
kind regards,
Sigrid
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
I have now read your previous comment. It is clear that if you use anther process to modify the content of database, you should set the 'fal;back2db' parameter to 1 to make this effective in real time. please see the documentation here: http://www.openser.org/docs/modules/1.3.x/presence.html
Anca Vamanu wrote:
Hi Sigrid,
First, a Notify with no body is sent in two cases:
- the status of the subscription is 'pending' or 'rejected'
- the server has no published information made by the user the
subscription is addressed to (for example, if a user subscribes to 5, from which only one is registered at the time, he will receive Notifies with no body for the other four ) .
Second, the presence server works by default in a cache mode with periodical updated in database. If a fallback to database is desired for any storing or querying operation, then the "fallback2db" parameter should be set. It useful only in the case of using more presence servers that share the same database. In this situation it is possible not to have a required info in cache, but it might have been processed by another server and might be present in database. I think it is a wrong observation that there are no more Notifies with no body if this parameter is set. The real determinant factor is whether the buddies have issued a Publish before the Subscription arrives at the server. But, if you do see a record in 'presentity' table for a user and a corresponding Notify, having in its From header the uri of the presentity, with no body, then there might be a bug there. I have to mention that I have tested this scenario right now and it works for me.
Regards, Anca Vamanu
Sigrid Thijs wrote:
Sigrid Thijs wrote:
Furthermore I noticed that sometimes, the presence NOTIFY requests do not contain a body. I checked the database, and there was data in the body column in the presentity table for the presence resource. The value in the status column of the watchers/active_watchers table is
- When I restart openser, the presence descriptions are added to the
NOTIFY requests again (the entry in the database did not change).
I have to say that we insert some presence states directly in the database via another process. But this is nothing more than an INSERT or UPDATE statement on the presentity table.
Do you have any idea why a NOTIFY without body is sent? Do i need to configure something extra? And why does it seem to work after openser has restarted?
Apparently there's a configuration option "fallback2db" in the presence module. When I set this value to 1, the problem is solved.
kind regards,
Sigrid
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
-
Anca Vamanu -
Iñaki Baz Castillo -
Iñaki Baz Castillo -
Sigrid Thijs