Give SIP to SIP priority on Reason Cause Mapping

5. Configuration
1

Hello,

On a SIP to SIP call, when Q.850 reason is present, ProSBC is given priority to Q.850, and mapping SIP cause to A-leg based on Q.850 of B-leg.

Is it possible, per profile, on a SIP to SIP call give priority to SIP mapping instead of Q.850?

For example now we have the following behavior:

B-leg (SIP)
SIP/2.0 480 Temporarily unavailable
Reason: Q.850;cause=127

A-leg (SIP)
SIP/2.0 500 Internal Server Error
Reason:Q.850;cause=127

Configure a profile to have the following behavior:

B-leg (SIP)
SIP/2.0 480 Temporarily unavailable
Reason: Q.850;cause=127

A-leg (SIP)
SIP/2.0 480 Temporarily unavailable
Reason: Q.850;cause=127

Thanks,

David Costa

2

Hello David,

This is a known behavior — the cause map engine always prioritizes the Q.850 reason code over the SIP status code when both are present. There is currently no per-profile toggle to invert that priority on SIP-to-SIP calls.

The cause map pipeline is: if a Reason header with Q.850 is present, the input to the cause map is that Q.850 code. The SIP status code is only used as input when no Q.850 Reason header exists.

Workaround options:

  1. Adjust the cause map for the specific Q.850 code — Profiles > (profile) > “Edit Reason Cause Mapping”. Change the SIP output for Q.850 cause 127 from 500 to 480. This fixes 127 → 480, but you’d need to do this for every Q.850 code where you want the SIP status to win, and it won’t dynamically follow the incoming SIP code.
  2. Strip the Reason header via a routing script — A custom Ruby routing script can remove the Reason header from the B-leg response before the SBC processes the disconnect. If no Reason header is present, the cause map falls back to the SIP status code as input. This is the closest you can get to dynamic SIP-priority behavior today.

Thank you,
Dave