Am 17.03.2010 13:44, schrieb Iñaki Baz Castillo:
2010/3/17 Klaus Darilionklaus.mailinglists@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