2010/4/1 Timo Reimann timo.reimann@1und1.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 :)