2010/9/29 Carsten Bock lists@bock.info:

...

I published a tutorial of how to implement a SIP SIMPLE Presence & XCAP server with latest Kamailio/SER version. You can find it at: http://bit.ly/btrJij

Hi, the DELETE action should also trigger refresh actions (for example it could be a partial DELETE removing a buddy or a specific rule):

2010/9/30 Daniel-Constantin Mierla miconda@gmail.com:

I wonder if a delete can change the status of watcher. Usually is translation from none to pending to active, but can be other way around triggered by xcap operation?

In OMA specs *any* change (PUT/DELETE) in resource-lists document must trigger a reload of pres-rules and other applications including references to lists in 'resource-lists'. The same in 'pres-rules' document, sure.

If for example Bob is included in <list id="friends> and such list is referred by <list id="oma_buddies"> and 'oma_buddies' is referred by a rule in pres-rules with action 'allow', then removing Bob from <list id="friends"> requires the *complete* (UGLY) pres-rules to be re-calculated so Bob's subscription status would change from "active" to "terminated".

Now to demostrate how ugly is all this stuff, let imagine you want to temporally block Bob (so he cannot see your current real presence status). According to OMA specs (and there are no other specs):

1) First you should do a partial DELETE operation in 'resource-list' to remove Bob uri from your granted <list>.

2) Later you should do a partial PUT operation in 'resource-lists' to include Bob in a <list id="oma_polite_blocked"> (or something similar).

Oppps, problem! After step 1 the presence server should *terminate* the subscription dialog with you (the watcher) so you receive a NOTIFY with "Subscription-Status: terminated;reason=rejected". Then it's *up to you* to subscribe to Bob again or not.

Imagine you subscribe again to Bob's presence upon receipt of the NOTIFY (but before the above step 2). Then your SUSBCRIBE would be rejected again. Will you try *again* a new SUSBCRIBE? for how long? After step 2, if you send a new SUBSCRIBE then the server will accept your subscription but notify you with false presence status (or no info at all) as you are polite-blocked.

Obviously this design is ugly. In contrast, in XMPP there is like an API to "authorize"/"desauthorize" a contact, "block" him... you must not deal with tedious XML files for *all*, neither you need to expect that the presence server and all your UA's (same AoR) interpret the whole XML documents in the same way (bob is included in "oma_granted" list but he is also included in 'pres-rules' document as a separate blocked entry, should I understand he is blocked or allowed? will the presence server understand the same as my UA?).

Also, in XMPP a change in your buddylist doesn't require the presence server to re-compute all the permissions of all your watchers.

Well, coming back to the original question: yes, any incremental/total change (PUT/DELETE) in pres-rules or resource-lists document should trigger a complete reload of watchers permissions. Also, the RLS application uses a reference to a <list> into resource-lists, so if a item in such list is modified the RLs should recompute the list of AoR's it must subscribe in behalf of the user (so ugly all of this...).

Regards.

On 9/30/10 12:53 AM, Iñaki Baz Castillo wrote:

2010/9/29 Daniel-Constantin Mierlamiconda@gmail.com:

...

I published a tutorial of how to implement a SIP SIMPLE Presence& XCAP server with latest Kamailio/SER version. You can find it at: http://bit.ly/btrJij

Hi, a typo:

"body lists - your contacts"

should be:

"buddy lists - your contacts"

:)

thanks, fixed.

Cheers, Daniel

Daniel,

In addition to my previous letter, for multidomain case, to prevent user@domain1 from changing xcaps for user@domain2, we need do something like this (withing second WITH_XHTTPAUTH section):

#!ifdef WITH_MULTIDOMAIN $var(tmp) = "sip:"+$aU; if ($var(uri)!=$var(tmp)) { #!else if ($au!=$(var(uri){uri.user})) { #!endif

Regards, Andrey.

01.10.10, 20:12, "Rouskol Andrey" anry-dev@yandex.ru:

Hello,

Daniel, could you verify your tutorial for cases with multidomain support. I've tried it (with curl as an xcap client) and I had to use user@domain:pass as an authentication string to pass through www_authorize("xcap", "subscriber"), after this I had to modify $var(url) assignment a little bit:

             if($xcapuri(u=>xuid)=~"^sip:.+@.+")
                     $var(uri) = $xcapuri(u=>xuid);
             else
                     if($xcapuri(u=>xuid)=~".+@.+")
                             $var(uri) = "sip:"+ $xcapuri(u=>xuid);
                     else
                             $var(uri) = "sip:"+ $xcapuri(u=>xuid) + "@" + $Ri;

Could you confirm, that it is correct, or point to my errors, please.

Regards, Andrey.

---

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

Daniel,

02.10.10, 12:37, "Daniel-Constantin Mierla" miconda@gmail.com:

But here is like this because your client uses user@domain in username field for authentication, right?

This is because www_authorize("xcap", "subscriber") requires me to use user@domain for authentication. I can not pass through it without domain. And I suppose that it becase of this: modparam("auth_db", "use_domain", MULTIDOMAIN).

However, in many cases, even in multi-domain environment, people still use only user part in username field and the domain is taken from R-URI or headers like From/To.

To make this complete for multi-domain, I think there must be a condition to check for domain in $aU and if missing, try to get it from other parts, right?

Daniel, you are the guru, not me. It was just an idea.

Regards, Andrey.

Daniel,

I've got your idea - sip communicator can not send user@domain when doing xcap requests. I've tested xcap with curl utility and my fault was to take it's behaviour as normal.

Regards, Andrey.

05.10.10, 11:46, "Daniel-Constantin Mierla" miconda@gmail.com:

Hello,

On 10/4/10 3:37 PM, Rouskol Andrey wrote:

...

Daniel,

02.10.10, 12:37, "Daniel-Constantin Mierla":

...

But here is like this because your client uses user@domain in username field for authentication, right?

This is because www_authorize("xcap", "subscriber") requires me to use user@domain for authentication. I can not pass through it without domain. And I suppose that it becase of this: modparam("auth_db", "use_domain", MULTIDOMAIN).

the multidomain is for database query in order to do select based on domain field, otherwise is ignored.

What sip phone do you use?

Cheers, Daniel

...

...

However, in many cases, even in multi-domain environment, people still use only user part in username field and the domain is taken from R-URI or headers like From/To.

To make this complete for multi-domain, I think there must be a condition to check for domain in $aU and if missing, try to get it from other parts, right?

Daniel, you are the guru, not me. It was just an idea.

Regards, Andrey.

---

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

Hello Andrey,

On 10/1/10 6:10 PM, Rouskol Andrey wrote:

Hello,

Daniel, could you verify your tutorial for cases with multidomain support. I've tried it (with curl as an xcap client) and I had to use user@domain:pass as an authentication string to pass through www_authorize("xcap", "subscriber"), after this I had to modify $var(url) assignment a little bit:

             if($xcapuri(u=>xuid)=~"^sip:.+@.+")
                     $var(uri) = $xcapuri(u=>xuid);
             else
                     if($xcapuri(u=>xuid)=~".+@.+")
                             $var(uri) = "sip:"+ $xcapuri(u=>xuid);
                     else
                             $var(uri) = "sip:"+ $xcapuri(u=>xuid) + "@" + $Ri;

Could you confirm, that it is correct, or point to my errors, please.

this looks correct, I added it on wiki. Will add to xcap_server readme as well.

Thanks, Daniel