Identify the pending operation
491 signals an overlapping request condition. A common case is both ends sending a re-INVITE before the other operation has completed. RFC 5407 illustrates this collision and the recovery exchange. It is not, by itself, evidence that the destination is busy with another telephone call.
Find the earlier outstanding operation on the same dialog. Retain the messages on both sides of the response; a status-code counter cannot show what was competing.
Observe recovery before changing settings
For the illustrated re-INVITE collision, each failure is acknowledged and the retry is delayed using the applicable randomized timing rules. An immediate synchronized retry can repeat the collision. A recovered isolated event may be less significant than the operation that never completes.
Record whether the user’s hold, resume or other requested change eventually succeeds. Keep the original media parameters and compare them with the later accepted change. A failed attempt does not prove that its proposed media settings became active.
Find the source of repeated overlap
Correlate recurring collisions with phone actions, application commands and session refresh activity. If two systems repeatedly request a change together, inspect their control sequence and exact software versions. Avoid globally disabling useful session behavior to hide a single endpoint defect.
For an escalation, provide a bounded redacted trace showing the competing requests, 491, acknowledgements and retries. State the observed user effect and whether the existing call remained usable. After correction, repeat the competing action and confirm that the requested change completes without a retry loop.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.