[sr-dev] 3 Comments on the New Dialog Module Design

[Edson - Lists]

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!
> 
> 
>