17 Mar
2010
17 Mar
'10
12:55 p.m.
2010/3/17 Klaus Darilion <klaus.mailinglists(a)pernau.at>at>:
But it's also true that more and more modules want to depend on dialog
module (take a look to OpenSIPS loadbalancer or mediaproxy modules).
And they fail when handling forking calls.
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?
Good question. IMHO it should be discarded as TM and dialog level (and
not relayed stateless).
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
But that is not a spoofed reply, instead it's just a 100% valid reply
with a different To-tag. It could occur if the called is a proxy which
performs serial forking (so after some seconds our proxy receives
responses with a new To-tag, i.e. the remote voicemail server).
Then the real 200 OK will be forwarded stateless by tm
module
No, it would be a valid response according to TM.
and may bypass dialog module (if callback is only
triggered is there is a
matching transaction)?
But there is matching transaction so no problem :)
--
Iñaki Baz Castillo
<ibc(a)aliax.net>