chan_pjsip: Require inband_progress and negotiated SDP before mapping RINGING to 183

[qnic11]

Dear maintainers, we are proposing a change to narrow the conditions under which AST_CONTROL_RINGING is mapped to 183 Session Progress.

Previously, the 183 path was selected when either inband_progress was enabled or SDP negotiation had already reached PJMEDIA_SDP_NEG_STATE_DONE. This could result in 183 being sent for early-offer calls where SDP was negotiated, even if the endpoint was not configured for in-band progress.

With this change, 183 is only selected when both conditions are met:

• inband_progress is enabled
• SDP negotiation is in PJMEDIA_SDP_NEG_STATE_DONE

In all other cases, AST_CONTROL_RINGING maps to 180 Ringing.

This avoids using SDP negotiation state alone as a trigger for 183, and instead ties the behavior to explicit endpoint configuration combined with confirmed media readiness.

[sangoma-oss-cla]

All committers have signed the CLA.

[jcolp]

Don't we already have an option to alter this behavior? Specifically "allow_sending_180_after_183"?

[qnic11]

Dear jcolp, thank you for your feedback, we appreciate it.

You are correct that allow_sending_180_after_183 influences provisional response behavior, and this patch is not meant to modify or deprecate that option; that setting applies to a different stage of the decision process: it controls whether a 180 Ringing can be sent after a 183 Session Progress has already been issued.

In the case of this patch, the intention is to evaluate a stricter condition where inband_progress acts as a requirement, so that SDP negotiation state alone does not trigger the use of 183.

We hope this makes sense to you and look forward to your feedback.

Regards,

[jcolp]

We do not change default/existing behavior unless absolutely necessary. As it is, this change will not be accepted.

[jcolp]

You also haven't explained why this change is needed.

[qnic11]

Dear jcolp, the reason for this change is based on observed behavior in early-offer call flows, where AST_CONTROL_RINGING may be translated to 183 Session Progress even when the endpoint is not configured with inband_progress.

In early-offer INVITE scenarios (INVITE with SDP), SDP negotiation typically reaches PJMEDIA_SDP_NEG_STATE_DONE before the first non-final response is sent. As a result, the existing condition frequently evaluates true in practice, causing ringing indications (AST_CONTROL_RINGING) to be represented as 183 based solely on SDP state.

The proposed change ensures that 183 is only selected when explicitly configured (inband_progress) and when SDP negotiation has completed, avoiding implicit upgrades of ringing to progress.

We hope this makes sense to you.

Regards,

[jcolp]

That's not really a reason or explanation sufficient enough to warrant changing this behavior that has existed for 20+ years. The behavior was written based on the behavior of chan_sip, as some endpoints do not handle 180 after SDP negotiation/183 well. This is why the 180 after 183 option was added as someone wanted to change that behavior, and so it was made optional and defaults to off so as to preserve the existing.

This change will not be accepted.

[qnic11]

Dear jcolp, thank you for your feedback and clarification.

We are trying to determine the most appropriate approach for handling a scenario observed in our deployment, where different endpoints within the same system have differing expectations for provisional signaling behavior.

In particular, some endpoints require 180 Ringing semantics for alerting, while others rely on 183 Session Progress to support early media.

From reviewing the current implementation, inband_progress provides per-endpoint control, but the effective behavior may still be influenced by SDP negotiation state. As a result, it is not clear to us how to enforce consistent per-endpoint behavior.

We would appreciate your guidance on the recommended approach for this use case. If the current behavior is considered correct by design, would an endpoint-level option to control this decision be an acceptable direction? We would be happy to iterate on the proposal accordingly.

Thank you.

[jcolp]

Okay, so now you're starting to provide an actual explanation over why you've done this in the first place.

How do the existing options not suffice? Provide actual examples of the SIP messages when using the options, and show what you actually need. It is still unclear what exactly is insufficient or what you are actually wanting that is not possible with the existing options.

[qnic11]

Dear jcolp, thank you again for your support and patience.

We have observed this behavior in production environments and the relevant SIP traces involve customer and ISP traffic, so sharing them publicly requires additional authorization on our side that might slow down or even block this case.

Would it be acceptable to share the traces with you privately (e.g., via email) to help illustrate the scenario?

In parallel, we can work on preparing a minimal reproducible example that can be shared publicly if needed.

Regards,

[jcolp]

Sharing privately does not provide public history or allow others to participate or provide input with the same information. SIPp scenario files for example that are written to demonstrate are perfectly fine as well. You will also need to provide accompanying endpoint configuration, and confirm that the existing options do not suffice.