One document matched: draft-audet-sipping-feature-ref-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "http://xml.resource.org/authoring/rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2141 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2141.xml">
<!ENTITY rfc3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY rfc3406 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3406.xml">
<!ENTITY rfc3515 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3515.xml">
<!ENTITY rfc3680 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3680.xml">
<!ENTITY rfc4235 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4235.xml">
<!ENTITY rfc4488 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4488.xml">
<!ENTITY rfc4538 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4538.xml">
<!ENTITY rfc5031 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5031.xml">
<!ENTITY rfc5057 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5057.xml">
<!ENTITY I-D.ietf-sipping-app-interaction-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sipping-app-interaction-framework.xml">
<!ENTITY I-D.ietf-sip-gruu SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sip-gruu.xml">
<!ENTITY I-D.ietf-sipping-cc-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sipping-cc-framework.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<rfc category="bcp" docName="draft-audet-sipping-feature-ref-00" ipr="full3978">
<front>
<title abbrev="Feature Referral">Feature Referral in the Session
Initiation Protocol (SIP)</title>
<author fullname="Francois Audet" initials="F." surname="Audet">
<organization>Nortel</organization>
<address>
<postal>
<street>4655 Great America Parkway</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95054</code>
<country>US</country>
</postal>
<phone>+1 408 495 2456</phone>
<email>audet@nortel.com</email>
</address>
</author>
<author fullname="Alan Johnston" initials="A" surname="Johnston">
<organization>Avaya</organization>
<address>
<postal>
<street/>
<city>St. Louis</city>
<region>MO</region>
<code>63124</code>
<country>US</country>
</postal>
<email>alan@sipstation.com</email>
</address>
</author>
<author fullname="Rohan Mahy" initials="R." surname="Mahy">
<organization>Plantronics</organization>
<address>
<postal>
<street>345 Encincal Street</street>
<city>Santa Cruz</city>
<region>CA</region>
<country>US</country>
</postal>
<email>rohan@ekabal.com</email>
</address>
</author>
<author fullname="Cullen Jennings" initials="C." surname="Jennings">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<street>Mailstop SJC-21/2</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>
<phone>+1 408 902-3341</phone>
<email>fluffy@cisco.com</email>
</address>
</author>
<date day="17" month="February" year="2008"/>
<area>RAI</area>
<workgroup>SIPPING WG</workgroup>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>SIP</keyword>
<keyword>feature referral</keyword>
<abstract>
<t>Feature referral allows for an application to make a high level
request to a User Agent to perform an action or "feature", and let the
the User Agent actually execute the feature as it sees fit. Feature
referral uses the SIP REFER method with a Refer-To header field
containing a URN.</t>
</abstract>
</front>
<middle>
<section title="Terminology">
<t>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 <xref target="RFC2119"/>.</t>
<t>To simplify discussions of the REFER method and its extensions, the
three terms below are being used throughout the document:</t>
<t>
<list style="symbols">
<t>REFER-Issuer: the UA issuing the REFER request</t>
<t>REFER-Recipient: the UA receiving the REFER request</t>
<t>REFER-Target: the UA designated in the Refer-To Uniform Resource
Identifier (URI), which, for this specification, is a Uniform
Resource Name (URN)</t>
</list>
</t>
</section>
<section title="Introduction">
<t>Feature referral allows for an application (such as a proxy or a user
agent) to make a high level request to a SIP <xref target="RFC3261"/> User Agent (UA) to perform an action or
"feature", and let the the User Agent actually execute the feature as it
sees fit. Feature referral uses the SIP REFER method <xref target="RFC3515"/> with a Refer-To header field containing a URN
<xref target="RFC2141"/>.</t>
<t>Feature referral is useful for collections of loosely coupled User
Agents which would like to present a coordinated user experience (i.e.,
when the Application is co-resident in the UA). Among other things, this
allows User Agents which handle orthogonal media types but which would
like to be present in a single conversation to add and remove each other
from the conversation as needed. This is especially appropriate when
coordinating conversations among organizers, general purpose computers,
and special purpose communications appliances like telephones, Internet
televisions, in-room video systems, electronic whiteboards, and gaming
devices. For example using feature referral, an Instant Messaging client
could initiate a multiplayer gaming session and an audio session to a
chat conversation. Likewise a telephone could add an electronic
whiteboard session to a voice conversation. Finally, a computer or
organizer could cause a nearby phone to dial from numbers or URIs in a
document, email, or address book; allow users to answer or deflect
incoming calls without removing hands from the computer keyboard; place
calls on hold; and join other sessions on the phone or otherwise.</t>
<t>Feature referral is also useful for a wide range of third party
applications that need to remotely control or influence a User Agent
(for example, in Contact center environment). In pre-SIP environments,
these environments have been using "Computer Telephony Integration": for
example, traditional PBXs use CTI protocols such as CSTA <xref target="ECMA269"/> to provide this functionality. CSTA works fine
for legacy PBXs with legacy phones but is problematic in a SIP
environment. For example, SIP includes totally new capabilities such as
presence and instant messaging. SIP also supports multiple users with
multiple devices operating at once, and with complex User Interfaces.
Furthermore, multiple applications may want to simultaneously wish to
interact with the device. Because of the lack of a native mechanism
mechanism to achieve such control for SIP, implementors have had to
implement such techniques as mapping CSTA's ASN.1 encoding to XML then
encapsulate it into SIP INFO requests in order to tunnel it to a SIP
B2BUA <xref target="ECMA323"/>, which then maps it to proprietary
device control protocols or to SIP with proprietary and incompatible
extensions. This document provides a clean and native way to meet the
requirements.</t>
<t>CTI fundamentally requires two components:</t>
<t>
<list style="symbols">
<t>Monitoring - to learn the state of the UA</t>
<t>Control - request the UA to perform certain features</t>
</list>
</t>
<t>SIP already provides some capabilities for monitoring, including the
following:</t>
<t>
<list style="symbols">
<t>Dialog package - call states</t>
<t>Registration package - phone status</t>
<t>Conference package - conference status</t>
</list>
</t>
<t>SIP also provide a method for requesting UAs do perform certain task,
i.e., REFER <xref target="RFC3515"/>, but today is it limited.
Specically:</t>
<t>
<list style="symbols">
<t>REFER does not allow for a UA to request another UA to respond to
requests, e.g., <list style="symbols">
<t>A UA cannot request another UA to answer a call</t>
<t>A UA cannot request another UA to reject a call</t>
</list>
</t>
<t>REFER does not allow for a UA to reques another UA to invoke
features, e.g.,<list style="symbols">
<t>REFER does not allow for a UA to request another UA to place
a call on hold, or to mute it</t>
<t>REFER does not allow for a UA to request another UA to
transfer, conference, or park a call</t>
</list>
</t>
</list>
</t>
<t>Feature referral is consistent with the SIP call control framework
<xref target="I-D.ietf-sipping-cc-framework"/> and is a natural
expansion of the Application Interaction Framework <xref target="I-D.ietf-sipping-app-interaction-framework"/> which allows
for referral to SIP resources (through the SIP URI scheme) and Web pages
(through the HTTP URI scheme).</t>
</section>
<section anchor="overview" title="Overview">
<t>A prototypical feature referal flow looks as per section 4.1 of <xref target="RFC3515"/>. The Refer-To URI in the REFER message includes
a URN describing the feature. The first part of the URN, i.e., the
Namespace Identifier, is indended to be in the formal space and assigned
by IANA, as per the procedures of <xref target="RFC3406"/>. An
alternative would be to use the service URN space <xref target="RFC5031"/>. Until this is resolved, this document will use
the following namespace: "feature". The second part of the URN includes
the feature name, and may be followed by a semi-colon and additional
feature-specific parameters.</t>
<t>Feature referral are sent to a GRUU when a specific instance of a UA
is the desired target. When the feature referral needs to be correlated
to a specific dialog, the Target-Dialog header field is used <xref target="RFC4538"/>. Some primitives require a second dialog
identifier (such as ConferenceCalls which causes the media from two
dialogs to be mixed). The mechanism to convey this second dialog
identifier is TBD.</t>
<t>The following is a list of sample features (using the CSTA TR/87
<xref target="TR87"/> minimal profile as a starting point):</t>
<t>
<list style="symbols">
<t>Answer call - urn:feature:AnswerCall</t>
<t>Clear connection - urn:feature:ClearConnection</t>
<t>Deflect call - urn:feature:DeflectCall</t>
<t>Hold call - urn:feature:HoldCall</t>
<t>Retrieve call - urn:feature:RetrieveCall</t>
<t>Single step transfer -urn:feature:SingleStepTransfer</t>
<t>Conference calls - urn:feature:ConferenceCalls</t>
<t>Separate calls - urn:feature:SeparateCalls</t>
</list>
</t>
<t>Note that the very important "Make call" CTI primitive does not
require a feature referral URN since it is accomplished by sending a
normal REFER with a URI identifying the resource (e.g., a sip, sips or
tel URI).</t>
<t>Of course, other features could also be added, beyond the realm of
traditional telephony, e.g.:</t>
<t>
<list style="symbols">
<t>Add buddy to list - urn:feature:AddBuddy;sip@bob@example.com</t>
<t>Send vCard - urn:feature:SendVCard</t>
</list>
</t>
</section>
<section title="User Agent Behavior">
<section title="Dialog usage">
<t>This document attempts to avoid using multiple dialog usages, for
the reasons described in <xref target="RFC5057"/>. Therefore,
this document will make use of the GRUU <xref target="I-D.ietf-sip-gruu"/>, and the Target-Dialog header field
<xref target="RFC4538"/> to associated and existing INVITE usage
with a REFER arriving on a new dialog to facilitate authorization of
that REFER.</t>
<t>In many use cases of feature referral, receiving notifications
about the status of a REFER request are superfluous, as the Refer
issuer often maintains a long duration subscription to the dialog
package <xref target="RFC4235"/>. Suppression of the REFER
notifications is done with the norefersub option-tag, defined in
section 7 of <xref target="RFC4488"/>. When the norefersub
option tag is present, a REFER request which would have created a new
subscription and dialog becomes a standalone transaction instead,
eliminating a multiple dialog usage. Each such standalone REFER
transaction use a new (unique) Call-ID header field value.</t>
<t>In the most common usage, the controller maintains a long duration
subscription to the dialog package, and sends REFER requests in
seperate dialogs Each REFER would include the norefersub option-tag in
a Supported header field.</t>
<t>In some cases, the controller does not maintain a dialog package
subscription for the Refer-Receiver. This might be the case for a
"webdialer" or other application which associates with other UAs on an
adhoc and intermitent basis. An initial REFER request is sent to start
a new dialog, which is followed by notifications for the refer event
type (the norefersub option-tag is not used in this case).</t>
</section>
<section title="Addressing the relevant parties">
<t>REFER requests contain a number of URIs which need to address the
appropriate parties. A list of the relevant fields include the
Request-URI, To URI, From URI, Contact URI, Refer-To URI, and the
Referred-By URI, as well as the Target-Dialog itself. This section
attempts to clarify what needs to be placed in each field.</t>
<t>In most cases, feature referral applies to dialogs or sessions on a
specific UA, in which case a GRUU <xref target="I-D.ietf-sip-gruu"/> for a single UA (i.e., Contact URI)
is used. Contact URIs for a UA can be discovered by subscribing to the
registration package <xref target="RFC3680"/> for the relevant
AORs.</t>
<t>In the cases where the controller does not care which specific UA
it manipulates, an AOR can be used instead. When an AOR is used, the
REFER request can include appropriate caller-preferences to encourage
selection of an appropriate Contact. The norefersub option-tag is not
used when the REFER Request-URI is an AOR, as the REFER Request could
fork and cause very odd behavior. While, the controller can discourage
a proxy from forking remote call control request by using the
Request-Disposition: no-fork header field, insuring that no proxy
forks requires the use of the callerpref option-tag in a Proxy-Require
header field value. Use of Proxy-Require is not normally advised
because any proxy in the chain of this request which did not support
caller preferences would cause the request to fail.</t>
<t>The To header field in the REFER request normally contains the same
URI as in the Request-URI. The From identifies the AOR of the
controller. The Refer-To URI is the feature referral URN.</t>
<t>Many uses of feature referral require that the Refer-Receiver take
some action in the context of an existing dialog. For example, the
controller might want the Refer-Receiver to send terminate an existing
dialog. To select the appropriate dialog from which to source the
request, the Target-Dialog header specified in <xref target="RFC4538"/> is used.</t>
</section>
</section>
<section title="Call flows">
<t>This sample provides non-normative sample calls flows for the
features listed in <xref target="overview"/>. It is important to
understand that the actual "realization" of the feature (i.e., the
actual procedures invoked) are the sole responsibility of the
Refer-Recipient. This document in no way attempts to standardize those
procedures, and the call flow below are merely examples.</t>
<t>In all cases, the "controller" (i.e., the Refer-Issuer) could be
Alice's PC, PDA, or a third party application. The controlled device is
Alice's phone (i.e., the Refer-Recipient). The Refer-Target is obviously
the feature referral URN. In all cases, it is assumed that the
controller is subscribed to Alice's Phone's dialog package.</t>
<t>The call flows in this document use the following conventions. The
dialog each message is sent in is shown on the left hand side. Selected
Request-URI and header fields are shown. The contents of message bodies
are shown for dialog-info+xml, sdp, and sipfrag message bodies. For
responses, the method is shown in parentheses. For reference, the
messages are labeled F1, F2, etc.</t>
<section title="Answer Call Operation">
<t>In message 1, Bob makes a call to Alice's Phone. A notification of
"trying" is sent to the controller. Alice's phone automatically sends
a "ringing" to Bob. Another notification of "early" is then sent to
the controller. The controller then tells the phone to answer the
call. Alice's phone sends a notification of "confirmed" to the
controller.</t>
<figure title="Answer Call Flow Example">
<artwork><![CDATA[
Controller Alice Bob
|<<< Controller subscribed >>>| |
|<< to Alice's dialog events >>| |
dialog1 | | F1 INVITE sip:Alice-AOR |
| |<---------------------------|
dialog2 | F2 NOTIFY sip:Controller-GRUU| |
| dialog-info+xml: dialog1=trying |
|<-----------------------------| |
| | |
dialog2 | F3 200 (NOTIFY) | |
|----------------------------->| |
dialog1 | | F4 180 (INVITE) |
| |--------------------------->|
dialog2 | F5 NOTIFY sip:Controller-GRUU| |
| dialog-info+xml: dialog1=early |
|<-----------------------------| |
| | |
dialog2 | F6 200 (NOTIFY) | |
|----------------------------->| |
| | |
dialog3 | F7 REFER sip:Alice-GRUU | |
| To: sip:Alice-GRUU | |
| Refer-To: urn:feature:AnswerCall |
| Target-Dialog: dialog1 | |
|----------------------------->| |
| | |
dialog3 | F8 202 (REFER) | |
|<-----------------------------| |
dialog1 | | F9 200 (INVITE) |
| |--------------------------->|
| | |
dialog1 | | F10 ACK |
| |<---------------------------|
dialog2 | F11 NOTIFY sip:Controller-GRUU |
| dialog-info+xml: dialog1=confirmed |
|<-----------------------------| |
| | |
dialog2 | F12 200 (NOTIFY) | |
|----------------------------->| |
]]></artwork>
</figure>
</section>
<section title="Clear Connection">
<t>Clear Connection is a perfect example of a feature whose treatment
(and consequently, the resulting call flow) depends on the situation,
for example, the state of the dialog between the remote parties.</t>
<t>Alice's Phone and Bob are currently in an established dialog. The
controller tells Alice's phone to "clear the connection" with Bob's
phone.</t>
<figure title="Clear Connection in Established Dialog Call Flow Example">
<artwork><![CDATA[
Controller Alice Bob
|<< Controller subscribed to >>|<<< Established dialog1 >>>>|
|<<< Alice's dialog events >>>>| |
| | |
dialog3 | F1 REFER sip:Alice-GRUU | |
| To: sip:Alice-GRUU | |
| Refer-To: urn:feature:ClearConnection |
| Target-Dialog: dialog1 | |
|----------------------------->| |
| | |
dialog3 | F2 202 (REFER) | |
|<-----------------------------| |
dialog1 | | F3 BYE sip:Bob-GRUU |
| |--------------------------->|
| | |
dialog1 | | F4 200 (BYE) |
| |<---------------------------|
| F5 NOTIFY sip:Controller-GRUU |
| dialog-info+xml: dialog2=local-bye |
|<-----------------------------| |
| | |
dialog2 | F6 200 (NOTIFY) | |
|----------------------------->| |
]]></artwork>
</figure>
<t>If Alice's Phone and Bob are in an early dialog with Bob calling
Alice, the call flow could be as follows.</t>
<figure title="Clear Connection in Early Dialog Call Flow Example">
<artwork><![CDATA[
Controller Alice Bob
|<< Controller subscribed to >>| |
|<<< Alice's dialog events >>>>| |
dialog1 | | F1 INVITE sip:Alice-AOR |
| (dialog2) |<---------------------------|
| | |
dialog2 | F2 NOTIFY sip:Controller-GRUU| |
| dialog-info+xml: dialog1=trying |
|<-----------------------------| |
| | |
dialog2 | F3 200 (NOTIFY) | |
|----------------------------->| |
dialog1 | | F4 180 (INVITE) |
| |--------------------------->|
dialog2 | F5 NOTIFY sip:Controller-GRUU| |
| dialog-info+xml: dialog1=early |
|<-----------------------------| |
| | |
dialog2 | F6 200 (NOTIFY) | |
|----------------------------->| |
| | |
dialog3 | F7 REFER sip:Alice-GRUU | |
| To: sip:Alice-GRUU | |
| Refer-To: urn:ietf:feature:ClearConnection |
| Target-Dialog: dialog1 | |
|----------------------------->| |
| | |
dialog3 | F8 202 (REFER) (dialog3) | |
|<-----------------------------| |
dialog1 | | F9 480 (INVITE) |
| |--------------------------->|
| | |
dialog1 | | F10 ACK |
| |<---------------------------|
dialog2 | F11 NOTIFY (Controller-GRUU) | |
| dialog-info+xml: dialog1=rejected |
|<-----------------------------| |
| | |
dialog2 | F12 200 (NOTIFY) | |
|----------------------------->| |
]]></artwork>
</figure>
<t>If Alice's Phone and Bob are in an early dialog with Alice calling
Bob, the call flow could be as follows.</t>
<figure title="Clear Connection Initiated Call Flow Example">
<artwork><![CDATA[
Controller Alice Bob
|<< Controller subscribed to >>| |
|<<< Alice's dialog events >>>| |
dialog1 | | F1 INVITE sip:Bob-AOR |
| |--------------------------->|
dialog2 | F2 NOTIFY sip:Controller-GRUU| |
| dialog-info+xml: dialog1=trying |
|<-----------------------------| |
| | |
dialog2 | F3 200 (NOTIFY) | |
|----------------------------->| |
dialog1 | | F4 180 (INVITE) |
| |<---------------------------|
dialog2 | F5 NOTIFY sip:Controller-GRUU| |
| dialog-info+xml: dialog1=early |
|<-----------------------------| |
| | |
dialog2 | F6 200 (NOTIFY) | |
|----------------------------->| |
| | |
dialog3 | F7 REFER sip:Alice-GRUU | |
| To: sip:Alice-GRUU | |
| Refer-To: urn:feature:ClearConnection |
| Target-Dialog: dialog1 | |
|----------------------------->| |
| | |
dialog3 | F8 202 (REFER) | |
|<-----------------------------| |
dialog1 | | F9 CANCEL |
| |--------------------------->|
| | |
dialog1 | | F10 200 (CANCEL) |
| |<---------------------------|
| | |
dialog1 | | F11 487 (INVITE) |
| |<---------------------------|
| | |
dialog1 | | F12 ACK |
| |--------------------------->|
| | |
dialog1 | F13 NOTIFY sip:Controller-GRUU |
| dialog-info+xml: dialog1=rejected |
|<-----------------------------| |
| | |
dialog2 | F14 200 (NOTIFY) | |
|----------------------------->| |
]]></artwork>
</figure>
</section>
<section title="Deflect Call">
<t>Bob makes a call to Alice's Phone. A notification of "trying" is
sent to the controller. Alice's phone automatically sends a "ringing"
to Bob. Another notification of "early" is then sent to the
controller. The controller tells the phone to deflect the call to
Cathy. Alice's phone sends a notification of "terminated" to the
controller. Bob's will attempt the call to Cathy.</t>
<figure title="Deflect Call Flow Example">
<artwork><![CDATA[
Controller Alice Bob
|<< Controller subscribed to >>| |
|<<< Alice's dialog events >>>>| |
dialog1 | | F1 INVITE sip:Alice-AOR |
| |<---------------------------|
dialog2 | F2 NOTIFY sip:Controller-GRUU| |
| dialog-info+xml: dialog1=trying |
|<-----------------------------| |
| | |
dialog2 | F3 200 (NOTIFY) | |
|----------------------------->| |
dialog1 | | F4 180 (INVITE) |
| |--------------------------->|
dialog2 | F5 NOTIFY sip:Controller-GRUU| |
| dialog-info+xml: dialog1=early |
|<-----------------------------| |
| | |
dialog2 | F6 200 (NOTIFY) | |
|----------------------------->| |
| | |
dialog3 | F7 REFER sip:Alice-GRUU | |
| To: sip:Alice-GRUU | |
| Refer-To: urn:feature:DeflectCall;target=(Cathy-AOR) |
| Target-Dialog: dialog1 | |
|----------------------------->| |
| | |
dialog3 | F8 202 (REFER) | |
|<-----------------------------| |
dialog1 | | F9 302 (INVITE) |
| | Contact: sip:Cathy-AOR |
| |--------------------------->|
| | |
dialog1 | | F10 ACK |
| |<---------------------------|
dialog2 | F11 NOTIFY sip:Controller-GRUU |
| dialog-info+xml: dialog1=rejected |
|<-----------------------------| |
| | |
dialog2 | F12 200 (NOTIFY) | |
|----------------------------->| |
| | |
| Cathy |
dialog4 | | F13 INVITE sip:Cathy-AOR |
| |<-------------------------------------------|
dialog4 | | F14 180 (INVITE) |
| |------------------------------------------->|
dialog4 | | F15 200 (INVITE) |
| |------------------------------------------->|
dialog4 | | F16 ACK |
| |<-------------------------------------------|
]]></artwork>
</figure>
<t/>
</section>
<section title="Hold Call">
<t>The controller tells Alice's phone to put on hold the already
established dialog with Bob. Alice's phone sends a re-INVVITE to Bob's
contact to put the media stream on hold. Note that a call hold is
different concept than held media. In fact, a user can be placed on
hold, and be provided with music on hold. A held call is a logical
state which could be useful for a number of things such as monitoring
the amount of time a user stays in a queue.</t>
<figure title="Call Hold Call Flow Example">
<artwork><![CDATA[
Controller Alice Bob
|<< Controller subscribed to >>|<<<< Established dialog1 >>>|
|<<< Alice's dialog events >>>>| |
| | |
dialog3 | F1 REFER sip:Alice-GRUU | |
| To: sip:Alice-GRUU | |
| Refer-To: urn:feature:HoldCall |
| Target-Dialog: dialog1 | |
|----------------------------->| |
| | |
dialog3 | F2 202 (REFER) | |
|<-----------------------------| |
dialog1 | | F3 re-INVITE sip:Bob-GRUU |
| | sdp: hold |
| |--------------------------->|
| | |
dialog1 | | F4 200 (re-INVITE) |
| |<---------------------------|
| | |
dialog1 | | F5 ACK |
| |<---------------------------|
dialog2 | F6 NOTIFY sip:Controller-GRUU| |
| dialog-info+xml: dialog2;confirmed;+sip.rendering="no" |
|<-----------------------------| |
| | |
dialog2 | F7 200 (NOTIFY) | |
|----------------------------->| |
]]></artwork>
</figure>
</section>
<section title="Retrieve Call">
<t>The controller tells Alice's phone to retrieve an held call with
Bob. Alice's phone sends a re-INVVITE to Bob's contact to resume the
media stream which was already on hold.</t>
<figure title="Retrieve Call Flow Example">
<artwork><![CDATA[
Controller Alice Bob
|<< Controller subscribed to >>|<<<< Established dialog1 >>>|
|<<< Alice's dialog events >>>>| |
| | |
| F1 REFER sip:Alice-GRUU | |
| To: sip:Alice-GRUU | |
| Refer-To: urn:feature:RetrieveCall |
| Target-Dialog: dialog1 | |
|----------------------------->| |
| | |
dialog3 | F2 202 (REFER) | |
|<-----------------------------| |
dialog1 | | F3 re-INVITE sip:Bob-GRUU |
| | sdp: un-hold |
| |--------------------------->|
| | |
dialog1 | | F4 200 (re-INVITE)
| |<---------------------------|
| | |
dialog1 | | F5 ACK |
| |<---------------------------|
dialog2 | F6 NOTIFY sip:Controller-GRUU | |
| dialog-info+xml: dialog2;confirmed;+sip.rendering="yes"|
|<-----------------------------| |
| | |
dialog2 | F7 200 (NOTIFY) (dialog2) | |
|----------------------------->| |
]]></artwork>
</figure>
</section>
<section title="Single Step Transfer Call Flow Example">
<t>Alice's phone and Bob are currently in an established dialog. The
controller tells Alice's phone to transfer the call to Cathy. Alice's
phone sends a REFER to Bob to transfer the call to Cathy. Cathy's
phone rings, is and is answered. Bob sends a notification to Alice's
phone of completion of REFER (using the implicit subscription).
Alice's phone then terminates the session with Bob and sends a
notification of "terminated" to the controller.</t>
<figure>
<artwork><![CDATA[
Controller Alice Bob
|<< Controller subscribed to >>|<<<< Established dialog1 >>>|
|<<< Alice's dialog events >>>>| |
| | |
dialog3 |F1 REFER sip:Alice-GRUU | |
| To: sip:Alice-GRUU | |
| Refer-To: urn:feature:SingleStepTransfer;target=Cathy-AOR
| Target-Dialog: dialog1 | |
|----------------------------->| |
| | |
dialog3 | F2 202 (REFER) | |
|<-----------------------------| |
dialog4 | | F3 REFER sip:Bob-GRUU |
| | Refer-To: (Cathy-AOR) |
| |--------------------------->|
| | |
dialog4 | | F4 200 (REFER) |
| |<---------------------------|
| | |
dialog4 | | F5 NOTIFY sip:Alice-GRUU |
| | sipfrag: 100 |
| |<---------------------------|
| | |
dialog4 | | F6 200 (NOTIFY) |
| Cathy |--------------------------->|
dialog5 | | F7 INVITE sip:Cathy-AOR |
| |<-------------------------------------------|
dialog5 | | F8 180 |
| |------------------------------------------->|
dialog5 | | F9 200 |
| |------------------------------------------->|
dialog5 | | F10 ACK |
| |<-------------------------------------------|
dialog4 | | F11 NOTIFY sip:Alice-GRUU |
| | sipfrag: 200 |
| |<---------------------------|
| | |
dialog4 | | F12 200 (NOTIFY) |
| |--------------------------->|
| | |
dialog1 | | F13 BYE |
| |--------------------------->|
| | |
dialog1 | | F14 200 (BYE) |
| |<---------------------------|
dialog2 | F15 NOTIFY sip:Controller-GRUU| |
| dialog-info+xml: dialog1=terminated |
|<-----------------------------| |
| | |
dialog2 | F16 200 (NOTIFY) | |
|----------------------------->| |
]]></artwork>
</figure>
<t/>
</section>
<section title="Conference Calls">
<t>T.B.D.</t>
</section>
<section title="Seperate Calls">
<t>T.B.D.</t>
</section>
</section>
<section title="Security Considerations">
<t>The functionality described in this document allows an authorized
party to manipulate SIP sessions and dialogs in arbitrary ways. Any user
agent that accepts these types of requests needs to be very careful in
who it authorizes to send these types of requests. The same security
considerations as <xref target="RFC3515"/> apply.</t>
</section>
<section title="IANA Considerations">
<t>T.B.D. Need to register urn namespace according to procedures of
<xref target="RFC3406"/>.</t>
</section>
<section title="Acknowledgments">
<t>Many thanks to Sean Olson, Orit Levin, Robert Sparks, Jonathan
Rosenberg, and John Elwell.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
</references>
<references title="Informational References">
&rfc2141;
&rfc3261;
&rfc3406;
&rfc3515;
&rfc3680;
&rfc4235;
&rfc4488;
&rfc4538;
&rfc5031;
&rfc5057;
&I-D.ietf-sipping-app-interaction-framework;
&I-D.ietf-sip-gruu;
&I-D.ietf-sipping-cc-framework;
<reference anchor="ECMA269">
<front>
<title>Services for Computer Suported Telecommunications
Communications Applications (CSTA) Phase III</title>
<author>
<organization>ECMA International</organization>
</author>
<date month="December" year="2006"/>
</front>
<seriesInfo name="Standard" value="ECMA-269"/>
<format target="http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-269.pdf" type="PDF"/>
</reference>
<reference anchor="ECMA323">
<front>
<title>XML Protocol for Computer Supported Telecommunications
Applications (CSTA) Phase III</title>
<author>
<organization>ECMA International</organization>
</author>
<date month="December" year="2006"/>
</front>
<seriesInfo name="Standard" value="ECMA-323"/>
<format target="http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-323.pdf" type="PDF"/>
</reference>
<reference anchor="TR87">
<front>
<title>Using CSTA for SIP Phone User Agents (uaCSTA)</title>
<author>
<organization>ECMA International</organization>
</author>
<date month="June" year="2004"/>
</front>
<seriesInfo name="Technical Report" value="TR/87"/>
<format target="http://www.ecma-international.org/publications/files/ECMA-TR/TR-087.pdf" type="PDF"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:21:18 |