[sr-dev] pua_subscribe (pua_mi) reuses key GUIDs

[Alex Balashov]

Hi,

I am initiating lots of subscriptions (several thousand) using the 
pua_subscribe MI command exported by the pua_mi module:

    http://kamailio.org/docs/modules/4.2.x/modules/pua_mi.html#idp267208

The immediate issue I am having is that the From-tag and Call-ID are 
reused in multiple successive subscriptions--at least 10 to 20 out of my 
several thousand. When combined with PUA db_mode 2 (DB-backed) this is 
disastrous:

Jan 24 14:50:28 sip /usr/local/sbin/kamailio[27986]: ERROR: db_mysql 
[km_dbase.c:123]: db_mysql_submit_query(): driver error on query: 
Duplicate entry '6e14fe38006106fb-14b28de6edf11d3914a0aa090636030d-b1f4' 
for key 'pua_idx'
Jan 24 14:50:28 sip /usr/local/sbin/kamailio[27986]: ERROR: <core>
[db_query.c:235]: db_do_insert_cmd(): error while submitting query

Jan 24 14:50:28 sip /usr/local/sbin/kamailio[27986]: ERROR: pua 
[pua_db.c:1190]: insert_dialog_puadb(): DB insert failed

This is because the 'pua' table has a UNIQUE constraint on a tuple of 
<tuple_id, etag, call_id, from_tag> in the schema definition:

    CREATE TABLE pua (
       ...
       CONSTRAINT pua_idx UNIQUE (etag, tuple_id, call_id, from_tag)
    );

The 'etag' and 'tuple_id' values are empty strings (''), so the same 
call_id and from_tag cause this error.

If I remove the unique constraint, other problems result that ultimately 
do not lead to correct management of the subscriptions in the 'pua' table:

Jan 23 12:50:56 sip /usr/local/sbin/kamailio[12101]: ERROR: pua 
[pua_db.c:1263]: get_dialog_puadb(): Too many rows found (2)... deleting

The From-tag and Call-ID is not unique in the SUBSCRIBEs generated by 
PUA. So, what I am wondering if there is a global option I can set for 
TM that leads to absolutely unique tags and Call-ID GUIDs in every case. 
Otherwise, I suspect the issue is that the random seeds used to generate 
the GUIDs are based on time(NULL) or something of that ilk, because this 
is not so much a problem if the subscriptions are spread out across the 
time domain. It's a problem that arises when I send several thousand 
pua_subscribe MI commands within 1-2 seconds.

Thanks!

-- Alex


-- 
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States

Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/