[sr-dev] new dialog module design: tm trigger for dialog management

[Timo Reimann]

Iñaki Baz Castillo wrote:
> 2010/4/13 Timo Reimann <timo.reimann at 1und1.de>:
>>> Unfortunatelly I'm trying to figure out this solution and now I don't like it:
>>>
>>> - Imagine there are two branches, both with 180.
>>> - Both share the same "dialog_id" field in "dialog_out" table.
>>> - Bob-1 replies 200. The second entry remains 3 seconds before being deleted.
>>> - But before these 3 seconds Bob-2 also replies 200.
>>> - Such 200 would match the second "dialog_out" entry, but then, how to
>>> change its dialog_id field?? In the example it must change from
>>> "1111a" to "1111b".
>>>
>>> Any suggestion for it? I leave it as TODO in the wiki for now.
>> What about this:
>>
>> When the dialog module detects that a concurrent call is about to be
>> confirmed, it copies that second call's dialog_out entry from the old
>> location (1111a) to a new one (1111b). Afterwards, it creates a new
>> dialog_in entry with the same hash ID (1111) but pointing to the new
>> location (1111b). Along that process, it also copies the first call's
>> dflags just like we have discussed before.
>>
>> What did I miss at night-time?
> 
> It sounds Ok, but for this we must be really sure that, upon receipt
> of the first 200, the other pending branches are not immediately
> removed so the second 200 (after less than 1-2 seconds) would match an
> entry in dialog_out.

Agreed. Does the SIP standard specify the time interval for which
another branch's 200 response must still conclude another (concurrently
confirmed) call? Or is this time interval naturally bound to some
standard-provided timer?

I've tried to figure that out from RFC 3261 but couldn't find anything.


Cheers,

--Timo