Hi, On 2020/03/09 20:04, George Joseph wrote: <--snip--> > > BTW: > While you're at it: it would be a great oportunity to get it > sorted out > completely by globaly adding session stability (one trunk always uses > same IP destination for all actions. If the destionation can't be > reached any more (or misbehaves), you have to reregister to another IP > of the list and remember the new IP for all following actions). > > > Yeah, we're thinking that's the only real solution but it's not a > quick fix and will need some serious thought. For instance, if on > registration the first server in the set was successful but when > Asterisk attempted to send a call, the first server failed, would you > expect Asterisk to automatically try to re-register and then use the > new server? That would be a lot of work just to support DT. Now if > they could point to an RFC that codifies their required behavior it > would be a different matter. We checked around and couldn't find > anything however.
I agree with this statement, not aware of anything either. However, also being on the ITSP side, and having similar restrictions in place, as well as knowing what other service providers in SA does similar things (I won't name them, nor the products they use). I would ask that this be given some thought. The least restrictive (and probably least out of line) with RFC "requirements" is to simply require that the source IP address of an invite matches the registered address of the client. Usually this is only checked on the host you're contacting but at least one provider we've encountered has gone to the effort of doing this via a central database, and asterisk would in the current behaviour work with that (as long as the registration stays valid). The majority of SPs that does this would however fail in a similar way as Deutsche Telekom. This restriction used to prevent a sensible amount of fraudulent activity, and with some code modification actually allowed us to detect brute-force attempts and give "wrong password" responses back on INVITE if not from the REGISTERED IP. The behaviours of hackers have however changed. I'd rather not go into the details, but would like to add that the security framework in asterisk 13 onwards helps greatly when used and monitored properly. The one thing I am willing to state w.r.t. behaviour from the fraudsters is that they've taken to after-hours work, and are particularly active between 18:00 on a Friday evening until around 6:00 on a Monday morning, and actually take time zones into consideration. They do now REGISTER before INVITE (not all, but as a general rule). Given the above, these restrictions are less and less useful, and with providers taking more and more efforts w.r.t. redundancy, in general is starting to become counter-productive. Doesn't really help to solve the issue, but I hope it provides some background as to WHY service providers do this. With regards to the temporary workaround - as it turns out, most of our customers prefers registering to a specific IP address as a rule anyway. When we move things around and their stuff breaks they complain profusely, and when pushed as to why they use IP instead of DNS it generally comes to the fore that their routers and/or DNS caches are really bad at something. MT is also a large contributor to this where certain DNS queries are simply not responded to properly (As far as we can determine it relates to larger DNS responses) and others caches failures upon their own link failures. We've taken precautionary measures, but this does mean slowing down certain operations by weeks (and months in extreme cases) in comparison to days. Kind Regards, Jaco
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
