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

[Alex Balashov]

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

-- 
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States

Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/