Hmm. Now that I think about this further, I am thinking that you can't
use the same TCP connection for the response without maintaining state.
Minimally, you need to maintain enough state to associate the response
with the connection. Without that, you can't decide to use the
connection for responses or other requests for the reasons that have
come up in the connection reuse draft. (It would provide an opportunity
for somebody to hyjack requests and responses.)
Of course the connection itself is state. So adding a small amount of
additional state to identify the transactions that can use this for
responses may be reasonable, and is quite a bit simpler than maintaining
full transaction state.
Paul
Balaji Murlitharan wrote:
>
> Hi Attila,
>
> My concern is how many sockets you can handle or open in a minute,
> definitely it will affect the system performance.
>
> We can do the following,
>
> 1. We can map the timeout duration based on the number of sockets
> handled per minute by the system.
> 2. At the time out ,We have to close the inactive sockets.
>
> But here the problem is how to take care the SIP Responses after the
> time out.??
>
>
> *Regds,
> Balaji Murlitharan.C
> Aricent *
>
>
>
> *"Attila Sipos" <[EMAIL PROTECTED]>*
> Sent by: [EMAIL PROTECTED]
>
> 02/08/2007 01:56 AM
>
>
> To
> "Paul Kyzivat" <[EMAIL PROTECTED]>
> cc
> [email protected], Victor Tsoukanov <[EMAIL PROTECTED]>
> Subject
> Re: [Sip-implementors] Stateless Proxy and TCP transport
>
>
>
>
>
>
>
>
> Brett, Paul,
>
> I agree, keeping the TCP connection open would be better.
>
> What kind of implementation would be best for this?
> I was thinking maybe the socket could have a short timeout.
> This would still keep the proxy stateless.
>
> Or maybe keep a small amount of information relating to
> the SIP request just forwarded. Then when the response
> comes in, it can be matched to the request and then close
> the related socket. As a backup, there would be a timeout too
> in case no response came back.
>
> Would these solutions be reasonable?
> Any better suggestions?
>
> Regards,
> Attila
>
> -----Original Message-----
> From: [EMAIL PROTECTED] on behalf
> of Paul Kyzivat
> Sent: Wed 07/02/2007 17:19
> To: Attila Sipos
> Cc: [email protected]; Victor Tsoukanov
> Subject: Re: [Sip-implementors] Stateless Proxy and TCP
> transport
>
>
>
> 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
>
>
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
>
>
> *********************** Aricent-Private ***********************
>
> "DISCLAIMER: This message is proprietary to Aricent and is intended solely
> for the use of
> the individual to whom it is addressed. It may contain privileged or
> confidential information and should not be
> circulated or used for any purpose other than for what it is intended. If you
> have received this message in error,
> please notify the originator immediately. If you are not the intended
> recipient, you are notified that you are strictly
> prohibited from using, copying, altering, or disclosing the contents of this
> message. Aricent accepts no responsibility for
> loss or damage arising from the use of the information transmitted by this
> email including damage from virus."
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
