21 Mar
2010
21 Mar
'10
1:22 a.m.
IMHO, I think it's better to have a dialog for each initial INVITE (no
to-tag) that is hitting the proxy and a cloned dialog for each branch.
The original dialog that is created when the INVITE arrives would be
for the first branch. If there's no forking, we are done.
If there is forking, a new dialog will be created (by cloning the
existing one) for each branch.
For each reply (forking case), we match the right dialog (based on branch).
For in dialog requests (for spiral case) we match on Route set.
Once we have a final reply to the original INVITE, there will be on
single winning dialog and all the other dialogs will be destroyed.
It may be a little heavy, but it's a clean design, easy to follow and
debug. And it is addressing all the issues: spiral and forking.
Just my 2c.
As long as the new dialog work is not affecting the existing dialog,
I'm happy. The current dialog design is not perfect, but it works in
most of the common scenarios. If one knows the limitations of the
dialog module, it can come up with workaround solutions and so far I'm
ok with the current dialog module. It can be improved, of course, but
works well for some common scenarios.
Regards,
Ovidiu Sas
On Sat, Mar 20, 2010 at 7:20 PM, Iñaki Baz Castillo <ibc(a)aliax.net> wrote:
2010/3/20 Ovidiu Sas <osas(a)voipembedded.com>om>:
Perhaps you are interested in creating a dialgo if the request comes
from a certain address... just wondering.
Ok, so in this case you would need a dialog for each time the same
INVITE arrives to the proxy, right?
Yes.
In your
case, wouldn't be enought if the dialog is created after the
spiral occurs?
How do you know that a spiral will occur? I mean,
without creating it for the first time the INVITE arrives to
the proxy (so just invoke dlg_manage() after the spiral).
If you have one single dialog for four media endpoints, how are you
going to manage them?
- first INVITE: UAC + P2
- second INVITE: P2 + UAS