17 Transactions

   SIP is a transactional protocol: interactions between components take
   place in a series of independent message exchanges.  Specifically, a
   SIP transaction consists of a single request and any responses to
   that request, which include zero or more provisional responses and
   one or more final responses.  In the case of a transaction where the
   request was an INVITE (known as an INVITE transaction), the
   transaction also includes the ACK only if the final response was not
   a 2xx response.  If the response was a 2xx, the ACK is not considered
   part of the transaction.

      The reason for this separation is rooted in the importance of
      delivering all 200 (OK) responses to an INVITE to the UAC.  To
      deliver them all to the UAC, the UAS alone takes responsibility

      for retransmitting them (see Section 13.3.1.4), and the UAC alone
      takes responsibility for acknowledging them with ACK (see Section
      13.2.2.4).  Since this ACK is retransmitted only by the UAC, it is
      effectively considered its own transaction.

   Transactions have a client side and a server side.  The client side
   is known as a client transaction and the server side as a server
   transaction.  The client transaction sends the request, and the
   server transaction sends the response.  The client and server
   transactions are logical functions that are embedded in any number of
   elements.  Specifically, they exist within user agents and stateful
   proxy servers.  Consider the example in Section 4.  In this example,
   the UAC executes the client transaction, and its outbound proxy
   executes the server transaction.  The outbound proxy also executes a
   client transaction, which sends the request to a server transaction
   in the inbound proxy.  That proxy also executes a client transaction,
   which in turn sends the request to a server transaction in the UAS.
   This is shown in Figure 4.

   +---------+        +---------+        +---------+        +---------+
   |      +-+|Request |+-+   +-+|Request |+-+   +-+|Request |+-+      |
   |      |C||------->||S|   |C||------->||S|   |C||------->||S|      |
   |      |l||        ||e|   |l||        ||e|   |l||        ||e|      |
   |      |i||        ||r|   |i||        ||r|   |i||        ||r|      |
   |      |e||        ||v|   |e||        ||v|   |e||        ||v|      |
   |      |n||        ||e|   |n||        ||e|   |n||        ||e|      |
   |      |t||        ||r|   |t||        ||r|   |t||        ||r|      |
   |      | ||        || |   | ||        || |   | ||        || |      |
   |      |T||        ||T|   |T||        ||T|   |T||        ||T|      |
   |      |r||        ||r|   |r||        ||r|   |r||        ||r|      |
   |      |a||        ||a|   |a||        ||a|   |a||        ||a|      |
   |      |n||        ||n|   |n||        ||n|   |n||        ||n|      |
   |      |s||Response||s|   |s||Response||s|   |s||Response||s|      |
   |      +-+|<-------|+-+   +-+|<-------|+-+   +-+|<-------|+-+      |
   +---------+        +---------+        +---------+        +---------+
      UAC               Outbound           Inbound              UAS
                        Proxy               Proxy

                  Figure 4: Transaction relationships

   A stateless proxy does not contain a client or server transaction.
   The transaction exists between the UA or stateful proxy on one side,
   and the UA or stateful proxy on the other side.  As far as SIP
   transactions are concerned, stateless proxies are effectively
   transparent.  The purpose of the client transaction is to receive a
   request from the element in which the client is embedded (call this
   element the "Transaction User" or TU; it can be a UA or a stateful
   proxy), and reliably deliver the request to a server transaction.

   The client transaction is also responsible for receiving responses
   and delivering them to the TU, filtering out any response
   retransmissions or disallowed responses (such as a response to ACK).
   Additionally, in the case of an INVITE request, the client
   transaction is responsible for generating the ACK request for any
   final response accepting a 2xx response.

   Similarly, the purpose of the server transaction is to receive
   requests from the transport layer and deliver them to the TU.  The
   server transaction filters any request retransmissions from the
   network.  The server transaction accepts responses from the TU and
   delivers them to the transport layer for transmission over the
   network.  In the case of an INVITE transaction, it absorbs the ACK
   request for any final response excepting a 2xx response.

   The 2xx response and its ACK receive special treatment.  This
   response is retransmitted only by a UAS, and its ACK generated only
   by the UAC.  This end-to-end treatment is needed so that a caller
   knows the entire set of users that have accepted the call.  Because
   of this special handling, retransmissions of the 2xx response are
   handled by the UA core, not the transaction layer.  Similarly,
   generation of the ACK for the 2xx is handled by the UA core.  Each
   proxy along the path merely forwards each 2xx response to INVITE and
   its corresponding ACK.

17.1 Client Transaction

   The client transaction provides its functionality through the
   maintenance of a state machine.

   The TU communicates with the client transaction through a simple
   interface.  When the TU wishes to initiate a new transaction, it
   creates a client transaction and passes it the SIP request to send
   and an IP address, port, and transport to which to send it.  The
   client transaction begins execution of its state machine.  Valid
   responses are passed up to the TU from the client transaction.

   There are two types of client transaction state machines, depending
   on the method of the request passed by the TU.  One handles client
   transactions for INVITE requests.  This type of machine is referred
   to as an INVITE client transaction.  Another type handles client
   transactions for all requests except INVITE and ACK.  This is
   referred to as a non-INVITE client transaction.  There is no client
   transaction for ACK.  If the TU wishes to send an ACK, it passes one
   directly to the transport layer for transmission.

   The INVITE transaction is different from those of other methods
   because of its extended duration.  Normally, human input is required
   in order to respond to an INVITE.  The long delays expected for
   sending a response argue for a three-way handshake.  On the other
   hand, requests of other methods are expected to complete rapidly.
   Because of the non-INVITE transaction's reliance on a two-way
   handshake, TUs SHOULD respond immediately to non-INVITE requests.

17.1.1 INVITE Client Transaction

17.1.1.1 Overview of INVITE Transaction

   The INVITE transaction consists of a three-way handshake.  The client
   transaction sends an INVITE, the server transaction sends responses,
   and the client transaction sends an ACK.  For unreliable transports
   (such as UDP), the client transaction retransmits requests at an
   interval that starts at T1 seconds and doubles after every
   retransmission.  T1 is an estimate of the round-trip time (RTT), and
   it defaults to 500 ms.  Nearly all of the transaction timers
   described here scale with T1, and changing T1 adjusts their values.
   The request is not retransmitted over reliable transports.  After
   receiving a 1xx response, any retransmissions cease altogether, and
   the client waits for further responses.  The server transaction can
   send additional 1xx responses, which are not transmitted reliably by
   the server transaction.  Eventually, the server transaction decides
   to send a final response.  For unreliable transports, that response
   is retransmitted periodically, and for reliable transports, it is
   sent once.  For each final response that is received at the client
   transaction, the client transaction sends an ACK, the purpose of
   which is to quench retransmissions of the response.

17.1.1.2 Formal Description

   The state machine for the INVITE client transaction is shown in
   Figure 5.  The initial state, "calling", MUST be entered when the TU
   initiates a new client transaction with an INVITE request.  The
   client transaction MUST pass the request to the transport layer for
   transmission (see Section 18).  If an unreliable transport is being
   used, the client transaction MUST start timer A with a value of T1.
   If a reliable transport is being used, the client transaction SHOULD
   NOT start timer A (Timer A controls request retransmissions).  For
   any transport, the client transaction MUST start timer B with a value
   of 64*T1 seconds (Timer B controls transaction timeouts).

   When timer A fires, the client transaction MUST retransmit the
   request by passing it to the transport layer, and MUST reset the
   timer with a value of 2*T1.  The formal definition of retransmit

   within the context of the transaction layer is to take the message
   previously sent to the transport layer and pass it to the transport
   layer once more.

   When timer A fires 2*T1 seconds later, the request MUST be
   retransmitted again (assuming the client transaction is still in this
   state).  This process MUST continue so that the request is
   retransmitted with intervals that double after each transmission.
   These retransmissions SHOULD only be done while the client
   transaction is in the "calling" state.

   The default value for T1 is 500 ms.  T1 is an estimate of the RTT
   between the client and server transactions.  Elements MAY (though it
   is NOT RECOMMENDED) use smaller values of T1 within closed, private
   networks that do not permit general Internet connection.  T1 MAY be
   chosen larger, and this is RECOMMENDED if it is known in advance
   (such as on high latency access links) that the RTT is larger.
   Whatever the value of T1, the exponential backoffs on retransmissions
   described in this section MUST be used.

   If the client transaction is still in the "Calling" state when timer
   B fires, the client transaction SHOULD inform the TU that a timeout
   has occurred.  The client transaction MUST NOT generate an ACK.  The
   value of 64*T1 is equal to the amount of time required to send seven
   requests in the case of an unreliable transport.

   If the client transaction receives a provisional response while in
   the "Calling" state, it transitions to the "Proceeding" state. In the
   "Proceeding" state, the client transaction SHOULD NOT retransmit the
   request any longer. Furthermore, the provisional response MUST be
   passed to the TU.  Any further provisional responses MUST be passed
   up to the TU while in the "Proceeding" state.

   When in either the "Calling" or "Proceeding" states, reception of a
   response with status code from 300-699 MUST cause the client
   transaction to transition to "Completed".  The client transaction
   MUST pass the received response up to the TU, and the client
   transaction MUST generate an ACK request, even if the transport is
   reliable (guidelines for constructing the ACK from the response are
   given in Section 17.1.1.3) and then pass the ACK to the transport
   layer for transmission.  The ACK MUST be sent to the same address,
   port, and transport to which the original request was sent.  The
   client transaction SHOULD start timer D when it enters the
   "Completed" state, with a value of at least 32 seconds for unreliable
   transports, and a value of zero seconds for reliable transports.
   Timer D reflects the amount of time that the server transaction can
   remain in the "Completed" state when unreliable transports are used.
   This is equal to Timer H in the INVITE server transaction, whose

   default is 64*T1.  However, the client transaction does not know the
   value of T1 in use by the server transaction, so an absolute minimum
   of 32s is used instead of basing Timer D on T1.

   Any retransmissions of the final response that are received while in
   the "Completed" state MUST cause the ACK to be re-passed to the
   transport layer for retransmission, but the newly received response
   MUST NOT be passed up to the TU.  A retransmission of the response is
   defined as any response which would match the same client transaction
   based on the rules of Section 17.1.3.

                               |INVITE from TU
             Timer A fires     |INVITE sent
             Reset A,          V                      Timer B fires
             INVITE sent +-----------+                or Transport Err.
               +---------|           |---------------+inform TU
               |         |  Calling  |               |
               +-------->|           |-------------->|
                         +-----------+ 2xx           |
                            |  |       2xx to TU     |
                            |  |1xx                  |
    300-699 +---------------+  |1xx to TU            |
   ACK sent |                  |                     |
resp. to TU |  1xx             V                     |
            |  1xx to TU  -----------+               |
            |  +---------|           |               |
            |  |         |Proceeding |-------------->|
            |  +-------->|           | 2xx           |
            |            +-----------+ 2xx to TU     |
            |       300-699    |                     |
            |       ACK sent,  |                     |
            |       resp. to TU|                     |
            |                  |                     |      NOTE:
            |  300-699         V                     |
            |  ACK sent  +-----------+Transport Err. |  transitions
            |  +---------|           |Inform TU      |  labeled with
            |  |         | Completed |-------------->|  the event
            |  +-------->|           |               |  over the action
            |            +-----------+               |  to take
            |              ^   |                     |
            |              |   | Timer D fires       |
            +--------------+   | -                   |
                               |                     |
                               V                     |
                         +-----------+               |
                         |           |               |
                         | Terminated|<--------------+
                         |           |
                         +-----------+

                 Figure 5: INVITE client transaction

   If timer D fires while the client transaction is in the "Completed"
   state, the client transaction MUST move to the terminated state.

   When in either the "Calling" or "Proceeding" states, reception of a
   2xx response MUST cause the client transaction to enter the
   "Terminated" state, and the response MUST be passed up to the TU.
   The handling of this response depends on whether the TU is a proxy

   core or a UAC core.  A UAC core will handle generation of the ACK for
   this response, while a proxy core will always forward the 200 (OK)
   upstream.  The differing treatment of 200 (OK) between proxy and UAC
   is the reason that handling of it does not take place in the
   transaction layer.

   The client transaction MUST be destroyed the instant it enters the
   "Terminated" state.  This is actually necessary to guarantee correct
   operation.  The reason is that 2xx responses to an INVITE are treated
   differently; each one is forwarded by proxies, and the ACK handling
   in a UAC is different.  Thus, each 2xx needs to be passed to a proxy
   core (so that it can be forwarded) and to a UAC core (so it can be
   acknowledged).  No transaction layer processing takes place.
   Whenever a response is received by the transport, if the transport
   layer finds no matching client transaction (using the rules of
   Section 17.1.3), the response is passed directly to the core.  Since
   the matching client transaction is destroyed by the first 2xx,
   subsequent 2xx will find no match and therefore be passed to the
   core.

17.1.1.3 Construction of the ACK Request

   This section specifies the construction of ACK requests sent within
   the client transaction.  A UAC core that generates an ACK for 2xx
   MUST instead follow the rules described in Section 13.

   The ACK request constructed by the client transaction MUST contain
   values for the Call-ID, From, and Request-URI that are equal to the
   values of those header fields in the request passed to the transport
   by the client transaction (call this the "original request").  The To
   header field in the ACK MUST equal the To header field in the
   response being acknowledged, and therefore will usually differ from
   the To header field in the original request by the addition of the
   tag parameter.  The ACK MUST contain a single Via header field, and
   this MUST be equal to the top Via header field of the original
   request.  The CSeq header field in the ACK MUST contain the same
   value for the sequence number as was present in the original request,
   but the method parameter MUST be equal to "ACK".

   If the INVITE request whose response is being acknowledged had Route
   header fields, those header fields MUST appear in the ACK.  This is
   to ensure that the ACK can be routed properly through any downstream
   stateless proxies.

   Although any request MAY contain a body, a body in an ACK is special
   since the request cannot be rejected if the body is not understood.
   Therefore, placement of bodies in ACK for non-2xx is NOT RECOMMENDED,
   but if done, the body types are restricted to any that appeared in
   the INVITE, assuming that the response to the INVITE was not 415.  If
   it was, the body in the ACK MAY be any type listed in the Accept
   header field in the 415.

   For example, consider the following request:

   INVITE sip:bob@biloxi.com SIP/2.0
   Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff
   To: Bob <sip:bob@biloxi.com>
   From: Alice <sip:alice@atlanta.com>;tag=88sja8x
   Max-Forwards: 70
   Call-ID: 987asjd97y7atg
   CSeq: 986759 INVITE

   The ACK request for a non-2xx final response to this request would
   look like this:

   ACK sip:bob@biloxi.com SIP/2.0
   Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff
   To: Bob <sip:bob@biloxi.com>;tag=99sa0xk
   From: Alice <sip:alice@atlanta.com>;tag=88sja8x
   Max-Forwards: 70
   Call-ID: 987asjd97y7atg
   CSeq: 986759 ACK

17.1.2 Non-INVITE Client Transaction

17.1.2.1 Overview of the non-INVITE Transaction

   Non-INVITE transactions do not make use of ACK.  They are simple
   request-response interactions.  For unreliable transports, requests
   are retransmitted at an interval which starts at T1 and doubles until
   it hits T2.  If a provisional response is received, retransmissions
   continue for unreliable transports, but at an interval of T2.  The
   server transaction retransmits the last response it sent, which can
   be a provisional or final response, only when a retransmission of the
   request is received.  This is why request retransmissions need to
   continue even after a provisional response; they are to ensure
   reliable delivery of the final response.

   Unlike an INVITE transaction, a non-INVITE transaction has no special
   handling for the 2xx response.  The result is that only a single 2xx
   response to a non-INVITE is ever delivered to a UAC.

17.1.2.2 Formal Description

   The state machine for the non-INVITE client transaction is shown in
   Figure 6.  It is very similar to the state machine for INVITE.

   The "Trying" state is entered when the TU initiates a new client
   transaction with a request.  When entering this state, the client
   transaction SHOULD set timer F to fire in 64*T1 seconds.  The request
   MUST be passed to the transport layer for transmission.  If an
   unreliable transport is in use, the client transaction MUST set timer
   E to fire in T1 seconds.  If timer E fires while still in this state,
   the timer is reset, but this time with a value of MIN(2*T1, T2).
   When the timer fires again, it is reset to a MIN(4*T1, T2).  This
   process continues so that retransmissions occur with an exponentially
   increasing interval that caps at T2.  The default value of T2 is 4s,
   and it represents the amount of time a non-INVITE server transaction
   will take to respond to a request, if it does not respond
   immediately.  For the default values of T1 and T2, this results in
   intervals of 500 ms, 1 s, 2 s, 4 s, 4 s, 4 s, etc.

   If Timer F fires while the client transaction is still in the
   "Trying" state, the client transaction SHOULD inform the TU about the
   timeout, and then it SHOULD enter the "Terminated" state.  If a
   provisional response is received while in the "Trying" state, the
   response MUST be passed to the TU, and then the client transaction
   SHOULD move to the "Proceeding" state.  If a final response (status
   codes 200-699) is received while in the "Trying" state, the response
   MUST be passed to the TU, and the client transaction MUST transition
   to the "Completed" state.

   If Timer E fires while in the "Proceeding" state, the request MUST be
   passed to the transport layer for retransmission, and Timer E MUST be
   reset with a value of T2 seconds.  If timer F fires while in the
   "Proceeding" state, the TU MUST be informed of a timeout, and the
   client transaction MUST transition to the terminated state.  If a
   final response (status codes 200-699) is received while in the
   "Proceeding" state, the response MUST be passed to the TU, and the
   client transaction MUST transition to the "Completed" state.

   Once the client transaction enters the "Completed" state, it MUST set
   Timer K to fire in T4 seconds for unreliable transports, and zero
   seconds for reliable transports.  The "Completed" state exists to
   buffer any additional response retransmissions that may be received
   (which is why the client transaction remains there only for

   unreliable transports).  T4 represents the amount of time the network
   will take to clear messages between client and server transactions.
   The default value of T4 is 5s.  A response is a retransmission when
   it matches the same transaction, using the rules specified in Section
   17.1.3.  If Timer K fires while in this state, the client transaction
   MUST transition to the "Terminated" state.

   Once the transaction is in the terminated state, it MUST be destroyed
   immediately.

17.1.3 Matching Responses to Client Transactions

   When the transport layer in the client receives a response, it has to
   determine which client transaction will handle the response, so that
   the processing of Sections 17.1.1 and 17.1.2 can take place.  The
   branch parameter in the top Via header field is used for this
   purpose.  A response matches a client transaction under two
   conditions:

      1.  If the response has the same value of the branch parameter in
          the top Via header field as the branch parameter in the top
          Via header field of the request that created the transaction.

      2.  If the method parameter in the CSeq header field matches the
          method of the request that created the transaction.  The
          method is needed since a CANCEL request constitutes a
          different transaction, but shares the same value of the branch
          parameter.

   If a request is sent via multicast, it is possible that it will
   generate multiple responses from different servers.  These responses
   will all have the same branch parameter in the topmost Via, but vary
   in the To tag.  The first response received, based on the rules
   above, will be used, and others will be viewed as retransmissions.
   That is not an error; multicast SIP provides only a rudimentary
   "single-hop-discovery-like" service that is limited to processing a
   single response.  See Section 18.1.1 for details.

17.1.4 Handling Transport Errors

                                   |Request from TU
                                   |send request
               Timer E             V
               send request  +-----------+
                   +---------|           |-------------------+
                   |         |  Trying   |  Timer F          |
                   +-------->|           |  or Transport Err.|
                             +-----------+  inform TU        |
                200-699         |  |                         |
                resp. to TU     |  |1xx                      |
                +---------------+  |resp. to TU              |
                |                  |                         |
                |   Timer E        V       Timer F           |
                |   send req +-----------+ or Transport Err. |
                |  +---------|           | inform TU         |
                |  |         |Proceeding |------------------>|
                |  +-------->|           |-----+             |
                |            +-----------+     |1xx          |
                |              |      ^        |resp to TU   |
                | 200-699      |      +--------+             |
                | resp. to TU  |                             |
                |              |                             |
                |              V                             |
                |            +-----------+                   |
                |            |           |                   |
                |            | Completed |                   |
                |            |           |                   |
                |            +-----------+                   |
                |              ^   |                         |
                |              |   | Timer K                 |
                +--------------+   | -                       |
                                   |                         |
                                   V                         |
             NOTE:           +-----------+                   |
                             |           |                   |
         transitions         | Terminated|<------------------+
         labeled with        |           |
         the event           +-----------+
         over the action
         to take

                 Figure 6: non-INVITE client transaction

   When the client transaction sends a request to the transport layer to
   be sent, the following procedures are followed if the transport layer
   indicates a failure.

   The client transaction SHOULD inform the TU that a transport failure
   has occurred, and the client transaction SHOULD transition directly
   to the "Terminated" state.  The TU will handle the failover
   mechanisms described in [4].

17.2 Server Transaction

   The server transaction is responsible for the delivery of requests to
   the TU and the reliable transmission of responses.  It accomplishes
   this through a state machine.  Server transactions are created by the
   core when a request is received, and transaction handling is desired
   for that request (this is not always the case).

   As with the client transactions, the state machine depends on whether
   the received request is an INVITE request.

17.2.1 INVITE Server Transaction

   The state diagram for the INVITE server transaction is shown in
   Figure 7.

   When a server transaction is constructed for a request, it enters the
   "Proceeding" state.  The server transaction MUST generate a 100
   (Trying) response unless it knows that the TU will generate a
   provisional or final response within 200 ms, in which case it MAY
   generate a 100 (Trying) response.  This provisional response is
   needed to quench request retransmissions rapidly in order to avoid
   network congestion.  The 100 (Trying) response is constructed
   according to the procedures in Section 8.2.6, except that the
   insertion of tags in the To header field of the response (when none
   was present in the request) is downgraded from MAY to SHOULD NOT.
   The request MUST be passed to the TU.

   The TU passes any number of provisional responses to the server
   transaction.  So long as the server transaction is in the
   "Proceeding" state, each of these MUST be passed to the transport
   layer for transmission.  They are not sent reliably by the
   transaction layer (they are not retransmitted by it) and do not cause
   a change in the state of the server transaction.  If a request
   retransmission is received while in the "Proceeding" state, the most
   recent provisional response that was received from the TU MUST be
   passed to the transport layer for retransmission.  A request is a
   retransmission if it matches the same server transaction based on the
   rules of Section 17.2.3.

   If, while in the "Proceeding" state, the TU passes a 2xx response to
   the server transaction, the server transaction MUST pass this
   response to the transport layer for transmission.  It is not

   retransmitted by the server transaction; retransmissions of 2xx
   responses are handled by the TU.  The server transaction MUST then
   transition to the "Terminated" state.

   While in the "Proceeding" state, if the TU passes a response with
   status code from 300 to 699 to the server transaction, the response
   MUST be passed to the transport layer for transmission, and the state
   machine MUST enter the "Completed" state.  For unreliable transports,
   timer G is set to fire in T1 seconds, and is not set to fire for
   reliable transports.

      This is a change from RFC 2543, where responses were always
      retransmitted, even over reliable transports.

   When the "Completed" state is entered, timer H MUST be set to fire in
   64*T1 seconds for all transports.  Timer H determines when the server
   transaction abandons retransmitting the response.  Its value is
   chosen to equal Timer B, the amount of time a client transaction will
   continue to retry sending a request.  If timer G fires, the response
   is passed to the transport layer once more for retransmission, and
   timer G is set to fire in MIN(2*T1, T2) seconds.  From then on, when
   timer G fires, the response is passed to the transport again for
   transmission, and timer G is reset with a value that doubles, unless
   that value exceeds T2, in which case it is reset with the value of
   T2.  This is identical to the retransmit behavior for requests in the
   "Trying" state of the non-INVITE client transaction.  Furthermore,
   while in the "Completed" state, if a request retransmission is
   received, the server SHOULD pass the response to the transport for
   retransmission.

   If an ACK is received while the server transaction is in the
   "Completed" state, the server transaction MUST transition to the
   "Confirmed" state.  As Timer G is ignored in this state, any
   retransmissions of the response will cease.

   If timer H fires while in the "Completed" state, it implies that the
   ACK was never received.  In this case, the server transaction MUST
   transition to the "Terminated" state, and MUST indicate to the TU
   that a transaction failure has occurred.

                               |INVITE
                               |pass INV to TU
            INVITE             V send 100 if TU won't in 200ms
            send response+-----------+
                +--------|           |--------+101-199 from TU
                |        | Proceeding|        |send response
                +------->|           |<-------+
                         |           |          Transport Err.
                         |           |          Inform TU
                         |           |--------------->+
                         +-----------+                |
            300-699 from TU |     |2xx from TU        |
            send response   |     |send response      |
                            |     +------------------>+
                            |                         |
            INVITE          V          Timer G fires  |
            send response+-----------+ send response  |
                +--------|           |--------+       |
                |        | Completed |        |       |
                +------->|           |<-------+       |
                         +-----------+                |
                            |     |                   |
                        ACK |     |                   |
                        -   |     +------------------>+
                            |        Timer H fires    |
                            V        or Transport Err.|
                         +-----------+  Inform TU     |
                         |           |                |
                         | Confirmed |                |
                         |           |                |
                         +-----------+                |
                               |                      |
                               |Timer I fires         |
                               |-                     |
                               |                      |
                               V                      |
                         +-----------+                |
                         |           |                |
                         | Terminated|<---------------+
                         |           |
                         +-----------+

              Figure 7: INVITE server transaction

   The purpose of the "Confirmed" state is to absorb any additional ACK
   messages that arrive, triggered from retransmissions of the final
   response.  When this state is entered, timer I is set to fire in T4
   seconds for unreliable transports, and zero seconds for reliable
   transports.  Once timer I fires, the server MUST transition to the
   "Terminated" state.

   Once the transaction is in the "Terminated" state, it MUST be
   destroyed immediately.  As with client transactions, this is needed
   to ensure reliability of the 2xx responses to INVITE.

17.2.2 Non-INVITE Server Transaction

   The state machine for the non-INVITE server transaction is shown in
   Figure 8.

   The state machine is initialized in the "Trying" state and is passed
   a request other than INVITE or ACK when initialized.  This request is
   passed up to the TU.  Once in the "Trying" state, any further request
   retransmissions are discarded.  A request is a retransmission if it
   matches the same server transaction, using the rules specified in
   Section 17.2.3.

   While in the "Trying" state, if the TU passes a provisional response
   to the server transaction, the server transaction MUST enter the
   "Proceeding" state.  The response MUST be passed to the transport
   layer for transmission.  Any further provisional responses that are
   received from the TU while in the "Proceeding" state MUST be passed
   to the transport layer for transmission.  If a retransmission of the
   request is received while in the "Proceeding" state, the most
   recently sent provisional response MUST be passed to the transport
   layer for retransmission.  If the TU passes a final response (status
   codes 200-699) to the server while in the "Trying" or "Proceeding" state, the
   transaction MUST enter the "Completed" state, and the response MUST
   be passed to the transport layer for transmission.

   When the server transaction enters the "Completed" state, it MUST set
   Timer J to fire in 64*T1 seconds for unreliable transports, and zero
   seconds for reliable transports.  While in the "Completed" state, the
   server transaction MUST pass the final response to the transport
   layer for retransmission whenever a retransmission of the request is
   received.  Any other final responses passed by the TU to the server
   transaction MUST be discarded while in the "Completed" state.  The
   server transaction remains in this state until Timer J fires, at
   which point it MUST transition to the "Terminated" state.

   The server transaction MUST be destroyed the instant it enters the
   "Terminated" state.

17.2.3 Matching Requests to Server Transactions

   When a request is received from the network by the server, it has to
   be matched to an existing transaction.  This is accomplished in the
   following manner.

   The branch parameter in the topmost Via header field of the request
   is examined.  If it is present and begins with the magic cookie
   "z9hG4bK", the request was generated by a client transaction
   compliant to this specification.  Therefore, the branch parameter
   will be unique across all transactions sent by that client.  The
   request matches a transaction if:

      1. the branch parameter in the request is equal to the one in the
         top Via header field of the request that created the
         transaction, and

      2. the sent-by value in the top Via of the request is equal to the
         one in the request that created the transaction, and

      3. the method of the request matches the one that created the
         transaction, except for ACK, where the method of the request
         that created the transaction is INVITE.

   This matching rule applies to both INVITE and non-INVITE transactions
   alike.

      The sent-by value is used as part of the matching process because
      there could be accidental or malicious duplication of branch
      parameters from different clients.

   If the branch parameter in the top Via header field is not present,
   or does not contain the magic cookie, the following procedures are
   used.  These exist to handle backwards compatibility with RFC 2543
   compliant implementations.

   The INVITE request matches a transaction if the Request-URI, To tag,
   From tag, Call-ID, CSeq, and top Via header field match those of the
   INVITE request which created the transaction.  In this case, the
   INVITE is a retransmission of the original one that created the
   transaction.  The ACK request matches a transaction if the Request-
   URI, From tag, Call-ID, CSeq number (not the method), and top Via
   header field match those of the INVITE request which created the
   transaction, and the To tag of the ACK matches the To tag of the
   response sent by the server transaction.  Matching is done based on
   the matching rules defined for each of those header fields.
   Inclusion of the tag in the To header field in the ACK matching
   process helps disambiguate ACK for 2xx from ACK for other responses

   at a proxy, which may have forwarded both responses (This can occur
   in unusual conditions.  Specifically, when a proxy forked a request,
   and then crashes, the responses may be delivered to another proxy,
   which might end up forwarding multiple responses upstream).  An ACK
   request that matches an INVITE transaction matched by a previous ACK
   is considered a retransmission of that previous ACK.

                                  |Request received
                                  |pass to TU
                                  V
                            +-----------+
                            |           |
                            | Trying    |-------------+
                            |           |             |
                            +-----------+             |200-699 from TU
                                  |                   |send response
                                  |1xx from TU        |
                                  |send response      |
                                  |                   |
               Request            V      1xx from TU  |
               send response+-----------+send response|
                   +--------|           |--------+    |
                   |        | Proceeding|        |    |
                   +------->|           |<-------+    |
            +<--------------|           |             |
            |Trnsprt Err    +-----------+             |
            |Inform TU            |                   |
            |                     |                   |
            |                     |200-699 from TU    |
            |                     |send response      |
            |  Request            V                   |
            |  send response+-----------+             |
            |      +--------|           |             |
            |      |        | Completed |<------------+
            |      +------->|           |
            +<--------------|           |
            |Trnsprt Err    +-----------+
            |Inform TU            |
            |                     |Timer J fires
            |                     |-
            |                     |
            |                     V
            |               +-----------+
            |               |           |
            +-------------->| Terminated|
                            |           |
                            +-----------+

                Figure 8: non-INVITE server transaction

   For all other request methods, a request is matched to a transaction
   if the Request-URI, To tag, From tag, Call-ID, CSeq (including the
   method), and top Via header field match those of the request that
   created the transaction.  Matching is done based on the matching

   rules defined for each of those header fields.  When a non-INVITE
   request matches an existing transaction, it is a retransmission of
   the request that created that transaction.

   Because the matching rules include the Request-URI, the server cannot
   match a response to a transaction.  When the TU passes a response to
   the server transaction, it must pass it to the specific server
   transaction for which the response is targeted.

17.2.4 Handling Transport Errors

   When the server transaction sends a response to the transport layer
   to be sent, the following procedures are followed if the transport
   layer indicates a failure.

   First, the procedures in [4] are followed, which attempt to deliver
   the response to a backup.  If those should all fail, based on the
   definition of failure in [4], the server transaction SHOULD inform
   the TU that a failure has occurred, and SHOULD transition to the
   terminated state.