Greger Viken Teigre wrote:
Frank, I think you would benefit from looking at a later SER or sip-router (as I believe your own conclusion is right). Why not isolate your tricky stuff into a "tag-for-forwarding-to-my-trickbox" and then set up sip-router to handle those exceptions? You would also benefit from simplifying your core configs. g-)
Is there something later than SER 2.0.0-RC1 (what I am running) and if so, where is it? Or are you meaning switching to OpenSER which seems to have had more recent development. (I've already taken some chunks of OpenSER and back-ported the features into SER.)
Is there actually something in this newer code you are thinking of that will do what I need? If so, what is it called and is there any documentation?
As to the other suggestion, I already run dozens of separate instances of SER not only to deal with the various wackiness out there, but mainly because SER doesn't have a clean way of switching from the running config file to a new one without disrupting everybody. Kill/restart just doesn't play well in the telco world. So almost everybody gets their own instance with all the baggage that brings along. (Had to bump the mysql connection limit way up.) This solution sucks but I see no nice way to to add or fix the traffic from one source without bothering everybody else who is up and running as SER exists today. The language is just too limited to create rules complex enough to just have flags in database that can be set to indicate that that this call is from the guy where you have to substitute this response code for another, or to tell me it is the other guy who needs four guide digits stripped from the front of the URI number, but not if the fifth digit isn't a 1 and the connection is from this IP address range. Oh, and there was the guy last week whose high-dollar box can't cope with "npdi" and has to have "npdi=yes". (sheesh) That sort of junk and plenty more is what I have to panel-beat SER into handling every day. I don't think I can pre-code enough tests and rules to deal with all this crazy stuff in one unified ser,cfg file, not in advance anyway. None of that solves the problem at hand, it just allows me to restrict whatever fix I eventually am able to get to just those that need it and not disturb everybody else while I'm putting it into service.
As i've already had to fix broken stuff rtpproxy and in nathelper plus implement new flags and functions in both, so having to write yet another function to perform the header clean-up that is needed is certainly something I can do, but I would rather avoid writing more stuff if functions exist to do the work already plus I can get this problem solved a lot faster.
If you can point to a release or third-party hack that can do what is needed (delete cic=nnnn), do let me know. Thanks!