<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hello,<br>
    <br>
    imo, using SIP-based matching dialog only should be done, no matter
    what internal dialog id option is going to be.<br>
    <br>
    On the other hand, having an unique id internally is important for
    referencing to dialog variables (which are stored in a separate db
    table) as well as some internal APIs.<br>
    <br>
    Cheers,<br>
    Daniel<br>
    <br>
    <br>
    On 4/11/12 2:28 PM, Jason Penton wrote:
    <blockquote
cite="mid:CALoGXNXTHahstLt8dYtPO8kOTg-x_ox8xo7tYR0z79k9i1_Y9w@mail.gmail.com"
      type="cite">Hey Daniel,
      <div><br>
      </div>
      <div>I am all for option 3, but also quite happy to deal with
        SIP-based dialog matching only. If we are going to use some form
        of alternative matching, then agreed, probably better to use the
        new uid as opposed to an id based on storage structures and
        their relative positions.</div>
      <div><br>
      </div>
      <div>Cheers</div>
      <div>Jason<br>
        <br>
        <div class="gmail_quote">On Wed, Apr 11, 2012 at 2:22 PM,
          Daniel-Constantin Mierla <span dir="ltr">&lt;<a
              moz-do-not-send="true" href="mailto:miconda@gmail.com">miconda@gmail.com</a>&gt;</span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
            <br>
            the internal dialog id - the pair h_entry,h_id - seems
            exposed to some issues. They:<br>
            - h_entry is the slot index (in the internal hash table)
            where the dialog structure will be stored<br>
            - h_id is an incremented counter for each slot<br>
            <br>
            h_entry is computed as a hash function over Call-Id value,
            then made modulo nr. of slots.<br>
            <br>
            The problems can appear upon restart when changing the
            hash_size module parameter:<br>
            <br>
            <a moz-do-not-send="true"
href="http://kamailio.org/docs/modules/stable/modules_k/dialog.html#id2534423"
              target="_blank">http://kamailio.org/docs/modules/stable/modules_k/dialog.html#id2534423</a><br>
            <br>
            If it is decremented, then some dialogs might be left
            outside since their h_entry might not be valid anymore.
            Also, when hash_size is changed, for matching on SIP dialog
            attributes of ongoing calls, the hash function over callid
            made modulo over the new nr. of slots may get a different
            hash table slot index, resulting in dialog structure not
            being found.<br>
            <br>
            A very unlikely issue is caused by the h_id, which being
            incremented can overflow and start from 0 again. But will
            overlap if an dialog is still going on after 2^32 new
            dialogs on that hash table slot were initiated.<br>
            <br>
            I wanted to brought all in the discussion to make a
            decision. I see few options for the moment:<br>
            1) document this issue, so a restart with change of
            hash_size parameter must have 0 active dialogs<br>
            2) replace h_entry with the value of the hash function over
            call id, doing modulo operation each time to find the slot.
            The unlikely issue with overflow of h_id is still there<br>
            3) switch over another kind of unique id (sriud.{c,h} added
            recently in lib/srutils/ can be an option). This will imply
            changing the database structure<br>
            <br>
            Besides these, might be better to drop using the
            Record-Route header parameter to carry dialog id and just do
            SIP based dialog matching. Completely trusting those tokens
            in RR parameter might add some security risks and if there
            is a fallback to SIP-based dialog matching, using the
            shortcut with RR does not impact anymore that much.<br>
            <br>
            Opinions and other suggestions?<br>
            <br>
            Cheers,<br>
            Daniel<span class="HOEnZb"><font color="#888888"><br>
                <br>
                -- <br>
                Daniel-Constantin Mierla<br>
                Kamailio Advanced Training, April 23-26, 2012, Berlin,
                Germany<br>
                <a moz-do-not-send="true"
                  href="http://www.asipto.com/index.php/kamailio-advanced-training/"
                  target="_blank">http://www.asipto.com/index.php/kamailio-advanced-training/</a><br>
                <br>
                <br>
                _______________________________________________<br>
                sr-dev mailing list<br>
                <a moz-do-not-send="true"
                  href="mailto:sr-dev@lists.sip-router.org"
                  target="_blank">sr-dev@lists.sip-router.org</a><br>
                <a moz-do-not-send="true"
                  href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev"
                  target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a><br>
              </font></span></blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Daniel-Constantin Mierla
Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany
<a class="moz-txt-link-freetext" href="http://www.asipto.com/index.php/kamailio-advanced-training/">http://www.asipto.com/index.php/kamailio-advanced-training/</a></pre>
  </body>
</html>