I do not think Paragraph 3 conflicts paragraph 2. Both are saying same thing about route set, in that, it needs to be recomputed when 2xx is received, because, as you also point out, rfc 2543 did not mandate echoing RR headers in 1xx responses.
Paragraph 3 is about updating other dialog states and that they should not be updated after receiving 2xx, only route set. The example is given of Cseq number. So to answer your question, after receiving 2xx to Invite, the route set should be recomputed and it replaces existing early dialog route set. Sanjay >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On >Behalf Of Brett Tate >Sent: Wednesday, August 20, 2008 1:18 PM >To: sip-implementors@lists.cs.columbia.edu >Subject: [Sip-implementors] rfc3261 section 13.2.2.4: INVITE >2xx impacts > >RFC 3261 section 13.2.2.4 discusses the impacts of INVITE 2xx >when a dialog known because prior 1xx. > >Paragraph 3 appears to conflict with paragraph 2 concerning >updating the route set. Paragraph 2 indicates that the route >set must be recomputed per 12.2.1.2 (which updates the >remote-target without discussing record-route). Paragraph 3 >appears to indicate that the route set should be impacted by >2xx record-route for backwards compatibility reasons. > >What should be the impacts of received INVITE 2xx's >record-route upon existing dialog switching to confirmed? > >Thanks, >Brett > >_______________________________________________ >Sip-implementors mailing list >Sip-implementors@lists.cs.columbia.edu >https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
