16.11 Stateless Proxy

   When acting statelessly, a proxy is a simple message forwarder.  Much
   of the processing performed when acting statelessly is the same as
   when behaving statefully.  The differences are detailed here.

   A stateless proxy does not have any notion of a transaction, or of
   the response context used to describe stateful proxy behavior.
   Instead, the stateless proxy takes messages, both requests and
   responses, directly from the transport layer (See section 18).  As a
   result, stateless proxies do not retransmit messages on their own.
   They do, however, forward all retransmissions they receive (they do
   not have the ability to distinguish a retransmission from the
   original message).  Furthermore, when handling a request statelessly,
   an element MUST NOT generate its own 100 (Trying) or any other
   provisional response.

   A stateless proxy MUST validate a request as described in Section
   16.3

   A stateless proxy MUST follow the request processing steps described
   in Sections 16.4 through 16.5 with the following exception:

      o  A stateless proxy MUST choose one and only one target from the
         target set.  This choice MUST only rely on fields in the
         message and time-invariant properties of the server.  In
         particular, a retransmitted request MUST be forwarded to the
         same destination each time it is processed.  Furthermore,
         CANCEL and non-Routed ACK requests MUST generate the same
         choice as their associated INVITE.

   A stateless proxy MUST follow the request processing steps described
   in Section 16.6 with the following exceptions:

      o  The requirement for unique branch IDs across space and time
         applies to stateless proxies as well.  However, a stateless
         proxy cannot simply use a random number generator to compute
         the first component of the branch ID, as described in Section
         16.6 bullet 8.  This is because retransmissions of a request
         need to have the same value, and a stateless proxy cannot tell
         a retransmission from the original request.  Therefore, the
         component of the branch parameter that makes it unique MUST be
         the same each time a retransmitted request is forwarded.  Thus
         for a stateless proxy, the branch parameter MUST be computed as
         a combinatoric function of message parameters which are
         invariant on retransmission.

         The stateless proxy MAY use any technique it likes to guarantee
         uniqueness of its branch IDs across transactions.  However, the
         following procedure is RECOMMENDED.  The proxy examines the
         branch ID in the topmost Via header field of the received
         request.  If it begins with the magic cookie, the first
         component of the branch ID of the outgoing request is computed
         as a hash of the received branch ID.  Otherwise, the first
         component of the branch ID is computed as a hash of the topmost
         Via, the tag in the To header field, the tag in the From header
         field, the Call-ID header field, the CSeq number (but not
         method), and the Request-URI from the received request.  One of
         these fields will always vary across two different
         transactions.

      o  All other message transformations specified in Section 16.6
         MUST result in the same transformation of a retransmitted
         request.  In particular, if the proxy inserts a Record-Route
         value or pushes URIs into the Route header field, it MUST place
         the same values in retransmissions of the request.  As for the
         Via branch parameter, this implies that the transformations
         MUST be based on time-invariant configuration or
         retransmission-invariant properties of the request.

      o  A stateless proxy determines where to forward the request as
         described for stateful proxies in Section 16.6 Item 10.  The
         request is sent directly to the transport layer instead of
         through a client transaction.

         Since a stateless proxy must forward retransmitted requests to
         the same destination and add identical branch parameters to
         each of them, it can only use information from the message
         itself and time-invariant configuration data for those
         calculations.  If the configuration state is not time-invariant
         (for example, if a routing table is updated) any requests that
         could be affected by the change may not be forwarded
         statelessly during an interval equal to the transaction timeout
         window before or after the change.  The method of processing
         the affected requests in that interval is an implementation
         decision.  A common solution is to forward them transaction
         statefully.

   Stateless proxies MUST NOT perform special processing for CANCEL
   requests.  They are processed by the above rules as any other
   requests.  In particular, a stateless proxy applies the same Route
   header field processing to CANCEL requests that it applies to any
   other request.

   Response processing as described in Section 16.7 does not apply to a
   proxy behaving statelessly.  When a response arrives at a stateless
   proxy, the proxy MUST inspect the sent-by value in the first
   (topmost) Via header field value.  If that address matches the proxy,
   (it equals a value this proxy has inserted into previous requests)
   the proxy MUST remove that header field value from the response and
   forward the result to the location indicated in the next Via header
   field value.  The proxy MUST NOT add to, modify, or remove the
   message body.  Unless specified otherwise, the proxy MUST NOT remove
   any other header field values.  If the address does not match the
   proxy, the message MUST be silently discarded.

<< Prev - Next >>