Vineet, For stateless proxy, I dig some more excerpts from RFC 3261,
17 Transactions A stateless proxy does not contain a client or server transaction. The transaction exists between the UA or stateful proxy on one side, and the UA or stateful proxy on the other side. The client transaction is also responsible for receiving responses and delivering them to the TU, filtering out any response retransmissions Similarly, the purpose of the server transaction is to receive requests from the transport layer and deliver them to the TU. The server transaction filters any request retransmissions from the network. To identify a retransmitted request/response for stateful proxy, you can refer section following sections of RFC 3261:- 17.2.3 Matching Requests to Server Transactions & 17.1.3 Matching Responses to Client Transactions Hope it helps. regards, Aman Aggarwal Aricent From: Vineet Menon [mailto:[email protected]] Sent: Monday, April 30, 2012 11:41 AM To: Aman Aggarwal Cc: Shanbhag, Somesh (NSN - IN/Bangalore); [email protected] Subject: Re: [Sip-implementors] detect retransmitted messages.. hi, Thanks Shanbhag and Aman for your answers... @Aman, does that mean a stateless proxy cannot detect retransmitted messages from the existing protocol? Regards, Vineet Menon On 30 April 2012 11:26, Aman Aggarwal <[email protected]<mailto:[email protected]>> wrote: Hi Vineet, Stateless proxy cannot distinguish a retransmission since it does not maintain any transaction. For stateless proxy, RFC 3261 states that 16.11 Stateless Proxy When acting statelessly, a proxy is a simple message forwarder. Much of the processing performed when acting statelessly is the same as when behaving statefully. The differences are detailed here. A stateless proxy does not have any notion of a transaction, or of the response context used to describe stateful proxy behavior. Instead, the stateless proxy takes messages, both requests and responses, directly from the transport layer (See section 18). As a result, stateless proxies do not retransmit messages on their own. They do, however, forward all retransmissions they receive (they do not have the ability to distinguish a retransmission from the original message). regards, Aman Aggarwal Aricent -----Original Message----- From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Shanbhag, Somesh (NSN - IN/Bangalore) Sent: Monday, April 30, 2012 10:59 AM To: ext Vineet Menon; [email protected]<mailto:[email protected]> Subject: Re: [Sip-implementors] detect retransmitted messages.. Hi Vineet, As far as stateful transaction is concerned, I think, call-id would give a clear enough picture of a retransmitted message, but what if it's a new invite for capability negotitation??? [Answer] The re-INVITE shall have the incremented CSeq number and the retransmission shall not have. This is because retransmission is normally done by Transaction layer in Stateful case. Regards, Somesh -----Original Message----- From: [email protected]<mailto:[email protected]> on behalf of ext Vineet Menon Sent: Mon 4/30/2012 10:32 AM To: [email protected]<mailto:[email protected]> Subject: [Sip-implementors] detect retransmitted messages.. Hi, I wanted to know is there a way to detect a retransmitted message in a stateless and statefull proxy? As far as stateful transaction is concerned, I think, call-id would give a clear enough picture of a retransmitted message, but what if it's a new invite for capability negotitation??? How to detect this in a stateless transaction?? Regards, Vineet Menon _______________________________________________ Sip-implementors mailing list [email protected]<mailto:[email protected]> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected]<mailto:[email protected]> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors =============================================================================== Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. =============================================================================== =============================================================================== Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. =============================================================================== _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
