[sr-dev] improving the dialog module

[Timo Reimann]

>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20100314/7e255856/attachment.htm>