After read the new proposal, i liked it and seems almost ok. Indeed i have 3 comments:
1) in the *dialog_in *table, is stated that /sflags/ is a row/field in doubt. I'm also in doubt, since, from my POV, all necessary flags for caller communication is already known by other module parms/flags. Could somebody elaborate a little the necessity of this row/field?
2) the relations between /dialog_in /and /dialog_out/ are 1:n or am i wrong? So, why, in the *dialog_out *table, is it necessary to keep the /caller_route_set/ (even optionally)??? Aren't all this info kept on the /dialog_in/ structure, since is equal to all /dialog_out/??? As 1 INVITE could result in many /dailog_out/ (legs), and caller info is shared with all generated /dialog_out/ legs, isn't this info more suitable on the /dialog_in/ structure???
3) in section "Dialog state for dialog_in and dialog_out", statement (2) is not clear. To me if at least one *dialog_out* is in /early /state, *dialog_in* is steal 'alive' and could not be changed to /terminated /state. Am I wrong???
Edson.
2010/3/19 Edson - Lists 4lists@gmail.com:
After read the new proposal, i liked it and seems almost ok. Indeed i have 3 comments:
- in the dialog_in table, is stated that sflags is a row/field in doubt.
I'm also in doubt, since, from my POV, all necessary flags for caller communication is already known by other module parms/flags. Could somebody elaborate a little the necessity of this row/field?
I've the same doubt :) Hope sombody caould clarify it.
- the relations between dialog_in and dialog_out are 1:n or am i wrong? So,
why, in the dialog_out table, is it necessary to keep the caller_route_set (even optionally)??? Aren't all this info kept on the dialog_in structure, since is equal to all dialog_out??? As 1 INVITE could result in many dailog_out (legs), and caller info is shared with all generated dialog_out legs, isn't this info more suitable on the dialog_in structure???
Same question already received by other member of the list. I'll fix it right now (already done in fact).
- in section "Dialog state for dialog_in and dialog_out", statement (2) is
not clear. To me if at least one dialog_out is in early state, dialog_in is steal 'alive' and could not be changed to terminated state. Am I wrong???
You are right, fixed now.
Thanks a lot!
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.
Another doubt (corner effect???): can one dialo-Out be in terminated state, while another is steal in early, or would the terminated generate a BYE to all other 'open' (in early state) dialog-out? Wouldn't it be clearer if it could be stated somewhere?
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... :)
Edson
Iñaki Baz Castillo escreveu:
2010/3/19 Edson - Lists 4lists@gmail.com:
After read the new proposal, i liked it and seems almost ok. Indeed i have 3 comments:
- in the dialog_in table, is stated that sflags is a row/field in doubt.
I'm also in doubt, since, from my POV, all necessary flags for caller communication is already known by other module parms/flags. Could somebody elaborate a little the necessity of this row/field?
I've the same doubt :) Hope sombody caould clarify it.
- the relations between dialog_in and dialog_out are 1:n or am i wrong? So,
why, in the dialog_out table, is it necessary to keep the caller_route_set (even optionally)??? Aren't all this info kept on the dialog_in structure, since is equal to all dialog_out??? As 1 INVITE could result in many dailog_out (legs), and caller info is shared with all generated dialog_out legs, isn't this info more suitable on the dialog_in structure???
Same question already received by other member of the list. I'll fix it right now (already done in fact).
- in section "Dialog state for dialog_in and dialog_out", statement (2) is
not clear. To me if at least one dialog_out is in early state, dialog_in is steal 'alive' and could not be changed to terminated state. Am I wrong???
You are right, fixed now.
Thanks a lot!
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.
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.
oppss.... i fail to read the parenthesis just before the statements... you already stated that the first match stops search... my bad...
Edson.
-
Edson - Lists -
Iñaki Baz Castillo