14 Feb
2008
14 Feb
'08
11:22 a.m.
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
14 Feb
14 Feb
12:25 p.m.
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.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
15 Feb
15 Feb
12:46 p.m.
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
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?
Here's a scenario in which this happened again.
The presence of user1(a)domain.com was inserted into the database by an
external process.
user2(a)domain.com subscribes to the presence of user1(a)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(a)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(a)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(a)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(a)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
17 Feb
17 Feb
1:33 a.m.
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.
--
Iñaki Baz Castillo
19 Feb
19 Feb
11:55 a.m.
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
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?
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
1:10 p.m.
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
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?
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(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
1:14 p.m.
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:
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:
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
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?
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(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
5935
days inactive
5940
days old
6 comments
4 participants
participants (4)
-
Anca Vamanu -
Iñaki Baz Castillo -
Iñaki Baz Castillo -
Sigrid Thijs