19 Mar
2010
19 Mar
'10
4:22 p.m.
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(a)gmail.com>om>:
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?
I've the same doubt :)
Hope sombody caould clarify it.
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???
Same question already received by other member of the list. I'll fix
it right now (already done in fact).
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???
You are right, fixed now.
Thanks a lot!