29 Sep
2010
29 Sep
'10
4:38 p.m.
Hello,
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
Last build of SIP Communicator softphone was used to exemplify some use
cases.
xcap_server is a new module in upcoming v3.1.0, I have tested it with
several SIP clients, but I have to say is not easy to find one that
implements many presence & xcap extensions (filled already couple of
bugs so far). So consider it a young component by now, however, with it
inside our SIP server, deploying a SIP presence server becomes trivial.
Hope is helpful,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
29 Sep
29 Sep
4:55 p.m.
New subject: [sr-dev] Tutorial: SIP SIMPLE Presence Made Simple with Kamailio 3.1
Hi Daniel,
absolutely great! Thank you!
Carsten
2010/9/29 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
Hello,
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
Last build of SIP Communicator softphone was used to exemplify some use
cases.
xcap_server is a new module in upcoming v3.1.0, I have tested it with
several SIP clients, but I have to say is not easy to find one that
implements many presence & xcap extensions (filled already couple of bugs so
far). So consider it a young component by now, however, with it inside our
SIP server, deploying a SIP presence server becomes trivial.
Hope is helpful,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Carsten Bock
Schomburgstr. 80
22767 Hamburg
Germany
Mobile +49 179 2021244
Home +49 40 34927217
Fax +49 40 34927218
mailto:carsten@bock.info
30 Sep
30 Sep
12:57 a.m.
New subject: [sr-dev] Tutorial: SIP SIMPLE Presence Made Simple with Kamailio 3.1
2010/9/29 Carsten Bock <lists(a)bock.info>fo>:
> 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):
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
12:14 p.m.
New subject: [sr-dev] Tutorial: SIP SIMPLE Presence Made Simple with Kamailio 3.1
On 9/30/10 12:57 AM, Iñaki Baz Castillo wrote:
2010/9/29 Carsten Bock<lists(a)bock.info>fo>:
added in the
wiki, thanks. I will update module docs as well.
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?
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.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, the DELETE action should also trigger refresh actions (for example
it could be a partial DELETE removing a buddy or a specific rule)
12:51 p.m.
New subject: [sr-dev] Tutorial: SIP SIMPLE Presence Made Simple with Kamailio 3.1
2010/9/30 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
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.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
12:53 a.m.
New subject: [Kamailio-Business] Tutorial: SIP SIMPLE Presence Made Simple with Kamailio 3.1
2010/9/29 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
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"
:)
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
12:10 p.m.
New subject: [Kamailio-Business] Tutorial: SIP SIMPLE Presence Made Simple with Kamailio 3.1
On 9/30/10 12:53 AM, Iñaki Baz Castillo wrote:
2010/9/29 Daniel-Constantin
Mierla<miconda(a)gmail.com>om>:
thanks, fixed.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.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"
:) 
1 Oct
1 Oct
6:10 p.m.
New subject: Tutorial: SIP SIMPLE Presence Made Simple with Kamailio 3.1
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.
7:47 p.m.
New subject: Tutorial: SIP SIMPLE Presence Made Simple with Kamailio 3.1
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(a)yandex.ru>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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
2 Oct
2 Oct
10:37 a.m.
New subject: Tutorial: SIP SIMPLE Presence Made Simple with Kamailio 3.1
Hello Andrey,
On 10/1/10 7:47 PM, Rouskol Andrey wrote:
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
But here is like this because your client uses user@domain in username
field for authentication, right?
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?
Cheers,
Daniel
01.10.10, 20:12, "Rouskol
Andrey"<anry-dev(a)yandex.ru>ndex.ru>:
--
Daniel-Constantin Mierla
http://www.asipto.com
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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
4 Oct
4 Oct
3:37 p.m.
New subject: Tutorial: SIP SIMPLE Presence Made Simple with Kamailio 3.1
Daniel,
02.10.10, 12:37, "Daniel-Constantin Mierla" <miconda(a)gmail.com>om>:
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.
5 Oct
5 Oct
9:46 a.m.
New subject: Tutorial: SIP SIMPLE Presence Made Simple with Kamailio 3.1
Hello,
On 10/4/10 3:37 PM, Rouskol Andrey wrote:
--
Daniel-Constantin Mierla
http://www.asipto.com
Daniel,
02.10.10, 12:37, "Daniel-Constantin Mierla"<miconda(a)gmail.com>ail.com>:
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
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.
_______________________________________________
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
2:50 p.m.
New subject: Tutorial: SIP SIMPLE Presence Made Simple with Kamailio 3.1
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(a)gmail.com>om>:
Hello,
On 10/4/10 3:37 PM, Rouskol Andrey wrote:
Daniel,
02.10.10, 12:37, "Daniel-Constantin Mierla":
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
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.
_______________________________________________
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
4:07 p.m.
New subject: Tutorial: SIP SIMPLE Presence Made Simple with Kamailio 3.1
Daniel,
What whould you think about this variant:
event_route[xhttp:request] {
xlog("L_INFO", "===== xhttp: request [$rv] $rm => $hu\n");
xdbg("===== xhttp: request [$rv] $rm => $hu\n");
if($hu=~"^/xcap-root/")
{
# xcap ops
$xcapuri(u=>data) = $hu;
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;
xlog("L_INFO", "===== xhttp: $xcapuri(u=>auid) :
$xcapuri(u=>xuid)\n");
if($xcapuri(u=>auid)=="xcap-caps")
{
set_reply_close();
set_reply_no_connect();
$var(xbody) =
..
xhttp_reply("200", "ok",
"application/xcap-caps+xml",
"$var(xbody)");
exit;
}
#!ifdef WITH_XHTTPAUTH
#!ifdef WITH_MULTIDOMAIN
if (!www_authorize("$(var(uri){uri.host})", "subscriber")) {
www_challenge("$(var(uri){uri.host})", "0");
#!else
if (!www_authorize("xcap", "subscriber")) {
www_challenge("xcap", "0");
#!endif
exit;
}
set_reply_close();
set_reply_no_connect();
#!ifdef WITH_XHTTPAUTH
# be sure auth user access only its documents
#!ifdef WITH_MULTIDOMAIN
if($aU=~".+@.+")
$var(tmp) = "sip:"+$aU;
else
$var(tmp) = "sip:"+$aU+"@"+$(var(uri){uri.host});
if ($var(uri)!=$var(tmp)) {
xlog("L_INFO", "===== xhttp: Forbidden!!! $var(tmp) -
$var(uri)\n");
#!else
if ($au!=$(var(uri){uri.user})) {
xlog("L_INFO", "===== xhttp: Forbidden!!! $au -
$(var(uri){uri.user})\n");
#!endif
..
Regards,
Andrey.
2 Oct
2 Oct
10:30 a.m.
New subject: Tutorial: SIP SIMPLE Presence Made Simple with Kamailio 3.1
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
--
Daniel-Constantin Mierla
http://www.asipto.com
4955
days inactive
4961
days old
14 comments
4 participants
participants (4)
-
Carsten Bock -
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Rouskol Andrey