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
