New subject: new dialog module design: tm trigger for dialog management

2 Apr 2010

2010/4/1 Timo Reimann &lt;timo.reimann(a)1und1.de&gt;de>:
...
  Hi,

 sorry for not replying any earlier. I was distracted by other, higher
 prioritized tasks (such as vacation :) ). 
That's an important task! ;)

...
  I just completed a major refurbishment on the proposal
page according to
 what we have discussed on the mailing list. Unfortunately, I had to do
 it in one big piece instead of changing the page iteratively since the
 changes depend on each other more or less. This is what I have modified:

 - Dialog state transition on responses is now done when a response is
 forwarded (instead of when it is received). 
Ok

...
  - References to and examples of spiraled routing with
the
 "allow_multiple_dialogs_for_spiral" parameter set to "yes" are gone.
 There's just one way of spiraling left, plus a new callback
 DLGCB_SPIRALED that allows users to hook up to spiraling events in order
 to imitate the old behavior (without the drawback of having multiple
 Kamailio dialogs to represent the same SIP dialog). 
Ok

...
  - dialog_out does not need a state anymore. 
Ok

...
  Please have a look and tell me what you think about
it. (You will
 probably need to re-read from top to bottom.) Furthermore, while I was
 working on the page, I came up with two more questions and would be
 grateful for some further feedback: 
It's really ok. I just did a minor fix you can see in the history.
At the end of this mail I comment, however, a possible problem I see.

...
  (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.

...
  (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).

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?

Thanks a lot for all, really good job refactoring the page :)

-- 
Iñaki Baz Castillo
&lt;ibc(a)aliax.net&gt;

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