12 Mar
2010
12 Mar
'10
8:56 p.m.
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.
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?
Cheers,
--Timo