2010/3/19 Edson - Lists 4lists@gmail.com:
Thanks Iñaki...
Oppsss.... just re-read and seams that statement (4) on "Dialog state for dialog_in and dialog_out" has something stange... Dialog_in can only be in rejected state if _all_ dialog_out states were rejected. In the current write it's against statement (2).
I would suggest to rewrite them as follow: # If ALL state in “dialog_out_states” is rejected then dialog_in gets rejected state.
Well, if not ALL state in “dialog_out_states” is "rejected" then it means than any other rule with higher preference has already been taken :)
Also note that "rejected" (and "terminated") entries in dialog_out table should be deleted from the table (perhaps after 2-3 seconds of being rejected/terminated).
Another doubt (corner effect???): can one dialo-Out be in terminated state, while another is steal in early,
This shouldn't be possible. The proxy must cancel the pending branches when a branch replies 200 for a dialog. Then such CANCEL would force a 487 from the corresponding branch which would update to "rejected" its entry in dialog_out.
or would the terminated generate a BYE to all other 'open' (in early state) dialog-out?
No, I didn't consider this feature (a proxy ending a call) into the module core design, as it breaks the RFC 3261 (a proxy cannot generate in-dialog requests as it's not a UA). Such feature should be an "add-on" for the config script, but far from the diaog module logic (IMHO).
Wouldn't it be clearer if it could be stated somewhere?
Sure, what do you propose exactly? Right now I don't understand when the doubt is as the case you have proposed is just impossible (theorically), but please, feel free to comment more about it, I'll very pleased to improve the documentation.
Who knows a good State Machine drawing tool? I suppose that such state diagram would help a lot.... not just for this New Dialog Module, but also for your previous present inquires... :)
Interesting idea ;)
Thanks a lot.