HI Daniel:

thanks a lot for the explaination.

I have tried the jitsi and bria.

jitsi use this kind of xcap uri: /xcap/resource-lists/users/sip:w102@192.168.51.20/index

while bria/eyebeam use:

/xcap/org.openmobilealliance.pres-rules/users/w103@192.168.51.20/pres-rules

The bria/eyebeam client does not have starting "sip:" on the xuid part.

so for the bria case the $var(uri) need to be updated as:

$var(uri) = "sip:"+ $xcapuri(u=>xuid);

Otherwise the kamailio xcap will give some ERROR: pv [pv_trans.c:522]: invalid uri [w103@192.168.51.20]

It is the xcaps_put/del using $var(uri) that confuse me a little bit, I thought it would store $var(uri) in the db.

xcaps_put("$var(uri)", "$hu", "$rb"); xcaps_del("$var(uri)", "$hu");

After checking the db, it seems the doc_uri has been stored correctly.

It seems some magic happened in the function: xcaps_put("$var(uri)", "$hu", "$rb"); Just wondering why $var(uri) is needed if all the info are in $hu? I have not checked the source code. :(

kind regards.

min

On 06/12/2012 12:10 PM, Daniel-Constantin Mierla wrote:

Hello,

On 6/12/12 11:28 AM, Min Wang wrote:

...

Hi I am trying to use kamailio xcap server, saw the sample code:

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


why should the xuid  have sip:xx@domain.com format?

The xcap standard seems does not enforce the format on the xui part?

http://xcap.example.com/root/resource-lists/users/joe |-------------v-------------||------v------||---v---| document root AUID XUI

the xuid is not not changed -- $var(uri) is built out of it to get to a SIP address (for a coherent format with xuid with or without domain part), but in database the xcap uri is stored as received.

In sip, the user id is email-like address, some functions required that, so if the domain part is missing, then the local ip is used.

Have you encountered some problem due to this thing or is some field in database stored with wrong value?

Cheers, Daniel

HI Daniel thanks a lot.

Each xcap document is stored for a specific user, whose ID is taken from first parameter of xcap_put(...)/etc. Now the user id can be the same as in xcap url or something known only internally, looked up via some logic in config. In this way you have full flexibility, not hardcoding to use only what xcap url gives. Also, as you notice, the xcap url can have different variants, you can normalized to a desired one by script operations.

Yes, it make sense.:)

Not sure you spotted yet, there is a tutorial that might be useful reading as well:

http://kb.asipto.com/kamailio:presence:k31-made-simple

Yes, I have read your great tutorial.

BTW, it seems jitsi does not support RLS at this moment even though it store the contact list in the xcap?? I guess I should asked this in the jitsi mailing list.

min

Hi,

On 06/13/2012 10:52 AM, Juha Heinanen wrote:

my feeling is that there is no real commitment in jitsi for sip presence/xcap. i found a presence bug long time ago and reported it on jitsi tracker. so far nothing has happened.

For me, reporting a presence bug on the jitsi-users mailing list, along with pointing out exactly where in the code and how to fix it eventually worked. Did you get in touch with them on one of the lists?

In my opinion, it's quite important to work with the client guys, because for some reason there are nearly no open source implementations out there which properly support presence, so Jitsi is already one of the better ones (what's the alternative?).

Andreas

Hi Juha,

On 06/13/2012 11:50 AM, Juha Heinanen wrote:

...

For me, reporting a presence bug on the jitsi-users mailing list, along with pointing out exactly where in the code and how to fix it eventually worked. Did you get in touch with them on one of the lists?

i don't remember if i send anything to mailing list. the bug is this if you want to try out:

http://java.net/jira/browse/JITSI-983

Looks like that has been addressed already. At least with svn trunk verison, it's sending SIP-If-Match with Expires: 0. Could be worth taking another try with a nightly 1.1 build?

Andreas

Hi Juha:

Just wondering which version of are you using on the kamailio server side ?

I've used kamailio 3.1, jitsi/bria are subscribed to each other and both's status=1 in the watchers.

If I restart jitsi, jitis did send publish from the trace, but kamailio did not send out the notification.

Could it be the 3.1 issue, or 3.3 or later is recommended?

thanks.

min

On 06/13/2012 04:04 PM, Juha Heinanen wrote:

Andreas Granig writes:

...

Looks like that has been addressed already. At least with svn trunk verison, it's sending SIP-If-Match with Expires: 0. Could be worth taking another try with a nightly 1.1 build?

yes, the bug is fixed in nightly build.

-- juha

---

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 Juha thanks a lot. Will do

min On 06/13/2012 05:10 PM, Juha Heinanen wrote:

Min Wang writes:

...

 Just wondering which version of are you using on the kamailio server

side ?

3.3.

...

 If I restart jitsi, jitis did send  publish from the trace, but

kamailio did not send out the notification.

try with kamailio 3.3 and tell exactly which publish you are talking about if the problem still persists.

-- juha

Hi Juha,

On 06/13/2012 05:07 PM, Juha Heinanen wrote:

i did some more presence tests with jitsi. when i start jitsi, it registers its sip uri, subscribes to its own presence.winfo and presence of another uri, and publishes its own presence.

when i then quit jitsi, it un-publishes its own presence, un-subscribes presence of the other uri, unregisters its own sip uri, and closes its tcp connection to kamailio. it does unregistering/closing before it has received notify from kamailio presence server to the un-subscribe. when presence server then tries to send the notify, it fails with syslog error, because tcp connection does not exist anymore.

Please send this to their users@jitsi.java.net mailing list with a link to this thread, so they realize that their implementation gets some attraction.

Andreas