In the case of a stateless proxy, I think it is "ok" for the proxy to
close the connection after sending the request. But it is also ok for it
to leave the connection open. Until the connection is closed it must be
prepared to receive responses over it. Once it is closed it must be
prepared to receive responses in accord with the Via header it used.
The next hop doesn't know if the prior hop was stateless or not, so it
can't change its behavior to account for that. If the connection is
still up with it is ready to send a response, then it should send the
response over the connection. If the connection is down, then it will go
into the prescribed fallback.
Paul
Attila Sipos wrote:
>
> And I think my previous e-mail is backed up by this
> from RFC3263:
>
> A server, according to RFC 3261 [1], will send a response on the
> connection it arrived on (in the case of reliable transport
> protocols), and for unreliable transport protocols, to the source
> address of the request, and the port in the Via header field. The
> procedures here are invoked when a server attempts to send to that
> location and that response fails (the specific conditions are
> detailed in RFC 3261). "Fails" is defined as any closure of the
> transport connection the request came in on before the response can
> be sent, or communication of a fatal error from the transport layer.
>
> In these cases, the server examines the value of the sent-by
> construction in the topmost Via header. etc.
>
> So, in the case of a stateless proxy, the TCP connection would close
> once the SIP request had been successfully sent. So, the connection for
> the response would "Fail" and the response would be sent to the sent-by
> (generally).
>
> Regards,
> Attila
>
>
>
> -----Original Message-----
> From: Attila Sipos
> Sent: 07 February 2007 10:55
> To: 'Victor Tsoukanov'; [email protected]
> Subject: RE: [Sip-implementors] Stateless Proxy and TCP transport
>
>
>
> Yeh, I was thinking the same thing.
>
> I think the answer is a bit later in the same paragraph...
> Under error conditions, the
> server may attempt to open a new connection to send the response. To
> handle this case, the transport layer MUST also be prepared to
> receive an incoming connection on the source IP address from which
> the request was sent and port number in the "sent-by" field.
>
> Like you I can't imagine that a stateless proxy could keep
> up a connection to wait for a response.
>
> I think that, for stateless proxies, the response must get
> sent to the address and port in the sent-by field.
>
> This won't be a problem unless you're trying to do dynamic
> NAT traversal.
>
> Regards,
>
> Attila
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Victor
> Tsoukanov
> Sent: 07 February 2007 08:05
> To: [email protected]
> Subject: [Sip-implementors] Stateless Proxy and TCP transport
>
>
> When stateless proxy forwards request with TCP it should open new client
> connection and send message. In accordance with RFC 3261 "....For reliable
> transports, the response is normally sent on the connection on which the
> request was received. Therefore, the client transport MUST be prepared to
> receive the response on the same connection used to send the request." As I
> understand it means that request and following resnpose/resnposes can be send
> on the same connection. Again from RFC 3261 ".... 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." From this point
> I am able to conclude that the client connection should be opend during SIP
> transaction. If "... A stateless proxy does not have any notion of a
> transaction" how can I provide such behavior ?
>
> Victor Tsoukanov
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
