15 Jun
2012
15 Jun
'12
3:25 p.m.
HI
I just did simple test-case: add user and delete user on kamailio 3.3
on 101 , I added 103, the watcher tables shows:
select * from watchers;
+----+------------------------+------------------+----------------+----------+--------+--------+---------------+
| id | presentity_uri | watcher_username | watcher_domain |
event | status | reason | inserted_time |
+----+------------------------+------------------+----------------+----------+--------+--------+---------------+
| 1 | sip:103@192.168.122.32 | 101 | 192.168.122.32 |
presence | 2 | | 1339772803 |
+----+------------------------+------------------+----------------+----------+--------+--------+---------------+
then I deleted the 103 from the contact list, the watcher table
still shows the same.
It seems a strange behavior, should this to be deleted from the db?
what's the expected behavior on the watchers table for delete/adding
user?
In my previos email testing case, there is terminated status=3 in
db, when will this item will be deleted?
http://lists.sip-router.org/pipermail/sr-users/2012-June/073621.html
From the http://tools.ietf.org/html/rfc3857#section-4.7.1, there is
nowhere to go if it it is in the terminated status.
subscribe,
policy= +----------+
reject | |<------------------------+
+------------>|terminated|<---------+ |
| | | | |
| | | |noresource |
| +----------+ |rejected |
| ^noresource |deactivated |
| |rejected |probation |
| |deactivated |timeout |noresource
| |probation | |rejected
| |giveup | |giveup
| | | |approved
+-------+ +-------+ +-------+ |
| |subscribe| |approved| | |
| init |-------->|pending|------->|active | |
| |no policy| | | | |
| | | | | | |
+-------+ +-------+ +-------+ |
| | ^ |
| subscribe, | | |
+-----------------------------------+ |
policy = accept | +-------+ |
| | | |
| |waiting|----------+
+----------->| |
timeout | |
+-------+
Figure 1: Subscription State Machine
just FYI, there were some discussions before regarding the deletion, state machine.
http://sip-router.org/tracker/index.php?do=details&task_id=133
http://lists.opensips.org/pipermail/devel/2009-August/003868.html
min
18 Jun
18 Jun
12:11 p.m.
New subject: simple test case: add user/delete user on kamailio 3.3 presence server
Hi,
On 06/15/2012 05:25 PM, Min Wang wrote:
| 1 | sip:103@192.168.122.32 | 101 |
192.168.122.32 |
presence | 2 | | 1339772803 |
then I deleted the 103 from the contact list, the watcher table still
shows the same.
For local storage, I'd expect an unsubscribe (subscribe with Expires=0)
from 101 to 103. The obvious work-flow would be to set it to
"terminated" in watchers table, and in case of a subsequent re-subscribe
it should be changed back to "pending" state, although the state-machine
doesn't indicate a transition from "terminated" back to "pending".
Isn't
this the case?
For xcap storage, there are other ways to block/remove a contact on/from
the list. As Iñaki pointed out in
http://lists.opensips.org/pipermail/devel/2009-August/003868.html, the
xcap server needs to notify the sip server about the change, which in
turn will notify the other party (103) that it's no longer allowed to
see 101's state. If the xcap_server module of kamailio is used, there is
the following code snippet in some examples floating around on the internet:
switch($rm) {
case "PUT":
xcaps_put("$var(uri)", "$hu", "$rb");
if($xcapuri(u=>auid)=~"pres-rules") {
pres_update_watchers("$var(uri)", "presence");
pres_refresh_watchers("$var(uri)", "presence", 1);
}
So, shouldn't this update the watchers accordingly? Anyways, also in
this case the watcher state should change to "terminated", and in case
of a re-subscribe it should go back to pending if xcap rules are
allowing this.
Maybe someone with good xcap_server/presence insights could elaborate on
that?
Andreas
19 Jun
19 Jun
8:41 a.m.
New subject: simple test case: add user/delete user on kamailio 3.3 presence server
Hello,
On 6/18/12 2:11 PM, Andreas Granig wrote:
Hi,
On 06/15/2012 05:25 PM, Min Wang wrote:
to summarize, you say that when the contact is removed from the buddy
list, the watcher table is not updated to state terminated by
pres_update_watchers(...)?
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
| 1 | sip:103@192.168.122.32 | 101
| 192.168.122.32 |
presence | 2 | | 1339772803 |
then I deleted the 103 from the contact list, the watcher table still
shows the same.
For local storage, I'd expect an unsubscribe (subscribe with
Expires=0)
from 101 to 103. The obvious work-flow would be to set it to
"terminated" in watchers table, and in case of a subsequent re-subscribe
it should be changed back to "pending" state, although the state-machine
doesn't indicate a transition from "terminated" back to
"pending". Isn't
this the case?
For xcap storage, there are other ways to block/remove a contact on/from
the list. As Iñaki pointed out in
http://lists.opensips.org/pipermail/devel/2009-August/003868.html, the
xcap server needs to notify the sip server about the change, which in
turn will notify the other party (103) that it's no longer allowed to
see 101's state. If the xcap_server module of kamailio is used, there is
the following code snippet in some examples floating around on the internet:
switch($rm) {
case "PUT":
xcaps_put("$var(uri)", "$hu", "$rb");
if($xcapuri(u=>auid)=~"pres-rules") {
pres_update_watchers("$var(uri)", "presence");
pres_refresh_watchers("$var(uri)", "presence", 1);
}
So, shouldn't this update the watchers accordingly? Anyways, also in
this case the watcher state should change to "terminated", and in case
of a re-subscribe it should go back to pending if xcap rules are
allowing this.
Maybe someone with good xcap_server/presence insights could elaborate on
that?
10:47 a.m.
New subject: simple test case: add user/delete user on kamailio 3.3 presence server
Hi
(1) I tested more. It is due to the difference between bria 3 and jitsi
while handling the adding/removing contact:
if contact is added/removed:
for jitsi, it send out:
PUT /xcap-root/resource-lists/users/sip:101@192.168.122.32/index
PUT /xcap-root/pres-rules/users/sip:101@192.168.122.32/presrules
for bria 3, it only send out
PUT
/xcap-root/resource-lists/users/101(a)192.168.122.32/contacts-resource-list.xml
HTTP/1.0.
PUT
/xcap-root/resource-lists/users/101(a)192.168.122.32/contacts-resource-list.xml
it does NOT send out the pres-rules.
Is it the good behavior ( from RFC point of view) ?
should I call the pres_update_watchers even though its is for
resource-lists?
(2) BTW, what is the exact purpose of watcher table?
e.g: on 101, if delete 103, watcher table become:
id presentity_uri watcher_username
watcher_domain event status reason inserted_time
1 sip:103@192.168.122.32 101 192.168.122.32
presence 1 1340096051
2 sip:101@192.168.122.32 103 192.168.122.32
presence 3 terminated 1340096181
it is item 2 become terminated instead of item 1. If watcher table
is for subscription, then seems item 1 should be terminated?
Look at the code, it seems somehow serve as mixed role of
subscription/auth/xcap purpose, not for subscription state?
and is the active_watcher mainly for the state machine of
http://tools.ietf.org/html/rfc3857#section-4.7.1?
thanks.
min
On 06/19/2012 10:41 AM, Daniel-Constantin Mierla wrote:
Hello,
On 6/18/12 2:11 PM, Andreas Granig wrote:
Hi,
On 06/15/2012 05:25 PM, Min Wang wrote:
to summarize, you say that when the contact is removed from the buddy
list, the watcher table is not updated to state terminated by
pres_update_watchers(...)?
Cheers,
Daniel
| 1 | sip:103@192.168.122.32 | 101
| 192.168.122.32 |
presence | 2 | | 1339772803 |
then I deleted the 103 from the contact list, the watcher table
still
shows the same.
For local storage, I'd expect an unsubscribe (subscribe with
Expires=0)
from 101 to 103. The obvious work-flow would be to set it to
"terminated" in watchers table, and in case of a subsequent re-subscribe
it should be changed back to "pending" state, although the state-machine
doesn't indicate a transition from "terminated" back to
"pending". Isn't
this the case?
For xcap storage, there are other ways to block/remove a contact on/from
the list. As Iñaki pointed out in
http://lists.opensips.org/pipermail/devel/2009-August/003868.html, the
xcap server needs to notify the sip server about the change, which in
turn will notify the other party (103) that it's no longer allowed to
see 101's state. If the xcap_server module of kamailio is used, there is
the following code snippet in some examples floating around on the
internet:
switch($rm) {
case "PUT":
xcaps_put("$var(uri)", "$hu", "$rb");
if($xcapuri(u=>auid)=~"pres-rules") {
pres_update_watchers("$var(uri)", "presence");
pres_refresh_watchers("$var(uri)", "presence", 1);
}
So, shouldn't this update the watchers accordingly? Anyways, also in
this case the watcher state should change to "terminated", and in case
of a re-subscribe it should go back to pending if xcap rules are
allowing this.
Maybe someone with good xcap_server/presence insights could elaborate on
that?
11 a.m.
New subject: simple test case: add user/delete user on kamailio 3.3 presence server
Hello,
you have to share the content of the messages sent, providing just the
url is not enough to see what happens.
watchers table is for the list of contacts and their global status in
regard to presentity, active_watchers is for keeping the presence dialogs.
Cheers,
Daniel
On 6/19/12 12:47 PM, Min Wang wrote:
Hi
(1) I tested more. It is due to the difference between bria 3 and
jitsi while handling the adding/removing contact:
if contact is added/removed:
for jitsi, it send out:
PUT /xcap-root/resource-lists/users/sip:101@192.168.122.32/index
PUT /xcap-root/pres-rules/users/sip:101@192.168.122.32/presrules
for bria 3, it only send out
PUT
/xcap-root/resource-lists/users/101(a)192.168.122.32/contacts-resource-list.xml
HTTP/1.0.
PUT
/xcap-root/resource-lists/users/101(a)192.168.122.32/contacts-resource-list.xml
it does NOT send out the pres-rules.
Is it the good behavior ( from RFC point of view) ?
should I call the pres_update_watchers even though its is for
resource-lists?
(2) BTW, what is the exact purpose of watcher table?
e.g: on 101, if delete 103, watcher table become:
id presentity_uri watcher_username
watcher_domain event status reason inserted_time
1 sip:103@192.168.122.32 101 192.168.122.32 presence
1 1340096051
2 sip:101@192.168.122.32 103 192.168.122.32 presence 3
terminated 1340096181
it is item 2 become terminated instead of item 1. If watcher table
is for subscription, then seems item 1 should be terminated?
Look at the code, it seems somehow serve as mixed role of
subscription/auth/xcap purpose, not for subscription state?
and is the active_watcher mainly for the state machine of
http://tools.ietf.org/html/rfc3857#section-4.7.1?
thanks.
min
On 06/19/2012 10:41 AM, Daniel-Constantin Mierla wrote:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
Hello,
On 6/18/12 2:11 PM, Andreas Granig wrote:
Hi,
On 06/15/2012 05:25 PM, Min Wang wrote:
to summarize, you say that when the contact is removed from the buddy
list, the watcher table is not updated to state terminated by
pres_update_watchers(...)?
Cheers,
Daniel
| 1 | sip:103@192.168.122.32 | 101
| 192.168.122.32 |
presence | 2 | | 1339772803 |
then I deleted the 103 from the contact list, the watcher table
still
shows the same.
For local storage, I'd expect an unsubscribe (subscribe with
Expires=0)
from 101 to 103. The obvious work-flow would be to set it to
"terminated" in watchers table, and in case of a subsequent
re-subscribe
it should be changed back to "pending" state, although the
state-machine
doesn't indicate a transition from "terminated" back to
"pending".
Isn't
this the case?
For xcap storage, there are other ways to block/remove a contact
on/from
the list. As Iñaki pointed out in
http://lists.opensips.org/pipermail/devel/2009-August/003868.html, the
xcap server needs to notify the sip server about the change, which in
turn will notify the other party (103) that it's no longer allowed to
see 101's state. If the xcap_server module of kamailio is used,
there is
the following code snippet in some examples floating around on the
internet:
switch($rm) {
case "PUT":
xcaps_put("$var(uri)", "$hu", "$rb");
if($xcapuri(u=>auid)=~"pres-rules") {
pres_update_watchers("$var(uri)", "presence");
pres_refresh_watchers("$var(uri)", "presence", 1);
}
So, shouldn't this update the watchers accordingly? Anyways, also in
this case the watcher state should change to "terminated", and in case
of a re-subscribe it should go back to pending if xcap rules are
allowing this.
Maybe someone with good xcap_server/presence insights could
elaborate on
that? 
11:46 a.m.
New subject: simple test case: add user/delete user on kamailio 3.3 presence server
HI Daniel
please see the attached trace files.
notes:
192.168.122.32 is the kamailio proxy
192.168.122.224 is the 101 client ( bria or jitsi)
192.168.122.1 is 103 client ( always jitsi)
the client is configedto use xcap server at
http://192.168.122.224:1080 which is proxied to kamailio proxy port 5060.
and the kamailio.cfg is something:
...
switch($rm) {
case "PUT":
xcaps_put("$var(uri)", "$hu",
"$rb");
if($xcapuri(u=>auid)=~"pres-rules")
{
xlog("===== xhttp put:
refreshing watchers for $var(uri)\n");
pres_update_watchers("$var(uri)", "presence");
pres_refresh_watchers("$var(uri)", "presence", 1);
}
else if
($xcapuri(u=>auid)=~"resource-lists"
||
$xcapuri(u=>auid)=~"rls-services") {
rls_update_subs("$var(uri)",
"presence");
}
exit;
break;
case "GET":
xlog("===== xhttp: get $var(uri) =>
$hu\n");
xcaps_get("$var(uri)", "$hu");
exit;
break;
case "DELETE":
xcaps_del("$var(uri)", "$hu");
if($xcapuri(u=>auid)=~"pres-rules")
{
xlog("===== xhttp del:
refreshing watchers for $var(uri)\n");
pres_update_watchers("$var(uri)", "presence");
pres_refresh_watchers("$var(uri)", "presence", 1);
}
else if
($xcapuri(u=>auid)=~"resource-lists"
||
$xcapuri(u=>auid)=~"rls-services") {
rls_update_subs("$var(uri)",
"presence");
}
exit;
break;
...
thanks.
min
On 06/19/2012 01:00 PM, Daniel-Constantin Mierla wrote:
Hello,
you have to share the content of the messages sent, providing just the
url is not enough to see what happens.
watchers table is for the list of contacts and their global status in
regard to presentity, active_watchers is for keeping the presence dialogs.
Cheers,
Daniel
On 6/19/12 12:47 PM, Min Wang wrote:
Hi
(1) I tested more. It is due to the difference between bria 3 and
jitsi while handling the adding/removing contact:
if contact is added/removed:
for jitsi, it send out:
PUT /xcap-root/resource-lists/users/sip:101@192.168.122.32/index
PUT /xcap-root/pres-rules/users/sip:101@192.168.122.32/presrules
for bria 3, it only send out
PUT
/xcap-root/resource-lists/users/101(a)192.168.122.32/contacts-resource-list.xml
HTTP/1.0.
PUT
/xcap-root/resource-lists/users/101(a)192.168.122.32/contacts-resource-list.xml
it does NOT send out the pres-rules.
Is it the good behavior ( from RFC point of view) ?
should I call the pres_update_watchers even though its is for
resource-lists?
(2) BTW, what is the exact purpose of watcher table?
e.g: on 101, if delete 103, watcher table become:
id presentity_uri watcher_username
watcher_domain event status reason inserted_time
1 sip:103@192.168.122.32 101 192.168.122.32
presence 1 1340096051
2 sip:101@192.168.122.32 103 192.168.122.32
presence 3 terminated 1340096181
it is item 2 become terminated instead of item 1. If watcher
table is for subscription, then seems item 1 should be terminated?
Look at the code, it seems somehow serve as mixed role of
subscription/auth/xcap purpose, not for subscription state?
and is the active_watcher mainly for the state machine of
http://tools.ietf.org/html/rfc3857#section-4.7.1?
thanks.
min
On 06/19/2012 10:41 AM, Daniel-Constantin Mierla wrote:
--
Daniel-Constantin Mierla -http://www.asipto.com
http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hello,
On 6/18/12 2:11 PM, Andreas Granig wrote:
Hi,
On 06/15/2012 05:25 PM, Min Wang wrote:
> | 1 | sip:103@192.168.122.32 | 101 | 192.168.122.32 |
> presence | 2 | | 1339772803 |
>
> then I deleted the 103 from the contact list, the watcher
> table still
> shows the same.
For local storage, I'd expect an unsubscribe (subscribe with
Expires=0)
from 101 to 103. The obvious work-flow would be to set it to
"terminated" in watchers table, and in case of a subsequent
re-subscribe
it should be changed back to "pending" state, although the
state-machine
doesn't indicate a transition from "terminated" back to
"pending".
Isn't
this the case?
For xcap storage, there are other ways to block/remove a contact
on/from
the list. As Iñaki pointed out in
http://lists.opensips.org/pipermail/devel/2009-August/003868.html, the
xcap server needs to notify the sip server about the change, which in
turn will notify the other party (103) that it's no longer allowed to
see 101's state. If the xcap_server module of kamailio is used,
there is
the following code snippet in some examples floating around on the
internet:
switch($rm) {
case "PUT":
xcaps_put("$var(uri)", "$hu", "$rb");
if($xcapuri(u=>auid)=~"pres-rules") {
pres_update_watchers("$var(uri)", "presence");
pres_refresh_watchers("$var(uri)", "presence", 1);
}
So, shouldn't this update the watchers accordingly? Anyways, also in
this case the watcher state should change to "terminated", and in case
of a re-subscribe it should go back to pending if xcap rules are
allowing this.
Maybe someone with good xcap_server/presence insights could
elaborate on
that?
to summarize, you say that when the contact is removed from the
buddy list, the watcher table is not updated to state terminated by
pres_update_watchers(...)?
Cheers,
Daniel
5:15 p.m.
New subject: simple test case: add user/delete user on kamailio 3.3 presence server
Hi
Here is another similar case which does not work. maybe it is related
the above issue as well.
Jitsi 1.1 client: 101/103 , with xcap as storage
proxy: kamailio 3.3
ip network is: 192.168.122.0
the setup is like the following:
101(.224) --- proxy (.32) --- 103 (.1)
After all presence related db are truncated, kamailio was restart. then
bring 101,103 online.
On 101 add 103, 103 prompt up authorization window, click ok.
now on 103, I can see 101 online status
but on 101, I can not see 103 status <----the first trace file: the
jitsi-101-add-103-confirm-2.pcap
(it is grey, even manually change 103 status from online to away etc,
on 101, the 103 always showed grey. <--- second trace file:
jitsi-101-103-change.pcap)
Please see the attached pcap files.
the watcher table shows:
id presentity_uri watcher_username watcher_domain
event status reason inserted_time
1 sip:103@192.168.122.32 101 192.168.122.32
presence 2 1340114579
2 sip:101@192.168.122.32 103 192.168.122.32
presence 1 1340114582
the active wacher table show:
id presentity_uri watcher_username watcher_domain
to_user to_domain event event_id to_tag from_tag
callid local_cseq remote_cseq contact record_route
expires status reason version socket_info
local_contact from_user from_domain updated updated_winfo
1 sip:101@192.168.122.32 101 192.168.122.32
101 192.168.122.32 message-summary
a6a1c5f60faecf035a1ae5b6e96e979a-7e2e 8b6ca8e7
9e8288d04d0dab18fda28f5fb24b40d8(a)0.0.0.0 1 2
sip:101@192.168.122.224:5060;transport=udp;registe...
1340117922 1 1 udp:192.168.122.32:5060
sip:192.168.122.32:5060;transport=udp 101 192.168.122.32 -1 -1
2 sip:101@192.168.122.32 101 192.168.122.32
101 192.168.122.32 presence.winfo
a6a1c5f60faecf035a1ae5b6e96e979a-8a99 9975004d
9b8cb0735bc559232639aa28c16a6f4b(a)0.0.0.0 2 2
sip:101@192.168.122.224:5060;transport=udp;registe...
1340117921 1 2 udp:192.168.122.32:5060
sip:192.168.122.32:5060;transport=udp 101 192.168.122.32 -1 -1
3 sip:103@192.168.122.32 103 192.168.122.32
103 192.168.122.32 message-summary
a6a1c5f60faecf035a1ae5b6e96e979a-0117 9d873afb
30fa1ce8cca7a7c50fea11e688ec3d5e@0:0:0:0:0:0:0:0 1 2
sip:103@192.168.122.1:5060;transport=udp;registeri...
1340117959 1 1 udp:192.168.122.32:5060
sip:192.168.122.32:5060;transport=udp 103 192.168.122.32 -1 -1
4 sip:103@192.168.122.32 103 192.168.122.32
103 192.168.122.32 presence.winfo
a6a1c5f60faecf035a1ae5b6e96e979a-9a71 101d721c
148be0ec1a4acc087c0083324398cf14@0:0:0:0:0:0:0:0 2 2
sip:103@192.168.122.1:5060;transport=udp;registeri...
1340117959 1 2 udp:192.168.122.32:5060
sip:192.168.122.32:5060;transport=udp 103 192.168.122.32 -1 -1
5 sip:103@192.168.122.32 101 192.168.122.32
103 192.168.122.32 presence
a6a1c5f60faecf035a1ae5b6e96e979a-5ab7 e9099546
6ed81a0fa2042996295974b671a8074f(a)0.0.0.0 1 2
sip:101@192.168.122.224:5060;transport=udp;registe...
1340118179 2 1 udp:192.168.122.32:5060
sip:192.168.122.32:5060;transport=udp 101 192.168.122.32 -1 -1
6 sip:101@192.168.122.32 103 192.168.122.32
101 192.168.122.32 presence
a6a1c5f60faecf035a1ae5b6e96e979a-98a8
thanks
min
On 06/19/2012 01:00 PM, Daniel-Constantin Mierla wrote:
Hello,
you have to share the content of the messages sent, providing just the
url is not enough to see what happens.
watchers table is for the list of contacts and their global status in
regard to presentity, active_watchers is for keeping the presence dialogs.
Cheers,
Daniel
On 6/19/12 12:47 PM, Min Wang wrote:
Hi
(1) I tested more. It is due to the difference between bria 3 and
jitsi while handling the adding/removing contact:
if contact is added/removed:
for jitsi, it send out:
PUT /xcap-root/resource-lists/users/sip:101@192.168.122.32/index
PUT /xcap-root/pres-rules/users/sip:101@192.168.122.32/presrules
for bria 3, it only send out
PUT
/xcap-root/resource-lists/users/101(a)192.168.122.32/contacts-resource-list.xml
HTTP/1.0.
PUT
/xcap-root/resource-lists/users/101(a)192.168.122.32/contacts-resource-list.xml
it does NOT send out the pres-rules.
Is it the good behavior ( from RFC point of view) ?
should I call the pres_update_watchers even though its is for
resource-lists?
(2) BTW, what is the exact purpose of watcher table?
e.g: on 101, if delete 103, watcher table become:
id presentity_uri watcher_username
watcher_domain event status reason inserted_time
1 sip:103@192.168.122.32 101 192.168.122.32
presence 1 1340096051
2 sip:101@192.168.122.32 103 192.168.122.32
presence 3 terminated 1340096181
it is item 2 become terminated instead of item 1. If watcher
table is for subscription, then seems item 1 should be terminated?
Look at the code, it seems somehow serve as mixed role of
subscription/auth/xcap purpose, not for subscription state?
and is the active_watcher mainly for the state machine of
http://tools.ietf.org/html/rfc3857#section-4.7.1?
thanks.
min
On 06/19/2012 10:41 AM, Daniel-Constantin Mierla wrote:
--
Daniel-Constantin Mierla -http://www.asipto.com
http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hello,
On 6/18/12 2:11 PM, Andreas Granig wrote:
Hi,
On 06/15/2012 05:25 PM, Min Wang wrote:
> | 1 | sip:103@192.168.122.32 | 101 | 192.168.122.32 |
> presence | 2 | | 1339772803 |
>
> then I deleted the 103 from the contact list, the watcher
> table still
> shows the same.
For local storage, I'd expect an unsubscribe (subscribe with
Expires=0)
from 101 to 103. The obvious work-flow would be to set it to
"terminated" in watchers table, and in case of a subsequent
re-subscribe
it should be changed back to "pending" state, although the
state-machine
doesn't indicate a transition from "terminated" back to
"pending".
Isn't
this the case?
For xcap storage, there are other ways to block/remove a contact
on/from
the list. As Iñaki pointed out in
http://lists.opensips.org/pipermail/devel/2009-August/003868.html, the
xcap server needs to notify the sip server about the change, which in
turn will notify the other party (103) that it's no longer allowed to
see 101's state. If the xcap_server module of kamailio is used,
there is
the following code snippet in some examples floating around on the
internet:
switch($rm) {
case "PUT":
xcaps_put("$var(uri)", "$hu", "$rb");
if($xcapuri(u=>auid)=~"pres-rules") {
pres_update_watchers("$var(uri)", "presence");
pres_refresh_watchers("$var(uri)", "presence", 1);
}
So, shouldn't this update the watchers accordingly? Anyways, also in
this case the watcher state should change to "terminated", and in case
of a re-subscribe it should go back to pending if xcap rules are
allowing this.
Maybe someone with good xcap_server/presence insights could
elaborate on
that?
to summarize, you say that when the contact is removed from the
buddy list, the watcher table is not updated to state terminated by
pres_update_watchers(...)?
Cheers,
Daniel
20 Jun
20 Jun
10:16 a.m.
New subject: simple test case: add user/delete user on kamailio 3.3 presence server
HI
This is another test case :
101/102 are jitsi client, but configured to use local storage mode, of
course they all use SIMPLE mode instead of peer-to-peer.
script is like:
if( is_method("SUBSCRIBE"))
{
$var(ret_code)= rls_handle_subscribe();
if($var(ret_code)== 10)
handle_subscribe();
t_release();
}
....
event_route[xhttp:request] {
...
xcap put/delete:
pres_update_watchers("$var(uri)", "presence");
pres_refresh_watchers("$var(uri)", "presence", 1);
...
}
when 101 add 102, auth window pop up, after click ok, but no presence on
both sides, all are grey.
Checked the the kamailio wathcer table, there are two items: 101<->102,
but both are in status=2 ( pending mode)
potential reason:
the current implemention of handle_subscribe() function does
not update the watcher table.
The only possible functions to update watcher table are:
pres_refresh_watchers/es_update_watcher.
since we do not have any xcap operation, so
pres_refresh_watchers/es_update_watcher never get called.
should we add pres_refresh_watchers/es_update_watcher after
handle_subscribe()?
or should handle_subscribe() should update the watcher table as well?
thanks
min
On 06/19/2012 10:41 AM, Daniel-Constantin Mierla wrote:
Hello,
On 6/18/12 2:11 PM, Andreas Granig wrote:
Hi,
On 06/15/2012 05:25 PM, Min Wang wrote:
to summarize, you say that when the contact is removed from the buddy
list, the watcher table is not updated to state terminated by
pres_update_watchers(...)?
Cheers,
Daniel
| 1 | sip:103@192.168.122.32 | 101
| 192.168.122.32 |
presence | 2 | | 1339772803 |
then I deleted the 103 from the contact list, the watcher table
still
shows the same.
For local storage, I'd expect an unsubscribe (subscribe with
Expires=0)
from 101 to 103. The obvious work-flow would be to set it to
"terminated" in watchers table, and in case of a subsequent re-subscribe
it should be changed back to "pending" state, although the state-machine
doesn't indicate a transition from "terminated" back to
"pending". Isn't
this the case?
For xcap storage, there are other ways to block/remove a contact on/from
the list. As Iñaki pointed out in
http://lists.opensips.org/pipermail/devel/2009-August/003868.html, the
xcap server needs to notify the sip server about the change, which in
turn will notify the other party (103) that it's no longer allowed to
see 101's state. If the xcap_server module of kamailio is used, there is
the following code snippet in some examples floating around on the
internet:
switch($rm) {
case "PUT":
xcaps_put("$var(uri)", "$hu", "$rb");
if($xcapuri(u=>auid)=~"pres-rules") {
pres_update_watchers("$var(uri)", "presence");
pres_refresh_watchers("$var(uri)", "presence", 1);
}
So, shouldn't this update the watchers accordingly? Anyways, also in
this case the watcher state should change to "terminated", and in case
of a re-subscribe it should go back to pending if xcap rules are
allowing this.
Maybe someone with good xcap_server/presence insights could elaborate on
that?
4346
days inactive
4351
days old
7 comments
4 participants
participants (4)
-
Andreas Granig -
Daniel-Constantin Mierla -
Min Wang -
Min Wang