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!