inline. Adam Roach wrote:
Well, its definitely more than zero. Caller prefs as it stands is, by definition, something a proxy spends cycles doing. How much more it will take to add this piece of processing, I am not certain."Jonathan Rosenberg" <jdrosen@dynamicsoft.com> writes:I am inclined to go with approach 3, adding the appropriate discussions on the privacy considerations. The specific algorithm I would propose is this. If the caller prefs selection process results in zero contact, the proxy re-runs the algorithms without the implicit preferences. If now, there are contacts remaining, it concludes that the implicit preferences caused the problem. It then checks to see if the problem was methods or event packages, and generates a 405 or 489 accordingly.
Two comments; one con, one "interesting": 1. It seems to me that this approach adds a substantial burden to the proxy.
Interesting indeed.2. This has the interesting effect of forcing the proxy to aggregate the methods and the event-packages available for an address-of-record. (e.g. if I have a client registered that supports MESSAGE, and one that supports INVITE, the proxy-generated 405 will ostensibly indicate both INVITE and MESSAGE as acceptable methods.) Of course, this may well exacerbate the security problems you discuss -- but it also might be a useful feature. It also has the odd consequence that I can get a more accurate picture of your capabilities by intentionally sending an invalid method than I can by sending an OPTIONS...