[sr-dev] improving the dialog module

Iñaki Baz Castillo ibc at aliax.net
Wed Mar 17 12:20:08 CET 2010


2010/3/17 Timo Reimann <timo.reimann at 1und1.de>:

>> 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.

Take for exmaple mediaproxy module and its function
"engage_mediaproxy" which is based on dialog module. It doesn't work
when there is forking! This is, if you call such function then the SDP
is modified for all the parallel or serial branches you create. This
is due to the dialog module limitation.



>> 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.

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).



> 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.



> 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.



> 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).



> 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).


Regards.



-- 
Iñaki Baz Castillo
<ibc at aliax.net>



More information about the sr-dev mailing list