17 Mar
2010
17 Mar
'10
12:40 p.m.
Am 17.03.2010 13:44, schrieb Iñaki Baz Castillo:
2010/3/17 Klaus
Darilion<klaus.mailinglists(a)pernau.at>at>:
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
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.