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

Timo Reimann timo.reimann at 1und1.de
Tue Apr 13 02:17:22 CEST 2010


Iñaki Baz Castillo wrote:
> 2010/4/13 Iñaki Baz Castillo <ibc at aliax.net>:
>>>> However the solution seems easy:
>>>> When a dialog gets confirmed mantain the rest of dialog_out entries
>>>> for a while (maybe 3-5 seconds), time enough to ensure that if a new
>>>> 200 arrives within an existing early-dialog it will match (an update
>>>> properly) such entry in dialog_out. What do you think?
> 
> 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?


Cheers,

--Timo




More information about the sr-dev mailing list