14 Mar
2010
14 Mar
'10
3:53 p.m.
From my prospective, in the case of a spiral, there is
more then one
call. And I like the fact that the statistics is showing this.
There are many other cases when a single dialog approach is breaking
other things. For instance, the qos module is keeping track of the
media connections between the two endpoints. In a single dialog
approach, this will not work.
It seems that mediaproxy module will be affected too.
A single dialog approach breaks too many things and I'm against it.
As Juha pointed out too, the dialog matching algorithm should be fixed
in order to avoid the left over dialogs in case of spiral calls.
Regards,
Ovidiu Sas
On Sun, Mar 14, 2010 at 8:37 AM, Timo Reimann <Timo.Reimann(a)1und1.de> wrote:
Let's
assume the following scenario:
UA1 --> P1 --> P2 --> P1 --> UA2
Now, UA2 rejects the call, but P2 decides to reroute the call to an IVR
UA1 --> P1 --> P2 --> IVR
What will be the state of the dialog on P1?
I think this example of yours shows a potential problem of the
multiple-dialogs case while there is none in the single-dialog case.
First, the single-dialog case: When P1 receives the request from UA1, it
establishes a new, yet unconfirmed dialog. When it receives the request
from P2, it continues the dialog and does not create a new one.
When UA2's rejection is received by P1, the dialog will be terminated.
(This is what the dialog module already does now.) When P2 decides to
send
out the request to another destination (like the IVR), P1 will establish
a
new dialog (since there's none to continue anymore). I cannot see any
dialog handling problems in this approach. If P1 kills the dialog on the first rejection
from UA2, there will be
no dialog left on P1.
That will definitely break the single-dialog approach. However, one could
work around this by introducing a counter to dialogs which is incremented
for each re-seen, unconfirmed request and decremented when responses are
forwarded (i.e., when the dialog module calls dlg_onreply()). There, the
dialog's state wouldn't be modified unless the counter drops to zero.
That way, the single dialog from the example above would not be destroyed
when UA2's rejection passes P1 because its counter will simply drop from 2
to 1, and will only be adjusted once a final reply from the IVR is
forwarded to P1 by P2 since the counter will drop to 0 then.
I realize that this looks more complicated than the multiple-dialogs
approach which may likely work just out-of-the-box with no additional
counters and exceptions required whatsoever. However, I believe that
convenience for users of dialog callbacks should be one primary goal when
improving the module, and I still find multiple dialogs much harder to
grasp and more tedious to code against (you will have to account for
multiple callbacks representing the same call in the same state, as I
I noted in my last post).
I am not sure if you (implicitly) suggested a different kind of SIP dialog
model where the endpoints are re-defined for multiple dialogs (i.e.,
between UA1 and P2, and between P2 and UA2). Again, that would aggravate
dialog callback usage because users cannot rely on a single peer-to-peer
relationship anymore.
Paraphrasing, I think we should put effort into making dialog callbacks
look and feel easy to use when in fact there is a lot of complex machinery
running in the background to get things right.
Cheers,
--Timo