<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7654.12">
<TITLE>RE: [sr-dev] improving the dialog module</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>>>> Let's assume the following scenario:<BR>
>>> UA1 --> P1 --> P2 --> P1 --> UA2<BR>
>>> Now, UA2 rejects the call, but P2 decides to reroute the call to an IVR<BR>
>>> UA1 --> P1 --> P2 --> IVR<BR>
>>> What will be the state of the dialog on P1?<BR>
>><BR>
>> I think this example of yours shows a potential problem of the<BR>
>> multiple-dialogs case while there is none in the single-dialog case.<BR>
>><BR>
>> First, the single-dialog case: When P1 receives the request from UA1, it<BR>
>> establishes a new, yet unconfirmed dialog. When it receives the request<BR>
>> from P2, it continues the dialog and does not create a new one.<BR>
>> When UA2's rejection is received by P1, the dialog will be terminated.<BR>
>> (This is what the dialog module already does now.) When P2 decides to send<BR>
>> out the request to another destination (like the IVR), P1 will establish a<BR>
>> new dialog (since there's none to continue anymore). I cannot see any<BR>
>> dialog handling problems in this approach.<BR>
><BR>
> I don't think that you got the right scenario here: when the call is<BR>
> rerouted, it is rerouted by P2 directly to IVR and P1 is no longer<BR>
> involved.<BR>
<BR>
You are right, I got the scenario wrong. Thanks for pointing me at that.<BR>
<BR>
<BR>
> If P1 kills the dialog on the first rejection from UA2, there will be<BR>
> no dialog left on P1.<BR>
<BR>
That will definitely break the single-dialog approach. However, one could<BR>
work around this by introducing a counter to dialogs which is incremented<BR>
for each re-seen, unconfirmed request and decremented when responses are<BR>
forwarded (i.e., when the dialog module calls dlg_onreply()). There, the<BR>
dialog's state wouldn't be modified unless the counter drops to zero.<BR>
<BR>
That way, the single dialog from the example above would not be destroyed<BR>
when UA2's rejection passes P1 because its counter will simply drop from 2<BR>
to 1, and will only be adjusted once a final reply from the IVR is<BR>
forwarded to P1 by P2 since the counter will drop to 0 then.<BR>
<BR>
<BR>
I realize that this looks more complicated than the multiple-dialogs<BR>
approach which may likely work just out-of-the-box with no additional<BR>
counters and exceptions required whatsoever. However, I believe that<BR>
convenience for users of dialog callbacks should be one primary goal when<BR>
improving the module, and I still find multiple dialogs much harder to<BR>
grasp and more tedious to code against (you will have to account for<BR>
multiple callbacks representing the same call in the same state, as I<BR>
I noted in my last post).<BR>
I am not sure if you (implicitly) suggested a different kind of SIP dialog<BR>
model where the endpoints are re-defined for multiple dialogs (i.e.,<BR>
between UA1 and P2, and between P2 and UA2). Again, that would aggravate<BR>
dialog callback usage because users cannot rely on a single peer-to-peer<BR>
relationship anymore.<BR>
<BR>
Paraphrasing, I think we should put effort into making dialog callbacks<BR>
look and feel easy to use when in fact there is a lot of complex machinery<BR>
running in the background to get things right.<BR>
<BR>
<BR>
Cheers,<BR>
<BR>
--Timo</FONT>
</P>
</BODY>
</HTML>