Hi Min!

As your already digging into the standards please propose a solution for correct behavior :-)

On 26.06.2012 00:07, Min Wang wrote:

HI

I did more analysis:

as before, the configure is:

  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

now 101 remove 102 from its contact, proxy will send out NOTIFY to 102

(1) if reason=terminated returned in NOTIFY ( this is the current kamaili behavior)

According to RFC 3265: If no reason code or an unknown reason code is present, the client MAY attempt to re- subscribe at any time (unless a "retry-after" parameter is present, in which case the client SHOULD NOT attempt re-subscription until after the number of seconds specified by the "retry-after" parameter).

 Jitsi 1.1  nightly will keep on re-subscribe ( at some random time ).

 And kamailio/proxy will keep on reject the subscribe with: NOTIFY,

with reason=terminated.

It seems to waste some resources (bandwidth/db/cpu etc). Image if

there are a lot of deleted contacts :(.

(2) if reason=rejected returned in NOTIFY

 according to the same RFC:

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".


 So the client will not send any re-subscribe, which is good, will

save some resources.

 But there is an issue:

 when 101 add 102 again,  after 101 puting pres-rules (allow 102) to

the xcap server ,

 there will be two cases:

 (2.a). If that subscription expired, or deleted by the kamailio

timer ( I hope I understand the code correctly)

        of course kamailio will not send any NOTIFY (to 102).

 (2.b). if that subscription do still exist in active_watcher, that

subscriptions will be marked as active

        kamailio  will send  the NOTIFY to 102 indicating 101's status

       But from 102 point of view:  since the subscription has been

terminated , this notify will be rejected as 481 non-exist.

 In neither case, can 102 see 101's status ( since 102 to 101's

subscription has been rejected/terminated from 102 point of view)

So from pure end-user point of view,  that is not the expected

behavior. User expect the 102 can see 101's status since 101 now allow 102 again and 102 did not remove 101 from his contact list

The question is:  how can we do it right?

Thanks.

min

On 06/25/2012 05:43 PM, Min Wang wrote:

...

HI

when I removed 102 from 101's contact list (using jitsi nightly 1.1 build), kamailio 3.3 send out NOTIFY to 102 like this:

NOTIFY sip:102@192.168.122.147:5060;transport=udp;registering_acc=192_168_122_32 SIP/2.0. Via: SIP/2.0/UDP 192.168.122.32;branch=z9hG4bK1bfb.afbf0a85.0. To: sip:102@192.168.122.32;tag=f6a40771. From: sip:101@192.168.122.32;tag=a6a1c5f60faecf035a1ae5b6e96e979a-5724. CSeq: 4 NOTIFY. Call-ID: c7c52dd058268596ec84dd3c645a2f17@0.0.0.0. Content-Length: 0. User-Agent: kamailio (3.3.0-rc0 (x86_64/linux)). Max-Forwards: 70. Event: presence. Contact: sip:192.168.122.32:5060;transport=udp. Subscription-State: terminated;reason=terminated. <-----------------

Note the reason code is:terminated.

From rfc3265, The defined reason codes are: deactivated/ probation/rejected/ timeout/giveup/noresource

What is the reason to send: reason=terminated instead one of the well-defined reason codes?

There was a discussion regarding at:

http://sip-router.org/tracker/index.php?do=details&task_id=133 http://sip-router.org/tracker/index.php?do=details&task_id=133

but I did not see the explaination of reason=terminated.

Thanks

min

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Hi Min,

I also consider the "terminated" reason is not the best choice in this case. I think reason "deactivated" is more appropriate. Since you seem to have researched about this also, do you agree? I can do this change in the code.

Thanks and regards, Anca

On 06/26/2012 01:07 AM, Min Wang wrote:

HI

I did more analysis:

as before, the configure is:

   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

now 101 remove 102 from its contact, proxy will send out NOTIFY to 102

(1) if reason=terminated returned in NOTIFY ( this is the current kamaili behavior)

According to RFC 3265:
  If no reason code or an unknown reason code is present, the client MAY attempt to re-
 subscribe at any time (unless a "retry-after" parameter is present,
 in which case the client SHOULD NOT attempt re-subscription until
 after the number of seconds specified by the "retry-after"
 parameter).


  Jitsi 1.1  nightly will keep on re-subscribe ( at some random time ).

  And kamailio/proxy will keep on reject the subscribe with: NOTIFY,

with reason=terminated.

 It seems to waste some resources (bandwidth/db/cpu etc). Image if

there are a lot of deleted contacts :(.

(2) if reason=rejected returned in NOTIFY

  according to the same RFC:

 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".


  So the client will not send any re-subscribe, which is good, will

save some resources.

  But there is an issue:

  when 101 add 102 again,  after 101 puting pres-rules (allow 102) to

the xcap server ,

  there will be two cases:

  (2.a). If that subscription expired, or deleted by the kamailio

timer ( I hope I understand the code correctly)

         of course kamailio will not send any NOTIFY (to 102).

  (2.b). if that subscription do still exist in active_watcher, that

subscriptions will be marked as active

         kamailio  will send  the NOTIFY to 102 indicating 101's status

        But from 102 point of view:  since the subscription has been

terminated , this notify will be rejected as 481 non-exist.

  In neither case, can 102 see 101's status ( since 102 to 101's

subscription has been rejected/terminated from 102 point of view)

 So from pure end-user point of view,  that is not the expected

behavior. User expect the 102 can see 101's status since 101 now allow 102 again and 102 did not remove 101 from his contact list

 The question is:  how can we do it right?

Thanks.

min

On 06/25/2012 05:43 PM, Min Wang wrote:

...

HI

when I removed 102 from 101's contact list (using jitsi nightly 1.1 build), kamailio 3.3 send out NOTIFY to 102 like this:

NOTIFY sip:102@192.168.122.147:5060;transport=udp;registering_acc=192_168_122_32 SIP/2.0. Via: SIP/2.0/UDP 192.168.122.32;branch=z9hG4bK1bfb.afbf0a85.0. To: sip:102@192.168.122.32;tag=f6a40771. From: sip:101@192.168.122.32;tag=a6a1c5f60faecf035a1ae5b6e96e979a-5724. CSeq: 4 NOTIFY. Call-ID: c7c52dd058268596ec84dd3c645a2f17@0.0.0.0. Content-Length: 0. User-Agent: kamailio (3.3.0-rc0 (x86_64/linux)). Max-Forwards: 70. Event: presence. Contact:sip:192.168.122.32:5060;transport=udp. Subscription-State: terminated;reason=terminated.<-----------------

Note the reason code is:terminated.

From rfc3265, The defined reason codes are: deactivated/ probation/rejected/ timeout/giveup/noresource

What is the reason to send: reason=terminated instead one of the well-defined reason codes?

There was a discussion regarding at:

http://sip-router.org/tracker/index.php?do=details&task_id=133 http://sip-router.org/tracker/index.php?do=details&task_id=133

but I did not see the explaination of reason=terminated.

Thanks

min

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

On 26.06.2012 12:22, Min Wang wrote:

hi Anca

  thanks a lot for the quick response.

   As you see from the RFC3265,  deactivated means the client will

try to re-subscribe immediately, which seems to be not good neither.

  The ideal behavior could: stop the client to re-subscribe if it is

not allowed ( this could be done by reason=rejeceted), then make the client to re-subscribe once if it is allowed again, but how to achieve this step? Is there a RFC/protocol way to do it.

I think the client should be smart enough to retry also if the previous error was a "permanent" reasons, e.g. the client should try to resubscribe once a day, or after restart.

regards Klaus

   I have re-posted the issue to the sim-implementors :

https://lists.cs.columbia.edu/pipermail/sip-implementors/2012-June/028585.ht...

   As for the code change, could you please wait until there is a

further discussion on it?

thanks again.

min

On 06/26/2012 12:02 PM, Anca Vamanu wrote:

...

Hi Min,

I also consider the "terminated" reason is not the best choice in this case. I think reason "deactivated" is more appropriate. Since you seem to have researched about this also, do you agree? I can do this change in the code.

Thanks and regards, Anca

On 06/26/2012 01:07 AM, Min Wang wrote:

...

HI

I did more analysis:

as before, the configure is:

   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

now 101 remove 102 from its contact, proxy will send out NOTIFY to 102

(1) if reason=terminated returned in NOTIFY ( this is the current kamaili behavior)

According to RFC 3265:
  If no reason code or an unknown reason code is present, the

client MAY attempt to re- subscribe at any time (unless a "retry-after" parameter is present, in which case the client SHOULD NOT attempt re-subscription until after the number of seconds specified by the "retry-after" parameter).

  Jitsi 1.1  nightly will keep on re-subscribe ( at some random

time ).

  And kamailio/proxy will keep on reject the subscribe with: NOTIFY,

with reason=terminated.

 It seems to waste some resources (bandwidth/db/cpu etc). Image if

there are a lot of deleted contacts :(.

(2) if reason=rejected returned in NOTIFY

  according to the same RFC:

 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".

  So the client will not send any re-subscribe, which is good, will

save some resources.

  But there is an issue:

  when 101 add 102 again,  after 101 puting pres-rules (allow

102. to

the xcap server ,

  there will be two cases:

  (2.a). If that subscription expired, or deleted by the kamailio

timer ( I hope I understand the code correctly)

         of course kamailio will not send any NOTIFY (to 102).

  (2.b). if that subscription do still exist in active_watcher, that

subscriptions will be marked as active

         kamailio  will send  the NOTIFY to 102 indicating 101's

status

        But from 102 point of view:  since the subscription has been

terminated , this notify will be rejected as 481 non-exist.

  In neither case, can 102 see 101's status ( since 102 to 101's

subscription has been rejected/terminated from 102 point of view)

 So from pure end-user point of view,  that is not the expected

behavior. User expect the 102 can see 101's status since 101 now allow 102 again and 102 did not remove 101 from his contact list

 The question is:  how can we do it right?

Thanks.

min

On 06/25/2012 05:43 PM, Min Wang wrote:

...

HI

when I removed 102 from 101's contact list (using jitsi nightly 1.1 build), kamailio 3.3 send out NOTIFY to 102 like this:

NOTIFY sip:102@192.168.122.147:5060;transport=udp;registering_acc=192_168_122_32

SIP/2.0. Via: SIP/2.0/UDP 192.168.122.32;branch=z9hG4bK1bfb.afbf0a85.0. To: sip:102@192.168.122.32;tag=f6a40771. From: sip:101@192.168.122.32;tag=a6a1c5f60faecf035a1ae5b6e96e979a-5724. CSeq: 4 NOTIFY. Call-ID: c7c52dd058268596ec84dd3c645a2f17@0.0.0.0. Content-Length: 0. User-Agent: kamailio (3.3.0-rc0 (x86_64/linux)). Max-Forwards: 70. Event: presence. Contact:sip:192.168.122.32:5060;transport=udp. Subscription-State: terminated;reason=terminated.<-----------------

Note the reason code is:terminated.

From rfc3265, The defined reason codes are: deactivated/ probation/rejected/ timeout/giveup/noresource

What is the reason to send: reason=terminated instead one of the well-defined reason codes?

There was a discussion regarding at:

http://sip-router.org/tracker/index.php?do=details&task_id=133 http://sip-router.org/tracker/index.php?do=details&task_id=133

but I did not see the explaination of reason=terminated.

Thanks

min

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Hi Anca:

Thanks again!

please see my comment inline:

The "terminated" reason that is sent now, I think it's a bug, it was

probably mistaken with the Subscription-Status.

Yes, I guess so.

Let's say user A deletes user B from its contact list. Let's say 

user B will receive a Notify with reason 'rejected'. In this moment user B could also delete the authorization rule for user A.

Yah it could be. But from pure end user point of view, it is some kind of werid. B already allowed A to see its status. Why should B disable A to see its status just because of A's behavior ( disable B to its status). A, B should be independent of its contact list and pres-rules.

e.g: B is kind of generous people, do not mind A's behavior.

From my test with (jitsi with reason=rejected), jitsi B will not update any of its pres-rules/resource-list etc.

User B will be allowed again to see the presence of user A when 

user A will add B again in its contact list. This is the moment when you wanted to announce user B to subscribe again. This is actually be achieved, as user B will receive a Notification for presence.winfo that the user A requests authorization. And in this case probably most of the clients ask if you want to add that user in your contact list also. And this is the moment when user B will subscribe again to user A.

Yah, you are right. that could be the moment. I remembered from my trace I do see the Kamailio send out presence.winfo ( active) to B ( in this case B did not remove this pres-rules , otherwise the presence.winfo will be pending), unfornately jitsi B did nothing for this case of active presence.winfo.

From strict RFC point of view, sending presence.winfo does not mean B need to re-subscribe to A, this is our interpretation to solve this issue. So we have to convince the client people to do this way. will this behavior break any other things?

I found similar call flow on Oracle site, it is:

http://docs.oracle.com/cd/E17667_01/doc.50/e17669/cpt_concepts.htm#

in the Changing Presence Rules section:

5. Because Alice's updated policy does not authorize Bob as a watcher, the presence server sends a NOTIFY request to Bob's client, notifying him that his subscription is terminated. In the NOTIFY request, the Subscription-State header specifies terminated and the reason is set to probation. This ends Bob's subscription with the presence server and also ends the underlying SIP dialog. Bob's client responds with a 200 OK message.

It uses **probation** as the reason for updated xcap policy. Not sure if it is OMA standard or not or just Oracle interpretation.

kind regards.

min

There can be some other way to that the client knows to reSubscribe again when it has received a Subscription from a user that had previously rejected its subscription. This is just one behavior example.

In this way the moment of reattempting the Subscription is actually determined by an input of a human, which was probably also desired by the RFC.

Regards, Anca

On 06/26/2012 01:22 PM, Min Wang wrote:

...

hi Anca

   thanks a lot for the quick response.

    As you see from the RFC3265,  deactivated means the client will

try to re-subscribe immediately, which seems to be not good neither.

   The ideal behavior could: stop the client to re-subscribe if 

it is not allowed ( this could be done by reason=rejeceted), then make the client to re-subscribe once if it is allowed again, but how to achieve this step? Is there a RFC/protocol way to do it.

    I have re-posted the issue to the sim-implementors :

https://lists.cs.columbia.edu/pipermail/sip-implementors/2012-June/028585.ht...

    As for the code change, could you please wait until there is a

further discussion on it?

thanks again.

min

On 06/26/2012 12:02 PM, Anca Vamanu wrote:

...

Hi Min,

I also consider the "terminated" reason is not the best choice in this case. I think reason "deactivated" is more appropriate. Since you seem to have researched about this also, do you agree? I can do this change in the code.

Thanks and regards, Anca

On 06/26/2012 01:07 AM, Min Wang wrote:

...

HI

I did more analysis:

as before, the configure is:

    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

now 101 remove 102 from its contact, proxy will send out NOTIFY to 102

(1) if reason=terminated returned in NOTIFY ( this is the current kamaili behavior)

 According to RFC 3265:
   If no reason code or an unknown reason code is present, the

client MAY attempt to re- subscribe at any time (unless a "retry-after" parameter is present, in which case the client SHOULD NOT attempt re-subscription until after the number of seconds specified by the "retry-after" parameter).

   Jitsi 1.1  nightly will keep on re-subscribe ( at some random

time ).

   And kamailio/proxy will keep on reject the subscribe with: 

NOTIFY, with reason=terminated.

  It seems to waste some resources (bandwidth/db/cpu etc). 

Image if there are a lot of deleted contacts :(.

(2) if reason=rejected returned in NOTIFY

   according to the same RFC:

  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".

   So the client will not send any re-subscribe, which is good, 

will save some resources.

   But there is an issue:

   when 101 add 102 again,  after 101 puting pres-rules (allow

102. to

the xcap server ,

   there will be two cases:

   (2.a). If that subscription expired, or deleted by the kamailio

timer ( I hope I understand the code correctly)

          of course kamailio will not send any NOTIFY (to 102).

   (2.b). if that subscription do still exist in 

active_watcher, that subscriptions will be marked as active

          kamailio  will send  the NOTIFY to 102 indicating 101's

status

         But from 102 point of view:  since the subscription 

has been terminated , this notify will be rejected as 481 non-exist.

   In neither case, can 102 see 101's status ( since 102 to 101's

subscription has been rejected/terminated from 102 point of view)

  So from pure end-user point of view,  that is not the expected

behavior. User expect the 102 can see 101's status since 101 now allow 102 again and 102 did not remove 101 from his contact list

  The question is:  how can we do it right?

Thanks.

min

On 06/25/2012 05:43 PM, Min Wang wrote:

...

HI

when I removed 102 from 101's contact list (using jitsi nightly 1.1 build), kamailio 3.3 send out NOTIFY to 102 like this:

NOTIFY sip:102@192.168.122.147:5060;transport=udp;registering_acc=192_168_122_32

SIP/2.0. Via: SIP/2.0/UDP 192.168.122.32;branch=z9hG4bK1bfb.afbf0a85.0. To: sip:102@192.168.122.32;tag=f6a40771. From: sip:101@192.168.122.32;tag=a6a1c5f60faecf035a1ae5b6e96e979a-5724. CSeq: 4 NOTIFY. Call-ID: c7c52dd058268596ec84dd3c645a2f17@0.0.0.0. Content-Length: 0. User-Agent: kamailio (3.3.0-rc0 (x86_64/linux)). Max-Forwards: 70. Event: presence. Contact:sip:192.168.122.32:5060;transport=udp. Subscription-State: terminated;reason=terminated.<-----------------

Note the reason code is:terminated.

From rfc3265, The defined reason codes are: deactivated/ probation/rejected/ timeout/giveup/noresource

What is the reason to send: reason=terminated instead one of the well-defined reason codes?

There was a discussion regarding at:

http://sip-router.org/tracker/index.php?do=details&task_id=133 http://sip-router.org/tracker/index.php?do=details&task_id=133

but I did not see the explaination of reason=terminated.

Thanks

min

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

HI Klaus , Anca:

...

http://docs.oracle.com/cd/E17667_01/doc.50/e17669/cpt_concepts.htm#

in the Changing Presence Rules section:

          5. Because Alice's updated policy does not authorize Bob

as a watcher, the presence server sends a NOTIFY request to Bob's client, notifying him that his subscription is terminated. In the NOTIFY request, the Subscription-State header specifies terminated and the reason is set to probation. This ends Bob's subscription with the presence server and also ends the underlying SIP dialog. Bob's client responds with a 200 OK message.

       It uses **probation** as the reason for updated xcap policy.

Not sure if it is OMA standard or not or just Oracle interpretation.

What about adding a module parameter (string) with "probation" as default?

I guess it is a good solution from practical point of view.

Also how about adding another parameter as well: retry_after , something default 10 or 30 minutes?

thanks

min

HI Anca

That is great. I will test it and report back.

kind regards.

min

On 06/27/2012 05:39 PM, Anca Vamanu wrote:

Hi Min, Klaus,

I followed your suggestions and added a module parameter - xcapauth_userdel_reason in presence_xml module. It has default value "probation". The retry-after parameter can be added easily by just attaching it also to the end of the reason when setting this parameter.

3.10. xcapauth_userdel_reason(str)

This parameter represents the reason that will be included in the Subscription-State header of the Notify when a rule is no longer found in the XCAP pres-auth document for a user that was previously allowed. The Subscription state in this case switches to "terminated". Because it is not clear which reason is most appropriate in this case from the ones defined by the RFC 3265, this parameter offers the possibility for the admin to decide which one he wishes to use.

Default value: “probation” . Since probation also accepts a retry-after parameter to specify after at least how may seconds the client should reattempt to resubscribe, you can include this in the parameter also.

Example 1.10. Set xcapauth_userdel_reason parameter ... modparam("presence_xml", "xcapauth_userdel_reason", "probation;retry-after=30") modparam("presence_xml", "xcapauth_userdel_reason", "rejected")

Min, I would appreciate if you could test this and let me know.

Regards, Anca

On 06/26/2012 08:03 PM, Min Wang wrote:

...

HI Klaus , Anca:

...

...

http://docs.oracle.com/cd/E17667_01/doc.50/e17669/cpt_concepts.htm#

in the Changing Presence Rules section:

           5. Because Alice's updated policy does not authorize 

Bob as a watcher, the presence server sends a NOTIFY request to Bob's client, notifying him that his subscription is terminated. In the NOTIFY request, the Subscription-State header specifies terminated and the reason is set to probation. This ends Bob's subscription with the presence server and also ends the underlying SIP dialog. Bob's client responds with a 200 OK message.

        It uses **probation** as the reason for updated xcap 

policy. Not sure if it is OMA standard or not or just Oracle interpretation.

What about adding a module parameter (string) with "probation" as default?

    I guess it is a good  solution from practical point of view.

    Also how about adding another parameter as well: retry_after ,

something default 10 or 30 minutes?

thanks

min