12 Jun
2012
12 Jun
'12
5:28 a.m.
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
thanks.
min
12 Jun
12 Jun
6:10 a.m.
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
--
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
6:51 a.m.
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(a)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(a)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
13 Jun
13 Jun
4:21 a.m.
Hello,
On 6/12/12 12:51 PM, Min Wang wrote:
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(a)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(a)192.168.51.20]
Yes, prefixing with 'sip:' is required in such case, as it has to get to
a full sip uri format.
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. :(
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.
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
Cheers,
Daniel
kind regards.
min
On 06/12/2012 12:10 PM, 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/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
4:45 a.m.
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
4:52 a.m.
Min Wang writes:
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.
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.
-- juha
5:35 a.m.
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
5:50 a.m.
Andreas Granig writes:
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
-- juha
7:42 a.m.
Hi Juha,
On 06/13/2012 11:50 AM, Juha Heinanen wrote:
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
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
10:34 a.m.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
11:10 a.m.
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
11:35 a.m.
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
11:07 a.m.
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.
conclusion: presence in jitsi is still broken.
-- juha
11:58 a.m.
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(a)jitsi.java.net mailing list with a link
to this thread, so they realize that their implementation gets some
attraction.
Andreas
4579
days inactive
4580
days old
14 comments
4 participants
participants (4)
-
Andreas Granig -
Daniel-Constantin Mierla -
Juha Heinanen -
Min Wang