13 Initiating a Session

13.1 Overview

   When a user agent client desires to initiate a session (for example,
   audio, video, or a game), it formulates an INVITE request.  The
   INVITE request asks a server to establish a session.  This request
   may be forwarded by proxies, eventually arriving at one or more UAS
   that can potentially accept the invitation.  These UASs will
   frequently need to query the user about whether to accept the

   invitation.  After some time, those UASs can accept the invitation
   (meaning the session is to be established) by sending a 2xx response.
   If the invitation is not accepted, a 3xx, 4xx, 5xx or 6xx response is
   sent, depending on the reason for the rejection.  Before sending a
   final response, the UAS can also send provisional responses (1xx) to
   advise the UAC of progress in contacting the called user.

   After possibly receiving one or more provisional responses, the UAC
   will get one or more 2xx responses or one non-2xx final response.
   Because of the protracted amount of time it can take to receive final
   responses to INVITE, the reliability mechanisms for INVITE
   transactions differ from those of other requests (like OPTIONS).
   Once it receives a final response, the UAC needs to send an ACK for
   every final response it receives.  The procedure for sending this ACK
   depends on the type of response.  For final responses between 300 and
   699, the ACK processing is done in the transaction layer and follows
   one set of rules (See Section 17).  For 2xx responses, the ACK is
   generated by the UAC core.

   A 2xx response to an INVITE establishes a session, and it also
   creates a dialog between the UA that issued the INVITE and the UA
   that generated the 2xx response.  Therefore, when multiple 2xx
   responses are received from different remote UAs (because the INVITE
   forked), each 2xx establishes a different dialog.  All these dialogs
   are part of the same call.

   This section provides details on the establishment of a session using
   INVITE.  A UA that supports INVITE MUST also support ACK, CANCEL and
   BYE.

13.2 UAC Processing

13.2.1 Creating the Initial INVITE

   Since the initial INVITE represents a request outside of a dialog,
   its construction follows the procedures of Section 8.1.1.  Additional
   processing is required for the specific case of INVITE.

   An Allow header field (Section 20.5) SHOULD be present in the INVITE.
   It indicates what methods can be invoked within a dialog, on the UA
   sending the INVITE, for the duration of the dialog.  For example, a
   UA capable of receiving INFO requests within a dialog [34] SHOULD
   include an Allow header field listing the INFO method.

   A Supported header field (Section 20.37) SHOULD be present in the
   INVITE.  It enumerates all the extensions understood by the UAC.

   An Accept (Section 20.1) header field MAY be present in the INVITE.
   It indicates which Content-Types are acceptable to the UA, in both
   the response received by it, and in any subsequent requests sent to
   it within dialogs established by the INVITE.  The Accept header field
   is especially useful for indicating support of various session
   description formats.

   The UAC MAY add an Expires header field (Section 20.19) to limit the
   validity of the invitation.  If the time indicated in the Expires
   header field is reached and no final answer for the INVITE has been
   received, the UAC core SHOULD generate a CANCEL request for the
   INVITE, as per Section 9.

   A UAC MAY also find it useful to add, among others, Subject (Section
   20.36), Organization (Section 20.25) and User-Agent (Section 20.41)
   header fields.  They all contain information related to the INVITE.

   The UAC MAY choose to add a message body to the INVITE.  Section
   8.1.1.10 deals with how to construct the header fields -- Content-
   Type among others -- needed to describe the message body.

   There are special rules for message bodies that contain a session
   description - their corresponding Content-Disposition is "session".
   SIP uses an offer/answer model where one UA sends a session
   description, called the offer, which contains a proposed description
   of the session.  The offer indicates the desired communications means
   (audio, video, games), parameters of those means (such as codec
   types) and addresses for receiving media from the answerer.  The
   other UA responds with another session description, called the
   answer, which indicates which communications means are accepted, the
   parameters that apply to those means, and addresses for receiving
   media from the offerer. An offer/answer exchange is within the
   context of a dialog, so that if a SIP INVITE results in multiple
   dialogs, each is a separate offer/answer exchange.  The offer/answer
   model defines restrictions on when offers and answers can be made
   (for example, you cannot make a new offer while one is in progress).
   This results in restrictions on where the offers and answers can
   appear in SIP messages.  In this specification, offers and answers
   can only appear in INVITE requests and responses, and ACK.  The usage
   of offers and answers is further restricted.  For the initial INVITE
   transaction, the rules are:

      o  The initial offer MUST be in either an INVITE or, if not there,
         in the first reliable non-failure message from the UAS back to
         the UAC.  In this specification, that is the final 2xx
         response.

      o  If the initial offer is in an INVITE, the answer MUST be in a
         reliable non-failure message from UAS back to UAC which is
         correlated to that INVITE.  For this specification, that is
         only the final 2xx response to that INVITE.  That same exact
         answer MAY also be placed in any provisional responses sent
         prior to the answer.  The UAC MUST treat the first session
         description it receives as the answer, and MUST ignore any
         session descriptions in subsequent responses to the initial
         INVITE.

      o  If the initial offer is in the first reliable non-failure
         message from the UAS back to UAC, the answer MUST be in the
         acknowledgement for that message (in this specification, ACK
         for a 2xx response).

      o  After having sent or received an answer to the first offer, the
         UAC MAY generate subsequent offers in requests based on rules
         specified for that method, but only if it has received answers
         to any previous offers, and has not sent any offers to which it
         hasn't gotten an answer.

      o  Once the UAS has sent or received an answer to the initial
         offer, it MUST NOT generate subsequent offers in any responses
         to the initial INVITE.  This means that a UAS based on this
         specification alone can never generate subsequent offers until
         completion of the initial transaction.

   Concretely, the above rules specify two exchanges for UAs compliant
   to this specification alone - the offer is in the INVITE, and the
   answer in the 2xx (and possibly in a 1xx as well, with the same
   value), or the offer is in the 2xx, and the answer is in the ACK.
   All user agents that support INVITE MUST support these two exchanges.

   The Session Description Protocol (SDP) (RFC 2327 [1]) MUST be
   supported by all user agents as a means to describe sessions, and its
   usage for constructing offers and answers MUST follow the procedures
   defined in [13].

   The restrictions of the offer-answer model just described only apply
   to bodies whose Content-Disposition header field value is "session".
   Therefore, it is possible that both the INVITE and the ACK contain a
   body message (for example, the INVITE carries a photo (Content-
   Disposition: render) and the ACK a session description (Content-
   Disposition: session)).

   If the Content-Disposition header field is missing, bodies of
   Content-Type application/sdp imply the disposition "session", while
   other content types imply "render".

   Once the INVITE has been created, the UAC follows the procedures
   defined for sending requests outside of a dialog (Section 8).  This
   results in the construction of a client transaction that will
   ultimately send the request and deliver responses to the UAC.

13.2.2 Processing INVITE Responses

   Once the INVITE has been passed to the INVITE client transaction, the
   UAC waits for responses for the INVITE.  If the INVITE client
   transaction returns a timeout rather than a response the TU acts as
   if a 408 (Request Timeout) response had been received, as described
   in Section 8.1.3.

13.2.2.1 1xx Responses

   Zero, one or multiple provisional responses may arrive before one or
   more final responses are received.  Provisional responses for an
   INVITE request can create "early dialogs".  If a provisional response
   has a tag in the To field, and if the dialog ID of the response does
   not match an existing dialog, one is constructed using the procedures
   defined in Section 12.1.2.

   The early dialog will only be needed if the UAC needs to send a
   request to its peer within the dialog before the initial INVITE
   transaction completes.  Header fields present in a provisional
   response are applicable as long as the dialog is in the early state
   (for example, an Allow header field in a provisional response
   contains the methods that can be used in the dialog while this is in
   the early state).

13.2.2.2 3xx Responses

   A 3xx response may contain one or more Contact header field values
   providing new addresses where the callee might be reachable.
   Depending on the status code of the 3xx response (see Section 21.3),
   the UAC MAY choose to try those new addresses.

13.2.2.3 4xx, 5xx and 6xx Responses

   A single non-2xx final response may be received for the INVITE.  4xx,
   5xx and 6xx responses may contain a Contact header field value
   indicating the location where additional information about the error
   can be found.  Subsequent final responses (which would only arrive
   under error conditions) MUST be ignored.

   All early dialogs are considered terminated upon reception of the
   non-2xx final response.

   After having received the non-2xx final response the UAC core
   considers the INVITE transaction completed.  The INVITE client
   transaction handles the generation of ACKs for the response (see
   Section 17).

13.2.2.4 2xx Responses

   Multiple 2xx responses may arrive at the UAC for a single INVITE
   request due to a forking proxy.  Each response is distinguished by
   the tag parameter in the To header field, and each represents a
   distinct dialog, with a distinct dialog identifier.

   If the dialog identifier in the 2xx response matches the dialog
   identifier of an existing dialog, the dialog MUST be transitioned to
   the "confirmed" state, and the route set for the dialog MUST be
   recomputed based on the 2xx response using the procedures of Section
   12.2.1.2.  Otherwise, a new dialog in the "confirmed" state MUST be
   constructed using the procedures of Section 12.1.2.

      Note that the only piece of state that is recomputed is the route
      set.  Other pieces of state such as the highest sequence numbers
      (remote and local) sent within the dialog are not recomputed.  The
      route set only is recomputed for backwards compatibility.  RFC
      2543 did not mandate mirroring of the Record-Route header field in
      a 1xx, only 2xx.  However, we cannot update the entire state of
      the dialog, since mid-dialog requests may have been sent within
      the early dialog, modifying the sequence numbers, for example.

   The UAC core MUST generate an ACK request for each 2xx received from
   the transaction layer.  The header fields of the ACK are constructed
   in the same way as for any request sent within a dialog (see Section
   12) with the exception of the CSeq and the header fields related to
   authentication.  The sequence number of the CSeq header field MUST be
   the same as the INVITE being acknowledged, but the CSeq method MUST
   be ACK.  The ACK MUST contain the same credentials as the INVITE.  If
   the 2xx contains an offer (based on the rules above), the ACK MUST
   carry an answer in its body.  If the offer in the 2xx response is not
   acceptable, the UAC core MUST generate a valid answer in the ACK and
   then send a BYE immediately.

   Once the ACK has been constructed, the procedures of [4] are used to
   determine the destination address, port and transport.  However, the
   request is passed to the transport layer directly for transmission,
   rather than a client transaction.  This is because the UAC core
   handles retransmissions of the ACK, not the transaction layer.  The
   ACK MUST be passed to the client transport every time a
   retransmission of the 2xx final response that triggered the ACK
   arrives.

   The UAC core considers the INVITE transaction completed 64*T1 seconds
   after the reception of the first 2xx response.  At this point all the
   early dialogs that have not transitioned to established dialogs are
   terminated.  Once the INVITE transaction is considered completed by
   the UAC core, no more new 2xx responses are expected to arrive.

   If, after acknowledging any 2xx response to an INVITE, the UAC does
   not want to continue with that dialog, then the UAC MUST terminate
   the dialog by sending a BYE request as described in Section 15.

13.3 UAS Processing

13.3.1 Processing of the INVITE

   The UAS core will receive INVITE requests from the transaction layer.
   It first performs the request processing procedures of Section 8.2,
   which are applied for both requests inside and outside of a dialog.

   Assuming these processing states are completed without generating a
   response, the UAS core performs the additional processing steps:

      1. If the request is an INVITE that contains an Expires header
         field, the UAS core sets a timer for the number of seconds
         indicated in the header field value.  When the timer fires, the
         invitation is considered to be expired.  If the invitation
         expires before the UAS has generated a final response, a 487
         (Request Terminated) response SHOULD be generated.

      2. If the request is a mid-dialog request, the method-independent
         processing described in Section 12.2.2 is first applied.  It
         might also modify the session; Section 14 provides details.

      3. If the request has a tag in the To header field but the dialog
         identifier does not match any of the existing dialogs, the UAS
         may have crashed and restarted, or may have received a request
         for a different (possibly failed) UAS.  Section 12.2.2 provides
         guidelines to achieve a robust behavior under such a situation.

   Processing from here forward assumes that the INVITE is outside of a
   dialog, and is thus for the purposes of establishing a new session.

   The INVITE may contain a session description, in which case the UAS
   is being presented with an offer for that session.  It is possible
   that the user is already a participant in that session, even though
   the INVITE is outside of a dialog.  This can happen when a user is
   invited to the same multicast conference by multiple other
   participants.  If desired, the UAS MAY use identifiers within the
   session description to detect this duplication.  For example, SDP

   contains a session id and version number in the origin (o) field.  If
   the user is already a member of the session, and the session
   parameters contained in the session description have not changed, the
   UAS MAY silently accept the INVITE (that is, send a 2xx response
   without prompting the user).

   If the INVITE does not contain a session description, the UAS is
   being asked to participate in a session, and the UAC has asked that
   the UAS provide the offer of the session.  It MUST provide the offer
   in its first non-failure reliable message back to the UAC.  In this
   specification, that is a 2xx response to the INVITE.

   The UAS can indicate progress, accept, redirect, or reject the
   invitation.  In all of these cases, it formulates a response using
   the procedures described in Section 8.2.6.

13.3.1.1 Progress

   If the UAS is not able to answer the invitation immediately, it can
   choose to indicate some kind of progress to the UAC (for example, an
   indication that a phone is ringing).  This is accomplished with a
   provisional response between 101 and 199.  These provisional
   responses establish early dialogs and therefore follow the procedures
   of Section 12.1.1 in addition to those of Section 8.2.6.  A UAS MAY
   send as many provisional responses as it likes.  Each of these MUST
   indicate the same dialog ID.  However, these will not be delivered
   reliably.

   If the UAS desires an extended period of time to answer the INVITE,
   it will need to ask for an "extension" in order to prevent proxies
   from canceling the transaction.  A proxy has the option of canceling
   a transaction when there is a gap of 3 minutes between responses in a
   transaction.  To prevent cancellation, the UAS MUST send a non-100
   provisional response at every minute, to handle the possibility of
   lost provisional responses.

      An INVITE transaction can go on for extended durations when the
      user is placed on hold, or when interworking with PSTN systems
      which allow communications to take place without answering the
      call.  The latter is common in Interactive Voice Response (IVR)
      systems.

13.3.1.2 The INVITE is Redirected

   If the UAS decides to redirect the call, a 3xx response is sent.  A
   300 (Multiple Choices), 301 (Moved Permanently) or 302 (Moved
   Temporarily) response SHOULD contain a Contact header field

   containing one or more URIs of new addresses to be tried.  The
   response is passed to the INVITE server transaction, which will deal
   with its retransmissions.

13.3.1.3 The INVITE is Rejected

   A common scenario occurs when the callee is currently not willing or
   able to take additional calls at this end system.  A 486 (Busy Here)
   SHOULD be returned in such a scenario.  If the UAS knows that no
   other end system will be able to accept this call, a 600 (Busy
   Everywhere) response SHOULD be sent instead.  However, it is unlikely
   that a UAS will be able to know this in general, and thus this
   response will not usually be used.  The response is passed to the
   INVITE server transaction, which will deal with its retransmissions.

   A UAS rejecting an offer contained in an INVITE SHOULD return a 488
   (Not Acceptable Here) response.  Such a response SHOULD include a
   Warning header field value explaining why the offer was rejected.

13.3.1.4 The INVITE is Accepted

   The UAS core generates a 2xx response.  This response establishes a
   dialog, and therefore follows the procedures of Section 12.1.1 in
   addition to those of Section 8.2.6.

   A 2xx response to an INVITE SHOULD contain the Allow header field and
   the Supported header field, and MAY contain the Accept header field.
   Including these header fields allows the UAC to determine the
   features and extensions supported by the UAS for the duration of the
   call, without probing.

   If the INVITE request contained an offer, and the UAS had not yet
   sent an answer, the 2xx MUST contain an answer.  If the INVITE did
   not contain an offer, the 2xx MUST contain an offer if the UAS had
   not yet sent an offer.

   Once the response has been constructed, it is passed to the INVITE
   server transaction.  Note, however, that the INVITE server
   transaction will be destroyed as soon as it receives this final
   response and passes it to the transport.  Therefore, it is necessary
   to periodically pass the response directly to the transport until the
   ACK arrives.  The 2xx response is passed to the transport with an
   interval that starts at T1 seconds and doubles for each
   retransmission until it reaches T2 seconds (T1 and T2 are defined in
   Section 17).  Response retransmissions cease when an ACK request for
   the response is received.  This is independent of whatever transport
   protocols are used to send the response.

      Since 2xx is retransmitted end-to-end, there may be hops between
      UAS and UAC that are UDP.  To ensure reliable delivery across
      these hops, the response is retransmitted periodically even if the
      transport at the UAS is reliable.

   If the server retransmits the 2xx response for 64*T1 seconds without
   receiving an ACK, the dialog is confirmed, but the session SHOULD be
   terminated.  This is accomplished with a BYE, as described in Section
   15.

14 Modifying an Existing Session

   A successful INVITE request (see Section 13) establishes both a
   dialog between two user agents and a session using the offer-answer
   model.  Section 12 explains how to modify an existing dialog using a
   target refresh request (for example, changing the remote target URI
   of the dialog).  This section describes how to modify the actual
   session.  This modification can involve changing addresses or ports,
   adding a media stream, deleting a media stream, and so on.  This is
   accomplished by sending a new INVITE request within the same dialog
   that established the session.  An INVITE request sent within an
   existing dialog is known as a re-INVITE.

      Note that a single re-INVITE can modify the dialog and the
      parameters of the session at the same time.

   Either the caller or callee can modify an existing session.

   The behavior of a UA on detection of media failure is a matter of
   local policy.  However, automated generation of re-INVITE or BYE is
   NOT RECOMMENDED to avoid flooding the network with traffic when there
   is congestion.  In any case, if these messages are sent
   automatically, they SHOULD be sent after some randomized interval.

      Note that the paragraph above refers to automatically generated
      BYEs and re-INVITEs.  If the user hangs up upon media failure, the
      UA would send a BYE request as usual.

14.1 UAC Behavior

   The same offer-answer model that applies to session descriptions in
   INVITEs (Section 13.2.1) applies to re-INVITEs.  As a result, a UAC
   that wants to add a media stream, for example, will create a new
   offer that contains this media stream, and send that in an INVITE
   request to its peer.  It is important to note that the full
   description of the session, not just the change, is sent.  This
   supports stateless session processing in various elements, and
   supports failover and recovery capabilities.  Of course, a UAC MAY

   send a re-INVITE with no session description, in which case the first
   reliable non-failure response to the re-INVITE will contain the offer
   (in this specification, that is a 2xx response).

   If the session description format has the capability for version
   numbers, the offerer SHOULD indicate that the version of the session
   description has changed.

   The To, From, Call-ID, CSeq, and Request-URI of a re-INVITE are set
   following the same rules as for regular requests within an existing
   dialog, described in Section 12.

   A UAC MAY choose not to add an Alert-Info header field or a body with
   Content-Disposition "alert" to re-INVITEs because UASs do not
   typically alert the user upon reception of a re-INVITE.

   Unlike an INVITE, which can fork, a re-INVITE will never fork, and
   therefore, only ever generate a single final response.  The reason a
   re-INVITE will never fork is that the Request-URI identifies the
   target as the UA instance it established the dialog with, rather than
   identifying an address-of-record for the user.

   Note that a UAC MUST NOT initiate a new INVITE transaction within a
   dialog while another INVITE transaction is in progress in either
   direction.

      1. If there is an ongoing INVITE client transaction, the TU MUST
         wait until the transaction reaches the completed or terminated
         state before initiating the new INVITE.

      2. If there is an ongoing INVITE server transaction, the TU MUST
         wait until the transaction reaches the confirmed or terminated
         state before initiating the new INVITE.

   However, a UA MAY initiate a regular transaction while an INVITE
   transaction is in progress.  A UA MAY also initiate an INVITE
   transaction while a regular transaction is in progress.

   If a UA receives a non-2xx final response to a re-INVITE, the session
   parameters MUST remain unchanged, as if no re-INVITE had been issued.
   Note that, as stated in Section 12.2.1.2, if the non-2xx final
   response is a 481 (Call/Transaction Does Not Exist), or a 408
   (Request Timeout), or no response at all is received for the re-
   INVITE (that is, a timeout is returned by the INVITE client
   transaction), the UAC will terminate the dialog.

   If a UAC receives a 491 response to a re-INVITE, it SHOULD start a
   timer with a value T chosen as follows:

      1. If the UAC is the owner of the Call-ID of the dialog ID
         (meaning it generated the value), T has a randomly chosen value
         between 2.1 and 4 seconds in units of 10 ms.

      2. If the UAC is not the owner of the Call-ID of the dialog ID, T
         has a randomly chosen value of between 0 and 2 seconds in units
         of 10 ms.

   When the timer fires, the UAC SHOULD attempt the re-INVITE once more,
   if it still desires for that session modification to take place.  For
   example, if the call was already hung up with a BYE, the re-INVITE
   would not take place.

   The rules for transmitting a re-INVITE and for generating an ACK for
   a 2xx response to re-INVITE are the same as for the initial INVITE
   (Section 13.2.1).

14.2 UAS Behavior

   Section 13.3.1 describes the procedure for distinguishing incoming
   re-INVITEs from incoming initial INVITEs and handling a re-INVITE for
   an existing dialog.

   A UAS that receives a second INVITE before it sends the final
   response to a first INVITE with a lower CSeq sequence number on the
   same dialog MUST return a 500 (Server Internal Error) response to the
   second INVITE and MUST include a Retry-After header field with a
   randomly chosen value of between 0 and 10 seconds.

   A UAS that receives an INVITE on a dialog while an INVITE it had sent
   on that dialog is in progress MUST return a 491 (Request Pending)
   response to the received INVITE.

   If a UA receives a re-INVITE for an existing dialog, it MUST check
   any version identifiers in the session description or, if there are
   no version identifiers, the content of the session description to see
   if it has changed.  If the session description has changed, the UAS
   MUST adjust the session parameters accordingly, possibly after asking
   the user for confirmation.

      Versioning of the session description can be used to accommodate
      the capabilities of new arrivals to a conference, add or delete
      media, or change from a unicast to a multicast conference.

   If the new session description is not acceptable, the UAS can reject
   it by returning a 488 (Not Acceptable Here) response for the re-
   INVITE.  This response SHOULD include a Warning header field.

   If a UAS generates a 2xx response and never receives an ACK, it
   SHOULD generate a BYE to terminate the dialog.

   A UAS MAY choose not to generate 180 (Ringing) responses for a re-
   INVITE because UACs do not typically render this information to the
   user.  For the same reason, UASs MAY choose not to use an Alert-Info
   header field or a body with Content-Disposition "alert" in responses
   to a re-INVITE.

   A UAS providing an offer in a 2xx (because the INVITE did not contain
   an offer) SHOULD construct the offer as if the UAS were making a
   brand new call, subject to the constraints of sending an offer that
   updates an existing session, as described in [13] in the case of SDP.
   Specifically, this means that it SHOULD include as many media formats
   and media types that the UA is willing to support.  The UAS MUST
   ensure that the session description overlaps with its previous
   session description in media formats, transports, or other parameters
   that require support from the peer.  This is to avoid the need for
   the peer to reject the session description.  If, however, it is
   unacceptable to the UAC, the UAC SHOULD generate an answer with a
   valid session description, and then send a BYE to terminate the
   session.

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.