[sr-dev] improving the dialog module

[Iñaki Baz Castillo]

2010/3/17 Klaus Darilion <klaus.mailinglists at pernau.at>:

>> 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.

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.



> 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 at aliax.net>