[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Error reporting in caller prefs
Hi,
I vote for option 4 with a subtle variation. Accept-contact w/ require
will still match contacts (with q=0) if all the explicit preferences
match but the implicit ones do not. The difference is that you still
get a 480 if you eliminated all contacts using an *explicit* match, but
an ordinary 405 or 489 if all contacts were eliminated using implicit
preferences only.
thanks,
-rohan
On Monday, January 27, 2003, at 11:27 AM, Jonathan Rosenberg wrote:
This is the second note of two that describes some recently encountered
issues while trying to wrap caller prefs.
The issue here is error reporting.
Lets say a caller lists a bunch of caller preferences, which include
Reject-Contacts and Require-Contacts (now removed in -08 and replaced
with a require parameter on Accept-Contact, but I'll use the -07
terminology). It is entirely
possible that these preferences will result in ALL registered contacts
getting discarded. The current behavior will be that the proxy acts as
if there were no registered contacts, and returns a 480. Now, this
means
that the caller has no way to determine if the request failed because
of
their preferences, or because there really were no registered contacts.
At first, I thought that this was a bad thing. But, thinking abuot it
more, I concluded it was a good thing, for privacy reasons. The proxy
is
the one performing the caller preferences computation. The proxy will
frequently not be the one authenticating the caller, or authorizing
them
to make calls or learn information abuot the called party. But, if a
proxy reported information on call failures because of preference
mismatches, a client would be able to "probe" the network using caller
preferences, and learn detailed ifnormation on the capabilities of the
devices associated with a user, without authentication. The current
behavior prevents that, and I think thats good.
OK, so whats the problem? Well, its those implicit preferences again.
Lets say a user sends a SUBSCRIBE request, without caller preferences
parameters. The called party has one UA, and it doesnt support
SUBSCRIBE. Its registration to its proxy indicated such. The proxy
supports caller preferences. So, it wuold compute an implicit
preference
to route the request to a UA that supports SUBSCRIBE, and give it the
require strength (meaning, contacts which don't support SUBSCRIBE are
discarded). Since none do, the
one registered contact is discarded, and the caller receives a 480.
A similar thing happens for event packages.
This is a change in behavior if caller preferences were not used, in
which case either (1) the UAS would authenticate and authorize the
caller, and then return a 405 with the allowed methods, (2) the UAS
would not authenticate or authorize the UAC, and thus genreate a 403
or 401.
As a result, even though the caller did not use caller preferences,
they
have suffered from a loss of information, just because the proxy used
caller prefs. The 405 would be useful for the UAC to perhaps try
another
method, or report the failure to the user. I dont mind a loss of
information with EXPLICIT preferences, since the caller knows what they
are getting into. But for implicit, we shouldn't be changing basic SIP
behavior as seen by the UAC.
There are a small number of solutions:
1. eliminate Require-Contact entirely (or, in -08 terms, eliminate the
require parameter to Accept-Contact). This solves the problem, because
the proxy will simply set the un-matching contacts to have a q-value
of zero, and try them last. In the above example, the one registered
contact remains with q=0, and is tried, resulting in a 405.
2.eliminate implicit preferences that use the Require-Contact semantic.
So, if the request fails with a 480, its because the client explicitly
asked for soemthing they couldnt get.
3. If a proxy uses caller prefs, and the result is the eliminatin of
all contacts, AND if the reason they were eliminated was that there
was an implicit Require-Contact for a specific method or event
package, the proxy generates a 405 or 489 as if it were the UAS.
4. modify the semantics of require-contact so that, in the case where
all contacts would be eliminated, instead of eliminating them, it sets
the q-value to zero. This avoids the error condition.
I didn't see any other approaches. None of these seem perfect:
1. Approach 1 is a non-starter; we have applications which need the
Require semantic.
2. Approach 2 is better than approach 1. However, it will result in
SUBSCRIBE and other methods being sent to a UAS that indicated that it
didn't support those methods. On the list, Juha had complained loudly
about this, and this thread was one of the motivations for adding
require-contact. Now, the client can add the explicit Require-Contact
with this solution, but that adds somewhat of a burden.
3. Appraoch 3 has a potential security issue. The proxy will generate
a 405 or 489 on behalf of the UAS. So, if the UAS would generally not
want to reveal this information (supported methods and event packages)
unless the UAC would be authorized and authenticated, this approach
will "leak" this information. One might argue that if the UAS uses
caller prefs, and tells the proxy which methods and event packages it
supports, it has forfeited its right to explicitly authenticate and
authorize the caller before this information is divulged. If the UAS
has these privacy concerns, it should not register these caller
preferences parameters.
4. Approach 4 has similar problems to approach 2.
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.
Comments?
-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave.
Chief Scientist First Floor
dynamicsoft East Hanover, NJ 07936
jdrosen@dynamicsoft.com FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.dynamicsoft.com
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip