Hi
I have the following case:
101 --- kamailio proxy/xcap server -- 102
101/102 : jitsi night build, xcap/SIMPLE mode
kamailio is 3.3
101 has 102 on its contacts list, and 102 has 101 on its contacts
list as well. ( no RLS involved)
(1) 101 add 102 to its contact list, what does it mean?
It seems that some(most?) sip clients' implemenatation ( at least for
jitsi or bria) assume:
101 will add 102 to its xcap resource-list, then 101 will subscribe
to 102's status
101 allow 102 to see its status by adding 102 to its allow list in
xcap pres-rules
(2) if 101 remove 102 from its contacts, what does it mean?
as in (1) that some(most?) sip clients' implemenatation ( at least
for jitsi or bria) assume:
101 remove 102 its from its xcap resource-list, 101 will un-subscribe
102's status
101 will not allow 102 to see its status by removing 102 from its
allow list in xcap pres-rules
(1)(2) so far seems reasonable.
(3) based on (1) and (2), let 101 remove 102 from its contacts list,
101 first remove 102 from its xcap pres-rules/resource-list, puts
those rules to the xcap server/proxy,
then send un-SUBSCRIBE ( expires=0 ).
proxy in this case will send out NOTIFY to 102 to indicate its
subscription of 101 has been terminated,
Subscription-State: terminated, reason=?
what should be the correct reason code?
according to the RFC 3265:
rejected: The subscription has been terminated due to change in
authorization policy. Clients SHOULD NOT attempt to re-subscribe.
The "retry-after" parameter has no semantics for "rejected".
It seems the rejected is the good choice.
Once client (102) received the rejected reason, the subscription
has been terminated, so it will NOT try to re-subscribe ( to 101)
again ( even though 101 is still in 102's contact list).
(4) But there is an issue, when 101 add 102 to its contact list again
In this case, 101 first puts pres-rules (allow 102 to see its
status), and resources-list( adding 102) to the xcap server ,
send subscribe to 102 to proxy,
The proxy( in our case kamailio) will try as following:
(4.a). If that subscription expired, or deleted by the kamailio
timer ( If understand kamailio code correctly)
of course kamailio will NOT send any NOTIFY (to 102) since
there is no such subscription..
(4.b). if that subscription do still exist in cache or db
(active_watcher in kamailio's case), that
subscriptions will be marked as active
kamailio/proxy will send the NOTIFY to 102 indicating
101's status
But from 102 point of view: since that subscription has been
terminated , this notify will be rejected as 481 non-exist. Is it right?
In neither case there is any way to indicate to 102 that 101 is
allowing 102 again,
thus 102 can NOT see 101's status.
is it correct?
(5) But from pure end-user point of view, that is not the expected
behavior.
User expect that 102 can see 101's status since 101 now allow
102 again
and 102 did not remove 101 from his contact list.
(6) are (1)-(5) above correct behavior based on the sip SIMPLE RFCs?
If so, how to solve the issue?
Is there any standard/RFC way to notify to 102 that 101 allow 102
again thus cause 102 to re-subscribe 101 again?
Just FYI, there was a discussion on it on the sip-router mailing list
http://lists.sip-router.org/pipermail/sr-users/2012-June/073759.html
Thanks.
min
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
