idnits 2.17.1
draft-ietf-bliss-shared-appearances-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1 on line 18.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 3205.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3216.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3223.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3229.
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 :
----------------------------------------------------------------------------
** There are 5 instances of too long lines in the document, the longest one
being 7 characters in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust Copyright Line does not match the
current year
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (November 2, 2008) is 5654 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)
== Missing Reference: 'RFC3688' is mentioned on line 2635, but not defined
== Unused Reference: 'RFC3325' is defined on line 3161, but no explicit
reference was found in the text
-- Obsolete informational reference (is this intentional?): RFC 3265
(Obsoleted by RFC 6665)
Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 8 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: May 6, 2009 M. Soroushnejad
5 V. Venkataramanan
6 Sylantro Systems Corp
7 November 2, 2008
9 Shared Appearances of a Session Initiation Protocol (SIP) Address of
10 Record (AOR)
11 draft-ietf-bliss-shared-appearances-01
13 Status of this Memo
15 By submitting this Internet-Draft, each author represents that any
16 applicable patent or other IPR claims of which he or she is aware
17 have been or will be disclosed, and any of which he or she becomes
18 aware will be disclosed, in accordance with Section 6 of BCP 79.
20 Internet-Drafts are working documents of the Internet Engineering
21 Task Force (IETF), its areas, and its working groups. Note that
22 other groups may also distribute working documents as Internet-
23 Drafts.
25 Internet-Drafts are draft documents valid for a maximum of six months
26 and may be updated, replaced, or obsoleted by other documents at any
27 time. It is inappropriate to use Internet-Drafts as reference
28 material or to cite them other than as "work in progress."
30 The list of current Internet-Drafts can be accessed at
31 http://www.ietf.org/ietf/1id-abstracts.txt.
33 The list of Internet-Draft Shadow Directories can be accessed at
34 http://www.ietf.org/shadow.html.
36 This Internet-Draft will expire on May 6, 2009.
38 Abstract
40 This document describes the requirements and implementation of a
41 group telephony feature commonly known as Bridged Line Appearance
42 (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line
43 Appearance (SCA). When implemented using the Session Initiation
44 Protocol (SIP), it is referred to as Shared Appearances (SA) of an
45 Address of Record (AOR) since SIP does not have the concept of lines.
46 This feature is commonly offered in IP Centrex services and IP-PBX
47 offerings and is likely to be implemented on SIP IP telephones and
48 SIP feature servers used in a business environment. This document
49 lists requirements and compares implementation options for this
50 feature. Extensions to the SIP dialog event package are proposed.
52 Table of Contents
54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
55 2. Conventions used in this document . . . . . . . . . . . . . . 5
56 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5
57 3.1. Executive/Assistant Arrangement . . . . . . . . . . . . . 5
58 3.2. Call Group . . . . . . . . . . . . . . . . . . . . . . . 5
59 3.3. Single Line Extension . . . . . . . . . . . . . . . . . . 6
60 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
61 5. Normative Description . . . . . . . . . . . . . . . . . . . . 7
62 5.1. Implementation . . . . . . . . . . . . . . . . . . . . . 8
63 5.2. Shared Appearance Dialog Package Extensions . . . . . . . 10
64 5.2.1. The element . . . . . . . . . . . . . . . 10
65 5.2.2. The element . . . . . . . . . . . . . . . 11
66 5.2.3. The element . . . . . . . . . . . . . 11
67 5.2.4. The element . . . . . . . . . . . . 11
68 5.3. Shared Appearance User Agents . . . . . . . . . . . . . . 11
69 5.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . 14
70 6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 16
71 7. User Interface Considerations . . . . . . . . . . . . . . . . 17
72 7.1. Appearance Number Rendering . . . . . . . . . . . . . . . 18
73 7.1.1. Single Appearance UAs . . . . . . . . . . . . . . . . 18
74 7.1.2. Dual Appearance UAs . . . . . . . . . . . . . . . . . 18
75 7.1.3. Shared Appearance UAs with Fixed Appearance Number . . 18
76 7.1.4. Shared Appearance UAs with Variable Appearance
77 Number . . . . . . . . . . . . . . . . . . . . . . . . 18
78 7.2. Call State Rendering . . . . . . . . . . . . . . . . . . 19
79 8. Interop with non-Shared Appearance UAs . . . . . . . . . . . . 20
80 8.1. Appearance Assignment . . . . . . . . . . . . . . . . . . 20
81 8.2. Appearance Release . . . . . . . . . . . . . . . . . . . 20
82 8.3. UAs Supporting Dialog Events but Not Shared Appearance . 21
83 9. Provisioning Considerations . . . . . . . . . . . . . . . . . 21
84 10. Example Message Flows . . . . . . . . . . . . . . . . . . . . 21
85 10.1. Registration and Subscription . . . . . . . . . . . . . . 21
86 10.2. Appearance Selection for Incoming Call . . . . . . . . . 24
87 10.3. Outgoing Call with Without Appearance Pre-Selection . . . 28
88 10.4. Outgoing Call with Appearance Selection . . . . . . . . . 33
89 10.5. Outgoing Call without using an Appearance Number . . . . 37
90 10.6. Appearance Release . . . . . . . . . . . . . . . . . . . 39
91 10.7. Appearance Pickup . . . . . . . . . . . . . . . . . . . . 40
92 10.8. Calls between UAs within the Group . . . . . . . . . . . 44
93 10.9. Consultation Hold with Appearances . . . . . . . . . . . 47
94 10.10. Joining or Bridging an Appearance . . . . . . . . . . . . 52
95 10.11. Appearance Allocation - Loss of Appearance . . . . . . . 55
96 10.12. Appearance Selection Contention Race Condition . . . . . 56
97 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57
98 11.1. SIP Event Package Parameter: shared . . . . . . . . . . . 58
99 11.2. URN Sub-Namespace Registration: sa-dialog-info . . . . . 58
100 11.3. XML Schema Registration . . . . . . . . . . . . . . . . . 59
101 12. Appendix A - Incoming Appearance Assignment . . . . . . . . . 59
102 13. Appendix B - Implementation Options Discussion . . . . . . . . 60
103 13.1. Appearance Implementation Options . . . . . . . . . . . . 60
104 13.1.1. URI parameter Approach . . . . . . . . . . . . . . . . 60
105 13.1.2. Dialog Package Parameter . . . . . . . . . . . . . . . 61
106 13.1.3. Appearance Selections Mechanisms . . . . . . . . . . . 64
107 13.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . 67
108 13.2.1. Comparison of Appearance Selection Methods . . . . . . 67
109 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 68
110 15. Security Considerations . . . . . . . . . . . . . . . . . . . 69
111 16. Informative References . . . . . . . . . . . . . . . . . . . . 69
112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70
113 Intellectual Property and Copyright Statements . . . . . . . . . . 72
115 1. Introduction
117 The feature and functionality requirements for SIP user agents (UAs)
118 supporting business telephony applications differ greatly from basic
119 SIP user agents, both in terms of services and end user experience.
120 In addition to basic SIP support [RFC3261], many of the services in a
121 business environment require the support for SIP extensions such as
122 REFER [RFC3515], SUBSCRIBE/NOTIFY primitives [RFC3265], PUBLISH
123 [RFC3903], the SIP Replaces [RFC3891], and Join [RFC3911], header
124 fields, etc. Many of the popular business services have been
125 documented in the SIP Service Examples
126 [I-D.ietf-sipping-service-examples].
128 This specification details a method for implementing a group
129 telephony feature known in telephony as Bridged Line Appearance (BLA)
130 or Multiple Line Appearances (MLA), one of the more popular advanced
131 features expected of SIP IP telephony devices in a business
132 environment. Other names for this feature include Shared Call/Line
133 Appearance (SCA), Shared Call Status and Multiple Call Appearance
134 (MCA). A variant of this feature is known as Single Line Extension.
136 This document looks at how this feature can be implemented using
137 standard SIP [RFC3261] in conjunction with [RFC3265] and [RFC3903]
138 for exchanging status among user agents, and the SIP dialog state
139 event package [RFC4235] to exchange dialog state information to
140 achieve the same. Different approaches will be discussed including
141 the use of URI parameters, feature tags, and dialog package
142 extensions along with the strengths and weaknesses of the various
143 approaches.
145 A call flow for Single Line Extension was formerly included in the
146 SIP Service Examples [I-D.ietf-sipping-service-examples]. However,
147 the attempt to implement using standard SIP primitives ultimately
148 failed, leading to its removal from that document. This document
149 defines SIP extensions to implement this service.
151 In traditional telephony, the line is physical. A common scenario in
152 telephony is for a number of business telephones to share a single or
153 a small number of lines. The sharing or appearance of these lines
154 between a number of phones is what gives this feature its. A common
155 scenario in SIP is for a number of business telephones to share a
156 single or a small number of Address of Record (AOR) URIs. In
157 addition, an AOR can have multiple appearances on a single UA in
158 terms of the user interface. The appearance number relates to the
159 user interface for the telephone - typically each appearance or an
160 AOR has a visual display (lamp that can change color or blink) and a
161 button (used to select the appearance). The telephony concept of
162 line appearance is still relevant to SIP due to the user interface
163 considerations. It is important to keep the appearance number
164 construct because:
166 1. Human users are used to the concept and will expect it in
167 replacement systems (e.g. an overhead page announcement says "Joe
168 pickup line 3").
169 2. It is a useful structure for user interface representation.
171 In this document, we will use the term "appearance" rather than "line
172 appearance" since SIP does not have the concept of lines. Note that
173 this does not mean that a conventional telephony user interface
174 (lamps and buttons) must be used - implementations may use another
175 metaphor as long as the appearance number is readily apparent to the
176 user. Each AOR has a separate appearance numbering space. As a
177 result, a given UA user interface may have multiple occurrences of
178 the same appearance number, but they will be for different AORs.
180 2. Conventions used in this document
182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
184 document are to be interpreted as described in RFC-2119 [RFC2119] and
185 indicate requirement levels for compliant mechanisms.
187 3. Usage Scenarios
189 The following examples are common applications of the Shared
190 Appearances feature and are mentioned here as informative use cases.
191 All these example usages can be supported by the Shared Appearances
192 feature described in this document. The differences relate to the
193 user interface considerations of the device.
195 3.1. Executive/Assistant Arrangement
197 The appearances on the executive's UA also appear on the assistant's
198 UA. The assistant may answer incoming calls to the executive and
199 then place the call on hold for the executive to pick up. The
200 assistant can always see the state of all calls on the executive's
201 UA. An assistant can make outgoing calls using the identity of
202 either the executive or their own.
204 3.2. Call Group
206 Users with similar business needs or tasks can be assigned to
207 specific groups and share the line appearances of each other on each
208 others SIP telephony devices. For example, an IT department staff of
209 five might answer a help line which has three appearances on each
210 phone in the IT work area. A call answered on one phone can be put
211 on hold and picked up on another phone. A shout or an IM to another
212 staff member can result in them taking over a call on a particular
213 appearance. Another phone can request to be added to an appearance
214 resulting in a conference call.
216 3.3. Single Line Extension
218 In this scenario, incoming calls are offered to a group of UAs. When
219 one answers, the other UAs are informed. If another UA in the group
220 selects the line (i.e. goes off hook), it is immediately bridged or
221 joined in with the call. This mimics the way residential telephone
222 extensions usually operate.
224 4. Requirements
226 The basic requirements of the shared appearance feature can be
227 summarized as follows:
229 REQ-1 Incoming calls to the AOR must be offered to a group of UAs and
230 can be answered by any of them.
232 REQ-2 Each UA in the group must be able to learn the call status of
233 the others in the group for the purpose of rendering this information
234 to the user.
236 REQ-3 Calls can be joined (also called bridged or conferenced
237 together) or can be picked up (taken) by another UA in the group in a
238 secure way.
240 REQ-4 The mechanism should require the minimal amount of
241 configuration. UAs registering against the group AOR should be able
242 to learn about each other and join the appearance group.
244 REQ-5 The mechanism must scale for large numbers of appearances, n,
245 and large numbers of UAs, N, without introducing excessive messaging
246 traffic.
248 REQ-6 Each call or session (incoming or outgoing) must be assigned a
249 common "appearance" number from a managed pool administered for the
250 AOR group. Once the session has terminated, the appearance number is
251 released back into the pool and can be reused by another incoming or
252 outgoing session.
254 REQ-7 Each UA in the group must be able to learn the appearance
255 status of the the group.
257 REQ-8 There must be mechanisms to resolve appearance contention among
258 the UAs in the group.
260 REQ-9 The mechanism must allow all UAs receiving an incoming session
261 request to select the same appearance number at the time of alerting.
263 REQ-10 The mechanism must have a way of reconstructing appearance
264 state after an outage that does not result in excessive traffic and
265 processing.
267 REQ-11 The mechanism must have backwards compatibility such that a UA
268 which is unaware of the feature can still register against the group
269 AOR and make and receive calls.
271 REQ-12 The mechanism must not allow UAs outside the group to select
272 or manipulate appearance numbers.
274 REQ-13 For privacy reasons, there must be a mechanism so that
275 appearance information is not leaked outside the group of UAs. (e.g.
276 "So who do you have on line 1?")
278 REQ-14 The mechanism must support a way for UAs to request
279 exclusivity on a line appearance. Exclusivity means that the UA
280 requesting it desires to have a private conversation with the
281 external party and other UAs must not be allowed to be joined or
282 taken. Exclusivity may be requested at the start of an incoming or
283 outgoing session or during the session. An exclusivity request may
284 be accepted or rejected by the entity providing the shared appearance
285 service. Therefore, the mechanism must provide a way of
286 communicating the result back to the requester UA.
288 REQ-15 The mechanism should support a way for a UA to select a
289 particular appearance number for outgoing requests prior to sending
290 the actual request. This is often called seizure.
292 REQ-16 The mechanism should support a way for a UA to select a
293 particular appearance number and also send the request at the same
294 time. This is needed when a ringdown feature is combined with shared
295 appearances - in this case, seizing the line is the same thing as
296 dialing.
298 OPEN ISSUE: This requirement is no longer supported by the proposed
299 solution. Is this OK?
301 5. Normative Description
303 This section normatively describes the shared appearance feature
304 extensions. For a discussion of various approaches to implement this
305 feature, see Appendix B.
307 5.1. Implementation
309 Many of the requirements for this service can be met using standard
310 SIP mechanisms such as:
312 - A SIP Forking Proxy and Registrar/Location Service meets REQ-1.
314 - The SIP Dialog Package meets REQ-2.
316 - The SIP Replaces and Join header fields meets REQ-3.
318 - The SIP Registration Package meets REQ-4.
320 - The use of a State Agent for the Dialog Package meets REQ-5.
322 REQ-6 suggests the need for an entity which manages the appearance
323 resource. Just as conferencing systems commonly have a single point
324 of control, known as a focus, a Shared Appearance group has a single
325 point of control of the appearance shared resource. This is defined
326 as an Appearance Agent for a group. While an Appearance Agent can be
327 part of a centralized server, it could also be co-resident in a
328 member User Agent who has taken on this functionality for a group.
329 The Appearance Agent learns the group state either dialog state
330 publications from members.
332 While the appearance resource could be managed co-operatively by a
333 group of UAs without any central control, this is not discussed in
334 this draft, but instead is left as a research project for future
335 standardization. It is also possible that the Appearance Agent logic
336 could be distributed in all UAs in the group. For example, rules
337 that govern assigning appearance numbers for incoming requests (e.g.
338 lowest available appearance number) and rules for contention handling
339 (e.g. when two UAs request the use of the same appearance number,
340 hash dialog identifiers and compare with the lowest hash winning)
341 would need to be defined and implemented.
343 Figure 1 illustrates the SIP components involved in supporting these
344 common requirements of the Shared Appearance using standard SIP
345 messages including REGISTER, INVITE, SUBSCRIBE, NOTIFY, and PUBLISH.
347 +----------------------------+ +----+
348 | | | |
349 | Appearance Agent | | UA |
350 | | | |
351 +----------------------------+ +----+
352 ^ ^ |1)SUBSCRIBE ^ ^ 4)NOTIFY INVITE |
353 | | |(Event:reg) | | registration sip:alice@example.com|
354 | | V | | events V
355 | | +--------------------+ +----------+7)Query+--------+
356 | | | (example.com) | | |<===== | |
357 | | | |3) Store| Location | | Proxy |
358 | | | Registrar |=======>| Service | | |
359 | | | | | |=====> | |
360 | | +--------------------+ +----------+8)Resp +--------+
361 | | ^ ^ | |
362 | | | | 2) REGISTER (alice) | |
363 | | | | | |
364 | | +----+ +----+ | |
365 | | | | | | | |
366 | | |UA1 | |UA2 | | |
367 | | | | | | | |
368 | | +----+ +----+ | |
369 | | ^ ^ ^ ^ | |
370 | | | | | | | |
371 | +----+ | | | | |
372 | | | +--------------------------------------+ |
373 | +----+-------------------------------------------+
374 | | 8) INVITE
375 +--------------+ sip:alice@example.com
376 5-7) SUBSCRIBE and/or PUBLISH
377 (Event:dialog)
379 OPEN ISSUE: This figure still shows the use of the registration event
380 package by the Appearance Agent - do we still need this?
382 Figure 1.
384 The next section discusses normal SIP operations used to implement
385 parts of the shared appearance feature.
387 1. The Appearance Agent SUBSCRIBEs to the registration event package
388 as outlined in [RFC3680] for contacts registered to the group
389 AOR. Thus, it has knowledge of all User Agents registered
390 against the AOR at any point of time.
391 2. UAs (UA1 and UA2 in Figure 1) belong to the appearance group and,
392 after authentication, register against the same AOR (e.g.,
393 sip:alice@example.com).
395 3. Each registration is stored in the Location Service.
396 4. The registrar notifies the Appearance Agent of successful
397 registration at each UA.
398 5. UAs PUBLISH their dialog state to the State Agent in the
399 Appearance Agent.
400 6. The UAs SUBSCRIBE to the Appearance Agent for the state of all
401 dialogs as defined in [RFC3265]. The Request-URI of the
402 SUBSCRIBE could be either the AOR of the group or a provisioned
403 URI.
404 7. The UAs PUBLISH their dialog information to the Appearance Agent
405 every time their dialog state changes (i.e. send an INVITE, enter
406 alerting state, answer a call, terminate a call, etc.), pickups
407 or joins a call, or seizes/selects an appearance.
408 8. The Forking Proxy forks an incoming INVITE for the AOR address to
409 the registered user agents.
411 The Appearance Agent can select the appearance number for an incoming
412 call
414 OPEN ISSUE: Do we want to define another mode of operation in
415 which UAs only PUBLISH to seize an appearance? This assumes the
416 Appearance Agent already knows about all dialogs related to the
417 AOR and could publish that information to the UAs in the shared
418 appearance group. This approach would simply UA operation and
419 reduce the number of SIP messages sent and received. If a
420 different SIP option tag was defined for this server mode, an
421 Appearance Agent could indicate support for this feature by
422 including it in a Supported in NOTIFYs. The UA could also include
423 the option tag in a Require header field in the initial PUBLISH.
424 A 200 OK response to the PUBLISH would confirm that the UA does
425 not need to PUBLISH any more state for the dialog.
427 5.2. Shared Appearance Dialog Package Extensions
429 This specification defines four new elements as extensions to the SIP
430 Dialog Event package [RFC3265]. The schema is defined in Section 6.
431 The elements are , , , and
432 which are sub-elements of the
1159
1161 F7 Proxy ----> Bob
1163 INVITE sip:alice@ua3.example.com SIP/2.0
1164 Via: SIP/2.0/UDP ua3.example.com;branch=z9hG4bK4324ea695b5B376A
1165 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK38432ji
1166 From: ;tag=44BAD75D-E3128D42
1167 To:
1168 CSeq: 106 INVITE
1169 Call-ID: 14-1541707345@example.com
1170 Contact:
1171 Max-Forwards: 69
1172 Alert-Info: ;alert=normal;appearance=1
1173 Content-Type: application/sdp
1174 Content-Length: 223
1176 v=0
1177 o=- 1102980499 1102980499 IN IP4 ua3.example.com
1178 s=
1179 c=IN IP4 ua3.example.com
1180 t=0 0
1181 a=sendrecv
1182 m=audio 2238 RTP/AVP 0 8 101
1183 a=rtpmap:0 PCMU/8000
1184 a=rtpmap:8 PCMA/8000
1185 a=rtpmap:101 telephone-event/8000
1187 F8 Proxy ----> Alice
1189 INVITE sip:alice@ua1.example.com SIP/2.0
1190 Via: SIP/2.0/UDP ua3.example.com;branch=z9hG4bK4324ea695b5B376A
1191 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK348281
1192 From: ;tag=44BAD75D-E3128D42
1193 To:
1194 CSeq: 106 INVITE
1195 Call-ID: 14-1541707345@example.com
1196 Contact:
1197 Max-Forwards: 69
1198 Alert-Info: ;alert=normal;appearance=1
1199 Content-Type: application/sdp
1200 Content-Length: 223
1202 v=0
1203 o=- 1102980499 1102980499 IN IP4 ua3.example.com
1204 s=
1205 c=IN IP4 ua3.example.com
1206 t=0 0
1207 a=sendrecv
1208 m=audio 2238 RTP/AVP 0 8 101
1209 a=rtpmap:0 PCMU/8000
1210 a=rtpmap:8 PCMA/8000
1211 a=rtpmap:101 telephone-event/8000
1212 F15: Bob notifies the Appearance Agent with dialog state
1213 payload indicating the dialog in confirmed state. Appearance
1214 Agent notifies Alice of the status of the dialog at Bob.
1216 F15 Bob ----> Appearance Agent
1218 PUBLILSH sip:appearance-agent@example.com SIP/2.0
1219 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK58a0dd68C2D63263
1220 From: ;tag=558C18F7-DB9DF7BC
1221 To: ;tag=1894685100249086
1222 CSeq: 14 PUBLISH
1223 Call-ID: 77-505889516@example.com
1224 Contact:
1225 Event: dialog;shared
1226 Max-Forwards: 70
1227 Content-Type: application/dialog-info+xml
1228 Content-Length: ...
1230
1231
1236
1241 1
1242 false
1243 confirmed
1244
1245
1246
1247
1248
1249
1250 sip:carol@ua.example.com
1251
1252
1253
1255 10.3. Outgoing Call with Without Appearance Pre-Selection
1257 In this scenario, Bob's UA places a call without first selecting an
1258 appearance number. After sending the INVITE, Bob sends out a dialog
1259 event PUBLISH with state (trying) but does not include an appearance
1260 number or the 'shared' dialog event parameter. As a result, the
1261 Appearance agent treats the publish as if it were sent by an shared
1262 appearance-unaware UA and assigns an appearance number for it. The
1263 NOTIFY from the appearance agent tells Bob what appearance number to
1264 use. Bob also publishes on receipt of the 180 Ringing and 200 OK
1265 responses. Note that NOTIFYs F16 and F25 do not tell Bob any new
1266 information and could be suppressed by the Appearance Agent.
1268 Carol Proxy Alice Appearance Agent Bob
1269 | | | | |
1270 | | | | |
1271 | |<------------------------------------- INVITE F1<|
1272 | | | | |
1273 | |>F2 100 Trying --------------------------------->|
1274 |<-- INVITE F3<| | | |
1275 | | | |<----- PUBLISH F4<|
1276 | | | | |
1277 | | | |>F5 200 OK ------>|
1278 | | |<-- NOTIFY F6<| |
1279 | | | | |
1280 | | |>F7 200 OK -->| |
1281 | | | |------- NOTIFY F8>|
1282 | | | | |
1283 | | | |F10 180 --->| | | |
1285 | |>F11 180 Ringing ------------------------------->|
1286 | | | | |
1287 | | | |<---- PUBLISH F12<|
1288 | | | | |
1289 | | | |>F13 200 OK ----->|
1290 | | |<- NOTIFY F14<| |
1291 | | | | |
1292 | | |>F15 200 OK ->| |
1293 | | | |------ NOTIFY F16>|
1294 | | | | |
1295 | | | |F18 200 OK ->| | | |
1297 | |>F19 200 OK ------------------------------------>|
1298 | | | | |
1299 | | | |<---- PUBLISH F20<|
1300 | | | | |
1301 | | | |>F21 200 OK ----->|
1302 | | | | |
1303 | |<--------------------------------------- ACK F22<|
1304 |<---- ACK F23<| | | |
1305 | | | | |
1306 |<================= Both way RTP established ===================>|
1307 | | | | |
1308 | | |<- NOTIFY F24<| |
1309 | | | | |
1310 | | |>F25 200 OK ->| |
1311 | | | |------ NOTIFY F26>|
1312 | | | | |
1313 | | | | Proxy
1320 INVITE sip:carol@example.com SIP/2.0
1321 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK98c87c52123A08BF
1322 From: ;tag=15A3DE7C-9283203B
1323 To:
1324 CSeq: 1 INVITE
1325 Call-ID: f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com
1326 Contact:
1327 Max-Forwards: 70
1328 Content-Type: application/sdp
1329 Content-Length: 223
1331 v=0
1332 o=- 1102980499 1102980499 IN IP4 ua2.example.com
1333 s=IP SIP UA
1334 c=IN IP4 ua2.example.com
1335 t=0 0
1336 a=sendrecv
1337 m=audio 2236 RTP/AVP 0 8 101
1338 a=rtpmap:0 PCMU/8000
1339 a=rtpmap:8 PCMA/8000
1340 a=rtpmap:101 telephone-event/8000
1342 F4 Bob ----> Appearance Agent
1344 PUBLISH sip:appearance-agent@example.com SIP/2.0
1345 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
1346 From: ;tag=44150CC6-A7B7919D
1347 To: ;tag=428765950880801
1348 CSeq: 7 PUBLISH
1349 Call-ID: 144-1289338424@example.com
1350 Contact:
1351 Event: dialog
1352 Max-Forwards: 70
1353 Content-Type: application/dialog-info+xml
1354 Content-Length: ...
1356
1357
1362
1363 false
1364 trying
1365
1366
1367
1368
1369
1370
1372 F5 Appearance Agent ----> Bob
1374 SIP/2.0 200 OK
1375 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
1376 CSeq: 7 PUBLISH
1377 Call-ID: 144-1289338424@example.com
1378 From: ;tag=44150CC6-A7B7919D
1379 To: ;tag=428765950880801
1380 Allow-Events: dialog
1381 Contact:
1382 Expires: 60
1383 Content-Length: 0
1385 F8 Appearance Agent ----> Bob
1387 NOTIFY sip:bob@ua1.example.com SIP/2.0
1388 From: ;tag=497585728578386
1389 To: ;tag=633618CF-B9C2EDA4
1390 Call-ID: a7d559db-d6d7dcad-311c9e3a@ua1.example.com
1391 CSeq: 7 NOTIFY
1392 Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1711759878512309
1393 Max-Forwards: 70
1394 Content-Type: application/dialog-info+xml
1395 Event: dialog;shared
1396 Subscription-State: active
1397 Contact:
1398 Content-Length: ...
1400
1401
1406
1407 0
1408 false
1409 trying
1410
1411
1412
1413
1414
1415
1417 F9 Bob ----> Appearance Agent
1419 SIP/2.0 200 OK
1420 Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1711759878512309
1421 From: ;tag=497585728578386
1422 To: ;tag=633618CF-B9C2EDA4
1423 CSeq: 7 NOTIFY
1424 Call-ID: a7d559db-d6d7dcad-311c9e3a@ua1.example.com
1425 Contact:
1426 Event: dialog;shared
1427 Content-Length: 0
1429 F20 Bob ----> Appearance Agent
1431 PUBLISH sip:appearance-agent@example.com SIP/2.0
1432 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa39d3f69D4E20602
1433 From: ;tag=44150CC6-A7B7919D
1434 To: ;tag=428765950880801
1435 CSeq: 9 PUBLISH
1436 Call-ID: 144-1289338424@example.com
1437 Contact:
1438 Event: dialog;shared
1439 Max-Forwards: 70
1440 Content-Type: application/dialog-info+xml
1441 Content-Length: ...
1443
1444
1449
1454 confirmed
1455 0
1456 false
1457
1458
1459
1460
1461
1462
1463 sip:carol@example.com
1464
1465
1466
1467
1469 10.4. Outgoing Call with Appearance Selection
1471 In this scenario, Bob's UA sends out a dialog event PUBLISH with
1472 state (trying) selecting an appearance number before sending the
1473 INVITE. After receiving the 200 OK from the Appearance Agent
1474 confirming the appearance number, Bob's UA sends the INVITE to Carol
1475 and establishes a session. For brevity, details of some of the
1476 messages are not included in the message flows.
1478 Carol Proxy Alice Appearance Agent Bob
1479 | | | | |
1480 | | | |<----- PUBLISH F1<|
1481 | | | | |
1482 | | | |>F2 200 OK ------>|
1483 | | | | |
1484 | |<------------------------------------- INVITE F3<|
1485 | | | | |
1486 | |>F4 100 Trying --------------------------------->|
1487 |<-- INVITE F5<| | | |
1488 | | |<-- NOTIFY F6<| |
1489 | | | | |
1490 | | |>F7 200 OK -->| |
1491 | | | |------- NOTIFY F8>|
1492 | | | | |
1493 | | | |F10 180 --->| | | |
1495 | |>F11 180 Ringing ------------------------------->|
1496 | | | | |
1497 | | | |<---- PUBLISH F12<|
1498 | | | | |
1499 | | | |>F13 200 OK ----->|
1500 | | |<- NOTIFY F14<| |
1501 | | | | |
1502 | | |>F15 200 OK ->| |
1503 | | | |------ NOTIFY F16>|
1504 | | | | |
1505 | | | |F18 200 OK ->| | | |
1507 | |>F19 200 OK ------------------------------------>|
1508 | | | | |
1509 | | | |<---- PUBLISH F20<|
1510 | | | | |
1511 | | | |>F21 200 OK ----->|
1512 | | | | |
1513 | |<--------------------------------------- ACK F22<|
1514 |<---- ACK F23<| | | |
1515 | | | | |
1516 |<================= Both way RTP established ===================>|
1517 | | | | |
1518 | | |<- NOTIFY F24<| |
1519 | | | | |
1520 | | |>F25 200 OK ->| |
1521 | | | |------ NOTIFY F26>|
1522 | | | | |
1523 | | | | Appearance Agent
1542 PUBLISH sip:appearance-agent@example.com SIP/2.0
1543 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
1544 From: ;tag=44150CC6-A7B7919D
1545 To: ;tag=428765950880801
1546 CSeq: 7 PUBLISH
1547 Call-ID: 144-1289338424@example.com
1548 Contact:
1549 Event: dialog;shared
1550 Max-Forwards: 70
1551 Content-Type: application/dialog-info+xml
1552 Content-Length: ...
1554
1555
1560
1561 0
1562 false
1563 trying
1564
1565
1566
1567
1568
1569
1571 F2 Appearance Agent ----> Bob
1573 SIP/2.0 200 OK
1574 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
1575 CSeq: 7 PUBLISH
1576 Call-ID: 144-1289338424@example.com
1577 From: ;tag=44150CC6-A7B7919D
1578 To: ;tag=428765950880801
1579 Allow-Events: dialog
1580 Contact:
1581 Expires: 60
1582 Content-Length: 0
1584 F8 Appearance Agent ----> Bob
1585 NOTIFY sip:bob@ua1.example.com SIP/2.0
1586 From: ;tag=497585728578386
1587 To: ;tag=633618CF-B9C2EDA4
1588 Call-ID: a7d559db-d6d7dcad-311c9e3a@ua1.example.com
1589 CSeq: 7 NOTIFY
1590 Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1711759878512309
1591 Max-Forwards: 70
1592 Content-Type: application/dialog-info+xml
1593 Event: dialog;shared
1594 Subscription-State: active
1595 Contact:
1596 Content-Length: ...
1598
1599
1604
1605 0
1606 false
1607 trying
1608
1609
1610
1611
1612
1613
1615 F9 Bob ----> Appearance Agent
1617 SIP/2.0 200 OK
1618 Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1711759878512309
1619 From: ;tag=497585728578386
1620 To: ;tag=633618CF-B9C2EDA4
1621 CSeq: 7 NOTIFY
1622 Call-ID: a7d559db-d6d7dcad-311c9e3a@ua1.example.com
1623 Contact:
1624 Event: dialog;shared
1625 Content-Length: 0
1626 10.5. Outgoing Call without using an Appearance Number
1628 In this scenario, Bob's UA sends out a dialog event PUBLISH with
1629 state (trying) indicating that he does not want to utilize an
1630 appearance number for this dialog. The PUBLISH does not have an
1631 appearance element but does have the 'shared' dialog event parameter.
1632 As a result, the Appearance Agent knows the UA does not wish to use
1633 an appearance number for this call. If the Appearance Agent does not
1634 wish to allow this, it would reject the PUBLISH with a 409 Conflict
1635 response and the UA would know to re-PUBLISH selecting an appearance
1636 number.
1638 Carol Proxy Alice Appearance Agent Bob
1639 | | | | |
1640 | | | |<----- PUBLISH F1<|
1641 | | | | |
1642 | | | |>F2 200 OK ------>|
1643 | | | | |
1644 | |<------------------------------------- INVITE F3<|
1645 | | | | |
1646 | |>F4 100 Trying --------------------------------->|
1647 |<-- INVITE F5<| | | |
1648 | | |<-- NOTIFY F6<| |
1649 | | | | |
1650 | | |>F7 200 OK -->| |
1651 | | | |------- NOTIFY F8>|
1652 | | | | |
1653 | | | |F10 180 --->| | | |
1655 | |>F11 180 Ringing ------------------------------->|
1656 | | | | |
1657 | | | |<---- PUBLISH F12<|
1658 | | | | |
1659 | | | |>F13 200 OK ----->|
1660 | | |<- NOTIFY F14<| |
1661 | | | | |
1662 | | |>F15 200 OK ->| |
1663 | | | |------ NOTIFY F16>|
1664 | | | | |
1665 | | | |F18 200 OK ->| | | |
1667 | |>F19 200 OK ------------------------------------>|
1668 | | | | |
1669 | | | |<---- PUBLISH F20<|
1670 | | | | |
1671 | | | |>F21 200 OK ----->|
1672 | | | | |
1673 | |<--------------------------------------- ACK F22<|
1674 |<---- ACK F23<| | | |
1675 | | | | |
1676 |<================= Both way RTP established ===================>|
1677 | | | | |
1678 | | |<- NOTIFY F24<| |
1679 | | | | |
1680 | | |>F25 200 OK ->| |
1681 | | | |------ NOTIFY F26>|
1682 | | | | |
1683 | | | | Appearance Agent
1690 PUBLISH sip:appearance-agent@example.com SIP/2.0
1691 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
1692 From: ;tag=44150CC6-A7B7919D
1693 To: ;tag=428765950880801
1694 CSeq: 7 PUBLISH
1695 Call-ID: 144-1289338424@example.com
1696 Contact:
1697 Event: dialog;shared
1698 Max-Forwards: 70
1699 Content-Type: application/dialog-info+xml
1700 Content-Length: ...
1702
1703
1708
1709 false
1710 trying
1711
1712
1713
1714
1715
1716
1718 10.6. Appearance Release
1720 Bob and Carol are in a dialog, created in one of the previous two
1721 call flows. Carol sends a BYE to Bob to terminate the dialog. Bob
1722 publishes the termination of the dialog and the Appearance Agent de-
1723 allocates the appearance number used.
1725 Carol Proxy Alice Appearance Agent Bob
1726 | | | | |
1727 | | | | |
1728 |<================= Both way RTP established ===================>|
1729 | | | | |
1730 |>F28 BYE ---->| | | |
1731 | |>F29 BYE --------------------------------------->|
1732 | | | | |
1733 | |<------------------------------------ 200 OK F30<|
1734 |<--200 OK F31<| | | |
1735 | | | |<---- PUBLISH F32<|
1736 | | | | |
1737 | | | |>F33 200 OK ----->|
1738 | | |<- NOTIFY F34<| |
1739 | | | | |
1740 | | |>F35 200 OK ->| |
1741 | | | |------ NOTIFY F36>|
1742 | | | | |
1743 | | | | Appearance Agent
1749 PUBLISH sip:appearance-agent@example.com SIP/2.0
1750 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
1751 From: ;tag=44150CC6-A7B7919D
1752 To: ;tag=428765950880801
1753 CSeq: 37 PUBLISH
1754 Call-ID: 65144-1289338424@example.com
1755 Contact:
1756 Event: dialog;shared
1757 Max-Forwards: 70
1758 Content-Type: application/dialog-info+xml
1759 Content-Length: ...
1761
1762
1767
1768 0
1769 terminated
1770
1771
1772
1773
1774
1775
1777 10.7. Appearance Pickup
1779 In this scenario, Bob has an established dialog with Carol created
1780 using the call flows of Figure 2 or Figure 3. Bob then places Carol
1781 on hold. Alice receives a notification of this and renders this on
1782 Alice's UI. Alice subsequently picks up the held call and has a
1783 established session with Carol. Finally, Carol hangs up.
1785 Carol Proxy Alice Appearance Agent Bob
1786 | | | | |
1787 |<================= Both way RTP established ===================>|
1788 | | | | |
1789 | |<------------------------------(hold) INVITE F28<|
1790 |<- INVITE F29<| | | |
1791 | | | | |
1792 |>F30 200 OK ->| | | |
1793 | |>F31 200 OK ------------------------------------>|
1794 | | | | |
1795 | |<--------------------------------------- ACK F32<|
1796 |<---- ACK F33<| | | |
1797 | | | |<---- PUBLISH F34<|
1798 | | | | |
1799 | | | |>F35 200 OK ----->|
1800 | | |<- NOTIFY F36<| |
1801 | | | | |
1802 | | |>F37 200 OK ->| |
1803 | | | |>F38 NOTIFY ----->|
1804 | | | | |
1805 | | | |<----- 200 OK F39<|
1806 | | | | |
1807 | | Alice decides to pick up the call |
1808 | | | | |
1809 | | |>F40 PUBLISH->| |
1810 | | | | |
1811 | | |<- 200 OK F41<| |
1812 | | | | |
1813 | | |<- NOTIFY F42<| |
1814 | | | | |
1815 | | |>F43 200 OK ->| |
1816 | | | |>F44 NOTIFY ----->|
1817 | | | | |
1818 | | | |<----- 200 OK F45<|
1819 | |<-- INVITE F46<| | |
1820 |<- INVITE F47<|(w/ Replaces) | | |
1821 |( w/ Replaces)| | | |
1822 |>F48 200 OK ->| | | |
1823 | |>F49 200 OK -->| | |
1824 | | |>F50 PUBLISH->| |
1825 | | | | |
1826 | | |<- 200 OK F51<| |
1827 | | | |>F52 NOTIFY ----->|
1828 | | | | |
1829 | | | |<----- 200 OK F53<|
1830 | | |<- NOTIFY F54<| |
1831 | | | | |
1832 | | |>F55 200 OK ->| |
1833 | | | | |
1834 | |<----- ACK F56<| | |
1835 |<---- ACK F57<| | | |
1836 | | | | |
1837 |<= Both way RTP established =>| | |
1838 | | | | |
1839 |>F58 BYE ---->| | | |
1840 | |>F59 BYE --------------------------------------->|
1841 | | | | |
1842 | |<------------------------------------ OK 200 F60<|
1843 |<- 200 OK F61<| | | |
1844 | | | | |
1845 | | | |<---- PUBLISH F62<|
1846 | | | | |
1847 | | | |>F63 200 OK ----->|
1848 | | |<- NOTIFY F64<| |
1849 | | | | |
1850 | | |>F65 200 OK ->| |
1851 | | | | |
1852 | | | |>F66 NOTIFY ----->|
1853 | | | | |
1854 | | | |<----- 200 OK F67<|
1856 Figure 8.
1858 F28 to F33: Bob places Carol on hold.
1860 F34 to F39: Bob notifies Appearance Agent of the status of the dialog to
1861 indicate the held state. It indicates this by setting the sip.rendering
1862 parameter in the NOTIFY payload to (no). Appearance Agent notifies
1863 Alice of the same.
1865 F34 Bob ----> Appearance Agent
1867 PUBLISH sip:appearance-agent@example.com SIP/2.0
1868 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A
1869 From: ;tag=44150CC6-A7B7919D
1870 To: ;tag=428765950880801
1871 CSeq: 11 PUBLISH
1872 Call-ID: 144-1289338424@example.com
1873 Contact:
1874 Event: dialog;shared
1875 Max-Forwards: 70
1876 Content-Type: application/dialog-info+xml
1877 Content-Length: ...
1879
1880
1885
1890 0
1891 false
1892 active
1893
1894
1895
1896
1897
1898
1899 sip:carol@example.com
1900
1901
1902
1903
1905 F40 Alice ----> Appearance Agent
1907 PUBLISH sip:appearance-agent@example.com SIP/2.0
1908 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A
1909 From: ;tag=44150CC6-A7B7919D
1910 To: ;tag=428765950880801
1911 CSeq: 11 PUBLISH
1912 Call-ID: 1289338424@example.com
1913 Contact:
1914 Event: dialog;shared
1915 Max-Forwards: 70
1916 Content-Type: application/dialog-info+xml
1917 Content-Length: ...
1919
1920
1925
1926 0
1927 false
1928
1932 trying
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1944 F46: Alice picks up the held call by sending an INVITE with
1945 Replaces: header . Session is established between Alice and
1946 Carol. The dialog between Carol and Bob is terminated.
1948 F46 Bob ----> Proxy
1950 INVITE sip:carol@example.com SIP/2.0
1951 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK4ea695b5B376A60C
1952 From: ;tag=8C4183CB-BCEAB710
1953 To:
1954 CSeq: 1 INVITE
1955 Call-ID: 3d57cd17-47deb849-dca8b6c6@ua1.example.com
1956 Contact:
1957
1958 Replaces: f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com;to-tag=65a98f7c
1959 -1dd2-11b2-88c6-b03162323164+65a98f7c;from-tag=15A3DE7C-9283203B
1960
1961 Max-Forwards: 70
1962 Content-Type: application/sdp
1963 Content-Length: 223
1965 v=0
1966 o=- 1102980497 1102980497 IN IP4 ua1.example.com
1967 s=IP SIP UA
1968 c=IN IP4 ua1.example.com
1969 t=0 0
1970 a=sendrecv
1971 m=audio 2238 RTP/AVP 0 8 101
1972 a=rtpmap:0 PCMU/8000
1973 a=rtpmap:8 PCMA/8000
1974 a=rtpmap:101 telephone-event/8000
1976 10.8. Calls between UAs within the Group
1978 In this scenario, Bob calls Alice who is also in the Appearance
1979 group. He chooses to allocate an appearance.
1981 Carol Proxy Alice Appearance Agent Bob
1982 | | | | |
1983 | |<-------------------- INVITE (to Alice's UA) F1<|
1984 | | | | |
1985 | | | |<----- PUBLISH F2<|
1986 | | | | |
1987 | | | |>F3 200 OK ------>|
1988 | | | | |
1989 | | |<-- NOTIFY F4<| |
1990 | | | | |
1991 | | |>F5 200 OK -->| |
1992 | | | |>F6 NOTIFY ------>|
1993 | | | | |
1994 | | | |<------ 200 OK F7<|
1995 | |>F8 INVITE --->| | |
1996 | | (appearance=1)| | |
1997 | | | | |
1998 | |<------ 180 F9<| | |
1999 | | | | |
2000 | |>F10 180 -------------------------------------->|
2001 | | | | |
2002 | | | |<---- PUBLISH F11<|
2003 | | | | |
2004 | | | |>F12 200 OK ----->|
2005 | | |<- NOTIFY F13<| |
2006 | | | | |
2007 | | |>F14 200 OK ->| |
2008 | | | |>F15 NOTIFY ----->|
2009 | | | | |
2010 | | | |<----- 200 OK F16<|
2011 | | | | |
2012 | | | | |
2013 | |<-- 200 OK F17<| | |
2014 | | |>F18 PUBLISH->| |
2015 | | | | |
2016 | | |<- 200 OK F19<| |
2017 | | | | |
2018 | | |<- NOTIFY F20<| |
2019 | | | | |
2020 | | |>F21 200 OK ->| |
2021 | | | |>F22 NOTIFY ----->|
2022 | | | | |
2023 | | | |<----- 200 OK F23<|
2024 | | | | |
2025 | |>F24 200 OK ------------------------------------>|
2026 | | | | |
2027 | |<--------------------------------------- ACK F25<|
2028 | | | | |
2029 | |>F26 ACK ----->| | |
2030 | | | | |
2031 | | |<======= RTP established =======>|
2032 | | | | |
2033 | | | |<---- PUBLISH F27<|
2034 | | | | |
2035 | | | |>F28 200 OK ----->|
2036 | | |<- NOTIFY F29<| |
2037 | | | | |
2038 | | |>F30 200 OK ->| |
2039 | | | |>F31 NOTIFY ----->|
2040 | | | | |
2041 | | | |<----- 200 OK F32<|
2042 | | | | |
2044 Figure 9.
2046 F2 Bob ----> Appearance Agent
2048 PUBLISH sip:appearance-agent@example.com SIP/2.0
2049 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A
2050 From: ;tag=44150CC6-A7B7919D
2051 To: ;tag=428765950880801
2052 CSeq: 11 PUBLISH
2053 Call-ID: 144-1289338424@example.com
2054 Contact:
2055 Event: dialog
2056 Max-Forwards: 70
2057 Content-Type: application/dialog-info+xml
2058 Content-Length: ...
2060
2061
2066
2070 true
2071 trying
2072
2073
2074
2075
2076
2077 sip:alice@example.com
2078
2079
2080
2081
2083 F6 Appearance Agent ----> Bob
2085 NOTIFY sip:bob@ua1.example.com SIP/2.0
2086 From: ;tag=497585728578386
2087 To: ;tag=633618CF-B9C2EDA4
2088 Call-ID: a7d559db-d6d7dcad-311c9e3a@ua1.example.com
2089 CSeq: 7 NOTIFY
2090 Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1711759878512309
2091 Max-Forwards: 70
2092 Content-Type: application/dialog-info+xml
2093 Event: dialog;shared
2094 Subscription-State: active
2095 Contact:
2096 Content-Length: ...
2098
2099
2104
2108 true
2109 1
2110 trying
2111
2112
2113
2114
2115
2116 sip:alice@example.com
2117
2118
2119
2120
2122 10.9. Consultation Hold with Appearances
2124 In this scenario, Bob has a call with Carol. Bob makes a
2125 consultation call to Alice by putting Carol on hold and calling
2126 Alice. Bob chooses not to have an appearance number for the call to
2127 Alice since he is treating it as part of the call to Carol. He
2128 indicates this in his PUBLISH F34 which is sent before the INVITE to
2129 Alice to ensure no appearance number is assigned by the Appearance
2130 Agent. Finally, Bob hangs up with Alice and resumes the call with
2131 Carol.
2133 Note that if Carol hangs up while Bob is consulting with Alice, Bob
2134 can decide if he wants to reuse the appearance number used with Carol
2135 for the call with Alice. If not, Bob publishes the termination of
2136 the dialog with Carol and the Appearance Agent will re-allocate the
2137 appearance. If he wants to keep the appearance, Bob will publish the
2138 termination of the dialog with Carol and also publish the appearance
2139 with the dialog with Alice. This will result in Bob keeping the
2140 appearance number until he reports the dialog with Alice terminated.
2142 Carol Proxy Alice Appearance Agent Bob
2143 | | | | |
2144 |<================= Both way RTP established ===================>|
2145 | | | | |
2146 | |<------------------------------(hold) INVITE F28<|
2147 |<- INVITE F29<| | | |
2148 | | | | |
2149 |>F30 200 OK ->| | | |
2150 | |>F31 200 OK ------------------------------------>|
2151 | | | | |
2152 | |<--------------------------------------- ACK F32<|
2153 |<---- ACK F33<| | | |
2154 | | | |<---- PUBLISH F34<|
2155 | | | | |
2156 | | | |>F35 200 OK ----->|
2157 | | |<- NOTIFY F36<| |
2158 | | | | |
2159 | | |>F37 200 OK ->| |
2160 | | | |>F38 NOTIFY ----->|
2161 | | | | |
2162 | | | |<----- 200 OK F39<|
2163 | | | | |
2164 | | Bob makes a consultation call to Alice |
2165 | | | | |
2166 | | | |<---- PUBLISH F40<|
2167 | | | | |
2168 | | | |>F41 200 OK ----->|
2169 | | | | |
2170 | |<------------------------------------ INVITE F42<|
2171 | | | | |
2172 | | |<- NOTIFY F43<| |
2173 | | | | |
2174 | | |>F44 200 OK ->| |
2175 | | | |>F45 NOTIFY ----->|
2176 | | | | |
2177 | | | |<----- 200 OK F46<|
2178 | |>F47 INVITE -->| | |
2179 | | | | |
2180 | |<-- 200 OK F48<| | |
2181 | | |>F49 PUBLISH->| |
2182 | | | | |
2183 | | |<- 200 OK F50<| |
2184 | | | | |
2185 | | |<- NOTIFY F51<| |
2186 | | | | |
2187 | | |>F52 200 OK ->| |
2188 | | | |>F53 NOTIFY ----->|
2189 | | | | |
2190 | | | |<----- 200 OK F54<|
2191 | | | | |
2192 | |>F55 200 OK ------------------------------------>|
2193 | | | | |
2194 | |<--------------------------------------- ACK F56<|
2195 | | | | |
2196 | |>F57 ACK ----->| | |
2197 | | | | |
2198 | | |<======= RTP established =======>|
2199 | | | | |
2200 | | | |<---- PUBLISH F58<|
2201 | | | | |
2202 | | | |>F59 200 OK ----->|
2203 | | |<- NOTIFY F60<| |
2204 | | | | |
2205 | | |>F61 200 OK ->| |
2206 | | | |>F62 NOTIFY ----->|
2207 | | | | |
2208 | | | |<----- 200 OK F63<|
2209 | | | | |
2210 | | Bob hangs up with Alice |
2211 | | | | |
2212 | |<--------------------------------------- BYE F64<|
2213 | | | | |
2214 | | | |<---- PUBLISH F65<|
2215 | | | | |
2216 | | | |>F66 200 OK ----->|
2217 | | |<- NOTIFY F67<| |
2218 | | | | |
2219 | | |>F68 200 OK ->| |
2220 | | | |>F69 NOTIFY ----->|
2221 | | | | |
2222 | | | |<----- 200 OK F70<|
2223 | |>F71 BYE ----->| | |
2224 | | | | |
2225 | |<-- 200 OK F72<| | |
2226 | | |>F73 PUBLISH->| |
2227 | | | | |
2228 | | |<- 200 OK F74<| |
2229 | | | | |
2230 | | |<- NOTIFY F75<| |
2231 | | | | |
2232 | | |>F76 200 OK ->| |
2233 | | | |>F77 NOTIFY ----->|
2234 | | | | |
2235 | | | |<----- 200 OK F78<|
2236 | | | | |
2237 | |>F79 200 OK ------------------------------------>|
2238 | | | | |
2239 | | | |<---- PUBLISH F80<|
2240 | | | | |
2241 | | | |>F81 200 OK ----->|
2242 | | |<- NOTIFY F82<| |
2243 | | | | |
2244 | | |>F83 200 OK ->| |
2245 | | | |>F84 NOTIFY ----->|
2246 | | | | |
2247 | | | |<----- 200 OK F85<|
2248 | | | | |
2249 | |<----------------------------(unhold) INVITE F86<|
2250 |<- INVITE F87<| | | |
2251 | | | | |
2252 |>F88 200 OK ->| | | |
2253 | |>F89 200 OK ------------------------------------>|
2254 | | | | |
2255 | |<--------------------------------------- ACK F90<|
2256 |<---- ACK F91<| | | |
2257 | | | |<---- PUBLISH F92<|
2258 | | | | |
2259 | | | |>F93 200 OK ----->|
2260 | | |<- NOTIFY F94<| |
2261 | | | | |
2262 | | |>F95 200 OK ->| |
2263 | | | |>F96 NOTIFY ----->|
2264 | | | | |
2265 | | | |<----- 200 OK F97<|
2266 | | | | |
2267 |<================= Both way RTP established ===================>|
2268 | | | | |
2270 Figure 10.
2272 F40 Bob ----> Appearance Agent
2274 PUBLISH sip:appearance-agent@example.com SIP/2.0
2275 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A
2276 From: ;tag=44150CC6-A7B7919D
2277 To: ;tag=428765950880801
2278 CSeq: 11 PUBLISH
2279 Call-ID: 144-1289338424@example.com
2280 Contact:
2281 Event: dialog;shared
2282 Max-Forwards: 70
2283 Content-Type: application/dialog-info+xml
2284 Content-Length: ...
2286
2287
2292
2296 true
2297 trying
2298
2299
2300
2301
2302
2303 sip:alice@example.com
2304
2305
2306
2307
2309 F45 Appearance Agent ----> Bob
2311 NOTIFY sip:bob@ua1.example.com SIP/2.0
2312 From: ;tag=497585728578386
2313 To: ;tag=633618CF-B9C2EDA4
2314 Call-ID: a7d559db-d6d7dcad-311c9e3a@ua1.example.com
2315 CSeq: 7 NOTIFY
2316 Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1711759878512309
2317 Max-Forwards: 70
2318 Content-Type: application/dialog-info+xml
2319 Event: dialog;shared
2320 Subscription-State: active
2321 Contact:
2322 Content-Length: ...
2324
2325
2330
2334 true
2335 trying
2336
2337
2338
2339
2340
2341 sip:alice@example.com
2342
2343
2344
2345
2347 10.10. Joining or Bridging an Appearance
2349 In this call flow, a call answered by Bob is joined by Alice or
2350 "bridged". The Join header field is used by Alice to request this
2351 bridging. If Bob did not support media mixing, Bob could obtain
2352 conferencing resources as described in [RFC4579].
2354 Carol Forking Proxy Appearance Agent Alice Bob
2355 | | | | |
2356 |<=============Both way RTP established===========>|
2357 | | | | |
2358 | | |< PUBLISH F28| |
2359 | | | | |
2360 | | |>F29 200 OK >| |
2361 | | | | |
2362 | |<---- INVITE (w/ Join) F30<| |
2363 | | | | |
2364 | |>F31 INVITE (w/Join)---------------->|
2365 | | | | |
2366 | | |>F32 NOTIFY >| |
2367 | | | | |
2368 | | |< 200 OK F33<| |
2369 | | | | |
2370 | | |>F34 NOTIFY ---------->|
2371 | | | | |
2372 | | |F38 200 OK ---------->|
2379 | | | | |
2380 | | |>F39 NOTIFY >| |
2381 | | | | |
2382 | | |< 200 OK F40<| |
2383 | | | | |
2384 | | |>F41 NOTIFY ---------->|
2385 | | | | |
2386 | | |F43 200 OK Contact:B----->| |
2389 | | | | |
2390 | | |< PUBLISH F44| |
2391 | | | | |
2392 | | |>F45 200 OK >| |
2393 | | | | |
2394 | | |>F46 NOTIFY >| |
2395 | | | | |
2396 | | |< 200 OK F47<| |
2397 | | | | |
2398 | | |>F48 NOTIFY ---------->|
2399 | | | | |
2400 | | |ACK F51---------------------------->|
2405 | | | | |
2406 | |<-----INVITE Contact:Bob;isfocus F52<|
2407 |<-INVITE F53| | | |
2408 | | | | |
2409 |>F54 200 -->| | | |
2410 | |>F55 200 OK ------------------------>|
2411 | | | | |
2412 | |<--------------------------- ACK F56<|
2413 |<--- ACK F57| | | |
2414 | | | |<==RTP==>|
2415 |<=============Both way RTP established===========>|
2416 | | | | |
2417 | | |<--------- PUBLISH F58<|
2418 | | | | |
2419 | | |>F59 200 OK ---------->|
2420 | | | | |
2421 | | |>F60 NOTIFY >| |
2422 | | | | |
2423 | | |< 200 OK F61<| |
2424 | | | | |
2425 | | |>F62 NOTIFY ---------->|
2426 | | | | |
2427 | | | Appearance Agent
2433 PUBLISH sip:appearance-agent@example.com SIP/2.0
2434 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A
2435 From: ;tag=44150CC6-A7B7919D
2436 To: ;tag=428765950880801
2437 CSeq: 11 PUBLISH
2438 Call-ID: 1289338424@example.com
2439 Contact:
2440 Event: dialog;shared
2441 Max-Forwards: 70
2442 Content-Type: application/dialog-info+xml
2443 Content-Length: ...
2445
2446
2451
2452 0
2453 false
2454
2458 trying
2459
2460
2461
2462
2463
2464
2465
2466
2467
2469 F20 Alice ----> Proxy
2471 INVITE sip:bob@ua.example.com SIP/2.0
2472 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKcc9d727c2C29BE31
2473 From: ;tag=605AD957-1F6305C2
2474 To:
2475 CSeq: 2 INVITE
2476 Call-ID: dc95da63-60db1abd-d5a74b48@ua1.example.com
2477 Contact:
2478
2479 Join: 14-1541707345@example.com;to-tag=d3b06488-1dd1-11b2-88c5
2480 -b03162323164+d3e48f4c;from-tag=44BAD75D-E3128D42
2481
2482 Max-Forwards: 70
2483 Content-Type: application/sdp
2484 Content-Length: 223
2486 v=0
2487 o=- 1103061265 1103061265 IN IP4 ua1.example.com
2488 s=IP SIP UA
2489 c=IN IP4 ua1.example.com
2490 t=0 0
2491 a=sendrecv
2492 m=audio 2236 RTP/AVP 0 8 101
2493 a=rtpmap:0 PCMU/8000
2494 a=rtpmap:8 PCMA/8000
2495 a=rtpmap:101 telephone-event/8000
2497 10.11. Appearance Allocation - Loss of Appearance
2499 Bob reserves an appearance with a PUBLISH, sends an INVITE to Carol,
2500 then becomes unreachable. When he fails to refresh his publication
2501 to the appearance agent, the Appearance Agent declares the dialog
2502 terminated and frees up the appearance using NOTIFYs R24 and F26.
2503 After retransmitting the NOTIFY F26 to Bob, the subscription is
2504 terminated.
2506 Carol Proxy Alice Appearance Agent Bob
2507 | | | | |
2508 | | | |<----- PUBLISH F1<|
2509 | | | | |
2510 | | | |>F2 200 OK ------>|
2511 | | | | |
2512 | |<------------------------------------- INVITE F3<|
2513 | | | | |
2514 | |>F4 100 Trying --------------------------------->|
2515 |<-- INVITE F5<| | | |
2516 | | |<-- NOTIFY F6<| |
2517 | | | | |
2518 | | |>F7 200 OK -->| |
2519 | | | |------- NOTIFY F8>|
2520 | | | | |
2521 | | | |F10 180 --->| | | |
2523 | |>F11 180 Ringing ------------------------------->|
2524 | | | | |
2525 | | | | Bob goes offline
2526 | | | |
2527 | | | Appearance selection times out
2528 | | | |
2529 | | | |
2530 | | |<- NOTIFY F24<|
2531 | | | |
2532 | | |>F25 200 OK ->|
2533 | | | |------ NOTIFY F26>
2534 | | | |
2535 | | | NOTIFY is retransmitted
2537 Figure 12.
2539 10.12. Appearance Selection Contention Race Condition
2541 Bob and Alice both try to reserve appearance 2 by publishing at the
2542 same time. The Appearance Agent allocates the appearance to Bob by
2543 sending a 200 OK and denies it to Alice by sending a 409 Conflict.
2544 After the NOTIFY F24, Alice learns that Bob is using appearance 2.
2545 Alice republishes for appearance 3 which is accepted.
2547 Carol Proxy Alice Appearance Agent Bob
2548 | | | | |
2549 | | | |<----- PUBLISH F1<|
2550 | | | | (appearance=2)
2551 | | |>F2 PUBLISH ->| |
2552 | | | (appearance=2) |
2553 | | | | |
2554 | | | |>F2 200 OK ------>|
2555 | | |<---- F3 409 <| |
2556 | | | | |
2557 | | |<-- NOTIFY F4<| |
2558 | | | | |
2559 | | |>F5 200 OK -->| |
2560 | | | |------- NOTIFY F6>|
2561 | | | | |
2562 | | | |F9 100 Trying --------------------------------->|
2567 |<- INVITE F10<| | | |
2568 | | |>F11 PUBLISH->| |
2569 | | | (appearance=3) |
2570 | | | | |
2571 | | |<--- F12 200 <| |
2572 | | | | |
2573 | | |<- NOTIFY F13<| |
2574 | | | | |
2575 | |>F14 200 OK ->| |
2576 Dave | | |------ NOTIFY F15>|
2577 | | | | |
2578 | | | |F18 100 Trying ------------->| |
2582 |<- INVITE F19<| | | |
2584 Figure 13.
2586 11. IANA Considerations
2588 This section registers the SIP Alert-Info header field parameter
2589 "appearance" and the XML namespace extensions to the SIP Dialog
2590 Package.
2592 11.1. SIP Event Package Parameter: shared
2594 This specification also defines a new event parameter 'shared' for
2595 the Dialog Package. When used in a NOTIFY, it indicates that the
2596 notifier supports the shared appearance feature. When used in a
2597 PUBLISH, it indicates that the publisher has explicit appearance
2598 information contained in the message body. If not present in a
2599 PUBLISH, the Appearance Agent MAY assign an appearance number to any
2600 new dialogs in the message body.
2602 11.2. URN Sub-Namespace Registration: sa-dialog-info
2604 This section registers a new XML namespace per the procedures in
2605 [RFC3688].
2607 URI: urn:ietf:params:xml:ns:sa-dialog-info.
2609 Registrant Contact: IETF BLISS working group, ,
2610 Alan Johnston
2612 XML:
2614 BEGIN
2615
2616
2618
2619
2620
2622 Shared Appearance Dialog Information Namespace
2623
2624
2625 Namespace for Shared Appearance Dialog Information
2626 urn:ietf:params:xml:ns:dialog-info
2627 See
2628 RFCXXXX.
2629
2630
2631 END
2633 11.3. XML Schema Registration
2635 This section registers an XML schema per the procedures in [RFC3688].
2637 URI: urn:ietf:params:xml:schesa:sa-dialog-info.
2639 Registrant Contact: IETF BLISS working group, ,
2640 Alan Johnston
2642 The XML for this schema can be found in .
2644 12. Appendix A - Incoming Appearance Assignment
2646 To best meet REQ-9, the appearance number for an incoming INVITE
2647 should be contained in the INVITE itself.
2649 For the dialog package parameter approach, REQ-9 could be met in two
2650 ways. When an incoming request is received, the Appearance Agent
2651 could send out a NOTIFY with state trying and include the appearance
2652 number to be used for this request. Upon receipt of this NOTIFY, the
2653 UAs could begin alerting using the appearance number selected. This
2654 approach is sub-optimal since the UAs could receive the INVITE but be
2655 unable to begin alerting if the NOTIFY from the Appearance Agent is
2656 delayed or lost
2658 An alternative approach is to define an extension parameter for the
2659 Alert-Info header field in RFC 3261 such as:
2661 Alert-Info: ;alert=normal;appearance=0
2663 This Alert-Info header would indicate to place the call on the first
2664 line appearance instance.
2666 OPEN ISSUE: What URI do we use if no special ring is requested?
2668 The determination as to what value to use in the appearance parameter
2669 can be done at the proxy that forks the incoming request to all the
2670 registered UAs. There are a variety of ways the proxy can use to
2671 determine what value it should use to populate this parameter. For
2672 example, the proxy could fetch this information by initiating a
2673 SUBSCRIBE request with Expires: 0 to the Appearance Agent for the AOR
2674 to fetch the list of lines that are in use. Alternatively, it could
2675 act like a UA that is a part of the appearance group and SUBSCRIBE to
2676 the State-Agent like any other UA. This would ensure that the active
2677 dialog information is available without having to poll on a need
2678 basis. It could keep track of the list of active calls for the
2679 appearance AOR based on how many unique INVITE requests it has forked
2680 to or received from the appearance AOR. Another approach would be
2681 for the Proxy to first send the incoming INVITE to the Appearance
2682 Agent which would redirect to the appearance group URI and escape the
2683 proper Alert-Info header field for the Proxy to recurse and
2684 distribute to the other UAs in the group.
2686 The Appearance Agent needs to know about all incoming requests to the
2687 AOR in order to select the appearance number. One way in which this
2688 could be done is for the Appearance Agent to register against the AOR
2689 with a higher q value. This will result in the INVITE being sent to
2690 the Appearance Agent first, then being offered to the UAs in the
2691 group.
2693 The changes to RFC 3261 ABNF would be:
2695 alert-param = LAQUOT absoluteURI RAQUOT *( SEMI (generic-param /
2696 appearance-param) )
2698 appearance-param = "appearance" EQUAL *DIGIT
2700 13. Appendix B - Implementation Options Discussion
2702 This section discusses some options on how to implement the Shared
2703 Appearances feature in SIP. This section is non-normative.
2705 13.1. Appearance Implementation Options
2707 This section discusses and compares two methods of implementing,
2708 conveying, and selecting appearances in SIP while meeting the
2709 requirements of Section 4. One approach involves a URI parameter and
2710 is discussed in section 5.1.1. The other approach uses a SIP dialog
2711 package extension parameter and is discussed in section 5.1.2. Both
2712 approaches assume the common elements and operations of Figure 1. In
2713 addition, this section discusses approaches for incoming appearance
2714 indication, REQ-9, and appearance contention, REQ-8. These
2715 approaches will be discussed for an example appearance group of N
2716 phones each with n line appearances. The usage of the word phone
2717 does not imply that this feature is limited to telephony devices.
2719 13.1.1. URI parameter Approach
2721 Some implementations of this feature utilize a URI parameter such as
2722 "line=3" on the Contact URI. Each appearance is effectively a
2723 logical UA, so each line appearance requires a separate registration.
2724 The number of line appearances needs to be provisioned on each phone.
2725 Each appearance also requires a separate dialog package subscription.
2727 Even using a State Agent for the dialog package, each phone must
2728 maintain n subscriptions to the dialog package.
2730 This results in 2nN total subscriptions and nN registrations for this
2731 implementation.
2733 Since Contact URI parameters will be conveyed by the dialog package,
2734 REQ-7 is met.
2736 REQ-10 can be met by having the Appearance Agent send a SUBSCRIBE to
2737 each UA and line number to obtain the current dialog state - this
2738 will result in nN SUBSCRIBEs and NOTIFYs.
2740 It is not obvious how to meet REQ-11 with this approach. A UA
2741 registering against the AOR but does not implement the appearance URI
2742 parameter will not include a line appearance number in Contact URIs
2743 and dialog package NOTIFYs. The Appearance Agent will have no way of
2744 indicating to the other UAs the appearance number being used by this
2745 UA, as adding a parameter to the Contact URI would cause call control
2746 operations such as Replaces and Join to fail.
2748 REQs 12 and 13 are difficult to meet with this approach as the line
2749 appearance number will be present in the Request-URI of incoming
2750 requests and the Contact URI in INVITE and 200 OK messages. This
2751 approach will require integrity protection of all dialog creating
2752 requests and responses, and privacy mechanisms to hide the Contact
2753 URI from other UAs.
2755 Also, this approach will require mechanisms to protect against
2756 another UA sending an INVITE directly to a group member with the line
2757 appearance number already set.
2759 13.1.2. Dialog Package Parameter
2761 Instead of the URI parameter approach, consider an extension
2762 parameter "appearance" to the SIP dialog package. The e.g.:
2764
2765
2770
2772 2
2773 false
2774
2775
2776 connected
2777
2778
2779
2780
2781
2782 ...
2784 In this approach, the appearance number is never carried in a
2785 Request-URI or Contact URI. Instead, it is only present in dialog
2786 package NOTIFY and PUBLISH messages. As a result, only a single
2787 registration per AOR is required. Also, only a single dialog package
2788 subscription in each direction per AOR.
2790 This results in 2N total subscriptions and N registrations for this
2791 approach.
2793 If the dialog package is extended to carry the appearance number,
2794 then REQ-7 is met.
2796 REQ-10 can be met by having the Appearance Agent send a SUBSCRIBE to
2797 each UA and line number to obtain the current dialog state - this
2798 will result in N SUBSCRIBEs and NOTIFYs.
2800 REQ-11 can be met by this approach. Even though a UA does not
2801 provide an appearance number in dialog package NOTIFYs, the
2802 Appearance Agent can assign one and include it in NOTIFYs to the
2803 other UAs. This parameter would simply be ignored by the UAs that
2804 did not understand the parameter, and have no impact on call control
2805 operations.
2807 REQs 12 and 13 are met because the appearance number is only conveyed
2808 in dialog package NOTIFYs. Integrity and privacy of NOTIFY bodies
2809 can be achieved using normal SIP mechanisms independent of the
2810 security mechanisms used for other requests.
2812 The dialog-package [RFC3265] describes a mechanism whereby shared-
2813 line privacy REQ-14 can be accomplished by suppressing certain dialog
2814 information from being presented to the UAs. The reasoning behind
2815 that is if the UAs were unaware of a dialog's call-id, local-tag and
2816 remote-tag then they will be unable to create requests such as INVITE
2817 with Replaces [RFC3891] and Join [RFC3911] header fields to barge-in
2818 or pickup the line appearance. Below is a quote from section 3.6 of
2819 dialog-package[RFC3265] that describes this approach:
2821 Note that many implementations of "shared-lines" have a feature that
2822 allows details of calls on a shared address-of-record to be made
2823 private. This is a completely reasonable authorization policy that
2824 could result in notifications that contain only the id attribute of
2825 the dialog element and the state element when shared-line privacy is
2826 requested, and notifications with more complete information when
2827 shared-line privacy is not requested.
2829 There are certain fundamental drawbacks in the privacy-by-obscurity
2830 approach described in [RFC3265] . It models exclusivity as a static
2831 property of the appearance AOR. There are situations where
2832 exclusivity needs to be a dynamic property (e.g. boss does not want
2833 secretary to listen-in on a particular part of the conversation). In
2834 addition, [RFC3265] does not address how a UA can request exclusivity
2835 at the start of a session or mid-session and how that request will be
2836 granted or rejected.
2838 Exclusivity being a dynamic property means that a UA can request it
2839 to be turned on or off in the middle of a session. When exclusivity
2840 is turned off all the UAs that share the line AOR will need to see
2841 the complete dialog information. Once they have that information it
2842 can not be taken back from them. This will not allow exclusivity to
2843 be turned on later on in the dialog lifetime. Therefore, there needs
2844 to be a centralized entity that will actually enforce exclusivity.
2846 The approach proposed for meeting REQ-14 is to include an exclusivity
2847 parameter to the dialog package. This allows a UA to request
2848 exclusivity, by setting the exclusive parameter in notifications.
2849 This could be done prior to a call being made or answered, or during
2850 a call at any time. A UA can remove exclusivity by sending a
2851 notification at any time during a call and setting "exclusive=no".
2852 It also allows a UA to learn that a particular dialog is exclusive by
2853 the presence of this parameter in a NOTIFY. In addition, a UA can
2854 still apply policy to any INVITE Join or Replaces requests it
2855 receives, as per normal SIP call control mechanisms.
2857 With this approach, the number of appearances is centrally managed
2858 and controlled by the Appearance Agent. For UAs with soft keys or
2859 buttons, this gives a great deal of flexibility in system management.
2861 The User Agents in the group could SUBSCRIBE to each other and NOTIFY
2862 dialog state events, but in a large group the User Agents have to
2863 manage a larger number of SUBSCRIPTIONS and NOTIFICATIONS. The State
2864 Agent in the Appearance Agent helps in managing large groups better.
2865 Further, the State Agent can filter dialog state events and NOTIFY
2866 User Agents of the dialog state events which are required for the
2867 application or feature. The State Agent can also SUBSCRIBE to dialog
2868 state events with filters to reduce the number of NOTIFY messages
2869 exchanged between the State Agent and the user agents in the group.
2870 This allows a group of N UAs to each only establish a pair of dialog
2871 state subscriptions (one in each direction) to learn the dialog state
2872 of all other group members. This results in 2N total subscriptions
2873 for the entire group. A full mesh of subscriptions without a state
2874 agent would result in N(N-1) total subscriptions.
2876 13.1.3. Appearance Selections Mechanisms
2878 Regardless of how the appearance number is conveyed by UAs, there is
2879 still the issue of how appearance numbers are selected. For example,
2880 some UAs might have actual buttons and lamps, and pressing a
2881 particular button requires the UA to reserve a particular appearance
2882 number. For devices with this type of user interface, the selection
2883 must be done before the user continues with the call and dials digits
2884 or a URI. Other UAs with different user interfaces can be flexible
2885 at the time of dialing, updating the display with the appearance
2886 number at a later date. For devices which require advance appearance
2887 selection, there are three options discussed in the following
2888 sections for meeting REQ-15.
2890 13.1.3.1. Floor Control Appearance Selection Mechanism
2892 This approach models each appearance number as a floor (shared
2893 resource) and uses a floor control server to arbitrate exclusive
2894 access (seizure of a particular appearance number). This approach
2895 uses a standard SIP Event State Compositor (ESC), a standard Floor
2896 Control Server that uses the Appearance Agent as Moderator. The
2897 Binary Floor Control Protocol (BFCP) is used between the UAs and the
2898 Floor Control Server. A Registrar/Forking Proxy Server talks to
2899 Appearance Agent about incoming calls. The Appearance Agent acts as
2900 a Moderator for the floor control server and tells forking proxy to
2901 insert the appearance number in incoming and outgoing requests.
2903 Appearance numbers are allocated/selected/reserved in two ways:
2905 For incoming calls, the Forking Proxy interacts with the Appearance
2906 Agent. The Appearance Agent selects an appearance by taking a
2907 particular floor and marking it "moderator controlled". This
2908 appearance number is then included by the Forking Proxy in INVITEs
2909 using the Alert-Info parameter. When a UA answers the call, it takes
2910 the appearance number from the Alert-Info and includes it in the
2911 dialog state publication. It then requests the floor associated with
2912 the appearance number from the floor control server, which forwards
2913 the request to the Appearance Agent (moderator). The Appearance
2914 Agent correlates the floor control request with the dialog state
2915 notification with the dialog ID from the INVITE with the Alert-Info.
2916 If they match, the floor is granted. If they do not match, it means
2917 the floor request is not an answer of the call but is a random
2918 appearance selection by the UA and will be rejected.
2920 For outgoing calls, the UA sends an INVITE and requests a particular
2921 floor from the floor control server. Depending on the User Interface
2922 requirements, the floor request can be done before or after sending
2923 the INVITE. The floor grant policy for most appearances is set to
2924 "first come first serve". Once the floor has been granted and the
2925 call answered, the dialog state publication by the UA will include
2926 the appearance number.
2928 When a call has ended, the UA releases the floor to the floor control
2929 server and this appearance is now available for incoming and outgoing
2930 calls.
2932 When a UA in the group which does not support BFCP is in a call, the
2933 Appearance Agent will grant the floor associated with that appearance
2934 to that UA. When that call is over, the Appearance Agent will
2935 release the floor. Since the UA will not publish the appearance
2936 number to the ESC, the Appearance Agent will need to do that on their
2937 behalf. If the UA does publish dialog state but without the
2938 appearance number, the Appearance Agent will still need to re-publish
2939 the dialog state including the appearance number. UAs in the group
2940 will be able to recognize these two dialogs as one since they will
2941 have the same SIP dialog ID.
2943 13.1.3.2. INVITE Appearance Selection Mechanism
2945 This is an alternative approach that utilizes sending an INVITE to
2946 select/reserve/seize an appearance number.
2948 A UA that does not need to select a particular appearance number (or
2949 doesn't care) would just send an INVITE as normal. The Appearance
2950 Agent would tell the proxy which appearance number was being used by
2951 inserting this information in a header field in the first non-100
2952 provisional response sent back to the calling UA. The UA would then
2953 PUBLISH this appearance number to the Dialog Event State Compositor
2954 for the AOR which would distribute details of the dialog and the
2955 appearance number to the other UAs in the group.
2957 If an INVITE is sent and no appearance number is available, the proxy
2958 would reject the INVITE with a suitable response code and perhaps a
2959 header field indication.
2961 A UA that does need to select a particular appearance number would
2962 use an approach similar to overlap dialing (multi-stage dialing). An
2963 INVITE would be sent when the appearance number is requested (i.e.
2964 when the button is pressed, before dialing begins). The appearance
2965 number selected would be carried in the INVITE, in a header field or
2966 in the Request-URI, for example. The proxy would reject the INVITE
2967 with a 484 Address Incomplete response (see RFC 3578) if the
2968 appearance number is Available and start a timer. The UA could then
2969 resend the INVITE after the URI has been dialed and then PUBLISH this
2970 appearance number to the ESC. If the appearance number is not
2971 available, another response code such as 403 would be sent. The user
2972 could then select a different appearance number and resend the
2973 INVITE. If no INVITE with a matching Call-ID is received before the
2974 timer expires, the appearance seizure is cancelled and is made
2975 available for other calls.
2977 Note that this approach does not actually require a B2BUA, but it
2978 does require a proxy that can act as a UAS and communicate with an
2979 Appearance Agent which keeps track of appearance number allocations.
2981 13.1.3.3. PUBLISH Appearance Selection Mechanism
2983 The approach used in previous versions of this draft is to use the
2984 PUBLISH to the event state compositor to select an appearance number.
2985 This approach requires a special event state compositor and special
2986 behavior on the part of the UA.
2988 In the selection of an appearance for requests initiated by UAs in
2989 the group, there is the possibility of contention where more than one
2990 UA select the same appearance number.
2992 One way to solve this and meet REQ-8 is to require UAs to send a
2993 notification (trying) to the Appearance Agent indicating the
2994 appearance number to be used for the session. The Appearance Agent
2995 would confirm the allocation of the appearance number in a NOTIFY
2996 sent to the group UAs. Should the appearance number be unavailable
2997 or otherwise not allowed, there are two options:
2999 - The notification could be rejected with a 500 response and a Retry-
3000 After header field. The Appearance Agent would send an immediate
3001 NOTIFY indicating that the appearance is unavailable. If the NOTIFY
3002 is received before the expiration of the Retry-After time, the
3003 notification state information would become out of date and would be
3004 discarded without resending. The UA would select another appearance
3005 number and send another notification.
3007 - The notification could be accepted but an immediate NOTIFY
3008 generated by the Appearance Agent indicating that the appearance is
3009 unavailable. The UA would then select another appearance number and
3010 PUBLISH again.
3012 UAs would wait for a notification from the Appearance Agent before
3013 sending the INVITE.
3015 13.2. Comparison
3017 In comparing the URI parameter and the dialog package parameter,
3018 there are clear differences in the number of registrations and
3019 subscriptions, with the dialog package approach requiring n times
3020 fewer in both cases.
3022 The security model for the dialog package parameter approach is much
3023 cleaner, since only NOTIFY and PUBLISH requests need integrity and
3024 privacy. The security model for the URI parameter approach would
3025 likely require a B2BUA which introduces many undesirable properties.
3027 The dialog package parameter approach has better backwards
3028 compatibility than the URI parameter approach.
3030 In summary, the dialog package parameter approach better meets REQs
3031 5, 10, 11, 12, and 13 while the URI parameter approach better meets
3032 REQ-9. However, the combined dialog package parameter approach and
3033 the Alert-Info parameter approach meets REQ-9.
3035 13.2.1. Comparison of Appearance Selection Methods
3037 All three approaches meet REQ-15 and REQ-16.
3039 Previous versions of this draft proposed the publish/notify method of
3040 appearance selection. The advantage of this approach is that the
3041 appearance number is only carried in one place (dialog package XML
3042 documents) and the same protocol/mechanism is used to select and
3043 learn appearance numbers. The disadvantage of this approach is that
3044 a specialized event state compositor must be used, since it is aware
3045 of appearance numbers. Also, concerns have been raised about whether
3046 this approach defines new semantics for publish/notify beyond that in
3047 RFC 3265.
3049 The floor control approach makes good reuse of existing protocols
3050 such as Binary Floor Control Protocol (BFCP) and cleanly models the
3051 state. However, while BFCP can be used in conferencing applications,
3052 it is unlikely most UAs implementing shared appearances would utilize
3053 the protocol. Also, having appearance state in two places (dialog
3054 package XML documents and floor control messages) complicates the
3055 application. Also, BFCP only runs over TCP and requires a separate
3056 offer/answer exchange to establish the connection, making operation
3057 through NATs and firewalls more difficult. The BFCP approach is also
3058 radically different from all current implementations of this feature.
3059 As a result, standardizing this approach would likely result in an
3060 increase in feature interoperability rather than a decrease.
3062 The INVITE selection mechanism is based on overlap dialing. Overlap
3063 dialing is supported in very few SIP UAs and is regarded as a
3064 somewhat archaic leftover from the PSTN. As such, it is not regarded
3065 as a good starting point for a common feature such as shared
3066 appearances.
3068 The PUBLISH selection mechanism reuses the SIP events extensions
3069 which already must be implemented by UAs supporting this feature. In
3070 fact, it results in no additional messages or round trips. It is
3071 also very similar to many current feature implementations today.
3072 Standardizing this approach is likely to increase overall
3073 interoperability of this feature.
3075 The rest of this document will only discuss the PUBLISH appearance
3076 selection mechanism.
3078 14. Acknowledgements
3080 The following individuals were part of the shared appearance Design
3081 team and have provided input and text to the document (in
3082 alphabetical order):
3084 Martin Dolly, Andrew Hutton, Raj Jain, Fernando Lombardo, Derek
3085 MacDonald, Bill Mitchell, Michael Procter, Theo Zowzouvillys.
3087 Thanks to Chris Boulton for helping with the XML schema.
3089 Much of the material has been drawn from previous work by Mohsen
3090 Soroushnejad, Venkatesh Venkataramanan, Paul Pepper and Anil Kumar,
3091 who in turn received assistance from:
3093 Kent Fritz, John Weald, and Sunil Veluvali of Sylantro Systems, Steve
3094 Towlson, and Michael Procter of Citel Technologies, Rob Harder and
3095 Hong Chen of Polycom Inc, John Elwell, J D Smith of Siemens
3096 Communications, Dale R. Worley of Pingtel, Graeme Dollar of Yahoo
3097 Inc.
3099 Also thanks to Geoff Devine, Paul Kyzivat, Jerry Yin, John Elwell,
3100 Dan York, Spenser Dawkins, Martin Dolly, and Brett Tate for their
3101 comments.
3103 15. Security Considerations
3105 Since multiple line appearance features are implemented using
3106 semantics provided by [RFC3261], Event Package for Dialog State as
3107 define in , and Event Notification [RFC3265], [RFC3903], security
3108 considerations in these documents apply to this draft as well.
3110 Specifically, since dialog state information and the dialog
3111 identifiers are supplied by UA's in an appearance group to other
3112 members, the same is prone to "call hijacks". For example, a rogue
3113 UA could snoop for these identifiers and send an INVITE with Replaces
3114 header containing these call details to take over the call. As such
3115 INVITES with Replaces header MUST be authenticated using the standard
3116 mechanism (like Digest or S/MIME) described in [RFC3261]. before it
3117 is accepted. NOTIFY or PUBLISH message bodies that provide the
3118 dialog state information and the dialog identifiers MAY be encrypted
3119 end-to-end using the standard mechanics. All SUBSCRIBES between the
3120 UA's and the Appearance Agent MUST be authenticated.
3122 16. Informative References
3124 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
3125 Requirement Levels", BCP 14, RFC 2119, March 1997.
3127 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
3128 A., Peterson, J., Sparks, R., Handley, M., and E.
3129 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
3130 June 2002.
3132 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
3133 Method", RFC 3515, April 2003.
3135 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
3136 Event Notification", RFC 3265, June 2002.
3138 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
3139 for Event State Publication", RFC 3903, October 2004.
3141 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
3142 Protocol (SIP) "Replaces" Header", RFC 3891,
3143 September 2004.
3145 [I-D.ietf-sipping-service-examples]
3146 Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and
3147 K. Summers, "Session Initiation Protocol Service
3148 Examples", draft-ietf-sipping-service-examples-15 (work in
3149 progress), July 2008.
3151 [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
3152 Initiated Dialog Event Package for the Session Initiation
3153 Protocol (SIP)", RFC 4235, November 2005.
3155 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
3156 Package for Registrations", RFC 3680, March 2004.
3158 [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol
3159 (SIP) "Join" Header", RFC 3911, October 2004.
3161 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
3162 Extensions to the Session Initiation Protocol (SIP) for
3163 Asserted Identity within Trusted Networks", RFC 3325,
3164 November 2002.
3166 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol
3167 (SIP) Call Control - Conferencing for User Agents",
3168 BCP 119, RFC 4579, August 2006.
3170 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
3171 "Indicating User Agent Capabilities in the Session
3172 Initiation Protocol (SIP)", RFC 3840, August 2004.
3174 Authors' Addresses
3176 Alan Johnston (editor)
3177 Avaya
3178 St. Louis, MO 63124
3180 Email: alan@sipstation.com
3182 Mohsen Soroushnejad
3183 Sylantro Systems Corp
3185 Email: mohsen.soroush@sylantro.com
3186 Venkatesh Venkataramanan
3187 Sylantro Systems Corp
3189 Email: vvenkatar@gmail.com
3191 Full Copyright Statement
3193 Copyright (C) The IETF Trust (2008).
3195 This document is subject to the rights, licenses and restrictions
3196 contained in BCP 78, and except as set forth therein, the authors
3197 retain all their rights.
3199 This document and the information contained herein are provided on an
3200 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
3201 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
3202 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
3203 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
3204 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
3205 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
3207 Intellectual Property
3209 The IETF takes no position regarding the validity or scope of any
3210 Intellectual Property Rights or other rights that might be claimed to
3211 pertain to the implementation or use of the technology described in
3212 this document or the extent to which any license under such rights
3213 might or might not be available; nor does it represent that it has
3214 made any independent effort to identify any such rights. Information
3215 on the procedures with respect to rights in RFC documents can be
3216 found in BCP 78 and BCP 79.
3218 Copies of IPR disclosures made to the IETF Secretariat and any
3219 assurances of licenses to be made available, or the result of an
3220 attempt made to obtain a general license or permission for the use of
3221 such proprietary rights by implementers or users of this
3222 specification can be obtained from the IETF on-line IPR repository at
3223 http://www.ietf.org/ipr.
3225 The IETF invites any interested party to bring to its attention any
3226 copyrights, patents or patent applications, or other proprietary
3227 rights that may cover technology that may be required to implement
3228 this standard. Please address the information to the IETF at
3229 ietf-ipr@ietf.org.