[sr-dev] improving the dialog module

Timo Reimann timo.reimann at 1und1.de
Wed Mar 17 11:52:39 CET 2010


Iñaki Baz Castillo wrote:
> 2010/3/16 Timo Reimann <timo.reimann at 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



More information about the sr-dev mailing list