Currently, when making an outbound call through a carrier that has multiple gateways configured, Jambonz will automatically attempt to use the next available gateway if the first one fails. This is excellent for handling technical failures (e.g., a gateway is unreachable).
However, this logic does not distinguish between a technical failure and a deliberate rejection by the called party. If a user receives a call and explicitly rejects it (e.g., by pressing the "decline" button on their phone), their device sends a final SIP response like 603 Decline or 486 Busy Here. Jambonz currently interprets this as a failure and immediately places a second call attempt via the next gateway.
This behavior results in a poor user experience for the recipient, who receives a second, immediate call after they have already indicated they do not wish to answer. It can be perceived as aggressive or spammy and is not the intended behavior for most calling applications.
I propose the introduction of a configuration option that allows administrators to specify a list of SIP response codes that should be considered "final" and should not trigger a failover to the next gateway.
Currently, when making an outbound call through a carrier that has multiple gateways configured, Jambonz will automatically attempt to use the next available gateway if the first one fails. This is excellent for handling technical failures (e.g., a gateway is unreachable).
However, this logic does not distinguish between a technical failure and a deliberate rejection by the called party. If a user receives a call and explicitly rejects it (e.g., by pressing the "decline" button on their phone), their device sends a final SIP response like 603 Decline or 486 Busy Here. Jambonz currently interprets this as a failure and immediately places a second call attempt via the next gateway.
This behavior results in a poor user experience for the recipient, who receives a second, immediate call after they have already indicated they do not wish to answer. It can be perceived as aggressive or spammy and is not the intended behavior for most calling applications.
I propose the introduction of a configuration option that allows administrators to specify a list of SIP response codes that should be considered "final" and should not trigger a failover to the next gateway.