BLISS A. Johnston, Ed.
Internet-Draft Avaya
Expires: May 6, 2009 M. Soroushnejad
V. Venkataramanan
Sylantro Systems Corp
November 2, 2008
Shared Appearances of a Session Initiation Protocol (SIP) Address of
Record (AOR)
draft-ietf-bliss-shared-appearances-01
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 May 6, 2009.
Abstract
This document describes the requirements and implementation of a
group telephony feature commonly known as Bridged Line Appearance
(BLA) or Multiple Line Appearance (MLA), or Shared Call/Line
Appearance (SCA). When implemented using the Session Initiation
Protocol (SIP), it is referred to as Shared Appearances (SA) of an
Address of Record (AOR) since SIP does not have the concept of lines.
This feature is commonly offered in IP Centrex services and IP-PBX
offerings and is likely to be implemented on SIP IP telephones and
SIP feature servers used in a business environment. This document
Johnston, et al. Expires May 6, 2009 [Page 1]
Internet-Draft SIP Shared Appearances November 2008
lists requirements and compares implementation options for this
feature. Extensions to the SIP dialog event package are proposed.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . 5
3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Executive/Assistant Arrangement . . . . . . . . . . . . . 5
3.2. Call Group . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Single Line Extension . . . . . . . . . . . . . . . . . . 6
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Normative Description . . . . . . . . . . . . . . . . . . . . 7
5.1. Implementation . . . . . . . . . . . . . . . . . . . . . 8
5.2. Shared Appearance Dialog Package Extensions . . . . . . . 10
5.2.1. The element . . . . . . . . . . . . . . . 10
5.2.2. The element . . . . . . . . . . . . . . . 11
5.2.3. The element . . . . . . . . . . . . . 11
5.2.4. The element . . . . . . . . . . . . 11
5.3. Shared Appearance User Agents . . . . . . . . . . . . . . 11
5.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . 14
6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 16
7. User Interface Considerations . . . . . . . . . . . . . . . . 17
7.1. Appearance Number Rendering . . . . . . . . . . . . . . . 18
7.1.1. Single Appearance UAs . . . . . . . . . . . . . . . . 18
7.1.2. Dual Appearance UAs . . . . . . . . . . . . . . . . . 18
7.1.3. Shared Appearance UAs with Fixed Appearance Number . . 18
7.1.4. Shared Appearance UAs with Variable Appearance
Number . . . . . . . . . . . . . . . . . . . . . . . . 18
7.2. Call State Rendering . . . . . . . . . . . . . . . . . . 19
8. Interop with non-Shared Appearance UAs . . . . . . . . . . . . 20
8.1. Appearance Assignment . . . . . . . . . . . . . . . . . . 20
8.2. Appearance Release . . . . . . . . . . . . . . . . . . . 20
8.3. UAs Supporting Dialog Events but Not Shared Appearance . 21
9. Provisioning Considerations . . . . . . . . . . . . . . . . . 21
10. Example Message Flows . . . . . . . . . . . . . . . . . . . . 21
10.1. Registration and Subscription . . . . . . . . . . . . . . 21
10.2. Appearance Selection for Incoming Call . . . . . . . . . 24
10.3. Outgoing Call with Without Appearance Pre-Selection . . . 28
10.4. Outgoing Call with Appearance Selection . . . . . . . . . 33
10.5. Outgoing Call without using an Appearance Number . . . . 37
10.6. Appearance Release . . . . . . . . . . . . . . . . . . . 39
10.7. Appearance Pickup . . . . . . . . . . . . . . . . . . . . 40
10.8. Calls between UAs within the Group . . . . . . . . . . . 44
10.9. Consultation Hold with Appearances . . . . . . . . . . . 47
10.10. Joining or Bridging an Appearance . . . . . . . . . . . . 52
10.11. Appearance Allocation - Loss of Appearance . . . . . . . 55
Johnston, et al. Expires May 6, 2009 [Page 2]
Internet-Draft SIP Shared Appearances November 2008
10.12. Appearance Selection Contention Race Condition . . . . . 56
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57
11.1. SIP Event Package Parameter: shared . . . . . . . . . . . 58
11.2. URN Sub-Namespace Registration: sa-dialog-info . . . . . 58
11.3. XML Schema Registration . . . . . . . . . . . . . . . . . 59
12. Appendix A - Incoming Appearance Assignment . . . . . . . . . 59
13. Appendix B - Implementation Options Discussion . . . . . . . . 60
13.1. Appearance Implementation Options . . . . . . . . . . . . 60
13.1.1. URI parameter Approach . . . . . . . . . . . . . . . . 60
13.1.2. Dialog Package Parameter . . . . . . . . . . . . . . . 61
13.1.3. Appearance Selections Mechanisms . . . . . . . . . . . 64
13.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . 67
13.2.1. Comparison of Appearance Selection Methods . . . . . . 67
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 68
15. Security Considerations . . . . . . . . . . . . . . . . . . . 69
16. Informative References . . . . . . . . . . . . . . . . . . . . 69
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70
Intellectual Property and Copyright Statements . . . . . . . . . . 72
Johnston, et al. Expires May 6, 2009 [Page 3]
Internet-Draft SIP Shared Appearances November 2008
1. Introduction
The feature and functionality requirements for SIP user agents (UAs)
supporting business telephony applications differ greatly from basic
SIP user agents, both in terms of services and end user experience.
In addition to basic SIP support [RFC3261], many of the services in a
business environment require the support for SIP extensions such as
REFER [RFC3515], SUBSCRIBE/NOTIFY primitives [RFC3265], PUBLISH
[RFC3903], the SIP Replaces [RFC3891], and Join [RFC3911], header
fields, etc. Many of the popular business services have been
documented in the SIP Service Examples
[I-D.ietf-sipping-service-examples].
This specification details a method for implementing a group
telephony feature known in telephony as Bridged Line Appearance (BLA)
or Multiple Line Appearances (MLA), one of the more popular advanced
features expected of SIP IP telephony devices in a business
environment. Other names for this feature include Shared Call/Line
Appearance (SCA), Shared Call Status and Multiple Call Appearance
(MCA). A variant of this feature is known as Single Line Extension.
This document looks at how this feature can be implemented using
standard SIP [RFC3261] in conjunction with [RFC3265] and [RFC3903]
for exchanging status among user agents, and the SIP dialog state
event package [RFC4235] to exchange dialog state information to
achieve the same. Different approaches will be discussed including
the use of URI parameters, feature tags, and dialog package
extensions along with the strengths and weaknesses of the various
approaches.
A call flow for Single Line Extension was formerly included in the
SIP Service Examples [I-D.ietf-sipping-service-examples]. However,
the attempt to implement using standard SIP primitives ultimately
failed, leading to its removal from that document. This document
defines SIP extensions to implement this service.
In traditional telephony, the line is physical. A common scenario in
telephony is for a number of business telephones to share a single or
a small number of lines. The sharing or appearance of these lines
between a number of phones is what gives this feature its. A common
scenario in SIP is for a number of business telephones to share a
single or a small number of Address of Record (AOR) URIs. In
addition, an AOR can have multiple appearances on a single UA in
terms of the user interface. The appearance number relates to the
user interface for the telephone - typically each appearance or an
AOR has a visual display (lamp that can change color or blink) and a
button (used to select the appearance). The telephony concept of
line appearance is still relevant to SIP due to the user interface
Johnston, et al. Expires May 6, 2009 [Page 4]
Internet-Draft SIP Shared Appearances November 2008
considerations. It is important to keep the appearance number
construct because:
1. Human users are used to the concept and will expect it in
replacement systems (e.g. an overhead page announcement says "Joe
pickup line 3").
2. It is a useful structure for user interface representation.
In this document, we will use the term "appearance" rather than "line
appearance" since SIP does not have the concept of lines. Note that
this does not mean that a conventional telephony user interface
(lamps and buttons) must be used - implementations may use another
metaphor as long as the appearance number is readily apparent to the
user. Each AOR has a separate appearance numbering space. As a
result, a given UA user interface may have multiple occurrences of
the same appearance number, but they will be for different AORs.
2. Conventions used in this document
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 RFC-2119 [RFC2119] and
indicate requirement levels for compliant mechanisms.
3. Usage Scenarios
The following examples are common applications of the Shared
Appearances feature and are mentioned here as informative use cases.
All these example usages can be supported by the Shared Appearances
feature described in this document. The differences relate to the
user interface considerations of the device.
3.1. Executive/Assistant Arrangement
The appearances on the executive's UA also appear on the assistant's
UA. The assistant may answer incoming calls to the executive and
then place the call on hold for the executive to pick up. The
assistant can always see the state of all calls on the executive's
UA. An assistant can make outgoing calls using the identity of
either the executive or their own.
3.2. Call Group
Users with similar business needs or tasks can be assigned to
specific groups and share the line appearances of each other on each
others SIP telephony devices. For example, an IT department staff of
Johnston, et al. Expires May 6, 2009 [Page 5]
Internet-Draft SIP Shared Appearances November 2008
five might answer a help line which has three appearances on each
phone in the IT work area. A call answered on one phone can be put
on hold and picked up on another phone. A shout or an IM to another
staff member can result in them taking over a call on a particular
appearance. Another phone can request to be added to an appearance
resulting in a conference call.
3.3. Single Line Extension
In this scenario, incoming calls are offered to a group of UAs. When
one answers, the other UAs are informed. If another UA in the group
selects the line (i.e. goes off hook), it is immediately bridged or
joined in with the call. This mimics the way residential telephone
extensions usually operate.
4. Requirements
The basic requirements of the shared appearance feature can be
summarized as follows:
REQ-1 Incoming calls to the AOR must be offered to a group of UAs and
can be answered by any of them.
REQ-2 Each UA in the group must be able to learn the call status of
the others in the group for the purpose of rendering this information
to the user.
REQ-3 Calls can be joined (also called bridged or conferenced
together) or can be picked up (taken) by another UA in the group in a
secure way.
REQ-4 The mechanism should require the minimal amount of
configuration. UAs registering against the group AOR should be able
to learn about each other and join the appearance group.
REQ-5 The mechanism must scale for large numbers of appearances, n,
and large numbers of UAs, N, without introducing excessive messaging
traffic.
REQ-6 Each call or session (incoming or outgoing) must be assigned a
common "appearance" number from a managed pool administered for the
AOR group. Once the session has terminated, the appearance number is
released back into the pool and can be reused by another incoming or
outgoing session.
REQ-7 Each UA in the group must be able to learn the appearance
status of the the group.
Johnston, et al. Expires May 6, 2009 [Page 6]
Internet-Draft SIP Shared Appearances November 2008
REQ-8 There must be mechanisms to resolve appearance contention among
the UAs in the group.
REQ-9 The mechanism must allow all UAs receiving an incoming session
request to select the same appearance number at the time of alerting.
REQ-10 The mechanism must have a way of reconstructing appearance
state after an outage that does not result in excessive traffic and
processing.
REQ-11 The mechanism must have backwards compatibility such that a UA
which is unaware of the feature can still register against the group
AOR and make and receive calls.
REQ-12 The mechanism must not allow UAs outside the group to select
or manipulate appearance numbers.
REQ-13 For privacy reasons, there must be a mechanism so that
appearance information is not leaked outside the group of UAs. (e.g.
"So who do you have on line 1?")
REQ-14 The mechanism must support a way for UAs to request
exclusivity on a line appearance. Exclusivity means that the UA
requesting it desires to have a private conversation with the
external party and other UAs must not be allowed to be joined or
taken. Exclusivity may be requested at the start of an incoming or
outgoing session or during the session. An exclusivity request may
be accepted or rejected by the entity providing the shared appearance
service. Therefore, the mechanism must provide a way of
communicating the result back to the requester UA.
REQ-15 The mechanism should support a way for a UA to select a
particular appearance number for outgoing requests prior to sending
the actual request. This is often called seizure.
REQ-16 The mechanism should support a way for a UA to select a
particular appearance number and also send the request at the same
time. This is needed when a ringdown feature is combined with shared
appearances - in this case, seizing the line is the same thing as
dialing.
OPEN ISSUE: This requirement is no longer supported by the proposed
solution. Is this OK?
5. Normative Description
This section normatively describes the shared appearance feature
Johnston, et al. Expires May 6, 2009 [Page 7]
Internet-Draft SIP Shared Appearances November 2008
extensions. For a discussion of various approaches to implement this
feature, see Appendix B.
5.1. Implementation
Many of the requirements for this service can be met using standard
SIP mechanisms such as:
- A SIP Forking Proxy and Registrar/Location Service meets REQ-1.
- The SIP Dialog Package meets REQ-2.
- The SIP Replaces and Join header fields meets REQ-3.
- The SIP Registration Package meets REQ-4.
- The use of a State Agent for the Dialog Package meets REQ-5.
REQ-6 suggests the need for an entity which manages the appearance
resource. Just as conferencing systems commonly have a single point
of control, known as a focus, a Shared Appearance group has a single
point of control of the appearance shared resource. This is defined
as an Appearance Agent for a group. While an Appearance Agent can be
part of a centralized server, it could also be co-resident in a
member User Agent who has taken on this functionality for a group.
The Appearance Agent learns the group state either dialog state
publications from members.
While the appearance resource could be managed co-operatively by a
group of UAs without any central control, this is not discussed in
this draft, but instead is left as a research project for future
standardization. It is also possible that the Appearance Agent logic
could be distributed in all UAs in the group. For example, rules
that govern assigning appearance numbers for incoming requests (e.g.
lowest available appearance number) and rules for contention handling
(e.g. when two UAs request the use of the same appearance number,
hash dialog identifiers and compare with the lowest hash winning)
would need to be defined and implemented.
Figure 1 illustrates the SIP components involved in supporting these
common requirements of the Shared Appearance using standard SIP
messages including REGISTER, INVITE, SUBSCRIBE, NOTIFY, and PUBLISH.
Johnston, et al. Expires May 6, 2009 [Page 8]
Internet-Draft SIP Shared Appearances November 2008
+----------------------------+ +----+
| | | |
| Appearance Agent | | UA |
| | | |
+----------------------------+ +----+
^ ^ |1)SUBSCRIBE ^ ^ 4)NOTIFY INVITE |
| | |(Event:reg) | | registration sip:alice@example.com|
| | V | | events V
| | +--------------------+ +----------+7)Query+--------+
| | | (example.com) | | |<===== | |
| | | |3) Store| Location | | Proxy |
| | | Registrar |=======>| Service | | |
| | | | | |=====> | |
| | +--------------------+ +----------+8)Resp +--------+
| | ^ ^ | |
| | | | 2) REGISTER (alice) | |
| | | | | |
| | +----+ +----+ | |
| | | | | | | |
| | |UA1 | |UA2 | | |
| | | | | | | |
| | +----+ +----+ | |
| | ^ ^ ^ ^ | |
| | | | | | | |
| +----+ | | | | |
| | | +--------------------------------------+ |
| +----+-------------------------------------------+
| | 8) INVITE
+--------------+ sip:alice@example.com
5-7) SUBSCRIBE and/or PUBLISH
(Event:dialog)
OPEN ISSUE: This figure still shows the use of the registration event
package by the Appearance Agent - do we still need this?
Figure 1.
The next section discusses normal SIP operations used to implement
parts of the shared appearance feature.
1. The Appearance Agent SUBSCRIBEs to the registration event package
as outlined in [RFC3680] for contacts registered to the group
AOR. Thus, it has knowledge of all User Agents registered
against the AOR at any point of time.
2. UAs (UA1 and UA2 in Figure 1) belong to the appearance group and,
after authentication, register against the same AOR (e.g.,
sip:alice@example.com).
Johnston, et al. Expires May 6, 2009 [Page 9]
Internet-Draft SIP Shared Appearances November 2008
3. Each registration is stored in the Location Service.
4. The registrar notifies the Appearance Agent of successful
registration at each UA.
5. UAs PUBLISH their dialog state to the State Agent in the
Appearance Agent.
6. The UAs SUBSCRIBE to the Appearance Agent for the state of all
dialogs as defined in [RFC3265]. The Request-URI of the
SUBSCRIBE could be either the AOR of the group or a provisioned
URI.
7. The UAs PUBLISH their dialog information to the Appearance Agent
every time their dialog state changes (i.e. send an INVITE, enter
alerting state, answer a call, terminate a call, etc.), pickups
or joins a call, or seizes/selects an appearance.
8. The Forking Proxy forks an incoming INVITE for the AOR address to
the registered user agents.
The Appearance Agent can select the appearance number for an incoming
call
OPEN ISSUE: Do we want to define another mode of operation in
which UAs only PUBLISH to seize an appearance? This assumes the
Appearance Agent already knows about all dialogs related to the
AOR and could publish that information to the UAs in the shared
appearance group. This approach would simply UA operation and
reduce the number of SIP messages sent and received. If a
different SIP option tag was defined for this server mode, an
Appearance Agent could indicate support for this feature by
including it in a Supported in NOTIFYs. The UA could also include
the option tag in a Require header field in the initial PUBLISH.
A 200 OK response to the PUBLISH would confirm that the UA does
not need to PUBLISH any more state for the dialog.
5.2. Shared Appearance Dialog Package Extensions
This specification defines four new elements as extensions to the SIP
Dialog Event package [RFC3265]. The schema is defined in Section 6.
The elements are , , , and
which are sub-elements of the
F7 Proxy ----> Bob
INVITE sip:alice@ua3.example.com SIP/2.0
Via: SIP/2.0/UDP ua3.example.com;branch=z9hG4bK4324ea695b5B376A
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK38432ji
From: ;tag=44BAD75D-E3128D42
Johnston, et al. Expires May 6, 2009 [Page 26]
Internet-Draft SIP Shared Appearances November 2008
To:
CSeq: 106 INVITE
Call-ID: 14-1541707345@example.com
Contact:
Max-Forwards: 69
Alert-Info: ;alert=normal;appearance=1
Content-Type: application/sdp
Content-Length: 223
v=0
o=- 1102980499 1102980499 IN IP4 ua3.example.com
s=
c=IN IP4 ua3.example.com
t=0 0
a=sendrecv
m=audio 2238 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
F8 Proxy ----> Alice
INVITE sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/UDP ua3.example.com;branch=z9hG4bK4324ea695b5B376A
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK348281
From: ;tag=44BAD75D-E3128D42
To:
CSeq: 106 INVITE
Call-ID: 14-1541707345@example.com
Contact:
Max-Forwards: 69
Alert-Info: ;alert=normal;appearance=1
Content-Type: application/sdp
Content-Length: 223
v=0
o=- 1102980499 1102980499 IN IP4 ua3.example.com
s=
c=IN IP4 ua3.example.com
t=0 0
a=sendrecv
m=audio 2238 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
Johnston, et al. Expires May 6, 2009 [Page 27]
Internet-Draft SIP Shared Appearances November 2008
F15: Bob notifies the Appearance Agent with dialog state
payload indicating the dialog in confirmed state. Appearance
Agent notifies Alice of the status of the dialog at Bob.
F15 Bob ----> Appearance Agent
PUBLILSH sip:appearance-agent@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK58a0dd68C2D63263
From: ;tag=558C18F7-DB9DF7BC
To: ;tag=1894685100249086
CSeq: 14 PUBLISH
Call-ID: 77-505889516@example.com
Contact:
Event: dialog;shared
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Content-Length: ...
1
false
confirmed
sip:carol@ua.example.com
10.3. Outgoing Call with Without Appearance Pre-Selection
In this scenario, Bob's UA places a call without first selecting an
appearance number. After sending the INVITE, Bob sends out a dialog
event PUBLISH with state (trying) but does not include an appearance
Johnston, et al. Expires May 6, 2009 [Page 28]
Internet-Draft SIP Shared Appearances November 2008
number or the 'shared' dialog event parameter. As a result, the
Appearance agent treats the publish as if it were sent by an shared
appearance-unaware UA and assigns an appearance number for it. The
NOTIFY from the appearance agent tells Bob what appearance number to
use. Bob also publishes on receipt of the 180 Ringing and 200 OK
responses. Note that NOTIFYs F16 and F25 do not tell Bob any new
information and could be suppressed by the Appearance Agent.
Carol Proxy Alice Appearance Agent Bob
| | | | |
| | | | |
| |<------------------------------------- INVITE F1<|
| | | | |
| |>F2 100 Trying --------------------------------->|
|<-- INVITE F3<| | | |
| | | |<----- PUBLISH F4<|
| | | | |
| | | |>F5 200 OK ------>|
| | |<-- NOTIFY F6<| |
| | | | |
| | |>F7 200 OK -->| |
| | | |------- NOTIFY F8>|
| | | | |
| | | |F10 180 --->| | | |
| |>F11 180 Ringing ------------------------------->|
| | | | |
| | | |<---- PUBLISH F12<|
| | | | |
| | | |>F13 200 OK ----->|
| | |<- NOTIFY F14<| |
| | | | |
| | |>F15 200 OK ->| |
| | | |------ NOTIFY F16>|
| | | | |
| | | |F18 200 OK ->| | | |
| |>F19 200 OK ------------------------------------>|
| | | | |
| | | |<---- PUBLISH F20<|
| | | | |
| | | |>F21 200 OK ----->|
| | | | |
| |<--------------------------------------- ACK F22<|
|<---- ACK F23<| | | |
| | | | |
|<================= Both way RTP established ===================>|
| | | | |
Johnston, et al. Expires May 6, 2009 [Page 29]
Internet-Draft SIP Shared Appearances November 2008
| | |<- NOTIFY F24<| |
| | | | |
| | |>F25 200 OK ->| |
| | | |------ NOTIFY F26>|
| | | | |
| | | | Proxy
INVITE sip:carol@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK98c87c52123A08BF
From: ;tag=15A3DE7C-9283203B
To:
CSeq: 1 INVITE
Call-ID: f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com
Contact:
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 223
v=0
o=- 1102980499 1102980499 IN IP4 ua2.example.com
s=IP SIP UA
c=IN IP4 ua2.example.com
t=0 0
a=sendrecv
m=audio 2236 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
F4 Bob ----> Appearance Agent
PUBLISH sip:appearance-agent@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
From: ;tag=44150CC6-A7B7919D
To: ;tag=428765950880801
CSeq: 7 PUBLISH
Call-ID: 144-1289338424@example.com
Contact:
Event: dialog
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Johnston, et al. Expires May 6, 2009 [Page 30]
Internet-Draft SIP Shared Appearances November 2008
Content-Length: ...
false
trying
F5 Appearance Agent ----> Bob
SIP/2.0 200 OK
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
CSeq: 7 PUBLISH
Call-ID: 144-1289338424@example.com
From: ;tag=44150CC6-A7B7919D
To: ;tag=428765950880801
Allow-Events: dialog
Contact:
Expires: 60
Content-Length: 0
F8 Appearance Agent ----> Bob
NOTIFY sip:bob@ua1.example.com SIP/2.0
From: ;tag=497585728578386
To: ;tag=633618CF-B9C2EDA4
Call-ID: a7d559db-d6d7dcad-311c9e3a@ua1.example.com
CSeq: 7 NOTIFY
Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1711759878512309
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Event: dialog;shared
Subscription-State: active
Contact:
Content-Length: ...
Johnston, et al. Expires May 6, 2009 [Page 31]
Internet-Draft SIP Shared Appearances November 2008
0
false
trying
F9 Bob ----> Appearance Agent
SIP/2.0 200 OK
Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1711759878512309
From: ;tag=497585728578386
To: ;tag=633618CF-B9C2EDA4
CSeq: 7 NOTIFY
Call-ID: a7d559db-d6d7dcad-311c9e3a@ua1.example.com
Contact:
Event: dialog;shared
Content-Length: 0
F20 Bob ----> Appearance Agent
PUBLISH sip:appearance-agent@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa39d3f69D4E20602
From: ;tag=44150CC6-A7B7919D
To: ;tag=428765950880801
CSeq: 9 PUBLISH
Call-ID: 144-1289338424@example.com
Contact:
Event: dialog;shared
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Content-Length: ...
confirmed
0
false
sip:carol@example.com
10.4. Outgoing Call with Appearance Selection
In this scenario, Bob's UA sends out a dialog event PUBLISH with
state (trying) selecting an appearance number before sending the
INVITE. After receiving the 200 OK from the Appearance Agent
confirming the appearance number, Bob's UA sends the INVITE to Carol
and establishes a session. For brevity, details of some of the
messages are not included in the message flows.
Carol Proxy Alice Appearance Agent Bob
| | | | |
| | | |<----- PUBLISH F1<|
| | | | |
| | | |>F2 200 OK ------>|
| | | | |
| |<------------------------------------- INVITE F3<|
| | | | |
| |>F4 100 Trying --------------------------------->|
|<-- INVITE F5<| | | |
| | |<-- NOTIFY F6<| |
| | | | |
| | |>F7 200 OK -->| |
| | | |------- NOTIFY F8>|
| | | | |
Johnston, et al. Expires May 6, 2009 [Page 33]
Internet-Draft SIP Shared Appearances November 2008
| | | |F10 180 --->| | | |
| |>F11 180 Ringing ------------------------------->|
| | | | |
| | | |<---- PUBLISH F12<|
| | | | |
| | | |>F13 200 OK ----->|
| | |<- NOTIFY F14<| |
| | | | |
| | |>F15 200 OK ->| |
| | | |------ NOTIFY F16>|
| | | | |
| | | |F18 200 OK ->| | | |
| |>F19 200 OK ------------------------------------>|
| | | | |
| | | |<---- PUBLISH F20<|
| | | | |
| | | |>F21 200 OK ----->|
| | | | |
| |<--------------------------------------- ACK F22<|
|<---- ACK F23<| | | |
| | | | |
|<================= Both way RTP established ===================>|
| | | | |
| | |<- NOTIFY F24<| |
| | | | |
| | |>F25 200 OK ->| |
| | | |------ NOTIFY F26>|
| | | | |
| | | | Appearance Agent
PUBLISH sip:appearance-agent@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
From: ;tag=44150CC6-A7B7919D
To: ;tag=428765950880801
CSeq: 7 PUBLISH
Call-ID: 144-1289338424@example.com
Contact:
Event: dialog;shared
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Content-Length: ...
0
false
trying
F2 Appearance Agent ----> Bob
SIP/2.0 200 OK
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
CSeq: 7 PUBLISH
Call-ID: 144-1289338424@example.com
From: ;tag=44150CC6-A7B7919D
To: ;tag=428765950880801
Allow-Events: dialog
Contact:
Expires: 60
Content-Length: 0
F8 Appearance Agent ----> Bob
Johnston, et al. Expires May 6, 2009 [Page 35]
Internet-Draft SIP Shared Appearances November 2008
NOTIFY sip:bob@ua1.example.com SIP/2.0
From: ;tag=497585728578386
To: ;tag=633618CF-B9C2EDA4
Call-ID: a7d559db-d6d7dcad-311c9e3a@ua1.example.com
CSeq: 7 NOTIFY
Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1711759878512309
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Event: dialog;shared
Subscription-State: active
Contact:
Content-Length: ...
0
false
trying
F9 Bob ----> Appearance Agent
SIP/2.0 200 OK
Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1711759878512309
From: ;tag=497585728578386
To: ;tag=633618CF-B9C2EDA4
CSeq: 7 NOTIFY
Call-ID: a7d559db-d6d7dcad-311c9e3a@ua1.example.com
Contact:
Event: dialog;shared
Content-Length: 0
Johnston, et al. Expires May 6, 2009 [Page 36]
Internet-Draft SIP Shared Appearances November 2008
10.5. Outgoing Call without using an Appearance Number
In this scenario, Bob's UA sends out a dialog event PUBLISH with
state (trying) indicating that he does not want to utilize an
appearance number for this dialog. The PUBLISH does not have an
appearance element but does have the 'shared' dialog event parameter.
As a result, the Appearance Agent knows the UA does not wish to use
an appearance number for this call. If the Appearance Agent does not
wish to allow this, it would reject the PUBLISH with a 409 Conflict
response and the UA would know to re-PUBLISH selecting an appearance
number.
Carol Proxy Alice Appearance Agent Bob
| | | | |
| | | |<----- PUBLISH F1<|
| | | | |
| | | |>F2 200 OK ------>|
| | | | |
| |<------------------------------------- INVITE F3<|
| | | | |
| |>F4 100 Trying --------------------------------->|
|<-- INVITE F5<| | | |
| | |<-- NOTIFY F6<| |
| | | | |
| | |>F7 200 OK -->| |
| | | |------- NOTIFY F8>|
| | | | |
| | | |F10 180 --->| | | |
| |>F11 180 Ringing ------------------------------->|
| | | | |
| | | |<---- PUBLISH F12<|
| | | | |
| | | |>F13 200 OK ----->|
| | |<- NOTIFY F14<| |
| | | | |
| | |>F15 200 OK ->| |
| | | |------ NOTIFY F16>|
| | | | |
| | | |F18 200 OK ->| | | |
| |>F19 200 OK ------------------------------------>|
| | | | |
| | | |<---- PUBLISH F20<|
| | | | |
| | | |>F21 200 OK ----->|
| | | | |
| |<--------------------------------------- ACK F22<|
Johnston, et al. Expires May 6, 2009 [Page 37]
Internet-Draft SIP Shared Appearances November 2008
|<---- ACK F23<| | | |
| | | | |
|<================= Both way RTP established ===================>|
| | | | |
| | |<- NOTIFY F24<| |
| | | | |
| | |>F25 200 OK ->| |
| | | |------ NOTIFY F26>|
| | | | |
| | | | Appearance Agent
PUBLISH sip:appearance-agent@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
From: ;tag=44150CC6-A7B7919D
To: ;tag=428765950880801
CSeq: 7 PUBLISH
Call-ID: 144-1289338424@example.com
Contact:
Event: dialog;shared
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Content-Length: ...
false
trying
Johnston, et al. Expires May 6, 2009 [Page 38]
Internet-Draft SIP Shared Appearances November 2008
10.6. Appearance Release
Bob and Carol are in a dialog, created in one of the previous two
call flows. Carol sends a BYE to Bob to terminate the dialog. Bob
publishes the termination of the dialog and the Appearance Agent de-
allocates the appearance number used.
Carol Proxy Alice Appearance Agent Bob
| | | | |
| | | | |
|<================= Both way RTP established ===================>|
| | | | |
|>F28 BYE ---->| | | |
| |>F29 BYE --------------------------------------->|
| | | | |
| |<------------------------------------ 200 OK F30<|
|<--200 OK F31<| | | |
| | | |<---- PUBLISH F32<|
| | | | |
| | | |>F33 200 OK ----->|
| | |<- NOTIFY F34<| |
| | | | |
| | |>F35 200 OK ->| |
| | | |------ NOTIFY F36>|
| | | | |
| | | | Appearance Agent
PUBLISH sip:appearance-agent@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
From: ;tag=44150CC6-A7B7919D
To: ;tag=428765950880801
CSeq: 37 PUBLISH
Call-ID: 65144-1289338424@example.com
Contact:
Event: dialog;shared
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Content-Length: ...
0
terminated
10.7. Appearance Pickup
In this scenario, Bob has an established dialog with Carol created
using the call flows of Figure 2 or Figure 3. Bob then places Carol
on hold. Alice receives a notification of this and renders this on
Alice's UI. Alice subsequently picks up the held call and has a
established session with Carol. Finally, Carol hangs up.
Carol Proxy Alice Appearance Agent Bob
| | | | |
|<================= Both way RTP established ===================>|
| | | | |
| |<------------------------------(hold) INVITE F28<|
|<- INVITE F29<| | | |
| | | | |
|>F30 200 OK ->| | | |
| |>F31 200 OK ------------------------------------>|
| | | | |
| |<--------------------------------------- ACK F32<|
|<---- ACK F33<| | | |
| | | |<---- PUBLISH F34<|
| | | | |
| | | |>F35 200 OK ----->|
| | |<- NOTIFY F36<| |
| | | | |
| | |>F37 200 OK ->| |
| | | |>F38 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F39<|
| | | | |
| | Alice decides to pick up the call |
| | | | |
| | |>F40 PUBLISH->| |
| | | | |
| | |<- 200 OK F41<| |
| | | | |
| | |<- NOTIFY F42<| |
Johnston, et al. Expires May 6, 2009 [Page 40]
Internet-Draft SIP Shared Appearances November 2008
| | | | |
| | |>F43 200 OK ->| |
| | | |>F44 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F45<|
| |<-- INVITE F46<| | |
|<- INVITE F47<|(w/ Replaces) | | |
|( w/ Replaces)| | | |
|>F48 200 OK ->| | | |
| |>F49 200 OK -->| | |
| | |>F50 PUBLISH->| |
| | | | |
| | |<- 200 OK F51<| |
| | | |>F52 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F53<|
| | |<- NOTIFY F54<| |
| | | | |
| | |>F55 200 OK ->| |
| | | | |
| |<----- ACK F56<| | |
|<---- ACK F57<| | | |
| | | | |
|<= Both way RTP established =>| | |
| | | | |
|>F58 BYE ---->| | | |
| |>F59 BYE --------------------------------------->|
| | | | |
| |<------------------------------------ OK 200 F60<|
|<- 200 OK F61<| | | |
| | | | |
| | | |<---- PUBLISH F62<|
| | | | |
| | | |>F63 200 OK ----->|
| | |<- NOTIFY F64<| |
| | | | |
| | |>F65 200 OK ->| |
| | | | |
| | | |>F66 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F67<|
Figure 8.
F28 to F33: Bob places Carol on hold.
F34 to F39: Bob notifies Appearance Agent of the status of the dialog to
indicate the held state. It indicates this by setting the sip.rendering
Johnston, et al. Expires May 6, 2009 [Page 41]
Internet-Draft SIP Shared Appearances November 2008
parameter in the NOTIFY payload to (no). Appearance Agent notifies
Alice of the same.
F34 Bob ----> Appearance Agent
PUBLISH sip:appearance-agent@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A
From: ;tag=44150CC6-A7B7919D
To: ;tag=428765950880801
CSeq: 11 PUBLISH
Call-ID: 144-1289338424@example.com
Contact:
Event: dialog;shared
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Content-Length: ...
0
false
active
sip:carol@example.com
F40 Alice ----> Appearance Agent
PUBLISH sip:appearance-agent@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A
Johnston, et al. Expires May 6, 2009 [Page 42]
Internet-Draft SIP Shared Appearances November 2008
From: ;tag=44150CC6-A7B7919D
To: ;tag=428765950880801
CSeq: 11 PUBLISH
Call-ID: 1289338424@example.com
Contact:
Event: dialog;shared
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Content-Length: ...
0
false
trying
F46: Alice picks up the held call by sending an INVITE with
Replaces: header . Session is established between Alice and
Carol. The dialog between Carol and Bob is terminated.
F46 Bob ----> Proxy
INVITE sip:carol@example.com SIP/2.0
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK4ea695b5B376A60C
From: ;tag=8C4183CB-BCEAB710
To:
CSeq: 1 INVITE
Call-ID: 3d57cd17-47deb849-dca8b6c6@ua1.example.com
Johnston, et al. Expires May 6, 2009 [Page 43]
Internet-Draft SIP Shared Appearances November 2008
Contact:
Replaces: f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com;to-tag=65a98f7c
-1dd2-11b2-88c6-b03162323164+65a98f7c;from-tag=15A3DE7C-9283203B
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 223
v=0
o=- 1102980497 1102980497 IN IP4 ua1.example.com
s=IP SIP UA
c=IN IP4 ua1.example.com
t=0 0
a=sendrecv
m=audio 2238 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
10.8. Calls between UAs within the Group
In this scenario, Bob calls Alice who is also in the Appearance
group. He chooses to allocate an appearance.
Carol Proxy Alice Appearance Agent Bob
| | | | |
| |<-------------------- INVITE (to Alice's UA) F1<|
| | | | |
| | | |<----- PUBLISH F2<|
| | | | |
| | | |>F3 200 OK ------>|
| | | | |
| | |<-- NOTIFY F4<| |
| | | | |
| | |>F5 200 OK -->| |
| | | |>F6 NOTIFY ------>|
| | | | |
| | | |<------ 200 OK F7<|
| |>F8 INVITE --->| | |
| | (appearance=1)| | |
| | | | |
| |<------ 180 F9<| | |
| | | | |
| |>F10 180 -------------------------------------->|
| | | | |
Johnston, et al. Expires May 6, 2009 [Page 44]
Internet-Draft SIP Shared Appearances November 2008
| | | |<---- PUBLISH F11<|
| | | | |
| | | |>F12 200 OK ----->|
| | |<- NOTIFY F13<| |
| | | | |
| | |>F14 200 OK ->| |
| | | |>F15 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F16<|
| | | | |
| | | | |
| |<-- 200 OK F17<| | |
| | |>F18 PUBLISH->| |
| | | | |
| | |<- 200 OK F19<| |
| | | | |
| | |<- NOTIFY F20<| |
| | | | |
| | |>F21 200 OK ->| |
| | | |>F22 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F23<|
| | | | |
| |>F24 200 OK ------------------------------------>|
| | | | |
| |<--------------------------------------- ACK F25<|
| | | | |
| |>F26 ACK ----->| | |
| | | | |
| | |<======= RTP established =======>|
| | | | |
| | | |<---- PUBLISH F27<|
| | | | |
| | | |>F28 200 OK ----->|
| | |<- NOTIFY F29<| |
| | | | |
| | |>F30 200 OK ->| |
| | | |>F31 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F32<|
| | | | |
Figure 9.
F2 Bob ----> Appearance Agent
PUBLISH sip:appearance-agent@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A
Johnston, et al. Expires May 6, 2009 [Page 45]
Internet-Draft SIP Shared Appearances November 2008
From: ;tag=44150CC6-A7B7919D
To: ;tag=428765950880801
CSeq: 11 PUBLISH
Call-ID: 144-1289338424@example.com
Contact:
Event: dialog
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Content-Length: ...
true
trying
sip:alice@example.com
F6 Appearance Agent ----> Bob
NOTIFY sip:bob@ua1.example.com SIP/2.0
From: ;tag=497585728578386
To: ;tag=633618CF-B9C2EDA4
Call-ID: a7d559db-d6d7dcad-311c9e3a@ua1.example.com
CSeq: 7 NOTIFY
Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1711759878512309
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Event: dialog;shared
Subscription-State: active
Contact:
Content-Length: ...
Johnston, et al. Expires May 6, 2009 [Page 46]
Internet-Draft SIP Shared Appearances November 2008
true
1
trying
sip:alice@example.com
10.9. Consultation Hold with Appearances
In this scenario, Bob has a call with Carol. Bob makes a
consultation call to Alice by putting Carol on hold and calling
Alice. Bob chooses not to have an appearance number for the call to
Alice since he is treating it as part of the call to Carol. He
indicates this in his PUBLISH F34 which is sent before the INVITE to
Alice to ensure no appearance number is assigned by the Appearance
Agent. Finally, Bob hangs up with Alice and resumes the call with
Carol.
Note that if Carol hangs up while Bob is consulting with Alice, Bob
can decide if he wants to reuse the appearance number used with Carol
for the call with Alice. If not, Bob publishes the termination of
the dialog with Carol and the Appearance Agent will re-allocate the
appearance. If he wants to keep the appearance, Bob will publish the
termination of the dialog with Carol and also publish the appearance
with the dialog with Alice. This will result in Bob keeping the
appearance number until he reports the dialog with Alice terminated.
Carol Proxy Alice Appearance Agent Bob
| | | | |
|<================= Both way RTP established ===================>|
| | | | |
Johnston, et al. Expires May 6, 2009 [Page 47]
Internet-Draft SIP Shared Appearances November 2008
| |<------------------------------(hold) INVITE F28<|
|<- INVITE F29<| | | |
| | | | |
|>F30 200 OK ->| | | |
| |>F31 200 OK ------------------------------------>|
| | | | |
| |<--------------------------------------- ACK F32<|
|<---- ACK F33<| | | |
| | | |<---- PUBLISH F34<|
| | | | |
| | | |>F35 200 OK ----->|
| | |<- NOTIFY F36<| |
| | | | |
| | |>F37 200 OK ->| |
| | | |>F38 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F39<|
| | | | |
| | Bob makes a consultation call to Alice |
| | | | |
| | | |<---- PUBLISH F40<|
| | | | |
| | | |>F41 200 OK ----->|
| | | | |
| |<------------------------------------ INVITE F42<|
| | | | |
| | |<- NOTIFY F43<| |
| | | | |
| | |>F44 200 OK ->| |
| | | |>F45 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F46<|
| |>F47 INVITE -->| | |
| | | | |
| |<-- 200 OK F48<| | |
| | |>F49 PUBLISH->| |
| | | | |
| | |<- 200 OK F50<| |
| | | | |
| | |<- NOTIFY F51<| |
| | | | |
| | |>F52 200 OK ->| |
| | | |>F53 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F54<|
| | | | |
| |>F55 200 OK ------------------------------------>|
| | | | |
Johnston, et al. Expires May 6, 2009 [Page 48]
Internet-Draft SIP Shared Appearances November 2008
| |<--------------------------------------- ACK F56<|
| | | | |
| |>F57 ACK ----->| | |
| | | | |
| | |<======= RTP established =======>|
| | | | |
| | | |<---- PUBLISH F58<|
| | | | |
| | | |>F59 200 OK ----->|
| | |<- NOTIFY F60<| |
| | | | |
| | |>F61 200 OK ->| |
| | | |>F62 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F63<|
| | | | |
| | Bob hangs up with Alice |
| | | | |
| |<--------------------------------------- BYE F64<|
| | | | |
| | | |<---- PUBLISH F65<|
| | | | |
| | | |>F66 200 OK ----->|
| | |<- NOTIFY F67<| |
| | | | |
| | |>F68 200 OK ->| |
| | | |>F69 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F70<|
| |>F71 BYE ----->| | |
| | | | |
| |<-- 200 OK F72<| | |
| | |>F73 PUBLISH->| |
| | | | |
| | |<- 200 OK F74<| |
| | | | |
| | |<- NOTIFY F75<| |
| | | | |
| | |>F76 200 OK ->| |
| | | |>F77 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F78<|
| | | | |
| |>F79 200 OK ------------------------------------>|
| | | | |
| | | |<---- PUBLISH F80<|
| | | | |
| | | |>F81 200 OK ----->|
Johnston, et al. Expires May 6, 2009 [Page 49]
Internet-Draft SIP Shared Appearances November 2008
| | |<- NOTIFY F82<| |
| | | | |
| | |>F83 200 OK ->| |
| | | |>F84 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F85<|
| | | | |
| |<----------------------------(unhold) INVITE F86<|
|<- INVITE F87<| | | |
| | | | |
|>F88 200 OK ->| | | |
| |>F89 200 OK ------------------------------------>|
| | | | |
| |<--------------------------------------- ACK F90<|
|<---- ACK F91<| | | |
| | | |<---- PUBLISH F92<|
| | | | |
| | | |>F93 200 OK ----->|
| | |<- NOTIFY F94<| |
| | | | |
| | |>F95 200 OK ->| |
| | | |>F96 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F97<|
| | | | |
|<================= Both way RTP established ===================>|
| | | | |
Figure 10.
F40 Bob ----> Appearance Agent
PUBLISH sip:appearance-agent@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A
From: ;tag=44150CC6-A7B7919D
To: ;tag=428765950880801
CSeq: 11 PUBLISH
Call-ID: 144-1289338424@example.com
Contact:
Event: dialog;shared
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Content-Length: ...
true
trying
sip:alice@example.com
F45 Appearance Agent ----> Bob
NOTIFY sip:bob@ua1.example.com SIP/2.0
From: ;tag=497585728578386
To: ;tag=633618CF-B9C2EDA4
Call-ID: a7d559db-d6d7dcad-311c9e3a@ua1.example.com
CSeq: 7 NOTIFY
Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1711759878512309
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Event: dialog;shared
Subscription-State: active
Contact:
Content-Length: ...
true
trying
Johnston, et al. Expires May 6, 2009 [Page 51]
Internet-Draft SIP Shared Appearances November 2008
sip:alice@example.com
10.10. Joining or Bridging an Appearance
In this call flow, a call answered by Bob is joined by Alice or
"bridged". The Join header field is used by Alice to request this
bridging. If Bob did not support media mixing, Bob could obtain
conferencing resources as described in [RFC4579].
Carol Forking Proxy Appearance Agent Alice Bob
| | | | |
|<=============Both way RTP established===========>|
| | | | |
| | |< PUBLISH F28| |
| | | | |
| | |>F29 200 OK >| |
| | | | |
| |<---- INVITE (w/ Join) F30<| |
| | | | |
| |>F31 INVITE (w/Join)---------------->|
| | | | |
| | |>F32 NOTIFY >| |
| | | | |
| | |< 200 OK F33<| |
| | | | |
| | |>F34 NOTIFY ---------->|
| | | | |
| | |F38 200 OK ---------->|
| | | | |
| | |>F39 NOTIFY >| |
| | | | |
| | |< 200 OK F40<| |
| | | | |
| | |>F41 NOTIFY ---------->|
Johnston, et al. Expires May 6, 2009 [Page 52]
Internet-Draft SIP Shared Appearances November 2008
| | | | |
| | |F43 200 OK Contact:B----->| |
| | | | |
| | |< PUBLISH F44| |
| | | | |
| | |>F45 200 OK >| |
| | | | |
| | |>F46 NOTIFY >| |
| | | | |
| | |< 200 OK F47<| |
| | | | |
| | |>F48 NOTIFY ---------->|
| | | | |
| | |ACK F51---------------------------->|
| | | | |
| |<-----INVITE Contact:Bob;isfocus F52<|
|<-INVITE F53| | | |
| | | | |
|>F54 200 -->| | | |
| |>F55 200 OK ------------------------>|
| | | | |
| |<--------------------------- ACK F56<|
|<--- ACK F57| | | |
| | | |<==RTP==>|
|<=============Both way RTP established===========>|
| | | | |
| | |<--------- PUBLISH F58<|
| | | | |
| | |>F59 200 OK ---------->|
| | | | |
| | |>F60 NOTIFY >| |
| | | | |
| | |< 200 OK F61<| |
| | | | |
| | |>F62 NOTIFY ---------->|
| | | | |
| | | Appearance Agent
Johnston, et al. Expires May 6, 2009 [Page 53]
Internet-Draft SIP Shared Appearances November 2008
PUBLISH sip:appearance-agent@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A
From: ;tag=44150CC6-A7B7919D
To: ;tag=428765950880801
CSeq: 11 PUBLISH
Call-ID: 1289338424@example.com
Contact:
Event: dialog;shared
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Content-Length: ...
0
false
trying
F20 Alice ----> Proxy
INVITE sip:bob@ua.example.com SIP/2.0
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKcc9d727c2C29BE31
From: ;tag=605AD957-1F6305C2
To:
CSeq: 2 INVITE
Call-ID: dc95da63-60db1abd-d5a74b48@ua1.example.com
Contact:
Join: 14-1541707345@example.com;to-tag=d3b06488-1dd1-11b2-88c5
Johnston, et al. Expires May 6, 2009 [Page 54]
Internet-Draft SIP Shared Appearances November 2008
-b03162323164+d3e48f4c;from-tag=44BAD75D-E3128D42
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 223
v=0
o=- 1103061265 1103061265 IN IP4 ua1.example.com
s=IP SIP UA
c=IN IP4 ua1.example.com
t=0 0
a=sendrecv
m=audio 2236 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
10.11. Appearance Allocation - Loss of Appearance
Bob reserves an appearance with a PUBLISH, sends an INVITE to Carol,
then becomes unreachable. When he fails to refresh his publication
to the appearance agent, the Appearance Agent declares the dialog
terminated and frees up the appearance using NOTIFYs R24 and F26.
After retransmitting the NOTIFY F26 to Bob, the subscription is
terminated.
Johnston, et al. Expires May 6, 2009 [Page 55]
Internet-Draft SIP Shared Appearances November 2008
Carol Proxy Alice Appearance Agent Bob
| | | | |
| | | |<----- PUBLISH F1<|
| | | | |
| | | |>F2 200 OK ------>|
| | | | |
| |<------------------------------------- INVITE F3<|
| | | | |
| |>F4 100 Trying --------------------------------->|
|<-- INVITE F5<| | | |
| | |<-- NOTIFY F6<| |
| | | | |
| | |>F7 200 OK -->| |
| | | |------- NOTIFY F8>|
| | | | |
| | | |F10 180 --->| | | |
| |>F11 180 Ringing ------------------------------->|
| | | | |
| | | | Bob goes offline
| | | |
| | | Appearance selection times out
| | | |
| | | |
| | |<- NOTIFY F24<|
| | | |
| | |>F25 200 OK ->|
| | | |------ NOTIFY F26>
| | | |
| | | NOTIFY is retransmitted
Figure 12.
10.12. Appearance Selection Contention Race Condition
Bob and Alice both try to reserve appearance 2 by publishing at the
same time. The Appearance Agent allocates the appearance to Bob by
sending a 200 OK and denies it to Alice by sending a 409 Conflict.
After the NOTIFY F24, Alice learns that Bob is using appearance 2.
Alice republishes for appearance 3 which is accepted.
Johnston, et al. Expires May 6, 2009 [Page 56]
Internet-Draft SIP Shared Appearances November 2008
Carol Proxy Alice Appearance Agent Bob
| | | | |
| | | |<----- PUBLISH F1<|
| | | | (appearance=2)
| | |>F2 PUBLISH ->| |
| | | (appearance=2) |
| | | | |
| | | |>F2 200 OK ------>|
| | |<---- F3 409 <| |
| | | | |
| | |<-- NOTIFY F4<| |
| | | | |
| | |>F5 200 OK -->| |
| | | |------- NOTIFY F6>|
| | | | |
| | | |F9 100 Trying --------------------------------->|
|<- INVITE F10<| | | |
| | |>F11 PUBLISH->| |
| | | (appearance=3) |
| | | | |
| | |<--- F12 200 <| |
| | | | |
| | |<- NOTIFY F13<| |
| | | | |
| |>F14 200 OK ->| |
Dave | | |------ NOTIFY F15>|
| | | | |
| | | |F18 100 Trying ------------->| |
|<- INVITE F19<| | | |
Figure 13.
11. IANA Considerations
This section registers the SIP Alert-Info header field parameter
"appearance" and the XML namespace extensions to the SIP Dialog
Package.
Johnston, et al. Expires May 6, 2009 [Page 57]
Internet-Draft SIP Shared Appearances November 2008
11.1. SIP Event Package Parameter: shared
This specification also defines a new event parameter 'shared' for
the Dialog Package. When used in a NOTIFY, it indicates that the
notifier supports the shared appearance feature. When used in a
PUBLISH, it indicates that the publisher has explicit appearance
information contained in the message body. If not present in a
PUBLISH, the Appearance Agent MAY assign an appearance number to any
new dialogs in the message body.
11.2. URN Sub-Namespace Registration: sa-dialog-info
This section registers a new XML namespace per the procedures in
[RFC3688].
URI: urn:ietf:params:xml:ns:sa-dialog-info.
Registrant Contact: IETF BLISS working group, ,
Alan Johnston
XML:
BEGIN
Shared Appearance Dialog Information Namespace
Namespace for Shared Appearance Dialog Information
urn:ietf:params:xml:ns:dialog-info
See
RFCXXXX.
END
Johnston, et al. Expires May 6, 2009 [Page 58]
Internet-Draft SIP Shared Appearances November 2008
11.3. XML Schema Registration
This section registers an XML schema per the procedures in [RFC3688].
URI: urn:ietf:params:xml:schesa:sa-dialog-info.
Registrant Contact: IETF BLISS working group, ,
Alan Johnston
The XML for this schema can be found in .
12. Appendix A - Incoming Appearance Assignment
To best meet REQ-9, the appearance number for an incoming INVITE
should be contained in the INVITE itself.
For the dialog package parameter approach, REQ-9 could be met in two
ways. When an incoming request is received, the Appearance Agent
could send out a NOTIFY with state trying and include the appearance
number to be used for this request. Upon receipt of this NOTIFY, the
UAs could begin alerting using the appearance number selected. This
approach is sub-optimal since the UAs could receive the INVITE but be
unable to begin alerting if the NOTIFY from the Appearance Agent is
delayed or lost
An alternative approach is to define an extension parameter for the
Alert-Info header field in RFC 3261 such as:
Alert-Info: ;alert=normal;appearance=0
This Alert-Info header would indicate to place the call on the first
line appearance instance.
OPEN ISSUE: What URI do we use if no special ring is requested?
The determination as to what value to use in the appearance parameter
can be done at the proxy that forks the incoming request to all the
registered UAs. There are a variety of ways the proxy can use to
determine what value it should use to populate this parameter. For
example, the proxy could fetch this information by initiating a
SUBSCRIBE request with Expires: 0 to the Appearance Agent for the AOR
to fetch the list of lines that are in use. Alternatively, it could
act like a UA that is a part of the appearance group and SUBSCRIBE to
the State-Agent like any other UA. This would ensure that the active
dialog information is available without having to poll on a need
basis. It could keep track of the list of active calls for the
Johnston, et al. Expires May 6, 2009 [Page 59]
Internet-Draft SIP Shared Appearances November 2008
appearance AOR based on how many unique INVITE requests it has forked
to or received from the appearance AOR. Another approach would be
for the Proxy to first send the incoming INVITE to the Appearance
Agent which would redirect to the appearance group URI and escape the
proper Alert-Info header field for the Proxy to recurse and
distribute to the other UAs in the group.
The Appearance Agent needs to know about all incoming requests to the
AOR in order to select the appearance number. One way in which this
could be done is for the Appearance Agent to register against the AOR
with a higher q value. This will result in the INVITE being sent to
the Appearance Agent first, then being offered to the UAs in the
group.
The changes to RFC 3261 ABNF would be:
alert-param = LAQUOT absoluteURI RAQUOT *( SEMI (generic-param /
appearance-param) )
appearance-param = "appearance" EQUAL *DIGIT
13. Appendix B - Implementation Options Discussion
This section discusses some options on how to implement the Shared
Appearances feature in SIP. This section is non-normative.
13.1. Appearance Implementation Options
This section discusses and compares two methods of implementing,
conveying, and selecting appearances in SIP while meeting the
requirements of Section 4. One approach involves a URI parameter and
is discussed in section 5.1.1. The other approach uses a SIP dialog
package extension parameter and is discussed in section 5.1.2. Both
approaches assume the common elements and operations of Figure 1. In
addition, this section discusses approaches for incoming appearance
indication, REQ-9, and appearance contention, REQ-8. These
approaches will be discussed for an example appearance group of N
phones each with n line appearances. The usage of the word phone
does not imply that this feature is limited to telephony devices.
13.1.1. URI parameter Approach
Some implementations of this feature utilize a URI parameter such as
"line=3" on the Contact URI. Each appearance is effectively a
logical UA, so each line appearance requires a separate registration.
The number of line appearances needs to be provisioned on each phone.
Each appearance also requires a separate dialog package subscription.
Johnston, et al. Expires May 6, 2009 [Page 60]
Internet-Draft SIP Shared Appearances November 2008
Even using a State Agent for the dialog package, each phone must
maintain n subscriptions to the dialog package.
This results in 2nN total subscriptions and nN registrations for this
implementation.
Since Contact URI parameters will be conveyed by the dialog package,
REQ-7 is met.
REQ-10 can be met by having the Appearance Agent send a SUBSCRIBE to
each UA and line number to obtain the current dialog state - this
will result in nN SUBSCRIBEs and NOTIFYs.
It is not obvious how to meet REQ-11 with this approach. A UA
registering against the AOR but does not implement the appearance URI
parameter will not include a line appearance number in Contact URIs
and dialog package NOTIFYs. The Appearance Agent will have no way of
indicating to the other UAs the appearance number being used by this
UA, as adding a parameter to the Contact URI would cause call control
operations such as Replaces and Join to fail.
REQs 12 and 13 are difficult to meet with this approach as the line
appearance number will be present in the Request-URI of incoming
requests and the Contact URI in INVITE and 200 OK messages. This
approach will require integrity protection of all dialog creating
requests and responses, and privacy mechanisms to hide the Contact
URI from other UAs.
Also, this approach will require mechanisms to protect against
another UA sending an INVITE directly to a group member with the line
appearance number already set.
13.1.2. Dialog Package Parameter
Instead of the URI parameter approach, consider an extension
parameter "appearance" to the SIP dialog package. The e.g.:
Johnston, et al. Expires May 6, 2009 [Page 61]
Internet-Draft SIP Shared Appearances November 2008
2
false
connected
...
In this approach, the appearance number is never carried in a
Request-URI or Contact URI. Instead, it is only present in dialog
package NOTIFY and PUBLISH messages. As a result, only a single
registration per AOR is required. Also, only a single dialog package
subscription in each direction per AOR.
This results in 2N total subscriptions and N registrations for this
approach.
If the dialog package is extended to carry the appearance number,
then REQ-7 is met.
REQ-10 can be met by having the Appearance Agent send a SUBSCRIBE to
each UA and line number to obtain the current dialog state - this
will result in N SUBSCRIBEs and NOTIFYs.
REQ-11 can be met by this approach. Even though a UA does not
provide an appearance number in dialog package NOTIFYs, the
Appearance Agent can assign one and include it in NOTIFYs to the
other UAs. This parameter would simply be ignored by the UAs that
did not understand the parameter, and have no impact on call control
operations.
REQs 12 and 13 are met because the appearance number is only conveyed
in dialog package NOTIFYs. Integrity and privacy of NOTIFY bodies
can be achieved using normal SIP mechanisms independent of the
security mechanisms used for other requests.
Johnston, et al. Expires May 6, 2009 [Page 62]
Internet-Draft SIP Shared Appearances November 2008
The dialog-package [RFC3265] describes a mechanism whereby shared-
line privacy REQ-14 can be accomplished by suppressing certain dialog
information from being presented to the UAs. The reasoning behind
that is if the UAs were unaware of a dialog's call-id, local-tag and
remote-tag then they will be unable to create requests such as INVITE
with Replaces [RFC3891] and Join [RFC3911] header fields to barge-in
or pickup the line appearance. Below is a quote from section 3.6 of
dialog-package[RFC3265] that describes this approach:
Note that many implementations of "shared-lines" have a feature that
allows details of calls on a shared address-of-record to be made
private. This is a completely reasonable authorization policy that
could result in notifications that contain only the id attribute of
the dialog element and the state element when shared-line privacy is
requested, and notifications with more complete information when
shared-line privacy is not requested.
There are certain fundamental drawbacks in the privacy-by-obscurity
approach described in [RFC3265] . It models exclusivity as a static
property of the appearance AOR. There are situations where
exclusivity needs to be a dynamic property (e.g. boss does not want
secretary to listen-in on a particular part of the conversation). In
addition, [RFC3265] does not address how a UA can request exclusivity
at the start of a session or mid-session and how that request will be
granted or rejected.
Exclusivity being a dynamic property means that a UA can request it
to be turned on or off in the middle of a session. When exclusivity
is turned off all the UAs that share the line AOR will need to see
the complete dialog information. Once they have that information it
can not be taken back from them. This will not allow exclusivity to
be turned on later on in the dialog lifetime. Therefore, there needs
to be a centralized entity that will actually enforce exclusivity.
The approach proposed for meeting REQ-14 is to include an exclusivity
parameter to the dialog package. This allows a UA to request
exclusivity, by setting the exclusive parameter in notifications.
This could be done prior to a call being made or answered, or during
a call at any time. A UA can remove exclusivity by sending a
notification at any time during a call and setting "exclusive=no".
It also allows a UA to learn that a particular dialog is exclusive by
the presence of this parameter in a NOTIFY. In addition, a UA can
still apply policy to any INVITE Join or Replaces requests it
receives, as per normal SIP call control mechanisms.
With this approach, the number of appearances is centrally managed
and controlled by the Appearance Agent. For UAs with soft keys or
buttons, this gives a great deal of flexibility in system management.
Johnston, et al. Expires May 6, 2009 [Page 63]
Internet-Draft SIP Shared Appearances November 2008
The User Agents in the group could SUBSCRIBE to each other and NOTIFY
dialog state events, but in a large group the User Agents have to
manage a larger number of SUBSCRIPTIONS and NOTIFICATIONS. The State
Agent in the Appearance Agent helps in managing large groups better.
Further, the State Agent can filter dialog state events and NOTIFY
User Agents of the dialog state events which are required for the
application or feature. The State Agent can also SUBSCRIBE to dialog
state events with filters to reduce the number of NOTIFY messages
exchanged between the State Agent and the user agents in the group.
This allows a group of N UAs to each only establish a pair of dialog
state subscriptions (one in each direction) to learn the dialog state
of all other group members. This results in 2N total subscriptions
for the entire group. A full mesh of subscriptions without a state
agent would result in N(N-1) total subscriptions.
13.1.3. Appearance Selections Mechanisms
Regardless of how the appearance number is conveyed by UAs, there is
still the issue of how appearance numbers are selected. For example,
some UAs might have actual buttons and lamps, and pressing a
particular button requires the UA to reserve a particular appearance
number. For devices with this type of user interface, the selection
must be done before the user continues with the call and dials digits
or a URI. Other UAs with different user interfaces can be flexible
at the time of dialing, updating the display with the appearance
number at a later date. For devices which require advance appearance
selection, there are three options discussed in the following
sections for meeting REQ-15.
13.1.3.1. Floor Control Appearance Selection Mechanism
This approach models each appearance number as a floor (shared
resource) and uses a floor control server to arbitrate exclusive
access (seizure of a particular appearance number). This approach
uses a standard SIP Event State Compositor (ESC), a standard Floor
Control Server that uses the Appearance Agent as Moderator. The
Binary Floor Control Protocol (BFCP) is used between the UAs and the
Floor Control Server. A Registrar/Forking Proxy Server talks to
Appearance Agent about incoming calls. The Appearance Agent acts as
a Moderator for the floor control server and tells forking proxy to
insert the appearance number in incoming and outgoing requests.
Appearance numbers are allocated/selected/reserved in two ways:
For incoming calls, the Forking Proxy interacts with the Appearance
Agent. The Appearance Agent selects an appearance by taking a
particular floor and marking it "moderator controlled". This
appearance number is then included by the Forking Proxy in INVITEs
Johnston, et al. Expires May 6, 2009 [Page 64]
Internet-Draft SIP Shared Appearances November 2008
using the Alert-Info parameter. When a UA answers the call, it takes
the appearance number from the Alert-Info and includes it in the
dialog state publication. It then requests the floor associated with
the appearance number from the floor control server, which forwards
the request to the Appearance Agent (moderator). The Appearance
Agent correlates the floor control request with the dialog state
notification with the dialog ID from the INVITE with the Alert-Info.
If they match, the floor is granted. If they do not match, it means
the floor request is not an answer of the call but is a random
appearance selection by the UA and will be rejected.
For outgoing calls, the UA sends an INVITE and requests a particular
floor from the floor control server. Depending on the User Interface
requirements, the floor request can be done before or after sending
the INVITE. The floor grant policy for most appearances is set to
"first come first serve". Once the floor has been granted and the
call answered, the dialog state publication by the UA will include
the appearance number.
When a call has ended, the UA releases the floor to the floor control
server and this appearance is now available for incoming and outgoing
calls.
When a UA in the group which does not support BFCP is in a call, the
Appearance Agent will grant the floor associated with that appearance
to that UA. When that call is over, the Appearance Agent will
release the floor. Since the UA will not publish the appearance
number to the ESC, the Appearance Agent will need to do that on their
behalf. If the UA does publish dialog state but without the
appearance number, the Appearance Agent will still need to re-publish
the dialog state including the appearance number. UAs in the group
will be able to recognize these two dialogs as one since they will
have the same SIP dialog ID.
13.1.3.2. INVITE Appearance Selection Mechanism
This is an alternative approach that utilizes sending an INVITE to
select/reserve/seize an appearance number.
A UA that does not need to select a particular appearance number (or
doesn't care) would just send an INVITE as normal. The Appearance
Agent would tell the proxy which appearance number was being used by
inserting this information in a header field in the first non-100
provisional response sent back to the calling UA. The UA would then
PUBLISH this appearance number to the Dialog Event State Compositor
for the AOR which would distribute details of the dialog and the
appearance number to the other UAs in the group.
Johnston, et al. Expires May 6, 2009 [Page 65]
Internet-Draft SIP Shared Appearances November 2008
If an INVITE is sent and no appearance number is available, the proxy
would reject the INVITE with a suitable response code and perhaps a
header field indication.
A UA that does need to select a particular appearance number would
use an approach similar to overlap dialing (multi-stage dialing). An
INVITE would be sent when the appearance number is requested (i.e.
when the button is pressed, before dialing begins). The appearance
number selected would be carried in the INVITE, in a header field or
in the Request-URI, for example. The proxy would reject the INVITE
with a 484 Address Incomplete response (see RFC 3578) if the
appearance number is Available and start a timer. The UA could then
resend the INVITE after the URI has been dialed and then PUBLISH this
appearance number to the ESC. If the appearance number is not
available, another response code such as 403 would be sent. The user
could then select a different appearance number and resend the
INVITE. If no INVITE with a matching Call-ID is received before the
timer expires, the appearance seizure is cancelled and is made
available for other calls.
Note that this approach does not actually require a B2BUA, but it
does require a proxy that can act as a UAS and communicate with an
Appearance Agent which keeps track of appearance number allocations.
13.1.3.3. PUBLISH Appearance Selection Mechanism
The approach used in previous versions of this draft is to use the
PUBLISH to the event state compositor to select an appearance number.
This approach requires a special event state compositor and special
behavior on the part of the UA.
In the selection of an appearance for requests initiated by UAs in
the group, there is the possibility of contention where more than one
UA select the same appearance number.
One way to solve this and meet REQ-8 is to require UAs to send a
notification (trying) to the Appearance Agent indicating the
appearance number to be used for the session. The Appearance Agent
would confirm the allocation of the appearance number in a NOTIFY
sent to the group UAs. Should the appearance number be unavailable
or otherwise not allowed, there are two options:
- The notification could be rejected with a 500 response and a Retry-
After header field. The Appearance Agent would send an immediate
NOTIFY indicating that the appearance is unavailable. If the NOTIFY
is received before the expiration of the Retry-After time, the
notification state information would become out of date and would be
discarded without resending. The UA would select another appearance
Johnston, et al. Expires May 6, 2009 [Page 66]
Internet-Draft SIP Shared Appearances November 2008
number and send another notification.
- The notification could be accepted but an immediate NOTIFY
generated by the Appearance Agent indicating that the appearance is
unavailable. The UA would then select another appearance number and
PUBLISH again.
UAs would wait for a notification from the Appearance Agent before
sending the INVITE.
13.2. Comparison
In comparing the URI parameter and the dialog package parameter,
there are clear differences in the number of registrations and
subscriptions, with the dialog package approach requiring n times
fewer in both cases.
The security model for the dialog package parameter approach is much
cleaner, since only NOTIFY and PUBLISH requests need integrity and
privacy. The security model for the URI parameter approach would
likely require a B2BUA which introduces many undesirable properties.
The dialog package parameter approach has better backwards
compatibility than the URI parameter approach.
In summary, the dialog package parameter approach better meets REQs
5, 10, 11, 12, and 13 while the URI parameter approach better meets
REQ-9. However, the combined dialog package parameter approach and
the Alert-Info parameter approach meets REQ-9.
13.2.1. Comparison of Appearance Selection Methods
All three approaches meet REQ-15 and REQ-16.
Previous versions of this draft proposed the publish/notify method of
appearance selection. The advantage of this approach is that the
appearance number is only carried in one place (dialog package XML
documents) and the same protocol/mechanism is used to select and
learn appearance numbers. The disadvantage of this approach is that
a specialized event state compositor must be used, since it is aware
of appearance numbers. Also, concerns have been raised about whether
this approach defines new semantics for publish/notify beyond that in
RFC 3265.
The floor control approach makes good reuse of existing protocols
such as Binary Floor Control Protocol (BFCP) and cleanly models the
state. However, while BFCP can be used in conferencing applications,
it is unlikely most UAs implementing shared appearances would utilize
Johnston, et al. Expires May 6, 2009 [Page 67]
Internet-Draft SIP Shared Appearances November 2008
the protocol. Also, having appearance state in two places (dialog
package XML documents and floor control messages) complicates the
application. Also, BFCP only runs over TCP and requires a separate
offer/answer exchange to establish the connection, making operation
through NATs and firewalls more difficult. The BFCP approach is also
radically different from all current implementations of this feature.
As a result, standardizing this approach would likely result in an
increase in feature interoperability rather than a decrease.
The INVITE selection mechanism is based on overlap dialing. Overlap
dialing is supported in very few SIP UAs and is regarded as a
somewhat archaic leftover from the PSTN. As such, it is not regarded
as a good starting point for a common feature such as shared
appearances.
The PUBLISH selection mechanism reuses the SIP events extensions
which already must be implemented by UAs supporting this feature. In
fact, it results in no additional messages or round trips. It is
also very similar to many current feature implementations today.
Standardizing this approach is likely to increase overall
interoperability of this feature.
The rest of this document will only discuss the PUBLISH appearance
selection mechanism.
14. Acknowledgements
The following individuals were part of the shared appearance Design
team and have provided input and text to the document (in
alphabetical order):
Martin Dolly, Andrew Hutton, Raj Jain, Fernando Lombardo, Derek
MacDonald, Bill Mitchell, Michael Procter, Theo Zowzouvillys.
Thanks to Chris Boulton for helping with the XML schema.
Much of the material has been drawn from previous work by Mohsen
Soroushnejad, Venkatesh Venkataramanan, Paul Pepper and Anil Kumar,
who in turn received assistance from:
Kent Fritz, John Weald, and Sunil Veluvali of Sylantro Systems, Steve
Towlson, and Michael Procter of Citel Technologies, Rob Harder and
Hong Chen of Polycom Inc, John Elwell, J D Smith of Siemens
Communications, Dale R. Worley of Pingtel, Graeme Dollar of Yahoo
Inc.
Also thanks to Geoff Devine, Paul Kyzivat, Jerry Yin, John Elwell,
Johnston, et al. Expires May 6, 2009 [Page 68]
Internet-Draft SIP Shared Appearances November 2008
Dan York, Spenser Dawkins, Martin Dolly, and Brett Tate for their
comments.
15. Security Considerations
Since multiple line appearance features are implemented using
semantics provided by [RFC3261], Event Package for Dialog State as
define in , and Event Notification [RFC3265], [RFC3903], security
considerations in these documents apply to this draft as well.
Specifically, since dialog state information and the dialog
identifiers are supplied by UA's in an appearance group to other
members, the same is prone to "call hijacks". For example, a rogue
UA could snoop for these identifiers and send an INVITE with Replaces
header containing these call details to take over the call. As such
INVITES with Replaces header MUST be authenticated using the standard
mechanism (like Digest or S/MIME) described in [RFC3261]. before it
is accepted. NOTIFY or PUBLISH message bodies that provide the
dialog state information and the dialog identifiers MAY be encrypted
end-to-end using the standard mechanics. All SUBSCRIBES between the
UA's and the Appearance Agent MUST be authenticated.
16. Informative 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.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
for Event State Publication", RFC 3903, October 2004.
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891,
September 2004.
[I-D.ietf-sipping-service-examples]
Johnston, et al. Expires May 6, 2009 [Page 69]
Internet-Draft SIP Shared Appearances November 2008
Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and
K. Summers, "Session Initiation Protocol Service
Examples", draft-ietf-sipping-service-examples-15 (work in
progress), July 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.
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004.
[RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol
(SIP) "Join" Header", RFC 3911, October 2004.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
November 2002.
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol
(SIP) Call Control - Conferencing for User Agents",
BCP 119, RFC 4579, August 2006.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
Authors' Addresses
Alan Johnston (editor)
Avaya
St. Louis, MO 63124
Email: alan@sipstation.com
Mohsen Soroushnejad
Sylantro Systems Corp
Email: mohsen.soroush@sylantro.com
Johnston, et al. Expires May 6, 2009 [Page 70]
Internet-Draft SIP Shared Appearances November 2008
Venkatesh Venkataramanan
Sylantro Systems Corp
Email: vvenkatar@gmail.com
Johnston, et al. Expires May 6, 2009 [Page 71]
Internet-Draft SIP Shared Appearances November 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.
Johnston, et al. Expires May 6, 2009 [Page 72]