19 Mar
2010
19 Mar
'10
3:46 p.m.
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.
19 Mar
19 Mar
4:05 p.m.
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!
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
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!
4:57 p.m.
2010/3/19 Edson - Lists <4lists(a)gmail.com>om>:
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.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
5:06 p.m.
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.
5393
days inactive
5393
days old
4 comments
2 participants
participants (2)
-
Edson - Lists -
Iñaki Baz Castillo