2010/3/12 Klaus Darilion <[email protected]>: >>> 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 <[email protected]> _______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
