Taisto,
You raise an interesting question.
I don't think it was one that was considered at the time.
The callerprefs/callee-caps work was under development for a long time
before it finally became RFCs. Most of the definition of the semantics
of individual capabilities was done quite early in that process, when
the semantics of matching was very loosely defined.
It was toward the end of that process when RFC 2533 was incorporated as
the say to do matching. When that was adopted, then the capability
syntax for ranges was added. We probably should have revisited the
definition of capabilities that have numeric values, such as priority.
But I guess we didn't.
Bottom line: I don't think there is a complete answer to your question.
You might want to file an erratum against RFC 3840.
There seem to be two choices:
- encode the value as a 'token-nobang' containing only digits.
- encode the value as a 'numeric'.
Note that the way the matching rules are defined in 3841 the two
representations above are compatible. So for purposes of callerprefs
matching you can use either form, or one form in the capability and the
other form in the preference, and just accept the match that results.
That means, for callerprefs matching, an integer would only represent
itself, not it and all larger values.
Understanding the meaning for purposes other than callerpref matching
could still follow the semantic description - that for a single integer
it means requests with priorities equal or greater will be handled.
Good luck,
Paul
On 6/11/14 6:00 AM, Taisto Qvist wrote:
Hey folks,
I've been looking into caller preferences and callee capabilities, and more specifically
the "Priority" feature tag and how it should be encoded/interpreted.
The definition according to RFC3840 says:
Summary of the media feature indicated by this tag: The sip.priority
feature tag indicates the call priorities the device is willing to
handle. A value of X means that the device is willing to take
requests with priority X and higher. This does not imply that a
phone has to reject calls of lower priority. As always, the
decision on handling of such calls is a matter of local policy.
Values appropriate for use with this feature tag: An integer. Each
integral value corresponds to one of the possible values of the
Priority header field as specified in SIP [1].
At the same time, the BNF, indicates possible "data-types" as:
feature-param = enc-feature-tag [EQUAL LDQUOT (tag-value-list
/ string-value ) RDQUOT]
enc-feature-tag = base-tags / other-tags
base-tags = "audio" / "automata" /
"class" / "duplex" / "data" /
"control" / "mobility" / "description" /
"events" / "priority" / "methods" /
"schemes" / "application" / "video" /
"language" / "type" / "isfocus" /
"actor" / "text" / "extensions"
tag-value-list = tag-value *("," tag-value)
tag-value = ["!"] (token-nobang / boolean / numeric)
token-nobang = 1*(alphanum / "-" / "." / "%" / "*"
/ "_" / "+" / "`" / "'" / "~" )
boolean = "TRUE" / "FALSE"
numeric = "#" numeric-relation number
numeric-relation = ">=" / "<=" / "=" / (number ":")
number = [ "+" / "-" ] 1*DIGIT ["." 0*DIGIT]
The ambiguity I am trying to resolve, is that "values appropriate" says *integer*, which would at
first glance tell me to use the "numeric" construct for tag-value. This would give me the possibility
to use values such as ;priority="#<=10" or similar for describing intervals/ranges of priority.
But that collides with the summary description which says: "A value of X means....priority X and
higher"...which would make the ">=;<=;=" operators redundant.
At the same time, RFC3841 indicates that the matching process:
The matching
rules in RFC 2533 only require an implementation to know whether the
feature tag is a numeric, token, or quoted string (booleans can be
treated as tokens).
Where the presence of param="#" indicates numeric. Without the "#",
;priority="10" becomes a token, and would be compared case-insensitive.
"Priority X and higher" indicates numeric analysis, wheras token comparison
does not.
So, which is it?
How is everyone else interpreting this?
Regards
Taisto Qvist
IP-Solutions.se
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
