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

[Iñaki Baz Castillo]

2010/3/24 Timo Reimann <timo.reimann at 1und1.de>:

> Consequently, step 2 of the algorithm that changes dialog_in state
> ("Algorithm for dialog_in state") given in the proposal boils down to a
> simple matching rule as follows:
>
> Set dialog_in state to the state corresponding to the return code of the
> forwarded message. That is, if the response code is
>  * greater than 100, but smaller than 200: set it to "early" (may be
>    skipped if there is a dialog_out entry already as this implies that
>    another early branch has already been established and the
>    dialog_in state set to "early"),
>  * 200: set it to "confirmed" (step 1 will have deleted the remaining
>    branches),
>  * greater than 200: set it to "terminated" (step 1 will have deleted
>    the remaining branches).

This means that the dialog status is 100% mapped to the INVITE
transaction status. It's ok, of course, except by the corner case in
which two 200 arrive at the same time (as you describe now).


> In-dialog BYE requests will just have to set the dialog_in state to
> "terminated", trimming down the state machine further.
>
> Considering the corner case of two branches' 200 responses arriving at
> exactly the same time (let's name them concurrently confirmed dialogs),
> I believe that this should yield two completely independent dialog
> entries, with one dialog_in and dialog_out each.

How and when would be the second dialog_in entry be generated?
The only approch coming to my mind is generating a new dialog_in entry
if a new 200 arrives for an already established dialog. Not sure if it
adds too much complexity or becomes easier to manage...


> Managing them under the
> same dialog_in as two dialog_outs gives the impression that they are
> somewhat related but this is not true as each carries a unique dialog
> identifier.

But the complete dialog identifier is the union of a dialog_in entry
and a dialog_out entry. By itself, a dialog_in entry means "nothing".

When parallel forking occurs and we have different ringing branches
it's clear that the approach of having one dialog_in for N dialog_out
is appropriate. Each dialog_out means a early-dialog. When some of
them is established it becomes a "dialog", but the concept is the same
(IMHO).

If the same INVITE receives two different 200 (so two established
dialogs) both belong to the same dialog_in entry, while each dialog
has its own properties (cseq, route-set, target, dflags...) in its
corresponding dialog_out entry. IMHO it makes sense.



> Furthermore, under the current proposal, I believe that
> callbacks registered for the yet non-confirmed dialog will be effective
> for the concurrently confirmed dialog too because both OK responses
> should be forwarded by the same transaction, resulting in the same
> dialog callbacks being run for both dialogs. If the transaction module
> handles simultaneously forwarded OK responses differently, then there
> will be no callbacks at all for one of the dialogs which is equally bad.

That's a good technical note :)


> Instead, there should be a clean separation of the two dialogs supported
> by a new dialog callback type (e.g., DLGCB_CONCURRENTLY_CONFIRMED) which
> allows the user to decide whether he wants to track the additionally
> confirmed dialog as well, and how long he wants to track it based on
> further dialog callbacks he chooses. For example, he may register
> DGLCB_TERMINATED on the additional dialog or opt that getting to know
> about its generation is sufficient. Generally, in-dialog requests will
> be mapped to the respective dialogs (which may involve some more effort
> because dialog hashes are stored in the route headers during processing
> of the initial request, but it's doable) and managed individually.

Then you couldn't set specific dflags to the secondly generated
dialog, neither manage it as any other "normal" dialog.
Imagine the UAC receives both 200 and sends the BYE for the first one.
Then there would exist an active dialog for which dialog module is not
storing its information properly. Do I miss something here?


> Concluding, this modified approach will keep the new dialog module from
> doing unnecessary and hard-to-do duplicate checks, eases state
> management, and keeps concurrently confirmed dialogs cleanly separated.
>
> Opinions?

I really agree with you, sure. By just taking into account the initial
INVITE transaction status it is easier to determine the "global"
dialog state (from the client's point of view).

But I still need to understand the possible limitation in double-200
scenarios. Could you please draw an example of how the dialog table(s)
would look when such scenario occurs? :)


Thanks a lot.

-- 
Iñaki Baz Castillo
<ibc at aliax.net>