[sr-dev] 3 Comments on the New Dialog Module Design
Edson - Lists
4lists at gmail.com
Fri Mar 19 15:22:50 CET 2010
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 at gmail.com>:
>> 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!
>
>
>
More information about the sr-dev
mailing list