A given system is sending me INVITEs of the form:
INVITE sip:6663338888@111.222.33.44;cic=9876;rn=6663331212;npdi SIP/2.0
that includes some URI parameters, eg the things after the semi-colon.
In this case, the cic=nnnn value is really some internal routing number and not a real PSTN CIC value (like 0288 for AT&T). So when this eventually reaches a switch on the PSTN, that switch sees that someone has already determined the CIC and it attempts to route using what really isn't a CIC at all.
I would like to strip this "cic=nnnn" out of the call within SER, and while there are a number of documented rewriteuri functions for altering the URI in SER, there doesn't seem to be anything that can be used to get at URI parameters. For the above, I would like to trim it to:
INVITE sip:6663338888@111.222.33.44;rn=6663331212;npdi SIP/2.0
as the rn= and npdi values are sane and can be used by the destination switch.
Is there such a beast, or is the only options to add a function/module or use the exec to invoke an external program to do the job?
Thanks in advance.
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-)
Frank Durda IV wrote:
A given system is sending me INVITEs of the form:
INVITE sip:6663338888@111.222.33.44;cic=9876;rn=6663331212;npdi SIP/2.0
that includes some URI parameters, eg the things after the semi-colon.
In this case, the cic=nnnn value is really some internal routing number and not a real PSTN CIC value (like 0288 for AT&T). So when this eventually reaches a switch on the PSTN, that switch sees that someone has already determined the CIC and it attempts to route using what really isn't a CIC at all.
I would like to strip this "cic=nnnn" out of the call within SER, and while there are a number of documented rewriteuri functions for altering the URI in SER, there doesn't seem to be anything that can be used to get at URI parameters. For the above, I would like to trim it to:
INVITE sip:6663338888@111.222.33.44;rn=6663331212;npdi SIP/2.0
as the rn= and npdi values are sane and can be used by the destination switch.
Is there such a beast, or is the only options to add a function/module or use the exec to invoke an external program to do the job?
Thanks in advance.
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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!
:-) Kamailio (previously openser) and SER are in the process of merging (http://sip-router.org). Both already now work very well on a shared core. This means that you with minor changes to your config (the core used is SER 2's) and get access to all the modules across both projects. g-)
Frank Durda IV wrote:
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!
-
Frank Durda IV -
Greger Viken Teigre