In 6.2 and earlier releases, SM alternate routes on a 603 or 606 response. This is not allowed by the JSR 289 specification and so the behavior was removed in 6.3.
In 6.1 and earlier releases, SM does not alternate route on a 404 or 486 response, and it always tries all resolved IP addresses / entity links before trying the next routing policy.
Handling Responses:
If the request succeeds (i.e., a 2xx is received), the call is completed. If a 3xx response is received, the response is passed back to the caller. If any 4xx (except 422, 423, 484), 500, 501, 502, 503, or 504 response is received, SM alternate routes. In the case of a 408, 500, 501, 502, 503 or 504 response SM alternate routes to the next resolved IP address. Once all IP addresses for the SIP Entity have been tried unsuccessfully, other entity links will then be tried unless all responses contained a Retry-After header, in which case SM will alternate route to the next routing policy. In the case of any 4xx (except 408) response, SM skips any remaining IP addresses / entity links for the current SIP entity and alternate routes to the next routing policy.
The above behavior is as of release 6.3. Earlier releases have slightly different behaviors.
There is a new module parameter in 6.3.4, if they manually want to stop this.
http://downloads.avaya.com/css/P8/documents/100168166
page 272
==> noar: In SM 6.3.4 and later, this parameter can contain a comma-separated list of SIP response codes and only applies during egress adaptation. If present, then it can be used to override the default alternate routing behavior. The SM will not alternate route a request to the next SIP entity if it gets one of the listed responses. Example: noar=404,486.
