Subject: [Sip] RE: Stateless Proxy and SIP responses

From: "CHADLI Youssef RD-CORE-ISS" <[email-masked]>
Date: Wed, 24 Jan 2007 09:57:02 +0100

> Hi all, 
> 
> RFC 3261 states that even a stateless SIP proxy must insert a Via
> entry containing its contact address in SIP request. Then, a stateless
> Proxy will receive all SIP responses to a proxied SIP request.
> However, in general, a stateless proxy would not need to receive the
> SIP responses to a being proxied request.
> I would like to konw what is the functional reason that leaded to
> mandate Proxy stateless to receive SIP responses for proxied requests.
> 
Thanks in advance

> Youssef  
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: David Viamonte <[email-masked]>
Date: Wed, 24 Jan 2007 15:03:59 +0100

A stateless
proxy must receive all responses related to a request. Otherwise, the
proxy is not able to know whether a proxied request succeeds, or a
transmisssion error occurs, or the receiving entity died, ...

Additionally, consider a (stateless) forking proxy: it needs to receive
an answer in one leg in order to cancel the request in the other leg,
for example.

In general, observe that a request is only 50% of a full transaction.
The minimum set of information any SIP node can proces is a full
transaction. Therefore, in order to correctly process a request, a
stateless proxy must receive and correctly process the answer(s) (e.g.:
100 Trying, 18x, 200 OK) as well. Afterwars, it may safely remain out
of the signalling path of subsequent SIP messages.

For INVITE requests, the final ACK message may not traverse the
stateless proxy. This is because the ACK is a "special" SIP message,
not exactly a real request as other SIP messages.

Cheers,

David

CHADLI Youssef RD-CORE-ISS escribió:

Hi all,

RFC 3261 states that even a stateless
SIP proxy must insert a Via entry containing its contact address in SIP
request. Then, a stateless Proxy will receive all SIP responses to a
proxied SIP request. However, in general, a stateless proxy would not
need to receive the SIP responses to a being proxied request.

I would like to konw what is the
functional reason that leaded to mandate Proxy stateless to receive SIP
responses for proxied requests.

Thanks in advance

Youssef

---

From: Diego B <[email-masked]>
Date: Wed, 24 Jan 2007 16:54:39 +0200

Hi
How a stateless proxy can fork a request and then cancel one of the legs?
A stateless Proxy has no Transaction memory, so it can not cancel a 
transaction after receiving a response.
I think a stateless proxy can not fork a request.

Regards
Diego B

David Viamonte wrote:
> A stateless proxy must receive all responses related to a request. 
> Otherwise, the proxy is not able to know whether a proxied request 
> succeeds, or a transmisssion error occurs, or the receiving entity 
> died, ...
>
> Additionally, consider a (stateless) forking proxy: it needs to 
> receive an answer in one leg in order to cancel the request in the 
> other leg, for example.
>
> stateless proxy must receive and correctly process the answer(s) 
> (e.g.: 100 Trying, 18x, 200 OK) as well. Afterwars, it may safely 
> remain out of the signalling path of subsequent SIP messages.
>
>> entry containing its contact address in SIP request. Then, a 
>> stateless Proxy will receive all SIP responses to a proxied SIP 
>> request. However, in general, a stateless proxy would not need to 
>> receive the SIP responses to a being proxied request.
>>
>> ------------------------------------------------------------------------
>>
> ------------------------------------------------------------------------
>

---

From: Robert Sparks <[email-masked]>
Date: Wed, 24 Jan 2007 09:33:52 -0600

Responses always follow the request path. Much of the defined  
behavior or SIP and its extensions count on this.
- Responses are sent back over the TCP connection they arrived on
- On UDP, responses are sent back to the apparent sending address  
(received) and if rport is present, the apparent sending port.

If you attempted a different design that allowed the response to  
"skip" nodes in the path, you would
have to rework many of those mechanisms, and you would have to  
introduce new solutions to deal with
situations where A can reach B, B can reach C, but C cannot send  
traffic directly to A (something like what we have with
Record-Route for dialogs).

RjS

---

From: [email-masked]
Date: Wed, 24 Jan 2007 10:45:34 -0500

From: Diego B <[email-masked]>

A stateless proxy can fork, and in some cases, can arrange to do
actions that seem to require keeping state, without actually doing so.

For forking, the simplest case is to do parallel forking -- when the
request comes in, the proxy sends multiple copies to multiple
destinations.  When the responses come in, the proxy forwards them
upstream.  At the worse, the UAC receives multiple responses to its
requests, and has to decide how to handle that, but it has to be able
to do that anyway.

The proxy can also do serial forking -- The proxy needs to save or
encode the incoming request-URI into the Via header, along with the
outgoing request-URI.  When a response comes in, the proxy examines
the Via header to determine the destination set it previously used for
the request, and which destination this response came from.  It can
then decide whether to send another request to the next destination,
or return the response upstream.

Etc.

Dale

---

From: [email-masked]
Date: Wed, 24 Jan 2007 10:51:11 -0500

From: "CHADLI Youssef RD-CORE-ISS" <[email-masked]>

   RFC 3261 states that even a stateless SIP proxy must insert a Via
   entry containing its contact address in SIP request. Then, a
   stateless Proxy will receive all SIP responses to a proxied SIP
   request.  However, in general, a stateless proxy would not need to
   receive the SIP responses to a being proxied request.  I would like
   to konw what is the functional reason that leaded to mandate Proxy
   stateless to receive SIP responses for proxied requests.

I expect that there are circumstances where a stateless proxy could
safely not add a Via header.  But one reason that you would want to
add a Via header is to ensure addressing:  If A sends the message to
B, and B sends it to C, it's difficult to guarantee that C can send
the response to the sent-by address that A uses in its Via header.

After all, the stateless proxy was probably put into the architecture
to solve some problem, and it probably wasn't to fork and route
requests intelligently.  The most likely reason is to gateway between
two subnetworks with different addressing environments.

Dale

---

From: Robert Sparks <[email-masked]>
Date: Wed, 24 Jan 2007 10:02:32 -0600

This is not correct. A stateless proxy as defined in 3261 is  
explicitly forbidden from forking.
See section 16.11 on page 116:

    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.

RjS

---

From: Diego B <[email-masked]>
Date: Wed, 24 Jan 2007 18:06:31 +0200

Hi;
See Inline:

Regards
Diego B

> requests, and has to decide how to handle that, but it has to be able
[DB] Ok; the stateless Proxy actually can fork, but it cannot perform 
the algorithm described in 3261 on selecting the best response, or
canceling the outgoing requests when receiving an OK response or 6xx 
response.

> or return the response upstream.
[DB] So, here you actually are saving the state on the Via header. In 
other words, you are
implementing a state full proxy but instead of using the SIP Transaction 
state machine
you are implementation your proprietary state machine.
I would not call this Proxy stateless.

---

From: David Viamonte <[email-masked]>
Date: Wed, 24 Jan 2007 17:08:44 +0100

OK, forget
about forking. It was only an example inside a more general
explanation, and I reckon I didn't check the spec before about this
particular topic.

Regardless, I think it is clear that -for more general and evident
reasons- a proxy must be able to receive the response in order to
correctly process the SIP request.

Cheers,

David

Robert Sparks escribió:

This is not correct. A stateless proxy as defined in 3261
is explicitly forbidden from forking.

RjS

From: Diego B
<[email-masked]>

How a stateless proxy can fork a request and then cancel one of the
legs?

to do that anyway.

Etc.

Dale