2010/3/12 Klaus Darilion klaus.mailinglists@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.