TheVoĉoTheVoĉo
Platform

SIP BYE vs CANCEL: What’s the Difference?

Unravel the crucial differences between SIP BYE and CANCEL methods. Learn when and how to use each for proper SIP call teardown, avoiding common VoIP engineering pitfalls.

Product Team
Product Team
•5 min read
Illustration for SIP BYE vs CANCEL: What’s the Difference?

SIP BYE vs CANCEL: What's the Difference?

In the world of VoIP, managing call lifecycles is paramount. Two fundamental SIP methods, BYE and CANCEL, are often confused but serve distinct purposes in terminating calls. Understanding their precise roles is essential for every VoIP/telecom engineer, developer, and operations specialist working with SIP.

Short Definition

SIP BYE gracefully terminates an established call dialog, signaling the end of an active conversation between two parties. In contrast, SIP CANCEL aborts a pending call attempt that has not yet been answered or fully established. Both are vital for proper session teardown and resource management, but operate at fundamentally different phases of the SIP call lifecycle, reflecting whether a call is already active or merely in progress of being set up.

Why They Exist / What Problem They Solve

Imagine the complexity of managing thousands, even millions, of concurrent phone calls. Without clear mechanisms to end these sessions, resources would quickly be exhausted, leading to system instability, ghost calls, and a poor user experience. BYE and CANCEL are SIP's elegant solutions to this challenge, each tailored for specific termination scenarios:

  • BYE: Ending Established Conversations
    BYE solves the problem of gracefully ending an active, two-way call. Once a call is established (i.e., the caller has received a 200 OK to their INVITE), both endpoints are actively exchanging media. When either party decides to hang up, BYE ensures that all participants are aware the conversation has concluded. This allows User Agents (UAs) and intermediate SIP proxies to reliably free up network, processing, and memory resources associated with that specific call session. Without BYE, calls could linger indefinitely, consuming bandwidth and processing power, leading to what are often called "ghost calls" or "stuck sessions."
  • CANCEL: Aborting Pending Calls
    CANCEL addresses the critical need to stop a call setup attempt before it's ever answered. This is invaluable in common scenarios like misdialing, reaching a busy line, or when a user simply changes their mind and decides not to proceed with the call while it's still ringing. By sending a CANCEL, the caller explicitly tells the network and the called party's device to stop the ringing and discard the call attempt. This prevents unnecessary ringing at the called party's end and ensures that resources allocated for the call setup, such as provisional media paths or routing entries, are promptly released for a call that will ultimately not be established.

How They Work (Step-by-Step)

While both methods aim to terminate a call, their operational mechanics differ significantly, reflecting their purpose for established vs. pending dialogs.

SIP BYE: Terminating an Established Dialog

  1. Initiation: Either party (caller or callee) in an *established* SIP dialog (meaning a 2xx OK response to the initial INVITE has been received and acknowledged with an ACK) decides to terminate the call.
  2. Sending BYE: The User Agent (UA) initiating the teardown sends a BYE request to the other UA. Crucially, this BYE request must be part of the existing dialog. This means it includes the same Call-ID, From header with its tag parameter, and To header with its tag parameter that define the established dialog. The CSeq header will be incremented for this new transaction.
  3. Proxying: Intermediate SIP proxies involved in the original call routing forward the BYE request to the intended recipient, ensuring it reaches the correct endpoint.
  4. Acknowledgment (200 OK): The receiving UA processes the BYE request, ceases media transmission/reception, and upon successful termination of its call leg, responds with a 200 OK to the BYE. This 200 OK confirms that the call is officially ended from its perspective.
  5. Resource Release: Upon receiving the 200 OK to BYE, both UAs and any stateful proxies involved release all resources associated with that call session. The dialog is now considered terminated.

SIP CANCEL: Aborting a Pending Transaction

  1. Initiation: The User Agent Client (UAC) that sent the original INVITE decides to abort the call *before* receiving a final positive response (e.g., a 200 OK) to that INVITE. This typically occurs while the call is still ringing (the UAC has received provisional responses like 180 Ringing or 183 Session Progress).
  2. Sending CANCEL: The UAC sends a CANCEL request. Importantly, the CANCEL request must mirror the Call-ID, From header (including its tag), and the CSeq number of the *original INVITE* it's trying to cancel. The To header should match the one from the INVITE (without a tag, or if present, matching the provisional To tag from 1xx responses).
  3. Proxying: Intermediate SIP proxies forward the CANCEL request towards the User Agent Server (UAS) that is currently processing the INVITE.
  4. UAS Action (Stop Ringing): When the UAS receives the CANCEL, it immediately stops any further processing of the original INVITE. This means it stops ringing the phone, stops forwarding the call, or cancels any pending actions related to the INVITE.
  5. Responding to Original INVITE (487 Request Terminated): The UAS *must* send a final response to the original INVITE, even though it was canceled. The correct response is 487 Request Terminated. This informs the UAC that its INVITE was successfully stopped before establishment. Failure to send this can lead to UAC timeouts.
  6. Responding to CANCEL (200 OK): The UAS also sends a 200 OK to the CANCEL request itself, acknowledging that the cancellation request was successfully processed.
  7. Resource Release: All entities involved in the transaction release any pending resources related to the unestablished call attempt.

Example Message Flows

Below are simplified message flows illustrating the key differences. Note the dialog-identifying headers:

SIP BYE Flow (Ending an Established Call)

Here, Alice hangs up after the call has been established:

Alice (UAC)                Proxy               Bob (UAS)__    |                         |                     |    |    |   INVITE sip:[email protected] SIP/2.0        |    |    |---------------------------------------------->|    |    |                         |                     |    |<-----------------------------------------------|    |    |   SIP/2.0 180 Ringing                        |    |    |                         |                     |    |<-----------------------------------------------|    |    |   SIP/2.0 200 OK (INVITE)                    |    |    |    Via: SIP/2.0/UDP alice.example.com:5060    |    |    |    From: Alice <sip:[email protected]>;tag=123|    |    |    To: Bob <sip:[email protected]>;tag=456      |    |    |    Call-ID: [email protected]       |    |    |    CSeq: 1 INVITE                              |    |---------------------------------------------->|    |    |   ACK sip:[email protected] SIP/2.0            |    |                         |                     |    | << Call Established - Media Flow >>          |    |                         |                     |    |    BYE sip:[email protected] SIP/2.0            |    |    Via: SIP/2.0/UDP alice.example.com:5060    |    |    From: Alice <sip:[email protected]>;tag=123|    |    To: Bob <sip:[email protected]>;tag=456      |    |    Call-ID: [email protected]       |    |    CSeq: 200 BYE                               | << Note CSeq incremented, tags match dialog     |    |---------------------------------------------->|    |                         |                     |    |<-----------------------------------------------|    |    SIP/2.0 200 OK (BYE)                       |    |    Via: SIP/2.0/UDP alice.example.com:5060    |    |    From: Alice <sip:[email protected]>;tag=123|    |    To: Bob <sip:[email protected]>;tag=456      |    |    Call-ID: [email protected]       |    |    CSeq: 200 BYE                               |    |                         |                     |    |<< Call Terminated >>                         |____|_________________________|_____________________|

SIP CANCEL Flow (Aborting a Pending Call)

Here, Alice aborts the call while Bob's phone is still ringing:

Alice (UAC)                Proxy               Bob (UAS)__    |                         |                     |    |    |   INVITE sip:[email protected] SIP/2.0         |    |    |    Via: SIP/2.0/UDP alice.example.com:5060    |    |    |    From: Alice <sip:[email protected]>;tag=abc|    |    |    To: Bob <sip:[email protected]>              |    |    |    Call-ID: [email protected]       |    |    |    CSeq: 1 INVITE                              |    |---------------------------------------------->|    |                         |                     |    |<-----------------------------------------------|    |    |   SIP/2.0 180 Ringing                        |    |    |    Via: SIP/2.0/UDP alice.example.com:5060    |    |    |    From: Alice <sip:[email protected]>;tag=abc|    |    |    To: Bob <sip:[email protected]>;tag=xyz      |    |    |    Call-ID: [email protected]       |    |    |    CSeq: 1 INVITE                              |    |                         |                     |    |    CANCEL sip:[email protected] SIP/2.0          |    |    Via: SIP/2.0/UDP alice.example.com:5060     |    |    From: Alice <sip:[email protected]>;tag=abc |    |    To: Bob <sip:[email protected]>               |    |    Call-ID: [email protected]        |    |    CSeq: 1 CANCEL                              | << Note CSeq matches original INVITE, To tag usually omitted/ignored     |---------------------------------------------->|    |                         |                     |    |<-----------------------------------------------|    |    SIP/2.0 200 OK (to CANCEL)                 |    |    Via: SIP/2.0/UDP alice.example.com:5060    |    |    From: Alice <sip:[email protected]>;tag=abc|    |    To: Bob <sip:[email protected]>              |    |    Call-ID: [email protected]       |    |    CSeq: 1 CANCEL                              |    |                         |                     |    |<-----------------------------------------------|    |    SIP/2.0 487 Request Terminated (to original INVITE)|    |    Via: SIP/2.0/UDP alice.example.com:5060    |    |    From: Alice <sip:[email protected]>;tag=abc|    |    To: Bob <sip:[email protected]>;tag=xyz      |    |    Call-ID: [email protected]       |    |    CSeq: 1 INVITE                              |    |                         |                     |    |<< Call Aborted >>                             |____|_________________________|_____________________|

Call Teardown Sequence Diagram

This diagram visually represents the two distinct call teardown scenarios:

sequenceDiagram    participant UAC as Alice (Caller)    participant Proxy    participant UAS as Bob (Callee)    UAC->>Proxy: INVITE    Proxy->>UAS: INVITE    UAS-->>Proxy: 180 Ringing    Proxy-->>UAC: 180 Ringing    alt Call Established then terminated        UAS-->>Proxy: 200 OK (INVITE)        Proxy-->>UAC: 200 OK (INVITE)        UAC->>UAC: ACK (to 200 OK)        Note over UAC,UAS: Call Established (Media Flow)        UAC->>Proxy: BYE (Call-ID, From/To Tags)        Proxy->>UAS: BYE (Call-ID, From/To Tags)        UAS-->>Proxy: 200 OK (BYE)        Proxy-->>UAC: 200 OK (BYE)        Note over UAC,UAS: Call Terminated    else Call Canceled Before Answer        UAC->>Proxy: CANCEL (Call-ID, CSeq of INVITE)        Proxy->>UAS: CANCEL (Call-ID, CSeq of INVITE)        UAS-->>Proxy: 200 OK (CANCEL)        Proxy-->>UAC: 200 OK (CANCEL)        UAS-->>Proxy: 487 Request Terminated (to original INVITE)        Proxy-->>UAC: 487 Request Terminated (to original INVITE)        Note over UAC,UAS: Call Aborted    end

Common Mistakes and Edge Cases

Even seasoned engineers can stumble over the nuances of BYE and CANCEL. Here are some common pitfalls:

  • Using BYE for Pending Calls: This is arguably the most common mistake. If a call is still ringing and a 200 OK to the INVITE has not yet been received, sending a BYE will be ignored or result in a "481 Call/Transaction Does Not Exist" error. This is because no dialog has been established for BYE to terminate. Always use CANCEL for call attempts in early media or ringing states.
  • Failing to Send 487 to the Original INVITE After CANCEL: A User Agent Server (UAS) receiving a CANCEL request *must* still send a final response to the original INVITE, even if the call was stopped. The correct response is 487 Request Terminated. Failing to do so can leave the User Agent Client's (UAC) INVITE transaction hanging, eventually timing out and potentially leading to resource leaks or retransmissions.
  • Incorrect Dialog or Transaction Identifiers:
    • For BYE: The BYE request must accurately match the Call-ID, From tag, and To tag of the established dialog.
    • For CANCEL: The CANCEL request must match the Call-ID, From header (including its tag), and the CSeq number of the *original INVITE transaction* it's trying to cancel.
    Mismatched identifiers for either BYE or CANCEL will lead to failures like 481 Call/Transaction Does Not Exist.
  • Multiple BYE Messages: Sending multiple BYE messages for the same dialog is generally unnecessary and can indicate faulty state management in an endpoint. Once a BYE is acknowledged with a 200 OK, the dialog is considered terminated.
  • Not Handling BYE from Either Party: SIP allows either the caller or the callee to send a BYE. SIP endpoints and proxies must be prepared to receive a BYE from either side to properly terminate the call and release resources.
  • Lingering Media Streams: While SIP handles signaling, it's crucial that endpoints also stop sending/receiving RTP media packets once a BYE is acknowledged or a CANCEL/487 sequence completes. Otherwise, "one-way audio" after hang-up or unnecessary media traffic might persist, consuming network resources. Implementations should tie signaling events to media session management.
  • Race Conditions with CANCEL: It's possible for a CANCEL to arrive at the UAS simultaneously with or immediately after the UAS sends a 200 OK to the original INVITE. In such cases, the UAS should ignore the CANCEL (as a dialog has already been established) and the UAC should then send a BYE to terminate the now-established call.

Related Terms (Internal Links)

To further deepen your understanding of SIP call flows and methods, explore these related topics:

  • SIP Methods Explained: Beyond BYE and CANCEL, understanding fundamental SIP requests like INVITE, ACK, and REGISTER is vital. For a deeper dive into the building blocks of SIP communication, read our guide on SIP Methods Explained.
  • SIP Call Flow Explained: The sequence of messages for a full call is a complex dance. Explore the complete journey of a SIP call from initiation to termination in our SIP Call Flow Explained article. This will put BYE and CANCEL into the broader context of a complete call.
  • SIP Response Codes: The 200 OK, 180 Ringing, and 487 Request Terminated are all part of the vast array of SIP responses that dictate call progress and state. Learn more about their meanings and implications in our post on SIP Response Codes.
  • SIP Dialog: This is the established peer-to-peer relationship between two UAs, uniquely identified by Call-ID, From tag, and To tag. Understanding dialogs is key to knowing when BYE applies.
  • SIP Transaction: A transaction refers to a request/response exchange, typically an INVITE and its final response, or a BYE and its 200 OK. CANCEL operates on an outstanding INVITE transaction, highlighting its role in managing pending requests.

By mastering the distinction and proper usage of SIP BYE and CANCEL, you'll be well-equipped to design, implement, and troubleshoot robust and efficient VoIP systems. These two methods are small but mighty components in ensuring reliable call management across any SIP network.

Tags:sipvoiptelecombyecancel
Back to all posts