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

[Frank Durda IV]

Victor Pascual Ávila wrote:
> On Sun, Oct 12, 2008 at 8:49 AM, Martin Hoffmann <hn at 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.