25 Mar
2010
25 Mar
'10
4:32 p.m.
2010/3/25 Timo Reimann <timo.reimann(a)1und1.de>de>:
It's ok IMHO.
Well, it seems we are very close to a definitive design which would
also handle the most complex cases :)
Thanks a lot for all your work.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
It should be
posible to set a dialog flag even in early state (imagine
mediaproxy module setting a dialog flag to force MediaProxy usage, it
must also work if there is RTP during the 183 session progress).
Is it allowed in your proposal?
I haven't explicitly considered it but it's easily feasible: When the
second (just marginally slower) 200 response is handled by the dialog
module, the dflags from the already existing dialog_out entry can be
copied into the new dialog_out entry. For better understanding, please
see the updated example for that specific part of the scenario. However, I'm wondering if this is the way it's
supposed to be done. I
consider the second 200 response to result in the creation of a new
dialog, so it seems wrong that the new dialog already comes with set
flags. For instance, there might be use cases where a set of already
configured dflags is not desired or, worse, breaks things.
Configurability of behavior might be one way out. For further
considerations, let me ask you this about mediaproxy: What does that
module do when multiple early responses with early media arrive for a
single INVITE? Will it relay to a different port for each response?
The fact is that I don't use mediaproxy but I do know about its
limitations when parallel forking occurs.
I think it creates a RTP session (different port-in and port-out) for
each branch having RTP (183 with SDP), but I'm not sure at 100%.
However I do know that using "engage_mediaproxy()" function is not
possible just to force MediaProxy for certains branches (i.e: those
detected as natted). This function is based on dialog module (just one
dialog entry is created as we do know). It's like a "dialog flag" so
there is no need to invoke mediaproxy for in-dialog requests as the
information about using or not mediaproxy belongs to the whole dialog.
This of course makes impossible to use mediaproxy just for certain
branches.
> But I don't like the usage of three tables
(dialog, dialog_in and
> dialog_out), so I've tryed to simplify it by just leaving dialog_in
> and dialog_out tables with some modifications:
>
> - dialog_in contains a new field "dialog_id".
> - dialog_out doesn't contain "hash_id" field anymore. Instead it
> contains "dialog_in".
Oviously I meant:
- dialog_out doesn't contain "hash_id" field anymore. Instead it
contains "dialog_id".
Please let me
know if it's ok or I miss something:
That's a good improvement. When I wrote the proposal amendment, I had
this feeling that three tables weren't optimal but couldn't get my head
around it. Very much appreciated. :)
I replaced my initial approach with yours.