[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]
Versions: (draft-poetzl-bliss-call-completion)
00 01 02 03 04 05 06 07 08 09 10 11
12 13 14 15 16 17 18 19 RFC 6910
bliss D. Worley
Internet-Draft Pingtel Corp.
Intended status: Standards Track M. Huelsemann
Expires: December 19, 2008 D. Alexeitsev
Deutsche Telekom
June 17, 2008
Call Completion for Session Initiation Protocol (SIP)
draft-ietf-bliss-call-completion-02
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 December 19, 2008.
Abstract
The features "call completion on busy subscriber" and "call
completion on no reply" allow the calling party of a failed call to
be notified when the called party becomes available to receive a
call. This document describes an architecture for implementing these
features in the Session Initiation Protocol: "Call completion"
implementations at the caller's and callee's endpoints cooperate to
place the caller's request for call completion into a queue at the
callee's endpoint, and, when a caller's request is ready to be
serviced, re-attempt the original, failed call.
Worley, et al. Expires December 19, 2008 [Page 1]
Internet-Draft Call Completion June 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements terminology . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Differences from SS . . . . . . . . . . . . . . . . . . . 6
5. Detailed Description of the Call-Completion Mechanism . . . . 7
5.1. Caller's Call-Completion Agent . . . . . . . . . . . . . . 8
5.2. Callee's Call-Completion Monitor . . . . . . . . . . . . . 9
5.3. The Original Call Is Made . . . . . . . . . . . . . . . . 10
5.4. Call-Completion Is Activated . . . . . . . . . . . . . . . 10
5.5. The Call-Completion Request Is Queued . . . . . . . . . . 12
5.6. Call-Completion Is Invoked . . . . . . . . . . . . . . . . 12
5.7. The caller is busy on receipt of the CC recall . . . . . . 13
5.8. Data Provided in the Call-Completion Event Package . . . . 14
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Call Completion Event Package . . . . . . . . . . . . . . . . 19
7.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 19
7.2. Event Package Parameters . . . . . . . . . . . . . . . . . 19
7.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 19
7.4. Subscribe Duration . . . . . . . . . . . . . . . . . . . . 20
7.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 20
7.6. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 21
7.7. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 21
7.8. Notifier Generation of NOTIFY Requests . . . . . . . . . . 22
7.9. Subscriber Processing of NOTIFY Requests . . . . . . . . . 22
7.10. Handling of Forked Requests . . . . . . . . . . . . . . . 22
7.11. Rate of Notifications . . . . . . . . . . . . . . . . . . 23
7.12. State Agents . . . . . . . . . . . . . . . . . . . . . . . 23
8. Call-completion information format . . . . . . . . . . . . . . 23
8.1. call-completion-state . . . . . . . . . . . . . . . . . . 24
8.2. service-retention . . . . . . . . . . . . . . . . . . . . 24
8.3. cc-URI . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
12. Normative References . . . . . . . . . . . . . . . . . . . . . 25
Appendix A. Example Caller's Agent . . . . . . . . . . . . . . . 26
Appendix B. Example Callee's Monitor . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 28
Worley, et al. Expires December 19, 2008 [Page 2]
Internet-Draft Call Completion June 2008
1. Introduction
The call-completion architecture is an end-to-end design driven by
the interactions between two types of agents, a "caller's agent"
which operates on behalf of the original caller, and a "callee's
monitor", which operates on behalf of the original callee. The two
agents are associated with the two UAs, though they may be provided
as services by the endpoints' home proxies or other network elements.
Though it is expected that a UA that "implements call completion"
will have both types of agents so that it can participate in call
completion as both caller and callee, the two agents are independent
of each other.
In order to allow flexibility and innovation, most of the interaction
between the caller's agent and the caller-user(s) and the caller's
UA(s) is out of the scope of this document.
Similarly, most of the interaction between the callee's monitor and
the callee-user(s) and the callee's UA(s) is out of the scope of this
document, as is also the policy by which the callee's monitor
arbitrates between multiple call-completion requests.
As a proof-of-concept, simple agents and monitors can be devised that
interact with users and UAs entirely through standard SIP mechanisms
[RFC3265], [RFC4235] and [RFC3515], as described in the Appendixes.
2. Requirements terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
This document uses terms from [RFC3261].
3. Terminology
For the purpose of this service, we provide the following
terminologies:
CC, or call completion: a service which allows a call which failed to
reach a desired destination user to be automatically retried at a
later time when the destination appears to be available. Martin: we
should avoid the expression 'retry' because it's not a trying, but a
notification when it's possible to recall. Therefore for me the
description from the abstract seems to be more appropriate: to be
notified when the called party becomes available to receive a call.
Worley, et al. Expires December 19, 2008 [Page 3]
Internet-Draft Call Completion June 2008
CC indicator: the data in responses to the INVITE of the original
call which indicate that CC is available for this call.
CC request: (1) the indication by the caller to the caller's agent
that the caller desires CC for a failed original call, (2) the
indication transmitted from the caller's agent to the callee's
monitor of the desire for CC processing, (3) the entry in the
callee's monitor queue representing the original call and the
caller's request for CC processing. Martin: At least for 1) and 2)
there may be a need for a differentiation in future. Perhaps we
should use differnet terms: 1) request 2) subscription 3) entry ?
Other suggestions?
CCBS, or Completion of Calls to Busy Subscriber: CC service when the
initial failure was that the destination UA was busy.
CCNR, or Completion of Calls on No Reply: a CC service when the
initial failure was that the destination UA was not answered.
CCBS/CCNR service duration timer, or CC service duration timer:
maximum time a CC request may remain active within the network.
CC call: a call from the caller to the callee, triggered by the CC
service when it determines that the callee is available.
CC recall: (1) the action of the callee's monitor selecting a
particular CC request as one that should initiate a CC call, (2) the
indication from the caller's agent to the caller that it is now
possible to initiate a CC call, (3) the indication by the caller to
initiate a CC call. Martin: IMO 3) belongs more to the CC call.
CC recall events: Event notifications of event package "call-
completion", sent by the callee's monitor to the caller's agent to
inform it of the status of its CC request.
Call-completion queue: a buffer at the callee' monitor which stores
incoming calls which have failed or may have failed. Note: This
buffer may or may not be organized as a queue. The use of the term
"queue" is by analogy with SS7 usage.
Caller, calling user, originator, or call-completion user: the
initiator of the original call and the CC request. The user on whose
behalf the call-completion call is made.
Callee, called user, destination, or call-completion target: a
destination of the original call, and a target of the call-completion
call.
Worley, et al. Expires December 19, 2008 [Page 4]
Internet-Draft Call Completion June 2008
Callee's monitor, or monitor: a component which implements the call-
completion queue for destination user(s)/UA(s), and performs the
associated tasks, including sending CC recall events, analogous to
the destination local exchange's role in SS7 CC.
Caller's agent, or agent: a component which makes CC requests and
responds to CC recall events on behalf of originating user(s)/UA(s),
analogous to the originating local exchange's role in SS7 CC.
Original call: the initial call which failed to reach a desired
destination.
Suspended CC request: a CC request which is temporarily not to be
selected for CC recall.
Retain option: a characteristic of the call-completion service; if
supported, call-completion calls which again encounter a busy callee
will not be queued again, but the position of the caller's entry in
the queue is retained.
4. Overview
4.1. General
The call-completion architecture augments each caller's UA (or UAC)
which wishes to be able to use the call-completion features with with
a "call-completion agent" (also written as "CC agent", "agent", or
"caller's agent"). It augments each callee's UA (or UAS) which
wishes to be able to be the target of the call-completion features
with a "call-completion monitor" (also written as "CC monitor",
"monitor", or "callee's monitor"). The agent and monitor functions
can be integrated into the respective UAs, be independent end-
systems, or be provided by a centralized application server.
In order to request call-completion, the caller's agent subscribes to
the call-completion event package (as defined in chapter 6) of the
callee's monitor. This subscription is used to coordinate with the
monitor (and indirectly with other caller's agents and other callee's
monitors) to implement the call-completion features.
When the caller's UA makes a call to a callee that fails (e.g.,
because the callee was busy or the callee did not answer), and the
caller wishes to use CC to contact the callee later, the caller
instructs the caller's agent to activate the CC feature.
The caller's agent sends a SUBSCRIBE request for the call-completion
event package to the original destination URI of the call. This
Worley, et al. Expires December 19, 2008 [Page 5]
Internet-Draft Call Completion June 2008
SUBSCRIBE reaches the callee's monitor. The callee's monitor uses
the existence of the subscription to know that the caller is
interested in using the CC feature in regard to the specified
original call. The monitor keeps a list or queue of failed calls to
the callee, and of the caller's agent's subscriptions, which indicate
the callers that are waiting to use the CC features.
When the callee's monitor judges that the callee and/or callee's UA
is available for call-completion, the callee's monitor selects
(usually) one request to be the next caller to execute call-
completion to the callee. The callee's monitor sends a call-
completion event update to the selected caller's agent's
subscription, telling it to begin execution of call-completion.
When the caller's agent receives this update, it calls the caller's
UA or otherwise tests whether the caller is available to take
advantage of call-completion. If the caller is available, the agent
directs the caller's UA to make again the call to the callee. This
call is identified as a call-completion call so it can be given
precedence in reaching the callee's UA.
If the caller is not available on the receipt of the ready for recall
notification, the CC agent suspends the CC request at the CC monitor.
The CC agent resumes the CC request once the caller becomes available
for CC again. On the receipt of the suspension from the top CC agent
in the queue, the CC monitor shall perform the callee monitoring for
the next not suspended CC agent in the queue. On the receipt of the
resume from the previously suspended top CC agent in the queue the CC
monitor shall perform the callee monitoring for this top CC agent.
When the call completion call fails there are two possible options:
the CC feature has to be activated again, or CC remains activated and
the original CC request retains its position in the queue, possibly
with the possibility to update the subscription.
4.2. Differences from SS
SIP call completion differs in some ways from the CCBS and CCNR
features of SS7 (which is used in the PSTN). For ease of
understanding, we enumerate some of the differences here.
SIP call completion does not fundamentally distinguish "call
completion on no reply" (CCNR) from "call completion on busy
subscriber" (CCBS), because the network does not need to make a
distinction, and given the potential complexity of SIP routing,
agents in the network may not be able to. However, SIP call
completion operations MAY carry an 'm' parameter to label call
completion actions as to the original cause of the failure.
Worley, et al. Expires December 19, 2008 [Page 6]
Internet-Draft Call Completion June 2008
Currently, the only defined values are "BS" and "NR". Other values
may be defined in the future, and SIP call completion operations
should succeed even if the 'm' parameter is omitted. However, in
these latter cases, interoperation with SS7 is likely to be impaired.
Due to the complex forking situations that are possible in SIP, a
call may "fail" from the point of view of the user and yet have a
"success" response from SIP's point of view. (This can happen even
in simple situations: e.g., a call to a busy user that fails over to
his voicemail receives a SIP success response, even though the caller
may consider it "busy subscriber".) Thus, the calling user must be
able to invoke call completion even when the original call appeared
to succeed. To support this, the caller's agent (and to a lesser
degree the callee's monitor) must record successful calls as well as
unsuccessful calls.
In SIP, only the caller's UA or service and the callee's UA or
service needs specifically to support call completion in order that
call completion work successfully between the UAs. Intermediate SIP
systems (proxies or B2BUAs) do not need specifically to implement
call completion; they only need to be transparent to the usual range
of SIP messages.
JRE: How does "caller's UA or service" relate to "caller's agent",
and how does "callee's UA or service" relate to "callee's monitor"?
Dale: The caller's UA or the caller's service implements the caller's
agent. Similar for the callee. What I was trying to emphasize is
that while the caller's and callee's "end" of the service path must
explicitly implement CC, any transit networks in between do not.
MH: Is it possible to express this with something like 'instances on
the originating resp. terminating side', in difference to
'intermediate instances'? Otherwise I think we have to explain the
term 'service' more deeply.
Due to flexibility needed to support legacy systems that are not
optimized to support call completion, there are a larger number of
situations in SIP where call completion services are offered but
eventually cannot be successfully executed.
5. Detailed Description of the Call-Completion Mechanism
Note: Many of the actions of call completion can be taken with the
actor possessing greater or lesser information about the particular
situation, depending on the specific messages involved. This
complexity is due to a number of factors: the complexities of SIP
Worley, et al. Expires December 19, 2008 [Page 7]
Internet-Draft Call Completion June 2008
forking, interoperation with other networks (specifically SS7), the
availability and use of optional SIP features to assist CC, and any
future enhancements of CC (either in SIP or SS7). Thus, in some of
the following descriptions, several alternative actions are presented
based on the information that the actor possesses. CC
implementations MUST properly choose between the described
alternatives, and MAY augment those alternatives based on any
additional information they possess.
5.1. Caller's Call-Completion Agent
The call-completion architecture augments each caller's UA (or UAC)
which wishes to be able to use the call-completion features with a
"call-completion agent".
An agent may be an integrated part of the UA, a separate end-system,
integrated with a proxy serving the UA, or a function of an
application server that provides these services to many UAs.
An agent may service more than one UA as a collective group if it is
common that a caller or population of users will be shared between
the UAs, and especially if the UAs share an AOR.
The caller's agent must be capable of performing a number of
functions relative to the UA(s). The method by which it does so is
outside the scope of this document, but an example method is
described in appendix A.
The agent monitors calls made from the UA(s) in order to determine
their destinations and (potentially) their final response statuses,
and the Call-Info headers of final responses and any HERFP
provisional responses.
The callers using the UA(s) can indicate to the agent when they wish
to avail themselves of CC for a recently-made call which failed to
reach their chosen destination.
The agent monitors the status of the UA(s) to determine when they are
available to be used for a CC call.
The agent can communicate to the UA(s) that CC recall is in progress
and to inquire if the relevant calling user is available for the CC
call.
The agent can order the UA(s) at which the relevant calling user is
available to generate a CC call to the callee.
Worley, et al. Expires December 19, 2008 [Page 8]
Internet-Draft Call Completion June 2008
5.2. Callee's Call-Completion Monitor
The call-completion architecture augments each callee's UA (or UAS)
which wishes to be able to be the target of the call-completion
features with a "call-completion monitor".
A monitor may be an integrated part of the UA, a separate end-system,
integrated with a proxy serving the UA, or a function of an
application server that provides these services to many UAs.
A monitor may service more than one UA as a collective group if it is
common that a callee or population of users will be shared between
the UAs, and especially if the UAs share an AOR.
The callee's monitor must be capable of performing a number of
functions relative to the UA(s). The method by which it does so is
outside the scope of this document, but an example method is
described in appendix B.
The monitor monitors calls made to the UA(s) in order to determine
their callers and (potentially) their final response statuses.
The monitor may supply the callee's UAS(s) with Call-Info header
values for final responses and any HERFP provisional responses.
The monitor receives SUBSCRIBEs for the call-completion event package
directed to the URIs serviced by the UA(s) and any URIs that the
monitor provides for use in Call-Info headers.
The callees using the UA(s) may be able to indicate to the monitor
when they wish to receive CC calls.
The monitor has a method of monitoring the status of the UA(s) and/or
their users to determine when they are "available" for a CC call,
that is, in a suitable state to receive a CC call. In a system with
rich presence information, the presence information may directly
provide this status. In a more restricted system, this determination
MAY depend on the mode of the CC call in question, which is provided
by the 'm' parameter. E.g., a UA is considered available for CCBS
("m=BS") when it is not busy, but a UA is considered available for
CCNR ("m=CR") when it becomes not busy after being busy with an
established call.
The monitor maintains information about the set of INVITEs that have
been received by the UA(s) that may not have been considered
successful by the calling user. In practice, the monitor may remove
knowledge about an incoming dialog from its set if its CC policy
establishes that the dialog is no longer eligible for CC requests.
Worley, et al. Expires December 19, 2008 [Page 9]
Internet-Draft Call Completion June 2008
The CC monitor MAY provide a URI to which the CC agent can subscribe
for call completion. When applicable, the CC URI SHALL be sent to
the CC agent in the Call Info header of an appropriate response
message to the initial INVITE, according to the following scheme:
Call-Info:monitor-URI;purpose=call-completion;m=XX Note that this
particular format for the information in a response has not been
fixed yet.
The 'm' parameter defines the "mode" of call completion and can
currently have the values 'BS' for CCBS and 'NR' for CCNR. It is
possible that other values will be defined in future. It is also
allowed to omit the 'm' parameter entirely. Implementations MUST
accept CC operations in which the 'm' parameter is missing or has an
unknown value, and perform them as well as is possible in their
environment (which is likely to be with degraded service, especially
in interoperation with SS7).
Issue: How does the CC monitor inform the CC agent if CC retention is
supported or not? MH: service retention parameter
5.3. The Original Call Is Made
The caller's UA sends an INVITE to a request URI. One or more forks
of this request reach one or more of the callee's UAs. By
hypothesis, none of the callee's UAs returns a success response, as
otherwise, call completion services would not be needed for this
call. However, the caller's INVITE might succeed at some other UA
that the calling user considers insufficient to satisfy his needs.
E.g., a call that is not answered by the callee user may connect to
the callee user's voicemail server. Eventually, the INVITE fails, or
the resulting dialog(s) are terminated.
The caller's agent MUST record the From URI and MAY record the final
request status that the caller's UA received and the contents of
Call-Info headers of final responses and any HERFP provisional
responses. The callee's monitor MUST record the From URI and MAY
record the final request status(es) returned by the callee's UA(s).
Note that the caller's UA may not receive any response from any of
the callee's UA(s), as the final response returned to the caller's UA
may have been from a fork that reached a UA that was not the
callee's.
5.4. Call-Completion Is Activated
The calling user indicates to the caller's agent that he wishes to
invoke call-completion services on the recent call. Note that from
Worley, et al. Expires December 19, 2008 [Page 10]
Internet-Draft Call Completion June 2008
the SIP point of view, the INVITE may be successful, but from the
user's point of view, the call may be unsuccessful. E.g., the call
may have connected to the callee's voicemail, which would return a
200 status to the INVITE but from the caller's point of view is "no
reply".
Question: At this point, it seems that the best choice is that the
caller's agent need not determine what type of CC is being requested
(CCNR vs. CCBS), as (1) it cannot determine this from the INVITE
final response, (2) it would be a burden to make the calling user to
specify it, and (3) the callee's monitor can determine this from the
responses returned by the callee's UAs. MH: Dependent if 'm'
parameter is included in the response.
The caller's agent subscribes to the call-completion event package
using the request URI of the original call. This SUBSCRIBE should be
routed in much the same way as the original INVITE, but ultimately
being routed not to the callee's UAs but to the callee's monitor.
The Event header of the subscribe specifies the call-completion event
package with a parameter call_id={Call-Id of the original call}.
Question: Should the specification of the original call be done in
the SUBSCRIBE body rather than in an event-param?
The SUBSCRIBE should have headers to optimize its routing. In
particular, it SHOULD contain "Request-Disposition: parallel, no-
cancel", and an Accept-Contact header to eliminate callee UAs that
are not acceptable to the calling user.
The callee's monitor(s) that receive the SUBSCRIBE establish
subscriptions. These subscriptions represent the caller's agent's
request for call-completion services. The callee's monitor must be
prepared to receive multiple forks of a single SUBSCRIBE, and should
respond 482 (Merged Request) to all but one fork. The callee's
monitor must be prepared to receive SUBSCRIBEs regarding original
calls that it has no knowledge of, and should respond 404 (Not Found)
to such SUBSCRIBEs. The monitor may apply additional restrictions as
to which caller's agents may subscribe.
The caller's agent must be prepared to receive multiple responses to
the SUBSCRIBE and to have multiple subscriptions established. The
agent must also be prepared to have the SUBSCRIBE fail, in which
case, CC cannot be invoked for this original call.
The call-completion event package returns various information to the
caller's agent, but the vital datum is that it contains an indication
whether the callee's monitor has chosen the caller's agent to perform
the next CC call to the callee. This datum is initially false.
Worley, et al. Expires December 19, 2008 [Page 11]
Internet-Draft Call Completion June 2008
5.5. The Call-Completion Request Is Queued
The continuation of the caller's agent's subscription indicates that
the caller's agent is prepared to initiate the CC call when it is
selected by the callee's monitor. If the caller's agent becomes
unwilling to initiate the CC call (e.g., because the calling user has
deactivated CC or because the caller's UA becomes busy), the caller's
agent must terminate or suspend the subscription(s). (Currently, no
method of suspending a subscription is defined.) If the caller's
agent later becomes willing again to initiate CC for the original
call, it may resume the suspended subscription(s) or initiate new
one(s).
If the callee's monitor becomes aware that, according to its policy,
the original call referenced by a subscription will never be selected
for call-completion, it should terminate the subscription. (And
respond to any attempt to start a new subscription for that original
call with 404.)
5.6. Call-Completion Is Invoked
The callee's monitor has a policy regarding when and how it selects
CC requests to be activated. This policy may take into account the
type of the requests (CCNR vs. CCBS), the state of the callee's
UA(s), the order in which the original calls arrived, and any
previous CC attempts for the same original call. Usually the
callee's monitor will choose only one CC request for activation at a
time, but if the callee's UA(s) can support multiple calls, it may
choose more than one.
The callee's monitor changes the "call completion active" datum for
the chosen caller's agent from false to true. This triggers a
notification for the agent's subscription.
The agent receives the notification with the CC active datum set to
true. It then terminates or suspends all other CC subscriptions for
this original call, and all CC subscriptions for all other original
calls, in order to prevent any other CC requests from this caller
from being activated. The agent then determines whether the calling
user is available for the CC call, usually by calling the caller's
UA(s).
If the calling user is not available, the caller's agent indicates
this to the callee's monitor by terminating the CC subscription.
If the calling user is available, the caller's agent causes the
caller's UA to initiate a call to the request URI (which is expected
to be routed to the callee's UA(s)).
Worley, et al. Expires December 19, 2008 [Page 12]
Internet-Draft Call Completion June 2008
Question: Should the callee's monitor supply a URI which should be
used in the CC call? This seems like it would be more reliable, as
the monitor is probably "for" a particular callee URI, and it has no
information about the destinations of any other forks of the original
call.
Question: The CC must be marked in some way as a CC call in order for
the callee's monitor to know that the CC activation is being acted
upon by the caller's agent. And the marking must include the
original Call-Id to allow correlation with the original call.
Possibilities for a marking are a special URI-parameter on the
request URI or a special header.
The callee's UA(s) and any associated proxies may give the CC call
precedence over non-CC calls.
The callee's monitor supervises the receiving of the CC call. If the
CC call does not arrive at the callee's UA(s) promptly, the monitor
will withdraw CC activation from the caller's agent by changing the
value of its CC active datum to false. Similarly, if the CC call
fails, the monitor will withdraw CC activation. Depending on its
policy, the same original call may be selected again for CC
activation at a later time. If the CC call succeeds, the monitor
will also withdraw CC activation, but the original call will never
again be selected for CC activation (and in practice, can be deleted
from the monitor's records).
Question: Is that last statement true? Can a call appear to succeed
from the monitor's point of view but fail from the calling user's
point of view?
Once the CC call has failed, or if it has succeeded, once the CC call
has been terminated, the callee's monitor's policy may select another
CC request for activation.
5.7. The caller is busy on receipt of the CC recall
If the caller is found to be busy previous to or on receipt of the CC
recall, then the CC request shall be suspended until the caller
becomes not busy again. The CC agent shall send a PUBLISH request
informing about the PIDF state 'closed' to the CC monitor, with the
URI of the caller in the From header and the To header. The Request-
URI of this PUBLISH request contains the monitor URI as received in
the Call-Info header of the 486 response.
If a queue entry is suspended, it is stepped over during CC
processing at the CC monitor.
Worley, et al. Expires December 19, 2008 [Page 13]
Internet-Draft Call Completion June 2008
When the caller is no longer busy, then the CC request shall be
resumed. The CC agent shall send a PUBLISH request informing about
the PIDF state 'open' to the CC monitor, with the URI of the caller
in the From header and the To header. The Request-URI of this
PUBLISH request contains the monitor URI as received in the Call-Info
header of the 486 response. When a CC request becomes resumed, then,
if the callee becomes not busy again and there is no entry in the CC
queue which is currently being processed, the CC monitor shall
process the destination B queue as described above.
If the processing of a CC request results in suspending that CC
request, the monitor shall stop the recall timer and attempt to
process the next CC request in the queue.
In case of the CC agent had sent several CC suspension requests to
different CC monitors and the caller becomes not busy again, the CC
agent shall send a CC resumption request to each CC monitor for which
there is a suspended CC request.
5.8. Data Provided in the Call-Completion Event Package
Question: What format should the event package data be presented in?
This draft proposes a simple attribute-value format. We might also
consider yet another XML format.
The only necessary information to be provided by the call-completion
event package is the CC activation datum, whose value is false
(meaning that this CC request has not been chosen for activation) or
true (meaning that it has).
Question: If we decide to let the callee's monitor provide the
request URI for the CC call, that request URI should probably be a
mandatory datum as well.
The event package may provide information about the callee's
monitor's policy. In particular, the PSTN CC feature gives an
indication of the "service retention" attribute, which indicates
whether the CC request can be continued to a later time if the call-
completion call fails due to the callee's UA(s) being busy.
If the callee has a caller-queuing facility, we want to treat the
call-completion queue as part of the queuing facility, and include in
the event package information regarding the state of the queue, such
as number of callers ahead of this caller and expected wait time. In
that case, this data should probably not trigger a notification every
time it changes, but rather at suitable time increments.
Need to revise
Worley, et al. Expires December 19, 2008 [Page 14]
Internet-Draft Call Completion June 2008
6. Examples
A basic flow, with only the most significant messages shown, is this:
Caller Callee
sip:123@a.com sip:456@b.com
| |
| INVITE sip:456@b.com |
|------------------------->|
| |
| 487 |
| Call-Info: <sip:456@b.com;monitor>;purpose=call-completion;m=NR
|<-------------------------|
| |
| SUBSCRIBE sip:456@b.com;monitor;id=xxxx;m=NR
| Request-Disposition: parallel, no-cancel
|------------------------->|
| |
| 200 |
|<-------------------------|
| |
| SUBSCRIBE sip:456@b.com;id=xxxx;m=NR
| Request-Disposition: parallel, no-cancel
|------------------------->|
| |
| 482 |
|<-------------------------|
| |
| NOTIFY sip:123@a.com |
|<-------------------------|
| |
| INVITE sip:456@b.com;id=xxxx;m=NR
|------------------------->|
| |
The original call is an ordinary INVITE. It fails due to no-response
(ring-no-answer). In this case, the callee's governing proxy
generates a 487 response because the proxy canceled the INVITE to the
UA when it rang too long without an answer. The response carries a
Call-Info header with "purpose=call-completion". The Call-Info
header positively indicates that CC is available for this failed fork
of the call. The "m=NR" parameter indicates that it failed due to
no-response, which is useful for PSTN interworking and assessing
presence information in the callee's monitor.
The URI in the Call-Info header is the where the caller's agent
should subscribe for call-completion processing. Ideally, it is a
Worley, et al. Expires December 19, 2008 [Page 15]
Internet-Draft Call Completion June 2008
globally-routable URI for the callee's monitor. In practice, it may
be the callee's AOR, and the SUBSCRIBE will be routed to the callee's
monitor because it specifies "Event: call-completion".
CC activation is done by sending a SUBSCRIBE to any known monitor
URIs. These can be provided by the Call-Info header in the response
to the INVITE. These can also be provided by any HERFP provisional
responses that are received. (More about that below.) Additionally,
the caller's agent needs to include the original request-URI in its
set of monitor URIs, because the call may have forked to additional
callees whose responses the caller has not seen. (A SUBSCRIBE to the
request-URI alone is used in cases where the caller's agent has not
received or cannot remember any monitor URI.)
The caller's agent adds to the URIs the 'id' and (if possible) 'm'
parameters.
In this case, the caller's agent forks the SUBSCRIBE to two
destinations, with appropriate Request-Disposition. The first
SUBSCRIBE is to the URI from Call-Info. The second SUBSCRIBE is to
the original request-URI, and reaches the same callee's monitor.
Because it has the same Call-Id as the SUBSCRIBE that has already
reached the monitor, the monitor rejects it with a 482, thus avoiding
redundant subscriptions.
Eventually, this caller is selected for CC, and is informed of this
via a NOTIFY. This NOTIFY carries a URI to which the CC completion
INVITE should be sent. In practice, this may be the AOR of the
callee.
The caller generates a new INVITE to the URI specified in the NOTIFY,
or if there was no such URI or if the caller's agent cannot remember
it, it may use the original request-URI. The caller adds the 'id'
and (if possible) 'm' parameters, to specify CC processing.
Complication: The caller's agent cannot remember the URIs returned in
the Call-Info header and the call-completion NOTIFY.
The caller's agent uses the request-URI of the original INVITE. This
may not provide ideal routing, but in simple cases it is likely to
reach the desired callee/callee's monitor.
Complication: Multiple callees are contacted in a deep forking
structure.
The caller's agent attempts to reach these by including a SUBSCRIBE
to the original request-URI.
Worley, et al. Expires December 19, 2008 [Page 16]
Internet-Draft Call Completion June 2008
Complication: Depending on the request-URI to reach all callee's
monitors is not reliable in deep forking structures.
The best solution I know of is to use the proposed 130 response code
(draft-mahy-sipping-herfp-fix) to allow callee UAs or their governing
proxies to directly carry callee's monitor URIs back to the caller.
The body of the 130 is a sipfrag which is the failure response of the
original call at that callee. In this application, most of the
apparatus described in the referenced draft is ignored, the body
sipfrag is only examined for a Call-Info header with purpose=call-
completion. If it is found, the URI is added to the list of URIs to
be contacted for CC activation.
(While the proposed 130 response code and the proposed 199 response
code (draft-holmberg-sipping-199) are generated in nearly identical
circumstances, they have different purposes and only the 130 carries
the final response as its body. If both purposes are to be served,
the two proposals should be merged.)
Fortunately, the 130 response proposal has good upward-compatibility
-- only the callee UA/proxy and the caller UA need to understand its
semantics, and if a caller UA that does not understand 130 receives
one, it will just discard it.
An example call flow is:
Caller Proxy Callee Callee
sip:123@a.com b.com sip:456@b.com sip:789@b.com
| | | |
| INVITE sip:abc@b.com | |
|------------------>| | |
| | INVITE sip:456@b.com |
| |------------------>| |
| | | |
| | 487 | |
| | Call-Info: <sip:456@b.com;monitor> |
| | ;purpose=call-completion;m=NR
| |<------------------| |
| | | |
| | 130 carrying: | |
| | 487 | |
| | Call-Info: <sip:456@b.com;monitor> |
| | ;purpose=call-completion;m=NR
|<--------------------------------------| |
| | | |
| | INVITE sip:789@b.com |
| |-------------------------------------->|
Worley, et al. Expires December 19, 2008 [Page 17]
Internet-Draft Call Completion June 2008
| | | |
| | 487 | |
| | Call-Info: <sip:789@b.com;monitor> |
| | ;purpose=call-completion;m=NR
| |<--------------------------------------|
| | | |
| | 130 carrying: | |
| | 487 | |
| | Call-Info: <sip:789@b.com;monitor> |
| | ;purpose=call-completion;m=NR
|<----------------------------------------------------------|
| | | |
| 487 | | |
| Call-Info: <sip:789@b.com;monitor>;purpose=call-completion;m=NR
|<------------------| | |
| | | |
| SUBSCRIBE sip:456@b.com;monitor;id=xxxx;m=NR |
| Request-Disposition: parallel, no-cancel |
|-------------------------------------->| |
| | | |
| 200 | | |
|<--------------------------------------| |
| | | |
| SUBSCRIBE sip:789@b.com;monitor;id=xxxx;m=NR |
| Request-Disposition: parallel, no-cancel |
|---------------------------------------------------------->|
| | | |
| 200 | | |
|<----------------------------------------------------------|
| | | |
| SUBSCRIBE sip:abc@b.com;id=xxxx;m=NR | |
| Request-Disposition: parallel, no-cancel |
|------------------>| | |
| | | |
| | SUBSCRIBE sip:456@b.com;id=xxxx;m=NR |
| | Request-Disposition: parallel, no-cancel
| |------------------>| |
| | | |
| | 482 | |
| |<------------------| |
| | | |
| | SUBSCRIBE sip:789@b.com;id=xxxx;m=NR |
| | Request-Disposition: parallel, no-cancel
| |-------------------------------------->|
| | | |
| | 482 | |
| |<--------------------------------------|
| | | |
Worley, et al. Expires December 19, 2008 [Page 18]
Internet-Draft Call Completion June 2008
| 482 | | |
|<------------------| | |
| | | |
| NOTIFY sip:123@a.com | |
|<--------------------------------------| |
| | | |
| INVITE sip:456@b.com;id=xxxx;m=NR | |
|-------------------------------------->| |
| | | |
7. Call Completion Event Package
This section specifies the call-completion event package, in
accordance with section 4.4 of [RFC3265].
7.1. Event Package Name
The SIP Events specification requires package definitions to specify
the name of their package or template-package. The name of this
package is "call-completion". This value appears in the Event and
Allow-events header fields.
7.2. Event Package Parameters
No package-specific Event header parameters are defined for this
event package.
7.3. SUBSCRIBE Bodies
[RFC3265] requires package definitions to define the usage, if any,
of bodies in SUBSCRIBE requests. A SUBSCRIBE request for a call-
completion package MAY contain a body. This body defines a filter to
be applied to the subscription. Filter documents are not specified
in this document.
The SUBSCRIBE request MAY contain an Accept header field. If no such
header field is present, it has a default value of "application/
call-completion". If the header field is present, it MUST include
"application/call-completion".
A SUBSCRIBE request for a call-completion package MAY contain a body.
This body defines a filter to be applied to the subscription. Filter
documents are not specified in this document, and may be the subject
of future standardization activity.
A SUBSCRIBE request requests call-completion information regarding
calls recently made from the same originator to the destination UA(s)
Worley, et al. Expires December 19, 2008 [Page 19]
Internet-Draft Call Completion June 2008
serviced by the notifier. Calls are defined to be "from the same
originator" if the URI-part of the From header value in the INVITE is
the same as the URI-part of the From header value in the SUBSCRIBE.
(The other parts of the From header values are not considered, as
they do not have canonical representations or a defined equality
comparison.)
John: Is this intended to be deleted from the final document? If so,
fine. If not, I am not sure this captures the true reason for
leaving out the tag, say.
Dale: I had not considered that the tag must obviously be left out.
I was more concerned with the display-name, of which there are many
formats, and there are no clear rules for comparison or canonical
representation.
7.4. Subscribe Duration
[RFC3265] requires package definitions to define a default value for
subscription durations, and to discuss reasonable choices for
durations when they are explicitly specified.
If a SUBSCRIBE does not explicitly request a duration, the default
requested duration is 3600 seconds, as that is the highest timer
value recommended for the call completion services in ETSI and ITU-T.
It is RECOMMENDED that subscribers request, and that notifiers grant,
a subscription time of at least 3600 seconds.
If a notifier can determine that, according to its policy, after
certain duration the requested subscription cannot proceed to "ready"
state, it SHOULD reduce the granted subscription time to that
duration. If a notifier can determine that, according to its policy,
the requested subscription cannot proceed to "ready" state, it should
refuse the subscription. For example, in many cases when resuming a
subscription the granted duration will be less than 3600 seconds.
7.5. NOTIFY Bodies
[RFC3265] requires package definitions to describe the allowed set if
body types in NOTIFY requests, and to specify the default value to be
used when there is no Accept header field in the SUBSCRIBE request A
NOTIFY for a call-completion package MUST contain a body that
describes the call-completion states.
As described in [RFC3265], the NOTIFY message will contain bodies
that describe the state of the subscribed resource. This body is in
a format listed in the Accept header field of the SUBSCRIBE, or in a
package-specific default format if the Accept header field was
Worley, et al. Expires December 19, 2008 [Page 20]
Internet-Draft Call Completion June 2008
omitted from the SUBSCRIBE.
In this event package, the body of the notification contains a call-
completion document. All subscribers and notifiers MUST support the
"application/call-completion" data format described in section 8.
The SUBSCRIBE request MAY contain an Accept header field. If no such
header field is present, it has a default value of "application/
call-completion". If the header field is present, it MUST include
"application/call-completion". Of course, the notifications
generated by the server MUST be in one of the formats specified in
the Accept header field in the SUBSCRIBE request.
7.6. Subscriber Generation of SUBSCRIBE Requests
Subscribers MUST generate SUBSCRIBE requests when they want to
subscribe to the call-completion event package at the terminating
side in order to receive call-completion notifications. The
generation of SUBSCRIBE requests MAY imply the usage of call-
completion service specific timers. An example of such an
implementation can be found in 3GPP TS 24.642.
Issue: timers have to be specified, a timer section has to be added.
7.7. Notifier Processing of SUBSCRIBE Requests
Upon receiving a subscription refresh, the notifier MUST set the
"expires" parameter of the Subscription-State header to the current
remaining duration of the subscription regardless of the value
received in the Expires header (if present) of the subscription
refresh.
If a subscription is not successful because the call-completion queue
has reached the maximum allowed number of entries (short term
denial), the notifier MUST send a 480 Temporarily Unavailable
response to the subscriber. If a subscription is not successful
because an error has occurred that prevents and will continue to
prevent the call-completion service (long term denial), the notifier
MUST send a 403 Forbidden response to the subscriber.
[Need to insert text about handling if there is no call to be
completed.]
A notifier MAY receive multiple forks of the same SUBSCRIBE.
(Multiple forks are, as always, identified by having the same
Call-Id.) In such a case, the notifier SHOULD reject all but one of
the SUBSCRIBEs with a 482 Merged Request response (unless some other
failure response applies).
Worley, et al. Expires December 19, 2008 [Page 21]
Internet-Draft Call Completion June 2008
The call-completion information can be sensitive. Therefore, all
subscriptions SHOULD be handled with consideration of the issues
discussed in Section 9.
7.8. Notifier Generation of NOTIFY Requests
Notifiers MUST generate NOTIFY requests when a call-completion
service condition occurs at the terminating side that needs to be
sent towards the originating side. A NOTIFY that is sent with non-
zero expiration MUST contain the "call-completion-state" parameter.
The parameter's value MUST be "queued" if the call-completion request
represented by the subscription is not at this time selected by the
monitor for CC recall, and the parameter's value MUST be "ready" if
the request is at this time selected by the monitor for CC recall.
A NOTIFY sent with a zero expiration (e.g., as a confirmation of a
request to unsubscribe) MAY contain the "call-completion-state"
parameter.
When the callee's monitor selects the request for CC recall, the
notifier MUST send a NOTIFY to the subscription of the selected
request. This NOTIFY MUST contain the "call-completion-state"
parameter set to "ready".
When the callee's monitor withdraws selection of the request for CC
recall (e.g., because the agent has not initiated the CC recall
INVITE promptly, or because the agent has suspended the request from
being considered for CC recall), the notifier MUST send a NOTIFY to
the subscription of the selected request. This NOTIFY MUST contain
the "call-completion-state" parameter set to "queued".
If the call-completion subscription was successful and the retention
option is supported at the callee, the NOTIFY MUST contain the
"retention-option" parameter.
7.9. Subscriber Processing of NOTIFY Requests
The subscriber processing of NOTIFY requests MAY trigger additional
CC service procedures, as described in this document and possibly in
other documents (e.g., 3GPP TS 24.642).
7.10. Handling of Forked Requests
Forked requests are expected to be common for the call-completion
event type. The subscriber MUST be prepared to process NOTIFY
requests from multiple notifiers and to coordinate its processing of
the information obtained from them in accordance with the procedures
in this document.
Worley, et al. Expires December 19, 2008 [Page 22]
Internet-Draft Call Completion June 2008
7.11. Rate of Notifications
The call completion service typically involves a single notification
per notifier and per subscription but MAY involve several
notifications separated by a call completion call that failed due to
a busy call completion target. Typically, notifications will be
separated by at least tens of seconds. Notifiers SHOULD NOT generate
more than two notifications in any ten-second interval.
John: A common situation might be a successful subscription to CCBS,
resulting in an initial NOTIFY "queued", and then the callee becomes
free a couple seconds later, resulting a second NOTIFY "ready".
Similarly following resume. It does not seem reasonable to suppress
or delay that second NOTIFY. I think the recommendation is too
severe. Perhaps NOTIFYs in response to SUBSCRIBEs need to be
excluded from this.
Dale: I'm quite willing to modify this prescription. I only included
it because RFC 3265 says that there must be a prescription; I believe
that if a monitor generate NOTIFYs only in response to relevant
events, its NOTIFY rate will be low enough.
However each of in the two cases you mention, there are only two
NOTIFYs, so the prescription as stated cannot be violation, since a
violation requires 3 NOTIFYs.
7.12. State Agents
State agents have no defined role in the handling of the call-
completion package.
8. Call-completion information format
The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) as described in RFC 2234. The formal syntax for the
application/call-completion MIME type is described below. In
general, the call-completion body is to be interpreted in the same
way as SIP headers: (1) the names of the lines are case-insensitive,
(2) the lines can be continued over line boundaries if the succeeding
lines start with horizontal white space, (3) lines with unknown names
are to be ignored, and (4) names starting with "X-" are reserved for
non-standardized uses. Two lines with the same name MUST NOT be
present, except when specifically permitted.
call-completion = *(cc-header CRLF)
cc-header = cc-state / cc-service-retention / cc-URI / extension-
Worley, et al. Expires December 19, 2008 [Page 23]
Internet-Draft Call Completion June 2008
header
The above rules whose names start with "cc-" are described below.
Other rules are described in RFC 3261.
8.1. call-completion-state
The cc-state line indicates the call-completion status of a
particular user with an entry in a call-completion queue. It MUST be
present unless the expiration time indicated in the NOTIFY is zero.
cc-state = "state" HCOLON ( "queued" / "ready" )
The value "queued" indicates that a user's entry in the call-
completion queue is not selected for CC recall. The value "ready"
indicates that a user's entry in the call-completion queue has been
selected for CC recall.
8.2. service-retention
The service-retention line indicates the support of the retain
option. The retain option, if supported at the callee, will maintain
the entry in the call-completion queue, if a call-completion call has
failed due to destination busy condition. If present, this parameter
indicates that the retain option is supported, otherwise it is not
supported. This parameter MAY be present in NOTIFY requests.
cc-service-retention = "service-retention" HCOLON "true"
8.3. cc-URI
The cc-URI line provides a URI (possibly in the form of a name-addr)
which the agent SHOULD use as the request-URI of the CC recall
INVITE. It SHOULD NOT be provided and MUST be ignored unless the cc-
state value is "ready". The URI SHOULD be globally routable. The
syntax provides for generic-params in the value, but this document
defines no such parameters. Parameters that are not understood by
the subscriber MUST be ignored.
cc-URI = "URI" HCOLON (name-addr / addr-spec) *(SEMI generic-param)
9. Security Considerations
The use of the CC facility allows the caller's agent to determine
some status information regarding the callee. The information is
confined to a busy/not-busy indication, and is to a considerable
degree protected by the necessity of presenting the Call-Id of a
Worley, et al. Expires December 19, 2008 [Page 24]
Internet-Draft Call Completion June 2008
recent call to the callee in order to obtain information.
The CC facility may enhance the effectiveness of SPIT by the
following technique: The caller makes calls to a group of targets.
The caller then requests CC for the calls that do not connect to the
targets. The CC calls resulting are probably more likely to reach
the targets than original calls to a further group of targets.
10. IANA Considerations
This specification registers an event package, based on the
registration procedures defined in . The followings is the
information required for such a registration:
Package Name: call-completion
Package or Template-Package: This is a package.
Published Document: RFC XXXX(Note for RFC Editor: Please fill in XXXX
with the RFC number of this specification).
Person to Contact: Martin Huelsemann, martin.huelsemann@telekom.de
11. Acknowledgments
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
12. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
Worley, et al. Expires December 19, 2008 [Page 25]
Internet-Draft Call Completion June 2008
Initiated Dialog Event Package for the Session Initiation
Protocol (SIP)", RFC 4235, November 2005.
Appendix A. Example Caller's Agent
This section outlines how an autonomous caller's agent can operate
using only standard SIP features to interact with the caller's UA.
This example is suitable only as a learning aid, as its performance
is poor.
The agent monitors calls made from the UA(s) by subscribing to the
dialog event package of the UA(s). Since this does not give the
agent access to the Call-Info headers of responses, the agent is
limited to using the original request URI for making CC requests.
The UA(s) or their proxy routes calls made with either of two special
dial sequences to the agent, which interprets the INVITEs as
indications to make a CC request with BS or NR mode for the latest
call made by the UA.
The agent monitors the status of the UA(s) for availability to be
used for a CC call by examining the dialog events.
The agent indicates to the UA(s) that CC recall is in progress by
making call to the UA(s). If the UA is answered, the agent assumes
that the caller is available and plays pre-recorded audio to indicate
that CC recall is in progress.
After playing the pre-recorded audio, the caller's agent uses REFER
to order the UA to make the CC call to the callee.
Appendix B. Example Callee's Monitor
This section outlines how an autonomous callee's monitor can operate
using only standard SIP features to interact with the callee's UA.
This example is suitable only as a learning aid, as its performance
is poor.
The monitor monitors calls made to the UA(s) by subscribing to the
UA(s) dialog events. This enables it to determine their Call-Id's
and their final response statuses.
The monitor does not supply Call-Info header values. The proxy for
the UA(s) routes to the monitor any SUBSCRIBEs for the call-
completion event package directed to the URIs serviced by the UA(s).
Worley, et al. Expires December 19, 2008 [Page 26]
Internet-Draft Call Completion June 2008
The callees cannot indicate to the monitor when they wish to receive
CC calls.
The monitor monitors the status of the UA(s) to determine when they
are in a suitable state to receive a CC call by watching the busy/
not-busy status of the UA(s): a UA is available for CCBS when it is
not busy, but a UA is available for CCNR when it becomes not busy
after being busy with an established call.
Authors' Addresses
Dale R. Worley
Pingtel Corp.
10 North Ave.
Burlington, MA, 01803
US
Phone: +1 781 229 0533 x173
Email: dworley@pingtel.com
URI: URI: http://www.pingtel.com
Martin Huelsemann
Deutsche Telekom
Heinrich-Hertz-Strasse 3-7
Darmstadt, 64307
Germany
Phone: +4961516282765
Email: martin.huelsemann@telekom.de
Denis Alexeitsev
Deutsche Telekom
Heinrich-Hertz-Strasse 3-7
Darmstadt, 64307
Germany
Phone: +4961516282773
Email: d.alexeitsev@telekom.de
Worley, et al. Expires December 19, 2008 [Page 27]
Internet-Draft Call Completion June 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.
Worley, et al. Expires December 19, 2008 [Page 28]
Html markup produced by rfcmarkup 1.129b, available from
https://tools.ietf.org/tools/rfcmarkup/