;uri-domain="example.com"
;schemes="sip,pres"
;mobility="fixed"
;class="business"
A SUBSCRIBE request for presence will arrive at the proxy for
example.com. Since there are no explicit preferences, it constructs
an implicit require-flagged Accept-Contact preference from the
request:
(& (sip.methods="SUBSCRIBE") (sip.events="presence"))
Following Section 7.2.4 of RFC 3841, this feature set only matches
the one registered by Yp. Because the require flag is set, the
contacts which do not match are removed from the target set.
Therefore, Y1..Yn are discarded. The request is sent to the
remaining contact, Yp, representing the PA.
An INVITE request without explicit preferences results in an implicit
require-flagged Accept-Contact preference:
(& (sip.methods="INVITE"))
The implicit Accept-Contact feature set matches Y1..Yn, but does not
match Yp. Using the scoring algorithm from Section 7.2.4 of RFC
3841, the score for Y1..Yn against this predicate is 1.0. As a
result, the caller preference Qa for each contact is 1.0. The
registrations did not contain q-values, so the default q-value of 1.0
is applied to each Contact URI. Since the caller and callee
preferences are the same and all equal to 1.0, there is no reordering
of contacts. The result is that the proxy will consider Y1..Yn each
as equally good targets for the request and possibly fork the request
to each.
A SUBSCRIBE request for the dialog event package without explicit
preferences will result in an implicit require-flagged Accept-Contact
preference:
(& (sip.methods="SUBSCRIBE") (sip.events="dialog"))
This only matches Y1..Yn, so Yp is discarded, and the request is
routed to the remaining contacts just as the INVITE was.
3.4. Package Routing II
3.4.1. Desired Behavior
This case is nearly identical to that of Section 3.3. However,
Y1..Yn omit the "events" feature tag from their registration. Yp
registers as in Section 3.3. A SUBSCRIBE for the presence event
package should still preferentially route to Yp.
3.4.2. Solution
The registration from Y1..Yn will look like:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Yi@pc.example.com>
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE"
;uri-user="<Yi>"
;uri-domain="example.com"
;audio
;schemes="sip"
;mobility="fixed"
;class="personal"
When the caller sends a SUBSCRIBE for the presence event package
(without explicit preferences), the proxy computes an implicit
preference:
(& (sip.methods="SUBSCRIBE") (sip.events="presence"))
This predicate matches Y1..Yn and Yp. However, the score for Y1..Yn
against this predicate is 0.5, and the score of Yp is 1.0. The
result is a caller preference Qa of 0.5 for Y1..Yn, and a caller
preference Qa of 1.0 for Yp. Since the callee provided no q-values,
the proxy will assume a default of 1.0. Thus, all contacts are in
the same equivalence class. They are then sorted by Qa, so that Yp
is first, followed by Y1 through Yn. It will therefore route the
request first to Yp, and if that should fail, to Y1..Yn.
3.5. Audio/Video vs. Audio Only
3.5.1. Desired Behavior
X sends an invitation to Y to initiate an audio/video call, including
both m=audio and m=video lines in the SDP. AOR Y has two contacts,
Y1 and Y2. Y1 represents a normal audio phone, where Y prefers to
receive their calls. It will answer an audio/video call, refusing
the video. Y2 represents an audio/video phone that should only used
when needed. The caller really wants the call answered by a device
that supports video, but will accept an audio-only call as a second
choice.
3.5.2. Solution
Y1 will generate a registration that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@pc.example.com>;q=1.0
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
;uri-user="<Y1>"
;uri-domain="example.com"
;audio
;schemes="sip,tel"
;mobility="fixed"
;class="business"
Y2 will generate a registration that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y2@pc.example.com>;q=0.6
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
;uri-user="<Y2>"
;uri-domain="example.com"
;audio
;video
;schemes="sip,tel"
;mobility="fixed"
;class="business"
Note the different q-values, allowing Y2 to be selected as a device
of "last resort".
To have the call preferentially routed to a device that supports
video, the caller X sends an INVITE that looks like, in part:
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *
;methods="INVITE"
;video
The proxy will convert this to a feature set. This feature set
matches Y2 and Y1. However, the score for Y2 is 1.0, and 0.5 for Y1.
The two contacts are then ordered by q-value and broken into
equivalence classes. There are two equivalence classes, each with
one contact. As a result, the caller preference values have no
impact on the ordering. The call will first try the higher priority
Y1, which will answer the call and reject the video stream. Thus,
the desired behavior is not achieved.
The desired behavior could be achieved by adding the "explicit" and
"require" tags to the Accept-Contact header field in the INVITE, as
is done in Section 3.6. However, doing so may result in calls
failing when they could occur, but without video. As discussed in
[3], both the "require" and "explicit" tags are generally used only
when the request cannot be serviced in any way unless the preferences
are met. That is not the case here.
3.6. Forcing Audio/Video
3.6.1. Desired Behavior
This case is similar to that of Section 3.5. However, X requires an
audio/video call and would like the call to fail if this is not
possible, rather than succeed with audio only.
3.6.2. Solution
The solution is similar to that of Section 3.5; however, the Accept-
Contact header field now includes the "explicit" and "require" tags,
guaranteeing that the call is never established to any UA that had
not explicitly indicated support for video:
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;video;require;explicit
This arrives at the example.com proxy. This explicit feature set
matches the feature set for Y2 and Y1. However, the match for Y1 did
not have a score of 1. Since the "explicit" and "require" tags are
present, the contact is discarded. That leaves Y2 only. The call
will therefore get routed to the videophone, and if the user is not
there, the audio phone will never ring.
Because both the "require" and "explicit" flags are present, a
contact will also be discarded if it does not include a feature tag
indicating support for video. Thus, a UA that can do video, but
neglected to indicate it, would not be reached in this case. This is
why it is important for a UA to indicate all of its capabilities.
Note that this is only true for a contact that indicated some
capabilities but not the video capability. Contacts that don’t
indicate any capabilities are "immune" from caller preferences
filtering and would not be discarded.
3.7. Third-Party Call Control: Forcing Media
3.7.1. Desired Behavior
Z is a third-party call control controller (3pcc) [9] trying to
establish an audio/video call from X to Y. X has contacts X1 and X2,
and Y has contacts Y1 and Y2. X1 and X2 have capabilities identical
to Y1 and Y2, respectively. Z needs to send an offerless invite to X
and use the offer proposed by X to send an invite to Y. When sending
the offerless invite to X, the 3pcc controller must ensure that an
audio/video contact (X2) is chosen over an audio only contact (X1).
3.7.2. Solution
X1 will generate a registration that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:X@example.com
Contact: <sip:X1@pc.example.com>;q=1.0
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
;uri-user="<X1>"
;uri-domain="example.com"
;audio
;schemes="sip,tel"
;mobility="fixed"
;class="business"
X2 will generate a registration that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:X@example.com
Contact: <sip:X2@pc.example.com>;q=0.6
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
;uri-user="<X2>"
;uri-domain="example.com"
;audio
;video
;schemes="sip,tel"
;mobility="fixed"
;class="business"
Z would include, in its INVITE, an Accept-Contact header field:
INVITE sip:X@example.com SIP/2.0
Accept-Contact: *;audio;video;require;explicit
This caller preference matches both X1 and X2. However, it matches
X1 with a score of .5 and X2 with a score of 1. Because of the
"require" and "explicit" tags, X1 is discarded despite X’s preference
for it. Thus, the call is routed to X2.
The same caveats apply here as do in Section 3.6. Generally, it is
not advisable to mandate support for features (such as video) that
are not strictly necessary for the request to proceed.
3.8. Maximizing Media Overlaps
3.8.1. Desired Behavior
AOR Y has two contacts: Y1, which is a regular audio phone, and Y2,
which is a PC capable of supporting both audio and session-oriented
IM [10]. X is a PC with capability to support audio, video, and
session-oriented IM. X calls Y for the purpose of establishing a
voice call. However, X wishes to connect to the device that has the
maximal overlap with its media capabilities, in order to maximize the
functionality available to the caller.
3.8.2. Solution
Y1 will generate a registration that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@phone.example.com>
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
;uri-user="<Y1>"
;uri-domain="example.com"
;audio
;schemes="sip,tel"
;mobility="fixed"
;class="business"
Y2 will generate a registration that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y2@pc.example.com>
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,MESSAGE"
;uri-user="<Y2>"
;uri-domain="example.com"
;audio
;+sip.message
;schemes="sip,tel"
;mobility="fixed"
;class="business"
The solution requires the caller to support caller preferences. The
caller would include, in their INVITE, an Accept-Contact header field
that lists all the media types they support. In this case:
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;audio;video;+sip.message
Both Y1 and Y2 match the predicate. Y1 matches with a score of 0.33,
and Y2 matches with a score of 0.66. Since there is only one Accept-
Contact predicate, the Qa for each contact is equal to the score.
The registered contacts are then sorted by q-value and broken into
equivalence classes. There is a single equivalence class with
q-value of 1.0. The two contacts in that class are then re-ordered
based on the values of Qa. Y2 has a higher Qa, so it is used first,
followed by Y1. The result is that the call is routed to the device
with the maximum overlap in media capabilities, as desired.
Note that neither "require" nor "explicit" tags are used because
there is no intent to exclude contacts, only to order them.
3.9. Multilingual Lines
3.9.1. Desired Behavior
AOR Y represents a shared line in an office. Several employees in
the office have phones registered for Y. Some of the employees speak
only English, some speak Spanish fluently and have some limited
capability for English, and some speak both English and Spanish
fluently. Calls from callers that speak only English should be
parallel forked to all office workers that speak fluent English. If
the call isn’t picked up, then the phones of workers that speak
English marginally should be rung. Calls from callers that speak
only Spanish should be forked only to workers that speak Spanish.
3.9.2. Solution
A user at phone Y1 that speaks English only would generate a REGISTER
that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@pc.example.com>;languages="en"
A user at a phone Y2 that speaks Spanish and a little bit of English
would generate a REGISTER that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y2-es@pc2.example.com>;languages="es"
Contact: <sip:Y2-en@pc2.example.com>;languages="en";q=0.2
Y2 has registered two contacts. Both of them route to the same
device (pc2.example.com), but they differ in their language support
and relative q-values. Multiple contacts are needed whenever a UA
wishes to express differing preferences for being reached for
different feature collections.
A user at phone Y3 that speaks English and Spanish fluently would
generate a REGISTER that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y3@pc3.example.com>;languages="es,en"
Notice that only a single contact is needed because the same q-value
is applied across all feature collections.
For the language-based routing to occur, the caller must indicate its
language preferences explicitly:
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;languages="en";require
The predicate derived from this looks like:
(& (languages="en"))
This matches the one contact for Y1, the second contact registered
for Y2, and the one contact for Y3, all with a score of 1.0. The
first contact registered by Y2 does not match, and because of the
"require" flag, is discarded. The remaining contacts are sorted by
q-value and divided into equivalence classes. There are two
equivalence classes. The first contains Y1 and Y3 with a q-value of
1.0, and the second contains Y2-en with a q-value of 0.2. The
contacts in the first class are ordered by Qa. However, since all
contacts have the same value of Qa (1.0), there is no change in
ordering. Thus, Y1 and Y3 are tried first, followed by Y2-en. This
is the desired behavior.
An "explicit" tag is not used because that would cause the exclusion
of a contact that does not mention language.
A caller that speaks Spanish only would specify their preference
thusly:
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;languages="es";require
This matches the first contact of Y2 phones, and Y3 phones, all with
a score of 1.0. The English contact of Y2, Y2-en, doesn’t match and
is discarded because of the "require" flag. The remaining contacts
are sorted by q-values (Y3, Y2-es) and broken into a single
equivalence class containing both contacts. Since the Qa for both
contacts is the same (1.0) there is no reordering. The result is
that the call is routed to either Y3 or Y2-es.
3.10. I Hate Voicemail!
3.10.1. Desired Behavior
AOR Y has two contacts, a phone Y1 and a voicemail service Y2. X
wishes to call Y and talk in person. X does not want to be sent to
voicemail under any circumstances.
3.10.2. Solution
The phone would register with a Contact that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@pc.example.com>
;audio
;mobility="fixed"
and the voicemail server would register with a Contact that looks
like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y2@pc.example.com>
;msgserver
;automata
;attendant
;audio
;q=0.2
The voicemail server registers with a lower q-value so that it is
used only after the phone itself is rung. Note that the voicemail
server need not actually register. There can be a configured contact
and feature set defined for it instead.
A caller that wishes to avoid voicemail can include an explicit
preference to avoid it. A caller would do this with the Reject-
Contact header field:
INVITE sip:Y@example.com SIP/2.0
Reject-Contact: *;msgserver
Since this feature set contains a feature tag that is not contained
in the registration for Y1, the feature set is discarded when
examining Y1. However, the registration for Y2 contains all feature
tags listed in the feature set, and so the rule is considered. There
is a match, and therefore, Y2 is discarded. The result is that the
user is never routed to voicemail.
3.11. I Hate People!
3.11.1. Desired Behavior
The situation is similar to Section 3.10, except the caller wishes
only to leave a message, not actually speak to the person.
3.11.2. Solution
The caller would send an INVITE that looks like, in part:
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;msgserver;require;explicit
This caller preference matches both Y1 and Y2. Y1 matches, but with
a score of zero. Y2 matches with a score of 1. Since both the
"require" and "explicit" flags are set, Y1 is discarded. Therefore,
the call is routed to Y2, the voicemail server, as desired.
Because of the presence of the "require" and "explicit" tags, if
these preferences are used with a user that doesn’t have voicemail or
that fails to indicate it with a msgserver capability, the call will
fail completely with a 480 Temporarily Unavailable error, rather than
connect to the user.
3.12. Prefer Voicemail
3.12.1. Desired Behavior
The situation is similar to that of Section 3.10. However, the
caller prefers to leave a message. If voicemail is not available,
they are willing to talk to a person.
3.12.2. Solution
It had been hoped that RFC 3841 could provide a solution for this
case, but it does not, because doing so would require a re-ordering
of the callee contacts, which is not done. The caller may achieve
the intended effect by making two call attempts:
o First, make an attempt requiring voicemail, as described in
Section 3.11.
o If that fails with a 480 error, send an invitation with no Accept-
Contact or Reject-Contact headers.
3.13. Routing to an Executive
3.13.1. Desired Behavior
Y is the AOR of an executive. It has three contacts. Y1 is the
phone on the executive’s desk. Y2 is the phone on the desk of the
executive’s assistant. Y3 is the address of an auto-attendant system
that can answer general questions, route calls to other parties, etc.
By default, calls to Y should be directed to Y2, and if that fails,
to Y3. If Y3 doesn’t answer, then Y1 should ring.
3.13.2. Solution
This is primarily a called party feature and is best accomplished
with a CPL (Call Processing Language) script [5]. However, it can be
accomplished with caller preferences alone by properly setting the
q-values across the three devices. Assuming this coordination is
possible, here are the settings that would be made:
Y1 would generate a REGISTER that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@pc.example.com>;q=0.1
Y2 would generate a REGISTER that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y2@pc2.example.com>;attendant;q=1.0
Y3 would generate a REGISTER that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y3@pc3.example.com>;attendant;automata;q=0.5
Note that, in reality, the automated attendant would probably not use
REGISTER. Since the attendant would be used for every employee in
the company, a static contact would probably be added
administratively for each user in the enterprise. However, the
information in that static contact would be identical to the
information in the registration above.
When X makes a call to the executive, Y, and expresses no preference,
the proxy computes an implicit preference to support INVITE. All
three contacts match such a preference, even though they have not
indicated explicit support for INVITE. Thus, no contacts are
discarded. Since each contact has a different q-value, the caller
preferences do not cause any reordering. The result is that the call
is first routed to Y2, then Y3, then Y1, all as a result of the
proper setting of the q-values.
3.14. Speak to the Executive
3.14.1. Desired Behavior
This case is similar to that of Section 3.13, but this time the
caller, X, has a preference. X calls Y, but wants to speak directly
to the executive. X doesn’t want the call to ring either the
assistant or the auto attendant (automaton).
3.14.2. Solution
X’s INVITE would look like, in part:
INVITE sip:Y@example.com SIP/2.0
Reject-Contact: *;attendant
Reject-Contact: *;automata
Note that the caller uses two separate Reject-Contact header field
values, rather than a single one with two separate feature
parameters. The distinction is important. If X had to use a single
value with two parameters, a matching UA would need to declare that
it was BOTH an attendant and an automaton. If it only declared that
it was one of these, based on the matching rules in the caller
preferences specification, it would not be rejected.
The above request would result in the elimination of both Y2 and Y3
as contacts. The call would then be routed to Y1, as desired.
This case indicates why a CPL script, or some other programmed
version of the feature, is preferable. With caller preferences, a
caller can override the desired ring sequence and disturb the
executive without any kind of authorization. A proper version of
this service would simply not permit caller preferences to force the
call to go directly to the executive.
3.15. Mobile Phone Only
3.15.1. Desired Behavior
The situation is similar to that in Section 3.13. However, the
executive also has a mobile phone that they have registered. Caller
X knows that the owner of Y is traveling, and that an assistant is
covering the office phone. X wants to call Y and ring only the
mobile phone.
3.15.2. Solution
The mobile phone would generate a registration that looks like, in
part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y4@mobile.example.com>;mobility="mobile";q=0.1
The caller would express their preference by generating an INVITE
that looks like, in part:
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;mobility="mobile";require;explicit
All four contacts match. However, Y1 through Y3 match with a score
of zero. Y4 matches with a score of 1. Because of the "require" and
"explicit" tags, Y1 through Y3 are discarded, and only Y4 is used, as
desired.
Note that this only works if the mobile phone specifies the mobility
feature in its registration.
3.16. Simultaneous Languages
3.16.1. Desired Behavior
AOR Y is as in Section 3.9. Caller X, fluent in both English and
Spanish, has discovered that the company’s Spanish language
documentation is inconsistent with the English language documentation
and wants to discuss the differences between the two. So X wants to
speak with one of the workers that is fluent in both English and
Spanish.
3.16.2. Solution