One document matched: draft-ietf-bliss-ach-analysis-02.txt
Differences from draft-ietf-bliss-ach-analysis-01.txt
BLISS WG J. Elwell
Internet-Draft Siemens Enterprise Communications
Intended status: Informational GmbH & Co KG
Expires: November 25, 2008 May 24, 2008
An Analysis of Automatic Call Handling Implementation Issues in the
Session Initiation Protocol (SIP)
draft-ietf-bliss-ach-analysis-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 25, 2008.
Abstract
This discusses problems associated with automatic call handling (ACH)
when using the Session Initiation Protocol (SIP).
This work is being discussed on the bliss@ietf.org mailing list.
Elwell Expires November 25, 2008 [Page 1]
Internet-Draft Automatic Call Handling May 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Examples of ACH . . . . . . . . . . . . . . . . . . . . . . . 3
3. Known problem areas with ACH . . . . . . . . . . . . . . . . . 5
3.1. Conflict between proxy and UA . . . . . . . . . . . . . . 5
3.2. Conflict between UAs . . . . . . . . . . . . . . . . . . . 6
3.3. Obtaining information from UA for ACH at proxy . . . . . . 6
3.4. Informing the calling UA . . . . . . . . . . . . . . . . . 6
3.5. Scope of conditions . . . . . . . . . . . . . . . . . . . 7
3.6. Configuring the proxy . . . . . . . . . . . . . . . . . . 8
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Proxy versus UA . . . . . . . . . . . . . . . . . . . . . 9
4.2. Avoiding inconsistent configurations . . . . . . . . . . . 10
4.3. Enterprise and carrier environments . . . . . . . . . . . 10
5. Potential measures that could be taken . . . . . . . . . . . . 10
5.1. Conflict between proxy and UA . . . . . . . . . . . . . . 11
5.2. Conflict between UAs . . . . . . . . . . . . . . . . . . . 12
5.3. Obtaining information from UA for ACH at proxy . . . . . . 12
5.3.1. Reason for rejection . . . . . . . . . . . . . . . . . 13
5.3.2. Desired scope of rejection . . . . . . . . . . . . . . 13
5.3.3. Response codes . . . . . . . . . . . . . . . . . . . . 14
5.4. Informing the calling UA . . . . . . . . . . . . . . . . . 15
5.5. Scope of conditions . . . . . . . . . . . . . . . . . . . 15
5.6. Configuring the proxy . . . . . . . . . . . . . . . . . . 15
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security considerations . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
10. Informative References . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Elwell Expires November 25, 2008 [Page 2]
Internet-Draft Automatic Call Handling May 2008
1. Introduction
The Session Initiation Protocol (SIP) [RFC3261] establishes calls or
sessions for real-time communication between users. When a call is
targeted at a called user, often the call is subject to some
automatic treatment to determine whether to present the call to the
user or take some alternative action such as forwarding to voicemail.
Similarly, if some condition arises after presenting a call to the
called user but before answer, automatic treatment can lead to some
alternative action. Automatic treatment is in accordance with policy
determined in advance by the user or the user's organization. This
automatic treatment of incoming calls is referred to as automatic
call handling (ACH) in this document.
In order to encourage innovation, ACH is deliberately not specified
in RFC 3261 or in RFCs that specify extensions to SIP. However, the
flexibility that this affords has sometimes led to problems, where
different implementations have approached the issue in different
ways, leading to unexpected and often unwanted behavior when those
implementations are deployed together. This document analyses the
sources of problems with ACH.
A number of other Standards Development Organisations (SDO) (e.g.,
3GPP, ETSI) have specified specific features or "services" that
involve specific forms of ACH.
A survey was conducted prior to IETF70 to get a feeling for what are
common practices in this area. Although the number of responses was
disappointingly small (see results [1]), in some cases it did give a
clue as to the most common practices. In the remainder of this
document, this is referred to as "the survey".
2. Examples of ACH
ACH can occur prior to or instead of presenting an incoming call to a
called user or after presentation but before the called user answers
the call. The particular treatment applied to a call is generally
dependent on a number of factors, examples of which are as follows:
o Whether there are other registered contacts that can handle the
call (e.g., a registered audio UA for an audio call).
o Whether the user's UA (or UAs) is known to be busy on another
call.
o Whether the user has failed to answer the call within a given
number of seconds.
Elwell Expires November 25, 2008 [Page 3]
Internet-Draft Automatic Call Handling May 2008
o Whether the user is known to be unwilling to receive calls at the
present time (a condition often known as Do Not Disturb, DND).
o Whether the user is known not to be available (e.g., on vacation).
o Whether an alternative user (e.g., a colleague, an assistant,
another family member) is known to be available.
o Whether the AoR at which the call is targeted represents a single
user or a team or group of users.
o Time of day, day of the week, date, etc..
o The type of call (e.g., audio, audio plus video, messaging, etc.).
o The source of the call (e.g., whether the caller is anonymous,
whether the caller is blacklisted or whitelisted, which
organization the caller belongs to, etc.).
The conditions above are detected though local information at the
entity performing ACH, by access to presence information or through
information received via SIP signalling (e.g., a UA's response to an
INVITE request).
Examples of particular treatment to be applied to a call if
appropriate conditions are met are as follows:
o Reject the call, with an appropriate indication to the caller.
This indication may or may not reveal the actual condition that
led to rejection.
o Forward the call to another UA serving that user (e.g., voicemail,
a mobile UA, a UA at another location).
o Forward the call to another user, e.g., the next member of a team,
an assistant.
o Modify the nature of the call (e.g., downgrade from audio to
messaging).
o Any of the above, but impacting presentation of the call at a
given UA, without impacting presentation at other UAs serving the
user.
A user can specify quite complex sets of rules for ACH. For example,
"if presence indicates I am in a meeting, or if my desk phone is
busy, or if I do not reply within 15 seconds, forward calls to my
assistant between the hours of 09.00 and 17.00, Monday to Friday, but
Elwell Expires November 25, 2008 [Page 4]
Internet-Draft Automatic Call Handling May 2008
at other times forward to my voicemail, unless the call is from my
home or my partner's mobile phone, in which case forward to my mobile
phone".
3. Known problem areas with ACH
3.1. Conflict between proxy and UA
A significant problem area with ACH is interactions between proxies
(or B2BUAs) that perform ACH and UAs that perform ACH. The domain
proxy for a user is configured to treat incoming calls in a certain
way under certain conditions. One of the user's UAs is configured to
treat incoming calls in a different way under the same or overlapping
conditions. If the condition can be detected by the proxy without
presenting the call to the UA, the proxy will win and the user may
wonder why the action configured at the UA is not being taken. For
example, if the proxy detects a DND condition from a presence server
and forwards calls to voicemail, any script at the UA to forward
private calls to a mobile phone would never execute. This may or may
not be what the user (or his/her organization) desires to happen.
Alternatively, if a condition is detected by a UA before it is
detected at the proxy, the action determined by the UA will "win",
unless the proxy is somehow able to figure out what has happened and
apply its own action. For example, if a phone determines it is busy
and returns a 302 response code to forward the call elsewhere or
performs "call waiting" action, this might prevent the proxy taking
whatever action it would have taken on receipt of a 486 response.
This may or may not be what the user (or his/her organization)
desires to happen.
If a UA attempts ACH, it may be possible for proxy to override it,
e.g., by taking account of the response code returned or, in the case
of a 3xx response code, whether the UA has provided further
information concerning the reason for redirection in accordance with
RFC 4458 [RFC4458].
The survey showed that the majority of proxies perform ACH without
first presenting the call to the UA, at least for certain types of
ACH.
The survey also showed that the majority of UAs implement some form
of UA. This does seem to confirm the potential for conflict between
proxy and UA. If, as a result of ACH, the call required redirection,
302 was the response code used in the majority of situations. Only a
minority of such implementations used RFC 4458 to provide more
information about the reason for redirection.
Elwell Expires November 25, 2008 [Page 5]
Internet-Draft Automatic Call Handling May 2008
3.2. Conflict between UAs
Where an incoming call is forked to multiple UAs, there is potential
for different UAs to be configured to perform different actions under
the same or overlapping conditions. With parallel forking (where the
INVITE request is sent to each UA at approximately the same time),
results can be indeterminate and might depend on which UA responds
first. With serial forking, this is likely to be more deterministic,
but UAs would need to be configured taking into account the order in
which the proxy presents calls to the UAs.
When a proxy forks a call, it can invoke ACH based on the first UA to
respond, can wait for all UAs to respond or behave in some other way
(e.g., act immediately on certain response codes). The survey did
not show a bias towards any one behavior.
3.3. Obtaining information from UA for ACH at proxy
When ACH is performed at a proxy, it sometimes requires information
from the UA, in response to the INVITE request. If this information
does not arrive in the form expected by the proxy (e.g, a particular
response code), ACH will be adversely impacted. For example, if the
proxy is configured to perform forwarding on DND and relies on the
DND condition to be indicated in the INVITE response, it depends on
the UA indicating the condition in the form expected by the proxy.
As there is no standardized means of indicating DND in a response
(see [I-D.elwell-bliss-dnd]), this can be a problem. Furthermore,
there might be more than one flavour of DND (e.g., with/without
forwarding to voicemail), requiring different responses.
The survey showed that 486 (Busy Here) is the response code most
commonly expected by proxies for indicating DND, but that accounted
for less than half of the responses. Other known response codes in
use include 406 (Not Accepetable), 480 (Temporarily Unavailable), 600
(Busy Everywhere) and 603 (Decline).
The survey also showed that even for the busy condition, proxies
expected different response codes. Although a small majority
expected 486 (Busy Here), other expectations included 480
(Temporarily Unavailable) and 600 (Busy Everywhere).
The survey did not yield significant information concerning response
codes issued by UAs.
3.4. Informing the calling UA
A related problem is informing the calling UA, and hence the caller,
what has happened. In the case where ACH results in rejection of the
Elwell Expires November 25, 2008 [Page 6]
Internet-Draft Automatic Call Handling May 2008
call, this might be just a case of sending back an appropriate
response code. Considerations are similar to those for a proxy in
Section 3.3, except that privacy might require the proxy to send a
different response code rather than the one reflecting the condition
encountered. For example, the user might not wish the caller to know
about his absence.
The choice of response code might not be an interoperability issue if
the calling UA is relatively dumb, but might be an issue if there is
an application that takes the response code into account. Where
there is forking proxy between the entity performing ACH and the
calling UA, information may be lost because of the Heterogeneous
Error Response Forking Problem (HERFP).
Where ACH results in forwarding (to a different AoR or a different
contact for the same AoR), this can be achieved by retargeting or
redirection. In the case of retargeting, the calling UA receives no
information, apart from a final response and perhaps identity from
the retargeted-to user. On the other hand, if redirection is used,
the calling UA will receive a 3xx response, the contact URI in which
could indicate the source of the redirection and the reason, in
accordance with [RFC4458].
3.5. Scope of conditions
When an INVITE request is forked to multiple UAs, the user may or may
not require a condition at one UA to be considered as applying to
other branches. This includes branches already active (through
parallel forking) or branches yet to be activated (through serial
forking). This can impact when to invoke ACH at the proxy, i.e.,
whether to perform ACH when one UA reports an appropriate condition
(cancelling other active branches if necessary) or to wait for the
outcome on other branches.
Although to a large extent this issue can be handled by appropriate
scripting at the proxy, an important consideration is how to treat
the 6xx class of responses. For example, if a UA issues a 600 Busy
Everywhere response (as opposed to a 486 Busy response), what is the
scope of "everywhere"? A simple interpretation is that it literally
means "everywhere", and all other branches should be abandoned and
the 6xx response passed back to the caller if no other ACH is
prescribed for this condition. However, this interpretation is not
always reasonable. If a user has several phones, it might be
reasonable to interpret a 600 response from one phone as meaning that
all other phones are busy, but if the user also has voicemail it is
unlikely that that too should be treated as busy. Also, if ACH
requires forwarding to a different user (different AoR) on busy, it
might be expected that this would take place even on receipt of a 600
Elwell Expires November 25, 2008 [Page 7]
Internet-Draft Automatic Call Handling May 2008
response from a UA.
Another example is the 603 Decline response code. This is often is
intended to be applied everywhere.
There is also a question of whether a proxy should trust a UA to
decide that all other branches need to be abandoned, particularly in
applications like call centres, where the different branches might be
different agents, rather than leading to different devices belonging
to the same user. It might wise to consider this a policy matter.
The survey gave only a very small number of answers on the issue of
handling 6xx responses, with no conclusions to be drawn other than
that forwarding to voice mail is sometimes allowed following a 6xx
response.
3.6. Configuring the proxy
If ACH is performed at the proxy, the user needs a means to configure
the proxy with the required rules. There is no SIP means of doing
this, but a number of mechanisms can perform the basis for this task,
e.g.:
o Via a web page.
o By uploading a CPL [RFC3880] script.
o Via a web services interface based on SOAP.
o Via Computer Supported Telecommunication Applications (CSTA)
[CSTA].
o Via XCAP [RFC4825]
The survey showed that web pages and SOAP-based web services were the
most common mechanisms supported by proxies, but the sample was very
small. The majority of UA implementations provided a web user
interface.
Without a single standardized way of configuring a proxy, there is a
danger that the UA and proxy might not support a common method,
requiring the user to employ other means (e.g., using a different
device, contacting a support centre). Furthermore, it might lead the
user to configuring ACH at the UA when in practice ACH at the proxy
would serve the user's needs better.
Related to this is the means by which a UA (and hence the user) can
discover how the proxy is configured. Most of the mechanisms listed
Elwell Expires November 25, 2008 [Page 8]
Internet-Draft Automatic Call Handling May 2008
above are applicable, and also a SIP SUBSCRIBE/NOTIFY mechanism could
be used. The survey indicated that only a minority of proxies
provided support in this respect.
4. Discussion
4.1. Proxy versus UA
The end-to-end principle of SIP would suggest that ACH at the UA is
more appropriate than ACH at the proxy. However, certain
considerations make ACH at the proxy more viable or even essential.
ACH in the event that there is no registered contact obviously can
only be performed by the proxy.
A proxy is more easily able to take account of the state of other
UAs, e.g., by waiting for all branches of a forked call to respond
before invoking ACH. Although a UA can use techniques such as the
registration event package [RFC3680] in combination with the dialog
event package [RFC4235] to determine the state of other UAs, this is
complex, may not yield the information required, and may suffer from
timing-related inconsistencies.
A proxy needs to be configured once and can perform ACH independently
of the number of UAs involved. Obtaining consistent behaviour using
ACH at the UA may involve configuring multiple UAs and keeping their
configurations aligned. The UA configuration framework
[I-D.ietf-sipping-config-framework] may be a suitable mechanism for
this and would require a means for the user to configure the profile
delivery server. However, there can be no guarantee that all UAs
will download a revised configuration at the same time, so it can
lead to a time window when inconsistent behaviour may occur.
With these considerations in mind, a proxy will often turn out to be
a more suitable place for performing ACH.
On the other hand, there may be situations in which UA-specific ACH
may be required, and it may not be feasible to configure the proxy to
provide this level of granularity. For example, it may be required
to take one action if the desk UA is busy but a different action if
the mobile UA is busy. Convincing use cases for this are hard to
find, but it cannot be ruled out. A possible approach here is to use
proxy-based ACH as the default handling for all UAs and UA-based ACH
for any UA-specific exceptions.
Elwell Expires November 25, 2008 [Page 9]
Internet-Draft Automatic Call Handling May 2008
4.2. Avoiding inconsistent configurations
Given that there is frequently a need to perform ACH at the proxy,
problems can be avoided by turning off ACH at all UAs. There may be
exceptions to this, e.g., where there is need for a specific UA to
perform actions different from default actions carried out by the
proxy, or where there is a requirement for behavior not supported by
the proxy. Where ACH does need to be configured at one or more UAs,
care must be taken to avoid unintentional conflicts. Use of the SIP
configuration framework can help to ensure consistent handling at all
UAs. One consideration during the work on profiles for use with the
SIP configuration framework might be the downloading of policy
relating to ACH, such that ACH could be suppressed in order to ensure
that proxy-based ACH operates correctly.
4.3. Enterprise and carrier environments
Considerations for ACH will often differ between enterprise and
carrier environments. In enterprise environments, enterprise policy
will often govern what a user can and cannot do. This does not
necessarily mean that ACH will be done at a proxy, because the
enterprise will probably manage UAs too and ensure that they behave
in line with policy, although proxy-based ACH will often be easier to
accomplish.
In a carrier environment, everything can be expected to be under the
control of the user. Proxy-based ACH is still relevant, however,
particularly for mobile devices that are often out of reach or turned
off.
Handling such as team calls (where any team member can be selected
according to availability) is perhaps more likely in enterprise,
although in a residential environment it could be used for finding
any family member.
Despite these different considerations, requirements are similar to a
large extent and the same solution should be sought for both
environments.
5. Potential measures that could be taken
In this section we explore potential measures that can be taken to
some of the problems identified above
Elwell Expires November 25, 2008 [Page 10]
Internet-Draft Automatic Call Handling May 2008
5.1. Conflict between proxy and UA
This appears to be an important problem to solve, in order to have
proxies and UAs from mixed vendors.
One approach is to specify that particular features that must or must
not be implemented in a proxy and particular features that must or
must not be implemented in UA. This is likely to fail for a number
of reasons:
o There are far too many possible features, and enumerating and
standardizing individual features is contrary to the philosophy of
SIP and likely to inhibit innovation.
o For a given feature, there will be some deployments where it makes
sense to do it at the proxy and other deployments where it makes
sense to do it at the UA. It will often be impracticable to
choose one.
o Proxy vendors and UA vendors will want to provide as many features
as possible on their products and are likely to ignore any
recommendation not to implement a particular feature.
Stipulating that ACH as a whole must always be done at the proxy or
must always be done at the UA is clearly out of the question, because
each has some advantages, depending on circumstances, and also
because vendors of one or the other will not be prepared to give up
producing features that play an important part in differentiating
their products.
Therefore it has to be accepted that ACH will be implemented on
proxies and UAs, with feature overlap between the two. The challenge
then is to ensure that, when deployed, the two can co-exist in a
sensible way.
It should be possible to control whether a proxy defers to a UA or
vice versa. For a proxy to defer to a UA, it requires the proxy to
deliver an INVITE request to a UA before taking any ACH action.
Depending on the response of the UA, the proxy may then perform its
own ACH action. For a UA to defer to a proxy, it should report any
conditions back to the proxy (e.g., by means of a suitable response
to the INVITE request) rather than taking unilateral action such as
redirecting or placing the call in a waiting state. In other words,
it should be possible to turn off ACH at a UA.
There are several ways to achieve this control:
Elwell Expires November 25, 2008 [Page 11]
Internet-Draft Automatic Call Handling May 2008
o Configure the UA and proxy independently. The SIP configuration
framework [I-D.ietf-sipping-config-framework] could be used to
configure the UA.
o Configure the UA (e.g., by means of the SIP configuration
framework [I-D.ietf-sipping-config-framework]) and use SIP to
instruct the proxy (e.g., by means of an indicator in REGISTER
requests).
o Configure the proxy and use SIP to instruct the UA (e.g., by means
of an indicator in inbound INVITE requests or in the 200 response
to a REGISTER request).
The configuration approach is the simplest and does not require any
enhancements to the SIP protocol. A simple configurable indicator at
the UA whether to defer to the proxy or not would suffice. This
would be in addition to normal proxy configuration for ACH (see also
section Section 5.6) and/or normal UA configuration for ACH. The
VOIP features dataset [I-D.petrie-sipping-voip-features-dataset-02]
should be enhanced to include this parameter. Use of this profile
and/or use of the SIP configuration framework
[I-D.ietf-sipping-config-framework] are possible ways in which the
indicator can be configured.
OPEN ISSUE: Should there be just one indicator or several indicators
(e.g., don't use 302, don't use call waiting)?
5.2. Conflict between UAs
This can really only be addressed by configuration. The SIP
configuration framework can help here. In fact, that would normally
configure all UAs having the same AoR with the same information.
Configuration outside this framework (e.g., local actions at the
device) might introduce differences (intentional or otherwise).
There seems little action that BLISS can take to address this issue.
5.3. Obtaining information from UA for ACH at proxy
There seems to be a case for more precisely defining or at least
recommending information given to the proxy when rejecting an inbound
call, in order to assist the proxy in providing the most relevant
ACH, if any. Ideally this information needs to be given as a SIP
response code, although potentially a response code could be
supplemented by a header field. In choosing a particular response
code, two factors need to be taken into account:
o the reason for rejection;
Elwell Expires November 25, 2008 [Page 12]
Internet-Draft Automatic Call Handling May 2008
o the desired scope of rejection.
5.3.1. Reason for rejection
The most relevant reasons for rejection (from an ACH perspective) are
as follows:
o Busy. UA resources are busy as a result of another call and
further calls cannot be accepted until resources become free. The
condition may also be visible via a presence system.
o Explicit rejection. The user has indicated an unwillingness to
accept the call at the present time. The user may have indicated
this in advance, so that any incoming calls (or those fulfilling
certain conditions) would be rejected in this way (a feature often
known as "do not disturb"). The user may impose such a condition
during a meeting or while working on a critical task. The user
may indicate in advance a time at which she expects the condition
to be lifted. The condition may also be visible via a presence
system. Alternatively the user may indicate an unwillingness to
accept a particular call in response to being alerted.
o Silent rejection. The user has responded to this call by
rejecting it, but does not wish the reason to be revealed to the
caller. A user would use this facility when not currently in a
position to answer a particular call or when she feels that it
would be better handled elsewhere (e.g., by voicemail, by an
assistant).
Note that silent rejection could also be achieved by returning a 180
response to the INVITE request, and then waiting (without alerting
the user) until the call is cleared or times out. In the meantime,
the proxy would be unaware of what is happening and would be unable
to take other action, such as cancelling other branches. On the
other hand, indicating silent rejection relies on the proxy to take
alternative ACH action (e.g., waiting for a certain time before
forwarding to voice mail or reporting to the caller that the call has
timed out), rather than revealing silent rejection to the caller.
Therefore silent rejection is suitable for use only when it is known
that the proxy will take appropriate action.
5.3.2. Desired scope of rejection
When rejecting a call the user (or the UA on the user's behalf) may
desire the rejection to have one of the following scopes:
o Local. Rejection impacts only the branch concerned or any
branches to the user's other devices. Forwarding to voicemail or
Elwell Expires November 25, 2008 [Page 13]
Internet-Draft Automatic Call Handling May 2008
to an assistant, for example, is not prevented and may be
instigated by the proxy as a result of receiving a local
rejection.
o Global. Rejection impacts all branches, including voicemail.
It is a matter for the proxy to determine what ACH to perform for a
local rejection or a global rejection (although this may be based on
per-user settings, which the user may have some control over, e.g.,
via a web page, see Section 5.6). For local rejection the proxy
might, for example, cancel other branches (to the user's other
devices) and forward immediately to voicemail or to an assistant. On
the other hand it may leave other branches unaffected. For global
rejection the proxy might reject the call outright, cancelling all
other branches, although policy might require a less severe action to
be taken. For example, in a call centre there might be a requirement
that all calls be answered.
5.3.3. Response codes
4xx response codes are appropriate for local rejection and 6xx
response codes are appropriate for global rejection.
The following response codes are recommended for local rejection:
o Busy/local. 486 should be used. As indicated in RFC 3261, this
can be accompanied by a Retry-After header field to indicate when
the user expects to be available again.
o Explicit rejection/local. 480 could be used. As indicated in RFC
3261, this can be accompanied by a Retry-After header field to
indicate when the user expects to be available again. OPEN ISSUE.
There is some concern about the overloaded use of this response
code. For example, if a domain proxy receives a 480, is it from
the UAS (indicating DND) or is it from an edge proxy (indicating
temporary lack of resources.
o Silent rejection/local. 487 could be used. This is the same
response code that would be used if a proxy were to issue a CANCEL
request.
The following response codes are recommended for global rejection:
o Busy/global. 600 should be used. As indicated in RFC 3261, this
can be accompanied by a Retry-After header field to indicate when
the user expects to be available again.
Elwell Expires November 25, 2008 [Page 14]
Internet-Draft Automatic Call Handling May 2008
o Explicit rejection/global. 603 should be used. As indicated in
RFC 3261, this can be accompanied by a Retry-After header field to
indicate when the user expects to be available again.
o Silent rejection/global. No code recommended.
OPEN ISSUE. No code is recommended for silent rejection/global. It
is not clear what is the use case for this. One possible use case,
however, is for dealing with SPIT, where the user can tell (e.g.,
from caller ID) that the call is unwanted and does not wish the call
to go to voicemail even. In this case, other issues arise, such as
indicating the SPIT status to an entity responsible for handling
SPIT. This would come under the remit of the RUCUS activity.
5.4. Informing the calling UA
Whilst this might be interesting, it is unlikely to impact
interoperability and is not seen as a priority issue for BLISS.
5.5. Scope of conditions
There seems to be a case for specifying the intended scope of 6xx
response codes. Ideally this should be a single specification for
the entire class, although we may find that individual members of the
class require special consideration. Probably a 6xx response code
should apply only to other contacts registered for that same AoR, and
should probably also exclude special contacts such as voice mail
systems. At present a [RFC3840] defines a feature tag to indicate
that a UA is an automaton, and another to indicate that it supports
audio. Consideration should be given as to whether these are
sufficient to determine that a UA is a voicemail server.
In view of existing practice, where 6xx response codes are generally
meant to apply to all branches and to override forwarding, it is
seems safest to stick with this meaning. If this is not the desired
behaviour when a particular condition arises at the UA (e.g., if
forwarding to voicemail is desired), a 4xx response code should be
used instead. The proposals in Section 5.3 take this into account.
5.6. Configuring the proxy
General methods for configuring proxies (including synchronization of
multiple proxies serving a domain) are considered outside the scope
of BLISS work.
There may be justification for studying methods by which a user or UA
can discover and possibly change the configuration of the proxy as
far as ACH is concerned. Often a user can do this by means such as
Elwell Expires November 25, 2008 [Page 15]
Internet-Draft Automatic Call Handling May 2008
web pages. Such methods are not suitable for the UA.
OPEN ISSUE: Input needed on this topic.
6. Conclusions
TODO: populate this section
7. IANA considerations
None.
8. Security considerations
This document just discusses interoperability issues relating to ACH.
It does not define any new protocol or practices and therefore does
not introduce any security issues, other than the possible user
desire not to disclose ACH actions to callers.
9. Acknowledgements
The author would like to acknowledge the assistance of Francois
Audet, Martin Dolly, Jason Fischl, Shida Schubert and Srivatsa
Srinivasan in writing this draft, and also input on specific
implementations from various members of the BLISS WG.
10. Informative References
[RFC3261] 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.
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3880] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing
Language (CPL): A Language for User Control of Internet
Telephony Services", RFC 3880, October 2004.
Elwell Expires November 25, 2008 [Page 16]
Internet-Draft Automatic Call Handling May 2008
[RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
Initiated Dialog Event Package for the Session Initiation
Protocol (SIP)", RFC 4235, November 2005.
[RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session
Initiation Protocol (SIP) URIs for Applications such as
Voicemail and Interactive Voice Response (IVR)", RFC 4458,
April 2006.
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[I-D.elwell-bliss-dnd]
Elwell, J. and S. Srinivasan, "An Analysis of Do Not
Disturb (DND) Implementations in the Session Initiation
Protocol (SIP)", draft-elwell-bliss-dnd-01 (work in
progress), November 2007.
[I-D.ietf-sipping-config-framework]
Channabasappa, S., "A Framework for Session Initiation
Protocol User Agent Profile Delivery",
draft-ietf-sipping-config-framework-15 (work in progress),
February 2008.
[I-D.petrie-sipping-voip-features-dataset-02]
Petrie, D., "The Session Initiation Protocol User Agent
VoIP Features Data Set".
[CSTA] "International Standard ISO/IEC 18051 "Information
Technology - Telecommunications and information exchange
between systems - Services for Computer Supported
Telecommunications Applications (CSTA) Phase III"".
[1] <http://www.bliss-ietf.org/ach_survey.html>
Author's Address
John Elwell
Siemens Enterprise Communications GmbH & Co KG
Hofmannstrasse 51
D-81379 Munich
Germany
Phone: +44 115 943 4989
Email: john.elwell@siemens.com
Elwell Expires November 25, 2008 [Page 17]
Internet-Draft Automatic Call Handling May 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Elwell Expires November 25, 2008 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-24 08:28:20 |