Section 15 Terminating a Session

This section describes the procedures for terminating a session
   established by SIP.  The state of the session and the state of the
   dialog are very closely related.  When a session is initiated with an
   INVITE, each 1xx or 2xx response from a distinct UAS creates a
   dialog, and if that response completes the offer/answer exchange, it
   also creates a session.  As a result, each session is "associated"
   with a single dialog - the one which resulted in its creation.  If an
   initial INVITE generates a non-2xx final response, that terminates
   all sessions (if any) and all dialogs (if any) that were created
   through responses to the request.  By virtue of completing the
   transaction, a non-2xx final response also prevents further sessions
   from being created as a result of the INVITE.  The BYE request is
   used to terminate a specific session or attempted session.  In this
   case, the specific session is the one with the peer UA on the other
   side of the dialog.  When a BYE is received on a dialog, any session
   associated with that dialog SHOULD terminate.  A UA MUST NOT send a
   BYE outside of a dialog.  The caller's UA MAY send a BYE for either
   confirmed or early dialogs, and the callee's UA MAY send a BYE on
   confirmed dialogs, but MUST NOT send a BYE on early dialogs.
   However, the callee's UA MUST NOT send a BYE on a confirmed dialog
   until it has received an ACK for its 2xx response or until the server
   transaction times out.  If no SIP extensions have defined other
   application layer states associated with the dialog, the BYE also
   terminates the dialog.
   The impact of a non-2xx final response to INVITE on dialogs and
   sessions makes the use of CANCEL attractive.  The CANCEL attempts to
   force a non-2xx response to the INVITE (in particular, a 487).
   Therefore, if a UAC wishes to give up on its call attempt entirely,
   it can send a CANCEL.  If the INVITE results in 2xx final response(s)
   to the INVITE, this means that a UAS accepted the invitation while
   the CANCEL was in progress.  The UAC MAY continue with the sessions
   established by any 2xx responses, or MAY terminate them with BYE.
      The notion of "hanging up" is not well defined within SIP.  It is
      specific to a particular, albeit common, user interface.
      Typically, when the user hangs up, it indicates a desire to
      terminate the attempt to establish a session, and to terminate any
      sessions already created.  For the caller's UA, this would imply a
      CANCEL request if the initial INVITE has not generated a final
      response, and a BYE to all confirmed dialogs after a final
      response.  For the callee's UA, it would typically imply a BYE;
      presumably, when the user picked up the phone, a 2xx was
      generated, and so hanging up would result in a BYE after the ACK
      is received.  This does not mean a user cannot hang up before
      receipt of the ACK, it just means that the software in his phone
      needs to maintain state for a short while in order to clean up
      properly.  If the particular UI allows for the user to reject a
      call before its answered, a 403 (Forbidden) is a good way to
      express that.  As per the rules above, a BYE can't be sent.
15.1 Terminating a Session with a BYE Request
15.1.1 UAC Behavior
   A BYE request is constructed as would any other request within a
   dialog, as described in Section 12.
   Once the BYE is constructed, the UAC core creates a new non-INVITE
   client transaction, and passes it the BYE request.  The UAC MUST
   consider the session terminated (and therefore stop sending or
   listening for media) as soon as the BYE request is passed to the
   client transaction.  If the response for the BYE is a 481
   (Call/Transaction Does Not Exist) or a 408 (Request Timeout) or no
   response at all is received for the BYE (that is, a timeout is
   returned by the client transaction), the UAC MUST consider the
   session and the dialog terminated.
15.1.2 UAS Behavior
   A UAS first processes the BYE request according to the general UAS
   processing described in Section 8.2.  A UAS core receiving a BYE
   request checks if it matches an existing dialog.  If the BYE does not
   match an existing dialog, the UAS core SHOULD generate a 481
   (Call/Transaction Does Not Exist) response and pass that to the
   server transaction.
      This rule means that a BYE sent without tags by a UAC will be
      rejected.  This is a change from RFC 2543, which allowed BYE
      without tags.
   A UAS core receiving a BYE request for an existing dialog MUST follow
   the procedures of Section 12.2.2 to process the request.  Once done,
   the UAS SHOULD terminate the session (and therefore stop sending and
   listening for media).  The only case where it can elect not to are
   multicast sessions, where participation is possible even if the other
   participant in the dialog has terminated its involvement in the
   session.  Whether or not it ends its participation on the session,
   the UAS core MUST generate a 2xx response to the BYE, and MUST pass
   that to the server transaction for transmission.
   The UAS MUST still respond to any pending requests received for that
   dialog.  It is RECOMMENDED that a 487 (Request Terminated) response
   be generated to those pending requests.