No subject

Wed Dec 21 17:12:16 CET 2011

RFC 3680), where the separate entity mentioned above acts as watcher for r=
eg-info events on all kamailio instances.
But I'm really looking=20at a simpler, lighter solution.

Regards,
Giacomo

From: Daniel-Constantin Mierla [mailto:miconda at gmail.com]
Sent: 20 January 2012 10:58
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users M=
ailing List
Cc: Giacomo Vacca
Subject: Re: [SR-Users] pua_usrloc, PUBLISH not send when contact is delet=
ed or expires

Hi Giacomo,

On 1/19/12 11:49 AM, Giacomo Vacca wrote:
Ah thanks Daniel,
So I had a wrong expectation on the behaviour of pua_usrloc.
It does make sense that the PUBLISH already carries its expiry and so the =
expiration moment is implicit and should/can be handled elsewhere.

I think what confused me were two things: the pua_usrloc documentation and=
 the fact that pua_usrloc does register for EXPIRE callbacks with usrloc.

I'm referring to:
"The pua_usrloc module is the connector between the usrloc and pua modules=
. It creates the environment to send PUBLISH requests for user location re=
cords, on specific events (e.g., when new record is added in usrloc, a PUB=
LISH with status open (online) is issued; when expires, it sends closed (o=
ffline))."

perhaps the documentation is misleading a bit with its phrasing. It send o=
ffline (closed) when it is an un-register, before the expiration. I haven'=
t looked in the code, but based on log messages and correlated with the ex=
pired carried by PUBLISH, the behavior is correct over all.

There is another aspect, usrloc cleans up expired records on timer, so usr=
loc callback can be executed later than actual expiration. A publish at th=
at time could be late. Of course, presence does cleanup on timer as well, =
but it may be more accurate to handle expiration there. It is like when an=
 UA with presence support disappears from networks, without sending any PU=
BLISH updates.

Cheers,
DAniel

From: Daniel-Constantin Mierla [mailto:miconda at gmail.com]
Sent: 19 January 2012 10:37
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users M=
ailing List
Cc: Giacomo Vacca
Subject: Re: [SR-Users] pua_usrloc, PUBLISH not send when contact is delet=
ed or expires

Hello,

On 1/19/12 11:22 AM, Giacomo Vacca wrote:
Hi Daniel,
Thanks for your feedback. Yes, using mysql and enabling presence made it w=
ork for un-registrations too.
Just for the purpose of this scenario I'm sending the PUBLISH back to the =
same entity, and it's being handled as a presentity.

I still have a missing piece though (which is in fact the reason for this =
configuration): having PUBLISH requests triggered by the expiration of a c=
ontact.

When a contact expires, pua_usrloc is now logging:

Jan 19 10:12:03 debian6 /usr/sbin/kamailio[4359]: INFO: pua_usrloc [ul_pub=
lish.c:211]: should not send ul publish

(please see below for traces and details).

Since I'm marking a registration with pua_set_publish(), why is that flag =
not seen as true when usrloc fires an EXPIRE callback?

I've tried marking every REGISTER request with pua_set_publish(), and not =
just the first one, before calling save("location") but the result was the=
 same.

the PUBLISH for registration expiration does not make sense, as PUBLISH ha=
s also an expire interval, so the record in the presence server should exp=
ire at the same time. A publish with update state to close will eventually=
 hit the presence server when there is no record for it. Presence server w=
ill send notifications when the record in its table expires.

Cheers,
Daniel

--

Daniel-Constantin Mierla -- http://www.asipto.com

http://linkedin.com/in/miconda -- http://twitter.com/miconda
Truphone Limited is a limited liability company registered in England & Wa=
les, registered office: 5 New Street Square, London EC4A 3TW. Registered N=
o. 04187081. VAT No. GB 851 5278 19.
Tru is a brand name of Truphone and is a Truphone Communications Service. =
Truphone is a trading name for a number of distinct legal entities that op=
erate in combination. www.truphone.com<http://www.truphone.com>.

This e-mail, and any attachment(s), may contain information which is confi=
dential and/or privileged, and is intended for the addressee only. If you =
are not the intended recipient, you may not use, disclose, copy or distrib=
ute this information in any manner whatsoever. If you have received this e=
-mail in error, please contact the sender immediately and delete it.

_______________________________________________

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list

sr-users at lists.sip-router.org<mailto:sr-users at lists.sip-router.org>

http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

--

Daniel-Constantin Mierla -- http://www.asipto.com

http://linkedin.com/in/miconda -- http://twitter.com/miconda
Truphone Limited is a limited liability company registered in England & Wa=
les, registered office: 4 Royal Mint Court, London, EC3N 4HJ. Registered N=
o. 04187081. VAT No. GB 851 5278 19.
Tru is a brand name of Truphone and is a Truphone Communications Service. =
Truphone is a trading name for a number of distinct legal entities that op=
erate in combination. www.truphone.com<http://www.truphone.com>.

This e-mail, and any attachment(s), may contain information which is confi=
dential and/or=20privileged, and is intended for the addressee only. If yo=
u are not the intended recipient, you may not use, disclose, copy or distr=
ibute this information in any manner whatsoever. If you have received this=
 e-mail in error, please contact the sender immediately and delete it.
--_000_A4E41C20520BEC409F1B16BA9FD72D34C83BBDitixex01_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii=
">
<style>
<!--
@font-face
=09{font-family:"Cambria Math"}
@font-face
=09{font-family:Calibri}
@font-face
=09{font-family:Tahoma}
@font-face
=09{font-family:Consolas}
@font-face
=09{font-family:"Times New Roman \, serif"}
p.MsoNormal, li.MsoNormal, div.MsoNormal
=09{margin:0cm;
=09margin-bottom:.0001pt;
=09font-size:11.0pt;
=09font-family:"Calibri","sans-serif";
=09color:black}
a:link, span.MsoHyperlink
=09{color:blue;
=09text-decoration:underline}
a:visited, span.MsoHyperlinkFollowed
=09{color:purple;
=09text-decoration:underline}
pre
=09{margin:0cm;
=09margin-bottom:.0001pt;
=09font-size:10.0pt;
=09font-family:"Courier New";
=09color:black}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
=09{margin:0cm;
=09margin-bottom:.0001pt;
=09font-size:8.0pt;
=09font-family:"Tahoma","sans-serif";
=09color:black}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
=09{margin-top:0cm;
=09margin-right:0cm;
=09margin-bottom:0cm;
=09margin-left:36.0pt;
=09margin-bottom:.0001pt;
=09font-size:11.0pt;
=09font-family:"Calibri","sans-serif";
=09color:black}
span.HTMLPreformattedChar
=09{font-family:Consolas;
=09color:black}
span.BalloonTextChar
=09{font-family:"Tahoma","sans-serif";
=09color:black}
p.msochpdefault, li.msochpdefault, div.msochpdefault
=09{margin-right:0cm;
=09margin-left:0cm;
=09font-size:12.0pt;
=09font-family:"Calibri","sans-serif";
=09color:black}
span.htmlpreformattedchar0
=09{font-family:Consolas;
=09color:black}
span.balloontextchar0
=09{font-family:"Tahoma","sans-serif";
=09color:black}
span.htmlpreformattedchar00
=09{font-family:Consolas;
=09color:black}
span.htmlpreformattedchar000
=09{font-family:Consolas;
=09color:black}
span.emailstyle17
=09{font-family:"Calibri","sans-serif";
=09color:windowtext}
span.htmlpreformattedchar0000
=09{font-family:Consolas;
=09color:black}
span.emailstyle23
=09{font-family:"Calibri","sans-serif";
=09color:#1F497D}
span.emailstyle24
=09{font-family:"Calibri","sans-serif";
=09color:#1F497D}
span.emailstyle28
=09{font-family:"Calibri","sans-serif";
=09color:#1F497D}
span.balloontextchar00
=09{font-family:"Tahoma","sans-serif";
=09color:black}
span.emailstyle31
=09{font-family:"Calibri","sans-serif";
=09color:#1F497D}
span.grame
=09{}
span.spelle
=09{}
span.EmailStyle36
=09{font-family:"Calibri","sans-serif";
=09color:#1F497D}
.MsoChpDefault
=09{font-size:10.0pt}
@page WordSection1
=09{margin:72.0pt 72.0pt 72.0pt 72.0pt}
div.WordSection1
=09{}
-->
</style>
</head>
<body bgcolor=3D"white" lang=3D"EN-GB" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Hi Daniel,</span></p>=

This is just great. I=
&#8217;ll test asap and report back.
&nbsp;
Cheers,
Giacomo
&nbsp;
<div>
<div style=3D"border:none; border-top:solid #B5C4DF 1.0pt; padding:3.0pt 0=
cm 0cm 0cm">
F=
rom: Daniel-Cons=
tantin Mierla
 [mailto:miconda at gmail.com] 
Sent: 27 January 2012 09:03 
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - =
Users Mailing List 
Cc: Giacomo Vacca 
Subject: Re: [SR-Users] pua_usrloc, PUBLISH not send when contact i=
s deleted or expires
</div>
</div>
&nbsp;
Hi Giacomo, 
 
I patched few days ago to make pua_usrloc sending the PUBLISH also for loc=
ation record expiration. 
 
<a href=3D"http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=3Dco=
mmit;h=3Dbdbacf559134022856f5723a91fe7e130ceada29">http://git.sip-router.o=
rg/cgi-bin/gitweb.cgi/sip-router/?a=3Dcommit;h=3Dbdbacf559134022856f5723a9=
1fe7e130ceada29</a> 
<a href=3D"http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=3Dco=
mmit;h=3D266fa4e2cd62f58ee1f2eec2a5a83bc3028d194a">http://git.sip-router.o=
rg/cgi-bin/gitweb.cgi/sip-router/?a=3Dcommit;h=3D266fa4e2cd62f58ee1f2eec2a=
5a83bc3028d194a</a> 
 
The idea is to set a branch flag for marking the contact for publishing --=
 pua_set_publish() can be still used actually, it sets also the branch fla=
g internally, if the module parameter specifying the flag is set -- altern=
ative is to use directly setbflag(index). 
 
I was out of office and couldn't try it yet, maybe you can test and report=
 if it is working fine. 
 
You have to install devel version, either from git or from nightly debs:<b=
r>
 
<a href=3D"http://www.kamailio.org/wiki/packages/debs#kamailio_development=
_-_nightly_builds">http://www.kamailio.org/wiki/packages/debs#kamailio_dev=
elopment_-_nightly_builds</a> 
 
Cheers, 
Daniel 
 
On 1/20/12 12:56 PM, Giacomo Vacca wrote: 
<div>
Thanks Daniel.=

What I&#8217;d like t=
o achieve is this: given a cluster of kamailio-based proxy/registrar, noti=
fy a separate entity whenever a contact is inserted or removed (either by =
deletion or expiration).
&nbsp;
I&#8217;d like this s=
eparate entity to be stateless (i.e. don&#8217;t manage expiry time), avoi=
d using a DB as shared information and have asynchronous notifications.</s=
pan>
&nbsp;
This is why I thought=
 pua_usrloc could help me, without the need of a full presence server in t=
he architecture to manage expiry times for presentities.
&nbsp;
What do you think cou=
ld be used to achieve this?
&nbsp;
From my point of view=
 the ideal solution is implementing reg-info events (RFC 3680), where the =
separate entity mentioned above acts as watcher for reg-info events on all=
 kamailio instances.
But I&#8217;m really =
looking at a simpler, lighter solution.
&nbsp;
Regards,
Giacomo
&nbsp;
&nbsp;
<div>
<div style=3D"border:none; border-top:solid #B5C4DF 1.0pt; padding:3.0pt 0=
cm 0cm 0cm">
F=
rom: Daniel-Cons=
tantin Mierla
 [<a href=3D"mailto:miconda at gmail.com">mailto:miconda at gmail.com</a>] 
Sent: 20 January 2012 10:58 
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - =
Users Mailing List 
Cc: Giacomo Vacca 
Subject: Re: [SR-Users] pua_usrloc, PUBLISH not send when contact i=
s deleted or expires
</div>
</div>
&nbsp;
Hi Giacomo, 
 
On 1/19/12 11:49 AM, Giacomo Vacca wrote: 
<div>
Ah thanks Daniel,</sp=
an>
So I had a wrong expe=
ctation on the behaviour of pua_usrloc.
It does make sense th=
at the PUBLISH already carries its expiry and so the expiration moment is =
implicit and should/can be handled elsewhere.
&nbsp;
I think what confused=
 me were two things: the pua_usrloc documentation and the fact that pua_us=
rloc does register for EXPIRE callbacks with usrloc.
&nbsp;
I&#8217;m referring t=
o:
&#8220;The pua_usrloc module is the connector between the usrloc and p=
ua modules. It creates the environment to send PUBLISH requests for user l=
ocation records, on specific events (e.g., when
 new record is added in usrloc, a PUBLISH with status open (online) is iss=
ued; when expires, it sends closed (offline)).&#8221;
</div>
<b=
r>
perhaps the documentation is misleading a bit with its phrasing. It send o=
ffline (closed) when it is an un-register, before the expiration. I haven'=
t looked in the code, but based on log messages and correlated with the ex=
pired carried by PUBLISH, the behavior
 is correct over all. 
 
There is another aspect, usrloc cleans up expired records on timer, so usr=
loc callback can be executed later than actual expiration. A publish at th=
at time could be late. Of course, presence does cleanup on timer as well, =
but it may be more accurate to handle
 expiration there. It is like when an UA with presence support disappears =
from networks, without sending any PUBLISH updates. 
 
Cheers, 
DAniel 
 
 
 

<div>
<div>
<div style=3D"border:none; border-top:solid #B5C4DF 1.0pt; padding:3.0pt 0=
cm 0cm 0cm">
F=
rom: Daniel-Cons=
tantin Mierla
 [<a href=3D"mailto:miconda at gmail.com">mailto:miconda at gmail.com</a>] 
Sent: 19 January 2012 10:37 
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - =
Users Mailing List 
Cc: Giacomo Vacca 
Subject: Re: [SR-Users] pua_usrloc, PUBLISH not send when contact i=
s deleted or expires
</div>
</div>
&nbsp;
Hello, 
 
On 1/19/12 11:22 AM, Giacomo Vacca wrote: 
<div>
Hi Daniel,=

<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Thanks for your feedb=
ack. Yes, using mysql and enabling presence made it work for un-registrati=
ons too.</span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Just for the purpose =
of this scenario I&#8217;m sending the PUBLISH back to the same entity, an=
d it&#8217;s being handled as a presentity.</span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;</span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">I still have a missin=
g piece though (which is in fact the reason for this configuration): havin=
g PUBLISH requests triggered by the expiration of a contact.</span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;</span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">When a contact expire=
s, pua_usrloc is now logging:</span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;</span></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-f=
amily:&quot;Courier New&quot;; color:windowtext">Jan 19 10:12:03 debian6 /=
usr/sbin/kamailio[4359]: INFO: pua_usrloc [ul_publish.c:211]: should not s=
end ul publish</span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;</span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">(please see below for=
 traces and details).</span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;</span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Since I&#8217;m marki=
ng a registration with pua_set_publish(), why is that flag not seen as tru=
e when usrloc fires an EXPIRE callback?</span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;</span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">I&#8217;ve tried mark=
ing every REGISTER request with pua_set_publish(), and not just the first =
one, before calling save(&#8220;location&#8221;) but the result was the sa=
me.</span></p>
</div>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"font-=
size:12.0pt; font-family:&quot;Times New Roman , serif&quot;,&quot;serif&q=
uot;"><br>
the PUBLISH for registration expiration does not make sense, as PUBLISH ha=
s also an expire interval, so the record in the presence server should exp=
ire at the same time. A publish with update state to close will eventually=
 hit the presence server when there
 is no record for it. Presence server will send notifications when the rec=
ord in its table expires.<br>
<br>
Cheers,<br>
Daniel</span></p>
</div>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">&nbsp;</p>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">&nbsp;</p>
<pre>-- </pre>
<pre>Daniel-Constantin Mierla -- <a href=3D"http://www.asipto.com">http://=
www.asipto.com</a></pre>
<pre><a href=3D"http://linkedin.com/in/miconda">http://linkedin.com/in/mic=
onda</a> -- <a href=3D"http://twitter.com/miconda">http://twitter.com/mico=
nda</a></pre>
</div>
<p class=3D"MsoNormal" style=3D"text-align:justify"><span style=3D"font-fa=
mily:&quot;Arial&quot;,&quot;sans-serif&quot;">Truphone Limited is a limit=
ed liability company registered in England &amp; Wales, registered office:=
 5 New Street Square, London EC4A 3TW.
<span class=3D"grame">Registered No. 04187081.</span> VAT No. <span class=3D=
"grame">GB 851 5278 19.</span>
</span></p>
<p class=3D"MsoNormal" style=3D"text-align:justify"><span class=3D"spelle"=
><span style=3D"font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">Tru<=
/span></span><span style=3D"font-family:&quot;Arial&quot;,&quot;sans-serif=
&quot;"> is a brand name of Truphone and is a Truphone Communications Serv=
ice. Truphone
 is a trading name for a number of distinct legal entities that operate in=
 combination.
</span><a href=3D"http://www.truphone.com"><span style=3D"font-family:&quo=
t;Arial&quot;,&quot;sans-serif&quot;">www.truphone.com</span></a><span sty=
le=3D"font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">.</span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt; font-family:&quot;=
Times New Roman&quot;,&quot;serif&quot;"><br clear=3D"all">
This e-mail, and any attachment(s), may contain information which is confi=
dential and/or privileged, and is intended for the addressee only. If you =
are not the intended recipient, you may not use, disclose, copy or distrib=
ute this information in any manner
 whatsoever. If you have received this e-mail in error, please contact the=
 sender immediately and delete it.<br>
<br>
<br>
<br>
</span></p>
<pre>_______________________________________________</pre>
<pre>SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing li=
st</pre>
<pre><a href=3D"mailto:sr-users at lists.sip-router.org">sr-users at lists.sip-r=
outer.org</a></pre>
<pre><a href=3D"http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-us=
ers">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a></pr=
e>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt; font-family:&quot;=
Times New Roman&quot;,&quot;serif&quot;"><br>
<br>
</span></p>
<pre>-- </pre>
<pre>Daniel-Constantin Mierla -- <a href=3D"http://www.asipto.com">http://=
www.asipto.com</a></pre>
<pre><a href=3D"http://linkedin.com/in/miconda">http://linkedin.com/in/mic=
onda</a> -- <a href=3D"http://twitter.com/miconda">http://twitter.com/mico=
nda</a></pre>
</div>
<p class=3D"MsoNormal" style=3D"text-align:justify"><span style=3D"font-si=
ze:11.0pt; font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">Truphone =
Limited is a limited liability company registered in England &amp; Wales, =
registered office: 4 Royal Mint Court, London, EC3N 4HJ.
<span class=3D"GramE">Registered No. 04187081.</span> VAT No. <span class=3D=
"GramE">GB 851 5278 19.</span>
</span></p>
<p class=3D"MsoNormal" style=3D"text-align:justify"><span class=3D"SpellE"=
><span style=3D"font-size:11.0pt; font-family:&quot;Arial&quot;,&quot;sans=
-serif&quot;">Tru</span></span><span style=3D"font-size:11.0pt; font-famil=
y:&quot;Arial&quot;,&quot;sans-serif&quot;"> is a brand name of Truphone a=
nd is a Truphone
 Communications Service. Truphone is a trading name for a number of distin=
ct legal entities that operate in combination.
</span><a href=3D"http://www.truphone.com"><span style=3D"font-size:11.0pt=
; font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">www.truphone.com</=
span></a><span style=3D"font-size:11.0pt; font-family:&quot;Arial&quot;,&q=
uot;sans-serif&quot;">.</span></p>
<br clear=3D"both">
This e-mail, and any attachment(s), may contain information which is confi=
dential and/or privileged, and is intended for the addressee only. If you =
are not the intended recipient, you may not use, disclose, copy or distrib=
ute this information in any manner whatsoever. If you have received this e=
-mail in error, please contact the sender immediately and delete it.<BR>
</body>
</html>

--_000_A4E41C20520BEC409F1B16BA9FD72D34C83BBDitixex01_--