16 Mar
2010
16 Mar
'10
5:56 p.m.
2010/3/16 Ovidiu Sas <osas(a)voipembedded.com>om>:
It doesn't change the fact that it remains being the same dialog :)
Not sure which
approach is better, perhaps the second one (from SIP
point of view, the spiral is still a single dialog!).
From a SIP point of view, it is the same dialog, but from a practical
point of view it's a different call (the second INVITE may have a
different SDP). Also, if you have a single dialog, when you need to
send BYEs on
timeout, where will you send the BYEs?
The unique dialog entry (dialog-in entry in the design suggestion)
must be created just for the *first* INVITE (and not when the same
INVITE arrives again due to a spiral). Then when sending a local
generated BYE it must be sent according to the first INVITE (so the
BYE would also do the spiral and so).
The problem is:
UAC --------> P1 -----> P2 -----> P1 -------> UAS
- When the INVITE arrives from UAC to P1, P1 creates the dialog-in
entry (From-tag, Call-ID).
- When the INVITE does spiral and arrives again to P1 from P2, the
dialog module checks that there is already a dialog-in entry with same
From-tag and Call-ID, so a new dialog-in entry is NOT created (even if
the route-set is different).
- UAS replies 200 Ok which arrives first to P1.
- P1 tries to match the 200 response against entries in dialog-in
table. Here is the problem as this response shouldn't match yet the
created dialog, but the only way to know it is by storing the
transaction branch of the last request within the dialog (for both
sides!).
I've been thinking long time about it and I always find corner cases
(or not so "corner") in which the mechanism would fail, there is not a
magic solution (for now).
What about the existing
modules that are already working on top of the existing dialog design?
For example? which modules do work over the dialog module? there are a
lot of such modules in OpenSIPS and all of them fail due to the
current dialog module limitations (same as we are debating here). IMHO
there is nothing to preserve as the current dialog design is just
limited to a few cases (any exotic and not so exotic case break it).
I will spent more time thinking about it. Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>