Why can a forking SIP proxy not be stateless?
A forking SIP proxy cannot be stateless because it needs to perform a filtering operation, returning (in general) one response out of the many it receives. For example, a forking proxy with three branches, that receives a 200-class, 400-class, and 500-class response on each branch respectively, should return only the 200-class response upstream. If the proxy were stateless, it would end up returning all three of the responses upstream (since it won’t remember that it had received prior responses when it gets another one). The result of this is (1) response implosion at the client, and (2) inconsistent responses at the client. (In this example, depending on the order the responses would be received, the client would think that the call failed, just to get a success indication some time later.) Thus, a forking proxy must be stateful. Also note that a proxy that uses TCP must be stateful as well, whether it forks or not. This has to do with reliability issues. Why do you want state in a p
