[VoiceOps] response code mapping to upstream peers
timthompson at nicodem.us
Wed Apr 11 16:38:36 EDT 2012
You can try that, but that's also assuming the peer in the middle isn't
manipulating it, themselves (and will also stop recursing on a 6xx).
We run into that same scenario quite a bit, ourselves; it can add up to
some insane PDD. Our solution was to add a level of loop detection in
our LCR, and 503 them. So far that seems to be working in the majority
On 04/11/2012 01:13 PM, David Hiers wrote:
> 502s are a bit of a pain for us. Every so often, one of the peers of
> our peer will use a 502 as a reason to retry the call as fast as they
> can, forever. The current hypothesis is that the remote peer has a
> couple of connections to our adjacent peer, and cycles between a small
> number of routes, all which come back to us, so all generate another
> round of 502s, so we get flooded with INVITEs.
> Thinking about a 6xx as an "abandon all hope" response...
> On Tue, Apr 10, 2012 at 4:06 PM, Tim Thompson<timthompson at nicodem.us> wrote:
>> We do this quite a bit, as well. We map many 4xx and 6xx responses to 503,
>> which seems to be the code most switches want to see to route advance.
>> Otherwise, they often just give up, instead of moving on to the next egress.
>> On 04/10/2012 03:50 PM, Ryan Delgrosso wrote:
>>> I actually do quite a bit of this.
>>> Metaswitch has a tendency to return 502 messages when what people
>>> actually want to see is a 503, 486, or 480 (depending on the case and
>>> direction of the call and if route advancing is desired or not). I also
>>> use this to sanitize things a tad on my access side.
>>> On 04/09/2012 01:33 PM, David Hiers wrote:
>>>> Does anyone do any response code mapping on the peer side? You can
>>>> deny information to attackers by changing you codes from the default
>>>> (turn a BUSY HERE into a BAD GATEWAY, at the SBC, for instance), and
>>>> I'm wondering if anyone has found a good reason to do so.
>>>> VoiceOps mailing list
>>>> VoiceOps at voiceops.org
>>> VoiceOps mailing list
>>> VoiceOps at voiceops.org
>> VoiceOps mailing list
>> VoiceOps at voiceops.org
More information about the VoiceOps