Hi,
we've configured OpenSER 1.3.0 on a FreeBSD server, together with OpenXCAP 0.9.9. When testing presence rules (RFC 5025) with our UA, we noticed the following behavior:
- Subscription Handling is set to "block" in the presence rules: When a watcher subscribes for presence, it receives a NOTIFY with the Subscription-State set to "terminated;reason=rejected". This is as expected. When the presentity changes it's presence, the watcher doesn't receive any NOTIFY requests with the presence update (also OK). But, when the presentity changes the subscription handling to "allow" in the presence-rules document, the server sends an in-dialog NOTIFY request on the subscription dialog that was previously terminated. This is not ok. See the attached file presence_rules_01.txt.
- Subscription Handling is set to "allow" in the presence rules: When the presentity changes the subscription handling to "block" in the presence-rules document, the server sends a NOTIFY with the Subscription-State set to "terminated;reason=timeout" to the watchers. When the presentity changes his presence, the presence server will still send NOTIFY requests to the watchers. See the attached file presence_rules_02.txt.
kind regards,
Sigrid
2008/04/14 12:10:11.167,trace,1352,sip,"sending message to 172.17.10.53:5060" 2008/04/14 12:10:11.167,trace,1352,sip,"----------------------------------------------------------------" 2008/04/14 12:10:11.167,trace,1352,sip,"SUBSCRIBE sip:test03@domain.com SIP/2.0" 2008/04/14 12:10:11.167,trace,1352,sip,"Via: SIP/2.0/UDP 172.17.10.18:5061;rport;branch=z9hG4bK1123400681" 2008/04/14 12:10:11.167,trace,1352,sip,"From: sip:test04@domain.com;tag=619180932" 2008/04/14 12:10:11.167,trace,1352,sip,"To: sip:test03@domain.com" 2008/04/14 12:10:11.167,trace,1352,sip,"Call-ID: 171821901@172.17.10.18" 2008/04/14 12:10:11.167,trace,1352,sip,"CSeq: 1 SUBSCRIBE" 2008/04/14 12:10:11.167,trace,1352,sip,"Contact: sip:test04@172.17.10.18:5061" 2008/04/14 12:10:11.167,trace,1352,sip,"Max-Forwards: 70" 2008/04/14 12:10:11.167,trace,1352,sip,"User-Agent: Intellivic SDK/4.1.0.401" 2008/04/14 12:10:11.167,trace,1352,sip,"Expires: 3600" 2008/04/14 12:10:11.167,trace,1352,sip,"Event: presence" 2008/04/14 12:10:11.167,trace,1352,sip,"Accept: application/cpim-pidf+xml, application/pidf+xml, application/xpidf+xml" 2008/04/14 12:10:11.167,trace,1352,sip,"Content-Length: 0" 2008/04/14 12:10:11.167,trace,1352,sip,"" 2008/04/14 12:10:11.167,trace,1352,sip,"" 2008/04/14 12:10:11.167,trace,1352,sip,"----------------------------------------------------------------"
2008/04/14 12:10:11.167,trace,2004,sip,"received message from 172.17.10.53:5060" 2008/04/14 12:10:11.167,trace,2004,sip,"----------------------------------------------------------------" 2008/04/14 12:10:11.167,trace,2004,sip,"SIP/2.0 202 OK" 2008/04/14 12:10:11.167,trace,2004,sip,"Via: SIP/2.0/UDP 172.17.10.18:5061;rport;branch=z9hG4bK1123400681" 2008/04/14 12:10:11.167,trace,2004,sip,"From: sip:test04@domain.com;tag=619180932" 2008/04/14 12:10:11.167,trace,2004,sip,"To: sip:test03@domain.com;tag=10.74166.1208167811.54" 2008/04/14 12:10:11.167,trace,2004,sip,"Call-ID: 171821901@172.17.10.18" 2008/04/14 12:10:11.167,trace,2004,sip,"CSeq: 1 SUBSCRIBE" 2008/04/14 12:10:11.167,trace,2004,sip,"Expires: 3600" 2008/04/14 12:10:11.167,trace,2004,sip,"Contact: sip:172.17.10.53:5060" 2008/04/14 12:10:11.167,trace,2004,sip,"Server: OpenSER (1.3.0-tls (i386/freebsd))" 2008/04/14 12:10:11.167,trace,2004,sip,"Content-Length: 0" 2008/04/14 12:10:11.167,trace,2004,sip,"" 2008/04/14 12:10:11.167,trace,2004,sip,"" 2008/04/14 12:10:11.167,trace,2004,sip,"----------------------------------------------------------------"
2008/04/14 12:10:11.167,trace,2004,sip,"received message from 172.17.10.53:5060" 2008/04/14 12:10:11.167,trace,2004,sip,"----------------------------------------------------------------" 2008/04/14 12:10:11.167,trace,2004,sip,"NOTIFY sip:test04@172.17.10.18:5061 SIP/2.0" 2008/04/14 12:10:11.167,trace,2004,sip,"Via: SIP/2.0/UDP 172.17.10.53:5060;branch=z9hG4bKf06f.1f19a641.0" 2008/04/14 12:10:11.167,trace,2004,sip,"To: sip:test04@domain.com;tag=619180932" 2008/04/14 12:10:11.167,trace,2004,sip,"From: sip:test03@domain.com;tag=10.74166.1208167811.54" 2008/04/14 12:10:11.167,trace,2004,sip,"CSeq: 1 NOTIFY" 2008/04/14 12:10:11.167,trace,2004,sip,"Call-ID: 171821901@172.17.10.18" 2008/04/14 12:10:11.177,trace,2004,sip,"Content-Length: 0" 2008/04/14 12:10:11.177,trace,2004,sip,"User-Agent: OpenSER (1.3.0-tls (i386/freebsd))" 2008/04/14 12:10:11.177,trace,2004,sip,"Max-Forwards: 70" 2008/04/14 12:10:11.177,trace,2004,sip,"Event: presence" 2008/04/14 12:10:11.177,trace,2004,sip,"Contact: sip:172.17.10.53:5060" 2008/04/14 12:10:11.177,trace,2004,sip,"Subscription-State: terminated;reason=rejected" 2008/04/14 12:10:11.177,trace,2004,sip,"" 2008/04/14 12:10:11.177,trace,2004,sip,"" 2008/04/14 12:10:11.177,trace,2004,sip,"----------------------------------------------------------------"
2008/04/14 12:10:11.267,trace,1352,sip,"sending message to 172.17.10.53:5060" 2008/04/14 12:10:11.267,trace,1352,sip,"----------------------------------------------------------------" 2008/04/14 12:10:11.267,trace,1352,sip,"SIP/2.0 200 OK" 2008/04/14 12:10:11.267,trace,1352,sip,"Via: SIP/2.0/UDP 172.17.10.53:5060;branch=z9hG4bKf06f.1f19a641.0" 2008/04/14 12:10:11.267,trace,1352,sip,"From: sip:test03@domain.com;tag=10.74166.1208167811.54" 2008/04/14 12:10:11.267,trace,1352,sip,"To: sip:test04@domain.com;tag=619180932" 2008/04/14 12:10:11.267,trace,1352,sip,"Call-ID: 171821901@172.17.10.18" 2008/04/14 12:10:11.267,trace,1352,sip,"CSeq: 1 NOTIFY" 2008/04/14 12:10:11.267,trace,1352,sip,"Content-Length: 0" 2008/04/14 12:10:11.267,trace,1352,sip,"" 2008/04/14 12:10:11.267,trace,1352,sip,"" 2008/04/14 12:10:11.267,trace,1352,sip,"----------------------------------------------------------------"
2008/04/14 12:12:41.413,trace,2004,sip,"received message from 172.17.10.53:5060" 2008/04/14 12:12:41.413,trace,2004,sip,"----------------------------------------------------------------" 2008/04/14 12:12:41.413,trace,2004,sip,"NOTIFY sip:test04@172.17.10.18:5061 SIP/2.0" 2008/04/14 12:12:41.413,trace,2004,sip,"Via: SIP/2.0/UDP 172.17.10.53:5060;branch=z9hG4bKc06f.00085e42.0" 2008/04/14 12:12:41.413,trace,2004,sip,"To: sip:test04@domain.com;tag=619180932" 2008/04/14 12:12:41.413,trace,2004,sip,"From: sip:test03@domain.com;tag=10.74166.1208167811.54" 2008/04/14 12:12:41.413,trace,2004,sip,"CSeq: 2 NOTIFY" 2008/04/14 12:12:41.413,trace,2004,sip,"Call-ID: 171821901@172.17.10.18" 2008/04/14 12:12:41.413,trace,2004,sip,"Content-Length: 434" 2008/04/14 12:12:41.413,trace,2004,sip,"User-Agent: OpenSER (1.3.0-tls (i386/freebsd))" 2008/04/14 12:12:41.413,trace,2004,sip,"Max-Forwards: 70" 2008/04/14 12:12:41.413,trace,2004,sip,"Event: presence" 2008/04/14 12:12:41.413,trace,2004,sip,"Contact: sip:172.17.10.53:5060" 2008/04/14 12:12:41.413,trace,2004,sip,"Subscription-State: active;expires=3450" 2008/04/14 12:12:41.413,trace,2004,sip,"Content-Type: application/pidf+xml" 2008/04/14 12:12:41.413,trace,2004,sip,"" 2008/04/14 12:12:41.413,trace,2004,sip,"<?xml version="1.0" encoding="UTF-8"?>" 2008/04/14 12:12:41.413,trace,2004,sip,"<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="sip:test03@domain.com"> " 2008/04/14 12:12:41.413,trace,2004,sip," <tuple id="2754173985">" 2008/04/14 12:12:41.413,trace,2004,sip," <status>" 2008/04/14 12:12:41.413,trace,2004,sip," <basic>open</basic>" 2008/04/14 12:12:41.413,trace,2004,sip," ep:activitypermanent-absence</ep:activity>" 2008/04/14 12:12:41.413,trace,2004,sip," </status>" 2008/04/14 12:12:41.413,trace,2004,sip," </tuple>" 2008/04/14 12:12:41.413,trace,2004,sip,"</presence>" 2008/04/14 12:12:41.413,trace,2004,sip,"" 2008/04/14 12:12:41.413,trace,2004,sip,"----------------------------------------------------------------"
...
2008/04/14 12:42:55.271,trace,1352,sip,"sending message to 172.17.10.53:5060" 2008/04/14 12:42:55.271,trace,1352,sip,"----------------------------------------------------------------" 2008/04/14 12:42:55.271,trace,1352,sip,"SUBSCRIBE sip:test03@domain.com SIP/2.0" 2008/04/14 12:42:55.271,trace,1352,sip,"Via: SIP/2.0/UDP 172.17.10.18:5061;rport;branch=z9hG4bK3796069995" 2008/04/14 12:42:55.271,trace,1352,sip,"From: sip:test04@domain.com;tag=823554229" 2008/04/14 12:42:55.271,trace,1352,sip,"To: sip:test03@domain.com" 2008/04/14 12:42:55.271,trace,1352,sip,"Call-ID: 2865051670@172.17.10.18" 2008/04/14 12:42:55.271,trace,1352,sip,"CSeq: 1 SUBSCRIBE" 2008/04/14 12:42:55.271,trace,1352,sip,"Contact: sip:test04@172.17.10.18:5061" 2008/04/14 12:42:55.271,trace,1352,sip,"Max-Forwards: 70" 2008/04/14 12:42:55.271,trace,1352,sip,"User-Agent: Intellivic SDK/4.1.0.401" 2008/04/14 12:42:55.271,trace,1352,sip,"Expires: 3600" 2008/04/14 12:42:55.271,trace,1352,sip,"Event: presence" 2008/04/14 12:42:55.271,trace,1352,sip,"Accept: application/cpim-pidf+xml, application/pidf+xml, application/xpidf+xml" 2008/04/14 12:42:55.271,trace,1352,sip,"Content-Length: 0" 2008/04/14 12:42:55.271,trace,1352,sip,"" 2008/04/14 12:42:55.271,trace,1352,sip,"" 2008/04/14 12:42:55.271,trace,1352,sip,"----------------------------------------------------------------"
2008/04/14 12:42:55.301,trace,2004,sip,"received message from 172.17.10.53:5060" 2008/04/14 12:42:55.301,trace,2004,sip,"----------------------------------------------------------------" 2008/04/14 12:42:55.301,trace,2004,sip,"SIP/2.0 202 OK" 2008/04/14 12:42:55.301,trace,2004,sip,"Via: SIP/2.0/UDP 172.17.10.18:5061;rport;branch=z9hG4bK3796069995" 2008/04/14 12:42:55.301,trace,2004,sip,"From: sip:test04@domain.com;tag=823554229" 2008/04/14 12:42:55.301,trace,2004,sip,"To: sip:test03@domain.com;tag=10.74166.1208169775.67" 2008/04/14 12:42:55.301,trace,2004,sip,"Call-ID: 2865051670@172.17.10.18" 2008/04/14 12:42:55.301,trace,2004,sip,"CSeq: 1 SUBSCRIBE" 2008/04/14 12:42:55.301,trace,2004,sip,"Expires: 3600" 2008/04/14 12:42:55.301,trace,2004,sip,"Contact: sip:172.17.10.53:5060" 2008/04/14 12:42:55.301,trace,2004,sip,"Server: OpenSER (1.3.0-tls (i386/freebsd))" 2008/04/14 12:42:55.301,trace,2004,sip,"Content-Length: 0" 2008/04/14 12:42:55.301,trace,2004,sip,"" 2008/04/14 12:42:55.301,trace,2004,sip,"" 2008/04/14 12:42:55.301,trace,2004,sip,"----------------------------------------------------------------"
2008/04/14 12:42:55.301,trace,2004,sip,"received message from 172.17.10.53:5060" 2008/04/14 12:42:55.301,trace,2004,sip,"----------------------------------------------------------------" 2008/04/14 12:42:55.301,trace,2004,sip,"NOTIFY sip:test04@172.17.10.18:5061 SIP/2.0" 2008/04/14 12:42:55.301,trace,2004,sip,"Via: SIP/2.0/UDP 172.17.10.53:5060;branch=z9hG4bK5f77.0e99e1a5.0" 2008/04/14 12:42:55.301,trace,2004,sip,"To: sip:test04@domain.com;tag=823554229" 2008/04/14 12:42:55.301,trace,2004,sip,"From: sip:test03@domain.com;tag=10.74166.1208169775.67" 2008/04/14 12:42:55.301,trace,2004,sip,"CSeq: 1 NOTIFY" 2008/04/14 12:42:55.301,trace,2004,sip,"Call-ID: 2865051670@172.17.10.18" 2008/04/14 12:42:55.301,trace,2004,sip,"Content-Length: 383" 2008/04/14 12:42:55.301,trace,2004,sip,"User-Agent: OpenSER (1.3.0-tls (i386/freebsd))" 2008/04/14 12:42:55.301,trace,2004,sip,"Max-Forwards: 70" 2008/04/14 12:42:55.301,trace,2004,sip,"Event: presence" 2008/04/14 12:42:55.301,trace,2004,sip,"Contact: sip:172.17.10.53:5060" 2008/04/14 12:42:55.301,trace,2004,sip,"Subscription-State: active;expires=3600" 2008/04/14 12:42:55.301,trace,2004,sip,"Content-Type: application/pidf+xml" 2008/04/14 12:42:55.301,trace,2004,sip,"" 2008/04/14 12:42:55.301,trace,2004,sip,"<?xml version="1.0" encoding="UTF-8"?>" 2008/04/14 12:42:55.301,trace,2004,sip,"<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="sip:test03@domain.com"> " 2008/04/14 12:42:55.301,trace,2004,sip," <tuple id="2754173985">" 2008/04/14 12:42:55.301,trace,2004,sip," <status>" 2008/04/14 12:42:55.301,trace,2004,sip," <basic>open</basic>" 2008/04/14 12:42:55.301,trace,2004,sip," </status>" 2008/04/14 12:42:55.301,trace,2004,sip," </tuple>" 2008/04/14 12:42:55.301,trace,2004,sip,"</presence>" 2008/04/14 12:42:55.301,trace,2004,sip,"" 2008/04/14 12:42:55.301,trace,2004,sip,"----------------------------------------------------------------"
2008/04/14 12:42:55.441,trace,1352,sip,"sending message to 172.17.10.53:5060" 2008/04/14 12:42:55.441,trace,1352,sip,"----------------------------------------------------------------" 2008/04/14 12:42:55.441,trace,1352,sip,"SIP/2.0 200 OK" 2008/04/14 12:42:55.441,trace,1352,sip,"Via: SIP/2.0/UDP 172.17.10.53:5060;branch=z9hG4bK5f77.0e99e1a5.0" 2008/04/14 12:42:55.441,trace,1352,sip,"From: sip:test03@domain.com;tag=10.74166.1208169775.67" 2008/04/14 12:42:55.441,trace,1352,sip,"To: sip:test04@domain.com;tag=823554229" 2008/04/14 12:42:55.441,trace,1352,sip,"Call-ID: 2865051670@172.17.10.18" 2008/04/14 12:42:55.441,trace,1352,sip,"CSeq: 1 NOTIFY" 2008/04/14 12:42:55.441,trace,1352,sip,"Content-Length: 0" 2008/04/14 12:42:55.441,trace,1352,sip,"" 2008/04/14 12:42:55.441,trace,1352,sip,"" 2008/04/14 12:42:55.441,trace,1352,sip,"----------------------------------------------------------------"
2008/04/14 12:43:12.285,trace,2004,sip,"received message from 172.17.10.53:5060" 2008/04/14 12:43:12.285,trace,2004,sip,"----------------------------------------------------------------" 2008/04/14 12:43:12.285,trace,2004,sip,"NOTIFY sip:test04@172.17.10.18:5061 SIP/2.0" 2008/04/14 12:43:12.285,trace,2004,sip,"Via: SIP/2.0/UDP 172.17.10.53:5060;branch=z9hG4bK2f77.31f65dd6.0" 2008/04/14 12:43:12.285,trace,2004,sip,"To: sip:test04@domain.com;tag=823554229" 2008/04/14 12:43:12.285,trace,2004,sip,"From: sip:test03@domain.com;tag=10.74166.1208169775.67" 2008/04/14 12:43:12.285,trace,2004,sip,"CSeq: 2 NOTIFY" 2008/04/14 12:43:12.285,trace,2004,sip,"Call-ID: 2865051670@172.17.10.18" 2008/04/14 12:43:12.285,trace,2004,sip,"Content-Length: 421" 2008/04/14 12:43:12.285,trace,2004,sip,"User-Agent: OpenSER (1.3.0-tls (i386/freebsd))" 2008/04/14 12:43:12.285,trace,2004,sip,"Max-Forwards: 70" 2008/04/14 12:43:12.285,trace,2004,sip,"Event: presence" 2008/04/14 12:43:12.285,trace,2004,sip,"Contact: sip:172.17.10.53:5060" 2008/04/14 12:43:12.285,trace,2004,sip,"Subscription-State: active;expires=3583" 2008/04/14 12:43:12.285,trace,2004,sip,"Content-Type: application/pidf+xml" 2008/04/14 12:43:12.285,trace,2004,sip,"" 2008/04/14 12:43:12.285,trace,2004,sip,"<?xml version="1.0" encoding="UTF-8"?>" 2008/04/14 12:43:12.285,trace,2004,sip,"<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="sip:test03@domain.com"> " 2008/04/14 12:43:12.285,trace,2004,sip," <tuple id="2754173985">" 2008/04/14 12:43:12.285,trace,2004,sip," <status>" 2008/04/14 12:43:12.285,trace,2004,sip," <basic>open</basic>" 2008/04/14 12:43:12.285,trace,2004,sip," ep:activitymeal</ep:activity>" 2008/04/14 12:43:12.285,trace,2004,sip," </status>" 2008/04/14 12:43:12.285,trace,2004,sip," </tuple>" 2008/04/14 12:43:12.285,trace,2004,sip,"</presence>" 2008/04/14 12:43:12.285,trace,2004,sip,"" 2008/04/14 12:43:12.285,trace,2004,sip,"----------------------------------------------------------------"
2008/04/14 12:43:12.315,trace,1352,sip,"sending message to 172.17.10.53:5060" 2008/04/14 12:43:12.315,trace,1352,sip,"----------------------------------------------------------------" 2008/04/14 12:43:12.305,trace,1352,sip,"SIP/2.0 200 OK" 2008/04/14 12:43:12.305,trace,1352,sip,"Via: SIP/2.0/UDP 172.17.10.53:5060;branch=z9hG4bK0a3.8cb82654.0" 2008/04/14 12:43:12.305,trace,1352,sip,"From: sip:test03@domain.com;tag=10.74167.1208169449.68" 2008/04/14 12:43:12.305,trace,1352,sip,"To: sip:test04@domain.com;tag=2701925734" 2008/04/14 12:43:12.305,trace,1352,sip,"Call-ID: 891393650@172.17.10.18" 2008/04/14 12:43:12.305,trace,1352,sip,"CSeq: 4 NOTIFY" 2008/04/14 12:43:12.305,trace,1352,sip,"Content-Length: 0" 2008/04/14 12:43:12.315,trace,1352,sip,"" 2008/04/14 12:43:12.315,trace,1352,sip,"" 2008/04/14 12:43:12.315,trace,1352,sip,"----------------------------------------------------------------"
2008/04/14 12:44:10.840,trace,2004,sip,"received message from 172.17.10.53:5060" 2008/04/14 12:44:10.840,trace,2004,sip,"----------------------------------------------------------------" 2008/04/14 12:44:10.840,trace,2004,sip,"NOTIFY sip:test04@172.17.10.18:5061 SIP/2.0" 2008/04/14 12:44:10.840,trace,2004,sip,"Via: SIP/2.0/UDP 172.17.10.53:5060;branch=z9hG4bK3f77.ab08f675.0" 2008/04/14 12:44:10.840,trace,2004,sip,"To: sip:test04@domain.com;tag=823554229" 2008/04/14 12:44:10.840,trace,2004,sip,"From: sip:test03@domain.com;tag=10.74166.1208169775.67" 2008/04/14 12:44:10.840,trace,2004,sip,"CSeq: 3 NOTIFY" 2008/04/14 12:44:10.840,trace,2004,sip,"Call-ID: 2865051670@172.17.10.18" 2008/04/14 12:44:10.840,trace,2004,sip,"Content-Length: 0" 2008/04/14 12:44:10.840,trace,2004,sip,"User-Agent: OpenSER (1.3.0-tls (i386/freebsd))" 2008/04/14 12:44:10.840,trace,2004,sip,"Max-Forwards: 70" 2008/04/14 12:44:10.840,trace,2004,sip,"Event: presence" 2008/04/14 12:44:10.840,trace,2004,sip,"Contact: sip:172.17.10.53:5060" 2008/04/14 12:44:10.840,trace,2004,sip,"Subscription-State: terminated;reason=timeout" 2008/04/14 12:44:10.840,trace,2004,sip,"" 2008/04/14 12:44:10.840,trace,2004,sip,"" 2008/04/14 12:44:10.840,trace,2004,sip,"----------------------------------------------------------------"
2008/04/14 12:44:10.900,trace,1352,sip,"sending message to 172.17.10.53:5060" 2008/04/14 12:44:10.900,trace,1352,sip,"----------------------------------------------------------------" 2008/04/14 12:44:10.900,trace,1352,sip,"SIP/2.0 200 OK" 2008/04/14 12:44:10.900,trace,1352,sip,"Via: SIP/2.0/UDP 172.17.10.53:5060;branch=z9hG4bK3f77.ab08f675.0" 2008/04/14 12:44:10.900,trace,1352,sip,"From: sip:test03@domain.com;tag=10.74166.1208169775.67" 2008/04/14 12:44:10.900,trace,1352,sip,"To: sip:test04@domain.com;tag=823554229" 2008/04/14 12:44:10.900,trace,1352,sip,"Call-ID: 2865051670@172.17.10.18" 2008/04/14 12:44:10.900,trace,1352,sip,"CSeq: 3 NOTIFY" 2008/04/14 12:44:10.900,trace,1352,sip,"Content-Length: 0" 2008/04/14 12:44:10.900,trace,1352,sip,"" 2008/04/14 12:44:10.900,trace,1352,sip,"" 2008/04/14 12:44:10.900,trace,1352,sip,"----------------------------------------------------------------"
2008/04/14 12:45:06.470,trace,2004,sip,"received message from 172.17.10.53:5060" 2008/04/14 12:45:06.470,trace,2004,sip,"----------------------------------------------------------------" 2008/04/14 12:45:06.470,trace,2004,sip,"NOTIFY sip:test04@172.17.10.18:5061 SIP/2.0" 2008/04/14 12:45:06.470,trace,2004,sip,"Via: SIP/2.0/UDP 172.17.10.53:5060;branch=z9hG4bK2f77.41f65dd6.0" 2008/04/14 12:45:06.470,trace,2004,sip,"To: sip:test04@domain.com;tag=823554229" 2008/04/14 12:45:06.470,trace,2004,sip,"From: sip:test03@domain.com;tag=10.74166.1208169775.67" 2008/04/14 12:45:06.470,trace,2004,sip,"CSeq: 2 NOTIFY" 2008/04/14 12:45:06.470,trace,2004,sip,"Call-ID: 2865051670@172.17.10.18" 2008/04/14 12:45:06.470,trace,2004,sip,"Content-Length: 383" 2008/04/14 12:45:06.470,trace,2004,sip,"User-Agent: OpenSER (1.3.0-tls (i386/freebsd))" 2008/04/14 12:45:06.470,trace,2004,sip,"Max-Forwards: 70" 2008/04/14 12:45:06.470,trace,2004,sip,"Event: presence" 2008/04/14 12:45:06.470,trace,2004,sip,"Contact: sip:172.17.10.53:5060" 2008/04/14 12:45:06.470,trace,2004,sip,"Subscription-State: active;expires=3469" 2008/04/14 12:45:06.470,trace,2004,sip,"Content-Type: application/pidf+xml" 2008/04/14 12:45:06.470,trace,2004,sip,"" 2008/04/14 12:45:06.470,trace,2004,sip,"<?xml version="1.0" encoding="UTF-8"?>" 2008/04/14 12:45:06.470,trace,2004,sip,"<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="sip:test03@domain.com"> " 2008/04/14 12:45:06.470,trace,2004,sip," <tuple id="2754173985">" 2008/04/14 12:45:06.470,trace,2004,sip," <status>" 2008/04/14 12:45:06.470,trace,2004,sip," <basic>open</basic>" 2008/04/14 12:45:06.470,trace,2004,sip," </status>" 2008/04/14 12:45:06.470,trace,2004,sip," </tuple>" 2008/04/14 12:45:06.470,trace,2004,sip,"</presence>" 2008/04/14 12:45:06.470,trace,2004,sip,"" 2008/04/14 12:45:06.470,trace,2004,sip,"----------------------------------------------------------------"
...
Hi Sigrid,
Thank you for your report. Dialogs were removed from cache, but not from database. And since you are probably running presence in a fallback to db mode, the dialogs were still found there. I have made a commit that should fix this problem. Could you please take the 'presence' module from the 1.3 svn branch and test again? As a note, unless you are using more that one presence servers, the fallback to db mode is not really needed and inefficient.
Thanks and regards, Anca Vamanu
Sigrid Thijs wrote:
Hi,
we've configured OpenSER 1.3.0 on a FreeBSD server, together with OpenXCAP 0.9.9. When testing presence rules (RFC 5025) with our UA, we noticed the following behavior:
- Subscription Handling is set to "block" in the presence rules:
When a watcher subscribes for presence, it receives a NOTIFY with the Subscription-State set to "terminated;reason=rejected". This is as expected. When the presentity changes it's presence, the watcher doesn't receive any NOTIFY requests with the presence update (also OK). But, when the presentity changes the subscription handling to "allow" in the presence-rules document, the server sends an in-dialog NOTIFY request on the subscription dialog that was previously terminated. This is not ok. See the attached file presence_rules_01.txt.
- Subscription Handling is set to "allow" in the presence rules:
When the presentity changes the subscription handling to "block" in the presence-rules document, the server sends a NOTIFY with the Subscription-State set to "terminated;reason=timeout" to the watchers. When the presentity changes his presence, the presence server will still send NOTIFY requests to the watchers. See the attached file presence_rules_02.txt.
kind regards,
Sigrid
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Hello,
Anca Vamanu wrote:
Hi Sigrid,
Thank you for your report. Dialogs were removed from cache, but not from database. And since you are probably running presence in a fallback to db mode, the dialogs were still found there. I have made a commit that should fix this problem. Could you please take the 'presence' module from the 1.3 svn branch and test again?
The fallback2db option was indeed set to 1 for the presence module, I thought it was necessary because OpenXCAP also accesses the database. I set the presence(_xml) configuration options based on the OpenSER configuration example from OpenXCAP (http://www.openxcap.org/wiki/Installation).
When I disabled the fallback2db mode, the issue still occurred. We have now updated the presence module, and this solved it. Thanks.
But now we noticed another problem. When the subscription handling is set to "polite-block", a NOTIFY should be sent containing a presence document that indicates that the presentity is unavailable. But the presence module sends a NOTIFY containing a presence description with the current presence state of the presentity. So there's no difference between setting the subscription handling to "allow" and "polite-block".
kind regards,
Sigrid
As a note, unless you are using more that one presence servers, the fallback to db mode is not really needed and inefficient.
Thanks and regards, Anca Vamanu
Sigrid Thijs wrote:
Hi,
we've configured OpenSER 1.3.0 on a FreeBSD server, together with OpenXCAP 0.9.9. When testing presence rules (RFC 5025) with our UA, we noticed the following behavior:
- Subscription Handling is set to "block" in the presence rules:
When a watcher subscribes for presence, it receives a NOTIFY with the Subscription-State set to "terminated;reason=rejected". This is as expected. When the presentity changes it's presence, the watcher doesn't receive any NOTIFY requests with the presence update (also OK). But, when the presentity changes the subscription handling to "allow" in the presence-rules document, the server sends an in-dialog NOTIFY request on the subscription dialog that was previously terminated. This is not ok. See the attached file presence_rules_01.txt.
- Subscription Handling is set to "allow" in the presence rules:
When the presentity changes the subscription handling to "block" in the presence-rules document, the server sends a NOTIFY with the Subscription-State set to "terminated;reason=timeout" to the watchers. When the presentity changes his presence, the presence server will still send NOTIFY requests to the watchers. See the attached file presence_rules_02.txt.
kind regards,
Sigrid
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Hi,
Sigrid Thijs wrote:
But now we noticed another problem. When the subscription handling is set to "polite-block", a NOTIFY should be sent containing a presence document that indicates that the presentity is unavailable. But the presence module sends a NOTIFY containing a presence description with the current presence state of the presentity. So there's no difference between setting the subscription handling to "allow" and "polite-block".
did you get any chance to take a look at this issue?
kind regards,
Sigrid
kind regards,
Sigrid
As a note, unless you are using more that one presence servers, the fallback to db mode is not really needed and inefficient.
Thanks and regards, Anca Vamanu
Sigrid Thijs wrote:
Hi,
we've configured OpenSER 1.3.0 on a FreeBSD server, together with OpenXCAP 0.9.9. When testing presence rules (RFC 5025) with our UA, we noticed the following behavior:
- Subscription Handling is set to "block" in the presence rules:
When a watcher subscribes for presence, it receives a NOTIFY with the Subscription-State set to "terminated;reason=rejected". This is as expected. When the presentity changes it's presence, the watcher doesn't receive any NOTIFY requests with the presence update (also OK). But, when the presentity changes the subscription handling to "allow" in the presence-rules document, the server sends an in-dialog NOTIFY request on the subscription dialog that was previously terminated. This is not ok. See the attached file presence_rules_01.txt.
- Subscription Handling is set to "allow" in the presence rules:
When the presentity changes the subscription handling to "block" in the presence-rules document, the server sends a NOTIFY with the Subscription-State set to "terminated;reason=timeout" to the watchers. When the presentity changes his presence, the presence server will still send NOTIFY requests to the watchers. See the attached file presence_rules_02.txt.
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
Hi,
I have fixed it now. Please update, test and reply if it works.
regards, Anca Vamanu
Sigrid Thijs wrote:
Hi,
Sigrid Thijs wrote:
But now we noticed another problem. When the subscription handling is set to "polite-block", a NOTIFY should be sent containing a presence document that indicates that the presentity is unavailable. But the presence module sends a NOTIFY containing a presence description with the current presence state of the presentity. So there's no difference between setting the subscription handling to "allow" and "polite-block".
did you get any chance to take a look at this issue?
kind regards,
Sigrid
kind regards,
Sigrid
As a note, unless you are using more that one presence servers, the fallback to db mode is not really needed and inefficient.
Thanks and regards, Anca Vamanu
Sigrid Thijs wrote:
Hi,
we've configured OpenSER 1.3.0 on a FreeBSD server, together with OpenXCAP 0.9.9. When testing presence rules (RFC 5025) with our UA, we noticed the following behavior:
- Subscription Handling is set to "block" in the presence rules:
When a watcher subscribes for presence, it receives a NOTIFY with the Subscription-State set to "terminated;reason=rejected". This is as expected. When the presentity changes it's presence, the watcher doesn't receive any NOTIFY requests with the presence update (also OK). But, when the presentity changes the subscription handling to "allow" in the presence-rules document, the server sends an in-dialog NOTIFY request on the subscription dialog that was previously terminated. This is not ok. See the attached file presence_rules_01.txt.
- Subscription Handling is set to "allow" in the presence rules:
When the presentity changes the subscription handling to "block" in the presence-rules document, the server sends a NOTIFY with the Subscription-State set to "terminated;reason=timeout" to the watchers. When the presentity changes his presence, the presence server will still send NOTIFY requests to the watchers. See the attached file presence_rules_02.txt.
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
Hi,
we've installed version 1.3.2 and it works now.
Thanks,
Sigrid
Anca Vamanu wrote:
Hi,
I have fixed it now. Please update, test and reply if it works.
regards, Anca Vamanu
Sigrid Thijs wrote:
Hi,
Sigrid Thijs wrote:
But now we noticed another problem. When the subscription handling is set to "polite-block", a NOTIFY should be sent containing a presence document that indicates that the presentity is unavailable. But the presence module sends a NOTIFY containing a presence description with the current presence state of the presentity. So there's no difference between setting the subscription handling to "allow" and "polite-block".
did you get any chance to take a look at this issue?
kind regards,
Sigrid
kind regards,
Sigrid
As a note, unless you are using more that one presence servers, the fallback to db mode is not really needed and inefficient.
Thanks and regards, Anca Vamanu
Sigrid Thijs wrote:
Hi,
we've configured OpenSER 1.3.0 on a FreeBSD server, together with OpenXCAP 0.9.9. When testing presence rules (RFC 5025) with our UA, we noticed the following behavior:
- Subscription Handling is set to "block" in the presence rules:
When a watcher subscribes for presence, it receives a NOTIFY with the Subscription-State set to "terminated;reason=rejected". This is as expected. When the presentity changes it's presence, the watcher doesn't receive any NOTIFY requests with the presence update (also OK). But, when the presentity changes the subscription handling to "allow" in the presence-rules document, the server sends an in-dialog NOTIFY request on the subscription dialog that was previously terminated. This is not ok. See the attached file presence_rules_01.txt.
- Subscription Handling is set to "allow" in the presence rules:
When the presentity changes the subscription handling to "block" in the presence-rules document, the server sends a NOTIFY with the Subscription-State set to "terminated;reason=timeout" to the watchers. When the presentity changes his presence, the presence server will still send NOTIFY requests to the watchers. See the attached file presence_rules_02.txt.
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
Just a remark: one more thing we noticed is that when a presentity has 'polite-block'ed a watcher, the presence module sends a NOTIFY to the watcher each time the presentity changes his presence, although the content of the NOTIFY stays the same (no body).
kind regards,
Sigrid
Sigrid Thijs wrote:
Hi,
we've installed version 1.3.2 and it works now.
Thanks,
Sigrid
Anca Vamanu wrote:
Hi,
I have fixed it now. Please update, test and reply if it works.
regards, Anca Vamanu
Sigrid Thijs wrote:
Hi,
Sigrid Thijs wrote:
But now we noticed another problem. When the subscription handling is set to "polite-block", a NOTIFY should be sent containing a presence document that indicates that the presentity is unavailable. But the presence module sends a NOTIFY containing a presence description with the current presence state of the presentity. So there's no difference between setting the subscription handling to "allow" and "polite-block".
did you get any chance to take a look at this issue?
kind regards,
Sigrid
kind regards,
Sigrid
As a note, unless you are using more that one presence servers, the fallback to db mode is not really needed and inefficient.
Thanks and regards, Anca Vamanu
Sigrid Thijs wrote:
Hi,
we've configured OpenSER 1.3.0 on a FreeBSD server, together with OpenXCAP 0.9.9. When testing presence rules (RFC 5025) with our UA, we noticed the following behavior:
- Subscription Handling is set to "block" in the presence rules:
When a watcher subscribes for presence, it receives a NOTIFY with the Subscription-State set to "terminated;reason=rejected". This is as expected. When the presentity changes it's presence, the watcher doesn't receive any NOTIFY requests with the presence update (also OK). But, when the presentity changes the subscription handling to "allow" in the presence-rules document, the server sends an in-dialog NOTIFY request on the subscription dialog that was previously terminated. This is not ok. See the attached file presence_rules_01.txt.
- Subscription Handling is set to "allow" in the presence rules:
When the presentity changes the subscription handling to "block" in the presence-rules document, the server sends a NOTIFY with the Subscription-State set to "terminated;reason=timeout" to the watchers. When the presentity changes his presence, the presence server will still send NOTIFY requests to the watchers. See the attached file presence_rules_02.txt.
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
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Hi,
I know it is useless but this is what the RFC says: a successful Subscribe must be followed by a Notify with the presence state(none in this case).
regards, Anca
Sigrid Thijs wrote:
Just a remark: one more thing we noticed is that when a presentity has 'polite-block'ed a watcher, the presence module sends a NOTIFY to the watcher each time the presentity changes his presence, although the content of the NOTIFY stays the same (no body).
kind regards,
Sigrid
Sigrid Thijs wrote:
Hi,
we've installed version 1.3.2 and it works now.
Thanks,
Sigrid
Anca Vamanu wrote:
Hi,
I have fixed it now. Please update, test and reply if it works.
regards, Anca Vamanu
Sigrid Thijs wrote:
Hi,
Sigrid Thijs wrote:
But now we noticed another problem. When the subscription handling is set to "polite-block", a NOTIFY should be sent containing a presence document that indicates that the presentity is unavailable. But the presence module sends a NOTIFY containing a presence description with the current presence state of the presentity. So there's no difference between setting the subscription handling to "allow" and "polite-block".
did you get any chance to take a look at this issue?
kind regards,
Sigrid
kind regards,
Sigrid
As a note, unless you are using more that one presence servers, the fallback to db mode is not really needed and inefficient.
Thanks and regards, Anca Vamanu
Sigrid Thijs wrote: > Hi, > > we've configured OpenSER 1.3.0 on a FreeBSD server, together > with OpenXCAP 0.9.9. > When testing presence rules (RFC 5025) with our UA, we noticed > the following behavior: > > - Subscription Handling is set to "block" in the presence rules: > When a watcher subscribes for presence, it receives a NOTIFY > with the Subscription-State set to "terminated;reason=rejected". > This is as expected. > When the presentity changes it's presence, the watcher doesn't > receive any NOTIFY requests with the presence update (also OK). > But, when the presentity changes the subscription handling to > "allow" in the presence-rules document, the server sends an > in-dialog NOTIFY request on the subscription dialog that was > previously terminated. This is not ok. See the attached file > presence_rules_01.txt. > > - Subscription Handling is set to "allow" in the presence rules: > When the presentity changes the subscription handling to "block" > in the presence-rules document, the server sends a NOTIFY with > the Subscription-State set to "terminated;reason=timeout" to the > watchers. > When the presentity changes his presence, the presence server > will still send NOTIFY requests to the watchers. > See the attached file presence_rules_02.txt. > > 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
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Anca Vamanu wrote:
Hi,
I know it is useless but this is what the RFC says: a successful Subscribe must be followed by a Notify with the presence state(none in this case).
But in this case, no SUBSCRIBE is sent by the watcher. The presentity changes his presence (which issues a PUBLISH), and the presence module sends notifications on all active watcher dialogs. Also those that are 'polite-block'-ed (who receive always a NOTIFY with the same content). I'm not saying it's wrong, it's just one thing we noticed.
kind regards,
Sigrid
regards, Anca
Sigrid Thijs wrote:
Just a remark: one more thing we noticed is that when a presentity has 'polite-block'ed a watcher, the presence module sends a NOTIFY to the watcher each time the presentity changes his presence, although the content of the NOTIFY stays the same (no body).
kind regards,
Sigrid
Sigrid Thijs wrote:
Hi,
we've installed version 1.3.2 and it works now.
Thanks,
Sigrid
Anca Vamanu wrote:
Hi,
I have fixed it now. Please update, test and reply if it works.
regards, Anca Vamanu
Sigrid Thijs wrote:
Hi,
Sigrid Thijs wrote:
But now we noticed another problem. When the subscription handling is set to "polite-block", a NOTIFY should be sent containing a presence document that indicates that the presentity is unavailable. But the presence module sends a NOTIFY containing a presence description with the current presence state of the presentity. So there's no difference between setting the subscription handling to "allow" and "polite-block".
did you get any chance to take a look at this issue?
kind regards,
Sigrid
kind regards,
Sigrid
> As a note, unless you are using more that one presence servers, > the fallback to db mode is not really needed and inefficient. > > Thanks and regards, > Anca Vamanu > > Sigrid Thijs wrote: >> Hi, >> >> we've configured OpenSER 1.3.0 on a FreeBSD server, together >> with OpenXCAP 0.9.9. >> When testing presence rules (RFC 5025) with our UA, we noticed >> the following behavior: >> >> - Subscription Handling is set to "block" in the presence rules: >> When a watcher subscribes for presence, it receives a NOTIFY >> with the Subscription-State set to "terminated;reason=rejected". >> This is as expected. >> When the presentity changes it's presence, the watcher doesn't >> receive any NOTIFY requests with the presence update (also OK). >> But, when the presentity changes the subscription handling to >> "allow" in the presence-rules document, the server sends an >> in-dialog NOTIFY request on the subscription dialog that was >> previously terminated. This is not ok. See the attached file >> presence_rules_01.txt. >> >> - Subscription Handling is set to "allow" in the presence rules: >> When the presentity changes the subscription handling to "block" >> in the presence-rules document, the server sends a NOTIFY with >> the Subscription-State set to "terminated;reason=timeout" to the >> watchers. >> When the presentity changes his presence, the presence server >> will still send NOTIFY requests to the watchers. >> See the attached file presence_rules_02.txt. >> >> 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
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Sigrid Thijs wrote:
Anca Vamanu wrote:
Hi,
I know it is useless but this is what the RFC says: a successful Subscribe must be followed by a Notify with the presence state(none in this case).
But in this case, no SUBSCRIBE is sent by the watcher. The presentity changes his presence (which issues a PUBLISH), and the presence module sends notifications on all active watcher dialogs. Also those that are 'polite-block'-ed (who receive always a NOTIFY with the same content). I'm not saying it's wrong, it's just one thing we noticed.
kind regards,
Sigrid
I did not understood correctly. You are right. There should be no Notify in this case. I will take a look.
Thanks, Anca
regards, Anca
Sigrid Thijs wrote:
Just a remark: one more thing we noticed is that when a presentity has 'polite-block'ed a watcher, the presence module sends a NOTIFY to the watcher each time the presentity changes his presence, although the content of the NOTIFY stays the same (no body).
kind regards,
Sigrid
Sigrid Thijs wrote:
Hi,
we've installed version 1.3.2 and it works now.
Thanks,
Sigrid
Anca Vamanu wrote:
Hi,
I have fixed it now. Please update, test and reply if it works.
regards, Anca Vamanu
Sigrid Thijs wrote:
Hi,
Sigrid Thijs wrote:
> But now we noticed another problem. When the subscription > handling is set to "polite-block", a NOTIFY should be sent > containing a presence document that indicates that the > presentity is unavailable. But the presence module sends a > NOTIFY containing a presence description with the current > presence state of the presentity. So there's no difference > between setting the subscription handling to "allow" and > "polite-block". > did you get any chance to take a look at this issue?
kind regards,
Sigrid
> kind regards, > > Sigrid > >> As a note, unless you are using more that one presence servers, >> the fallback to db mode is not really needed and inefficient. >> >> Thanks and regards, >> Anca Vamanu >> >> Sigrid Thijs wrote: >>> Hi, >>> >>> we've configured OpenSER 1.3.0 on a FreeBSD server, together >>> with OpenXCAP 0.9.9. >>> When testing presence rules (RFC 5025) with our UA, we noticed >>> the following behavior: >>> >>> - Subscription Handling is set to "block" in the presence rules: >>> When a watcher subscribes for presence, it receives a NOTIFY >>> with the Subscription-State set to >>> "terminated;reason=rejected". This is as expected. >>> When the presentity changes it's presence, the watcher doesn't >>> receive any NOTIFY requests with the presence update (also OK). >>> But, when the presentity changes the subscription handling to >>> "allow" in the presence-rules document, the server sends an >>> in-dialog NOTIFY request on the subscription dialog that was >>> previously terminated. This is not ok. See the attached file >>> presence_rules_01.txt. >>> >>> - Subscription Handling is set to "allow" in the presence rules: >>> When the presentity changes the subscription handling to >>> "block" in the presence-rules document, the server sends a >>> NOTIFY with the Subscription-State set to >>> "terminated;reason=timeout" to the watchers. >>> When the presentity changes his presence, the presence server >>> will still send NOTIFY requests to the watchers. >>> See the attached file presence_rules_02.txt. >>> >>> 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 >
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Hi,
I have just committed a fix. Could you please update to the svn version of presence module. Or take the patch from here http://openser.svn.sourceforge.net/viewvc/openser/branches/1.3/modules/prese... http://openser.svn.sourceforge.net/viewvc/openser/branches/1.3/modules/presence/notify.c?r1=4265&r2=4264&view=patch&pathrev=4265 and apply it manually and reply if it works.
regards, Anca Vamanu
Sigrid Thijs wrote:
Anca Vamanu wrote:
Hi,
I know it is useless but this is what the RFC says: a successful Subscribe must be followed by a Notify with the presence state(none in this case).
But in this case, no SUBSCRIBE is sent by the watcher. The presentity changes his presence (which issues a PUBLISH), and the presence module sends notifications on all active watcher dialogs. Also those that are 'polite-block'-ed (who receive always a NOTIFY with the same content). I'm not saying it's wrong, it's just one thing we noticed.
kind regards,
Sigrid
regards, Anca
Sigrid Thijs wrote:
Just a remark: one more thing we noticed is that when a presentity has 'polite-block'ed a watcher, the presence module sends a NOTIFY to the watcher each time the presentity changes his presence, although the content of the NOTIFY stays the same (no body).
kind regards,
Sigrid
Sigrid Thijs wrote:
Hi,
we've installed version 1.3.2 and it works now.
Thanks,
Sigrid
Anca Vamanu wrote:
Hi,
I have fixed it now. Please update, test and reply if it works.
regards, Anca Vamanu
Sigrid Thijs wrote:
Hi,
Sigrid Thijs wrote:
> But now we noticed another problem. When the subscription > handling is set to "polite-block", a NOTIFY should be sent > containing a presence document that indicates that the > presentity is unavailable. But the presence module sends a > NOTIFY containing a presence description with the current > presence state of the presentity. So there's no difference > between setting the subscription handling to "allow" and > "polite-block". > did you get any chance to take a look at this issue?
kind regards,
Sigrid
> kind regards, > > Sigrid > >> As a note, unless you are using more that one presence servers, >> the fallback to db mode is not really needed and inefficient. >> >> Thanks and regards, >> Anca Vamanu >> >> Sigrid Thijs wrote: >>> Hi, >>> >>> we've configured OpenSER 1.3.0 on a FreeBSD server, together >>> with OpenXCAP 0.9.9. >>> When testing presence rules (RFC 5025) with our UA, we noticed >>> the following behavior: >>> >>> - Subscription Handling is set to "block" in the presence rules: >>> When a watcher subscribes for presence, it receives a NOTIFY >>> with the Subscription-State set to >>> "terminated;reason=rejected". This is as expected. >>> When the presentity changes it's presence, the watcher doesn't >>> receive any NOTIFY requests with the presence update (also OK). >>> But, when the presentity changes the subscription handling to >>> "allow" in the presence-rules document, the server sends an >>> in-dialog NOTIFY request on the subscription dialog that was >>> previously terminated. This is not ok. See the attached file >>> presence_rules_01.txt. >>> >>> - Subscription Handling is set to "allow" in the presence rules: >>> When the presentity changes the subscription handling to >>> "block" in the presence-rules document, the server sends a >>> NOTIFY with the Subscription-State set to >>> "terminated;reason=timeout" to the watchers. >>> When the presentity changes his presence, the presence server >>> will still send NOTIFY requests to the watchers. >>> See the attached file presence_rules_02.txt. >>> >>> 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 >
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Thanks, that fixed it.
kind regards,
Sigrid
Anca Vamanu wrote:
Hi,
I have just committed a fix. Could you please update to the svn version of presence module. Or take the patch from here http://openser.svn.sourceforge.net/viewvc/openser/branches/1.3/modules/prese... http://openser.svn.sourceforge.net/viewvc/openser/branches/1.3/modules/presence/notify.c?r1=4265&r2=4264&view=patch&pathrev=4265
and apply it manually and reply if it works.
regards, Anca Vamanu
Sigrid Thijs wrote:
Anca Vamanu wrote:
Hi,
I know it is useless but this is what the RFC says: a successful Subscribe must be followed by a Notify with the presence state(none in this case).
But in this case, no SUBSCRIBE is sent by the watcher. The presentity changes his presence (which issues a PUBLISH), and the presence module sends notifications on all active watcher dialogs. Also those that are 'polite-block'-ed (who receive always a NOTIFY with the same content). I'm not saying it's wrong, it's just one thing we noticed.
kind regards,
Sigrid
regards, Anca
Sigrid Thijs wrote:
Just a remark: one more thing we noticed is that when a presentity has 'polite-block'ed a watcher, the presence module sends a NOTIFY to the watcher each time the presentity changes his presence, although the content of the NOTIFY stays the same (no body).
kind regards,
Sigrid
Sigrid Thijs wrote:
Hi,
we've installed version 1.3.2 and it works now.
Thanks,
Sigrid
Anca Vamanu wrote:
Hi,
I have fixed it now. Please update, test and reply if it works.
regards, Anca Vamanu
Sigrid Thijs wrote: > Hi, > > Sigrid Thijs wrote: > >> But now we noticed another problem. When the subscription >> handling is set to "polite-block", a NOTIFY should be sent >> containing a presence document that indicates that the >> presentity is unavailable. But the presence module sends a >> NOTIFY containing a presence description with the current >> presence state of the presentity. So there's no difference >> between setting the subscription handling to "allow" and >> "polite-block". >> > did you get any chance to take a look at this issue? > > kind regards, > > Sigrid > >> kind regards, >> >> Sigrid >> >>> As a note, unless you are using more that one presence servers, >>> the fallback to db mode is not really needed and inefficient. >>> >>> Thanks and regards, >>> Anca Vamanu >>> >>> Sigrid Thijs wrote: >>>> Hi, >>>> >>>> we've configured OpenSER 1.3.0 on a FreeBSD server, together >>>> with OpenXCAP 0.9.9. >>>> When testing presence rules (RFC 5025) with our UA, we noticed >>>> the following behavior: >>>> >>>> - Subscription Handling is set to "block" in the presence rules: >>>> When a watcher subscribes for presence, it receives a NOTIFY >>>> with the Subscription-State set to >>>> "terminated;reason=rejected". This is as expected. >>>> When the presentity changes it's presence, the watcher doesn't >>>> receive any NOTIFY requests with the presence update (also OK). >>>> But, when the presentity changes the subscription handling to >>>> "allow" in the presence-rules document, the server sends an >>>> in-dialog NOTIFY request on the subscription dialog that was >>>> previously terminated. This is not ok. See the attached file >>>> presence_rules_01.txt. >>>> >>>> - Subscription Handling is set to "allow" in the presence rules: >>>> When the presentity changes the subscription handling to >>>> "block" in the presence-rules document, the server sends a >>>> NOTIFY with the Subscription-State set to >>>> "terminated;reason=timeout" to the watchers. >>>> When the presentity changes his presence, the presence server >>>> will still send NOTIFY requests to the watchers. >>>> See the attached file presence_rules_02.txt. >>>> >>>> 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 >>
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Unfortunately I jumped to conclusions to quickly. The NOTIFY requests are not sent anymore when the watcher is "polite-block"-ed, but now they are also not sent anymore to watchers that are allowed. An allowed watcher only receives the correct presence state of the presentity when he initiates the subscription.
kind regards,
Sigrid
Sigrid Thijs wrote:
Thanks, that fixed it.
kind regards,
Sigrid
Anca Vamanu wrote:
Hi,
I have just committed a fix. Could you please update to the svn version of presence module. Or take the patch from here http://openser.svn.sourceforge.net/viewvc/openser/branches/1.3/modules/prese... http://openser.svn.sourceforge.net/viewvc/openser/branches/1.3/modules/presence/notify.c?r1=4265&r2=4264&view=patch&pathrev=4265
and apply it manually and reply if it works.
regards, Anca Vamanu
Sigrid Thijs wrote:
Anca Vamanu wrote:
Hi,
I know it is useless but this is what the RFC says: a successful Subscribe must be followed by a Notify with the presence state(none in this case).
But in this case, no SUBSCRIBE is sent by the watcher. The presentity changes his presence (which issues a PUBLISH), and the presence module sends notifications on all active watcher dialogs. Also those that are 'polite-block'-ed (who receive always a NOTIFY with the same content). I'm not saying it's wrong, it's just one thing we noticed.
kind regards,
Sigrid
regards, Anca
Sigrid Thijs wrote:
Just a remark: one more thing we noticed is that when a presentity has 'polite-block'ed a watcher, the presence module sends a NOTIFY to the watcher each time the presentity changes his presence, although the content of the NOTIFY stays the same (no body).
kind regards,
Sigrid
Sigrid Thijs wrote:
Hi,
we've installed version 1.3.2 and it works now.
Thanks,
Sigrid
Anca Vamanu wrote: > Hi, > > I have fixed it now. Please update, test and reply if it works. > > regards, > Anca Vamanu > > > Sigrid Thijs wrote: >> Hi, >> >> Sigrid Thijs wrote: >> >>> But now we noticed another problem. When the subscription >>> handling is set to "polite-block", a NOTIFY should be sent >>> containing a presence document that indicates that the >>> presentity is unavailable. But the presence module sends a >>> NOTIFY containing a presence description with the current >>> presence state of the presentity. So there's no difference >>> between setting the subscription handling to "allow" and >>> "polite-block". >>> >> did you get any chance to take a look at this issue? >> >> kind regards, >> >> Sigrid >> >>> kind regards, >>> >>> Sigrid >>> >>>> As a note, unless you are using more that one presence servers, >>>> the fallback to db mode is not really needed and inefficient. >>>> >>>> Thanks and regards, >>>> Anca Vamanu >>>> >>>> Sigrid Thijs wrote: >>>>> Hi, >>>>> >>>>> we've configured OpenSER 1.3.0 on a FreeBSD server, together >>>>> with OpenXCAP 0.9.9. >>>>> When testing presence rules (RFC 5025) with our UA, we noticed >>>>> the following behavior: >>>>> >>>>> - Subscription Handling is set to "block" in the presence rules: >>>>> When a watcher subscribes for presence, it receives a NOTIFY >>>>> with the Subscription-State set to >>>>> "terminated;reason=rejected". This is as expected. >>>>> When the presentity changes it's presence, the watcher doesn't >>>>> receive any NOTIFY requests with the presence update (also OK). >>>>> But, when the presentity changes the subscription handling to >>>>> "allow" in the presence-rules document, the server sends an >>>>> in-dialog NOTIFY request on the subscription dialog that was >>>>> previously terminated. This is not ok. See the attached file >>>>> presence_rules_01.txt. >>>>> >>>>> - Subscription Handling is set to "allow" in the presence rules: >>>>> When the presentity changes the subscription handling to >>>>> "block" in the presence-rules document, the server sends a >>>>> NOTIFY with the Subscription-State set to >>>>> "terminated;reason=timeout" to the watchers. >>>>> When the presentity changes his presence, the presence server >>>>> will still send NOTIFY requests to the watchers. >>>>> See the attached file presence_rules_02.txt. >>>>> >>>>> 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 >>> _______________________________________________ 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
Hi Sigrid,
I tested myself and you were right. Please update again and test.
Thanks and regards, Anca
Sigrid Thijs wrote:
Unfortunately I jumped to conclusions to quickly. The NOTIFY requests are not sent anymore when the watcher is "polite-block"-ed, but now they are also not sent anymore to watchers that are allowed. An allowed watcher only receives the correct presence state of the presentity when he initiates the subscription.
kind regards,
Sigrid
Sigrid Thijs wrote:
Thanks, that fixed it.
kind regards,
Sigrid
Anca Vamanu wrote:
Hi,
I have just committed a fix. Could you please update to the svn version of presence module. Or take the patch from here http://openser.svn.sourceforge.net/viewvc/openser/branches/1.3/modules/prese... http://openser.svn.sourceforge.net/viewvc/openser/branches/1.3/modules/presence/notify.c?r1=4265&r2=4264&view=patch&pathrev=4265
and apply it manually and reply if it works.
regards, Anca Vamanu
Sigrid Thijs wrote:
Anca Vamanu wrote:
Hi,
I know it is useless but this is what the RFC says: a successful Subscribe must be followed by a Notify with the presence state(none in this case).
But in this case, no SUBSCRIBE is sent by the watcher. The presentity changes his presence (which issues a PUBLISH), and the presence module sends notifications on all active watcher dialogs. Also those that are 'polite-block'-ed (who receive always a NOTIFY with the same content). I'm not saying it's wrong, it's just one thing we noticed.
kind regards,
Sigrid
regards, Anca
Sigrid Thijs wrote:
Just a remark: one more thing we noticed is that when a presentity has 'polite-block'ed a watcher, the presence module sends a NOTIFY to the watcher each time the presentity changes his presence, although the content of the NOTIFY stays the same (no body).
kind regards,
Sigrid
Sigrid Thijs wrote: > Hi, > > we've installed version 1.3.2 and it works now. > > Thanks, > > Sigrid > > Anca Vamanu wrote: >> Hi, >> >> I have fixed it now. Please update, test and reply if it works. >> >> regards, >> Anca Vamanu >> >> >> Sigrid Thijs wrote: >>> Hi, >>> >>> Sigrid Thijs wrote: >>> >>>> But now we noticed another problem. When the subscription >>>> handling is set to "polite-block", a NOTIFY should be sent >>>> containing a presence document that indicates that the >>>> presentity is unavailable. But the presence module sends a >>>> NOTIFY containing a presence description with the current >>>> presence state of the presentity. So there's no difference >>>> between setting the subscription handling to "allow" and >>>> "polite-block". >>>> >>> did you get any chance to take a look at this issue? >>> >>> kind regards, >>> >>> Sigrid >>> >>>> kind regards, >>>> >>>> Sigrid >>>> >>>>> As a note, unless you are using more that one presence >>>>> servers, the fallback to db mode is not really needed and >>>>> inefficient. >>>>> >>>>> Thanks and regards, >>>>> Anca Vamanu >>>>> >>>>> Sigrid Thijs wrote: >>>>>> Hi, >>>>>> >>>>>> we've configured OpenSER 1.3.0 on a FreeBSD server, >>>>>> together with OpenXCAP 0.9.9. >>>>>> When testing presence rules (RFC 5025) with our UA, we >>>>>> noticed the following behavior: >>>>>> >>>>>> - Subscription Handling is set to "block" in the presence >>>>>> rules: >>>>>> When a watcher subscribes for presence, it receives a >>>>>> NOTIFY with the Subscription-State set to >>>>>> "terminated;reason=rejected". This is as expected. >>>>>> When the presentity changes it's presence, the watcher >>>>>> doesn't receive any NOTIFY requests with the presence >>>>>> update (also OK). >>>>>> But, when the presentity changes the subscription handling >>>>>> to "allow" in the presence-rules document, the server sends >>>>>> an in-dialog NOTIFY request on the subscription dialog that >>>>>> was previously terminated. This is not ok. See the attached >>>>>> file presence_rules_01.txt. >>>>>> >>>>>> - Subscription Handling is set to "allow" in the presence >>>>>> rules: >>>>>> When the presentity changes the subscription handling to >>>>>> "block" in the presence-rules document, the server sends a >>>>>> NOTIFY with the Subscription-State set to >>>>>> "terminated;reason=timeout" to the watchers. >>>>>> When the presentity changes his presence, the presence >>>>>> server will still send NOTIFY requests to the watchers. >>>>>> See the attached file presence_rules_02.txt. >>>>>> >>>>>> 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 >>>> > _______________________________________________ > 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
Ok,
we've been testing, and this is our experience: - watcher is allowed: when the watcher subscribes, it receives the presence and the presence updates (OK) - watcher is polite-blocked: when the watchers subscribes, it receives a 'appear-offline' NOTIFY and no further presence updates (OK)
When there's already a subscription active, and the presentity changes the subscription-handling in the presence-rules from 'allow' to 'polite-block', the watcher receives one NOTIFY (appear-offline) and no further presence updates. (OK)
But, when there's an active subscription, and the presentity changes the subscription handling from 'polite-block' to 'allow', the watcher only receives one NOTIFY, containing the current presence description of the presentity, but no further presence updates => not OK.
This also happens when the subscription-handling switches from 'allow' to 'confirm' back to 'allow'. But this is probably not a real world example.
kind regards,
Sigrid
Anca Vamanu wrote:
Hi Sigrid,
I tested myself and you were right. Please update again and test.
Thanks and regards, Anca
Sigrid Thijs wrote:
Unfortunately I jumped to conclusions to quickly. The NOTIFY requests are not sent anymore when the watcher is "polite-block"-ed, but now they are also not sent anymore to watchers that are allowed. An allowed watcher only receives the correct presence state of the presentity when he initiates the subscription.
kind regards,
Sigrid
Sigrid Thijs wrote:
Thanks, that fixed it.
kind regards,
Sigrid
Anca Vamanu wrote:
Hi,
I have just committed a fix. Could you please update to the svn version of presence module. Or take the patch from here http://openser.svn.sourceforge.net/viewvc/openser/branches/1.3/modules/prese... http://openser.svn.sourceforge.net/viewvc/openser/branches/1.3/modules/presence/notify.c?r1=4265&r2=4264&view=patch&pathrev=4265
and apply it manually and reply if it works.
regards, Anca Vamanu
Sigrid Thijs wrote:
Anca Vamanu wrote:
Hi,
I know it is useless but this is what the RFC says: a successful Subscribe must be followed by a Notify with the presence state(none in this case).
But in this case, no SUBSCRIBE is sent by the watcher. The presentity changes his presence (which issues a PUBLISH), and the presence module sends notifications on all active watcher dialogs. Also those that are 'polite-block'-ed (who receive always a NOTIFY with the same content). I'm not saying it's wrong, it's just one thing we noticed.
kind regards,
Sigrid
regards, Anca
Sigrid Thijs wrote: > Just a remark: one more thing we noticed is that when a > presentity has 'polite-block'ed a watcher, the presence module > sends a NOTIFY to the watcher each time the presentity changes > his presence, although the content of the NOTIFY stays the same > (no body). > > kind regards, > > Sigrid > > Sigrid Thijs wrote: >> Hi, >> >> we've installed version 1.3.2 and it works now. >> >> Thanks, >> >> Sigrid >> >> Anca Vamanu wrote: >>> Hi, >>> >>> I have fixed it now. Please update, test and reply if it works. >>> >>> regards, >>> Anca Vamanu >>> >>> >>> Sigrid Thijs wrote: >>>> Hi, >>>> >>>> Sigrid Thijs wrote: >>>> >>>>> But now we noticed another problem. When the subscription >>>>> handling is set to "polite-block", a NOTIFY should be sent >>>>> containing a presence document that indicates that the >>>>> presentity is unavailable. But the presence module sends a >>>>> NOTIFY containing a presence description with the current >>>>> presence state of the presentity. So there's no difference >>>>> between setting the subscription handling to "allow" and >>>>> "polite-block". >>>>> >>>> did you get any chance to take a look at this issue? >>>> >>>> kind regards, >>>> >>>> Sigrid >>>> >>>>> kind regards, >>>>> >>>>> Sigrid >>>>> >>>>>> As a note, unless you are using more that one presence >>>>>> servers, the fallback to db mode is not really needed and >>>>>> inefficient. >>>>>> >>>>>> Thanks and regards, >>>>>> Anca Vamanu >>>>>> >>>>>> Sigrid Thijs wrote: >>>>>>> Hi, >>>>>>> >>>>>>> we've configured OpenSER 1.3.0 on a FreeBSD server, >>>>>>> together with OpenXCAP 0.9.9. >>>>>>> When testing presence rules (RFC 5025) with our UA, we >>>>>>> noticed the following behavior: >>>>>>> >>>>>>> - Subscription Handling is set to "block" in the presence >>>>>>> rules: >>>>>>> When a watcher subscribes for presence, it receives a >>>>>>> NOTIFY with the Subscription-State set to >>>>>>> "terminated;reason=rejected". This is as expected. >>>>>>> When the presentity changes it's presence, the watcher >>>>>>> doesn't receive any NOTIFY requests with the presence >>>>>>> update (also OK). >>>>>>> But, when the presentity changes the subscription handling >>>>>>> to "allow" in the presence-rules document, the server sends >>>>>>> an in-dialog NOTIFY request on the subscription dialog that >>>>>>> was previously terminated. This is not ok. See the attached >>>>>>> file presence_rules_01.txt. >>>>>>> >>>>>>> - Subscription Handling is set to "allow" in the presence >>>>>>> rules: >>>>>>> When the presentity changes the subscription handling to >>>>>>> "block" in the presence-rules document, the server sends a >>>>>>> NOTIFY with the Subscription-State set to >>>>>>> "terminated;reason=timeout" to the watchers. >>>>>>> When the presentity changes his presence, the presence >>>>>>> server will still send NOTIFY requests to the watchers. >>>>>>> See the attached file presence_rules_02.txt. >>>>>>> >>>>>>> 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 >>>>> >> _______________________________________________ >> 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
Hi,
Sigrid Thijs wrote:
But, when there's an active subscription, and the presentity changes the subscription handling from 'polite-block' to 'allow', the watcher only receives one NOTIFY, containing the current presence description of the presentity, but no further presence updates => not OK.
This also happens when the subscription-handling switches from 'allow' to 'confirm' back to 'allow'. But this is probably not a real world example.
Did you get a chance to look into these two issues?
kind regards,
Sigrid
Anca Vamanu wrote:
Hi Sigrid,
I tested myself and you were right. Please update again and test.
Thanks and regards, Anca
Sigrid Thijs wrote:
Unfortunately I jumped to conclusions to quickly. The NOTIFY requests are not sent anymore when the watcher is "polite-block"-ed, but now they are also not sent anymore to watchers that are allowed. An allowed watcher only receives the correct presence state of the presentity when he initiates the subscription.
kind regards,
Sigrid
Sigrid Thijs wrote:
Thanks, that fixed it.
kind regards,
Sigrid
Anca Vamanu wrote:
Hi,
I have just committed a fix. Could you please update to the svn version of presence module. Or take the patch from here http://openser.svn.sourceforge.net/viewvc/openser/branches/1.3/modules/prese... http://openser.svn.sourceforge.net/viewvc/openser/branches/1.3/modules/presence/notify.c?r1=4265&r2=4264&view=patch&pathrev=4265
and apply it manually and reply if it works.
regards, Anca Vamanu
Sigrid Thijs wrote:
Anca Vamanu wrote: > Hi, > > > I know it is useless but this is what the RFC says: a successful > Subscribe must be followed by a Notify with the presence > state(none in this case). > But in this case, no SUBSCRIBE is sent by the watcher. The presentity changes his presence (which issues a PUBLISH), and the presence module sends notifications on all active watcher dialogs. Also those that are 'polite-block'-ed (who receive always a NOTIFY with the same content). I'm not saying it's wrong, it's just one thing we noticed.
kind regards,
Sigrid
> regards, > Anca > > > Sigrid Thijs wrote: >> Just a remark: one more thing we noticed is that when a >> presentity has 'polite-block'ed a watcher, the presence module >> sends a NOTIFY to the watcher each time the presentity changes >> his presence, although the content of the NOTIFY stays the same >> (no body). >> >> kind regards, >> >> Sigrid >> >> Sigrid Thijs wrote: >>> Hi, >>> >>> we've installed version 1.3.2 and it works now. >>> >>> Thanks, >>> >>> Sigrid >>> >>> Anca Vamanu wrote: >>>> Hi, >>>> >>>> I have fixed it now. Please update, test and reply if it works. >>>> >>>> regards, >>>> Anca Vamanu >>>> >>>> >>>> Sigrid Thijs wrote: >>>>> Hi, >>>>> >>>>> Sigrid Thijs wrote: >>>>> >>>>>> But now we noticed another problem. When the subscription >>>>>> handling is set to "polite-block", a NOTIFY should be sent >>>>>> containing a presence document that indicates that the >>>>>> presentity is unavailable. But the presence module sends a >>>>>> NOTIFY containing a presence description with the current >>>>>> presence state of the presentity. So there's no difference >>>>>> between setting the subscription handling to "allow" and >>>>>> "polite-block". >>>>>> >>>>> did you get any chance to take a look at this issue? >>>>> >>>>> kind regards, >>>>> >>>>> Sigrid >>>>> >>>>>> kind regards, >>>>>> >>>>>> Sigrid >>>>>> >>>>>>> As a note, unless you are using more that one presence >>>>>>> servers, the fallback to db mode is not really needed and >>>>>>> inefficient. >>>>>>> >>>>>>> Thanks and regards, >>>>>>> Anca Vamanu >>>>>>> >>>>>>> Sigrid Thijs wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> we've configured OpenSER 1.3.0 on a FreeBSD server, >>>>>>>> together with OpenXCAP 0.9.9. >>>>>>>> When testing presence rules (RFC 5025) with our UA, we >>>>>>>> noticed the following behavior: >>>>>>>> >>>>>>>> - Subscription Handling is set to "block" in the presence >>>>>>>> rules: >>>>>>>> When a watcher subscribes for presence, it receives a >>>>>>>> NOTIFY with the Subscription-State set to >>>>>>>> "terminated;reason=rejected". This is as expected. >>>>>>>> When the presentity changes it's presence, the watcher >>>>>>>> doesn't receive any NOTIFY requests with the presence >>>>>>>> update (also OK). >>>>>>>> But, when the presentity changes the subscription handling >>>>>>>> to "allow" in the presence-rules document, the server sends >>>>>>>> an in-dialog NOTIFY request on the subscription dialog that >>>>>>>> was previously terminated. This is not ok. See the attached >>>>>>>> file presence_rules_01.txt. >>>>>>>> >>>>>>>> - Subscription Handling is set to "allow" in the presence >>>>>>>> rules: >>>>>>>> When the presentity changes the subscription handling to >>>>>>>> "block" in the presence-rules document, the server sends a >>>>>>>> NOTIFY with the Subscription-State set to >>>>>>>> "terminated;reason=timeout" to the watchers. >>>>>>>> When the presentity changes his presence, the presence >>>>>>>> server will still send NOTIFY requests to the watchers. >>>>>>>> See the attached file presence_rules_02.txt. >>>>>>>> >>>>>>>> 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 >>>>>> >>> _______________________________________________ >>> 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
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
-
Anca Vamanu -
Sigrid Thijs