[sr-dev] a bit about dialog module

[Daniel-Constantin Mierla]

Hello,

imo, using SIP-based matching dialog only should be done, no matter what 
internal dialog id option is going to be.

On the other hand, having an unique id internally is important for 
referencing to dialog variables (which are stored in a separate db 
table) as well as some internal APIs.

Cheers,
Daniel


On 4/11/12 2:28 PM, Jason Penton wrote:
> 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 at gmail.com <mailto:miconda at gmail.com>> wrote:
>
>     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
>
>     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/
>
>
>     _______________________________________________
>     sr-dev mailing list
>     sr-dev at lists.sip-router.org <mailto:sr-dev at lists.sip-router.org>
>     http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>

-- 
Daniel-Constantin Mierla
Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany
http://www.asipto.com/index.php/kamailio-advanced-training/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20120411/d9386ce3/attachment.htm>