[VoiceOps] response code mapping to upstream peers
hiersd at gmail.com
Wed Apr 11 16:13:55 EDT 2012
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