Hi all,
I am stuck with a presence authorization problem using openSer 1.3 and openXcap 0.9.9. I have read some similar posts in the mailing list but I couldn't find a solution, so I'll try to explain my scenario to see if it is my mistake or it is a bug.
I explain the scenario: User test1 and test2 successfully register and sunscribe to presence.winfo. Both receive a NOTIFY informing that their winfo subscriptions are active.
Test2 adds test1 as a contact so he subscribes to test1's presence, then test1 receives a winfo NOTIFY requesting authorization for test2. Test1 does it sending a XCAP document to openXcap the document is correctly stored in openSer xcap table.
User test2 receives a presence NOTIFY in pending state, even if user test1 publishes other presence state, the subscription state of test2 remains pending forever.
If we look the data base in that moment:
+------+--------------------------+------------------+----------------+---------+----------------+----------------+----------+----------------------+---------------+--------------------------------------+------------+-------------+-------------------+--------------+------------+--------+--------+---------+------------------------+------------------------+ | id | presentity_uri | watcher_username | watcher_domain | to_user | to_domain | event | event_id | to_tag | from_tag | callid | local_cseq | remote_cseq | contact | record_route | expires | status | reason | version | socket_info | local_contact | +------+--------------------------+------------------+----------------+---------+----------------+----------------+----------+----------------------+---------------+--------------------------------------+------------+-------------+-------------------+--------------+------------+--------+--------+---------+------------------------+------------------------+ | 1177 | sip:test2@Mydomain | test2 | Mydomain | test2 | Mydomain | presence.winfo | NULL | 10.2670.1209516359.7 | cvvUDerBXK1Qc | b4c2997e-64ac-122b-2780-39a48cb53b8d | 1 | 96206117 | sip:192.168.1.222 | NULL | 1209519959 | 1 | | 1 | udp:192.168.1.210:5060 | sip:192.168.1.210:5060 | +------+--------------------------+------------------+----------------+---------+----------------+----------------+----------+----------------------+---------------+--------------------------------------+------------+-------------+-------------------+--------------+------------+--------+--------+---------+------------------------+------------------------+
WATCHERS +----+--------------------------+------------------+----------------+----------+--------+--------+---------------+ | id | presentity_uri | watcher_username | watcher_domain | event | status | reason | inserted_time | +----+--------------------------+------------------+----------------+----------+--------+--------+---------------+ | 80 | sip:test1@Mydomain | test2 | Mydomain | presence | 2 | NULL | 1209516407 | +----+--------------------------+------------------+----------------+----------+--------+--------+---------------+
XCAP +-----+----------+----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+----------------------------------+--------+-------------+------+ | id | username | domain | doc | doc_type | etag | source | doc_uri | port | +-----+----------+----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+----------------------------------+--------+-------------+------+ | 190 | test2 | Mydomain | <?xml version="1.0" encoding="UTF-8"?> <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"><list name="Users"><entry uri="sip:test1@Mydomain"><display-name>test1</display-name></entry></list></resource-lists>
| 4 | 8ea82eeb40e00fcf626dbe17d1961ad5 | 0 | buddies.xml | 0 | | 191 | test2 | Mydomain | <?xml version='1.0' encoding='UTF-8'?><ruleset xmlns='urn:ietf:params:xml:ns:common-policy' xmlns:pr='urn:ietf:params:xml:ns:pres-rules'><rule id='whitelist'><conditions><identity></identity></conditions><actions>pr:sub-handlingallow</pr:sub-handling></actions></rule><rule id='politeblocklist'><conditions><identity></identity></conditions><actions>pr:sub-handlingpolite-block</pr:sub-handling></actions></rule><rule id='blacklist'><conditions><identity></identity></conditions><actions>pr:sub-handlingblock</pr:sub-handling></actions></rule></ruleset> | 2 | 46353b3b55d23d24fd4d9c87a5ff7ba4 | 0 | index.xml | 0 | | 192 | test1 | Mydomain | <?xml version='1.0' encoding='UTF-8'?><resource-lists xmlns='urn:ietf:params:xml:ns:resource-lists'><list name='Users'></list></resource-lists> | 4 | f854971d48ed1a8913e20b3409a6b723 | 0 | buddies.xml | 0 | | 193 | test1 | Mydomain | <?xml version="1.0" encoding="UTF-8"?> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy" xmlns:pr="urn:ietf:params:xml:ns:pres-rules"><rule id="whitelist"><conditions><identity><one id="sip:test2@Mydomain"/></identity></conditions><actions>pr:sub-handlingallow</pr:sub-handling></actions></rule><rule id="politeblocklist"><conditions/><actions>pr:sub-handlingpolite-block</pr:sub-handling></actions></rule><rule id="blacklist"><conditions/><actions>pr:sub-handlingblock</pr:sub-handling></actions></rule></ruleset> | 2 | 8afbf7f0464de1273303bbea554404ff | 0 | index.xml | 0 | +-----+----------+----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+----------------------------------+--------+-------------+------+
We can see in 'WATCHERS' table that test2 has a pending presence subscription but as can be seen in 'XCAP' table user test1 has authorized test2 to see his presence.
My thinking is that once test1 changes his authorization rule, the presence subscription should chage to active, am I right?
My conclusion is that something between the presence rules authorization and the subscriptions is not working fine, or I did something wrong and I haven't noticed it. Please, I really need help with that as I have been stuck here for weeks.
Thanks in advance!! Gregorio
Hi,
I think you might be right about the problem source. The real time update in OpenSER is triggered by OpenXCAP with an mi command: "mi_refreshWatchers". You could set the 'debug' in config file to 7 and search in the log for 'mi_refreshWatchers' string and send the debug messages printed while processing.
regards, Anca Vamanu
greg.co wrote:
Hi all,
I am stuck with a presence authorization problem using openSer 1.3 and openXcap 0.9.9. I have read some similar posts in the mailing list but I couldn't find a solution, so I'll try to explain my scenario to see if it is my mistake or it is a bug.
I explain the scenario: User test1 and test2 successfully register and sunscribe to presence.winfo. Both receive a NOTIFY informing that their winfo subscriptions are active.
Test2 adds test1 as a contact so he subscribes to test1's presence, then test1 receives a winfo NOTIFY requesting authorization for test2. Test1 does it sending a XCAP document to openXcap the document is correctly stored in openSer xcap table.
User test2 receives a presence NOTIFY in pending state, even if user test1 publishes other presence state, the subscription state of test2 remains pending forever.
If we look the data base in that moment:
+------+--------------------------+------------------+----------------+---------+----------------+----------------+----------+----------------------+---------------+--------------------------------------+------------+-------------+-------------------+--------------+------------+--------+--------+---------+------------------------+------------------------+ | id | presentity_uri | watcher_username | watcher_domain | to_user | to_domain | event | event_id | to_tag | from_tag | callid | local_cseq | remote_cseq | contact | record_route | expires | status | reason | version | socket_info | local_contact | +------+--------------------------+------------------+----------------+---------+----------------+----------------+----------+----------------------+---------------+--------------------------------------+------------+-------------+-------------------+--------------+------------+--------+--------+---------+------------------------+------------------------+ | 1177 | sip:test2@Mydomain | test2 | Mydomain | test2 | Mydomain | presence.winfo | NULL | 10.2670.1209516359.7 | cvvUDerBXK1Qc | b4c2997e-64ac-122b-2780-39a48cb53b8d | 1 | 96206117 | sip:192.168.1.222 | NULL | 1209519959 | 1 | | 1 | udp:192.168.1.210:5060 | sip:192.168.1.210:5060 | +------+--------------------------+------------------+----------------+---------+----------------+----------------+----------+----------------------+---------------+--------------------------------------+------------+-------------+-------------------+--------------+------------+--------+--------+---------+------------------------+------------------------+
WATCHERS +----+--------------------------+------------------+----------------+----------+--------+--------+---------------+ | id | presentity_uri | watcher_username | watcher_domain | event | status | reason | inserted_time | +----+--------------------------+------------------+----------------+----------+--------+--------+---------------+ | 80 | sip:test1@Mydomain | test2 | Mydomain | presence | 2 | NULL | 1209516407 | +----+--------------------------+------------------+----------------+----------+--------+--------+---------------+
XCAP +-----+----------+----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+----------------------------------+--------+-------------+------+ | id | username | domain | doc | doc_type | etag | source | doc_uri | port | +-----+----------+----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+----------------------------------+--------+-------------+------+ | 190 | test2 | Mydomain | <?xml version="1.0" encoding="UTF-8"?> <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"><list name="Users"><entry uri="sip:test1@Mydomain"><display-name>test1</display-name></entry></list></resource-lists>
| 4 | 8ea82eeb40e00fcf626dbe17d1961ad5 | 0 | buddies.xml | 0 | | 191 | test2 | Mydomain | <?xml version='1.0' encoding='UTF-8'?><ruleset xmlns='urn:ietf:params:xml:ns:common-policy' xmlns:pr='urn:ietf:params:xml:ns:pres-rules'><rule id='whitelist'><conditions><identity></identity></conditions><actions>pr:sub-handlingallow</pr:sub-handling></actions></rule><rule id='politeblocklist'><conditions><identity></identity></conditions><actions>pr:sub-handlingpolite-block</pr:sub-handling></actions></rule><rule id='blacklist'><conditions><identity></identity></conditions><actions>pr:sub-handlingblock</pr:sub-handling></actions></rule></ruleset> | 2 | 46353b3b55d23d24fd4d9c87a5ff7ba4 | 0 | index.xml | 0 | | 192 | test1 | Mydomain | <?xml version='1.0' encoding='UTF-8'?><resource-lists xmlns='urn:ietf:params:xml:ns:resource-lists'><list name='Users'></list></resource-lists> | 4 | f854971d48ed1a8913e20b3409a6b723 | 0 | buddies.xml | 0 | | 193 | test1 | Mydomain | <?xml version="1.0" encoding="UTF-8"?> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy" xmlns:pr="urn:ietf:params:xml:ns:pres-rules"><rule id="whitelist"><conditions><identity><one id="sip:test2@Mydomain"/></identity></conditions><actions>pr:sub-handlingallow</pr:sub-handling></actions></rule><rule id="politeblocklist"><conditions/><actions>pr:sub-handlingpolite-block</pr:sub-handling></actions></rule><rule id="blacklist"><conditions/><actions>pr:sub-handlingblock</pr:sub-handling></actions></rule></ruleset> | 2 | 8afbf7f0464de1273303bbea554404ff | 0 | index.xml | 0 | +-----+----------+----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+----------------------------------+--------+-------------+------+
We can see in 'WATCHERS' table that test2 has a pending presence subscription but as can be seen in 'XCAP' table user test1 has authorized test2 to see his presence.
My thinking is that once test1 changes his authorization rule, the presence subscription should chage to active, am I right?
My conclusion is that something between the presence rules authorization and the subscriptions is not working fine, or I did something wrong and I haven't noticed it. Please, I really need help with that as I have been stuck here for weeks.
Thanks in advance!! Gregorio
Hi Anca et all,
I have repeated the same test described in the first name with the debug level set to 7 and I couldn't find the string 'mi_refreshWatchers' in the debbug messages. I can't attach the debug messages file because it is too large. I am using OpenSer 1.3 and openXcap 0.99. My configuration related to presence is this:
modparam("presence|usrloc", "db_url","mysql://openser:password@127.0.0.1/openser") modparam("presence", "presentity_table", "presentity") modparam("presence", "active_watchers_table", "active_watchers") modparam("presence", "watchers_table", "watchers") modparam("presence", "clean_period", 100) modparam("presence", "max_expires", 3600) modparam("presence", "server_address", "sip:192.168.1.210:5060") modparam("presence", "fallback2db", 1)
#MI_XMLRPC modparam("mi_xmlrpc", "log_file", "/var/log/openser-xmlrpc.log") modparam("mi_xmlrpc", "port", 8080)
modparam("pua", "db_url", "mysql://openser:password@127.0.0.1/openser")
# -- xcap params -- modparam("presence_xml", "db_url", "mysql://openser:password@127.0.0.1/openser") modparam("presence_xml", "force_active", 0) #0 Activates permissions for subscriptions modparam("presence_xml", "xcap_table", "xcap") modparam("presence_xml", "integrated_xcap_server", 1)
If someone needs the debug messages I can send it to personal mail accounts, and thank you very much for helping. Regards, Gregorio.
-----Mensaje original----- De: users-bounces@lists.openser.org [mailto:users-bounces@lists.openser.org] En nombre de Anca Vamanu Enviado el: jueves, 06 de marzo de 2008 10:34 Para: greg.co CC: users@lists.openser.org Asunto: Re: [OpenSER-Users] OpenSER + OpenXcap for pres-rules: no NOTIFY
Hi,
I think you might be right about the problem source. The real time update in OpenSER is triggered by OpenXCAP with an mi command: "mi_refreshWatchers". You could set the 'debug' in config file to 7 and search in the log for 'mi_refreshWatchers' string and send the debug messages printed while processing.
regards, Anca Vamanu
greg.co wrote:
Hi all,
I am stuck with a presence authorization problem using openSer 1.3 and openXcap 0.9.9. I have read some similar posts in the mailing list but I couldn't find a solution, so I'll try to explain my scenario to see if it
is
my mistake or it is a bug.
I explain the scenario: User test1 and test2 successfully register and sunscribe to
presence.winfo.
Both receive a NOTIFY informing that their winfo subscriptions are active.
Test2 adds test1 as a contact so he subscribes to test1's presence, then test1 receives a winfo NOTIFY requesting authorization for test2. Test1
does
it sending a XCAP document to openXcap the document is correctly stored in openSer xcap table.
User test2 receives a presence NOTIFY in pending state, even if user test1 publishes other presence state, the subscription state of test2 remains pending forever.
If we look the data base in that moment:
+------+--------------------------+------------------+----------------+----- ----+----------------+----------------+----------+----------------------+--- ------------+--------------------------------------+------------+----------- --+-------------------+--------------+------------+--------+--------+------- --+------------------------+------------------------+
| id | presentity_uri | watcher_username | watcher_domain | to_user | to_domain | event | event_id | to_tag
| from_tag | callid | local_cseq | remote_cseq | contact | record_route | expires | status | reason | version | socket_info | local_contact |
+------+--------------------------+------------------+----------------+----- ----+----------------+----------------+----------+----------------------+--- ------------+--------------------------------------+------------+----------- --+-------------------+--------------+------------+--------+--------+------- --+------------------------+------------------------+
| 1177 | sip:test2@Mydomain | test2 | Mydomain |
test2
| Mydomain | presence.winfo | NULL | 10.2670.1209516359.7 | cvvUDerBXK1Qc | b4c2997e-64ac-122b-2780-39a48cb53b8d | 1 | 96206117 | sip:192.168.1.222 | NULL | 1209519959 | 1 |
|
1 | udp:192.168.1.210:5060 | sip:192.168.1.210:5060 |
+------+--------------------------+------------------+----------------+----- ----+----------------+----------------+----------+----------------------+--- ------------+--------------------------------------+------------+----------- --+-------------------+--------------+------------+--------+--------+------- --+------------------------+------------------------+
WATCHERS
+----+--------------------------+------------------+----------------+------- ---+--------+--------+---------------+
| id | presentity_uri | watcher_username | watcher_domain |
event
| status | reason | inserted_time |
+----+--------------------------+------------------+----------------+------- ---+--------+--------+---------------+
| 80 | sip:test1@Mydomain | test2 | Mydomain | presence | 2 | NULL | 1209516407 |
+----+--------------------------+------------------+----------------+------- ---+--------+--------+---------------+
XCAP
+-----+----------+----------------+----------------------------------------- ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ------------------------------------------------------------------+--------- -+----------------------------------+--------+-------------+------+
| id | username | domain | doc
| doc_type | etag | source | doc_uri |
port
|
+-----+----------+----------------+----------------------------------------- ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ------------------------------------------------------------------+--------- -+----------------------------------+--------+-------------+------+
| 190 | test2 | Mydomain | <?xml version="1.0" encoding="UTF-8"?> <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"><list name="Users"><entry
uri="sip:test1@Mydomain"><display-name>test1</display-name></entry></list></ resource-lists>
| 4 | 8ea82eeb40e00fcf626dbe17d1961ad5 | 0 | buddies.xml |
0
| | 191 | test2 | Mydomain | <?xml version='1.0'
encoding='UTF-8'?><ruleset
xmlns='urn:ietf:params:xml:ns:common-policy' xmlns:pr='urn:ietf:params:xml:ns:pres-rules'><rule
id='whitelist'><conditions><identity></identity></conditions><actions>pr:su b-handlingallow</pr:sub-handling></actions></rule><rule
id='politeblocklist'><conditions><identity></identity></conditions><actions> pr:sub-handlingpolite-block</pr:sub-handling></actions></rule><rule
id='blacklist'><conditions><identity></identity></conditions><actions>pr:su b-handlingblock</pr:sub-handling></actions></rule></ruleset>
| 2 | 46353b3b55d23d24fd4d9c87a5ff7ba4 | 0 | index.xml |
0
| | 192 | test1 | Mydomain | <?xml version='1.0' encoding='UTF-8'?><resource-lists xmlns='urn:ietf:params:xml:ns:resource-lists'><list name='Users'></list></resource-lists>
| 4 | f854971d48ed1a8913e20b3409a6b723 | 0 | buddies.xml |
0
| | 193 | test1 | Mydomain | <?xml version="1.0" encoding="UTF-8"?> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy" xmlns:pr="urn:ietf:params:xml:ns:pres-rules"><rule id="whitelist"><conditions><identity><one
id="sip:test2@Mydomain"/></identity></conditions><actions>pr:sub-handlinga llow</pr:sub-handling></actions></rule><rule
id="politeblocklist"><conditions/><actions>pr:sub-handlingpolite-block</pr :sub-handling></actions></rule><rule
id="blacklist"><conditions/><actions>pr:sub-handlingblock</pr:sub-handling
</actions></rule></ruleset> | 2 | 8afbf7f0464de1273303bbea554404ff
|
0 | index.xml | 0 |
+-----+----------+----------------+----------------------------------------- ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ------------------------------------------------------------------+--------- -+----------------------------------+--------+-------------+------+
We can see in 'WATCHERS' table that test2 has a pending presence subscription but as can be seen in 'XCAP' table user test1 has authorized test2 to see his presence.
My thinking is that once test1 changes his authorization rule, the
presence
subscription should chage to active, am I right?
My conclusion is that something between the presence rules authorization
and
the subscriptions is not working fine, or I did something wrong and I haven't noticed it. Please, I really need help with that as I have been stuck here for weeks.
Thanks in advance!! Gregorio
_______________________________________________ Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
-
Anca Vamanu -
greg.co -
Gregorio