<!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>> Ovidiu Sas wrote:<BR>
>> If not, I don't think creating two dialogs for each call were one of<BR>
>> them will definitely be dangling and not cleaned up until the dialog<BR>
>> timeout (which is quite long by default) triggers is a viable option for<BR>
>> large-scale environments (such as ours). The rate at which new dialogs<BR>
>> are created could possibly outrun the rate at which they terminate,<BR>
>> which isn't desirable resource-wise.<BR>
><BR>
> The issue in the current design is the dialog matching algorithm.<BR>
> If two dialogs are created, both of them will be chained in the same<BR>
> dialog list.<BR>
> When an in dialog request is received, the first dialog that matched<BR>
> the callid, to/from tag is updated and the second one is just hanging<BR>
> around (it will never be touched).<BR>
> What we need, is a better dialog match (if an in dialog request for<BR>
> the second dialog is received, then the second dialog should be<BR>
> selected and updated, not the first one). What I'm proposing here is<BR>
> that dialog matching should be done based on callid, to/from tag,<BR>
> branch id, list of Route/Record-Route headers). This should ensure<BR>
> that the proper dialog is handle for each in dialog request and no<BR>
> dialog will be left over.<BR>
<BR>
Agreed that more strict matching logic will allow having multiple<BR>
dialogs to be resolved properly. Still, multiple dialogs come at a<BR>
price, please see further below.<BR>
<BR>
<BR>
> Even if we have a spiral and the INVITE is going twice through the<BR>
> server (and two individual transactions are created), IMHO one dialog<BR>
> is not a proper representation of the call.<BR>
<BR>
Can you be more specific as to why a single dialog isn't appropriate?<BR>
<BR>
I am thinking that a single dialog could actually be helpful: It abstracts<BR>
from numerous transactions that could possibly be established for a<BR>
request that is essentially the same (i.e., except for routing information)<BR>
at several locations in spiral scenarios. From an end-to-end perspective,<BR>
it doesn't seem that important to know how many transactions a request<BR>
spawns but how the associated dialog's state changes over time. Having as<BR>
little dialogs as possible will help with observing these changes.<BR>
<BR>
<BR>
> 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>
Now to the multiple-dialog case. When P1 receives P2's request, instead<BR>
of continuing the first dialog, it establishes another one which is<BR>
differentiated from the first by means of improved dialog matching<BR>
capabilities (covering the additional items branch ID and record/record-<BR>
route headers that you mentioned above). Now, if I get you right, when<BR>
UA2's rejection is received by P1, it will terminate just one of its<BR>
dialogs (the second one I suppose).<BR>
The next question that I ask myself is: When P2's re-routed request is<BR>
received by P1, will it re-use the first dialog? I'm not sure if that<BR>
will definitely happen, especially not if you select the Via header as<BR>
branch ID that changes between the initial and re-routed request. In that<BR>
case, you will end up with another new dialog (a third one), and the very<BR>
first one will never have a chance to be destroyed prior to the dialog<BR>
timeout trigger.<BR>
<BR>
<BR>
> I think having multiple dialogs for each branch of the spiral keeps<BR>
> things clean and easy to understand. The key is to perform proper<BR>
> matching for in-dialog requests to the corresponding dialog.<BR>
<BR>
Unless my comparison of the two approaches w.r.t. the call setup above<BR>
is wrong, it seems to me that the continuation method is easier to<BR>
grasp (you do not have to think it terms of multiple dialogs), consumes<BR>
less memory, and presumably requires less code modifications.<BR>
<BR>
Another issue from the dialog users' perspective: If you want to track<BR>
the call given above using the dialog module's callbacks, it should be<BR>
easier to do so the less dialogs of essentially the same call exist.<BR>
When there are multiple dialogs, users will need to take care themselves<BR>
not to track calls multiple times. For instance, if you want to make a<BR>
copy of the SIP messages exchanged for some reason, you'd need special<BR>
effort to avoid duplicate copies if several dialogs track the same call<BR>
data.<BR>
<BR>
<BR>
>>> One issue that I have with one single dialog is related to how dialog<BR>
>>> termination is handled on timeout. When BYE on timeout needs to be<BR>
>>> sent, where will be sent, as the single dialog will have four<BR>
>>> endpoints:<BR>
>>> - UA1 (the original caller)<BR>
>>> - P2 (the routed destination for the initial request)<BR>
>>> - P2 (the incoming destination for the forwarded request)<BR>
>>> - UA2 (the routed destination for the forwarded request)<BR>
>><BR>
>> I believe it's still just two endpoints no matter how long the route<BR>
>> path is, namely the hosts comprising the end-to-end dialog relationship<BR>
>> at the edge defined by the Contact header addresses.<BR>
>><BR>
>> That's where BYE messages are sent based on a look at the dialog code.<BR>
>> It also seems that record-routing is honored, so even if hosts on the<BR>
>> route require to see the triggered or "natural" BYE message, they will<BR>
>> do so.<BR>
><BR>
> If you have a single dialog, then were the BYE messages will be sent:<BR>
> - to UA1 and P2<BR>
> - to P2 and UA1<BR>
> - to UA1 and UA2<BR>
<BR>
To UA1 and UA2: They represent the endpoints because they provide the<BR>
respective Contact headers used to send the BYE message. The Contact<BR>
addresses will never change no matter at which point in the routing path<BR>
you set up a dialog.<BR>
<BR>
<BR>
Cheers,<BR>
<BR>
--Timo</FONT>
</P>
</BODY>
</HTML>