Proxy Behavior

	SIP proxies are elements that route SIP requests to user agent
   servers and SIP responses to user agent clients.  A request may
   traverse several proxies on its way to a UAS.  Each will make routing
   decisions, modifying the request before forwarding it to the next
   element.  Responses will route through the same set of proxies
   traversed by the request in the reverse order.

16.1 Overview

 Being a proxy is a logical role for a SIP element.  When a request
   arrives, an element that can play the role of a proxy first decides
   if it needs to respond to the request on its own.  For instance, the
   request may be malformed or the element may need credentials from the
   client before acting as a proxy.  The element MAY respond with any
   appropriate error code.  When responding directly to a request, the
   element is playing the role of a UAS and MUST behave as described in
   Section 8.2.

   A proxy can operate in either a stateful or stateless mode for each
   new request.  When stateless, a proxy acts as a simple forwarding
   element.  It forwards each request downstream to a single element
   determined by making a targeting and routing decision based on the
   request.  It simply forwards every response it receives upstream.  A
   stateless proxy discards information about a message once the message
   has been forwarded.  A stateful proxy remembers information
   (specifically, transaction state) about each incoming request and any
   requests it sends as a result of processing the incoming request.  It
   uses this information to affect the processing of future messages
   associated with that request.  A stateful proxy MAY choose to "fork"
   a request, routing it to multiple destinations.  Any request that is
   forwarded to more than one location MUST be handled statefully.

   In some circumstances, a proxy MAY forward requests using stateful
   transports (such as TCP) without being transaction-stateful.  For
   instance, a proxy MAY forward a request from one TCP connection to
   another transaction statelessly as long as it places enough
   information in the message to be able to forward the response down
   the same connection the request arrived on.  Requests forwarded
   between different types of transports where the proxy's TU must take
   an active role in ensuring reliable delivery on one of the transports
   MUST be forwarded transaction statefully.

   A stateful proxy MAY transition to stateless operation at any time
   during the processing of a request, so long as it did not do anything
   that would otherwise prevent it from being stateless initially
   (forking, for example, or generation of a 100 response).  When
   performing such a transition, all state is simply discarded.  The
   proxy SHOULD NOT initiate a CANCEL request.

   Much of the processing involved when acting statelessly or statefully
   for a request is identical.  The next several subsections are written
   from the point of view of a stateful proxy.  The last section calls
   out those places where a stateless proxy behaves differently.

Prev - Next >>