Hello Bogdan, An lun., févr 08, 2010, Bogdan-Andrei Iancu schrieb: >[email protected] wrote: >> Thinking today about why my messages are sometimes routed to >> nonexistent TCP endpoints, I came upon the following idea: >> >> It seems that if the usrloc db_mode is anything but 0, >> then TCP AORs could be read from the database after a >> crash. This can't work because once OpenSIPS stops, >> the TCP connections are destroyed. They aren't reusable >> again, because routers and firewalls would block the >> connections that OpenSIPS tries to reestablish. >> >> First of all, is that right? >> >That is correct. > >> If so, then for what reason are the db_modes 1, 2, and 3 >> even useful at all? For UDP-only systems, right? >> >not really. Even if the TCP conn is lost while the registration >still valid, the conn can be re-established from the client side >(like the client placing a call). > I tested this and at least with my routers when a TCP connection to OpenSIPS is lost the NAT binding is destroyed. Should the UAC place a call once OpenSIPS is started again, a new TCP connection is created with a new NAT binding and a different outgoing TCP port.
That means that should OpenSIPS reuse the old TCP port from the registration in usrloc, then it could send for example a NOTIFY to the wrong place, right? By the way, I set db_mode to 0 to avoid this problem. The location table in db_text is still being populated when save() is called. Doesn't the db_mode '0' parameter of usrloc mean that nothing will be written to the database when save() is called? Regards, Brian _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
