[sr-dev] new dialog module design: tm trigger for dialog management

[Timo Reimann]

Iñaki Baz Castillo wrote:
> 2010/4/15 Timo Reimann <timo.reimann at 1und1.de>:
>> Iñaki Baz Castillo wrote:
>>> 2010/4/15 Iñaki Baz Castillo <ibc at aliax.net>:
>>>> 2010/4/15 Timo Reimann <timo.reimann at 1und1.de>:
>>>>> Alright. Let me know when you found the time to dig it out.
>>>> This is the thread. I must re-read it:
>>>> https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-August/020028.html
>>> The conclusion is easy:
>>>
>>> The 200 must contain Record-Route and Contact so the Dialog module
>>> shuld just care about such fields in the 2XX response.
>>> Anyhow, for information purposes, it could extract these fields from
>>> provisional responses and set the dialog_out entries according.
>> What about terminating early dialogs using the MI interface? Assuming
>> that a provisional response carried a Contact header and no final
>> response was sent yet, it seems to me that terminating such an early
>> dialog would only be possible if the dialog module actually stored the
>> header. This is beyond purely informational purposes.
> 
> Yes, right. What I've added to the wiki allows this feature in fact :)
> 
> 
>> On the other hand, I don't think terminating early dialogs isn't
>> supported by the current implementation anyway. Changing that would just
>> mean another feature, making it less critical.
> 
> Could it be specified into the proposal as a requeriment? anyhow is
> not critical at all.

If it's a lot of effort, I wouldn't make it a requirement. However,
since we will have to touch the MI functions anyway (e.g., Contact
headers from both caller and callee are now stored in different tables),
terminating early dialogs might be easily implemented anyway.

But as we agree that it's non-critical, let's just make it low-priority.


>>> Other issue: dialog flags.
>>>
>>> The proposal just allows setting a dflag during onreply_route. This
>>> makes a lot of sense as there is no dialog yet in route, branch_route
>>> and failure_route. So setdflag() function just could be inoked in
>>> onreply_route. Is it ok?
>> Dialogs are already established in spiraling cases, however.
> 
> Well, I don't consider it an established dialog, but just a
> "prosceeding" dialog (an entry in dialog_in) which prevent the
> creation of a new one in order to avoid spirals.

Yeah sorry that's what I meant, establishing as in a dialog structure
has been set up.


>> Might it
>> prove useful if dflag manipulation worked the instant a spiral is
>> happening (which may be in route or branch_route)?
> 
> Humm, I don't see how it could be useful.

Ok so let's settle with onreply_route.


Cheers,

--Timo