idnits 2.17.1
draft-ietf-bliss-shared-appearances-00.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 22.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 2565.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2576.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2583.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2589.
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 7 instances of too long lines in the document, the longest one
being 416 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 (September 24, 2008) is 5690 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 2004, but not defined
== Unused Reference: 'RFC3325' is defined on line 2510, 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: March 28, 2009 M. Soroushnejad
5 V. Venkataramanan
6 Sylantro Systems Corp
7 P. Pepper
8 Citel Technologies
9 A. Kumar
10 Yahoo Inc.
11 September 24, 2008
13 Shared Appearances of a Session Initiation Protocol (SIP) Address of
14 Record (AOR)
15 draft-ietf-bliss-shared-appearances-00
17 Status of this Memo
19 By submitting this Internet-Draft, each author represents that any
20 applicable patent or other IPR claims of which he or she is aware
21 have been or will be disclosed, and any of which he or she becomes
22 aware will be disclosed, in accordance with Section 6 of BCP 79.
24 Internet-Drafts are working documents of the Internet Engineering
25 Task Force (IETF), its areas, and its working groups. Note that
26 other groups may also distribute working documents as Internet-
27 Drafts.
29 Internet-Drafts are draft documents valid for a maximum of six months
30 and may be updated, replaced, or obsoleted by other documents at any
31 time. It is inappropriate to use Internet-Drafts as reference
32 material or to cite them other than as "work in progress."
34 The list of current Internet-Drafts can be accessed at
35 http://www.ietf.org/ietf/1id-abstracts.txt.
37 The list of Internet-Draft Shadow Directories can be accessed at
38 http://www.ietf.org/shadow.html.
40 This Internet-Draft will expire on March 28, 2009.
42 Abstract
44 This document describes the requirements and implementation of a
45 group telephony feature commonly known as Bridged Line Appearance
46 (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line
47 Appearance (SCA). When implemented using the Session Initiation
48 Protocol (SIP), it is referred to as Shared Appearances (SA) of an
49 Address of Record (AOR) since SIP does not have the concept of lines.
50 This feature is commonly offered in the IP Centrex services and IP-
51 PBX offerings and is likely to be implemented on SIP IP telephones
52 and SIP feature servers used in a business environment. This
53 document lists requirements and compares implementation options for
54 this feature. Extensions to the SIP dialog event package are
55 proposed.
57 Table of Contents
59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
60 2. Conventions used in this document . . . . . . . . . . . . . . 5
61 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5
62 3.1. Executive/Assistant Arrangement . . . . . . . . . . . . . 5
63 3.2. BLA Call Group . . . . . . . . . . . . . . . . . . . . . . 5
64 3.3. Single Line Extension . . . . . . . . . . . . . . . . . . 6
65 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
66 5. Normative Description . . . . . . . . . . . . . . . . . . . . 7
67 5.1. Implementation . . . . . . . . . . . . . . . . . . . . . . 7
68 5.2. SA Dialog Package Extensions . . . . . . . . . . . . . . . 10
69 5.2.1. The element . . . . . . . . . . . . . . . 11
70 5.2.2. The element . . . . . . . . . . . . . . . 11
71 5.2.3. The element . . . . . . . . . . . . . 11
72 5.3. Shared Appearance User Agents . . . . . . . . . . . . . . 11
73 5.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . . 13
74 6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 14
75 7. User Interface Considerations . . . . . . . . . . . . . . . . 15
76 7.1. Appearance Number Rendering . . . . . . . . . . . . . . . 15
77 7.1.1. Single Appearance UAs . . . . . . . . . . . . . . . . 16
78 7.1.2. Dual Appearance UAs . . . . . . . . . . . . . . . . . 16
79 7.1.3. Shared Appearance UAs with Fixed Appearance Number . . 16
80 7.1.4. Shared Appearance UAs with Variable Appearance
81 Number . . . . . . . . . . . . . . . . . . . . . . . . 16
82 7.2. Call State Rendering . . . . . . . . . . . . . . . . . . . 17
83 8. Interop with non-SA UAs . . . . . . . . . . . . . . . . . . . 17
84 8.1. Appearance Assignment . . . . . . . . . . . . . . . . . . 18
85 8.2. Appearance Release . . . . . . . . . . . . . . . . . . . . 18
86 8.3. UAs Supporting Dialog Events but Not SA . . . . . . . . . 18
87 9. Provisioning Considerations . . . . . . . . . . . . . . . . . 19
88 10. Example Message Flows . . . . . . . . . . . . . . . . . . . . 19
89 10.1. Registration and Subscription . . . . . . . . . . . . . . 19
90 10.2. Appearance Selection for Outgoing Call . . . . . . . . . . 22
91 10.3. Taking an Appearance . . . . . . . . . . . . . . . . . . . 26
92 10.4. Appearance Selection for Incoming Call . . . . . . . . . . 33
93 10.5. Appearance Publication . . . . . . . . . . . . . . . . . . 37
94 10.6. Joining an Appearance . . . . . . . . . . . . . . . . . . 39
95 10.7. Appearance Allocation - Loss of Subscription with UA . . . 42
96 10.8. Appearance Selection Contention Race Condition . . . . . . 43
97 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
98 11.1. SIP Event Package Parameter: sa . . . . . . . . . . . . . 44
99 11.2. URN Sub-Namespace Registration: sa-dialog-info . . . . . . 44
100 11.3. XML Schema Registration . . . . . . . . . . . . . . . . . 45
101 12. Appendix A - Incoming Appearance Assignment . . . . . . . . . 45
102 13. Appendix B - Implementation Options Discussion . . . . . . . . 46
103 13.1. Appearance Implementation Options . . . . . . . . . . . . 46
104 13.1.1. URI parameter Approach . . . . . . . . . . . . . . . . 46
105 13.1.2. Dialog Package Parameter . . . . . . . . . . . . . . . 47
106 13.1.3. Appearance Selections Mechanisms . . . . . . . . . . . 50
107 13.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 52
108 13.2.1. Comparison of Appearance Selection Methods . . . . . . 53
109 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 54
110 15. Security Considerations . . . . . . . . . . . . . . . . . . . 54
111 16. Informative References . . . . . . . . . . . . . . . . . . . . 55
112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56
113 Intellectual Property and Copyright Statements . . . . . . . . . . 57
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 is
152 for a number of business telephones to share a single or a small
153 number of Address of Record (AOR) URIs. The sharing of this AOR
154 between multiple UAs is what gives this feature its name. In
155 addition, an AOR can have multiple appearances on a single UA in
156 terms of the user interface. The appearance number relates to the
157 user interface for the telephone - typically each appearance or an
158 AOR has a visual display (lamp that can change color or blink) and a
159 button (used to select the appearance). The telephony concept of
160 line aappearance is still relevant to SIP due to the user interface
161 considerations. It is important to keep the appearance number
162 construct because:
164 1. Human users are used to the concept and will expect it in
165 replacement systems (e.g. an overhead page announcement says "Joe
166 pickup line 3").
167 2. It is a useful structure for user interface representation.
169 In this document, we will use the term "appearance" rather than "line
170 appearance" since SIP does not have the concept of lines. Note that
171 this does not mean that a conventional telephony user interface
172 (lamps and buttons) must be used - implementations may use another
173 metaphor as long as the appearance number is readily apparent to the
174 user. Each AOR has a separate appearance numbering space. As a
175 result, a given UA user interface may have multiple occurrences of
176 the same appearance number, but they will be for different AORs.
178 2. Conventions used in this document
180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
182 document are to be interpreted as described in RFC-2119 [RFC2119] and
183 indicate requirement levels for compliant mechanisms.
185 3. Usage Scenarios
187 The following examples are common applications of the Shared
188 Appearances feature and are mentioned here as informative use cases.
189 All these example usages can be supported by the Shared Appearances
190 feature described in this document. The differences relate to the
191 user interface considerations of the device.
193 3.1. Executive/Assistant Arrangement
195 The appearances on the executive's UA may also appear on the
196 assistant's UA. The assistant may answer incoming calls to the
197 executive and then place the call on hold for the executive to pick
198 up. The assistant can always see the state of all calls on the
199 executive's UA.
201 3.2. BLA Call Group
203 Users with similar business needs or tasks can be assigned to
204 specific groups and share the line appearances of each other on each
205 others SIP telephony devices. For example, an IT department staff of
206 five might answer a help line which has three appearances on each
207 phone in the IT work area. A call answered on one phone can be put
208 on hold and picked up on another phone. A shout or an IM to another
209 staff member can result in them taking over a call on a particular
210 appearance. Another phone can request to be added to an appearance
211 resulting in a conference call.
213 3.3. Single Line Extension
215 In this scenario, incoming calls are offered to a group of UAs. When
216 one answers, the other UAs are informed. If another UA in the group
217 selects the line (i.e. goes off hook), it is immediately bridged or
218 joined in with the call. This mimics the way residential telephone
219 extensions usually operate.
221 4. Requirements
223 The basic requirements of the shared appearance feature can be
224 summarized as follows:
226 REQ-1 Incoming calls to the AOR must be offered to a group of UAs and
227 can be answered by any of them.
229 REQ-2 Each UA in the group must be able to learn the call status of
230 the others in the group for the purpose of rendering this information
231 to the user.
233 REQ-3 Calls can be joined (also called bridged or conferenced
234 together) or can be picked up (taken) by another UA in the group in a
235 secure way.
237 REQ-4 The mechanism should require the minimal amount of
238 configuration. UAs registering against the group AOR should be able
239 to learn about each other and join the appearance group.
241 REQ-5 The mechanism must scale for large numbers of appearances, n,
242 and large numbers of UAs, N, without introducing excessive messaging
243 traffic.
245 REQ-6 Each call or session (incoming or outgoing) must be assigned a
246 common "appearance" number from a managed pool administered for the
247 AOR group. Once the session has terminated, the appearance number is
248 released back into the pool and can be reused by another incoming or
249 outgoing session.
251 REQ-7 Each UA in the group must be able to learn the appearance
252 status of the the group.
254 REQ-8 There must be mechanisms to resolve appearance contention among
255 the UAs in the group.
257 REQ-9 The mechanism must allow all UAs receiving an incoming session
258 request to select the same appearance number at the time of alerting.
260 REQ-10 The mechanism must have a way of reconstructing appearance
261 state after an outage that does not result in excessive traffic and
262 processing.
264 REQ-11 The mechanism must have backwards compatibility such that a UA
265 which is unaware of the feature can still register against the group
266 AOR and make and receive calls.
268 REQ-12 The mechanism must not allow UAs outside the group to select
269 or manipulate appearance numbers.
271 REQ-13 For privacy reasons, there must be a mechanism so that
272 appearance information is not leaked outside the group of UAs. (e.g.
273 "So who do you have on line 1?")
275 REQ-14 The mechanism must support a way for UAs to request
276 exclusivity on a line appearance. Exclusivity means that the UA
277 requesting it desires to have a private conversation with the
278 external party and other UAs must not be allowed to barge-in.
279 Exclusivity may be requested at the start of an incoming or outgoing
280 session or during the session. An exclusivity request may be
281 accepted or rejected by the entity providing the SA service.
282 Therefore, the mechanism must provide a way of communicating the
283 result back to the requester UA.
285 REQ-15 The mechanism should support a way for a UA to select a
286 particular appearance number for outgoing requests prior to sending
287 the actual request. This is often called seizure.
289 REQ-16 The mechanism should support a way for a UA to select a
290 particular appearance number and also send the request at the same
291 time. This is needed when a ringdown feature is combined with shared
292 appearances - in this case, seizing the line is the same thing as
293 dialing.
295 5. Normative Description
297 This section normatively describes the SA feature extensions.
299 5.1. Implementation
301 Many of the requirements for this service can be met using standard
302 SIP mechanisms such as:
304 - A SIP Forking Proxy and Registrar/Location Service meets REQ-1.
306 - The SIP Dialog Package meets REQ-2.
308 - The SIP Replaces and Join header fields meets REQ-3.
310 - The SIP Registration Package meets REQ-4.
312 - The use of a State Agent for the Dialog Package meets REQ-5.
314 REQ-6 suggests the need for an entity which manages the appearance
315 resource. Just as conferencing systems commonly have a single point
316 of control, known as a focus, a Shared Appearance group has a single
317 point of control of the appearance shared resource. This is defined
318 as an Appearance Agent for a group. While an Appearance Agent can be
319 part of a centralized server, it could also be co-resident in a
320 member User Agent who has taken on this functionality for a group.
321 The Appearance Agent learns the group state either by subscribing to
322 the dialog state of each member UA individually or by dialog state
323 publications from members.
325 While the appearance resource could be managed co-operatively by a
326 group of UAs without any central control, this is not discussed in
327 this draft, but instead is left as a research project for future
328 standardization. It is also possible that the Appearance Agent logic
329 could be distributed in all UAs in the group. For example, rules
330 that govern assigning appearance numbers for incoming requests (e.g.
331 lowest available appearance number) and rules for contention handling
332 (e.g. when two UAs request the use of the same appearance number,
333 hash dialog identifiers and compare with the lowest hash winning)
334 would need to be defined and implemented.
336 REQs 6-13 can be implemented using a number of approaches, as
337 discussed in the following sections.
339 Figure 1 illustrates the SIP components involved in supporting these
340 common requirements of the Shared Appearance using standard SIP
341 messages including REGISTER, INVITE, SUBSCRIBE, NOTIFY, and PUBLISH.
343 +----------------------------+ +----+
344 | | | |
345 | Appearance Agent | | UA |
346 | | | |
347 +----------------------------+ +----+
348 ^ ^ |1)SUBSCRIBE ^ ^ 4)NOTIFY INVITE |
349 | | |(Event:reg) | | registration sip:alice@example.com|
350 | | V | | events V
351 | | +--------------------+ +----------+7)Query+--------+
352 | | | (example.com) | | |<===== | |
353 | | | |3) Store| Location | | Proxy |
354 | | | Registrar |=======>| Service | | |
355 | | | | | |=====> | |
356 | | +--------------------+ +----------+8)Resp +--------+
357 | | ^ ^ | |
358 | | | | 2) REGISTER (alice) | |
359 | | | | | |
360 | | +----+ +----+ | |
361 | | | | | | | |
362 | | |UA1 | |UA2 | | |
363 | | | | | | | |
364 | | +----+ +----+ | |
365 | | ^ ^ ^ ^ | |
366 | | | | | | | |
367 | +----+ | | | | |
368 | | | +--------------------------------------+ |
369 | +----+-------------------------------------------+
370 | | 8) INVITE
371 +--------------+ sip:alice@example.com
372 5-7) SUBSCRIBE and/or PUBLISH
373 (Event:dialog)
375 Figure 1.
377 The next section discusses normal SIP operations used to implement
378 parts of the shared appearance feature.
380 1. The Appearance Agent SUBSCRIBES to the registration event package
381 as outlined in [RFC3680] for contacts registered to the group
382 AOR. Thus, it has knowledge of all User Agents registered
383 against the AOR at any point of time.
384 2. UAs (UA1 and UA2 in Figure 1) belong to the appearance group and,
385 after authentication, register against the same AOR (e.g.,
386 sip:alice@example.com).
387 3. Each registration is stored in the Location Service.
388 4. The registrar notifies the Appearance Agent of successful
389 registration at each UA.
391 5. UAs PUBLISH their dialog state to the State Agent in the
392 Appearance Agent.
393 6. The UAs SUBSCRIBE to the Appearance Agent for the state of all
394 dialogs as defined in [RFC3265] . The Request-URI of the
395 SUBSCRIBE could be either the AOR of the group, the Contact URI
396 information it received in the incoming subscription from the
397 Appearance Agent, or a provisioned URI.
398 7. The UAs PUBLISH their dialog information to the Appearance Agent
399 every time their dialog state changes (i.e. receive an INVITE,
400 enter alerting state, answer a call, terminate a call, generate
401 an INVITE, etc.)
402 8. Forking Proxy forks an incoming INVITE for the AOR address to the
403 registered user agents.
405 The User Agents in the group could SUBSCRIBE to each other and NOTIFY
406 dialog state events, but in a large group the User Agents have to
407 manage a larger number of SUBSCRIPTIONS and NOTIFICATIONS. The State
408 Agent in the Appearance Agent helps in managing large groups better.
409 Further, the State Agent can filter dialog state events and NOTIFY
410 User Agents of the dialog state events which are required for the
411 application or feature. The State Agent can also SUBSCRIBE to dialog
412 state events with filters to reduce the number of NOTIFY messages
413 exchanged between the State Agent and the user agents in the group.
414 This allows a group of N UAs to each only establish a pair of dialog
415 state subscriptions (one in each direction) to learn the dialog state
416 of all other group members. This results in 2N total subscriptions
417 for the entire group. A full mesh of subscriptions without a state
418 agent would result in N(N-1) total subscriptions.
420 The Appearance Agent can select the appearance number for an incoming
421 call
423 OPEN ISSUE: Do we want to define another mode of operation in which
424 UAs only PUBLISH to seize a line appearance? This assumes the
425 Appearance Agent already knows about all dialogs related to the AOR
426 and could publish that information to the UAs in the SA group. This
427 approach would simply UA operation and cleanly resolve some race
428 conditions. Should we define this mode in a separate draft?
430 5.2. SA Dialog Package Extensions
432 This specification defines three new elements as extensions to the
433 SIP Dialog Event package [RFC3265] . The schema is defined in
434 Section 7. The elements are , ;, and . All three elements are sub-elements of the
1045
1047 F2 Appearance Agent ----> Bob
1048 SIP/2.0 200 OK
1049 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
1050 CSeq: 7 PUBLISH
1051 Call-ID: 144-1289338424@example.com
1052 From: ;tag=44150CC6-A7B7919D
1053 To: ;tag=428765950880801
1054 Allow-Events: dialog
1055 Contact:
1056 Content-Length: 0
1058 F3 Appearance Agent ----> Alice
1060 NOTIFY sip:alice@ua1.example.com SIP/2.0
1061 From: ;tag=497585728578386
1062 To: ;tag=633618CF-B9C2EDA4
1063 Call-ID: a7d559db-d6d7dcad-311c9e3a@ua1.example.com
1064 CSeq: 7 NOTIFY
1065 Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1711759878512309
1066 Max-Forwards: 70
1067 Content-Type: application/dialog-info+xml
1068 Event: dialog
1069 Subscription-State: active
1070 Contact:
1071 Content-Length: ...
1073
1074
1079
1081 false
1082 trying
1083
1084
1085
1086
1087
1088
1090 F4 Alice ----> Appearance Agent
1092 SIP/2.0 200 OK
1093 Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1711759878512309
1094 From: ;tag=497585728578386
1095 To: ;tag=633618CF-B9C2EDA4
1096 CSeq: 7 NOTIFY
1097 Call-ID: a7d559db-d6d7dcad-311c9e3a@ua1.example.com
1098 Contact:
1099 Event: dialog
1100 User-Agent: ABC-UA/1.2.3
1101 Content-Length: 0
1103 F5 and F6: The Appearance Agent sends a NOTIFY to Bob confirming appearance number.
1105 F11 to F17: Bob places a call to Carol by sending the INVITE request
1106 towards the Proxy. The INVITE (see F5 message below) includes a
1107 P-Preferred-Identity header to designate the identity to be
1108 used as the calling party for this call (i.e., Alice instead of Bob).
1110 F11 Bob ----> Proxy
1112 INVITE sip:carol@example.com SIP/2.0
1113 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK98c87c52123A08BF
1114 From: ;tag=15A3DE7C-9283203B
1115 To:
1116 CSeq: 1 INVITE
1117 Call-ID: f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com
1118 Contact:
1119 User-Agent: XYZ-UA/4.5.6
1120 P-Preferred-Identity:
1121 Max-Forwards: 70
1122 Content-Type: application/sdp
1123 Content-Length: 223
1125 v=0
1126 o=- 1102980499 1102980499 IN IP4 ua2.example.com
1127 s=IP SIP UA
1128 c=IN IP4 ua2.example.com
1129 t=0 0
1130 a=sendrecv
1131 m=audio 2236 RTP/AVP 0 8 101
1132 a=rtpmap:0 PCMU/8000
1133 a=rtpmap:8 PCMA/8000
1134 a=rtpmap:101 telephone-event/8000
1136 F18 to F21: Bob notifies the Appearance Agent of the status of the
1137 dialog (i.e., confirmed). Appearance Agent notifies Alice of the
1138 same.
1140 F18 Bob ----> Appearance Agent
1142 NOTIFY sip:sa@stateagent.example.com SIP/2.0
1143 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa39d3f69D4E20602
1144 From: ;tag=44150CC6-A7B7919D
1145 To: ;tag=428765950880801
1146 CSeq: 9 NOTIFY
1147 Call-ID: 144-1289338424@example.com
1148 Contact:
1149 Event: dialog
1150 User-Agent: XYZ-UA/4.5.6
1151 Subscription-State: active;expires=3342
1152 Max-Forwards: 70
1153 Content-Type: application/dialog-info+xml
1154 Content-Length: ...
1156
1157
1162
1169 false
1170
1171
1172
1173
1174
1175
1176 sip:carol@example.com
1177
1178
1179
1180
1182 10.3. Taking an Appearance
1184 In this scenario, Bob has an established dialog with Carol. Bob then
1185 places Carol on hold. Alice subsequently picks up the held call and
1186 has a established session with Carol. Finally, Carol hangs up. The
1187 details of the notifications amongst the user agents and the
1188 Appearance Agent in updating the status of the BLA group members are
1189 shown below. For brevity, details of some of the messages are not
1190 included in the message flows.
1192 Carol Proxy Alice Appearance Agent Bob
1193 | | | | |
1194 | | | | |
1195 |<================= Both way RTP established ===================>|
1196 | | | | |
1197 | | | | |
1198 | |<------------------------------(hold) INVITE F16<|
1199 |<- INVITE F17<| | | |
1200 | | | | |
1201 |>F18 200 OK ->| | | |
1202 | |>F19 200 OK ------------------------------------>|
1203 | | | | |
1204 |<------------------------------------------------------ ACK F20<|
1205 | | | | |
1206 | | | |<----- NOTIFY F21<|
1207 | | | | |
1208 | | | |>F22 200 OK ----->|
1209 | | |<- NOTIFY F23<| |
1210 | | | | |
1211 | | |>F24 200 OK ->| |
1212 | |<-- INVITE F25<| | |
1213 |<- INVITE F26<|(w/ Replaces) | | |
1214 |( w/ Replaces)| | | |
1215 |>F27 200 OK ->| | | |
1216 | |>F28 200 OK -->| | |
1217 | | | | |
1218 |<-------------------- ACK F29<| | |
1219 | | | | |
1220 |<= Both way RTP established =>| | |
1221 | | | | |
1222 |>F30 BYE ---->| | | |
1223 | |>F31 BYE --------------------------------------->|
1224 | | | | |
1225 | |<------------------------------------ OK 200 F32<|
1226 |<- 200 OK F33<| | | |
1227 | | | | |
1228 | | | |<----- NOTIFY F34<|
1229 | | | | |
1230 | | | |>F35 200 OK ----->|
1231 | | |<- NOTIFY F36<| |
1232 | | | | |
1233 | | |>F37 200 OK ->| |
1234 | | | | |
1235 | | |>F38 NOTIFY ->| |
1236 | | | | |
1237 | | |<- 200 OK F39<| |
1238 | | | |>F40 NOTIFY ----->|
1239 | | | | |
1240 | | | |<----- 200 OK F41<|
1241 |>F42 BYE ---->| | | |
1242 | |>F43 BYE ----->| | |
1243 | | | | |
1244 | |<-- 200 OK F44<| | |
1245 |<--200 OK F45<| | | |
1246 | | |>F46 NOTIFY ->| |
1247 | | | | |
1248 | | |<- 200 OK F47<| |
1249 | | | |>F48 NOTIFY ----->|
1250 | | | | |
1251 | | | |<----- OK 200 F49<|
1253 Figure 4.
1255 F16 to F20: Bob places Carol on hold.
1257 F22 to F24: Bob notifies Appearance Agent of the status of the dialog to
1258 indicate the held state. It indicates this by setting the sip.rendering
1259 parameter in the NOTIFY payload to (no). Appearance Agent notifies
1260 Alice of the same.
1262 F22 Bob ----> Appearance Agent
1264 NOTIFY sip:sa@stateagent.example.com SIP/2.0
1265 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK6c78a6c5CA00520E
1266 From: ;tag=44150CC6-A7B7919D
1267 To: ;tag=428765950880801
1268 CSeq: 10 NOTIFY
1269 Call-ID: 144-1289338424@example.com
1270 Contact:
1271 Event: dialog
1272 User-Agent: XYZ-UA/4.5.6
1273 Subscription-State: active;expires=3338
1274 Max-Forwards: 70
1275 Content-Type: application/dialog-info+xml
1276 Content-Length: ...
1278
1279
1284
1302
1304 F26 to F34 : Alice picks up the held call by sending an INVITE with
1305 Replaces: header (F26). Session is established between Alice and
1306 Carol. The dialog between Carol and Bob is terminated.
1308 F26 Alice ----> Proxy
1310 INVITE sip:carol@example.com SIP/2.0
1311 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK4ea695b5B376A60C
1312 From: ;tag=8C4183CB-BCEAB710
1313 To:
1314 CSeq: 1 INVITE
1315 Call-ID: 3d57cd17-47deb849-dca8b6c6@ua1.example.com
1316 Contact:
1317 User-Agent: ABC-UA/1.2.3
1318 P-Preferred-Identity:
1319
1320 Replaces: f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com;to-tag=65a98f7c
1321 -1dd2-11b2-88c6-b03162323164+65a98f7c;from-tag=15A3DE7C-9283203B
1322
1323 Max-Forwards: 70
1324 Content-Type: application/sdp
1325 Content-Length: 223
1327 v=0
1328 o=- 1102980497 1102980497 IN IP4 ua1.example.com
1329 s=IP SIP UA
1330 c=IN IP4 ua1.example.com
1331 t=0 0
1332 a=sendrecv
1333 m=audio 2238 RTP/AVP 0 8 101
1334 a=rtpmap:0 PCMU/8000
1335 a=rtpmap:8 PCMA/8000
1336 a=rtpmap:101 telephone-event/8000
1338 F34 to F41: Bob notifies the Appearance Agent of the termination of
1339 dialog at his UA. Alice notifies the Appearance Agent of the
1340 confirmed state of the dialog at her UA.
1342 F34 Bob ----> Appearance Agent
1344 NOTIFY sip:sa@stateagent.example.com SIP/2.0
1345 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A
1346 From: ;tag=44150CC6-A7B7919D
1347 To: "State_Agent" ;tag=428765950880801
1348 CSeq: 11 NOTIFY
1349 Call-ID: 144-1289338424@example.com
1350 Contact:
1351 Event: dialog
1352 User-Agent: XYZ-UA/4.5.6
1353 Subscription-State: active;expires=3334
1354 Max-Forwards: 70
1355 Content-Type: application/dialog-info+xml
1356 Content-Length: ...
1358
1359
1364
1382
1384 F38 Alice ----> Appearance Agent
1386 NOTIFY sip:sa@stateagent.example.com SIP/2.0
1387 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK93f44af3518A1572
1388 From: ;tag=5861255C-14C04045
1389 To: "State_Agent" ;tag=920163082722420
1390 CSeq: 10 NOTIFY
1391 Call-ID: 143-1840952798@example.com
1392 Contact:
1393 Event: dialog
1394 User-Agent: ABC-UA/1.2.3
1395 Subscription-State: active;expires=3315
1396 Max-Forwards: 70
1397 Content-Type: application/dialog-info+xml
1398 Content-Length: ...
1400
1401
1406
1425
1427 F42 to F59: Carol terminates the dialog with Alice. Alice notifies the
1428 Appearance Agent of the dialog state (terminated). The Appearance Agent
1429 notifies Bob of the same.
1431 F46 Alice ----> Appearance Agent
1433 NOTIFY sip:sa@stateagent.example.com SIP/2.0
1434 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKa46c2f85F29F839C
1435 From: ;tag=5861255C-14C04045
1436 To: "State_Agent" ;tag=920163082722420
1437 CSeq: 11 NOTIFY
1438 Call-ID: 143-1840952798@example.com
1439 Contact:
1440 Event: dialog
1441 User-Agent: ABC-UA/1.2.3
1442 Subscription-State: active;expires=3311
1443 Max-Forwards: 70
1444 Content-Type: application/dialog-info+xml
1445 Content-Length: ...
1447
1448
1453
1471
1473 10.4. Appearance Selection for Incoming Call
1475 In the call flow below Bob and Alice are in an appearance group
1476 identified by Alice's AOR. Carol places a call to Alice. Both Alice
1477 and Bob's devices are alerted of the incoming call. Bob answers the
1478 call. He then places Carol on hold. Alice picks up the held call
1479 and has a established session with Carol. Finally, Carol terminates
1480 the session. All NOTIFY messages in the call flow below carry dialog
1481 events and only dialog states are mentioned for simplicity. For
1482 brevity, the details of some messages are not shown below.
1484 Forking Appearance
1485 Carol Proxy Agent Alice Bob
1486 | | | | |
1487 |>F1 INVITE >| | | |
1488 | |< - - - - - >| | |
1489 | | |>F2 NOTIFY ----------->|
1490 | | | | |
1491 | | |F4 NOTIFY ->| |
1494 | | | | |
1495 | | |<-200 OK F5-<| |
1496 | | | | |
1497 | |>F6 INVITE ------------------------->|
1498 | | | | |
1499 | |>F7 INVITE --------------->| |
1500 | | | | |
1501 |<- 100 F8 -<| | | |
1502 | | | | |
1503 | |<-------------------- Ringing 180 F9<|
1504 |< 180 F10 -<| | | |
1505 | |<--------- 180 Ringing F11<| |
1506 |< 180 F12 -<| | | |
1507 | |<------------------------ 200 OK F13<|
1508 |< 200 F14 -<| | | |
1509 | | | | |
1510 | |>F14 CANCEL -------------->| |
1511 | | | | |
1512 | |<-------------- 200 OK F15<| |
1513 | | | | |
1514 | |F17 ACK ----------------->| |
1517 |>F18 ACK -->| | | |
1518 | |>F19 ACK --------------------------->|
1519 | | | | |
1520 |<=============Both way RTP established===========>|
1521 | | | | |
1522 | | |<---------- NOTIFY F20<|
1523 | | | | |
1524 | | |>F21 200 OK ---------->|
1525 | | | | |
1526 | | |>F22 NOTIFY >| |
1527 | | | | |
1528 | | |<- 200 F22 -<| |
1529 | | | | |
1530 | | |-------- SUBSCRIBE F23>|
1531 | | | |
1532 | | |F26 200 OK ---------->|
1537 | | | |
1539 Figure 5.
1541 F1 to F16: An incoming call from Carol to Alice is forked to
1542 Bob and Alice. Both Alice and Bob indicate an incoming call
1543 (e.g., ringing) from Carol. Bob answers the call and two-way
1544 media is established between Carol and Bob.
1546 F2 Proxy ----> Bob
1548 INVITE sip:alice@ua3.example.com SIP/2.0
1549 Via: SIP/2.0/UDP ua3.example.com;branch=z9hG4bK4324ea695b5B376A
1550 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK38432ji
1551 From: ;tag=94183CB-BCEAB7
1552 To:
1553 CSeq: 106 INVITE
1554 Call-ID: 47deb849-dca8b6c6-3d342
1555 Contact:
1556 Max-Forwards: 69
1557 Alert-Info: ;alert=normal;appearance=0
1558 Content-Type: application/sdp
1559 Content-Length: 223
1561 v=0
1562 o=- 1102980499 1102980499 IN IP4 ua3.example.com
1563 s=
1564 c=IN IP4 ua3.example.com
1565 t=0 0
1566 a=sendrecv
1567 m=audio 2238 RTP/AVP 0 8 101
1568 a=rtpmap:0 PCMU/8000
1569 a=rtpmap:8 PCMA/8000
1570 a=rtpmap:101 telephone-event/8000
1572 F3 Proxy ----> Alice
1574 INVITE sip:alice@ua1.example.com SIP/2.0
1575 Via: SIP/2.0/UDP ua3.example.com;branch=z9hG4bK4324ea695b5B376A
1576 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK348281
1577 From: ;tag=94183CB-BCEAB7
1578 To:
1579 CSeq: 106 INVITE
1580 Call-ID: 47deb849-dca8b6c6-3d342
1581 Contact:
1582 Max-Forwards: 69
1583 Alert-Info: ;alert=normal;appearance=0
1584 Content-Type: application/sdp
1585 Content-Length: 223
1587 v=0
1588 o=- 1102980499 1102980499 IN IP4 ua3.example.com
1589 s=
1590 c=IN IP4 ua3.example.com
1591 t=0 0
1592 a=sendrecv
1593 m=audio 2238 RTP/AVP 0 8 101
1594 a=rtpmap:0 PCMU/8000
1595 a=rtpmap:8 PCMA/8000
1596 a=rtpmap:101 telephone-event/8000
1598 F17 - F20: Bob notifies the Appearance Agent with dialog state
1599 payload indicating the dialog in confirmed state. Appearance
1600 Agent notifies Alice of the status of the dialog at Bob.
1602 F17 Bob ----> Appearance Agent
1604 NOTIFY sip:sa@stateagent.example.com SIP/2.0
1605 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK58a0dd68C2D63263
1606 From: ;tag=558C18F7-DB9DF7BC
1607 To: ;tag=1894685100249086
1608 CSeq: 14 NOTIFY
1609 Call-ID: 77-505889516@example.com
1610 Contact:
1611 Event: dialog
1612 User-Agent: XYZ-UA/4.5.6
1613 Subscription-State: active;expires=3427
1614 Max-Forwards: 70
1615 Content-Type: application/dialog-info+xml
1616 Content-Length: ...
1618
1619
1624
1642
1644 F19 Appearance Agent ----> Alice
1646 NOTIFY sip:alice@ua1.example.com SIP/2.0
1647 From: ;tag=151702541050937
1648 To: ;tag=18433323-C3D237CE
1649 Call-ID: 1e361d2f-a9f51109-bafe31d4@ua1.example.com
1650 CSeq: 12 NOTIFY
1651 Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK14031499568413
1652 Max-Forwards: 70
1653 Content-Type: application/dialog-info+xml
1654 Event: dialog
1655 Subscription-State: active
1656 Contact:
1657 Content-Length: ...
1659
1660
1665
1682
1684 10.5. Appearance Publication
1686 This call flow shows the use of PUBLISH between the members of the
1687 appearance group and the Appearance Agent.
1689 Carol Proxy Alice Appearance Agent Bob
1690 | | | | |
1691 | | | |<----- PUBLISH F1<|
1692 | | | | |
1693 | | | |>F2 200 OK ------>|
1694 | | | | |
1695 | | |<-- NOTIFY F3<| |
1696 | | | | |
1697 | | |>F4 200 OK -->| |
1698 | | | | |
1699 | |<------------------------------------- INVITE F5<|
1700 | | | | |
1701 |<-- INVITE F6<| | | |
1702 | | | | |
1703 |>F7 180 Ring >| | | |
1704 | |>F8 180 Ringing -------------------------------->|
1705 |>F9 200 OK -->| | | |
1706 | |>F10 200 OK ------------------------------------>|
1707 | | | | |
1708 |<------------------------------------------------------ ACK F11<|
1709 | | | | |
1710 |<================= Both way RTP established ===================>|
1711 | | | | |
1712 | | | |<---- PUBLISH F12<|
1713 | | | | |
1714 | | | |>F13 200 OK ----->|
1715 | | |<- NOTIFY F14<| |
1716 | | | | |
1717 | | |>F15 200 OK ->| |
1718 | | | | |
1719 | |<------------------------------(hold) INVITE F16<|
1720 |<- INVITE F17<| | | |
1721 | | | | |
1722 |>F18 200 OK ->| | | |
1723 | |>F19 200 OK ------------------------------------>|
1724 | | | | |
1725 |<------------------------------------------------------ ACK F20<|
1726 | | | | |
1727 | | | |<---- PUBLISH F21<|
1728 | | | | |
1729 | | | |>F22 200 OK ----->|
1730 | | |<- NOTIFY F23<| |
1731 | | | | |
1732 | | |>F24 200 OK ->| |
1733 | |<-- INVITE F25<| | |
1734 |<- INVITE F26<|(w/ Replaces) | | |
1735 |( w/ Replaces)| | | |
1736 |>F27 200 OK ->| | | |
1737 | |>F28 200 OK -->| | |
1738 | | | | |
1739 |<-------------------- ACK F29<| | |
1740 | | | | |
1741 |<= Both way RTP established =>| | |
1742 | | | | |
1743 |>F30 BYE ---->| | | |
1744 | |>F31 BYE --------------------------------------->|
1745 | | | | |
1746 | |<------------------------------------ OK 200 F32<|
1747 |<- 200 OK F33<| | | |
1748 | | | | |
1749 | | | |<---- PUBLISH F34<|
1750 | | | | |
1751 | | | |>F35 200 OK ----->|
1752 | | |<- NOTIFY F36<| |
1753 | | | | |
1754 | | |>F37 200 OK ->| |
1755 | | | | |
1756 | | |>F38 PUBLISH >| |
1757 | | | | |
1758 | | |<- 200 OK F39<| |
1759 | | | |>F40 NOTIFY ----->|
1760 | | | | |
1761 | | | |<----- 200 OK F41<|
1762 |>F42 BYE ---->| | | |
1763 | |>F43 BYE ----->| | |
1764 | | | | |
1765 | |<-- 200 OK F44<| | |
1766 |<--200 OK F45<| | | |
1767 | | |>F46 PUBLISH >| |
1768 | | | | |
1769 | | |<- 200 OK F47<| |
1770 | | | |>F48 NOTIFY ----->|
1771 | | | | |
1772 | | | |<----- OK 200 F49<|
1774 Figure 6.
1776 10.6. Joining an Appearance
1778 In this call flow, a call answered by Bob is joined by Alice or
1779 "bridged". The Join header field is used by Alice to request this
1780 bridging. If Bob did not support media mixing, Bob could obtain
1781 conferencing resources as described in [RFC4579].
1783 Carol Forking Proxy Appearance Agent Alice Bob
1784 | | | | |
1785 |>F1 INVITE >| | | |
1786 | |>F2 INVITE ------------------------->|
1787 | | | | |
1788 | |>F3 INVITE --------------->| |
1789 | | | | |
1790 |<-100Try F4<| | | |
1791 | | | | |
1792 | |<-------------------- Ringing 180 F5<|
1793 |<180Ring F6<| | | |
1794 | |<---------- Ringing 180 F7<| |
1795 |<180Ring F8<| | | |
1796 | |<------------------------- 200 OK F9<|
1797 |<-200OK F10<| | | |
1798 | | | | |
1799 | |>F11 CANCEL -------------->| |
1800 | | | | |
1801 | |<-------------- 200 OK F12<| |
1802 | | | | |
1803 | |F14 ACK ----------------->| |
1806 |>F15 ACK -->| | | |
1807 | |>F16 ACK --------------------------->|
1808 | | | | |
1809 |<=============Both way RTP established===========>|
1810 | | | | |
1811 | | |<---------- NOTIFY F17<|
1812 | | | | |
1813 | | |>F18 200 OK ---------->|
1814 | | | | |
1815 | | |>F19 NOTIFY >| |
1816 | | | | |
1817 | | |<- 200OK F20<| |
1818 | | | | |
1819 | |<---- INVITE (w/ Join) F21<| |
1820 | | | | |
1821 | |>F22 INVITE (w/Join)---------------->|
1822 | | | | |
1823 | |<---- OK 200 Contact:Bob;isfocus F23<|
1824 | | | | |
1825 | |>F24 200 OK Contact:Bob;isfocus----->|
1826 | | | | |
1827 | |<----------------- ACK F25<| |
1828 | | | | |
1829 | |>ACK F26---------------------------->|
1830 | | | | |
1831 | |<-----INVITE Contact:Bob;isfocus F27<|
1832 |<-INVITE F28| | | |
1833 |>F29 200 -->| | | |
1834 | |>F30 200 OK ------------------------>|
1835 | | | | |
1836 | |<--------------------------- ACK F31<|
1837 |<--- ACK F32| | | |
1838 | | | |<==RTP==>|
1839 |<=============Both way RTP established===========>|
1841 Figure 7.
1843 F21 Alice ----> Proxy
1845 INVITE sip:bob@ua.example.com SIP/2.0
1846 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKcc9d727c2C29BE31
1847 From: ;tag=605AD957-1F6305C2
1848 To:
1849 CSeq: 2 INVITE
1850 Call-ID: dc95da63-60db1abd-d5a74b48@ua1.example.com
1851 Contact:
1852 User-Agent: ABC-UA/1.2.3
1853 P-Preferred-Identity:
1854
1855 Join: 14-1541707345@example.com;to-tag=d3b06488-1dd1-11b2-88c5
1856 -b03162323164+d3e48f4c;from-tag=44BAD75D-E3128D42
1857
1858 Max-Forwards: 70
1859 Content-Type: application/sdp
1860 Content-Length: 223
1862 v=0
1863 o=- 1103061265 1103061265 IN IP4 ua1.example.com
1864 s=IP SIP UA
1865 c=IN IP4 ua1.example.com
1866 t=0 0
1867 a=sendrecv
1868 m=audio 2236 RTP/AVP 0 8 101
1869 a=rtpmap:0 PCMU/8000
1870 a=rtpmap:8 PCMA/8000
1871 a=rtpmap:101 telephone-event/8000
1873 10.7. Appearance Allocation - Loss of Subscription with UA
1875 UA Appearance Agent UA1 UA2
1876 | | | |
1877 | | F1: NOTIFY (trying) |
1878 | |<---------------| |
1879 | | F2: 200 OK | |
1880 | |--------------->| |
1881 | | F3: NOTIFY (trying) |
1882 | |----------------+--------------->|
1883 | | F4: 200 OK | |
1884 | |<---------------+----------------|
1885 | F5: INVITE | | |
1886 |<--------------------------------| |
1887 | F6: 180 Ringing| | |
1888 |-------------------------------->| |
1889 | | | |
1890 | | End |
1891 | | |
1892 | | |
1893 | | F7: SUBSCRIBE x 6 retries |
1894 | |---------------> |
1895 | | |
1896 | | F8: NOTIFY (terminated) |
1897 | |-------------------------------->|
1898 | | F9: 200 OK |
1899 | |<--------------------------------|
1900 | | |
1902 Figure 8.
1904 The flow shown in this figure illustrates the failure of a user agent
1905 after it has obtained an appearance number (F1-F2). Messages used to
1906 refresh the subscription from Appearance Agent to UA1 are shown at
1907 F7. When the Appearance Agent attempts to refresh its subscription
1908 but receives no response. In this case, the Appearance Agent may
1909 apply policy and free up the appearance number as it wishes. In this
1910 case, after a delay, the Appearance Agent frees up the appearance
1911 number and sends NOTIFY messages (F8) indicating the termination of
1912 the dialog associated with the shared line.
1914 10.8. Appearance Selection Contention Race Condition
1916 UA Appearance Agent UA1 UA2
1917 | | | |
1918 | | F1 NOTIFY (trying appearance=1) |
1919 | |<---------------| |
1920 | | F2 NOTIFY (trying appearance=1) |
1921 | |<---------------+----------------|
1922 | | F3 200 OK | |
1923 | |--------------->| |
1924 | | F4 200 OK | |
1925 | |----------------+--------------->|
1926 | | F5 NOTIFY (trying appearance=1)|
1927 | |--------------->| |
1928 | | F6 200 OK | |
1929 | |<---------------| |
1930 | | F7 NOTIFY (trying) |
1931 | |----------------+--------------->|
1932 | | F8 200 OK | |
1933 | |<---------------+----------------|
1934 | F9 INVITE | | |
1935 |<--------------------------------| |
1936 | | F10 NOTIFY (trying appearance=2)|
1937 | |<---------------+----------------|
1938 | | F11 200 OK | |
1939 | |----------------+--------------->|
1940 | | F12 NOTIFY (trying appearance=2)|
1941 | |----------------+--------------->|
1942 | | F13 200 OK | |
1943 | |<---------------+----------------|
1944 | F14 INVITE | | |
1945 |<-------------------------------------------------|
1946 | | | |
1948 Figure 9.
1950 This figure illustrates two user agents, UA1 and UA2, attempting to
1951 select the same appearance number (i.e. seize the same line number)
1952 simultaneously. This type of race condition is often referred to in
1953 telephony as a glare condition. Appearance Agent may use any desired
1954 policy to decide which UA receives the appearance and which does not.
1955 In this case UA1 obtains the appearance number, as indicated by the
1956 NOTIFY from the Appearance Agent with the appearance number. UA2
1957 learns that it did not obtain the appearance number since its NOTIFY
1958 does not contain the appearance number from its NOTIFY.
1960 11. IANA Considerations
1962 This section registers the SIP Alert-Info header field parameter
1963 "appearance" and the XML namespace extensions to the SIP Dialog
1964 Package.
1966 11.1. SIP Event Package Parameter: sa
1968 This specification also defines a new event parameter "sa" for the
1969 Dialog Package.
1971 11.2. URN Sub-Namespace Registration: sa-dialog-info
1973 This section registers a new XML namespace per the procedures in
1974 [RFC3688].
1976 URI: urn:ietf:params:xml:ns:sa-dialog-info.
1978 Registrant Contact: IETF BLISS working group, ,
1979 Alan Johnston
1981 XML:
1983 BEGIN
1984
1985
1987
1988
1989
1991 Shared Appearance Dialog Information Namespace
1992
1993
1994
Namespace for Shared Appearance Dialog Information
1998
1999
2000 END
2002 11.3. XML Schema Registration
2004 This section registers an XML schema per the procedures in [RFC3688].
2006 URI: urn:ietf:params:xml:schesa:sa-dialog-info.
2008 Registrant Contact: IETF BLISS working group, ,
2009 Alan Johnston
2011 The XML for this schema can be found in Section 7.
2013 12. Appendix A - Incoming Appearance Assignment
2015 To best meet REQ-9, the appearance number for an incoming INVITE
2016 should be contained in the INVITE itself.
2018 For the dialog package parameter approach, REQ-9 could be met in two
2019 ways. When an incoming request is received, the Appearance Agent
2020 could send out a NOTIFY with state trying and include the appearance
2021 number to be used for this request. Upon receipt of this NOTIFY, the
2022 UAs could begin alerting using the appearance number selected. This
2023 approach is sub-optimal since the UAs could receive the INVITE but be
2024 unable to begin alerting if the NOTIFY from the Appearance Agent is
2025 delayed or lost
2027 An alternative approach is to define an extension parameter for the
2028 Alert-Info header field in RFC 3261 such as:
2030 Alert-Info: ;alert=normal;appearance=0
2032 This Alert-Info header would indicate to place the call on the first
2033 line appearance instance.
2035 The determination as to what value to use in the appearance parameter
2036 can be done at the proxy that forks the incoming request to all the
2037 registered UAs. There are a variety of ways the proxy can use to
2038 determine what value it should use to populate this parameter. For
2039 example, the proxy could fetch this information by initiating a
2040 SUBSCRIBE request with Expires: 0 to the Appearance Agent for the AOR
2041 to fetch the list of lines that are in use. Alternatively, it could
2042 act like a UA that is a part of the appearance group and SUBSCRIBE to
2043 the State-Agent like any other UA. This would ensure that the active
2044 dialog information is available without having to poll on a need
2045 basis. It could keep track of the list of active calls for the
2046 appearance AOR based on how many unique INVITE requests it has forked
2047 to or received from the appearance AOR. Another approach would be
2048 for the Proxy to first send the incoming INVITE to the Appearance
2049 Agent which would redirect to the appearance group URI and escape the
2050 proper Alert-Info header field for the Proxy to recurse and
2051 distribute to the other UAs in the group.
2053 The Appearance Agent needs to know about all incoming requests to the
2054 AOR in order to select the appearance number. One way in which this
2055 could be done is for the Appearance Agent to register against the AOR
2056 with a higher q value. This will result in the INVITE being sent to
2057 the Appearance Agent first, then being offered to the UAs in the
2058 group.
2060 The changes to RFC 3261 ABNF would be:
2062 alert-param = LAQUOT absoluteURI RAQUOT *( SEMI (generic-param /
2063 appearance-param) )
2065 appearance-param = "appearance" EQUAL *DIGIT
2067 13. Appendix B - Implementation Options Discussion
2069 This section discusses some options on how to implement the Shared
2070 Appearances feature in SIP. This section is non-normative.
2072 13.1. Appearance Implementation Options
2074 This section discusses and compares two methods of implementing,
2075 conveying, and selecting appearances in SIP while meeting the
2076 requirements of Section 4. One approach involves a URI parameter and
2077 is discussed in section 5.1.1. The other approach uses a SIP dialog
2078 package extension parameter and is discussed in section 5.1.2. Both
2079 approaches assume the common elements and operations of Figure 1. In
2080 addition, this section discusses approaches for incoming appearance
2081 indication, REQ-9, and appearance contention, REQ-8. These
2082 approaches will be discussed for an example appearance group of N
2083 phones each with n line appearances. The usage of the word phone
2084 does not imply that this feature is limited to telephony devices.
2086 13.1.1. URI parameter Approach
2088 Some implementations of this feature utilize a URI parameter such as
2089 "line=3" on the Contact URI. Each appearance is effectively a
2090 logical UA, so each line appearance requires a separate registration.
2091 The number of line appearances needs to be provisioned on each phone.
2092 Each appearance also requires a separate dialog package subscription.
2093 Even using a State Agent for the dialog package, each phone must
2094 maintain n subscriptions to the dialog package.
2096 This results in 2nN total subscriptions and nN registrations for this
2097 implementation.
2099 Since Contact URI parameters will be conveyed by the dialog package,
2100 REQ-7 is met.
2102 REQ-10 can be met by having the Appearance Agent send a SUBSCRIBE to
2103 each UA and line number to obtain the current dialog state - this
2104 will result in nN SUBSCRIBEs and NOTIFYs.
2106 It is not obvious how to meet REQ-11 with this approach. A UA
2107 registering against the AOR but does not implement the appearance URI
2108 parameter will not include a line appearance number in Contact URIs
2109 and dialog package NOTIFYs. The Appearance Agent will have no way of
2110 indicating to the other UAs the appearance number being used by this
2111 UA, as adding a parameter to the Contact URI would cause call control
2112 operations such as Replaces and Join to fail.
2114 REQs 12 and 13 are difficult to meet with this approach as the line
2115 appearance number will be present in the Request-URI of incoming
2116 requests and the Contact URI in INVITE and 200 OK messages. This
2117 approach will require integrity protection of all dialog creating
2118 requests and responses, and privacy mechanisms to hide the Contact
2119 URI from other UAs.
2121 Also, this approach will require mechanisms to protect against
2122 another UA sending an INVITE directly to a group member with the line
2123 appearance number already set.
2125 13.1.2. Dialog Package Parameter
2127 Instead of the URI parameter approach, consider an extension
2128 parameter "appearance" to the SIP dialog package. The e.g.:
2130
2131
2136
2147
2148 ...
2150 In this approach, the appearance number is never carried in a
2151 Request-URI or Contact URI. Instead, it is only present in dialog
2152 package NOTIFY and PUBLISH messages. As a result, only a single
2153 registration per AOR is required. Also, only a single dialog package
2154 subscription in each direction per AOR.
2156 This results in 2N total subscriptions and N registrations for this
2157 approach.
2159 If the dialog package is extended to carry the appearance number,
2160 then REQ-7 is met.
2162 REQ-10 can be met by having the Appearance Agent send a SUBSCRIBE to
2163 each UA and line number to obtain the current dialog state - this
2164 will result in N SUBSCRIBEs and NOTIFYs.
2166 REQ-11 can be met by this approach. Even though a UA does not
2167 provide an appearance number in dialog package NOTIFYs, the
2168 Appearance Agent can assign one and include it in NOTIFYs to the
2169 other UAs. This parameter would simply be ignored by the UAs that
2170 did not understand the parameter, and have no impact on call control
2171 operations.
2173 REQs 12 and 13 are met because the appearance number is only conveyed
2174 in dialog package NOTIFYs. Integrity and privacy of NOTIFY bodies
2175 can be achieved using normal SIP mechanisms independent of the
2176 security mechanisms used for other requests.
2178 The dialog-package [RFC3265] describes a mechanism whereby shared-
2179 line privacy REQ-14 can be accomplished by suppressing certain dialog
2180 information from being presented to the UAs. The reasoning behind
2181 that is if the UAs were unaware of a dialog's call-id, local-tag and
2182 remote-tag then they will be unable to create requests such as INVITE
2183 with Replaces [RFC3891] and Join [RFC3911] header fields to barge-in
2184 or pickup the line appearance. Below is a quote from section 3.6 of
2185 dialog-package[RFC3265] that describes this approach:
2187 Note that many implementations of "shared-lines" have a feature that
2188 allows details of calls on a shared address-of-record to be made
2189 private. This is a completely reasonable authorization policy that
2190 could result in notifications that contain only the id attribute of
2191 the dialog element and the state element when shared-line privacy is
2192 requested, and notifications with more complete information when
2193 shared-line privacy is not requested.
2195 There are certain fundamental drawbacks in the privacy-by-obscurity
2196 approach described in [RFC3265] . It models exclusivity as a static
2197 property of the appearance AOR. There are situations where
2198 exclusivity needs to be a dynamic property (e.g. boss does not want
2199 secretary to listen-in on a particular part of the conversation). In
2200 addition, [RFC3265] does not address how a UA can request exclusivity
2201 at the start of a session or mid-session and how that request will be
2202 granted or rejected.
2204 Exclusivity being a dynamic property means that a UA can request it
2205 to be turned on or off in the middle of a session. When exclusivity
2206 is turned off all the UAs that share the line AOR will need to see
2207 the complete dialog information. Once they have that information it
2208 can not be taken back from them. This will not allow exclusivity to
2209 be turned on later on in the dialog lifetime. Therefore, there needs
2210 to be a centralized entity that will actually enforce exclusivity.
2212 The approach proposed for meeting REQ-14 is to include an exclusivity
2213 parameter to the dialog package. This allows a UA to request
2214 exclusivity, by setting the exclusive parameter in notifications.
2215 This could be done prior to a call being made or answered, or during
2216 a call at any time. A UA can remove exclusivity by sending a
2217 notification at any time during a call and setting "exclusive=no".
2218 It also allows a UA to learn that a particular dialog is exclusive by
2219 the presence of this parameter in a NOTIFY. In addition, a UA can
2220 still apply policy to any INVITE Join or Replaces requests it
2221 receives, as per normal SIP call control mechanisms.
2223 With this approach, the number of appearances is centrally managed
2224 and controlled by the Appearance Agent. For UAs with soft keys or
2225 buttons, this gives a great deal of flexibility in system management.
2227 13.1.3. Appearance Selections Mechanisms
2229 Regardless of how the appearance number is conveyed by UAs, there is
2230 still the issue of how appearance numbers are selected. For example,
2231 some UAs might have actual buttons and lamps, and pressing a
2232 particular button requires the UA to reserve a particular appearance
2233 number. For devices with this type of user interface, the selection
2234 must be done before the user continues with the call and dials digits
2235 or a URI. Other UAs with different user interfaces can be flexible
2236 at the time of dialing, updating the display with the appearance
2237 number at a later date. For devices which require advance appearance
2238 selection, there are three options discussed in the following
2239 sections for meeting REQ-15.
2241 13.1.3.1. Floor Control Appearance Selection Mechanism
2243 This approach models each appearance number as a floor (shared
2244 resource) and uses a floor control server to arbitrate exclusive
2245 access (seizure of a particular appearance number). This approach
2246 uses a standard SIP Event State Compositor (ESC), a standard Floor
2247 Control Server that uses the Appearance Agent as Moderator. The
2248 Binary Floor Control Protocol (BFCP) is used between the UAs and the
2249 Floor Control Server. A Registrar/Forking Proxy Server talks to
2250 Appearance Agent about incoming calls. The Appearance Agent acts as
2251 a Moderator for the floor control server and tells forking proxy to
2252 insert the appearance number in incoming and outgoing requests.
2254 Appearance numbers are allocated/selected/reserved in two ways:
2256 For incoming calls, the Forking Proxy interacts with the Appearance
2257 Agent. The Appearance Agent selects an appearance by taking a
2258 particular floor and marking it "moderator controlled". This
2259 appearance number is then included by the Forking Proxy in INVITEs
2260 using the Alert-Info parameter. When a UA answers the call, it takes
2261 the appearance number from the Alert-Info and includes it in the
2262 dialog state publication. It then requests the floor associated with
2263 the appearance number from the floor control server, which forwards
2264 the request to the Appearance Agent (moderator). The Appearance
2265 Agent correlates the floor control request with the dialog state
2266 notification with the dialog ID from the INVITE with the Alert-Info.
2267 If they match, the floor is granted. If they do not match, it means
2268 the floor request is not an answer of the call but is a random
2269 appearance selection by the UA and will be rejected.
2271 For outgoing calls, the UA sends an INVITE and requests a particular
2272 floor from the floor control server. Depending on the User Interface
2273 requirements, the floor request can be done before or after sending
2274 the INVITE. The floor grant policy for most appearances is set to
2275 "first come first serve". Once the floor has been granted and the
2276 call answered, the dialog state publication by the UA will include
2277 the appearance number.
2279 When a call has ended, the UA releases the floor to the floor control
2280 server and this appearance is now available for incoming and outgoing
2281 calls.
2283 When a UA in the group which does not support BFCP is in a call, the
2284 Appearance Agent will grant the floor associated with that appearance
2285 to that UA. When that call is over, the Appearance Agent will
2286 release the floor. Since the UA will not publish the appearance
2287 number to the ESC, the Appearance Agent will need to do that on their
2288 behalf. If the UA does publish dialog state but without the
2289 appearance number, the Appearance Agent will still need to re-publish
2290 the dialog state including the appearance number. UAs in the group
2291 will be able to recognize these two dialogs as one since they will
2292 have the same SIP dialog ID.
2294 13.1.3.2. INVITE Appearance Selection Mechanism
2296 This is an alternative approach that utilizes sending an INVITE to
2297 select/reserve/seize an appearance number.
2299 A UA that does not need to select a particular appearance number (or
2300 doesn't care) would just send an INVITE as normal. The Appearance
2301 Agent would tell the proxy which appearance number was being used by
2302 inserting this information in a header field in the first non-100
2303 provisional response sent back to the calling UA. The UA would then
2304 PUBLISH this appearance number to the Dialog Event State Compositor
2305 for the AOR which would distribute details of the dialog and the
2306 appearance number to the other UAs in the group.
2308 If an INVITE is sent and no appearance number is available, the proxy
2309 would reject the INVITE with a suitable response code and perhaps a
2310 header field indication.
2312 A UA that does need to select a particular appearance number would
2313 use an approach similar to overlap dialing (multi-stage dialing). An
2314 INVITE would be sent when the appearance number is requested (i.e.
2315 when the button is pressed, before dialing begins). The appearance
2316 number selected would be carried in the INVITE, in a header field or
2317 in the Request-URI, for example. The proxy would reject the INVITE
2318 with a 484 Address Incomplete response (see RFC 3578) if the
2319 appearance number is Available and start a timer. The UA could then
2320 resend the INVITE after the URI has been dialed and then PUBLISH this
2321 appearance number to the ESC. If the appearance number is not
2322 available, another response code such as 403 would be sent. The user
2323 could then select a different appearance number and resend the
2324 INVITE. If no INVITE with a matching Call-ID is received before the
2325 timer expires, the appearance seizure is cancelled and is made
2326 available for other calls.
2328 Note that this approach does not actually require a B2BUA, but it
2329 does require a proxy that can act as a UAS and communicate with an
2330 Appearance Agent which keeps track of appearance number allocations.
2332 13.1.3.3. PUBLISH Appearance Selection Mechanism
2334 The approach used in previous versions of this draft is to use the
2335 PUBLISH to the event state compositor to select an appearance number.
2336 This approach requires a special event state compositor and special
2337 behavior on the part of the UA.
2339 In the selection of an appearance for requests initiated by UAs in
2340 the group, there is the possibility of contention where more than one
2341 UA select the same appearance number.
2343 One way to solve this and meet REQ-8 is to require UAs to send a
2344 notification (trying) to the Appearance Agent indicating the
2345 appearance number to be used for the session. The Appearance Agent
2346 would confirm the allocation of the appearance number in a NOTIFY
2347 sent to the group UAs. Should the appearance number be unavailable
2348 or otherwise not allowed, there are two options:
2350 - The notification could be rejected with a 500 response and a Retry-
2351 After header field. The Appearance Agent would send an immediate
2352 NOTIFY indicating that the appearance is unavailable. If the NOTIFY
2353 is received before the expiration of the Retry-After time, the
2354 notification state information would become out of date and would be
2355 discarded without resending. The UA would select another appearance
2356 number and send another notification.
2358 - The notification could be accepted but an immediate NOTIFY
2359 generated by the Appearance Agent indicating that the appearance is
2360 unavailable. The UA would then select another appearance number and
2361 PUBLISH again.
2363 UAs would wait for a notification from the Appearance Agent before
2364 sending the INVITE.
2366 13.2. Comparison
2368 In comparing the URI parameter and the dialog package parameter,
2369 there are clear differences in the number of registrations and
2370 subscriptions, with the dialog package approach requiring n times
2371 fewer in both cases.
2373 The security model for the dialog package parameter approach is much
2374 cleaner, since only NOTIFY and PUBLISH requests need integrity and
2375 privacy. The security model for the URI parameter approach would
2376 likely require a B2BUA which introduces many undesirable properties.
2378 The dialog package parameter approach has better backwards
2379 compatibility than the URI parameter approach.
2381 In summary, the dialog package parameter approach better meets REQs
2382 5, 10, 11, 12, and 13 while the URI parameter approach better meets
2383 REQ-9. However, the combined dialog package parameter approach and
2384 the Alert-Info parameter approach meets REQ-9.
2386 13.2.1. Comparison of Appearance Selection Methods
2388 All three approaches meet REQ-15 and REQ-16.
2390 Previous versions of this draft proposed the publish/notify method of
2391 appearance selection. The advantage of this approach is that the
2392 appearance number is only carried in one place (dialog package XML
2393 documents) and the same protocol/mechanism is used to select and
2394 learn appearance numbers. The disadvantage of this approach is that
2395 a specialized event state compositor must be used, since it is aware
2396 of appearance numbers. Also, concerns have been raised about whether
2397 this approach defines new semantics for publish/notify beyond that in
2398 RFC 3265.
2400 The floor control approach makes good reuse of existing protocols
2401 such as Binary Floor Control Protocol (BFCP) and cleanly models the
2402 state. However, while BFCP can be used in conferencing applications,
2403 it is unlikely most UAs implementing shared appearances would utilize
2404 the protocol. Also, having appearance state in two places (dialog
2405 package XML documents and floor control messages) complicates the
2406 application. Also, BFCP only runs over TCP and requires a separate
2407 offer/answer exchange to establish the connection, making operation
2408 through NATs and firewalls more difficult. The BFCP approach is also
2409 radically different from all current implementations of this feature.
2410 As a result, standardizing this approach would likely result in an
2411 increase in feature interoperability rather than a decrease.
2413 The INVITE selection mechanism is based on overlap dialing. Overlap
2414 dialing is supported in very few SIP UAs and is regarded as a
2415 somewhat archaic leftover from the PSTN. As such, it is not regarded
2416 as a good starting point for a common feature such as shared
2417 appearances.
2419 The PUBLISH selection mechanism reuses the SIP events extensions
2420 which already must be implemented by UAs supporting this feature. In
2421 fact, it results in no additional messages or round trips. It is
2422 also very similar to many current feature implementations today.
2423 Standardizing this approach is likely to increase overall
2424 interoperability of this feature.
2426 The rest of this document will only discuss the PUBLISH appearance
2427 selection mechanism.
2429 14. Acknowledgements
2431 The following individuals were part of the SA Design team and have
2432 provided input and text to the document (in alphabetical order):
2434 Martin Dolly, Andrew Hutton, Raj Jain, Fernando Lombardo, Derek
2435 MacDonald, Bill Mitchell, Michael Procter, Theo Zowzouvillys.
2437 Thanks to Chris Boulton for helping with the XML schema.
2439 Much of the material has been drawn from previous work by Mohsen
2440 Soroushnejad, Venkatesh Venkataramanan, Paul Pepper and Anil Kumar,
2441 who in turn received assistance from:
2443 Kent Fritz, John Weald, and Sunil Veluvali of Sylantro Systems, Steve
2444 Towlson, and Michael Procter of Citel Technologies, Rob Harder and
2445 Hong Chen of Polycom Inc, John Elwell, J D Smith of Siemens
2446 Communications, Dale R. Worley of Pingtel, Graeme Dollar of Yahoo
2447 Inc.
2449 Also thanks to Geoff Devine, Paul Kyzivat, Jerry Yin, John Elwell,
2450 Dan York, Spenser Dawkins, and Martin Dolly for their comments.
2452 15. Security Considerations
2454 Since multiple line appearance features are implemented using
2455 semantics provided by [RFC3261], Event Package for Dialog State as
2456 define in , and Event Notification [RFC3265], [RFC3903], security
2457 considerations in these documents apply to this draft as well.
2459 Specifically, since dialog state information and the dialog
2460 identifiers are supplied by UA's in an appearance group to other
2461 members, the same is prone to "call hijacks". For example, a rogue
2462 UA could snoop for these identifiers and send an INVITE with Replaces
2463 header containing these call details to take over the call. As such
2464 INVITES with Replaces header MUST be authenticated using the standard
2465 mechanism (like Digest or S/MIME) described in [RFC3261]. before it
2466 is accepted. NOTIFY message bodies that provide the dialog state
2467 information and the dialog identifiers MAY be encrypted end-to-end
2468 using the standard mechanics. All SUBSCRIBES between the UA's and
2469 the Appearance Agent MUST be authenticated.
2471 16. Informative References
2473 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2474 Requirement Levels", BCP 14, RFC 2119, March 1997.
2476 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
2477 A., Peterson, J., Sparks, R., Handley, M., and E.
2478 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
2479 June 2002.
2481 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
2482 Method", RFC 3515, April 2003.
2484 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
2485 Event Notification", RFC 3265, June 2002.
2487 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
2488 for Event State Publication", RFC 3903, October 2004.
2490 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
2491 Protocol (SIP) "Replaces" Header", RFC 3891,
2492 September 2004.
2494 [I-D.ietf-sipping-service-examples]
2495 Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and
2496 K. Summers, "Session Initiation Protocol Service
2497 Examples", draft-ietf-sipping-service-examples-15 (work in
2498 progress), July 2008.
2500 [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
2501 Initiated Dialog Event Package for the Session Initiation
2502 Protocol (SIP)", RFC 4235, November 2005.
2504 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
2505 Package for Registrations", RFC 3680, March 2004.
2507 [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol
2508 (SIP) "Join" Header", RFC 3911, October 2004.
2510 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
2511 Extensions to the Session Initiation Protocol (SIP) for
2512 Asserted Identity within Trusted Networks", RFC 3325,
2513 November 2002.
2515 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol
2516 (SIP) Call Control - Conferencing for User Agents",
2517 BCP 119, RFC 4579, August 2006.
2519 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
2520 "Indicating User Agent Capabilities in the Session
2521 Initiation Protocol (SIP)", RFC 3840, August 2004.
2523 Authors' Addresses
2525 Alan Johnston (editor)
2526 Avaya
2527 St. Louis, MO 63124
2529 Email: alan@sipstation.com
2531 Mohsen Soroushnejad
2532 Sylantro Systems Corp
2534 Email: mohsen.soroush@sylantro.com
2536 Venkatesh Venkataramanan
2537 Sylantro Systems Corp
2539 Email: vvenkatar@gmail.com
2541 Paul Pepper
2542 Citel Technologies
2544 Email: paul.pepper@citel.com
2546 Anil Kumar
2547 Yahoo Inc.
2549 Email: anil@yahoo-inc.com
2551 Full Copyright Statement
2553 Copyright (C) The IETF Trust (2008).
2555 This document is subject to the rights, licenses and restrictions
2556 contained in BCP 78, and except as set forth therein, the authors
2557 retain all their rights.
2559 This document and the information contained herein are provided on an
2560 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2561 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
2562 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
2563 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
2564 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2565 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2567 Intellectual Property
2569 The IETF takes no position regarding the validity or scope of any
2570 Intellectual Property Rights or other rights that might be claimed to
2571 pertain to the implementation or use of the technology described in
2572 this document or the extent to which any license under such rights
2573 might or might not be available; nor does it represent that it has
2574 made any independent effort to identify any such rights. Information
2575 on the procedures with respect to rights in RFC documents can be
2576 found in BCP 78 and BCP 79.
2578 Copies of IPR disclosures made to the IETF Secretariat and any
2579 assurances of licenses to be made available, or the result of an
2580 attempt made to obtain a general license or permission for the use of
2581 such proprietary rights by implementers or users of this
2582 specification can be obtained from the IETF on-line IPR repository at
2583 http://www.ietf.org/ipr.
2585 The IETF invites any interested party to bring to its attention any
2586 copyrights, patents or patent applications, or other proprietary
2587 rights that may cover technology that may be required to implement
2588 this standard. Please address the information to the IETF at
2589 ietf-ipr@ietf.org.