2010/3/16 Timo Reimann <[email protected]>: > Interesting idea. Let me ask two questions: > > (1) I re-checked when dialog state is modified exactly for responses > (and believe I have to doubt what I initially claimed to be true): > > So, taking into account that (serial > and parallel) forking proxies will *forward* responses only when all > forking attempts have finally failed or one succeeded,
Early dialogs are created when a provisional response with a different To-tag arrives, and of course all the provisional responses (different early-dialogs) are relayed by the proxy to the UAC. > wouldn't that > automatically implement your "dialog-outs will properly adjust > dialog-in's state" approach and render dialog-outs unnecessary? Or am I > wrong on the assumption how forking works? Not sure, but I think you miss the case in which parallel forking (or serial forking) is performed by a proxy (P2) behind kamailio (P1): UAC ------------ P1 -------------- P2 ---------------UAS1,UAS2,UAS3 (different To-tags) In this case, for each early-dialog (different To-tag) P1 will receive such response within the same outgoing transaction (P1 just created a single outgoing transaction to relay the INVITE to P2). Theorically onlye the UAC cares about dialogs, and not a proxy. If a proxy must be aware of dialogs (dialog module) it should handle all the early-dialogs, and it doesn't matter if different early-dialogs have been originated due to forking in local proxy or in a proxy in the path (after the local proxy). I'm not sure, however, if this replies your question. If not please explain it to me again. > (2) How would your approach deal with unconfirmed requests traversing > the same proxy multiple times, i.e., what has been denoted as > "spiraling" in this thread, as in this example: > > UA1 --> P1 --> P2 --> P1 --> UA2 > > Will that result in the creation of two dialog(-in)s? As the INVITE from P2 to P1 is a different transaction, it should create a new dialog-in entry. In order to distinguish which INVITE transaction each response belongs to, the dialog module should also store the INVITE branch (in both the dialog-in entry and dialog-out entry/entries pointing to the dialog-in entry). Unfortunatelly in order to match in-dialog requests (as ACK, re-INVITE, UPDATe, BYE...) with the proper dialog-in entry, it would also be needed to store route-set information for each dialog-in entry. This is, in you example if UA1 sends an in-dialog re-INVITE, the only difference between INVITE from UA1 to P1 and the INVITE from P2 to P1 would be the route set. Other approach would be avoiding creating two dialog-in entries for such spiral case. This is, when the INVITE arrives from P2 to P1, P1 would create a new dialog-in entry as there is already a dialog-in entry with same Call-ID and From-tag. Not sure which approach is better, perhaps the second one (from SIP point of view, the spiral is still a single dialog!). -- Iñaki Baz Castillo <[email protected]> _______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
