[OpenSIPS-Users] B2B Call-ID GUID generation scheme

[Bogdan-Andrei Iancu]

Hi Alex,

I agree on the problem - the current way of generating the B2B call-id 
does not properly cover the uniqueness of call-id in time .

As solution, I would say extending the current format to include some 
time-based info will do the trick (provide the uniqueness without 
disrupting the whole call-id matching in B2B).

Please open a bug request on the tracker and I can have a patch in place.

Thanks and Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 01.02.2016 00:28, Alex Balashov wrote:
> Hello,
>
> I am using the "top hiding" B2B scenario and am a bit puzzled as to 
> the thinking that led to the current scheme for the generation of 
> GUIDs on the B-leg of B2BUA entities.
>
> In b2b_entities/dlg.c:b2b_generate_key(), the use of this format:
>
>    <B2B prefix>.<hash index>.<local index>
>
> leads to very short Call-IDs like this:
>
>    Call-ID: B2B.27572.17705
>
> 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.
>
> 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 
> b2b_entities/dlg.c:b2b_parse_key(). This function also foresees the 
> length of the GUID and the positioning of the delimiters to be rather 
> static in nature.
>
> Furthermore, the only way I can see to lengthen the GUID is to 
> increase the B2B entity hash size. I have it set to 2^16, but it 
> doesn't seem practical or worthwhile to set it to much more than that. 
> Even increasing it to millions of buckets will only produce a gain of 
> another 3-4 [0-9] digits, which isn't the combinatoric explosion I'm 
> looking for. :-)
>
> For the moment, I have "solved" this problem by:
>
> 1) Setting a static
>
> modparam("b2b_entities", "b2b_key_prefix", "ABCDEFGIJKLMNOP")
>
> of 15 characters in length.
>
> 1) Removing the code in b2b_parse_key() that compares the prefix to 
> the value of the `b2b_key_prefix` modparam, so that this portion of 
> the Call-ID can be any 15-character string.
>
> 2) Modifying b2b_generate_key() to generate a random 15-character 
> string in place of the `b2b_key_prefix`:
>
> ---
> static char *ever_so_random(int len)
> {
>         static char buf[20];
>         int i = 0;
>         struct timeval tv;
>
>         memset(&buf, 0, sizeof(buf));
>
>         gettimeofday(&tv, NULL);
>         srand(tv.tv_usec);
>
>         for(i = 0; i < len; i ++) {
>                 srand(rand());
>
>                 buf[i] = (char) ((int) 'A' + (rand() % 26));
>         }
>
>         return buf;
> }
>
> ...
>
> str* b2b_generate_key(unsigned int hash_index, unsigned int local_index)
> {
>         ...
>         len = sprintf(buf, "%s.%d.%d", 
> ever_so_random(b2b_key_prefix.len), hash_index, local_index);
>         ...
> }
> ---
>
> This is a rather naive and unsophisticated approach to generating 
> random data, just the first thing that popped into my head. Together 
> with an augmented HASH_SIZE constant of 1 << 23, passed to 
> core_hash(), it generates Call-IDs like:
>
> Call-ID: LGHJRYMWFKMRIMP.55196.78746776
> Call-ID: GIUSLMQJLSWSJVW.42081.639158452
> Call-ID: DNDAINOIOZXCEDB.9209.1278194624
>
> Better than nothing, but not ultimately where happiness lies. :-)
>
> My real questions are:
>
> 1) Am I missing any key design decisions that led to the generation of 
> such short Call-IDs on the B leg, seemingly in flagrant violation of 
> RFC 3261's prescription (Section 8.1.1.4 "Call-ID") that ...
>
>    In a new request created by a UAC outside of any dialog, the Call-ID
>    header field MUST be selected by the UAC as a globally unique
>    identifier over space and time unless overridden by method-specific
>    behavior.  All SIP UAs must have a means to guarantee that the Call-
>    ID header fields they produce will not be inadvertently generated by
>    any other UA.
>
> 2) Is there some way to override this that I don't realise, e.g. using 
> a minimalistic scenario file for topology hiding?
>
> Many thanks in advance!
>
> -- Alex
>