idnits 2.17.1
draft-ietf-bliss-shared-appearances-02.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** The document seems to lack a License Notice according IETF Trust
Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009
Section 6.b -- however, there's a paragraph with a matching beginning.
Boilerplate error?
(You're using the IETF Trust Provisions' Section 6.b License Notice from
12 Feb 2009 rather than one of the newer Notices. See
https://trustee.ietf.org/license-info/.)
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document seems to contain a disclaimer for pre-RFC5378 work, and may
have content which was first submitted before 10 November 2008. The
disclaimer is necessary when there are original authors that you have
been unable to contact, or if some do not wish to grant the BCP78 rights
to the IETF Trust. If you are able to get all authors (current and
original) to grant those rights, you can and should remove the
disclaimer; otherwise, the disclaimer is needed and you can ignore this
comment. (See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (March 9, 2009) is 5528 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Obsolete informational reference (is this intentional?): RFC 3265
(Obsoleted by RFC 6665)
Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 BLISS A. Johnston, Ed.
3 Internet-Draft Avaya
4 Expires: September 10, 2009 M. Soroushnejad
5 V. Venkataramanan
6 Sylantro Systems Corp
7 March 9, 2009
9 Shared Appearances of a Session Initiation Protocol (SIP) Address of
10 Record (AOR)
11 draft-ietf-bliss-shared-appearances-02
13 Status of this Memo
15 This Internet-Draft is submitted to IETF in full conformance with the
16 provisions of BCP 78 and BCP 79. This document may contain material
17 from IETF Documents or IETF Contributions published or made publicly
18 available before November 10, 2008. The person(s) controlling the
19 copyright in some of this material may not have granted the IETF
20 Trust the right to allow modifications of such material outside the
21 IETF Standards Process. Without obtaining an adequate license from
22 the person(s) controlling the copyright in such materials, this
23 document may not be modified outside the IETF Standards Process, and
24 derivative works of it may not be created outside the IETF Standards
25 Process, except to format it for publication as an RFC or to
26 translate it into languages other than English.
28 Internet-Drafts are working documents of the Internet Engineering
29 Task Force (IETF), its areas, and its working groups. Note that
30 other groups may also distribute working documents as Internet-
31 Drafts.
33 Internet-Drafts are draft documents valid for a maximum of six months
34 and may be updated, replaced, or obsoleted by other documents at any
35 time. It is inappropriate to use Internet-Drafts as reference
36 material or to cite them other than as "work in progress."
38 The list of current Internet-Drafts can be accessed at
39 http://www.ietf.org/ietf/1id-abstracts.txt.
41 The list of Internet-Draft Shadow Directories can be accessed at
42 http://www.ietf.org/shadow.html.
44 This Internet-Draft will expire on September 10, 2009.
46 Copyright Notice
48 Copyright (c) 2009 IETF Trust and the persons identified as the
49 document authors. All rights reserved.
51 This document is subject to BCP 78 and the IETF Trust's Legal
52 Provisions Relating to IETF Documents in effect on the date of
53 publication of this document (http://trustee.ietf.org/license-info).
54 Please review these documents carefully, as they describe your rights
55 and restrictions with respect to this document.
57 Abstract
59 This document describes the requirements and implementation of a
60 group telephony feature commonly known as Bridged Line Appearance
61 (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line
62 Appearance (SCA). When implemented using the Session Initiation
63 Protocol (SIP), it is referred to as shared appearances of an Address
64 of Record (AOR) since SIP does not have the concept of lines. This
65 feature is commonly offered in IP Centrex services and IP-PBX
66 offerings and is likely to be implemented on SIP IP telephones and
67 SIP feature servers used in a business environment. This document
68 lists requirements and compares implementation options for this
69 feature. Extensions to the SIP dialog event package are proposed.
71 Table of Contents
73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
74 2. Conventions used in this document . . . . . . . . . . . . . . 6
75 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 6
76 3.1. Executive/Assistant Arrangement . . . . . . . . . . . . . 6
77 3.2. Call Group . . . . . . . . . . . . . . . . . . . . . . . 6
78 3.3. Single Line Extension . . . . . . . . . . . . . . . . . . 7
79 4. Requirements and Implementation . . . . . . . . . . . . . . . 7
80 4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 7
81 4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 8
82 5. Normative Description . . . . . . . . . . . . . . . . . . . . 10
83 5.1. Elements . . . . . . . . . . . . . . . . . . . . . . . . 10
84 5.2. Shared Appearance Dialog Package Extensions . . . . . . . 11
85 5.2.1. The element . . . . . . . . . . . . . . . 11
86 5.2.2. The element . . . . . . . . . . . . . . . 11
87 5.2.3. The element . . . . . . . . . . . . . 11
88 5.2.4. The element . . . . . . . . . . . . 12
89 5.3. Shared Appearance User Agents . . . . . . . . . . . . . . 12
90 5.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . 15
91 6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 16
92 7. User Interface Considerations . . . . . . . . . . . . . . . . 18
93 7.1. Appearance Number Rendering . . . . . . . . . . . . . . . 18
94 7.1.1. Single Appearance UAs . . . . . . . . . . . . . . . . 18
95 7.1.2. Dual Appearance UAs . . . . . . . . . . . . . . . . . 18
96 7.1.3. Shared Appearance UAs with Fixed Appearance Number . . 18
97 7.1.4. Shared Appearance UAs with Variable Appearance
98 Number . . . . . . . . . . . . . . . . . . . . . . . . 19
99 7.2. Call State Rendering . . . . . . . . . . . . . . . . . . 19
100 8. Interop with non-Shared Appearance UAs . . . . . . . . . . . . 20
101 8.1. Appearance Assignment . . . . . . . . . . . . . . . . . . 20
102 8.2. Appearance Release . . . . . . . . . . . . . . . . . . . 20
103 8.3. UAs Supporting Dialog Events but Not Shared Appearance . 21
104 9. Provisioning Considerations . . . . . . . . . . . . . . . . . 21
105 10. Example Message Flows . . . . . . . . . . . . . . . . . . . . 21
106 10.1. Registration and Subscription . . . . . . . . . . . . . . 21
107 10.2. Appearance Selection for Incoming Call . . . . . . . . . 24
108 10.3. Outgoing Call without Appearance Pre-Selection . . . . . 28
109 10.4. Outgoing Call with Appearance Pre-Selection . . . . . . . 30
110 10.5. Outgoing Call without using an Appearance Number . . . . 33
111 10.6. Appearance Release . . . . . . . . . . . . . . . . . . . 35
112 10.7. Appearance Pickup . . . . . . . . . . . . . . . . . . . . 36
113 10.8. Calls between UAs within the Group . . . . . . . . . . . 40
114 10.9. Consultation Hold with Appearances . . . . . . . . . . . 43
115 10.10. Joining or Bridging an Appearance . . . . . . . . . . . . 45
116 10.11. Appearance Allocation - Loss of Appearance . . . . . . . 48
117 10.12. Appearance Selection Contention Race Condition . . . . . 49
118 10.13. Appearance Agent Subscription to UAs . . . . . . . . . . 50
120 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52
121 11.1. SIP Event Package Parameter: shared . . . . . . . . . . . 52
122 11.2. URN Sub-Namespace Registration: sa-dialog-info . . . . . 53
123 11.3. XML Schema Registration . . . . . . . . . . . . . . . . . 53
124 12. Appendix A - Incoming Appearance Assignment . . . . . . . . . 54
125 13. Appendix B - Implementation Options Discussion . . . . . . . . 55
126 13.1. Appearance Implementation Options . . . . . . . . . . . . 55
127 13.1.1. URI parameter Approach . . . . . . . . . . . . . . . . 55
128 13.1.2. Dialog Package Parameter . . . . . . . . . . . . . . . 56
129 13.1.3. Appearance Selections Mechanisms . . . . . . . . . . . 58
130 13.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . 61
131 13.2.1. Comparison of Appearance Selection Methods . . . . . . 62
132 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 63
133 15. Security Considerations . . . . . . . . . . . . . . . . . . . 63
134 16. Informative References . . . . . . . . . . . . . . . . . . . . 64
135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 65
137 1. Introduction
139 The feature and functionality requirements for SIP user agents (UAs)
140 supporting business telephony applications differ greatly from basic
141 SIP user agents, both in terms of services and end user experience.
142 In addition to basic SIP support [RFC3261], many of the services in a
143 business environment require the support for SIP extensions such as
144 REFER [RFC3515], SUBSCRIBE/NOTIFY primitives [RFC3265], PUBLISH
145 [RFC3903], the SIP Replaces [RFC3891], and Join [RFC3911] header
146 fields, etc. Many of the popular business services have been
147 documented in the SIP Service Examples [RFC5359].
149 This specification details a method for implementing a group
150 telephony feature known variously in telephony as Bridged Line
151 Appearance (BLA) or Multiple Line Appearances (MLA), one of the more
152 popular advanced features expected of SIP IP telephony devices in a
153 business environment. Other names for this feature include Shared
154 Call/Line Appearance (SCA), Shared Call Status and Multiple Call
155 Appearance (MCA). A variant of this feature is known as Single Line
156 Extension.
158 This document looks at how this feature can be implemented using
159 standard SIP [RFC3261] in conjunction with SIP events [RFC3265] and
160 publication [RFC3903] for exchanging status among user agents, and
161 the SIP dialog state event package [RFC4235] to exchange dialog state
162 information to achieve the same. Different approaches will be
163 discussed including the use of URI parameters, feature tags, and
164 dialog package extensions along with the strengths and weaknesses of
165 the various approaches.
167 In traditional telephony, the line is physical. A common scenario in
168 telephony is for a number of business telephones to share a single or
169 a small number of lines. The sharing or appearance of these lines
170 between a number of phones is what gives this feature its. A common
171 scenario in SIP is for a number of business telephones to share a
172 single or a small number of Address of Record (AOR) URIs. In
173 addition, an AOR can have multiple appearances on a single UA in
174 terms of the user interface. The appearance number relates to the
175 user interface for the telephone - typically each appearance or an
176 AOR has a visual display (lamp that can change color or blink) and a
177 button (used to select the appearance). The telephony concept of
178 line appearance is still relevant to SIP due to the user interface
179 considerations. It is important to keep the appearance number
180 construct because:
182 1. Human users are used to the concept and will expect it in
183 replacement systems (e.g. an overhead page announcement says "Joe
184 pickup line 3").
186 2. It is a useful structure for user interface representation.
188 In this document, we will use the term "appearance" rather than "line
189 appearance" since SIP does not have the concept of lines. Note that
190 this does not mean that a conventional telephony user interface
191 (lamps and buttons) must be used - implementations may use another
192 metaphor as long as the appearance number is readily apparent to the
193 user. Each AOR has a separate appearance numbering space. As a
194 result, a given UA user interface may have multiple occurrences of
195 the same appearance number, but they will be for different AORs.
197 2. Conventions used in this document
199 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
200 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
201 document are to be interpreted as described in RFC-2119 [RFC2119] and
202 indicate requirement levels for compliant mechanisms.
204 3. Usage Scenarios
206 The following examples are common applications of the Shared
207 Appearances feature and are mentioned here as informative use cases.
208 All these example usages can be supported by the Shared Appearances
209 feature described in this document. The differences relate to the
210 user interface considerations of the device.
212 3.1. Executive/Assistant Arrangement
214 The appearances on the executive's UA also appear on the assistant's
215 UA. The assistant may answer incoming calls to the executive and
216 then place the call on hold for the executive to pick up. The
217 assistant can always see the state of all calls on the executive's
218 UA. An assistant can make outgoing calls using the identity of
219 either the executive or their own.
221 3.2. Call Group
223 Users with similar business needs or tasks can be assigned to
224 specific groups and share the line appearances of each other on each
225 others SIP telephony devices. For example, an IT department staff of
226 five might answer a help line which has three appearances on each
227 phone in the IT work area. A call answered on one phone can be put
228 on hold and picked up on another phone. A shout or an IM to another
229 staff member can result in them taking over a call on a particular
230 appearance. Another phone can request to be added to an appearance
231 resulting in a conference call.
233 3.3. Single Line Extension
235 In this scenario, incoming calls are offered to a group of UAs. When
236 one answers, the other UAs are informed. If another UA in the group
237 selects the line (i.e. goes off hook), it is immediately bridged or
238 joined in with the call. This mimics the way residential telephone
239 extensions usually operate.
241 4. Requirements and Implementation
243 The next section details the requirements and discusses the
244 implementation of the shared appearances of an AOR feature.
246 4.1. Requirements
248 The basic requirements of the shared appearance feature can be
249 summarized as follows:
251 REQ-1 Incoming calls to the AOR must be offered to a group of UAs and
252 can be answered by any of them.
254 REQ-2 Each UA in the group must be able to learn the call status of
255 the others in the group for the purpose of rendering this information
256 to the user.
258 REQ-3 Calls can be joined (also called bridged or conferenced
259 together) or can be picked up (taken) by another UA in the group in a
260 secure way.
262 REQ-4 The mechanism should require the minimal amount of
263 configuration. UAs registering against the group AOR should be able
264 to learn about each other and join the appearance group.
266 REQ-5 The mechanism must scale for large numbers of appearances, n,
267 and large numbers of UAs, N, without introducing excessive messaging
268 traffic.
270 REQ-6 Each call or session (incoming or outgoing) must be assigned a
271 common "appearance" number from a managed pool administered for the
272 AOR group. Once the session has terminated, the appearance number is
273 released back into the pool and can be reused by another incoming or
274 outgoing session.
276 REQ-7 Each UA in the group must be able to learn the appearance
277 status of the the group.
279 REQ-8 There must be mechanisms to resolve appearance contention among
280 the UAs in the group.
282 REQ-9 The mechanism must allow all UAs receiving an incoming session
283 request to select the same appearance number at the time of alerting.
285 REQ-10 The mechanism must have a way of reconstructing appearance
286 state after an outage that does not result in excessive traffic and
287 processing.
289 REQ-11 The mechanism must have backwards compatibility such that a UA
290 which is unaware of the feature can still register against the group
291 AOR and make and receive calls.
293 REQ-12 The mechanism must not allow UAs outside the group to select
294 or manipulate appearance numbers.
296 REQ-13 For privacy reasons, there must be a mechanism so that
297 appearance information is not leaked outside the group of UAs. (e.g.
298 "So who do you have on line 1?")
300 REQ-14 The mechanism must support a way for UAs to request
301 exclusivity on a line appearance. Exclusivity means that the UA
302 requesting it desires to have a private conversation with the
303 external party and other UAs must not be allowed to be joined or
304 taken. Exclusivity may be requested at the start of an incoming or
305 outgoing session or during the session. An exclusivity request may
306 be accepted or rejected by the entity providing the shared appearance
307 service. Therefore, the mechanism must provide a way of
308 communicating the result back to the requester UA.
310 REQ-15 The mechanism should support a way for a UA to select a
311 particular appearance number for outgoing requests prior to sending
312 the actual request. This is often called seizure.
314 REQ-16 The mechanism should support a way for a UA to select a
315 particular appearance number and also send the request at the same
316 time. This is needed when a ringdown feature is combined with shared
317 appearances - in this case, seizing the line is the same thing as
318 dialing.
320 4.2. Implementation
322 Many of the requirements for this service can be met using standard
323 SIP mechanisms such as:
325 - A SIP Forking Proxy and Registrar/Location Service meets REQ-1.
327 - The SIP Dialog Package meets REQ-2.
329 - The SIP Replaces and Join header fields meets REQ-3.
331 - The use of a State Agent for the Dialog Package meets REQ-4 and
332 REQ-5.
334 REQ-6 suggests the need for an entity which manages the appearance
335 resource. Just as conferencing systems commonly have a single point
336 of control, known as a focus, a Shared Appearance group has a single
337 point of control of the appearance shared resource. This is defined
338 as an Appearance Agent for a group. While an Appearance Agent can be
339 part of a centralized server, it could also be co-resident in a
340 member User Agent who has taken on this functionality for a group.
341 The Appearance Agent learns the group state either dialog state
342 publications from members.
344 While the appearance resource could be managed co-operatively by a
345 group of UAs without any central control, this is not discussed in
346 this draft, but instead is left as a research project for future
347 standardization. It is also possible that the Appearance Agent logic
348 could be distributed in all UAs in the group. For example, rules
349 that govern assigning appearance numbers for incoming requests (e.g.
350 lowest available appearance number) and rules for contention handling
351 (e.g. when two UAs request the use of the same appearance number,
352 hash dialog identifiers and compare with the lowest hash winning)
353 would need to be defined and implemented.
355 The next section discusses normal SIP operations used to implement
356 parts of the shared appearance feature.
358 1. A UA is configured with the AOR of a shared appearance group. It
359 registers against the AOR, then attempts a dialog state
360 subscription to the AOR. If the subscription fails, loops back
361 to itself, or returns a 482 Loop Detected, it knows there is no
362 State Agent, and hence no Appearance Agent and this feature is
363 not implemented.
364 2. If the subscription receives a 200 OK, the UA knows there is a
365 State Agent and that the feature is implemented. The UA then
366 follows the steps in this list.
367 3. Information learned about the dialog state of other UAs in the
368 group is rendered to the user.
369 4. Incoming calls are forked to all UAs in the group, and any may
370 answer. UAs receive a notification from the Appearance Agent
371 indicating the appearance number to use in rendering the incoming
372 call. The UA will also receive a notification if the call is
373 answered by another UA in the group so this information can be
374 rendered to the user.
376 5. For outgoing calls, the operation depends on the user input. If
377 the user selects a particular appearance number for the call, the
378 UA publishes this information and waits for a 200 OK before
379 sending the INVITE.
380 6. For outgoing calls, if the user does not select a particular
381 appearance or does not care, the INVITE can be sent immediately,
382 and the appearance number learned as the call progresses from a
383 notification from the Appearance Agent.
384 7. For outgoing calls, if the user does not wish to select an
385 appearance (such as during a consultation call), the UA also
386 publishes this prior to sending the INVITE.
387 8. Established calls within the group may be joined (bridged) or
388 taken (picked) by another UA. Information in the dialog package
389 notifications can be used to construct Join or Replaces header
390 fields. Since the same appearance number is used for these types
391 of operations, this information is published prior to sending the
392 INVITE Join or INVITE Replaces.
393 9. In some cases, the Appearance Agent may not have full access to
394 the complete dialog state of some or all of the UAs in the group.
395 If this is the case, the Appearance Agent will subscribe to the
396 dialog state of individual UAs in the group to obtain this
397 information. Normal notifications will be sent every time the
398 dialog state changes, including calls placed, answered, placed on
399 and off hold, and hangups.
401 5. Normative Description
403 This section normatively describes the shared appearance feature
404 extensions. For a discussion of various approaches to implement this
405 feature, see Appendix B.
407 5.1. Elements
409 A complete system to implement this feature consists of:
411 1. User Agents that support publications, subscriptions, and
412 notifications for the SIP dialog event package, and the shared
413 appearance dialog package extensions and behavior.
414 2. An Appearance Agent consisting of a State Agent for the dialog
415 event package that implements an Event State Compositor (ESC) and
416 the shared appearance dialog package extensions and behavior.
417 The Appearance Agent also has logic for assigning and releasing
418 appearance numbers, and resolving appearance number contention.
419 3. A forking proxy server that can communicate with the State Agent
420 4. A registrar that supports the registration event package.
422 The behavior of these elements is described normatively in the
423 following sections after the definitions of the dialog package
424 extensions.
426 5.2. Shared Appearance Dialog Package Extensions
428 This specification defines four new elements as extensions to the SIP
429 Dialog Event package [RFC3265]. The schema is defined in Section 6.
430 The elements are , , , and
431 which are sub-elements of the
1156
1158 F7 Proxy ----> Bob
1160 INVITE sip:alice@ua3.example.com SIP/2.0
1161 Via: SIP/2.0/UDP ua3.example.com;branch=z9hG4bK4324ea
1162 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK38432ji
1163 From: ;tag=44BAD75D-E3128D42
1164 To:
1165 CSeq: 106 INVITE
1166 Call-ID: 14-1541707345
1167 Contact:
1168 Max-Forwards: 69
1169 Alert-Info: ;alert=normal;appearance=1
1170 Content-Type: application/sdp
1171 Content-Length: 223
1173 v=0
1174 o=- 1102980499 1102980499 IN IP4 ua3.example.com
1175 s=
1176 c=IN IP4 ua3.example.com
1177 t=0 0
1178 a=sendrecv
1179 m=audio 2238 RTP/AVP 0 8 101
1180 a=rtpmap:0 PCMU/8000
1181 a=rtpmap:8 PCMA/8000
1182 a=rtpmap:101 telephone-event/8000
1184 F21 Appearance Agent ----> Alice
1186 NOTIFY sip:alice@ua1.example.com SIP/2.0
1187 From: ;tag=151702541050937
1188 To: ;tag=18433323-C3D237CE
1189 Call-ID: 1e361d2f-a9f51109-bafe31d4
1190 CSeq: 12 NOTIFY
1191 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1403
1192 Max-Forwards: 70
1193 Content-Type: application/dialog-info+xml
1194 Event: dialog;shared
1195 Subscription-State: active
1196 Contact:
1197 Content-Length: ...
1199
1200
1205
1210 1
1211 confirmed
1212
1213 sip:carol@ua.example.com
1215
1216
1217
1219 10.3. Outgoing Call without Appearance Pre-Selection
1221 In this scenario, Bob's UA places a call without first selecting an
1222 appearance number. After Bob sends the INVITE, the appearance
1223 assigns an appearance number for it and notifies both Alice and Bob.
1225 Carol Proxy Alice Appearance Agent Bob
1226 | | | | |
1227 | | | | |
1228 | |<------------------------------------- INVITE F1<|
1229 | | | | |
1230 | |>F2 100 Trying --------------------------------->|
1231 |<-- INVITE F3<| | | |
1232 | | |<-- NOTIFY F4<| |
1233 | | | | |
1234 | | |>F5 200 OK -->| |
1235 | | | |------- NOTIFY F6>|
1236 | | | | |
1237 | | | |F8 180 ---->| | | |
1239 | |>F9 180 Ringing -------------------------------->|
1240 | | | | |
1241 | | |<- NOTIFY F10<| |
1242 | | | | |
1243 | | |>F11 200 OK ->| |
1244 | | | |------ NOTIFY F12>|
1245 | | | | |
1246 | | | |F14 200 OK ->| | | |
1248 | |>F15 200 OK ------------------------------------>|
1249 | | | | |
1250 | |<--------------------------------------- ACK F16<|
1251 |<---- ACK F17<| | | |
1252 | | | | |
1253 |<================= Both way RTP established ===================>|
1254 | | | | |
1255 | | |<- NOTIFY F18<| |
1256 | | | | |
1257 | | |>F19 200 OK ->| |
1258 | | | |------ NOTIFY F20>|
1259 | | | | |
1260 | | | | Proxy
1266 INVITE sip:carol@example.com SIP/2.0
1267 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK98c87c52123A08BF
1268 From: ;tag=15A3DE7C-9283203B
1269 To:
1270 CSeq: 1 INVITE
1271 Call-ID: f3b3cbd0-a2c5775e-5df9f8d5
1272 Contact:
1273 Max-Forwards: 70
1274 Content-Type: application/sdp
1275 Content-Length: 223
1277 v=0
1278 o=- 1102980499 1102980499 IN IP4 ua2.example.com
1279 s=IP SIP UA
1280 c=IN IP4 ua2.example.com
1281 t=0 0
1282 a=sendrecv
1283 m=audio 2236 RTP/AVP 0 8 101
1284 a=rtpmap:0 PCMU/8000
1285 a=rtpmap:8 PCMA/8000
1286 a=rtpmap:101 telephone-event/8000
1288 F6 Appearance Agent ----> Bob
1290 NOTIFY sip:bob@ua1.example.com SIP/2.0
1291 From: ;tag=497585728578386
1292 To: ;tag=633618CF-B9C2EDA4
1293 Call-ID: a7d559db-d6d7dcad-311c9e3a
1294 CSeq: 7 NOTIFY
1295 Via: SIP/2.0/UDP appearanceagent.example.com
1296 ;branch=z9hG4bK1711759878512309
1297 Max-Forwards: 70
1298 Content-Type: application/dialog-info+xml
1299 Event: dialog;shared
1300 Subscription-State: active
1301 Contact:
1302 Content-Length: ...
1304
1305
1310
1313 0
1314 false
1315 trying
1316
1317
1318
1319
1320
1321
1323 10.4. Outgoing Call with Appearance Pre-Selection
1325 In this scenario, Bob's UA sends out a dialog event PUBLISH with
1326 state (trying) selecting an appearance number before sending the
1327 INVITE. After receiving the 200 OK from the Appearance Agent
1328 confirming the appearance number, Bob's UA sends the INVITE to Carol
1329 and establishes a session. For brevity, details of some of the
1330 messages are not included in the message flows.
1332 Carol Proxy Alice Appearance Agent Bob
1333 | | | | |
1334 | | | |<----- PUBLISH F1<|
1335 | | | | |
1336 | | | |>F2 200 OK ------>|
1337 | | | | |
1338 | | |<-- NOTIFY F3<| |
1339 | | | | |
1340 | | |>F4 200 OK -->| |
1341 | | | |------- NOTIFY F5>|
1342 | | | | |
1343 | | | |F8 100 Trying --------------------------------->|
1348 |<-- INVITE F9<| | | |
1349 | | | |<---- PUBLISH F10<|
1350 | | | | |
1351 | | | |>F11 200 OK ----->|
1352 | | | | |
1353 |>F12 180 --->| | | |
1354 | |>F13 180 Ringing ------------------------------->|
1355 | | | | |
1356 | | |<- NOTIFY F14<| |
1357 | | | | |
1358 | | |>F15 200 OK ->| |
1359 | | | |------ NOTIFY F16>|
1360 | | | | |
1361 | | | |F18 200 OK ->| | | |
1363 | |>F19 200 OK ------------------------------------>|
1364 | | | | |
1365 | |<--------------------------------------- ACK F20<|
1366 |<---- ACK F21<| | | |
1367 | | | | |
1368 |<================= Both way RTP established ===================>|
1369 | | | | |
1370 | | |<- NOTIFY F22<| |
1371 | | | | |
1372 | | |>F23 200 OK ->| |
1373 | | | |------ NOTIFY F24>|
1374 | | | | |
1375 | | | | Appearance Agent
1394 PUBLISH sip:alice@example.com SIP/2.0
1395 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
1396 From: ;tag=44150CC6-A7B7919D
1397 To:
1398 CSeq: 7 PUBLISH
1399 Call-ID: 44fwF144-F12893K38424
1400 Contact:
1401 Event: dialog;shared
1402 Max-Forwards: 70
1403 Content-Type: application/dialog-info+xml
1404 Content-Length: ...
1406
1407
1412
1413 0
1414 false
1415 trying
1416
1417
1418
1419
1420
1421
1423 F10 Bob ----> Appearance Agent
1425 PUBLISH sip:alice@example.com SIP/2.0
1426 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK6d644638E7
1427 From: ;tag=0CCf6-A7FdsB79D
1428 To:
1429 CSeq: 437 PUBLISH
1430 Call-ID: fwF14d4-F1FFF2F2893K38424
1431 Contact:
1432 Event: dialog;shared
1433 Max-Forwards: 70
1434 Content-Type: application/dialog-info+xml
1435 Content-Length: ...
1437
1438
1443
1447 0
1448 false
1449 trying
1450
1451
1452
1453
1454
1455
1457 10.5. Outgoing Call without using an Appearance Number
1459 In this scenario, Bob's UA sends out a dialog event PUBLISH with
1460 state (trying) indicating that he does not want to utilize an
1461 appearance number for this dialog. The PUBLISH does not have an
1462 appearance element but does have the 'shared' dialog event parameter.
1463 As a result, the Appearance Agent knows the UA does not wish to use
1464 an appearance number for this call. If the Appearance Agent does not
1465 wish to allow this, it would reject the PUBLISH with a 409 Conflict
1466 response and the UA would know to re-PUBLISH selecting an appearance
1467 number.
1469 Carol Proxy Alice Appearance Agent Bob
1470 | | | | |
1471 | | | |<----- PUBLISH F1<|
1472 | | | | |
1473 | | | |>F2 200 OK ------>|
1474 | | | | |
1475 | | |<-- NOTIFY F3<| |
1476 | | | | |
1477 | | |>F4 200 OK -->| |
1478 | | | |------- NOTIFY F5>|
1479 | | | | |
1480 | | | |F8 100 Trying --------------------------------->|
1485 |<-- INVITE F9<| | | |
1486 | | | |<---- PUBLISH F10<|
1487 | | | | |
1488 | | | |>F11 200 OK ----->|
1489 | | | | |
1490 |>F12 180 --->| | | |
1491 | |>F13 180 Ringing ------------------------------->|
1492 | | | | |
1493 | | |<- NOTIFY F14<| |
1494 | | | | |
1495 | | |>F15 200 OK ->| |
1496 | | | |------ NOTIFY F16>|
1497 | | | | |
1498 | | | |F18 200 OK ->| | | |
1500 | |>F19 200 OK ------------------------------------>|
1501 | | | | |
1502 | |<--------------------------------------- ACK F20<|
1503 |<---- ACK F21<| | | |
1504 | | | | |
1505 |<================= Both way RTP established ===================>|
1506 | | | | |
1507 | | |<- NOTIFY F22<| |
1508 | | | | |
1509 | | |>F23 200 OK ->| |
1510 | | | |------ NOTIFY F24>|
1511 | | | | |
1512 | | | | Appearance Agent
1519 PUBLISH sip:appearanceagent.example.com SIP/2.0
1520 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
1521 From: ;tag=4415df82k39sf
1522 To:
1523 CSeq: 7 PUBLISH
1524 Call-ID: 44fwF144-F12893K38424
1525 Contact:
1526 Event: dialog;shared
1527 Max-Forwards: 70
1528 Content-Type: application/dialog-info+xml
1529 Content-Length: ...
1531
1532
1537
1538 false
1539 trying
1540
1541
1542
1543
1544
1545
1547 10.6. Appearance Release
1549 Bob and Carol are in a dialog, created in one of the previous two
1550 call flows. Carol sends a BYE to Bob to terminate the dialog. Bob
1551 publishes the termination of the dialog and the Appearance Agent de-
1552 allocates the appearance number used.
1554 Carol Proxy Alice Appearance Agent Bob
1555 | | | | |
1556 | | | | |
1557 |<================= Both way RTP established ===================>|
1558 | | | | |
1559 |>F22 BYE ---->| | | |
1560 | |>F23 BYE --------------------------------------->|
1561 | | | | |
1562 | |<------------------------------------ 200 OK F24<|
1563 |<--200 OK F25<| | | |
1564 | | |<- NOTIFY F26<| |
1565 | | | | |
1566 | | |>F27 200 OK ->| |
1567 | | | |------ NOTIFY F28>|
1568 | | | | |
1569 | | | | Bob
1575 NOTIFY sip:bob@ua1.example.com SIP/2.0
1576 From: ;tag=497585728578386
1577 To:
1578 Call-ID: a7d559db-d6d7dcad-311c9e3a
1579 CSeq: 7 NOTIFY
1580 Via: SIP/2.0/UDP appearanceagent.example.com
1581 ;branch=z9hG4bK759878512309
1582 Max-Forwards: 70
1583 Content-Type: application/dialog-info+xml
1584 Event: dialog;shared
1585 Subscription-State: active
1586 Contact:
1587 Content-Length: ...
1589
1590
1595
1600 0
1601 false
1602 terminated
1603
1604
1605
1606
1607
1608
1610 10.7. Appearance Pickup
1612 In this scenario, Bob has an established dialog with Carol created
1613 using the call flows of Figure 1 or Figure 2. Bob then places Carol
1614 on hold. Alice receives a notification of this and renders this on
1615 Alice's UI. Alice subsequently picks up the held call and has a
1616 established session with Carol. Finally, Carol hangs up.
1618 Carol Proxy Alice Appearance Agent Bob
1619 | | | | |
1620 |<================= Both way RTP established ===================>|
1621 | | | | |
1622 | |<------------------------------(hold) INVITE F22<|
1623 |<- INVITE F23<| | | |
1624 | | | | |
1625 |>F24 200 OK ->| | | |
1626 | |>F25 200 OK ------------------------------------>|
1627 | | | | |
1628 | |<--------------------------------------- ACK F26<|
1629 |<---- ACK F27<| | | |
1630 | | |<- NOTIFY F28<| |
1631 | | | | |
1632 | | |>F29 200 OK ->| |
1633 | | | |>F30 NOTIFY ----->|
1634 | | | | |
1635 | | | |<----- 200 OK F31<|
1636 | | | | |
1637 | | Alice decides to pick up the call |
1638 | | | | |
1639 | | |>F32 PUBLISH->| |
1640 | | | | |
1641 | | |<- 200 OK F33<| |
1642 | | | | |
1643 | | |<- NOTIFY F34<| |
1644 | | | | |
1645 | | |>F35 200 OK ->| |
1646 | | | |>F36 NOTIFY ----->|
1647 | | | | |
1648 | | | |<----- 200 OK F37<|
1649 | |<-- INVITE F38<| | |
1650 |<- INVITE F39<|(w/ Replaces) | | |
1651 |( w/ Replaces)| | | |
1652 |>F40 200 OK ->| | | |
1653 | |>F41 200 OK -->| | |
1654 | | | |>F42 NOTIFY ----->|
1655 | | | | |
1656 | | | |<----- 200 OK F43<|
1657 | | |<- NOTIFY F44<| |
1658 | | | | |
1659 | | |>F45 200 OK ->| |
1660 | | | | |
1661 | |<----- ACK F46<| | |
1662 |<---- ACK F47<| | | |
1663 | | | | |
1664 |<= Both way RTP established =>| | |
1665 | | | | |
1666 |>F48 BYE ---->| | | |
1667 | |>F49 BYE --------------------------------------->|
1668 | | | | |
1669 | |<------------------------------------ OK 200 F50<|
1670 |<- 200 OK F51<| | | |
1671 | | | | |
1672 | | |<- NOTIFY F52<| |
1673 | | | | |
1674 | | |>F53 200 OK ->| |
1675 | | | | |
1676 | | | |>F54 NOTIFY ----->|
1677 | | | | |
1678 | | | |<----- 200 OK F55<|
1680 Figure 7.
1682 F28 Appearance ----> Alice
1684 NOTIFY sip:alice@ua1.example.com SIP/2.0
1685 From: ;tag=151702541050937
1686 To: ;tag=18433323-C3D237CE
1687 Call-ID: 1e361d2f-a9f51109-bafe31d4
1688 CSeq: 12 NOTIFY
1689 Via: SIP/2.0/UDP appearanceagent.example.com
1690 ;branch=z9hG4bK1403
1691 Max-Forwards: 70
1692 Content-Type: application/dialog-info+xml
1693 Event: dialog;shared
1694 Subscription-State: active
1695 Contact:
1696 Content-Length: ...
1698
1699
1704
1709 0
1710 false
1711 active
1712
1713
1714
1715
1716
1717
1718 sip:carol@example.com
1719
1720
1721
1722
1724 F32 Alice ----> Appearance Agent
1726 PUBLISH sip:alice@example.com SIP/2.0
1727 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A
1728 From: ;tag=44150CC6-A7B7919D
1729 To: ;tag=428765950880801
1730 CSeq: 11 PUBLISH
1731 Call-ID: 87837Fkw87asfds
1732 Contact:
1733 Event: dialog;shared
1734 Max-Forwards: 70
1735 Content-Type: application/dialog-info+xml
1736 Content-Length: ...
1738
1739
1744
1747 0
1748 false
1749
1753 trying
1754
1755
1756
1757
1759
1760
1761
1762
1763
1764
1766 F38 Alice ----> Proxy
1768 INVITE sip:carol@example.com SIP/2.0
1769 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK4ea695b5B376A60C
1770 From: ;tag=8C4183CB-BCEAB710
1771 To:
1772 CSeq: 1 INVITE
1773 Call-ID: 3d57cd17-47deb849-dca8b6c6
1774 Contact:
1775
1776 Replaces: f3b3cbd0-a2c5775e-5df9f8d5;to-tag=65a98f7c
1777 -1dd2-11b2-88c6-b03162323164+65a98f7c;from-tag=15A3DE7C-9283203B
1778
1779 Max-Forwards: 70
1780 Content-Type: application/sdp
1781 Content-Length: 223
1783 v=0
1784 o=- 1102980497 1102980497 IN IP4 ua1.example.com
1785 s=IP SIP UA
1786 c=IN IP4 ua1.example.com
1787 t=0 0
1788 a=sendrecv
1789 m=audio 2238 RTP/AVP 0 8 101
1790 a=rtpmap:0 PCMU/8000
1791 a=rtpmap:8 PCMA/8000
1792 a=rtpmap:101 telephone-event/8000
1794 10.8. Calls between UAs within the Group
1796 In this scenario, Bob calls Alice who is also in the Appearance
1797 group.
1799 Carol Proxy Alice Appearance Agent Bob
1800 | | | | |
1801 | |<-------------------- INVITE (to Alice's UA) F1<|
1802 | | | | |
1803 | |<- - - - - - ->| | |
1804 | | | | |
1805 | | |<-- NOTIFY F2<| |
1806 | | | | |
1807 | | |>F3 200 OK -->| |
1808 | | | |>F4 NOTIFY ------>|
1809 | | | | |
1810 | | | |<------ 200 OK F5<|
1811 | |>F6 INVITE --->| | |
1812 | | (appearance=1)| | |
1813 | | | | |
1814 | |<------ 180 F7<| | |
1815 | | | | |
1816 | |>F8 180 --------------------------------------->|
1817 | | | | |
1818 | | |<-- NOTIFY F9<| |
1819 | | | | |
1820 | | |>F10 200 OK ->| |
1821 | | | |>F11 NOTIFY ----->|
1822 | | | | |
1823 | | | |<----- 200 OK F12<|
1824 | |<-- 200 OK F13<| | |
1825 | | |<- NOTIFY F14<| |
1826 | | | | |
1827 | | |>F15 200 OK ->| |
1828 | | | |>F16 NOTIFY ----->|
1829 | | | | |
1830 | | | |<----- 200 OK F17<|
1831 | | | | |
1832 | |>F18 200 OK ------------------------------------>|
1833 | | | | |
1834 | |<--------------------------------------- ACK F19<|
1835 | | | | |
1836 | |>F20 ACK ----->| | |
1837 | | | | |
1838 | | |<======= RTP established =======>|
1839 | | | | |
1840 | | |<- NOTIFY F21<| |
1841 | | | | |
1842 | | |>F22 200 OK ->| |
1843 | | | |>F23 NOTIFY ----->|
1844 | | | | |
1845 | | | |<----- 200 OK F24<|
1846 | | | | |
1848 Figure 8.
1850 F16 Appearance Agent ----> Bob
1851 NOTIFY sip:bob@ua1.example.com SIP/2.0
1852 From: ;tag=497585728578386
1853 To: ;tag=633618CF-B9C2EDA4
1854 Call-ID: a7d559db-d6d7dcad-311c9e3a
1855 CSeq: 7 NOTIFY
1856 Via: SIP/2.0/UDP appearanceagent.example.com
1857 ;branch=z9hG4bK1711759878512309
1858 Max-Forwards: 70
1859 Content-Type: application/dialog-info+xml
1860 Event: dialog;shared
1861 Subscription-State: active
1862 Contact:
1863 Content-Length: ...
1865
1866
1871
1876 true
1877 1
1878 connected
1879
1880
1881
1882
1883
1884 sip:alice@example.com
1885
1886
1887
1889
1894 true
1895 1
1896 connected
1897
1898
1900
1901
1902 sip:alice@example.com
1903
1904
1905
1907
1909 10.9. Consultation Hold with Appearances
1911 In this scenario, Bob has a call with Carol. Bob makes a
1912 consultation call to Alice by putting Carol on hold and calling
1913 Alice. Bob chooses not to have an appearance number for the call to
1914 Alice since he is treating it as part of the call to Carol. He
1915 indicates this in his PUBLISH F32 which is sent before the INVITE to
1916 Alice to ensure no appearance number is assigned by the Appearance
1917 Agent. Finally, Bob hangs up with Alice and resumes the call with
1918 Carol. Note that the Appearance Agent does not generate
1919 notifications on the dialog state of the consultation call.
1921 Note that if Carol hangs up while Bob is consulting with Alice, Bob
1922 can decide if he wants to reuse the appearance number used with Carol
1923 for the call with Alice. If not, Bob publishes the termination of
1924 the dialog with Carol and the Appearance Agent will re-allocate the
1925 appearance. If he wants to keep the appearance, Bob will publish the
1926 termination of the dialog with Carol and also publish the appearance
1927 with the dialog with Alice. This will result in Bob keeping the
1928 appearance number until he reports the dialog with Alice terminated.
1930 Carol Proxy Alice Appearance Agent Bob
1931 | | | | |
1932 |<================= Both way RTP established ===================>|
1933 | | | | |
1934 | |<------------------------------(hold) INVITE F22<|
1935 |<- INVITE F23<| | | |
1936 | | | | |
1937 |>F24 200 OK ->| | | |
1938 | |>F25 200 OK ------------------------------------>|
1939 | | | | |
1940 | |<--------------------------------------- ACK F26<|
1941 |<---- ACK F27<| | | |
1942 | | |<- NOTIFY F28<| |
1943 | | | | |
1944 | | |>F29 200 OK ->| |
1945 | | | |>F30 NOTIFY ----->|
1946 | | | | |
1947 | | | |<----- 200 OK F31<|
1948 | | | | |
1949 | | Bob makes a consultation call to Alice |
1950 | | | | |
1951 | | | |<---- PUBLISH F32<|
1952 | | | | |
1953 | | | |>F33 200 OK ----->|
1954 | | | | |
1955 | |<------------------------------------ INVITE F34<|
1956 | | | | |
1957 | |>F35 INVITE -->| | |
1958 | | | | |
1959 | |<-- 200 OK F36<| | |
1960 | | | | |
1961 | |>F37 200 OK ------------------------------------>|
1962 | | | | |
1963 | |<--------------------------------------- ACK F38<|
1964 | | | | |
1965 | |>F39 ACK ----->| | |
1966 | | | | |
1967 | | |<======= RTP established =======>|
1968 | | | | |
1969 | | Bob hangs up with Alice |
1970 | | | | |
1971 | |<--------------------------------------- BYE F40<|
1972 | | | | |
1973 | |>F41 BYE ----->| | |
1974 | | | | |
1975 | |<-- 200 OK F42<| | |
1976 | | | | |
1977 | |>F43 200 OK ------------------------------------>|
1978 | | | | |
1979 | |<----------------------------(unhold) INVITE F44<|
1980 |<- INVITE F45<| | | |
1981 | | | | |
1982 |>F46 200 OK ->| | | |
1983 | |>F47 200 OK ------------------------------------>|
1984 | | | | |
1985 | |<--------------------------------------- ACK F48<|
1986 |<---- ACK F49<| | | |
1987 | | |<- NOTIFY F50<| |
1988 | | | | |
1989 | | |>F51 200 OK ->| |
1990 | | | |>F52 NOTIFY ----->|
1991 | | | | |
1992 | | | |<----- 200 OK F53<|
1993 | | | | |
1994 |<================= Both way RTP established ===================>|
1995 | | | | |
1997 Figure 9.
1999 F32 Bob ----> Appearance Agent
2001 PUBLISH sip:alice@example.com SIP/2.0
2002 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A
2003 From: ;tag=44150CC6-A7B7919D
2004 To: ;tag=428765950880801
2005 CSeq: 11 PUBLISH
2006 Call-ID: 44fwF144-F12893K38424
2007 Contact:
2008 Event: dialog;shared
2009 Max-Forwards: 70
2010 Content-Type: application/dialog-info+xml
2011 Content-Length: ...
2013
2014
2019
2023 true
2024 trying
2025
2026
2027
2028
2029
2030 sip:alice@example.com
2031
2032
2033
2034
2036 10.10. Joining or Bridging an Appearance
2038 In this call flow, a call answered by Bob is joined by Alice or
2039 "bridged". The Join header field is used by Alice to request this
2040 bridging. If Bob did not support media mixing, Bob could obtain
2041 conferencing resources as described in [RFC4579].
2043 Carol Forking Proxy Appearance Agent Alice Bob
2044 | | | | |
2045 |<=============Both way RTP established===========>|
2046 | | | | |
2047 | | |< PUBLISH F22| |
2048 | | | | |
2049 | | |>F23 200 OK >| |
2050 | | | | |
2051 | |<---- INVITE (w/ Join) F24<| |
2052 | | | | |
2053 | |>F25 INVITE (w/Join)---------------->|
2054 | | | | |
2055 | |<---- OK 200 Contact:Bob;isfocus F26<|
2056 | | | | |
2057 | | |>F27 NOTIFY >| |
2058 | | | | |
2059 | | |< 200 OK F28<| |
2060 | | | | |
2061 | | |>F29 NOTIFY ---------->|
2062 | | | | |
2063 | | |F31 200 OK Contact:B----->| |
2066 | | | | |
2067 | |<----------------- ACK F32<| |
2068 | | | | |
2069 | |>ACK F33---------------------------->|
2070 | | | | |
2071 | |<-----INVITE Contact:Bob;isfocus F34<|
2072 |<-INVITE F35| | | |
2073 | | | | |
2074 |>F26 200 -->| | | |
2075 | |>F37 200 OK ------------------------>|
2076 | | | | |
2077 | |<--------------------------- ACK F38<|
2078 |<--- ACK F39| | | |
2079 | | | |<==RTP==>|
2080 |<=============Both way RTP established===========>|
2081 | | | | |
2082 | | |>F40 NOTIFY >| |
2083 | | | | |
2084 | | |< 200 OK F41<| |
2085 | | | | |
2086 | | |>F42 NOTIFY ---------->|
2087 | | | | |
2088 | | | Appearance Agent
2095 PUBLISH sip:alice@example.com SIP/2.0
2096 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A
2097 From: ;tag=44150CC6-A7B7919D
2098 To: ;tag=428765950880801
2099 CSeq: 11 PUBLISH
2100 Call-ID: 87837Fkw87asfds
2101 Contact:
2102 Event: dialog;shared
2103 Max-Forwards: 70
2104 Content-Type: application/dialog-info+xml
2105 Content-Length: ...
2107
2108
2113
2116 0
2117 false
2118
2122 trying
2123
2124
2125
2126
2127
2128
2129
2130
2131
2133 F24 Alice ----> Proxy
2135 INVITE sip:bob@ua.example.com SIP/2.0
2136 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKcc9d727c2C29BE31
2137 From: ;tag=605AD957-1F6305C2
2138 To:
2139 CSeq: 2 INVITE
2140 Call-ID: dc95da63-60db1abd-d5a74b48
2141 Contact:
2142
2143 Join: 14-1541707345;to-tag=d3b06488-1dd1-11b2-88c5
2144 -b03162323164+d3e48f4c;from-tag=44BAD75D-E3128D42
2145
2146 Max-Forwards: 70
2147 Content-Type: application/sdp
2148 Content-Length: 223
2150 v=0
2151 o=- 1103061265 1103061265 IN IP4 ua1.example.com
2152 s=IP SIP UA
2153 c=IN IP4 ua1.example.com
2154 t=0 0
2155 a=sendrecv
2156 m=audio 2236 RTP/AVP 0 8 101
2157 a=rtpmap:0 PCMU/8000
2158 a=rtpmap:8 PCMA/8000
2159 a=rtpmap:101 telephone-event/8000
2161 10.11. Appearance Allocation - Loss of Appearance
2163 Bob reserves an appearance with a PUBLISH, sends an INVITE to Carol,
2164 then becomes unreachable. When he fails to refresh his publication
2165 to the appearance agent, the Appearance Agent declares the dialog
2166 terminated and frees up the appearance using NOTIFYs R24 and F26.
2167 After retransmitting the NOTIFY F26 to Bob, the subscription is
2168 terminated.
2170 Carol Proxy Alice Appearance Agent Bob
2171 | | | | |
2172 | | | |<----- PUBLISH F1<|
2173 | | | | |
2174 | | | |>F2 200 OK ------>|
2175 | | | | |
2176 | | |<-- NOTIFY F3<| |
2177 | | | | |
2178 | | |>F4 200 OK -->| |
2179 | | | |------- NOTIFY F5>|
2180 | | | | |
2181 | | | |F8 100 Trying --------------------------------->|
2186 |<-- INVITE F9<| | | |
2187 | | | |<---- PUBLISH F10<|
2188 | | | | |
2189 | | | |>F11 200 OK ----->|
2190 | | | | |
2191 |>F12 180 --->| | | |
2192 | |>F13 180 Ringing ------------------------------->|
2193 | | | | |
2194 | | | | Bob goes offline
2195 | | | |
2196 | | | Appearance selection times out
2197 | | | |
2198 | | | |
2199 | | |<- NOTIFY F14<|
2200 | | | |
2201 | | |>F15 200 OK ->|
2202 | | | |------ NOTIFY F16>
2203 | | | |
2204 | | | NOTIFY is retransmitted
2206 Figure 11.
2208 10.12. Appearance Selection Contention Race Condition
2210 Bob and Alice both try to reserve appearance 2 by publishing at the
2211 same time. The Appearance Agent allocates the appearance to Bob by
2212 sending a 200 OK and denies it to Alice by sending a 409 Conflict.
2213 After the NOTIFY F24, Alice learns that Bob is using appearance 2.
2214 Alice republishes for appearance 3 which is accepted.
2216 Carol Proxy Alice Appearance Agent Bob
2217 | | | | |
2218 | | | |<----- PUBLISH F1<|
2219 | | | | (appearance=2)
2220 | | |>F2 PUBLISH ->| |
2221 | | | (appearance=2) |
2222 | | | | |
2223 | | | |>F3 200 OK ------>|
2224 | | |<---- F4 409 <| |
2225 | | | | |
2226 | | |<-- NOTIFY F5<| |
2227 | | | | |
2228 | | |>F6 200 OK -->| |
2229 | | | |------- NOTIFY F7>|
2230 | | | | |
2231 | | | |F10 100 Trying -------------------------------->|
2236 |<- INVITE F11<| | | |
2237 | | | |<---- PUBLISH F12<|
2238 | | | | (appearance=2)
2239 | | | |>F13 200 OK ----->|
2240 | | |>F14 PUBLISH->| |
2241 | | | (appearance=3) |
2242 | | | | |
2243 | | |<--- F15 200 <| |
2244 | | | | |
2245 | | |<- NOTIFY F16<| |
2246 | | | | |
2247 | |>F17 200 OK ->| |
2248 Dave | | |------ NOTIFY F18>|
2249 | | | | |
2250 | | | |F21 100 ----->| | |
2254 |<- INVITE F22<| | | |
2256 Figure 12.
2258 10.13. Appearance Agent Subscription to UAs
2260 In this scenario, the Appearance Agent does not have any way of
2261 knowing Bob's dialog state information, except through Bob. This
2262 could be because the Appearance Agent is not part of a B2BUA, or
2263 perhaps Bob is remotely registering. When Bob registers, the
2264 Appearance Agent receives a registration event package notification
2265 from the registrar. The Appearance Agent then SUBSCRIBEs to Bob's
2266 dialog event state. Whenever Bob's dialog state changes, a NOTIFY is
2267 sent to the Appearance Agent who then notifies the other other UAs in
2268 the group.
2270 Carol Proxy Alice Appearance Agent Bob
2271 | | | | |
2272 | |<----------------------------------- REGISTER F1<|
2273 | | | | |
2274 | |>F2 200 OK ------------------------------------->|
2275 | | | | |
2276 | |>F3 NOTIFY ------------------>| |
2277 | | | | |
2278 | |<------------------ 200 OK F4<| |
2279 | | | |---- SUBSCRIBE F5>|
2280 | | | | |
2281 | | | |F8 200 OK ------>|
2286 | | | | |
2287 | | | |<--- SUBSCRIBE F9<|
2288 | | | | |
2289 | | | |>F10 200 OK ----->|
2290 | | | | |
2291 | | | |------ NOTIFY F11>|
2292 | | | | |
2293 | | | |F14 100 Trying -------------------------------->|
2298 |<- INVITE F15<| | | |
2299 | | | |<----- NOTIFY F16<|
2300 | | | | |
2301 | | | |>F17 200 OK ----->|
2302 | | |<- NOTIFY F18<| |
2303 | | | | |
2304 | | |>F19 200 OK ->| |
2305 | | | |------ NOTIFY F20>|
2306 | | | | |
2307 | | | |F22 180 --->| | | |
2309 | |>F23 180 Ringing ------------------------------->|
2310 | | | | |
2311 | | | |<----- NOTIFY F24<|
2312 | | | | |
2313 | | | |>F25 200 OK ----->|
2314 | | |<- NOTIFY F26<| |
2315 | | | | |
2316 | | |>F27 200 OK ->| |
2317 | | | |------ NOTIFY F28>|
2318 | | | | |
2319 | | | |F30 200 OK ->| | | |
2321 | |>F31 200 OK ------------------------------------>|
2322 | | | | |
2323 | | | |<----- NOTIFY F32<|
2324 | | | | |
2325 | | | |>F33 200 OK ----->|
2326 | | | | |
2327 | |<--------------------------------------- ACK F34<|
2328 |<---- ACK F35<| | | |
2329 | | | | |
2330 |<================= Both way RTP established ===================>|
2331 | | | | |
2332 | | |<- NOTIFY F36<| |
2333 | | | | |
2334 | | |>F37 200 OK ->| |
2335 | | | |------ NOTIFY F38>|
2336 | | | | |
2337 | | | |,
2366 Alan Johnston
2368 XML:
2370 BEGIN
2371
2372
2374
2375
2376
2378 Shared Appearance Dialog Information Namespace
2379
2380
2381 Namespace for Shared Appearance Dialog Information
2382 urn:ietf:params:xml:ns:dialog-info
2383 See
2384 RFCXXXX.
2385
2386
2387 END
2389 11.3. XML Schema Registration
2391 This section registers an XML schema per the procedures in
2392 [RFC3688].
2394 URI: urn:ietf:params:xml:schesa:sa-dialog-info.
2396 Registrant Contact: IETF BLISS working group, ,
2397 Alan Johnston
2399 The XML for this schema can be found in Section 6.
2401 12. Appendix A - Incoming Appearance Assignment
2403 To best meet REQ-9, the appearance number for an incoming INVITE
2404 should be contained in the INVITE itself.
2406 For the dialog package parameter approach, REQ-9 could be met in two
2407 ways. When an incoming request is received, the Appearance Agent
2408 could send out a NOTIFY with state trying and include the appearance
2409 number to be used for this request. Upon receipt of this NOTIFY, the
2410 UAs could begin alerting using the appearance number selected. This
2411 approach is sub-optimal since the UAs could receive the INVITE but be
2412 unable to begin alerting if the NOTIFY from the Appearance Agent is
2413 delayed or lost
2415 An alternative approach is to define an extension parameter for the
2416 Alert-Info header field in RFC 3261 such as:
2418 Alert-Info: ;alert=normal;appearance=0
2420 This Alert-Info header would indicate to place the call on the first
2421 line appearance instance.
2423 OPEN ISSUE: What URI do we use if no special ring is requested?
2425 The determination as to what value to use in the appearance parameter
2426 can be done at the proxy that forks the incoming request to all the
2427 registered UAs. There are a variety of ways the proxy can use to
2428 determine what value it should use to populate this parameter. For
2429 example, the proxy could fetch this information by initiating a
2430 SUBSCRIBE request with Expires: 0 to the Appearance Agent for the AOR
2431 to fetch the list of lines that are in use. Alternatively, it could
2432 act like a UA that is a part of the appearance group and SUBSCRIBE to
2433 the State-Agent like any other UA. This would ensure that the active
2434 dialog information is available without having to poll on a need
2435 basis. It could keep track of the list of active calls for the
2436 appearance AOR based on how many unique INVITE requests it has forked
2437 to or received from the appearance AOR. Another approach would be
2438 for the Proxy to first send the incoming INVITE to the Appearance
2439 Agent which would redirect to the appearance group URI and escape the
2440 proper Alert-Info header field for the Proxy to recurse and
2441 distribute to the other UAs in the group.
2443 The Appearance Agent needs to know about all incoming requests to the
2444 AOR in order to select the appearance number. One way in which this
2445 could be done is for the Appearance Agent to register against the AOR
2446 with a higher q value. This will result in the INVITE being sent to
2447 the Appearance Agent first, then being offered to the UAs in the
2448 group.
2450 The changes to RFC 3261 ABNF would be:
2452 alert-param = LAQUOT absoluteURI RAQUOT *( SEMI (generic-param /
2453 appearance-param) )
2455 appearance-param = "appearance" EQUAL *DIGIT
2457 13. Appendix B - Implementation Options Discussion
2459 This section discusses some options on how to implement the Shared
2460 Appearances feature in SIP. This section is non-normative.
2462 13.1. Appearance Implementation Options
2464 This section discusses and compares two methods of implementing,
2465 conveying, and selecting appearances in SIP while meeting the
2466 requirements of Section 4. One approach involves a URI parameter and
2467 is discussed in section 5.1.1. The other approach uses a SIP dialog
2468 package extension parameter and is discussed in section 5.1.2. Both
2469 approaches assume an Appearance Agent. In addition, this section
2470 discusses approaches for incoming appearance indication, REQ-9, and
2471 appearance contention, REQ-8. These approaches will be discussed for
2472 an example appearance group of N phones each with n line appearances.
2473 The usage of the word phone does not imply that this feature is
2474 limited to telephony devices.
2476 13.1.1. URI parameter Approach
2478 Some implementations of this feature utilize a URI parameter such as
2479 "line=3" on the Contact URI. Each appearance is effectively a
2480 logical UA, so each line appearance requires a separate registration.
2481 The number of line appearances needs to be provisioned on each phone.
2482 Each appearance also requires a separate dialog package subscription.
2483 Even using a State Agent for the dialog package, each phone must
2484 maintain n subscriptions to the dialog package.
2486 This results in 2nN total subscriptions and nN registrations for this
2487 implementation.
2489 Since Contact URI parameters will be conveyed by the dialog package,
2490 REQ-7 is met.
2492 REQ-10 can be met by having the Appearance Agent send a SUBSCRIBE to
2493 each UA and line number to obtain the current dialog state - this
2494 will result in nN SUBSCRIBEs and NOTIFYs.
2496 It is not obvious how to meet REQ-11 with this approach. A UA
2497 registering against the AOR but does not implement the appearance URI
2498 parameter will not include a line appearance number in Contact URIs
2499 and dialog package NOTIFYs. The Appearance Agent will have no way of
2500 indicating to the other UAs the appearance number being used by this
2501 UA, as adding a parameter to the Contact URI would cause call control
2502 operations such as Replaces and Join to fail.
2504 REQs 12 and 13 are difficult to meet with this approach as the line
2505 appearance number will be present in the Request-URI of incoming
2506 requests and the Contact URI in INVITE and 200 OK messages. This
2507 approach will require integrity protection of all dialog creating
2508 requests and responses, and privacy mechanisms to hide the Contact
2509 URI from other UAs.
2511 Also, this approach will require mechanisms to protect against
2512 another UA sending an INVITE directly to a group member with the line
2513 appearance number already set.
2515 13.1.2. Dialog Package Parameter
2517 Instead of the URI parameter approach, consider an extension
2518 parameter "appearance" to the SIP dialog package. The e.g.:
2520
2521
2526
2528 2
2529 false
2530
2532
2534 connected
2535
2536
2537
2538
2539
2540 ...
2542 In this approach, the appearance number is never carried in a
2543 Request-URI or Contact URI. Instead, it is only present in dialog
2544 package NOTIFY and PUBLISH messages. As a result, only a single
2545 registration per AOR is required. Also, only a single dialog package
2546 subscription in each direction per AOR.
2548 This results in 2N total subscriptions and N registrations for this
2549 approach.
2551 If the dialog package is extended to carry the appearance number,
2552 then REQ-7 is met.
2554 REQ-10 can be met by having the Appearance Agent send a SUBSCRIBE to
2555 each UA and line number to obtain the current dialog state - this
2556 will result in N SUBSCRIBEs and NOTIFYs.
2558 REQ-11 can be met by this approach. Even though a UA does not
2559 provide an appearance number in dialog package NOTIFYs, the
2560 Appearance Agent can assign one and include it in NOTIFYs to the
2561 other UAs. This parameter would simply be ignored by the UAs that
2562 did not understand the parameter, and have no impact on call control
2563 operations.
2565 REQs 12 and 13 are met because the appearance number is only conveyed
2566 in dialog package NOTIFYs. Integrity and privacy of NOTIFY bodies
2567 can be achieved using normal SIP mechanisms independent of the
2568 security mechanisms used for other requests.
2570 The dialog-package [RFC3265] describes a mechanism whereby shared-
2571 line privacy REQ-14 can be accomplished by suppressing certain dialog
2572 information from being presented to the UAs. The reasoning behind
2573 that is if the UAs were unaware of a dialog's call-id, local-tag and
2574 remote-tag then they will be unable to create requests such as INVITE
2575 with Replaces [RFC3891] and Join [RFC3911] header fields to barge-in
2576 or pickup the line appearance. Below is a quote from section 3.6 of
2577 dialog-package[RFC3265] that describes this approach:
2579 Note that many implementations of "shared-lines" have a feature that
2580 allows details of calls on a shared address-of-record to be made
2581 private. This is a completely reasonable authorization policy that
2582 could result in notifications that contain only the id attribute of
2583 the dialog element and the state element when shared-line privacy is
2584 requested, and notifications with more complete information when
2585 shared-line privacy is not requested.
2587 There are certain fundamental drawbacks in the privacy-by-obscurity
2588 approach described in [RFC3265] . It models exclusivity as a static
2589 property of the appearance AOR. There are situations where
2590 exclusivity needs to be a dynamic property (e.g. boss does not want
2591 secretary to listen-in on a particular part of the conversation). In
2592 addition, [RFC3265] does not address how a UA can request exclusivity
2593 at the start of a session or mid-session and how that request will be
2594 granted or rejected.
2596 Exclusivity being a dynamic property means that a UA can request it
2597 to be turned on or off in the middle of a session. When exclusivity
2598 is turned off all the UAs that share the line AOR will need to see
2599 the complete dialog information. Once they have that information it
2600 can not be taken back from them. This will not allow exclusivity to
2601 be turned on later on in the dialog lifetime. Therefore, there needs
2602 to be a centralized entity that will actually enforce exclusivity.
2604 The approach proposed for meeting REQ-14 is to include an exclusivity
2605 parameter to the dialog package. This allows a UA to request
2606 exclusivity, by setting the exclusive parameter in notifications.
2607 This could be done prior to a call being made or answered, or during
2608 a call at any time. A UA can remove exclusivity by sending a
2609 notification at any time during a call and setting "exclusive=no".
2610 It also allows a UA to learn that a particular dialog is exclusive by
2611 the presence of this parameter in a NOTIFY. In addition, a UA can
2612 still apply policy to any INVITE Join or Replaces requests it
2613 receives, as per normal SIP call control mechanisms.
2615 With this approach, the number of appearances is centrally managed
2616 and controlled by the Appearance Agent. For UAs with soft keys or
2617 buttons, this gives a great deal of flexibility in system management.
2619 The User Agents in the group could SUBSCRIBE to each other and NOTIFY
2620 dialog state events, but in a large group the User Agents have to
2621 manage a larger number of SUBSCRIPTIONS and NOTIFICATIONS. The State
2622 Agent in the Appearance Agent helps in managing large groups better.
2623 Further, the State Agent can filter dialog state events and NOTIFY
2624 User Agents of the dialog state events which are required for the
2625 application or feature. The State Agent can also SUBSCRIBE to dialog
2626 state events with filters to reduce the number of NOTIFY messages
2627 exchanged between the State Agent and the user agents in the group.
2628 This allows a group of N UAs to each only establish a pair of dialog
2629 state subscriptions (one in each direction) to learn the dialog state
2630 of all other group members. This results in 2N total subscriptions
2631 for the entire group. A full mesh of subscriptions without a state
2632 agent would result in N(N-1) total subscriptions.
2634 13.1.3. Appearance Selections Mechanisms
2636 Regardless of how the appearance number is conveyed by UAs, there is
2637 still the issue of how appearance numbers are selected. For example,
2638 some UAs might have actual buttons and lamps, and pressing a
2639 particular button requires the UA to reserve a particular appearance
2640 number. For devices with this type of user interface, the selection
2641 must be done before the user continues with the call and dials digits
2642 or a URI. Other UAs with different user interfaces can be flexible
2643 at the time of dialing, updating the display with the appearance
2644 number at a later date. For devices which require advance appearance
2645 selection, there are three options discussed in the following
2646 sections for meeting REQ-15.
2648 13.1.3.1. Floor Control Appearance Selection Mechanism
2650 This approach models each appearance number as a floor (shared
2651 resource) and uses a floor control server to arbitrate exclusive
2652 access (seizure of a particular appearance number). This approach
2653 uses a standard SIP Event State Compositor (ESC), a standard Floor
2654 Control Server that uses the Appearance Agent as Moderator. The
2655 Binary Floor Control Protocol (BFCP) is used between the UAs and the
2656 Floor Control Server. A Registrar/Forking Proxy Server talks to
2657 Appearance Agent about incoming calls. The Appearance Agent acts as
2658 a Moderator for the floor control server and tells forking proxy to
2659 insert the appearance number in incoming and outgoing requests.
2661 Appearance numbers are allocated/selected/reserved in two ways:
2663 For incoming calls, the Forking Proxy interacts with the Appearance
2664 Agent. The Appearance Agent selects an appearance by taking a
2665 particular floor and marking it "moderator controlled". This
2666 appearance number is then included by the Forking Proxy in INVITEs
2667 using the Alert-Info parameter. When a UA answers the call, it takes
2668 the appearance number from the Alert-Info and includes it in the
2669 dialog state publication. It then requests the floor associated with
2670 the appearance number from the floor control server, which forwards
2671 the request to the Appearance Agent (moderator). The Appearance
2672 Agent correlates the floor control request with the dialog state
2673 notification with the dialog ID from the INVITE with the Alert-Info.
2674 If they match, the floor is granted. If they do not match, it means
2675 the floor request is not an answer of the call but is a random
2676 appearance selection by the UA and will be rejected.
2678 For outgoing calls, the UA sends an INVITE and requests a particular
2679 floor from the floor control server. Depending on the User Interface
2680 requirements, the floor request can be done before or after sending
2681 the INVITE. The floor grant policy for most appearances is set to
2682 "first come first serve". Once the floor has been granted and the
2683 call answered, the dialog state publication by the UA will include
2684 the appearance number.
2686 When a call has ended, the UA releases the floor to the floor control
2687 server and this appearance is now available for incoming and outgoing
2688 calls.
2690 When a UA in the group which does not support BFCP is in a call, the
2691 Appearance Agent will grant the floor associated with that appearance
2692 to that UA. When that call is over, the Appearance Agent will
2693 release the floor. Since the UA will not publish the appearance
2694 number to the ESC, the Appearance Agent will need to do that on their
2695 behalf. If the UA does publish dialog state but without the
2696 appearance number, the Appearance Agent will still need to re-publish
2697 the dialog state including the appearance number. UAs in the group
2698 will be able to recognize these two dialogs as one since they will
2699 have the same SIP dialog ID.
2701 13.1.3.2. INVITE Appearance Selection Mechanism
2703 This is an alternative approach that utilizes sending an INVITE to
2704 select/reserve/seize an appearance number.
2706 A UA that does not need to select a particular appearance number (or
2707 doesn't care) would just send an INVITE as normal. The Appearance
2708 Agent would tell the proxy which appearance number was being used by
2709 inserting this information in a header field in the first non-100
2710 provisional response sent back to the calling UA. The UA would then
2711 PUBLISH this appearance number to the Dialog Event State Compositor
2712 for the AOR which would distribute details of the dialog and the
2713 appearance number to the other UAs in the group.
2715 If an INVITE is sent and no appearance number is available, the proxy
2716 would reject the INVITE with a suitable response code and perhaps a
2717 header field indication.
2719 A UA that does need to select a particular appearance number would
2720 use an approach similar to overlap dialing (multi-stage dialing). An
2721 INVITE would be sent when the appearance number is requested (i.e.
2722 when the button is pressed, before dialing begins). The appearance
2723 number selected would be carried in the INVITE, in a header field or
2724 in the Request-URI, for example. The proxy would reject the INVITE
2725 with a 484 Address Incomplete response (see RFC 3578) if the
2726 appearance number is Available and start a timer. The UA could then
2727 resend the INVITE after the URI has been dialed and then PUBLISH this
2728 appearance number to the ESC. If the appearance number is not
2729 available, another response code such as 403 would be sent. The user
2730 could then select a different appearance number and resend the
2731 INVITE. If no INVITE with a matching Call-ID is received before the
2732 timer expires, the appearance seizure is cancelled and is made
2733 available for other calls.
2735 Note that this approach does not actually require a B2BUA, but it
2736 does require a proxy that can act as a UAS and communicate with an
2737 Appearance Agent which keeps track of appearance number allocations.
2739 13.1.3.3. PUBLISH Appearance Selection Mechanism
2741 The approach used in previous versions of this draft is to use the
2742 PUBLISH to the event state compositor to select an appearance number.
2743 This approach requires a special event state compositor and special
2744 behavior on the part of the UA.
2746 In the selection of an appearance for requests initiated by UAs in
2747 the group, there is the possibility of contention where more than one
2748 UA select the same appearance number.
2750 One way to solve this and meet REQ-8 is to require UAs to send a
2751 notification (trying) to the Appearance Agent indicating the
2752 appearance number to be used for the session. The Appearance Agent
2753 would confirm the allocation of the appearance number in a NOTIFY
2754 sent to the group UAs. Should the appearance number be unavailable
2755 or otherwise not allowed, there are two options:
2757 - The notification could be rejected with a 500 response and a Retry-
2758 After header field. The Appearance Agent would send an immediate
2759 NOTIFY indicating that the appearance is unavailable. If the NOTIFY
2760 is received before the expiration of the Retry-After time, the
2761 notification state information would become out of date and would be
2762 discarded without resending. The UA would select another appearance
2763 number and send another notification.
2765 - The notification could be accepted but an immediate NOTIFY
2766 generated by the Appearance Agent indicating that the appearance is
2767 unavailable. The UA would then select another appearance number and
2768 PUBLISH again.
2770 UAs would wait for a notification from the Appearance Agent before
2771 sending the INVITE.
2773 13.2. Comparison
2775 In comparing the URI parameter and the dialog package parameter,
2776 there are clear differences in the number of registrations and
2777 subscriptions, with the dialog package approach requiring n times
2778 fewer in both cases.
2780 The security model for the dialog package parameter approach is much
2781 cleaner, since only NOTIFY and PUBLISH requests need integrity and
2782 privacy. The security model for the URI parameter approach would
2783 likely require a B2BUA which introduces many undesirable properties.
2785 The dialog package parameter approach has better backwards
2786 compatibility than the URI parameter approach.
2788 In summary, the dialog package parameter approach better meets REQs
2789 5, 10, 11, 12, and 13 while the URI parameter approach better meets
2790 REQ-9. However, the combined dialog package parameter approach and
2791 the Alert-Info parameter approach meets REQ-9.
2793 13.2.1. Comparison of Appearance Selection Methods
2795 All three approaches meet REQ-15 and REQ-16.
2797 Previous versions of this draft proposed the publish/notify method of
2798 appearance selection. The advantage of this approach is that the
2799 appearance number is only carried in one place (dialog package XML
2800 documents) and the same protocol/mechanism is used to select and
2801 learn appearance numbers. The disadvantage of this approach is that
2802 a specialized event state compositor must be used, since it is aware
2803 of appearance numbers. Also, concerns have been raised about whether
2804 this approach defines new semantics for publish/notify beyond that in
2805 RFC 3265.
2807 The floor control approach makes good reuse of existing protocols
2808 such as Binary Floor Control Protocol (BFCP) and cleanly models the
2809 state. However, while BFCP can be used in conferencing applications,
2810 it is unlikely most UAs implementing shared appearances would utilize
2811 the protocol. Also, having appearance state in two places (dialog
2812 package XML documents and floor control messages) complicates the
2813 application. Also, BFCP only runs over TCP and requires a separate
2814 offer/answer exchange to establish the connection, making operation
2815 through NATs and firewalls more difficult. The BFCP approach is also
2816 radically different from all current implementations of this feature.
2817 As a result, standardizing this approach would likely result in an
2818 increase in feature interoperability rather than a decrease.
2820 The INVITE selection mechanism is based on overlap dialing. Overlap
2821 dialing is supported in very few SIP UAs and is regarded as a
2822 somewhat archaic leftover from the PSTN. As such, it is not regarded
2823 as a good starting point for a common feature such as shared
2824 appearances.
2826 The PUBLISH selection mechanism reuses the SIP events extensions
2827 which already must be implemented by UAs supporting this feature. In
2828 fact, it results in no additional messages or round trips. It is
2829 also very similar to many current feature implementations today.
2830 Standardizing this approach is likely to increase overall
2831 interoperability of this feature.
2833 The rest of this document will only discuss the PUBLISH appearance
2834 selection mechanism.
2836 14. Acknowledgements
2838 The following individuals were part of the shared appearance Design
2839 team and have provided input and text to the document (in
2840 alphabetical order):
2842 Martin Dolly, Andrew Hutton, Raj Jain, Fernando Lombardo, Derek
2843 MacDonald, Bill Mitchell, Michael Procter, Theo Zowzouvillys.
2845 Thanks to Chris Boulton for helping with the XML schema.
2847 Much of the material has been drawn from previous work by Mohsen
2848 Soroushnejad, Venkatesh Venkataramanan, Paul Pepper and Anil Kumar,
2849 who in turn received assistance from:
2851 Kent Fritz, John Weald, and Sunil Veluvali of Sylantro Systems, Steve
2852 Towlson, and Michael Procter of Citel Technologies, Rob Harder and
2853 Hong Chen of Polycom Inc, John Elwell, J D Smith of Siemens
2854 Communications, Dale R. Worley of Pingtel, Graeme Dollar of Yahoo
2855 Inc.
2857 Also thanks to Geoff Devine, Paul Kyzivat, Jerry Yin, John Elwell,
2858 Dan York, Spenser Dawkins, Martin Dolly, and Brett Tate for their
2859 comments.
2861 15. Security Considerations
2863 Since multiple line appearance features are implemented using
2864 semantics provided by [RFC3261], Event Package for Dialog State as
2865 define in , and Event Notification [RFC3265], [RFC3903], security
2866 considerations in these documents apply to this draft as well.
2868 Specifically, since dialog state information and the dialog
2869 identifiers are supplied by UA's in an appearance group to other
2870 members, the same is prone to "call hijacks". For example, a rogue
2871 UA could snoop for these identifiers and send an INVITE with Replaces
2872 header containing these call details to take over the call. As such
2873 INVITES with Replaces header MUST be authenticated using the standard
2874 mechanism (like Digest or S/MIME) described in [RFC3261]. before it
2875 is accepted. NOTIFY or PUBLISH message bodies that provide the
2876 dialog state information and the dialog identifiers MAY be encrypted
2877 end-to-end using the standard mechanics. All SUBSCRIBES between the
2878 UA's and the Appearance Agent MUST be authenticated.
2880 16. Informative References
2882 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2883 Requirement Levels", BCP 14, RFC 2119, March 1997.
2885 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
2886 A., Peterson, J., Sparks, R., Handley, M., and E.
2887 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
2888 June 2002.
2890 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
2891 Method", RFC 3515, April 2003.
2893 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
2894 Event Notification", RFC 3265, June 2002.
2896 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
2897 for Event State Publication", RFC 3903, October 2004.
2899 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
2900 Protocol (SIP) "Replaces" Header", RFC 3891,
2901 September 2004.
2903 [RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and
2904 K. Summers, "Session Initiation Protocol Service
2905 Examples", BCP 144, RFC 5359, October 2008.
2907 [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
2908 Initiated Dialog Event Package for the Session Initiation
2909 Protocol (SIP)", RFC 4235, November 2005.
2911 [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol
2912 (SIP) "Join" Header", RFC 3911, October 2004.
2914 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol
2915 (SIP) Call Control - Conferencing for User Agents",
2916 BCP 119, RFC 4579, August 2006.
2918 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
2919 "Indicating User Agent Capabilities in the Session
2920 Initiation Protocol (SIP)", RFC 3840, August 2004.
2922 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
2923 January 2004.
2925 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
2926 Package for Registrations", RFC 3680, March 2004.
2928 Authors' Addresses
2930 Alan Johnston (editor)
2931 Avaya
2932 St. Louis, MO 63124
2934 Email: alan@sipstation.com
2936 Mohsen Soroushnejad
2937 Sylantro Systems Corp
2939 Email: mohsen.soroush@sylantro.com
2941 Venkatesh Venkataramanan
2942 Sylantro Systems Corp
2944 Email: vvenkatar@gmail.com