[sr-dev] improving the dialog module

[Iñaki Baz Castillo]

2010/3/12 Klaus Darilion <klaus.mailinglists at pernau.at>:

>>> Why do they have the same to-tag? Actually the to-tag creates a dialog.
>>
>> Yeah my bad, you're completely right. Of course, they do not have any
>> To-tag while still unconfirmed. Still, branches will be mapped to the
>> same dialog.

Hummm, this is not correct. The only response having no To-tag is a
100 Trying (which doesn't create an early-dialog). Any other
provisional response MUST contain a To-tag and identifies an
early-dialog.

The dialog module should create a dialog entry for every early-dialogs
generated by a single request (this can occurs when the proxy itself
forks or when a proxy behind forks, in any case inspecting the To-tag
should do the work).

Having a different dialog entry for each early-dialog is also required
in order to properly handle the CSeq value. For example a request
could be forked in parallel to GW1 and GW2 and GW2 could require
100rel so the UAC would send a PRACK for the early-dialog with GW2.
This PRACK would increase the client CSeq just in the second
early-dialog and this should be updated in the earylu-dialog entry in
the dialog module. If not, local generated requests (as BYE) could
fail if the don't contain and increased CSeq within the appropriate
(early-)dialog.

By fixing this point a potential new issue arises: I use dialog module
to count the number of dialogs per client (in order to limit them). If
a request is forked by the proxy, I still need it to be computed as a
single dialog for the originating client (even if for dialog module
there are two active early-dialogs). A solution would be a new MI
function that counts dialog by Call-ID and From-tag, so two
early-dialogs due to local forking (or remote forking) would be
considered a single dialog for the client.



> So, maybe if a response is received and there is no dialog with this totag,
> just create a new dialog. Also somehow group these early dialogs to destroy
> them in case one of these gets into confirmed state.

They should be destroyed by the 487 received after cancelling them,
right? If no 487 is received then a local timeout would do the job. I
don't see the need of a special handling for forked requests. Instead,
the whold dialog module should be improved to manage early-dialogs
rather than just confirmed dialogs, and this should be all, no need
for more logic.


Regards.


-- 
Iñaki Baz Castillo
<ibc at aliax.net>