12 Mar
2010
12 Mar
'10
8:46 p.m.
On Fri, Mar 12, 2010 at 12:56 PM, Timo Reimann <timo.reimann(a)1und1.de> wrote:
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
Hey Ovidiu,
Ovidiu Sas wrote:
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.
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