Iñaki Baz Castillo wrote:
2010/3/16 Timo Reimann timo.reimann@1und1.de:
(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.
Multiple provisional responses should not interfere with dialog workings, as far as I can tell. But please read on below.
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).
The question is, to what extent does the dialog module need to handle early dialogs in order to track dialogs correctly?
As far as managing dialog state is concerned, multiple provisional responses from different UASes all forwarded to the same UAC shouldn't mess up with the dialog state as they all enforce the same state, i.e., "early". To stick with the routing example above: When the first provisional response (say, from UAS1) passes P1, it will change the dialog state from "none" to "early". When a second provisional response (say, from UAS2) arrives on P1 and is forwarded to UAC, no state transition will occur: The state machine just doesn't do anything when a 1xx response is parsed for a call which is already in the early state.
As far as dialog callbacks are concerned, a bit additional code may be required to make sure that callbacks to DLGCB_EARLY are executed once only. Should be as simple as limiting such callbacks to cases where the dialog state has actually transitioned from DLGCB_NONE to DLGCB_EARLY.
As far as the varying To-tags among different provisional responses are concerned, I wonder if that's an issue. It may suffice to associate just the To-tag from the final response with the dialog state and not any To-tags from provisional responses. However, there is RFC 3261, section 13.2.2.1, which mentions that early dialogs are needed (only) "if the UAC needs to send a request to its peer within the dialog before the initial INVITE transaction completes". I'm not aware whether the current dialog module is already capable of dealing with in-early-dialog messaging, and if not, whether your "dialog-in/dialog-out" approach could do so.
Before, you mentioned 100rel required by certain gateways, resulting in PRACKs, increased CSeq numbers, and problems for locally generated requests. It's not absolutely clear to me whether this is already taken care of by your approach, and whether anything of what I laid out in this post would possibly make such problems look less threatening for the current dialog implementation. Are locally generated requests generated in this context in-dialog or even in-early-dialog?
(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).
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!).
As you have probably noted yourself by now, there has been an ongoing discussion on how to handle spiraling. To me, it seems that a design decision on this sub-topic is crucial and has to be settled before hands-on, coding work on a better, improved dialog module can start.
Cheers,
--Timo