[sr-dev] improving the dialog module

[Ovidiu Sas]

On Fri, Mar 12, 2010 at 12:56 PM, Timo Reimann <timo.reimann at 1und1.de> wrote:
> Hey Ovidiu,
>
>
> Ovidiu Sas wrote:
>> You are right about the today's server behavior with respect to this
>> case, but on the other hand, I disagree with the one dialog approach.
>>
>> IMHO two dialogs should be created and a better dialog match should be
>> enforced (adding Via and Route/Record-Route headers checking).
>> Like this, each message should be mapped to it's proper dialog and
>> each dialog will be properly terminated when the corresponding BYE is
>> received.
>
> Would that improved dialog matching somehow shorten the time until
> dangling dialogs are destroyed substantially?
>
> If not, I don't think creating two dialogs for each call were one of
> them will definitely be dangling and not cleaned up until the dialog
> timeout (which is quite long by default) triggers is a viable option for
> large-scale environments (such as ours). The rate at which new dialogs
> are created could possibly outrun the rate at which they terminate,
> which isn't desirable resource-wise.

The issue in the current design is the dialog matching algorithm.
If two dialogs are created, both of them will be chained in the same
dialog list.
When an in dialog request is received, the first dialog that matched
the callid, to/from tag is updated and the second one is just hanging
around (it will never be touched).
What we need, is a better dialog match (if an in dialog request for
the second dialog is received, then the second dialog should be
selected and updated, not the first one).  What I'm proposing here is
that dialog matching should be done based on callid, to/from tag,
branch id, list of Route/Record-Route headers).  This should ensure
that the proper dialog is handle for each in dialog request and no
dialog will be left over.

Even if we have a spiral and the INVITE is going twice through the
server (and two individual transactions are created), IMHO one dialog
is not a proper representation of the call.


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 having multiple dialogs for each branch of the spiral keeps
things clean and easy to understand.  The key is to perform proper
matching for in-dialog requests to the corresponding dialog.


>> One issue that I have with one single dialog is related to how dialog
>> termination is handled on timeout.  When BYE on timeout needs to be
>> sent, where will be sent, as the single dialog will have four
>> endpoints:
>>  - UA1 (the original caller)
>>  - P2 (the routed destination for the initial request)
>>  - P2 (the incoming destination for the forwarded request)
>>  - UA2 (the routed destination for the forwarded request)
>
> I believe it's still just two endpoints no matter how long the route
> path is, namely the hosts comprising the end-to-end dialog relationship
> at the edge defined by the Contact header addresses.
>
> That's where BYE messages are sent based on a look at the dialog code.
> It also seems that record-routing is honored, so even if hosts on the
> route require to see the triggered or "natural" BYE message, they will
> do so.
>
> Was that your issue, or did I miss something vital?

If you have a single dialog, then were the BYE messages will be sent:
 - to UA1 and P2
 - to P2 and UA1
 - to UA1 and UA2


> Cheers,
>
> --Timo
>