Hey Daniel,
I am all for option 3, but also quite happy to deal with SIP-based dialog
matching only. If we are going to use some form of alternative matching,
then agreed, probably better to use the new uid as opposed to an id based
on storage structures and their relative positions.
Cheers
Jason
On Wed, Apr 11, 2012 at 2:22 PM, Daniel-Constantin Mierla <miconda(a)gmail.com
Hello,
the internal dialog id - the pair h_entry,h_id - seems exposed to some
issues. They:
- h_entry is the slot index (in the internal hash table) where the dialog
structure will be stored
- h_id is an incremented counter for each slot
h_entry is computed as a hash function over Call-Id value, then made
modulo nr. of slots.
The problems can appear upon restart when changing the hash_size module
parameter:
http://kamailio.org/docs/**modules/stable/modules_k/**
dialog.html#id2534423<http://kamailio.org/docs/modules/stable/modules_k/…
If it is decremented, then some dialogs might be left outside since their
h_entry might not be valid anymore. Also, when hash_size is changed, for
matching on SIP dialog attributes of ongoing calls, the hash function over
callid made modulo over the new nr. of slots may get a different hash table
slot index, resulting in dialog structure not being found.
A very unlikely issue is caused by the h_id, which being incremented can
overflow and start from 0 again. But will overlap if an dialog is still
going on after 2^32 new dialogs on that hash table slot were initiated.
I wanted to brought all in the discussion to make a decision. I see few
options for the moment:
1) document this issue, so a restart with change of hash_size parameter
must have 0 active dialogs
2) replace h_entry with the value of the hash function over call id, doing
modulo operation each time to find the slot. The unlikely issue with
overflow of h_id is still there
3) switch over another kind of unique id (sriud.{c,h} added recently in
lib/srutils/ can be an option). This will imply changing the database
structure
Besides these, might be better to drop using the Record-Route header
parameter to carry dialog id and just do SIP based dialog matching.
Completely trusting those tokens in RR parameter might add some security
risks and if there is a fallback to SIP-based dialog matching, using the
shortcut with RR does not impact anymore that much.
Opinions and other suggestions?
Cheers,
Daniel
--
Daniel-Constantin Mierla
Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany
http://www.asipto.com/index.**php/kamailio-advanced-**training/<http://w…
______________________________**_________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**dev<http://l…