Hello All,
RFC 3841 gives a helpful example of caller preferences processing in
7.2.5, quoted below. But, I am not sure about the significance of the
q-value in the Accept-Contact: header, e.g.
Accept-Contact: *;methods="BYE";class="business";q=1.0
In the example, Contact:
sip:[EMAIL PROTECTED];audio;video;methods="INVITE,BYE";q=0.2 is said to
match the preferences in the Accept-Contact: header above with a score
of 0.5, but this seems to ignore the mismatching q-values. Should the
score not be 0.33 (one match out of 3, not one match out of 2)?
Can someone please explain this to me, I have read through RFC 4596 as
well, but I can't find any other example of a q-value in an
Accept-Contact: header.
Regards,
Peter
>From RFC 3841:
7.2.5. Example
Consider the following example, which is contrived but illustrative
of the various components of the matching process. There are five
registered Contacts for sip:[EMAIL PROTECTED] They are:
Contact: sip:[EMAIL PROTECTED];audio;video;methods="INVITE,BYE";q=0.2
Contact: sip:[EMAIL PROTECTED];audio="FALSE";
methods="INVITE";actor="msg-taker";q=0.2
Contact: sip:[EMAIL PROTECTED];audio;actor="msg-taker";
methods="INVITE";video;q=0.3
Contact: sip:[EMAIL PROTECTED];audio;methods="INVITE,OPTIONS";q=0.2
Contact: sip:[EMAIL PROTECTED];q=0.5
An INVITE sent to sip:[EMAIL PROTECTED] contained the following caller
preferences header fields:
Reject-Contact: *;actor="msg-taker";video
Accept-Contact: *;audio;require
Accept-Contact: *;video;explicit
Accept-Contact: *;methods="BYE";class="business";q=1.0
There are no implicit preferences in this example, because explicit
preferences are provided.
The proxy first removes u5 from the target set, since it is immune
from caller preferences processing.
Next, the proxy processes the Reject-Contact header field. It is a
match for all four remaining contacts, but only an explicit match for
u3. That is because u3 is the only one that explicitly indicated
support for video, and explicitly indicated it is a message taker.
So, u3 gets discarded, and the others remain.
Next, each of the remaining three contacts is compared against each
of the three Accept-Contact predicates. u1 is a match to all three,
earning a score of 1.0 for the first two predicates, and 0.5 for the
third (the methods feature tag was present in the contact predicate,
but the class tag was not). u2 doesn't match the first predicate.
Because that predicate has a require tag, u2 is discarded. u4
matches the first predicate, earning a score of 1.0. u4 matches the
Rosenberg, et al. Standards Track [Page 16]
RFC 3841 Caller Preferences for SIP August 2004
second predicate, but since the match is not explicit (the score is
0.0, in fact), the score is set to zero (it was already zero, so
nothing changes). u4 does not match the third predicate.
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
