Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3261

SIP: Session Initiation Protocol

Pages: 269
Proposed Standard
Errata
Obsoletes:  2543
Updated by:  326538534320491653935621562656305922595460266141666568787462746382178591876088988996
Part 7 of 13 – Pages 122 to 141
First   Prev   Next

Top   ToC   RFC3261 - Page 122   prevText

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
Top   ToC   RFC3261 - Page 123
      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.
Top   ToC   RFC3261 - Page 124
   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.
Top   ToC   RFC3261 - Page 125
   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
Top   ToC   RFC3261 - Page 126
   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
Top   ToC   RFC3261 - Page 127
   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.
Top   ToC   RFC3261 - Page 128
                               |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
Top   ToC   RFC3261 - Page 129
   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".
Top   ToC   RFC3261 - Page 130
   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.
Top   ToC   RFC3261 - Page 131
   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
Top   ToC   RFC3261 - Page 132
   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.
Top   ToC   RFC3261 - Page 133

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.
Top   ToC   RFC3261 - Page 134
   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
Top   ToC   RFC3261 - Page 135
   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.
Top   ToC   RFC3261 - Page 136
                               |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
Top   ToC   RFC3261 - Page 137
   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 "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.
Top   ToC   RFC3261 - Page 138

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
Top   ToC   RFC3261 - Page 139
   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.
Top   ToC   RFC3261 - Page 140
                                  |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
Top   ToC   RFC3261 - Page 141
   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.


(page 141 continued on part 8)

Next Section