Hi Subhash, I just saw the copy of the RFC in http://www.ietf.org/rfc/rfc3261.txt?number=3261
But still I could see that typo.... ( see the 6th line from top of page 124) Thanks & Regards, Nataraju A.B. -----Original Message----- From: Nayak, Subhash [mailto:[EMAIL PROTECTED] Sent: Monday, November 21, 2005 4:46 PM To: [EMAIL PROTECTED]; [email protected] Subject: RE: [Sip-implementors] typo error in RFC-3261 Hi Nataraju, 1) The typo is not present in the RFC. Probably your local copy was edited by mistake. 2) The Route headers in ACK (300-699) are meaningful only for stateless proxies. Since ACK to non-2xx is a hop-by-hop mechanism, each stateful proxy will consume the received non-2xx, ACK it, and generate a new non-2xx response for the upstream element. So if all elements in a call-flow were stateful proxies, there is no need for copying of Route headers. But incase there is a stateless proxy (P2) between two stateful elements (P1 and P3), and the Route headers are not present in the ACK generated by P1 to non-2xx generated by P3, then P2 will route the ACK request based on the Request-URI (whereas it had used the Route header to route the INVITE). Hence the ACK might land at a different proxy. Subhash Nayak Sonus Networks Inc. http://www.sonusnet.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nataraju A B Sent: Monday, November 21, 2005 12:41 PM To: [email protected] Subject: [Sip-implementors] typo error in RFC-3261 Hi All, I guess these are the typo error found in the rfc-3261. Can these be fixed ? 1. 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. As far as SIP transactions are concerned, stateless proxies are effectively transparent. The purpose of the client transaction is to receive a request from the element in which the client is embedded (call this element the "Transaction User" or TU; it can be a UA or a stateful proxy), and reliably deliver the request to a server transaction. Rosenberg, et. al. Standards Track [Page 123] RFC 3261 SIP: Session Initiation Protocol June 2002 The client transaction is also responsible for receiving responses and delivering them to the TU, filtering out any response retransmissions or disallowed responses (such as a response to ACK). Additionally, in the case of an INVITE request, the client transaction is responsible for generating the ACK request for any >> final response accepting a 2xx response. The last sentence should have been mentioned as EXCEPTING 2xx response instead of accepting 2xx response. 2. If the INVITE request whose response is being acknowledged had Route header fields, those header fields MUST appear in the ACK. This is to ensure that the ACK can be routed properly through any downstream stateless proxies. [ABN] I feel Route header in ACK (for 300-699) would be more meaningful for stateful proxies rather than stateless proxies.. Best Regards, Nataraju A.B. Kodiak Networks Ind Pvt Ltd "Be a student not a follower" _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
