In the past I had posted a similar question to sip-implementors. The explanation was this:
The R-R headers are added to new request to give a chance to crashed end-points to re-create state from a mid-dialog request such as re-INVITE to refresh the call. This is clearer from Section 16.6: Step 4. "The proxy will remain on the path if it chooses to not insert a R-R header field value into requests that are already part of a dialog. However, it would be removed from the path when an endpoint that has failed reconstitutes the dialog." Regards, --will http://article.gmane.org/gmane.ietf.sip-implementors/8974/match=record+route http://tools.ietf.org/html/rfc3261#section-16.6 Klaus Darilion wrote: > > > Juha Heinanen schrieb: > > > > > If this request is already part of a dialog, the proxy SHOULD > insert > > > > a Record-Route header field value if it wishes to remain on the > path > > > > of future requests in the dialog. In normal endpoint operation as > > > > described in Section 12, these Record- Route header field > values will > > > > not have any effect on the route sets used by the endpoints. > > > > > > It should insert Record-Route but it has no effect??? > > > > does not make sense to me and therefore my proxy does not insert r-r > > header to in-dialog requests. > > IMO you are doing it right (my proxies also do not insert RR in > in-dialog requests). > > But for example fwd does insert RR headers. This caused ugly NAT > problems as eyebeam/xlite < 1.5.16 also was buggy and updated the > route set if there were Record-Route headers in in-dialog requests. > > I fear there are many more buggy clients out there. > > regards > klaus > > > _______________________________________________ > Devel mailing list > Devel@openser.org > http://openser.org/cgi-bin/mailman/listinfo/devel _______________________________________________ Devel mailing list Devel@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel
