Re: [sr-dev] Proposal: New Dialog Module Design

Two remarks: (1) Under "dialog_out table", the following is stated: "A response arrives to the proxy and TM modules invokes the Dialog module callback for the previously generated dialog. *Such callback ignores the response if its Call-ID or From-tag doesn't match the entry in dialog_in table with same hash_id*[...]" I do not think the module has to check whether the response's Call-ID and From-tag match the entry in the dialog_in table because a mismatch should never happen: When the tm callback to dlg_reply() was registered in dlg_onreq(), the hash ID of the very dialog created during dlg_onreq() was passed as argument to tm's registration function. And since the tm module makes sure that you cannot receive a response-based callback for a different transaction than the one the registration was carried out from, the dialog that the response-triggered callback will point to must be the right one. (2) The "Spiral" example only shows one possible implementation with two dialog states created for an effectively single dialog. However, during the thread on the mailing list that started off the re-design proposal, we discussed another approach where a single dialog state is maintained for spirals only (denoted "dialog continuation" by myself). Is there a reason why this approach isn't taken into consideration on the wiki page? If it's just a matter of time and effort, I'd be glad to add some text and another example in order to let people comment on this further. Like I said before, I really consider having dialog callback users deal with module deficits the worse choice if a better option is available. Cheers, --Timo