Victor Pascual Ávila wrote:
On Sun, Oct 12, 2008 at 8:49 AM, Martin Hoffmann hn@nvnc.de wrote:
That said, our SER server knows the given condition sent from a paired PSTN switch is permanent, eg the SIP caller can't call this number via our network now, tomorrow or next week because of who you they or whom their provider is (or what they failed to buy), so in this situation returning 503 all the way out of our network is correct behavior (as stated in the RFC), and doing so allows the upstream entity to click over to the next preferred carrier that might reach that destination.
I think it isn't. Neither 500 nor 503 is a status code for a permanent situation. The gateway should return a 4xx class code instead because actually this is a client error -- the client is not allowed to call this specific number. Sounds like a 403 to me.
I agree with Martin, a 4xx class code should be used instead.
IMO it sounds like an ISUP Cause value "2 no route to destination" which should be mapped to SIP "404 Not found" (RFC 3398).
Please, correct me if I'm wrong,
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.