Changing an existing session
A re-INVITE is an INVITE inside an existing dialog. It can renegotiate media, such as hold direction or a changed media address. UPDATE can modify session parameters without changing the dialog state and may be useful during early dialogs when supported. These methods have different transaction behavior even when both carry SDP. Identify the dialog with Call-ID and tags. A larger CSeq alone does not tell you whether a request is a new call or an update to an existing one.
Offer and answer must remain ordered
Do not interpret every SDP body as an independent instruction. Determine which message contains the offer and which contains its answer, then compare media direction and accepted formats. Overlapping negotiations can be rejected and retried; a 491 Request Pending response can reflect an offer collision rather than an incompatible codec. For hold, compare sendrecv, sendonly, recvonly and inactive attributes on the relevant media section. A phone's mute button may operate locally without any SIP change. Music on hold generated by a PBX also creates behavior that cannot be inferred from one endpoint's SDP alone.
A controlled troubleshooting sequence
Start with a stable answered call. Capture one hold/resume cycle, then repeat for transfer or network change as a separate experiment. Record the before-and-after connection address, port, codec and direction on each PBX leg. If the session update fails, check what media state remains in force rather than assuming the call must terminate. Inspect the rejection response and the endpoint's recovery behavior. Forcing all updates off can hide an interoperability issue while breaking legitimate hold, session refresh or direct-media behavior.
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.