[VoiceOps] response code mapping to upstream peers

[Tim Thompson]

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 
of cases.

On 04/11/2012 01:13 PM, David Hiers wrote:
> Interesting!
>
> 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...
>
> David
>
>
>
> 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:
>>>>
>>>> Hi,
>>>> 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.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> David
>>>> _______________________________________________
>>>> VoiceOps mailing list
>>>> VoiceOps at voiceops.org
>>>> https://puck.nether.net/mailman/listinfo/voiceops
>>>
>>> _______________________________________________
>>> VoiceOps mailing list
>>> VoiceOps at voiceops.org
>>> https://puck.nether.net/mailman/listinfo/voiceops
>>
>> _______________________________________________
>> VoiceOps mailing list
>> VoiceOps at voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops