[VoiceOps] response code mapping to upstream peers

[David Hiers]

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