15 Apr
2010
15 Apr
'10
5:58 p.m.
Iñaki Baz Castillo wrote:
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.
Ok so let's settle with onreply_route.
Cheers,
--Timo
2010/4/15 Timo Reimann <timo.reimann(a)1und1.de>de>:
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.
Iñaki Baz Castillo wrote:
Yes, right. What I've added to the wiki allows this feature in fact :)
2010/4/15 Iñaki Baz Castillo
<ibc(a)aliax.net>et>:
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. 2010/4/15 Timo Reimann
<timo.reimann(a)1und1.de>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…
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. 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. 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. 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.