The caller would generate an INVITE that looks like, in part:
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;language="en";require
Accept-Contact: *;language="es";require
This will require a Contact URI to match both constraints. That
means it needs to support English and Spanish. This will achieve the
desired property.
Note that there are two separate Accept-Contact header fields. If
the caller had instead used this INVITE:
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;language="en,es";require
It would have connected them to a UA that speaks either English or
Spanish, which is not what is desired here.
An "explicit" option is not used, because it would bypass contacts
that do not include a language tag.
3.17. The Number You Have Called...
3.17.1. Desired Behavior
Consider once more the case of the executive, where the caller wishes
to reach only their mobile phone (Section 3.15). However, there is a
twist. The callee Y has moved to new address YY, and all the
configuration described for the callee now applies to YY. The old
address Y remains with a pair of statically assigned contacts. One
contact is YY. The other is M, referencing an automaton that
generates a voice message reporting that the number has been changed.
The caller is unaware of the move and calls Y, requesting to reach
the mobile phone in exactly the same way they did in Section 3.15.
The call should connect to the mobile.
3.17.2. Solution
There would be four registrations against YY:
YY1, the executive, would generate a REGISTER that looks like, in
part:
REGISTER sip:example.com SIP/2.0
To: sip:YY@example.com
Contact: <sip:YY1@pc.example.com>;q=0.1
YY2, the attendant, would generate a REGISTER that looks like, in
part:
REGISTER sip:example.com SIP/2.0
To: sip:YY@example.com
Contact: <sip:YY2@pc2.example.com>;attendant;q=1.0
YY3, the answering service, would generate a REGISTER that looks
like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:YY@example.com
Contact: <sip:YY3@pc3.example.com>;attendant;automata;q=0.5
YY4, the mobile, would generate a REGISTER that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:YY@example.com
Contact: <sip:YY4@mobile.example.com>;mobility="mobile";q=0.5
Although it would be configured administratively, there are two
registered contacts for Y. The first is for the forwarding:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:YY@example.com>;q=1.0
and the second for the automated answering service:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:machine@example.com>;automata;q=0.5
The caller, not knowing that Y has moved, calls Y and asks for their
mobile phone:
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;mobility="mobile";require;explicit
This reaches the example.com proxy, which finds two registrations.
Only one of these (the automaton) is associated with feature
parameters. The other has no feature parameters and is therefore
immune to caller preferences processing. The caller preferences are
applied to the automaton’s contact. The feature sets match, but have
a score of zero. Since the "require" and "explicit" tags are
present, the contact for the automaton is dropped. The other
contact, YY@example.com, is then added back in as the sole contact.
The proxy therefore sends the call to sip:YY@example.com. There,
there are four registrations, all of which are associated with
feature parameters. The caller preferences are applied. Only YY4
matches explicitly, however. Because of the presence of the
"require" and "explicit" flags, all other contacts are dropped. As
such, the call is forwarded to YY4, and the mobile phone rings.
3.18. The Number You Have Called, Take Two
3.18.1. Desired Behavior
This use case is nearly identical to that of Section 3.17. However,
this time, the caller wishes to contact the personal phone of Y.
They don’t feel strongly about it, and will accept other devices.
3.18.2. Solution
The INVITE generated by the caller in this case will look like:
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;class="personal"
This reaches the example.com proxy. Once more, the first
registration (which forwards to the address-of-record for YY) is
unaffected by the caller preferences computation. The other contact,
for the automaton, is a match, but its score is zero. Its caller
preference Qa equals zero. The other contact is added back in with a
Qa of 1.0. The contacts are sorted based on q-value, resulting in YY
(q=1.0) followed by machine (q=0.5). These are broken into
equivalence classes. There are two classes, one for each contact.
As a result, the caller’s preferences have no impact on the ordering,
and the call is routed to YY.
When the request for YY@example.com is processed, all four contacts
match. However, the score for all of them is zero (none are the
personal phone). As such, the contacts are ordered based on q-value.
Each contact has a different q-value, so no reordering based on
caller preference is possible (not that the caller preference would
cause a reordering; all contacts have a Qa of 0.0). Thus, the
highest q-value contact is tried, which is the executive assistant.
3.19. Forwarding to a Colleague
3.19.1. Desired Behavior
Alice wants to forward her phone to Bob, but doesn’t want folks
calling her to get Bob’s voicemail if he doesn’t answer. She wants
her callers to get her voicemail.
3.19.2. Solution
Alice would create three registrations. The first, Y1, represents
Alice’s phone. The second is Bob’s AOR. The third is a voicemail
server. The three contacts have decreasing q-values. The
registration for Bob’s AOR contains an embedded Reject-Contact header
field, which rejects message servers.
REGISTER sip:example.com
To: <sip:alice@example.com>
Contact: <sip:Y1@192.0.2.150>;q=1.0
REGISTER sip:example.com
To: <sip:alice@example.com>
Contact: <sip:bob@example.com?Reject-Contact=*;msgserver>;q=0.3
REGISTER sip:example.com
To: <sip:alice@example.com>
Contact: <sip:alice-drop@msgcenter.example.com>
;msgserver;
;automata
;attendant
;q=0.1
Meanwhile, Bob is registered as follows:
REGISTER sip:example.com
To: <sip:bob@example.com>
Contact: <sip:bob3@192.0.2.212>;q=0.8
REGISTER sip:example.com
To: <sip:bob@example.com>
Contact: <sip:bob-drop@msgcenter.example.com>
;msgserver
;automata
;attendant
;q=0.2
Carol calls Alice and doesn’t include any caller preference
parameters. As such, the example.com proxy constructs an implicit
preference for INVITE. This preference matches all three registered
contacts, with a score of zero. Because each contact has a different
q-value, there is no reordering of contacts. So, the proxy tries the
highest q-value Contact, Alice’s desk phone (Y1). The proxy cancels
after a few seconds (no answer). The proxy then tries the next
Contact, which is Bob’s AOR. When constructing the request for this
Contact, the proxy includes the embedded Reject-Contact header field
in the INVITE. This INVITE undergoes caller preferences processing
based on Bob’s registered Contacts.
Bob has two registered Contacts. The second is a message server, and
it matches the Reject-Contact in the INVITE. Thus, this contact is
discarded. The other remaining Contact, Bob’s phone, is tried. Bob
is not around, so his phone rings for a while. Upon timeout, the
proxy determines it is unable to reach Bob’s AOR. So, the proxy
handling Alice tries the final remaining contact, which is Alice’s
message server.
4. Capability Use Cases
The callee capabilities spec [2] allows the Contact header field in
OPTIONS responses and dialog initiating messages to contain
capabilities of the UA. These capabilities can be very useful for
developing new applications. In the subsections below, several
usages are outlined.
4.1. Web Redirect
A caller sends an INVITE to the called party. However, the called
party is not present. The proxy server representing the called party
would like to redirect the caller to a web page, where they can find
out more information on how to reach the called party. However, the
proxy needs to know whether or not the caller supports redirects to
web pages. If it doesn’t, the proxy would connect the user to an
interactive voice response (IVR) device, which would execute an
answering machine application.
The proxy could make such a determination if the caller included the
"schemes" feature tag in the Contact header field of its INVITE:
INVITE sip:callee@example.com SIP/2.0
Contact: <sip:host22.example.com>;schemes="http,sip,sips,tel"
This tells the proxy that the UAC can be redirected to an http URI.
The INVITE from a normal "black phone" that lacked this capability
would look like:
INVITE sip:callee@example.com SIP/2.0
Contact: <sip:host22.example.com>;schemes="sip,sips,tel"
This indicates that it needs to be connected to the IVR.
4.2. Voicemail Icon
On the circuit network, when a user makes a call, and an answering
machine picks up, the caller usually requires several seconds to
determine that they are speaking to an answering machine. It would
be helpful if a phone could display an icon immediately on call
completion that indicated that an answering machine was reached.
This indication can be provided by the "msgserver" feature parameter.
When the answering machine picks up, its 200 OK looks like, in part:
SIP/2.0 200 OK
Contact: <sip:server33.example.com>;msgserver;automata;attendant
This tells the caller that it’s an answering machine.
5. Usage of the Feature Tags
The caller preferences extension briefly enumerates a list of media
feature tags that can be registered by a device and included in the
Accept-Contact and Reject-Contact header fields in a request. Proper
operation of caller preferences depends strongly on consistent
interpretation of these feature tags by the caller and the callee.
In this section, we provide some guidelines on the usage of these
feature tags.
Generally speaking, the more information a device provides when it
registers, the more effective the caller preferences extension is.
This is why the callee capabilities extension recommends that a
device register as much information as it can. This point cannot be
overstated.
If devices explicitly registered features that they don’t support,
such as ’video="false"’, the operation of RFC 3841 would be improved.
However, given the open-ended nature of capabilities, it will never
be possible to ensure the registration of negative values for all
capabilities of interest to a caller. Furthermore, attempting to do
so would significantly bloat registrations. Instead, it is
recommended that all "unusual" capabilities be explicitly registered.
The subsections below show example registrations from typical
devices.
5.1. Traditional Cell Phone
A VoIP cell phone capable of making voice calls would generate a
registration that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:user@example.com
Contact: <sip:cell-phone@example.com>
;audio
;class="business"
;duplex="full"
;+sip.extensions="100rel,path"
;mobility="mobile"
;methods="INVITE,BYE,OPTIONS,CANCEL,ACK"
;schemes="sip,sips,tel"
;uri-user="<cell-phone>"
;uri-domain="example.com"
5.2. Traditional Work Phone
A traditional landline IP PBX phone would generate a registration
that looks like:
REGISTER sip:example.com SIP/2.0
To: sip:user@example.com
Contact: <sip:ippbx-phone@example.com>
;audio
;class="business"
;duplex="full"
;events="dialog"
;+sip.extensions="100rel,privacy"
;mobility="fixed"
;methods="INVITE,BYE,OPTIONS,CANCEL,ACK,SUBSCRIBE"
;schemes="sip,sips,tel"
;uri-user="<ippbx-phone>"
;uri-domain="example.com"
This device also supports the dialog event package and several SIP
extensions that would be typical in an IP PBX phone.
5.3. PC Messaging Application
A PC messenger client, capable of just doing presence and IM (no
voice) would generate a registration that looks like:
REGISTER sip:example.com SIP/2.0
To: sip:user@example.com
Contact: <sip:pc-msgr@example.com>
;class="personal"
;mobility="fixed"
;methods="OPTIONS,MESSAGE,NOTIFY"
;schemes="sip,sips,im,pres"
;uri-user="<pc-msgr>"
;uri-domain="example.com"
5.4. Standalone Videophone
A standalone IP videophone, capable of audio and video, would
generate a registration that looks like, in part
REGISTER sip:example.com SIP/2.0
To: sip:user@example.com
Contact: <sip:vp@example.com>
;audio
;video
;class="business"
;duplex="full"
;mobility="fixed"
;methods="INVITE,BYE,OPTIONS,CANCEL,ACK"
;schemes="sip,sips,tel"
;uri-user="<vp>"
;uri-domain="example.com"
6. Example of Implementation of Preference and Capability Matching
RFC 3841 [3] utilizes the definitions and feature matching algorithm
defined in RFC 2533 [6]. This provides a precise normative
specification of the algorithm. However, that specification isn’t
ideal as a guideline for implementation because it is more complex
than is required for the restricted use employed by RFC 3841. (The
simplification is primarily because a particular feature tag may only
appear once in each Contact, Accept-Contact, or Reject-Contact
header.)
This section provides a sample approach to implementing the matching
of caller preferences to callee capabilities; it does not require the
use of the notation and techniques of RFC 2533. It is not normative,
but is believed to be consistent with that definition. It may be
considered an alternative for that portion of RFC 3841 beginning with
Section 7.2.3 and extending to the end of page 13 in the middle of
Section 7.2.4.
In this section, there are frequent references to syntactic elements
defined by ABNF in RFC 3840, Section 9, and RFC 3841, Section 10.
Here, ABNF elements are enclosed to single quotes -- for example,
’feature-param’. Such a reference identifies a sequence of octets
within a SIP request that match the corresponding ABNF element when
the sip request is parsed according to RFCs 3261, 3840, and 3841.
6.1. Extracting a Feature Set from a Header
Contact header fields, Accept-Contact header fields, and Reject-
Contact header fields each contain zero or more ’feature-param’s,
each in turn may contain one or more ’tag-value’s, or a ’string-
value’. The first step is to extract from each header field a more
useful representation as a feature set, herein called an FS. (This
FS representation of a feature set representation differs from that
in RFC 2533.) This process is the same for each type of header.
An FS consists of a set of one or more feature params denoted by FP.
Each FP has a name, denoted FP.NAME, and a set of one or more value
ranges denoted by VR. Each VR consists of:
o A type (VR.TYPE): either token (TOKEN-TYPE), string (STRING-TYPE),
or number-range (RANGE-TYPE)
o A negation flag (VR.NEGATION): either NEGATED, or NON-NEGATED
o The actual value, differing by type:
* For TOKEN-TYPE and STRING-TYPE, a sequence of octets
(VR.OCTETS)
* For RANGE-TYPE, a pair of signed real numbers (VR.LB and VR.UB)
representing the lower and upper bounds on the range,
inclusive.
A single FS is created to represent the features of one header.
(Contact, Accept-Contact, Reject-Contact.) Within the FS, an FP is
created for each ’feature-param’ in the header. To create an FP, a
’feature-param’ is examined as follows:
o If the ’feature-param’ contains an instance of ’other-tags’, then
FP.NAME is the value matched by ’ftag-name’.
o Otherwise, the ’feature-param’ contains an instance of ’base-
tags’. If the value matched by ’base-tags’ is "language" or
"type", then FP.NAME is just the value matched by ’base-tags’. If
not, then FP.NAME is the value matched by ’base-tags’ and prefixed
with "sip.".
o The value of the ’feature-param’, if any, is processed (according
to the rules in the next section) to extract a set of one or more
VRs that are associated with the FP.
6.2. Extracting Values from a Feature Parameter
The value of a ’feature-param’ is an encoded representation (as
specified in RFC 3840) of one or more value ranges of the
corresponding feature. There are several data types that these
values may take on: boolean, token, string, number, or numeric range.
The type is determined by the encoded form of the value. (These
types and their representations are specific to this implementation.)
(Note: numeric values can explicitly represent a range of values.
The other types only represent single value: a degenerate range. The
term value range is used to encompass all of these.)
The value of the ’feature-param’ (’string-value’, ’tag-value-list’,
or none) is converted to VR form as follows:
o If there is no value, then a single new VR is created with VR.TYPE
= TOKEN-TYPE, VR.NEGATION = NON-NEGATED, and VR.OCTETS set to
"true".
o If the ’feature-param’ contains a ’string-value’, then a single
new VR is created with VR.TYPE = STRING-TYPE, VR.NEGATION =
NON-NEGATED, and VR.OCTETS is set to the octets matching ’qdtext’.
o Otherwise the ’feature-param’ contains a ’tag-value-list’, and a
new VR is created for each ’tag-value’ in the ’tag-value-list’, as
follows:
o If the ’tag-value’ begins with "!", VR.NEGATION = NEGATED;
otherwise, VR.NEGATION = NON-NEGATED.
o If the ’tag-value’ contains a ’boolean’ or ’token-nobang’, then
VR.TYPE = TOKEN-TYPE, and VR.OCTETS is set to the octets matched
by ’boolean’ or ’token-nobang’.
o If the ’tag-value’ contains a ’numeric’, VR.TYPE = RANGE-TYPE and:
* If ’numeric-relation’ is "<=", VR.UB is set to the numeric
value matching ’number’. VR.LB is set to MIN-REAL (a negative
number with the largest expressible magnitude.)
* If ’numeric-relation’ is "=", both VR.LB and VR.UB are set to
the numeric value matching ’number’.
* If ’numeric-relation’ is ">=", VR.LB is set to the numeric
value matching ’number’ plus a small epsilon. VR.UB is set to
MAX-REAL (a positive number with the largest expressible
magnitude).
* Else the ’numeric-relation’ consists of two ’number’s separated
by a colon. In this case, VR.LB is set to the numeric value of
the smaller of the two numbers, and VR.UB is set to the numeric
value of the larger of the two numbers.
6.3. Comparing Two Value-Ranges
Two VRs match if their ranges overlap. The comparison is done
according to type, and only comparisons between like types are
defined. When two VRs of differing types are compared, they are
considered not to overlap. Either or both of the VRs may be NEGATED.
Comparison proceeds as follows:
o If the VRs are of different types, the match is false.
o Otherwise:
* Two VRs with VR.TYPE = RANGE-TYPE match if max(VR1.LB, VR2.LB)
<= min(VR1.UB, VR2.UB).
* Two VRs with VR.TYPE = TOKEN-TYPE match if their respective
VR.OCTETS values compare equal by case-insensitive comparison.
* Two VRs with VR.TYPE = STRING-TYPE match if their respective
VR.OCTETS values compare equal by case-sensitive comparison.
o The result (true/false) is then negated if VR1.NEGATION = NEGATED,
and negated again if VR2.NEGATION = NEGATED.
6.4. Feature Set to Feature Set Matching
In RFC 2533, the matching of two feature sets is commutative, but as
applied to caller preferences matching it is not. In this
application, one feature set comes from an Accept-Contact or Reject-
Contact header, and the other comes from a Contact header. For
purposes of this description, these will be termed the preferred-
features (FSp) and the capability-features (FSc), respectively.
Non-commutativity arises from explicit tests for the presence among
capability-params of feature param names used in preferred-features.
A preferred-features feature set FSp may be matched to one
capability-features feature set FSc, and this yields the following
metrics:
o NPF - The number of preferred-features.
o NCF - The number of preferred-features for which there is a
capability-feature of the same name.
o NVM - The number of value matches between corresponding features
of the two feature sets.
For a particular pair of FPp and FPc, these metrics are computed as
follows:
o All the metrics are set to zero.
o The following steps are applied for each feature param (FPp) of
the FSp:
* NPF is incremented.
* A corresponding FP with the same name is sought (using case-
insensitive comparison) in the FSc.
* If a corresponding feature param (FPc) is found:
+ NCF is incremented.
+ Every VR of FPp is matched to every VR of FPc.
+ If any of those matches succeed, NVM is incremented.
6.5. Selecting and Ordering Contacts Based on Caller Preferences
6.5.1. Reject-Contact Processing
The reject processing specified in Section 7.4.2 of RFC 3841 may be
performed as follows:
o For each candidate Contact in the target set, match the feature
set of each Reject-Contact to it.
o If (NVM == NPF) & (NCF == NPF), remove the contact URI from the
target set.
6.5.2. Accept-Contact Processing
The matching of an Accept-Contact against a Contact and subsequent
scoring of the match specified in Section 7.4.2 of RFC 3841 may be
performed as follows:
o Match the feature set of the Accept-Contact to that of the Contact
as specified in Section 6.4.
o If (NVM < NCF), then the match failed. If the Accept-Contact had
its "require" flag set, then discard the corresponding contact URI
from the target set.
o Compute the score as NVM/NPF.
o Apply the "require" and "explicit" flags as specified in the text
and Figure 7 of RFC 3841.
7. Security Considerations
This document provides explanation and examples of the use and
implementation of RFCs 3840 and 3841. The security considerations
sections of those documents apply to the material presented here.
8. Acknowledgements
The authors would like to thank Rohan Mahy for his input in this
specification.
9. Informative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating
User Agent Capabilities in the Session Initiation Protocol
(SIP)", RFC 3840, August 2004.
[3] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004.