<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi Giacomo,<br>
    <br>
    I patched few days ago to make pua_usrloc sending the PUBLISH also
    for location record expiration.<br>
    <br>
<a class="moz-txt-link-freetext" href="http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=bdbacf559134022856f5723a91fe7e130ceada29">http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=bdbacf559134022856f5723a91fe7e130ceada29</a><br>
<a class="moz-txt-link-freetext" href="http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=266fa4e2cd62f58ee1f2eec2a5a83bc3028d194a">http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=266fa4e2cd62f58ee1f2eec2a5a83bc3028d194a</a><br>
    <br>
    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 flag internally, if the module parameter specifying
    the flag is set -- alternative is to use directly setbflag(index).<br>
    <br>
    I was out of office and couldn't try it yet, maybe you can test and
    report if it is working fine.<br>
    <br>
    You have to install devel version, either from git or from nightly
    debs:<br>
    <br>
<a class="moz-txt-link-freetext" href="http://www.kamailio.org/wiki/packages/debs#kamailio_development_-_nightly_builds">http://www.kamailio.org/wiki/packages/debs#kamailio_development_-_nightly_builds</a><br>
    <br>
    Cheers,<br>
    Daniel<br>
    <br>
    On 1/20/12 12:56 PM, Giacomo Vacca wrote:
    <blockquote
      cite="mid:A4E41C20520BEC409F1B16BA9FD72D34C82FFC@itixex01"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <style>
<!--
@font-face
        {font-family:"Cambria Math"}
@font-face
        {font-family:Calibri}
@font-face
        {font-family:Tahoma}
@font-face
        {font-family:Consolas}
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";
        color:black}
a:link, span.MsoHyperlink
        {color:blue;
        text-decoration:underline}
a:visited, span.MsoHyperlinkFollowed
        {color:purple;
        text-decoration:underline}
pre
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";
        color:black}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:8.0pt;
        font-family:"Tahoma","sans-serif";
        color:black}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {margin-top:0cm;
        margin-right:0cm;
        margin-bottom:0cm;
        margin-left:36.0pt;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";
        color:black}
span.HTMLPreformattedChar
        {font-family:Consolas;
        color:black}
span.BalloonTextChar
        {font-family:"Tahoma","sans-serif";
        color:black}
p.msochpdefault, li.msochpdefault, div.msochpdefault
        {margin-right:0cm;
        margin-left:0cm;
        font-size:12.0pt;
        font-family:"Calibri","sans-serif";
        color:black}
span.htmlpreformattedchar0
        {font-family:Consolas;
        color:black}
span.htmlpreformattedchar00
        {font-family:Consolas;
        color:black}
span.emailstyle17
        {font-family:"Calibri","sans-serif";
        color:windowtext}
span.htmlpreformattedchar000
        {font-family:Consolas;
        color:black}
span.emailstyle23
        {font-family:"Calibri","sans-serif";
        color:#1F497D}
span.emailstyle24
        {font-family:"Calibri","sans-serif";
        color:#1F497D}
span.emailstyle28
        {font-family:"Calibri","sans-serif";
        color:#1F497D}
span.balloontextchar0
        {font-family:"Tahoma","sans-serif";
        color:black}
span.EmailStyle31
        {font-family:"Calibri","sans-serif";
        color:#1F497D}
.MsoChpDefault
        {font-size:10.0pt}
@page WordSection1
        {margin:72.0pt 72.0pt 72.0pt 72.0pt}
div.WordSection1
        {}
-->
</style>
      <div class="WordSection1">
        <p class="MsoNormal"><span style="color:#1F497D">Thanks Daniel.</span></p>
        <p class="MsoNormal"><span style="color:#1F497D">What I&#8217;d like
            to achieve is this: given a cluster of kamailio-based
            proxy/registrar, notify a separate entity whenever a contact
            is inserted or removed (either by deletion or expiration).</span></p>
        <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span></p>
        <p class="MsoNormal"><span style="color:#1F497D">I&#8217;d like this
            separate entity to be stateless (i.e. don&#8217;t manage expiry
            time), avoid using a DB as shared information and have
            asynchronous notifications.</span></p>
        <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span></p>
        <p class="MsoNormal"><span style="color:#1F497D">This is why I
            thought pua_usrloc could help me, without the need of a full
            presence server in the architecture to manage expiry times
            for presentities.</span></p>
        <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span></p>
        <p class="MsoNormal"><span style="color:#1F497D">What do you
            think could be used to achieve this?</span></p>
        <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span></p>
        <p class="MsoNormal"><span style="color:#1F497D">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.</span></p>
        <p class="MsoNormal"><span style="color:#1F497D">But I&#8217;m really
            looking at a simpler, lighter solution.</span></p>
        <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span></p>
        <p class="MsoNormal"><span style="color:#1F497D">Regards,</span></p>
        <p class="MsoNormal"><span style="color:#1F497D">Giacomo</span></p>
        <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span></p>
        <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span></p>
        <div>
          <div style="border:none; border-top:solid #B5C4DF 1.0pt;
            padding:3.0pt 0cm 0cm 0cm">
            <p class="MsoNormal"><b><span style="font-size:10.0pt;
                  font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;
                  color:windowtext" lang="EN-US">From:</span></b><span
                style="font-size:10.0pt;
                font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;
                color:windowtext" lang="EN-US"> Daniel-Constantin Mierla
                [<a class="moz-txt-link-freetext" href="mailto:miconda@gmail.com">mailto:miconda@gmail.com</a>] <br>
                <b>Sent:</b> 20 January 2012 10:58<br>
                <b>To:</b> SIP Router - Kamailio (OpenSER) and SIP
                Express Router (SER) - Users Mailing List<br>
                <b>Cc:</b> Giacomo Vacca<br>
                <b>Subject:</b> Re: [SR-Users] pua_usrloc, PUBLISH not
                send when contact is deleted or expires</span></p>
          </div>
        </div>
        <p class="MsoNormal">&nbsp;</p>
        <p class="MsoNormal">Hi Giacomo,<br>
          <br>
          On 1/19/12 11:49 AM, Giacomo Vacca wrote: </p>
        <div>
          <p class="MsoNormal"><span style="color:#1F497D">Ah thanks
              Daniel,</span></p>
          <p class="MsoNormal"><span style="color:#1F497D">So I had a
              wrong expectation on the behaviour of pua_usrloc.</span></p>
          <p class="MsoNormal"><span style="color:#1F497D">It does make
              sense that the PUBLISH already carries its expiry and so
              the expiration moment is implicit and should/can be
              handled elsewhere.</span></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span></p>
          <p class="MsoNormal"><span style="color:#1F497D">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.</span></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span></p>
          <p class="MsoNormal"><span style="color:#1F497D">I&#8217;m referring
              to:</span></p>
          <p class="MsoNormal"><span style="color:#1F497D">&#8220;</span><span
              lang="EN">The pua_usrloc module is the connector between
              the usrloc and pua modules. It creates the environment to
              send PUBLISH requests for user location records, on
              specific events (e.g., when new record is added in usrloc,
              a PUBLISH with status open (online) is issued; when
              expires, it sends closed (offline)).&#8221;</span></p>
        </div>
        <p class="MsoNormal"><span style="font-size:12.0pt;
            font-family:&quot;Times New Roman&quot;,&quot;serif&quot;"><br>
            perhaps the documentation is misleading a bit with its
            phrasing. It send offline (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
            expired carried by PUBLISH, the behavior is correct over
            all.<br>
            <br>
            There is another aspect, usrloc cleans up expired records on
            timer, so usrloc callback can be executed later than actual
            expiration. A publish at that 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.<br>
            <br>
            Cheers,<br>
            DAniel<br>
            <br>
            <br>
            <br>
            <br>
          </span></p>
        <div>
          <div>
            <div style="border:none; border-top:solid #B5C4DF 1.0pt;
              padding:3.0pt 0cm 0cm 0cm">
              <p class="MsoNormal"><b><span style="font-size:10.0pt;
                    font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;
                    color:windowtext" lang="EN-US">From:</span></b><span
                  style="font-size:10.0pt;
                  font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;
                  color:windowtext" lang="EN-US"> Daniel-Constantin
                  Mierla [<a moz-do-not-send="true"
                    href="mailto:miconda@gmail.com">mailto:miconda@gmail.com</a>]
                  <br>
                  <b>Sent:</b> 19 January 2012 10:37<br>
                  <b>To:</b> SIP Router - Kamailio (OpenSER) and SIP
                  Express Router (SER) - Users Mailing List<br>
                  <b>Cc:</b> Giacomo Vacca<br>
                  <b>Subject:</b> Re: [SR-Users] pua_usrloc, PUBLISH not
                  send when contact is deleted or expires</span></p>
            </div>
          </div>
          <p class="MsoNormal">&nbsp;</p>
          <p class="MsoNormal">Hello,<br>
            <br>
            On 1/19/12 11:22 AM, Giacomo Vacca wrote: </p>
          <div>
            <p class="MsoNormal"><span style="color:#1F497D">Hi Daniel,</span></p>
            <p class="MsoNormal"><span style="color:#1F497D">Thanks for
                your feedback. Yes, using mysql and enabling presence
                made it work for un-registrations too.</span></p>
            <p class="MsoNormal"><span style="color:#1F497D">Just for
                the purpose of this scenario I&#8217;m sending the PUBLISH
                back to the same entity, and it&#8217;s being handled as a
                presentity.</span></p>
            <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span></p>
            <p class="MsoNormal"><span style="color:#1F497D">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 contact.</span></p>
            <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span></p>
            <p class="MsoNormal"><span style="color:#1F497D">When a
                contact expires, pua_usrloc is now logging:</span></p>
            <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span></p>
            <p class="MsoNormal" style="text-autospace:none"><span
                style="font-family:&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 send ul publish</span></p>
            <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span></p>
            <p class="MsoNormal"><span style="color:#1F497D">(please see
                below for traces and details).</span></p>
            <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span></p>
            <p class="MsoNormal"><span style="color:#1F497D">Since I&#8217;m
                marking a registration with pua_set_publish(), why is
                that flag not seen as true when usrloc fires an EXPIRE
                callback?</span></p>
            <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span></p>
            <p class="MsoNormal"><span style="color:#1F497D">I&#8217;ve tried
                marking every REGISTER request with pua_set_publish(),
                and not just the first one, before calling
                save(&#8220;location&#8221;) but the result was the same.</span></p>
          </div>
          <p class="MsoNormal" style="margin-bottom:12.0pt"><span
              style="font-size:12.0pt; font-family:&quot;Times New
              Roman&quot;,&quot;serif&quot;"><br>
              the PUBLISH for registration expiration does not make
              sense, as PUBLISH has also an expire interval, so the
              record in the presence server should expire 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 record in
              its table expires.<br>
              <br>
              Cheers,<br>
              Daniel<br>
              <br>
            </span></p>
        </div>
        <p class="MsoNormal"><span style="font-size:12.0pt;
            font-family:&quot;Times New Roman&quot;,&quot;serif&quot;"><br>
            <br>
          </span></p>
        <p class="MsoNormal"><span style="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 moz-do-not-send="true" href="http://www.asipto.com">http://www.asipto.com</a></pre>
        <pre><a moz-do-not-send="true" href="http://linkedin.com/in/miconda">http://linkedin.com/in/miconda</a> -- <a moz-do-not-send="true" href="http://twitter.com/miconda">http://twitter.com/miconda</a></pre>
      </div>
      <p class="MsoNormal" style="text-align:justify"><span
          style="font-size: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: 5 New Street Square, London
          EC4A 3TW.
          <span class="GramE">Registered No. 04187081.</span> VAT No. <span
            class="GramE">GB 851 5278 19.</span>
        </span></p>
      <p class="MsoNormal" style="text-align:justify"><span
          class="SpellE"><span style="font-size:11.0pt;
            font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">Tru</span></span><span
          style="font-size:11.0pt;
          font-family:&quot;Arial&quot;,&quot;sans-serif&quot;"> 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 operate in combination.
        </span><a moz-do-not-send="true" href="http://www.truphone.com"><span
            style="font-size:11.0pt;
            font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">www.truphone.com</span></a><span
          style="font-size:11.0pt;
          font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">.</span></p>
      <br clear="all">
      This e-mail, and any attachment(s), may contain information which
      is confidential and/or privileged, and is intended for the
      addressee only. If you are not the intended recipient, you may not
      use, disclose, copy or distribute 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>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a>
<a class="moz-txt-link-freetext" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Daniel-Constantin Mierla -- <a class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
<a class="moz-txt-link-freetext" href="http://linkedin.com/in/miconda">http://linkedin.com/in/miconda</a> -- <a class="moz-txt-link-freetext" href="http://twitter.com/miconda">http://twitter.com/miconda</a></pre>
  </body>
</html>