Martin Hoffmann wrote:
This leaves the registrar stuff. But that is writing to the database anyways. What would be more important here is to have it transactional in a sensible way. They way it works now is that if you have database problems, you delay your response which makes your UAs re-send the request which causes more database troubles. (This, BTW, is true for INVITE processing as well -- here you process your request with all the checks and database lookups and whatnots only to find out upon t_relay() that, oops, re-sent INVITE, needs to be dropped, all for nothing). True, this is not a problem if you use the right db_mode.
I think this is a good place for improvement indeed. We have been thinking of some aggregation of delayed writes but haven't moved forward on this yet.
I think a function "t_go_stateful()" might be enough (and use t_reply() in the registrar). The function checks if a transaction for the request exists and if so, ends processing right away. Otherwise it creates a transaction in a prelimary state.
Doesn't t_lookup_request() help you?
regards klaus