<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi,<br>
    <br>
    I have attached an example where it is working, in this case the BLF
    is disabled when the 2nd publish is sent to the presence server, in
    the example where it is not working, it appears that the BLF stays
    enabled, its as if it never gets a notify message for the terminated
    call state. I assume this is becase the presence server cant update
    the existing presentity entry and therefor doesnt send the
    associated notification.<br>
    <br>
    It's intermitent in the sense that it could happen on the 1st test
    call, or I could have 5 successfull calls and then this issue
    occurs, but yes, as you say, the issue presented itself with the BLF
    not being disabled, I am assuming it is because the etag is not sent
    in the subsequent publish message, however, if it can be worked
    around by not considering the etag I am willing to try it. I had a
    look at the presence and presence_dialoginfo module documentation
    and I cannot see an module parameter which may enable/disable the
    etag check.<br>
    <br>
    I managed to work around the expiry of the entry out the database by
    setting the override_lifetime pua_dialoginfo module parameter,
    however, the blf issue still persists even with the expiry working.<br>
    <br>
    Thanks<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 20/10/2015 20:37, Daniel-Constantin
      Mierla wrote:<br>
    </div>
    <blockquote cite="mid:562697FB.7000606@gmail.com" type="cite">
      <meta content="text/html; charset=windows-1252"
        http-equiv="Content-Type">
      Hello,<br>
      <br>
      the source code needs to be checked, iirc, at some point there was
      an option to use last publish, so the etag was not really
      considered.<br>
      <br>
      You said 'intermitent', but I assume is not the case that etag is
      used for follow up publish, just the effect on blf.<br>
      <br>
      Cheers,<br>
      Daniel<br>
      <br>
      <div class="moz-cite-prefix">On 17/10/15 13:24, Asgaroth wrote:<br>
      </div>
      <blockquote cite="mid:56222FD7.1030308@gmail.com" type="cite">Hi
        All, <br>
        <br>
        I've come accross an intermittent issue where an initial publish
        is sent to our presence server, proxy recieves the subsequent
        200 with etag, but the following publish sent does not contain
        the sip-if-match header of the recieved 200, which ends up
        causing trouble with BLF on our test devices, it also has the
        added side affect of not being cleared out of the presentity
        table, these entries need to be manually removed. <br>
        <br>
        This does not occur all the time, I can use the same phone and
        make several calls before this issue occurs. It is not limited
        to a device type, we've tried with panasonic, polycom, cisco,
        zoiper, yealink and linksys devices, all exhibit the same
        sporadic behaviour. <br>
        <br>
        I've attached an example sip trace of the publish messages where
        this happens, you can see the second publish doesnt have the
        sip-if-match header whose content should be that of the sip-etag
        in the previous 200 to the initial publish. <br>
        <br>
        I'm not sure if there is something I am misunderstanding here, a
        configuration issue, or if this is indeed a bug. <br>
        <br>
        Both the proxy and the presence server are running kamailio
        v4.3.3. <br>
        <br>
        Any pointers/suggestions/guidance would be appreciated. <br>
        <br>
        If you need any additional info, please dont hesitate to ask. <br>
        <br>
        Thanks <br>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a>
<a moz-do-not-send="true" 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 moz-do-not-send="true" class="moz-txt-link-freetext" href="http://twitter.com/#%21/miconda">http://twitter.com/#!/miconda</a> - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a>
Book: SIP Routing With Kamailio - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a></pre>
      <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>
  </body>
</html>