Will Quan wrote:
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."
Yes. But IMO a client should not re-create state. If the UAS does not
find a matching dialog it should reject the transaction and the UAC
should create a new dialog. Much more safe - accepting in-dialog request
without matching having a matching dialog introduces lots of security
problems.
regards
klaus
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
