[sr-dev] improving the dialog module

[Klaus Darilion]

Am 17.03.2010 13:44, schrieb Iñaki Baz Castillo:
> 2010/3/17 Klaus Darilion<klaus.mailinglists at pernau.at>:
>> Hi!
>>
>> I have not followed the whole discussion. I just had an idea which might be
>> useful: Why not hook up dialog module with tm module? Tm module already
>> knows the state of forked INVITE transaction, which ones are in early
>> states, and which branch is the winner.
>
> This is not valid for the case in which a dialog is forked by a proxy
> behind our proxy. From the point of view of TM it's a single
> transaction.

That's true. It probably depends on what you actually want to track with 
the dialog module. E.g. if you just want to track the number of 
established dialogs then you do not care about multiple early dialogs.

Btw: how are dialogs in dialog module and transactions in tm module are 
exactly identified? For example a response with proper callid and 
fromtag but faked Via branch, will it be accepted by dialog module but 
ignored (drop or stateless forwarding) by tm?

Or the other way round - e.g. a spoofed 200 reply with proper Via 
branchid and false fromtag. Will it terminate the transaction but keep 
the dialog in early state (RFC 3261 says transaction matching does not 
care about callid/tags)? Then the real 200 OK will be forwarded 
stateless by tm module and may bypass dialog module (if callback is only 
triggered is there is a matching transaction)?

Note: This is just speculation as I do not know details about callbacks 
and dialog/transaction matching.

regards
klaus