Subject: RE: [Sipping] methods contact parameter

From: Adam Roach <[email-masked]>
Date: Wed, 4 Sep 2002 17:06:38 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> 
> the above mentioned i-d also defines an accept-contact header that the
> uac can use to specify, which contacts a request should be proxied to.
> in order to prevent subscribes and messages from going to sip phones
> that don't support them (and that don't include the methods contact
> parameter in register), would it be correct proxy behavior to 
> only proxy
> a message with
> 
> accept-contact: *; methods="method"
> 
> to those contacts that actually have explicitly listed the 
> method in the
> register message?  

The fundamental problem is that callerprefs is (and will
remain) an extension to base SIP, not part of the core
protocol. Its use is completely orthagonal to implementation
of MESSAGE, SUBSCRIBE, NOTIFY, PUBLISH, and any other
extension methods. While RFC 3265 mentions callerprefs as
a mechanism for advertising support for SUBSCRIBE, it does
not mandate -- and neither will any of its sucessors, to
the best of my knowledge.

If you implement a proxy that behaves in the way that you
describe, you are virtually guaranteed to not send messages
to all of the nodes that *can* support them. It is not
a valid optimization.

That said, I beleive it would be acceptable for your registrar
to send an OPTIONS to any contact which is registered with it,
and if (but only if) the response contains an "Allow:" header
in it, you can safely store the fact that the contact supports
those and only those methods. Because of the possibility that
the client might change, though (think PC clients), I'd say
you need to refresh such information every time a client
registers. In the final equasion, I doubt this approach will
save you any any messaging overhead at all.

/a
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 04 Sep 2002 18:43:03 -0400

In addition to what Adam says, if you implement the proxy as you describe, you will be in violation of callerprefs. Its matching rules say that a contact that doesn't mention a particular preference type matches all values of that preference type. So a contact that didn't explicitly mention methods= must be assumed by the proxy to support all methods.

If you have control of the endpoints, you can solve this by having the endpoints explicitly register with the methods they do support.

Also note that as of the last rev of callerprefs, there is another pref type for event, so you can select both on support for SUBSCRIBE and on the particular event package being subscribed.

BTW, Adam's OPTIONS idea is interesting.

	Paul

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 5 Sep 2002 09:41:42 +0300

thanks for the replies.  i need to check how widely OPTIONs is supported
by UAs (which may not be that common).  hopefully however i get better
results than what happens now with SUBSCRIBE.  NONE of the half a dozen
sip phones that i own, returned 405 to subscribe.  instead they returned
400 bad req or 406 not acceptable.

it might be a good idea for you guys who participate in sip
standardization, once is a while check what your company's products are
actually doing in real world:-).  by the way, dynamicsoft ua (if any)
was not among those that i tested.

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 5 Sep 2002 11:32:20 +0300

Adam Roach writes:

 > those and only those methods. 

if i rememebr correctly, allow header can also appear in the register
message.  if so, isn't it a good idea for each UA to always add the
allow header?  then the registrar would not need to query the methods
via options.

-- juha

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 05 Sep 2002 12:46:04 -0400

inline.

> allow header?  then the registrar would not need to query the methods

Table 2/3 allows Allow in REGISTER, but its usage in REGISTER is not 
explicitly discussed anywhere. Usage of Allow in register can be 
confusing, though. REGISTER provides information potentially on several 
contacts. Which one of those contacts (each of which is a separate UA) 
is the one that Allow is referring to? This ambiguity is resolved with 
caller preferences, which would associate capabilities with a specific 
contact URI (and thus, specific UA).

This is probably a spec error - Allow should probably not be allowed in 
REGISTER.

Let me also take this opportunity to "pitch" caller preferences. We are 
finding more and more that caller preferences helps solve a host of 
problems that are being encountered. As the number of different devices 
on the market increases, we will have more and more need to be able to 
determine the capabilities of those devices to properly route to them 
and provide them services. Caller preferences does all that. Its time 
for UA implementors to take this specification very seriously.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 05 Sep 2002 13:49:46 -0400

> allow header?  then the registrar would not need to query the methods

That doesn't mean what you want.

An Allow header in the register would mean that the UA sending the register supports the specified methods. But the UA sending the register isn't necessarily the same as the UA(s) being registered, which are defined by the Contact parameters of the register message.

If the UA is smart enough to add an Allow header, it can also be smart enough to add callerprefs parameters to the Contact headers it is registering:

	REGISTER sip:acme.com
	From: sip:[email-masked]
	To: sip:[email-masked]
	Contact: sip:[email-masked];
	   methods="INVITE,ACK,OPTIONS,CANCEL,BYE"

or

	REGISTER sip:acme.com
	From: sip:[email-masked]
	To: sip:[email-masked]
	Contact: sip:[email-masked];
	   methods="INVITE,ACK,OPTIONS,CANCEL,BYE,SUBSCRIBE,NOTIFY";
           events="presence,dialog"

With both of the registrations above, a callerprefs aware proxy receiving a SUBSCRIBE for dialog would adjust the contact list, ending up with: 

	Contact: sip:[email-masked];q=1.0
	   methods="INVITE,ACK,OPTIONS,CANCEL,BYE,SUBSCRIBE,NOTIFY";
           events="presence,dialog"
	Contact: sip:[email-masked];q=0.0
	   methods="INVITE,ACK,OPTIONS,CANCEL,BYE"

and so would try phone89 before phone12.

Unfortunately, I think this highlights a problem with callerprefs. Contacts that don't match any Accept-Contact are simply placed at the end of the list (with q=0.0), not excluded altogether. To get something out of the list entirely you must use Reject-Contact. That is ok for explicitly written preferences, but isn't so good for the ones implicitly generated for "priority", "methods", and "events". I think maybe the implicit preferences ought to be rendered as Reject-Contact rather than Accept-Contact.

	Paul

---

From: [email-masked]
Date: Fri, 6 Sep 2002 10:05:37 +0300

how about the following rule when a proxy receives a request X:

it forwards X to all contacts that either (a) have included X in the
methods list of the contact during registration or (b) have not included
a methods list at all

this way new UAs that include methods would not receive unwanted
requests and the callers would not include any caller preferences for
this purpose.

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 06 Sep 2002 10:31:32 -0400

Juha,

The problem is that currently the handling of methods is integrated with other callerprefs. There is some logic to provide implicit values for the "methods", "events", and "priority" parameters to Accept-Contact if no explict values are provided for those. Then the standard routing logic is applied.

To achieve what you suggest, either the general method for matching callerprefs must be changed, or else the manner in which "methods" are used must be detached from the general approach and be special cased.

If we consider just "methods" for a moment, it clearly isn't useful to send a SUBSCRIBE message to a server that has explicitly indicated that it doesn't support SUBSCRIBE. This can be rendered in explicit callerprefs headers as:

	Reject-Contact: *;methods="!SUBSCRIBE"

The same is true for the "events". 

Priority is weird. The server gets to express the minimum priority it wishes to handle, so it would presumably like to see calls with less priority sent somewhere else. But the caller has total control of the priority it claims. The caller probably has no preference at all - it is only providing the priority as a courtesy to the callee. This doesn't seem well suited to the callerprefs mechanism at all - it ought to be driven by a callee specified algorithm. If we try to handle it via a callerprefs mechanism at all, the Reject-Contact approach seems at least as reasonable as anything else.

So, I am thinking that all the defaulting, for "methods", "events", and "priority" should probably generate Reject-Contact rules rather than Accept-Contact rules.

An alternative would be to change the matching logic for Accept-Contact so that Contacts with a final qvalue of 0.0 are removed rather than used. But I think that is probably a bad idea.

Unfortunately, this is a bad time to be discussing this, because I believe callerprefs has already gone through last call and may already be well on its way to becoming an RFC, if it hasn't already done so.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 06 Sep 2002 16:23:11 -0400

inline.

Paul Kyzivat wrote:
 > Juha,
 >
 > The problem is that currently the handling of methods is integrated
 > with other callerprefs. There is some logic to provide implicit
 > values for the "methods", "events", and "priority" parameters to
 > Accept-Contact if no explict values are provided for those. Then the
 > standard routing logic is applied.

Just for the edification of the group, the algorithm that Juha has 
suggested:

    it forwards X to all contacts that either (a) have included X in the
    methods list of the contact during registration or (b) have not
    included

is very close to what caller preferneces will do today. In the current 
caller preferences spec, when the caller says nothing about preferred 
methods, the proxy constructs an implicit preference of:

Accept-Contact: *;methods="SUBSCRIBE"

or whatever the method of the request is, if not SUBSCRIBE. The caller 
preferences logic in the proxy will match this preference to any 
registered contact that explicitly indicates support for SUBSCRIBE in 
the methods paramter, or indicates nothing about methods at all. As a 
result, the proxy will preferentially send the request to those contacts 
first. However, it may still try the others, as a lower priority choice.

 >
 > To achieve what you suggest, either the general method for matching
 > callerprefs must be changed, or else the manner in which "methods"
 > are used must be detached from the general approach and be special
 > cased.
 >
 > If we consider just "methods" for a moment, it clearly isn't useful
 > to send a SUBSCRIBE message to a server that has explicitly indicated
 > that it doesn't support SUBSCRIBE. This can be rendered in explicit
 > callerprefs headers as:
 >

Ah. Interesting. This would change the logic only slightly, really. The 
result of this change is that the request would NEVER go to a UA that 
declared support for a set of methods, but omitted SUBSCRIBE. I'm really 
not sure thats what you want. It puts a serious burden on the UA to 
never forget to include anything, else it will never receive messages. I 
fear this introduces some brittleness that we may not want.

Either way, I think the result would satisfy Juha.

 >
 > Priority is weird. The server gets to express the minimum priority it
 > wishes to handle, so it would presumably like to see calls with less
 > priority sent somewhere else. But the caller has total control of the
 > priority it claims. The caller probably has no preference at all - it
 > is only providing the priority as a courtesy to the callee.

I don't see this as the case at all.

Lets say I declare my personal cell phone for high priority calls, and 
my enterprise PBX phone for everything else. I did that setting since I 
always answer the cell phone.  If someone calls with a high priority 
call, it will ring my cell phone first. In such a case, the caller does 
have a preference - they really want to reach me NOW, and therefore are 
asking for this call to be routed to the phone which I have declared as 
high priority - the one I always answer.

Perhaps that intent is not clear enough from the spec...

 > This
 > doesn't seem well suited to the callerprefs mechanism at all - it
 > ought to be driven by a callee specified algorithm. If we try to
 > handle it via a callerprefs mechanism at all, the Reject-Contact
 > approach seems at least as reasonable as anything else.

I don't see that.

 >
 > So, I am thinking that all the defaulting, for "methods", "events",
 > and "priority" should probably generate Reject-Contact rules rather
 > than Accept-Contact rules.

I'd prefer to keep it, for the reasons above, but would welcome 
additional thoughts on the subject.

 >
 > An alternative would be to change the matching logic for
 > Accept-Contact so that Contacts with a final qvalue of 0.0 are
 > removed rather than used. But I think that is probably a bad idea.

I hate special casing.

 >
 > Unfortunately, this is a bad time to be discussing this, because I
 > believe callerprefs has already gone through last call and may
 > already be well on its way to becoming an RFC, if it hasn't already
 > done so.

No, it hasn't gone off (my bad). I need to do another rev based on 
things agreed to in Yokohama. Real work kept me from this for some time, 
so I am reworking it this very moment. SO now is an ideal time.

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 06 Sep 2002 20:03:57 -0400

> first. However, it may still try the others, as a lower priority choice.
                     ^^^
                     WILL

Of course in some sense the proxy can do whatever it wants. It can use some other logic to decide among the choices. But if it hasn't been instructed to do anything except follow the callerprefs specification, then it will eventually try the contacts that were not accepted before giving up.

> fear this introduces some brittleness that we may not want.

I think this is an entirely reasonable burden. If you know enough to put a methods parameter on your Contact, you ought to know enough to include the right values. Otherwise why are you putting it at all? In any case, if you do it wrong it won't take much testing to discover it.

(I presume if you are building a UAS that does SUBSCRIBE, you probably test that subscriptions work after you make coding changes to it. If you code in a registration with a methods param and omit SUBSCRIBE, your first test of subscriptions will fail.)

> Either way, I think the result would satisfy Juha.

Lets see what he says. He seemed concerned with avoiding subscriptions going where they aren't wanted. So I predict that the existing way won't satisfy him.

> Perhaps that intent is not clear enough from the spec...

Maybe I was just too dense to see it.

Achieving your intent just with callerprefs is a bit tricky. One way you might try is:

   Contact: sip:cellphone;priority="high";q=1.0
   Contact: sip:pbxphone;q=0.5

With current rules this will have callers with high priority to trying the cellphone first and the pbx phone second, while lower priority callers will try the pbx phone first and the cellphone later. That isn't what you want. Another possibility is:

   Contact: sip:cellphone;priority="high";q=1.0
   Contact: sip:pbxphone;q=0.5
   Contact: sip:voicemail;q=0.2

Here high priority callers will try the cell phone, then the pbx, then voicemail. Lower priority callers will try the pbx, then voicemail, then the cellphone. Since voicemail should always pick up, this is close to what you want.

But there is no obvious way to skip the voicemail and just give the low priority caller ring no answer on the pbx phone.

If we change the handling of priority to a Reject-Contact, then kinds of registration above will achieve your intent.

>  > approach seems at least as reasonable as anything else.

You convinced me.

> additional thoughts on the subject.

Maybe it takes some other cases test this out, but your case is better using Reject-Contact.

BTW, in draft-ietf-sip-callerprefs-06 there is no defined "high" priority value. :-)

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 08 Sep 2002 15:32:50 -0400

inline.

Paul Kyzivat wrote:
 >> it forwards X to all contacts that either (a) have included X in
 >> the methods list of the contact during registration or (b) have not
 >>  included
 >>
 >> is very close to what caller preferneces will do today. In the
 >> current caller preferences spec, when the caller says nothing about
 >> preferred methods, the proxy constructs an implicit preference of:
 >>
 >> or whatever the method of the request is, if not SUBSCRIBE. The
 >> caller preferences logic in the proxy will match this preference to
 >> any registered contact that explicitly indicates support for
 >> SUBSCRIBE in the methods paramter, or indicates nothing about
 >> methods at all. As a result, the proxy will preferentially send the
 >> request to those contacts first. However, it may still try the
 >> others, as a lower priority choice.
 >
 > ^^^ WILL
 >
 > Of course in some sense the proxy can do whatever it wants. It can
 > use some other logic to decide among the choices. But if it hasn't
 > been instructed to do anything except follow the callerprefs
 > specification, then it will eventually try the contacts that were not
 > accepted before giving up.
 >
 >
 >>>
 >>> To achieve what you suggest, either the general method for
 >>> matching callerprefs must be changed, or else the manner in which
 >>> "methods" are used must be detached from the general approach and
 >>> be special cased.
 >>>
 >>> If we consider just "methods" for a moment, it clearly isn't
 >>> useful to send a SUBSCRIBE message to a server that has
 >>> explicitly indicated that it doesn't support SUBSCRIBE. This can
 >>> be rendered in explicit callerprefs headers as:
 >>>
 >> Ah. Interesting. This would change the logic only slightly, really.
 >> The result of this change is that the request would NEVER go to a
 >> UA that declared support for a set of methods, but omitted
 >> SUBSCRIBE. I'm really not sure thats what you want. It puts a
 >> serious burden on the UA to never forget to include anything, else
 >> it will never receive messages. I fear this introduces some
 >> brittleness that we may not want.
 >
 >
 > I think this is an entirely reasonable burden. If you know enough to
 > put a methods parameter on your Contact, you ought to know enough to
 > include the right values. Otherwise why are you putting it at all? In
 > any case, if you do it wrong it won't take much testing to discover
 > it.
 >
 > (I presume if you are building a UAS that does SUBSCRIBE, you
 > probably test that subscriptions work after you make coding changes
 > to it. If you code in a registration with a methods param and omit
 > SUBSCRIBE, your first test of subscriptions will fail.)

I was about to concede the point, and change the spec to your proposal, 
when I realized it doesn't have the desired property.

The thing to remember is that each caller preferences syntax defines a 
feature set - a collection of points in N-dimensional "feature space", 
with each dimension corresponding to some feature tag (such as methods, 
events, etc.). Two feature sets match when there exists at least one 
point - aka a feature collection - in both sets.

COnsider this predicate in a Reject-Contact header:

methods="!SUBSCRIBE"

*ANY* feature collection (i.e., n-dimensional vector) whose methods tag 
is not SUBSCRIBE is in this set. Now, consider a UA that registers to 
receive INVITE, BYE, OPTIONS, CANCEL, SUBSCRIBE and NOTIFY:

REGISTER
Contact: sip:1.2.3.4;
  methods="INVITE,BYE,OPTIONS,CANCEL,SUBSCRIBE,NOTIFY"

this set includes points whose method doesn't equal SUBSCRIBE, such as 
INVITE. Therefore, the two feature sets match, and the UA will not be 
contacted with the incoming SUBSCRIBE request!

The semantics you are really after is something like "please reject a 
contact if it does not match the following feature set". This is not the 
semantic of Reject-Contact, which says "please reject this contact if it 
does match the following feature set". So, a new header is needed, 
something like Reject-Contact-IfNoMatch. Thus, the implicit preference 
would be constructed as:

Reject-Contact-IfNoMatch: *;methods="SUBSCRIBE"

and this would have the desired effect.

I would actually propose to add this header to caller preferences, along 
with a matching Accept-Contact-IfNoMatch, which says to accept a contact 
if its feature set doesn't match the feature set in the header value. 
Since there DOES appear to be consensus, between yourself and Juha, 
about the desired semantic for the implicit preferences, and since it 
should be done using standard headers, this is necessary. I'm not too 
worried about backwards compatibility since very few people are 
including any kind of preference headers in requests right now. I also 
want to make sure we can use caller prefs to do the few things we know 
we need to do, such as this one.

 > Lets see what he says. He seemed concerned with avoiding
 > subscriptions going where they aren't wanted. So I predict that the
 > existing way won't satisfy him.

Indeed, since Juha has threatened to once again light himself on fire 
and throw himself in front of his proxy vendor, it appears you are 
correct ;)

Note that I would change the implicit preference rules as you have 
requested for the event and methods feature tags only (i.e., use 
Reject-Contact-IfNoMatch). There are two others, the various media 
feature tags (audio, video, message, application) and the priority 
feature tag, which are different. The difference is, in these cases, if 
the request does go to a UA that doesn't support the specific feature, 
the spec defines ways in which the call can still proceed successfully. 
In these cases, I don't think you want to preclude these UAs from being 
contacted at a lower priority.

So, let me give an example. First off, I have already split the "media" 
feature tag into separate boolean attributes for each media type. So, if 
a UA supports audio and video, it would register like this:

Contact: sip:1.2.3.4;audio="TRUE";video="TRUE"

A UA for the same AOR that only supports audio would register like this:

Contact: sip:1.2.3.5;audio="TRUE";video="FALSE"

(Its actually important that it explicitly indicate that it DOESNT do 
video. Otherwise, the two of these would be considered equally good for 
receiving video calls!)

If the proxy receives an INVITE with an SDP with audio and video streams 
in it, it can (at MAY strength as per new text in -07) construct an 
implicit preference like this:

Accept-Contact: *;audio="TRUE";video="TRUE"

This would match the 1.2.3.4 contact, but not the 1.2.3.5 contact. Thus, 
it gets routed to the UA that does audio and video. If this UA is not 
there, the proxy can still route the call to the 1.2.3.5 UA. Per 
offer/answer, that UA could simply reject the video stream, and the call 
is still set up. Thus, I believe its still useful to try this UA at 
lower priority. This argues for an implicit Accept-Contact rather than 
an implicit Accept-Contact-IfNoMatch.

Same goes for priority. More on that below.

 >
 >
 >>>
 >>> Priority is weird. The server gets to express the minimum
 >>> priority it wishes to handle, so it would presumably like to see
 >>> calls with less priority sent somewhere else. But the caller has
 >>> total control of the priority it claims. The caller probably has
 >>> no preference at all - it is only providing the priority as a
 >>> courtesy to the callee.
 >>
 >> Lets say I declare my personal cell phone for high priority calls,
 >> and my enterprise PBX phone for everything else. I did that setting
 >> since I always answer the cell phone. If someone calls with a high
 >> priority call, it will ring my cell phone first. In such a case,
 >> the caller does have a preference - they really want to reach me
 >> NOW, and therefore are asking for this call to be routed to the
 >> phone which I have declared as high priority - the one I always
 >> answer.
 >>
 > Contact: sip:cellphone;priority="high";q=1.0 Contact:
 > sip:pbxphone;q=0.5
 >
 > With current rules this will have callers with high priority to
 > trying the cellphone first and the pbx phone second, while lower
 > priority callers will try the pbx phone first and the cellphone
 > later. That isn't what you want. Another possibility is:
 >
 > Contact: sip:cellphone;priority="high";q=1.0 Contact:
 > sip:pbxphone;q=0.5 Contact: sip:voicemail;q=0.2
 >
 > Here high priority callers will try the cell phone, then the pbx,
 > then voicemail. Lower priority callers will try the pbx, then
 > voicemail, then the cellphone. Since voicemail should always pick up,
 > this is close to what you want.
 >
 > But there is no obvious way to skip the voicemail and just give the
 > low priority caller ring no answer on the pbx phone.
 >
 > If we change the handling of priority to a Reject-Contact, then kinds
 > of registration above will achieve your intent.
 >
 >
 >>> This doesn't seem well suited to the callerprefs mechanism at all
 >>> - it ought to be driven by a callee specified algorithm. If we
 >>> try to handle it via a callerprefs mechanism at all, the
 >>> Reject-Contact approach seems at least as reasonable as anything
 >>> else.
 >>
 >> I don't see that.
 >
 >
 > You convinced me.

Not sure whether I convinced you that caller prefs is useful for this, 
or you are saying that I had convinced you previously that it wasnt.

Anyway, I do see your point about priority primarily being a callee 
driven thing. In fact, the CPL spec has a priority-switch for this 
capability. The CPL would allow the callee to indicate exactly how to 
route calls of various priorities.

Given that, we should consider the proper behavior in the context of a 
caller preference. I would still argue that the implicit behavior 
currently described is correct, because it gets the caller to the 
highest priority device first. Furthermore, since other devices can in 
fact receive the call, there is no reason to eliminate them. If the 
callee wants them eliminated, it would do that with CPL.

 >
 >
 >>>
 >>> So, I am thinking that all the defaulting, for "methods",
 >>> "events", and "priority" should probably generate Reject-Contact
 >>> rules rather than Accept-Contact rules.
 >>

Should there be? bis doesn't define one, AFAIK - its just non-urgent, 
normal, urgent and emergency.

-Jonathan R.

---

From: [email-masked]
Date: Sun, 8 Sep 2002 09:39:38 +0300

> any case, if you do it wrong it won't take much testing to discover

i agree with paul.  if a UA includes the methods parameter in a contact,
then it is not unreasonable requirement to list ALL methods that the
contact can handle.  

my conclusion of this is that i'll ask my proxy vendor to implement the
rule that i described in the previous message.  if i find a UA that
includes methods, but doesn't list all methods the contact supports,
then i simply don't recommend my customers to use such a UA.

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 Sep 2002 13:02:26 -0400

Jonathan,

draft-ietf-sip-callerprefs-06 made a radical change in the statement of algorithm, but I thought it in general was intended to preserve the semantics from before. It is possible that something was lost in the translation, so I want to look back to draft-ietf-sip-callerprefs-05 to check the meaning of the case we are discussing. It says (in section 6.4.1):

   The parameters match if and only if each parameter in the rule
   matches the contact entry. A single parameter in the rule matches the
   contact entry if that parameter is present in the contact entry, and
   their values match. If a parameter exists in the rule, and there is
   no parameter of the same name in the contact entry, whether or not
   this is a match is context dependent. If the rule is present in the
   Accept-Contact header, it is considered a match. If the rule is
   present in the Reject-Contact header, it is not considered a match.

   Parameter names are matched by case-sensitive comparison.  The
   parameter values in the rule are interpreted as an OR-of-ANDs logic
   statement, with the conjunctions separated by commas, and the
   components in the conjunction separated by ampersands. The logic
   statement can be preceded by the negation operator (!). The parameter
   values in the contact entry are interpreted as a set of elements. A
   component in the logic statement is true if its value appears in the
   set of elements (based on a case sensitive string comparison), false
   otherwise. The rule matches the contact entry if the rule would
   evaluate to true, given that the value of the components of the rule
   are true or false depending on their presence in the set defined by
   the contact entry.

So lets apply that to the following pair (your example):

   Reject-Contact header: *;methods="!SUBSCRIBE"

   Contact: sip:1.2.3.4;methods="INVITE,BYE,OPTIONS,CANCEL,SUBSCRIBE,NOTIFY"

- the parameter (methods) is present both in the rule and the contact.
- the value SUBSCRIBE appears in both, so that part of the rule evaluates true
- the negation then causes the rule as a whole to evaluate false
- so this Contact is NOT rejected

Lets try it on another case:

   Reject-Contact header: *;methods="!SUBSCRIBE"

   Contact: sip:1.2.3.4;methods="INVITE,BYE,OPTIONS,CANCEL,NOTIFY"

- the parameter (methods) is present both in the rule and the contact.
- the value SUBSCRIBE appears in the rule but not the contact,
  so that part of the rule evaluates false
- the negation then causes the rule as a whole to evaluate true
- so this Contact IS rejected

Lets try a degenerate case:

   Reject-Contact header: *;methods="!SUBSCRIBE"

   Contact: sip:1.2.3.4

- the parameter (methods) is present in the rule but not the contact.
- because this is a Reject-Contact, this is NOT considered a match
- so this Contact is NOT rejected

All of these are consistent with what I expect. And this is different than the result you came up with.

Now, I must admit at this point that I only skimmed rfc 2533 when callerprefs-06 came out. Superficially it looked like it was probably just stating the same matching rules that had been stated previously in a different way. I just went back and looked a little closer, and now I see that this may not be the case - I am going to have to spend significant time to understand it in sufficient depth to be sure I can predict outcomes. I was going to attempt to formally apply it to the cases above, but decided that was going to be a lot of work, so I am going to postpone it.

Without doing that, I think I can see some places where nuances of the earlier algorithms may have been lost in the translation:

- the new rules translate 

  Contact: sip:1.2.3.4;methods="INVITE,BYE,OPTIONS,CANCEL,NOTIFY"

  into something like (methods=INVITE) OR (methods=BYE) OR ...
  whereas the old rules effectively used AND

- I no longer see anything corresponding to the old special case that treated Accept-Contact and Reject-Contact differently when a parameter in the rule has no corresponding parameter in the contact. 

BOTTOM LINE: 

I think something important was lost in going from callerprefs-05 to -06. I don't think the solution is in adding a Reject-Contact-IfNoMatch header. Rather I suspect that we need to revise the mapping to rfc 2533. 

(While I need more time to study it, it does appear that rfc 2533 is probably suitable for expressing our matching algorithm if we can just state things appropriately. OTOH, it may suffiently obfuscate things that interoperability will never be achieved.)

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 12 Sep 2002 16:14:55 -0400

inline.

Paul Kyzivat wrote:
 > Jonathan,
 >
 > draft-ietf-sip-callerprefs-06 made a radical change in the statement
 > of algorithm, but I thought it in general was intended to preserve
 > the semantics from before. It is possible that something was lost in
 > the translation, so I want to look back to
 > draft-ietf-sip-callerprefs-05 to check the meaning of the case we are
 >  discussing. It says (in section 6.4.1):

As a high level comment, the goal of the change to rfc2533 was not a 
preservation in the exact semantics (although I think they are more or 
less close), but rather alignment with a model that is much better well 
defined and well thought out.

 > present in the Reject-Contact header, it is not considered a match.

This last bit (Reject-Contact doesn't match if the rule specifies a tag 
not present in the contact parameter) will have changed with the new 
rules. I think it makes sense; the matching operation should not be 
context dependent. Sets either match or they don't.

 > otherwise.

This interpretation of the negation operator is also different from 
rfc2533. The negation operation in rfc2533 is a way to say that an 
element is described by all values of a feature tag EXCEPT the listed 
ones. In -05, it modified the matching algorithm.

 > The rule matches the contact entry if the rule would
 > Contact:
 > sip:1.2.3.4;methods="INVITE,BYE,OPTIONS,CANCEL,SUBSCRIBE,NOTIFY"
 >
 > - the parameter (methods) is present both in the rule and the
 > contact. - the value SUBSCRIBE appears in both, so that part of the
 > rule evaluates true - the negation then causes the rule as a whole to
 >  evaluate false - so this Contact is NOT rejected

Agreed this is the interpretation from -05.

 > - the parameter (methods) is present both in the rule and the
 > contact. - the value SUBSCRIBE appears in the rule but not the
 > contact, so that part of the rule evaluates false - the negation then
 >  causes the rule as a whole to evaluate true - so this Contact IS
 > rejected

Agreed again, based on -05 semantics.

 >  - because this is a Reject-Contact, this is NOT considered a match -
 >  so this Contact is NOT rejected

Agreed.

 > Now, I must admit at this point that I only skimmed rfc 2533 when
 > callerprefs-06 came out. Superficially it looked like it was probably
 >  just stating the same matching rules that had been stated previously
 >  in a different way. I just went back and looked a little closer, and
 >  now I see that this may not be the case - I am going to have to
 > spend significant time to understand it in sufficient depth to be
 > sure I can predict outcomes. I was going to attempt to formally apply
 > it to the cases above, but decided that was going to be a lot of
 > work, so I am going to postpone it.

I think its really easier to understand with the rfc2533 semantics. You 
just need to understand the model. THe model is that each feature tag 
(audio, methods, events), represents an axis in N-dimenational space. A 
point in this N-dimensional space is a feature collection, and describes 
  a particular instance of a usage. A feature set is a set of feature 
collections. To describe the set, you construct a boolean predicate. A 
feature collection V is in the set if, when you evaluate the boolean, it 
evaluates to true. That is:

feature collection V is in the feature set described by the boolean 
function f() if f(V) = TRUE.

Here is the key thing - two feature sets match if there exists at least 
one feature collection that is present in both feature sets. That is, 
for predicates f1 and f2, f1 matches f2 IFF there exists some V such 
that f1(V) = TRUE and f2(V) = TRUE. Geometrically, the N-dimenational 
spaces described by f1 and f2 need to overlap.

The benefit of this model is that it extends to matching of arbitrary 
feature numbers of feature sets. The caller-prefs -05 algorithm only 
works for two. So, in the future, if we wanted to specify administrator 
preferences that also needed to be matched, we can. We couldn't with -05.

 >
 > Without doing that, I think I can see some places where nuances of
 > the earlier algorithms may have been lost in the translation:
 >
 > into something like (methods=INVITE) OR (methods=BYE) OR ... whereas
 > the old rules effectively used AND

Using AND here makes no sense given the definition of the model. Part of 
the problem we had before is that we didnt have a model - this was what 
led to all this confusion about what AND meant in these contexts. The 
contact you list above would translate to:

(| (methods=INVITE) (methods=BYE) (methods=OPTIONS) (methods=CANCEL) 
(methods=NOTIFY))

 >
 > - I no longer see anything corresponding to the old special case that
 >  treated Accept-Contact and Reject-Contact differently when a
 > parameter in the rule has no corresponding parameter in the contact.

You get that effect using the new Reject-Contact-IfNoMatch, which 
performs a negation after completion. So consider:

If the registered contact is sip:1.2.3.4;methods="INVITE,BYE", the two 
feature sets don't match, and the contact is therefore rejected (reject 
if no match). If the registered contact is 
sip:1.2.3.4;methods="SUBSCRIBE,INVITE,BYE", the two feature sets do 
match, so the contact is not rejected. If the registered contact is 
sip:1.2.3.4, the two feature  sets DO match (think about it), and 
therefore it is not rejected.

So, to summarize, the behavior that -05 implied with:

is now had through:

which is why I added it - so we could have this semantic and fit within 
the 2533 model.

 >
 >
 > BOTTOM LINE:
 >
 > I think something important was lost in going from callerprefs-05 to
 > -06. I don't think the solution is in adding a
 > Reject-Contact-IfNoMatch header. Rather I suspect that we need to
 > revise the mapping to rfc 2533.

I disagree. We can't (and dont want to) modify the matching algorithm. 
Once matching the algorithm is separated from the feature set 
description (which it should be), the negation operation as defined 
before cannot be used. What I have done here is "factor it out", the 
result of that being its now in existence in the header, through the 
IfNoMatch clause.

-Jonathan R.