No subject

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 at 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.
>>
>> I don't think that you got the right scenario here: when the call is
>> rerouted, it is rerouted by P2 directly to IVR and P1 is no longer
>> involved.
>
> You are right, I got the scenario wrong. Thanks for pointing me at that.
>
>
>> 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