14 Apr
2008
14 Apr
'08
3:38 p.m.
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(a)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(a)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(a)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(a)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(a)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:activity>permanent-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(a)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(a)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(a)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(a)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(a)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:activity>meal</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(a)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(a)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(a)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(a)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,"----------------------------------------------------------------"
...
15 Apr
15 Apr
3:44 p.m.
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(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
30 Apr
30 Apr
10:41 a.m.
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(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
15 May
15 May
10:26 a.m.
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:
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
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(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
1:39 p.m.
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(a)lists.openser.org
>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>
>
> _______________________________________________
> Users mailing list
> Users(a)lists.openser.org
> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>
26 May
26 May
3:35 p.m.
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(a)lists.openser.org
>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>
>
> _______________________________________________
> Users mailing list
> Users(a)lists.openser.org
> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>
29 May
29 May
9:44 a.m.
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:
_______________________________________________
Users mailing list
Users(a)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(a)lists.openser.org
>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
> _______________________________________________
> Users mailing list
> Users(a)lists.openser.org
> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>
4:13 p.m.
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(a)lists.openser.org
>>>>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users(a)lists.openser.org
>>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>>
>>
>
> _______________________________________________
> Users mailing list
> Users(a)lists.openser.org
> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>
4:57 p.m.
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(a)lists.openser.org
>>>>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users(a)lists.openser.org
>>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>>
>>
>
> _______________________________________________
> Users mailing list
> Users(a)lists.openser.org
> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>
4:58 p.m.
Sigrid Thijs wrote:
Anca Vamanu wrote:
I did not understood correctly. You are right. There should be no Notify
in this case. I will take a look.
Thanks,
Anca
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(a)lists.openser.org
>>>>>>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users(a)lists.openser.org
>>>>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>>>>
>>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users(a)lists.openser.org
>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>
>
>
5:39 p.m.
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/pres…
<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(a)lists.openser.org
>>>>>>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users(a)lists.openser.org
>>>>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>>>>
>>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users(a)lists.openser.org
>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>
>
>
5 Jun
5 Jun
12:30 p.m.
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/pres…
<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(a)lists.openser.org
>>>>>>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users(a)lists.openser.org
>>>>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>>>>
>>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users(a)lists.openser.org
>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>
>
>
12:53 p.m.
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/pres…
<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:
_______________________________________________
Users mailing list
Users(a)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(a)lists.openser.org
>>>>>>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users(a)lists.openser.org
>>>>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users(a)lists.openser.org
>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>
>
6 Jun
6 Jun
6:34 p.m.
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/pres…
>>
<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(a)lists.openser.org
>>>>>>>>>>>
http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>>>>>>> _______________________________________________
>>>>>>>>> Users mailing list
>>>>>>>>> Users(a)lists.openser.org
>>>>>>>>>
http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users(a)lists.openser.org
>>>>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>>>>
>>>>
>>
>
> _______________________________________________
> Users mailing list
> Users(a)lists.openser.org
> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>
10 Jun
10 Jun
12:18 p.m.
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/pres…
>>
<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(a)lists.openser.org
>>>>>>>>>>>
http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>>>>>>> _______________________________________________
>>>>>>>>> Users mailing list
>>>>>>>>> Users(a)lists.openser.org
>>>>>>>>>
http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users(a)lists.openser.org
>>>>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>>>>
>>>>
>>
>
> _______________________________________________
> Users mailing list
> Users(a)lists.openser.org
> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>
7 Jul
7 Jul
12:19 p.m.
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:
_______________________________________________
Users mailing list
Users(a)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/pres…
>>
<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(a)lists.openser.org
>>>>>>>>>>>
http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>>>>>>> _______________________________________________
>>>>>>>>> Users mailing list
>>>>>>>>> Users(a)lists.openser.org
>>>>>>>>>
http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users(a)lists.openser.org
>>>>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>>>>
> _______________________________________________
> Users mailing list
> Users(a)lists.openser.org
> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>
5981
days inactive
6065
days old
15 comments
2 participants
participants (2)
-
Anca Vamanu -
Sigrid Thijs