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/
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
