On Fri, Mar 12, 2010 at 12:56 PM, Timo Reimann timo.reimann@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