[sr-dev] improving the dialog module

[Timo Reimann]

Iñaki Baz Castillo wrote:
>> 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.
> 
> It could occur a corner case (very famous in SIPit events) in which
> two UAS (UAS1 and UAS2) reply 200 for the INVITE at the same time so
> the proxy must relay *both* 200 responses to UAC which must ACK both
> and later send a BYE for one of them. Until such BYE occurs there are
> two established dialogs in the proxy (or there must be).

Since it's up to the UAC what to do with these "concurrent dialogs"
(e.g., immediately BYE one dialog, or keep both for a long period of
time) the creation of another, regular dialog should take care of
things. That is, when a response is about to be forwarded for which a
dialog with the same Call-ID and From-tag already exists, create a
completely new dialog. That way, a concurrent dialog created from such a
race condition would be treated and managed just like another dialog
created "regularly", including in-dialog routing as the dialog
identifiers will differ.

The only issue one have to think about in these scenarios is how to deal
with callbacks as one of the two concurrent dialogs hasn't gone through
the regular "none/early/confirmed" transition but starts off right at
being "confirmed". Maybe a flag or a brand new callback type could be
used to enable users to hook up to dialogs established this very special
way.


>> 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.
> 
> But AFAIK that would fail in case of serial forking as the new branch
> (created after the first one fails) doesn't inherit the callbacks.

Does serial forking imply deletion of the transaction and creation of a
new one? If so, the dialog callbacks will in fact be destroyed. If not,
each branch's provisional response will map to the same transaction and
hence, to the same dialog. I believe the latter is the case but please
correct me if I am wrong.


>> 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.
> 
> Well, a provisional response *containing Record-Route and Contact* is
> required for that, so the UAC can send an in-dialog request (i.e.
> UPDATE) to a specific branch. For this to work in the proxy it's
> needed that the dialog module stores all the early-dialogs (different
> To-tags) as different entries (each one with its own local/remote
> CSeq, route-set and remote-target/Contact-uri).
> 
> So having each early-dialog (each dialog) in its own dialog-out entry
> would do the job.

Yeah, I guess this is were you need dialog-outs. However, if what I
recommended above really works and we (you ;) ) do not find any further
deficits,  it could be that you only need to use dialog-outs for routing
but not for state management. This would make things easier as you would
not have to modify dialog state from both dialog-ins and -outs but just
from dialog-ins.


>> 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,
> 
> It's taken in my approach as each dialog-out entry would store local
> and remote CSeq. In normal circumstances just one dialog-out entry
> would be in "established" status while the others have been cancelled
> or rejected by other UAS's. So finally, when invoking a local BYE from
> Kamailio, it would contain the proper CSeq value according to its
> dialog-out entry.
> 
> As stated above, during a parallel forking a server could require
> 100rel so the UAC would increase the CSeq jsut for such early-dialog,
> sending a PRACK. The dialog module would match the PRACK Call-ID,
> From-tag and To-tag against a dialog-out entry and update it
> accordingly.
> 
> 
>> Are locally generated requests generated in this context in-dialog or
>> even in-early-dialog?
> 
> For now they are in-dialog (in-established-dialog). I expect that it's
> not useful that the proxy could generate local requests withing
> early-dialogs, as just the UPDATE (to change the SDP) and BYE would
> make sense from the UAC's point of view, but from a proxy's point of
> view it can terminate a branch by sending a CANCEL (if the branch is
> locally generated of course).

So this is another set of examples why dialog-outs seem required.


>> 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.
> 
> Agree. I'm trying to figure out the best design taking spirals into
> account. It will take some time to me as I don't find a proper
> solution yet (all the solutions have some corner cases or
> vulnerabilities when handling spirals).

Do you happen to have a list of these corner cases where spiraling or
the dialog module in general fails?

I think it would prove really helpful if we make a checklist of items,
including issues we have already discussed and and those which we
haven't but which you may know. That way, we could verify whether any
new approach discussed here is sufficiently good.

Additionally, I think that as soon as we have figured out the most
important design choices for the improved dialog module, we should set
up a wiki page to maintain the new dialog design and have a rough
specification to implement from.


Cheers,

--Timo