[sr-dev] new dialog module design: tm trigger for dialog management

Timo Reimann timo.reimann at 1und1.de
Thu Mar 25 15:15:55 CET 2010


Iñaki Baz Castillo wrote:
> 2010/3/24 Timo Reimann <timo.reimann at 1und1.de>:
> 
>> Considering the corner case of two branches' 200 responses arriving at
>> exactly the same time (let's name them concurrently confirmed dialogs),
>> I believe that this should yield two completely independent dialog
>> entries, with one dialog_in and dialog_out each.
> 
> How and when would be the second dialog_in entry be generated?
> The only approch coming to my mind is generating a new dialog_in entry
> if a new 200 arrives for an already established dialog. Not sure if it
> adds too much complexity or becomes easier to manage...

Generating a new dialog_in entry if a new 200 arrives is what I had in
mind. Should be easy to do because response messages contain the
associated request message as well, so you would just call the
yet-to-be-written create_dialog_in() function based on the request
message. This should be fairly similar to what you need to do when a
request message forms the basis for dialog generation.

The only tricky part is the dialog hash ID added to the record-route
header during request processing. Since the two UASes that
simultaneously answered 200 already stored the dialog hash ID in their
respective route sets, both dialogs must be managed under the same hash
ID. Consequently, the dialog module must keep a list of dialog_ins
maintained under the same hash ID. They will be distinguishable by the
varying To-tags which must be taken into account during in-request routing.

I realize that this introduces a certain degree of ugliness in the
design but I see this as the price in order to handle concurrent dialogs
truly separately.


>> Managing them under the
>> same dialog_in as two dialog_outs gives the impression that they are
>> somewhat related but this is not true as each carries a unique dialog
>> identifier.
> 
> But the complete dialog identifier is the union of a dialog_in entry
> and a dialog_out entry. By itself, a dialog_in entry means "nothing".

I agree with that. However, by attaching dialog callbacks to the
dialog_in entry, you associate multiple dialog_outs resulting from
concurrent 200 responses to the same dialog from a user's perspective.
That's why I believe they need to be separated.

Don't get me wrong -- I still want to keep one dialog_out per confirmed
response. However, I do not see them attached properly under the same
dialog_in entry. Instead, there should be distinct dialog_ins per
confirmed response, and that includes concurrent 200 responses.


> When parallel forking occurs and we have different ringing branches
> it's clear that the approach of having one dialog_in for N dialog_out
> is appropriate. Each dialog_out means a early-dialog. When some of
> them is established it becomes a "dialog", but the concept is the same
> (IMHO).
> 
> If the same INVITE receives two different 200 (so two established
> dialogs) both belong to the same dialog_in entry, while each dialog
> has its own properties (cseq, route-set, target, dflags...) in its
> corresponding dialog_out entry. IMHO it makes sense.

Again, I do not think it does from a dialog module user's perspective.
In the current proposal, you cannot use the dialog module callbacks to
track just one of the two calls, you can only track either both or none.
That's not how it should be as each 200 response constitutes a distinct
SIP dialog, and the modules' callbacks should be able to reflect that.


>> Instead, there should be a clean separation of the two dialogs supported
>> by a new dialog callback type (e.g., DLGCB_CONCURRENTLY_CONFIRMED) which
>> allows the user to decide whether he wants to track the additionally
>> confirmed dialog as well, and how long he wants to track it based on
>> further dialog callbacks he chooses. For example, he may register
>> DGLCB_TERMINATED on the additional dialog or opt that getting to know
>> about its generation is sufficient. Generally, in-dialog requests will
>> be mapped to the respective dialogs (which may involve some more effort
>> because dialog hashes are stored in the route headers during processing
>> of the initial request, but it's doable) and managed individually.
> 
> Then you couldn't set specific dflags to the secondly generated
> dialog, neither manage it as any other "normal" dialog.
> Imagine the UAC receives both 200 and sends the BYE for the first one.
> Then there would exist an active dialog for which dialog module is not
> storing its information properly. Do I miss something here?

I think a callback to DLGCB_CONCURRENTLY_CONFIRMED should be treated
similar to a callback to DLGCB_CREATED, i.e., it is not related to a
prior dialog. So the earliest moment a user can set dflags on a
concurrently confirmed dialog is when DLGCB_CONCURRENTLY_CONFIRMED is
executed, analogous to a regularly created dialog and DLGCB_CREATED.
After that, both call type's dflags should be usable in the same fashion.

If this doesn't answer your question or you think I got something wrong...


> But I still need to understand the possible limitation in double-200
> scenarios. Could you please draw an example of how the dialog table(s)
> would look when such scenario occurs? :)

...please have a look at the wiki section covering an example scenario I
just created

http://www.kamailio.org/dokuwiki/doku.php/dialog-stateful:new-dialog-module-design#concurrently_confirmed_calls

and add further comments here.


Cheers,

--Timo



More information about the sr-dev mailing list