I have a problem where an upstream provider will correctly send a SIP 486 Busy Here from their voice gateway with a Reason header containing Q.850 cause=17 when a B party is genuinely busy. However if we exceed certain traffic thresholds, instead of receiving a SIP 503 with a retryable cause code, their proxy sitting in front of their voice switch sends us a SIP 486 Busy Here and no reason header. Different user agent and also contains a Server: header that the voice gateway responses do not. Therefore we start failing calls that we would otherwise route advance to another upstream. I want to be able to discern the difference between the two responses and route advance on the false user busy. I've tried using variations of the example LUA code found here https://freeswitch.org/confluence/display/FREESWITCH/Cause+Code+Substitution... but what I have found is that, of the variables I seem to have access to at this point in the call flow, sip_invite_failure_status=486 and last_bridge_hangup_cause=USER_BUSY are set the same in both cases. I think I need to be able to check for the absence of a Reason header or presence of the Server header to know that I have a false user busy. My question is then, is it possible to obtain the specific headers that are present in the B leg response after a failed bridge? I've tried addressing sip_h*, sip_bye_h* type variables but none seem to be populated. I'm guessing that I'm trying to address them in the A leg but they're only present in the B leg. Any tips or advice would be greatly appreciated. David