<p>In <code>b2b_entities/dlg.c:b2b_generate_key()</code>, the use of this format:</p>

<p><code>&lt;B2B prefix&gt;.&lt;hash index&gt;.&lt;local index&gt;</code></p>

<p>leads to very short Call-IDs like this:</p>

<p><code>Call-ID: B2B.27572.17705</code></p>

<p>This is impractically short, and is certain to lead to collisions in a high-volume environment with millions of calls daily. There are many database systems etc. that rely on all calls being identifiable by a unique GUID. I don't think it conforms to the RFC 3261 prescription that GUIDs be good GUIDs.</p>

<p>Unfortunately, it's not possible to simply append additional random data to the key string, since the Call-ID has specific meaning that is extracted in sequential requests, as per <code>b2b_entities/dlg.c:b2b_parse_key()</code>. This function also foresees the length of the GUID and the positioning of the delimiters to be rather static in nature.</p>

<p>Some sort of solution to increase overall Call-ID length and combinatorial complexity is needed, such as appending time-based data into the string. </p>

<p>Much appreciated!</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">&mdash;<br>Reply to this email directly or <a href="https://github.com/OpenSIPS/opensips/issues/783">view it on GitHub</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/AFOcibyh93cCfGz0eQCzryHLP9dfGg1Qks5phpQOgaJpZM4HU_q_.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/OpenSIPS/opensips/issues/783"></link>
  <meta itemprop="name" content="View Issue"></meta>
</div>
<meta itemprop="description" content="View this Issue on GitHub"></meta>
</div>