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

[Timo Reimann]

Hi,


Iñaki Baz Castillo wrote:
>> (1) Is the inv_branch parameter really needed? Initially, my impression
>> was that proxies require it in order to know which branches to prune in
>> case of remote forking and a final response coming in. However, the
>> inv_branch shouldn't be required for that IMHO since callbacks to the
>> response handling function pass along the dialog_in's hash ID that the
>> responses refer to. By matching the dialog_in's dialog_id with entries
>> in the dialog_out table, it can determine all the branches belonging to
>> a given call, and thereby also those that need to be deleted.
> 
> Right. As now dialog status just relies on the responses sent upstream
> to the client I think inv_branch is not required anymore.
> 
> I just see a minor issue with this. Imagine P1 is running the Dialog
> module and a proxy P2 behind it does parallel forking and replies 2
> early dialogs. This would mean two entries under dialog_out table.
> Later P2 sends a negative final response for the first dialog. Just
> the dialog_out entry matching the To-tag would be deleted, while the
> other one would exist until the whole dialog is confirmed or
> terminated.
> Anyhow, I think this is not a big problem.

Forking proxies do not forward negative replies until a call has been
finally deemed unsuccessful. This means that once a negative response
arrives at P1, the entire call has failed and thus, P1 may safely delete
all branches belonging to that call. The way to find these branches is
by looking up all dialog_out entries with the dialog ID that matches the
one from the dialog_in table referenced by the callback-provided hash
ID. (Oh boy!)

Or, looking at our "Parallel forking" example, if P1's dialog tables
would look as following (showing just the relevant columns) right before
the reception of a final response:

dialog_in:
| hash_id | dialog_id |
|   1111  |   1111a   |

dialog_out:
| dialog_id | To-tag |
|   1111a   |  foo   |
|   1111a   |  bar   |

Then, on reception of a final negative response, it will extract hash ID
1111 from the dialog callback parameter, find that it maps to dialog ID
1111a, and lookup both dialog_out entries with that dialog ID 1111a.

That's how I see it.


>> (2) Is the dialog_out table required for anything else but displaying
>> dialog data (e.g., callee To-tag, callee CSeq number, etc.) over the MI
>> interface right now? Specifically, is it needed for proper state
>> keeping? AFAICS, the current proposal's state machine may operate on
>> response codes/request methods and current state alone.
>> I realize that displaying statistics is important enough to hold on to
>> the dialog_out table; this question is for clarification purposes only.
> 
> dialog_out entries are important in order to mantain the proper CSeq
> of caller and callee and also remote target and route set for each
> dialog (useful when using the Dialog module MI function to terminate a
> call). Also dialog_out entries store per (early-)dialog flags
> (dflags), probably needed by some modules also during early-dialog
> (i.e. mediaproxy and "engage_media()" method).

Alright. I've added some of your examples to the wiki page as further
rationale behind the new proposal.


> Also, currently I see an issue related to "Concurrently confirmed calls":
> 
> -------------
> Immediately afterwards, Bob-2 replies 200 as well. The delay is too
> short for the proxy to cancel Bob-2 yet so it forwards the response it
> as well, thereby establishing another dialog. That is, a new dialog_in
> and dialog_out entry will be created from Bob-2's 200 response and
> associated with each other.
> In order to preserve any dflags from the dialog just confirmed, the
> proxy will also copy the dflags from the dialog_out entry under the
> current hash ID (which, remember, was passed as part of the callback).
> Specifically, it will find the dialog_out entry “branch1” for the hash
> ID “1111a” and copy its dflags to the new dialog_out entry
> -------------
> 
> Imagine the following case:
> 
> - alice calls to bob and the proxy forks to bob1 and bob2.
> - Both replies 183 with SDP.
> - 183 from bob2 requires PRACK.
> - alice sends PRACK for bob2 (so its associated entry in dialog_out
> gets the caller_cseq incremented).
> - Module XXX sets a dflag(N) just for the dialog with bob1.
> - bob1 replies 200.
> - At this point the dialog_out entry for bob2 is destroyed.
> - But bob2 replies 200 before receiving the CANCEL.
> - As the text above states a new entry in dialog_out would be created
> by copying the dflags from the already confirmed dialog_out entry (so
> dfalg(N) is set), and copying the dialog_in's original_caller_cseq
> into its caller_cseq.
> 
> This would be obviously wrong becase the created dialog for bob2 has a
> wrong caller_cseq and wrong dflags.
> 
> 
> 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?

Sounds reasonable. I wonder how much dependent the current dialog module
implementation is on the transaction deletion timer (i.e., if there is
already a delay that prevents the dialog from being removed right after
a final response has been forwarded). Unless you or someone else knows,
I'll try to find that out and update the wiki accordingly.


Cheers,

--Timo