Re: [Serusers] How can I keep SER from changing reply Response Code from 503 to 500?

Victor Pascual Ávila wrote: No, you probably are not wrong, but you are trying to push a 50 story building that is already built six feet to the left just because you would like it to be there. This is just not going to happen. I have tried to convince these companies (now numbering in the dozens that I have encountered this issue with) that they should use 404 in this situation, but they are consistently adamant, saying the SBC models they own only allows them to redirect calls on receipt of a 503 and will not do so for a 404 or any other more plausable code, although one reluctantly could handle 502 instead of 503. So if I want their business I am stuck catering to their demands, regardless of the SHOULDiness of the RFC on this point. Plus I've got sales people reminding me that the customer is always right, give them what they want, etc. (Oh, I have worked as part of a team or contributor to RFCs that are in force today, and have submitted RFC-DRAFTs over the past 25 years, so I do know a tiny bit about that process. I also know that even if I came up with a RFC that obsoleted the existing SIP ones how unlikely it is to get anybody to accept an expansion of the SIP response code lexicon mainly because of how long the existing limited set has existed and how much embedded hardware (switches, SBCs, etc) exists that will only know the old codes. That's why 2821/2822 look so much like 821/822 and didn't address many issues that needed addressing.) To be clear, even if the RFC said MUST on the current SER handling of 503, I would lose this argument and be forced to provide 503 from SER, or dump SER and replace it with some hardware that will (as apparently most of the turn-key boxes out there will happily do this). This is not what is right or wrong, but what the majority of the gear (that the clients already own) are using 503 for. I suggest taking religious concerns on this point to the makers of SBCs who didn't provide a far better way to do LCR. Shoot, I've got a carrier who also wants us to reject calls they are sending to us if they aren't marked as having been dipped already. And we are return them with what response code? Oh. with a 503 of course. Then they will pass that call on to someone who apparently charges less for database lookups than we do, and then maybe the same now-dipped call will come back to us, or go elsewhere. Maybe the situation elsewhere in the world is different, but in the US I would estimate that currently at least 70% of the companies wanting to send us SIP want us to send back a 503 for at least one condition and no other value will do, due to limitations in the reaction choices available in their equipment, or perhaps this mostly in-company policies they have standardized on even if their equipment could do the same thing in response to some other code. And almost all of those outfits are sending us some or 100% international calls. As mentioned before, too few SIP codes, too many SS7 to SIP overloads in the SIP world. Example: 47 is the SS7 release when call gapping occurs, as in when too many people trying to vote on American Idol or any other contest that hits the pre-defined limit for a giving called party number. What does 47 usually turn into? 503, of course, and what do these carriers do? They promptly try this gapped call somewhere else, where it is also going to fail because the throttle timers likely have not expired yet. Arguably, that situation might be better served by having this become a 600 by the time it gets to SIP, but that is also something out of my control. Telcoridia says a 47 should be produced, and the RFC says turn that into a 503. And SER turns that into 500. And here we are. Meanwhile, back to the original problem I have of making SER emit a 503 or having to dump SER: Someone else pointed out that sl_reply wasn't appropriate where I suggested I could used it, will try t_reply(). If that is still overridden by the SER internals as well (and I was really hoping someone here would save me time by saying if the internal rule could not be defeated via the config file but no one has come forward on that point), then I have no choice then to make another round of changes to the SER source code, or buy a turnkey box and throw SER away. I would prefer to salvage SER and not have the demise of its use here occur over such a silly point, but I'm not getting much confidence here that SER is willing to work with what the rest of the world seems to be doing.