Hello,
On 4/11/11 12:23 PM, Klaus Darilion wrote:
Am 11.04.2011 10:17, schrieb Alex Balashov:
On 04/11/2011 03:25 AM, Klaus Darilion wrote:
Thus: Check for to-tag. This is how you can differ out-of-dialog requests from in-dialog requests. Only if the to-tag is present, call loose_route().
I suppose in principle the problem here is that has_totag() only checks if there is *a* To-tag, not whether it is a valid To-tag associated with a known dialog.
Yes, that's the disadvantage of a transaction-only stateful proxy.
Takeing a look at the previous problems with dialog module, and the recent problems, I prefer to not use dialog module even in the case someone my abuse my proxy as reflector. ;-)
first, skipping authentication for within dialog requests in default configuration file comes mainly from the early years when not many sip endpoints supported that. But can be done, of course and perhaps it should be enabled (or at least added as a #!define option).
We all know that Kamailio has a programable configuration file, the default one is given to address most common (and basic) needs and be a reliable starting point to add more actions to it, but surely can be improved a lot in terms of security and features. For example, one can tighten the checks by allowing traffic/calls only from registered endpoints (checking source IP and port using $ulc(...)) and from trusted peers. When allowing traffic from external untrusted networks, then for sure you have to analyze and add more security checks.
In Debian-like OS-es, kamailio does not start by default when it is installed from packages -- people have to edit the defaults file for it, making in this way sure that the admins at least know they started the service -- hopefully, also they understand what the config is doing.
To ship kamailio with most secure config it would be very easy, here it is that one:
route { exit; }
Then let the people build from this one so they are fully aware of what they add there :-) ...
Regarding dialog states, it is not really needed to use dialog module, I use a lot htable for this purpose -- using call-id and the tags to build the keys, you can track lot of attributes, as you need, e.g., the IP addresses, auth state, a.s.o.
Cheers, Daniel