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 element. 434 5.2.1. The element 436 The element is used convey the appearance number. The 437 appearance number is a non-negative integer. When sent in a 438 notification in state Trying to the Appearance Agent, it is used to 439 request an appearance number. When sent by the Appearance Agent, it 440 indicates that the appearance number is associated with a dialog. 442 5.2.2. The element 444 The element is a boolean used to indicate whether the UA 445 will accept Join or Replaces INVITEs for this dialog. For example, 446 some shared appearance systems only allow call pickup when the call 447 is on hold. In this case, the element should be used to 448 explicitly indicate this, rather than implicitly by the hold state. 450 It is important to note that this element is a hint. Although a UA 451 may set exclusive to true, the UA must still be ready to reject an 452 INVITE Join relating to this dialog. Also, an INVITE Replaces might 453 be sent to the non-shared appearance UA to take the call. For this 454 reason, a UA MAY also not report full dialog identifier information 455 to the Appearance Agent for calls set to exclusive. If these dialog 456 identifiers have already been shared with the Appearance Agent, the 457 UA could send an INVITE Replaces to change them and then not report 458 the new ones to the Appearance Agent. 460 If the proxy knows which dialogs are marked exclusive, the proxy MAY 461 enforce this exclusivity by rejecting INVITE Join and INVITE Replaces 462 requests containing those dialog identifiers with a 403 Forbidden 463 response. 465 5.2.3. The element 467 The element is used convey dialog identifiers of any 468 other dialogs which are joined (mixed or bridged) with the dialog. 469 Only the UA which is performing the actual media mixing should 470 include this element in notifications to the Appearance Agent. Note 471 that this element should still be used even when the Join header 472 field was not used to join the dialogs. For example, two separate 473 dialogs on a UA could be joined without any SIP call control 474 operations. Joined dialogs will share the same appearance number. 476 5.2.4. The element 478 The element is used convey dialog identifiers of 479 any other dialogs which will be or have been replaced with this 480 dialog. For example, a UA in the group picking up a call on another 481 UA by sending an INVITE with Replaces would include this element for 482 the replacing dialog. Replaced dialogs will share the same 483 appearance number. 485 5.3. Shared Appearance User Agents 487 User Agents that support the Shared Appearance feature MUST support 488 the dialog state package [RFC4235] with the shared appearance 489 extensions and the 'shared' dialog event package parameter defined in 490 this draft. 492 User Agents MUST use the dialog package extensions in Section 5.2 493 along with the PUBLISH [RFC3903] method to send local status to the 494 Appearance Agent, and SUBSCRIBE [RFC3265] to the Appearance Agent to 495 learn the status of other User Agents in the group. SUBSCRIBE 496 requests MUST include the 'shared' Event package parameter. 498 The presence of the 'shared' Event package parameter in the 499 SUBSCRIBE tells the Appearance Agent that this UA supports this 500 specification. 502 PUBLISH requests SHOULD include the 'shared' Event package parameter, 503 except when specified otherwise. The publication URI is either a 504 provisioned value or the default username 'appearance-agent'. For 505 example, a UA in the domain of example.com would publish dialog state 506 to sip:appearance-agent@example.com. 508 OPEN ISSUE: Should a UA be able to publish to the group AOR? 510 User Agents SHOULD support sending and receiving an INVITE with a 511 Replaces [RFC3891] header to allow the Call Pickup operation. User 512 Agents MUST support sending an INVITE a Join [RFC3911] header to 513 initiate bridging. User Agents MUST support receiving an INVITE with 514 a Join header, though they are not obligated to support bridging of 515 calls, either through policy, preference, or implementation 516 limitations such as bandwidth or hardware constraints. 518 When publishing dialog package information, a UA MUST include all 519 dialog identification available at the time of publication, with the 520 exception that a UA may omit information if it wishes to prevent 521 other UAs from joining or picking up a call. Dialog identification 522 includes local and remote target URIs, call-id, to-tag, and from-tag. 523 When calls are placed on hold, the "+sip.rendering=no" feature tag 524 MUST be included in dialog package notifications. 526 The accurate rendering of the idle/active/alerting/hold state of 527 other UAs in the group is an important part of the shared 528 appearance feature. 530 A UA SHOULD render the appearance number to the user or display 531 appearance status information to the user in a way that preserves the 532 appearance order. 534 A UA SHOULD send dialog package PUBLISH requests for the following 535 events: 537 1. When going selecting an appearance number (i.e. going "off-hook" 538 if the UA's user interface uses this metaphor), 539 2. When sending an outgoing INVITE, 540 3. When receiving a 18x response, 541 4. When sending or receiving a 2xx response to an INVITE, 542 5. When sending or receiving a BYE 544 A UA SHOULD NOT send dialog package PUBLISH requests when receiving 545 an incoming INVITE or when sending a 18x response. 547 A large group of UAs publishing in these conditions when an INVITE 548 has forked will generate significant dialog package PUBLISH and 549 NOTIFY traffic that actually conveys no new information to other 550 UAs in the group. 552 UAs can tell that a set of dialogs are joined (bridged or mixed) 553 together by the presence of one or more elements 554 containing other SIP dialog identifiers. 556 Prior to placing an outbound call, UAs may select or "seize" an 557 appearance number by sending a PUBLISH to the Appearance Agent 558 identifying the appearance number selected in an 559 element. In traditional telephony terms, this corresponds to "going 560 off hook" with an analog telephone. Note that when a UA selects an 561 appearance prior to establishment of a dialog, not all dialog 562 information will be available. In particular, when a UA publishes an 563 attempt to select an appearance prior to knowing the destination very 564 minimal dialog information may be available. For example, a minimal 565 set might be just the local target URI for the call. Only after 566 receiving the 200 OK to the PUBLISH SHOULD the INVITE be sent. If no 567 dialog identification information was present in the initial PUBLISH, 568 the UA MUST PUBLISH again after receiving the 100 Trying. 570 For an emergency call, a UA MUST never wait for a confirmed seizure 571 before sending an INVITE. Instead, the emergency call MUST proceed 572 regardless of the status of PUBLISH transaction. This requirement 573 applies to both clients and servers implementing this feature. 575 A UA that does not need to select a particular appearance number (or 576 doesn't care) would just send an INVITE as normal to place an 577 outbound call. The UA placing the call SHOULD PUBLISH after 578 receiving a 1xx response to the INVITE. If the appearance number is 579 not known, the 'appearance' element is not included in the 580 publication and the 'shared' event package parameter SHOULD NOT be 581 included. Once the appearance number is known, it should be included 582 in all publications for this dialog and the 'shared' event package 583 parameter included in the PUBLISH. 585 The publication without the 'shared' event package parameter looks 586 identical to a publication from a UA which does not understand the 587 shared appearance feature. In both these cases, the Appearance 588 Agent will assign an appearance number for this dialog. 590 A UA wanting to place a call but not have an appearance number 591 assigned publishes before sending the INVITE without an 'appearance' 592 element but with the 'shared' event package parameter present. If 593 the Appearance Agent policy does not allow calls without an assigned 594 appearance number, a 409 Conflict response will be received, and the 595 UA will republish either selecting an appearance number or without 596 one, in which case the Appearance Agent will assign one. 598 The publication with 'shared' event package parameter allows the 599 Appearance Agent to determine that no appearance number should be 600 allocated. 602 OPEN ISSUE: The only use case we have for this is consultation 603 hold. Are there other use cases? Is that use case important 604 enough or should we remove this mechanism? 606 When an INVITE is generated to attempt to bridge or take a call (i.e. 607 contains Join or Replaces with a dialog identifier of another dialog 608 in the shared appearance group), the appearance number of the joined 609 or replaced call SHOULD be used. In this case, the PUBLISH MUST be 610 sent prior to sending the INVITE. The publication MUST contain the 611 appearance number of the dialog to be joined or replaced and the 612 dialog identifier in the 'joined-dialog' or 'replaced-dialog' 613 elements. The INVITE is sent after the receipt of a 200 OK to the 614 PUBLISH. 616 For inbound calls which contain a reference to an appearance number 617 in the INVITE, a UA MUST PUBLISH the use of an appearance number 618 after it responds with a 2xx to establish a dialog. 620 A UA SHOULD register against the AOR only if it is likely the UA will 621 be answering incoming calls. If the UA is mainly going to be 622 monitoring the status of the shared appearance group calls and 623 picking or joining calls, the UA SHOULD only subscribe to the 624 Appearance Agent and not register against the AOR. 626 All subscribed UAs will received NOTIFYs of Trying state for 627 incoming INVITEs. 629 5.4. Appearance Agent 631 An Appearance Agent defined in this specification MUST implement a 632 dialog package state agent for the UAs registered against the AOR. 634 The Appearance Agent MUST support the appearance dialog package 635 extensions defined in Section 5.2. The Appearance Agent MUST support 636 publications and subscriptions for this event package. 638 The Appearance Agent MUST have a way of discovering the dialog 639 identifiers of incoming INVITEs. The Appearance Agent MUST allocate 640 an appearance number for all incoming calls and send immediate 641 notifications to the UAs subscribed to the shared group AOR. An 642 Appearance Agent MAY assign an appearance number to an INVITE if a 643 PUBLISH is not received for the dialog within a reasonable period of 644 time. If the appearance group has non-shared appearance UAs, the 645 Appearance Agent MUST allocate appearance numbers for INVITEs sent by 646 those UAs. 648 Note that in general, the Appearance Agent makes appearance 649 allocation decisions based on publications rather than on INVITEs. 651 An Appearance Agent receiving a PUBLISH with an appearance number 652 checks to make sure the publication is valid. An appearance number 653 can be assigned to only one dialog unless there is a 'joined-dialog' 654 or 'replaced-dialog' element indicating that the dialog will be/has 655 been replaced or joined. A 409 Conflict response is returned if the 656 chosen appearance number is invalid, and an immediate NOTIFY should 657 be sent to the UA. 659 An Appearance Agent receiving a PUBLISH without an appearance number 660 and without the 'shared' event package parameter checks to see if the 661 dialog already has an appearance number assigned to it. If it does, 662 it replies with 200 OK and updates the dialog information. If it 663 does not, the Appearance Agent assigns an available appearance 664 number, returns a 200 OK and NOTIFYs the other UAs in the group. 666 Note that this case could be a shared appearance unaware UA or a 667 UA that does not care what appearance number is used for the 668 dialog. 670 An Appearance Agent receiving a PUBLISH without an appearance number 671 but with the 'shared' event package parameter present interprets this 672 as a request by the UA to not assign an appearance number. If the 673 Appearance Agent policy does not allow this, a 409 Conflict response 674 is returned. If policy does allow this, a 200 OK response is 675 returned and no appearance number is allocated. 677 The Appearance Agent controls the rate of dialog state publication 678 using the Expires header field in 200 OK responses to PUBLISH 679 requests. The Appearance Agent MAY vary the expiration interval 680 depending on the type of publication, or, an Appearance Agent MAY 681 just use the same interval for all publications. For publications of 682 trying, alerting, or connected state, an interval of 3 minutes is 683 RECOMMENDED. 685 During dynamic situations, such as during a call pickup or join 686 action, the Appearance Agent MAY choose to implement rate limiting to 687 reduce the amount of notification traffic. For example, an 688 Appearance Agent may choose not to generate immediate NOTIFYs upon 689 receipt of PUBLISHes. Instead, a single NOTIFY can convey the 690 effects of a number of PUBLISHes, thus reducing the NOTIFY traffic 691 within the group. 693 If an INVITE is sent and no appearance number is available, the proxy 694 MAY reject the INVITE with a 403 Forbidden response code. 696 6. XML Schema Definition 698 The 'appearance', 'joined-dialog', 'replaced-dialog', and 'exclusive' 699 elements are defined within a new XML namespace URI. This namespace 700 is "urn:ietf:params:xml:ns:sa-dialog-info". The schema for these 701 elements is: 703 704 710 711 712 714 716 718 719 721 722 723 725 727 729 730 732 733 734 735 737 738 739 740 741 743 7. User Interface Considerations 745 The "appearance number" allocated to a call is an important concept 746 that enables calls to be handled by multiple devices with 747 heterogeneous user interfaces in a manner that still allows users to 748 see a consistent model. Careful treatment of the appearance number 749 is essential to meet the expectations of the users. Also, rendering 750 the correct call/appearance state to users is also important. 752 7.1. Appearance Number Rendering 754 Since different UAs have different user interface capabilities, it is 755 usual to find that some UAs have restrictions that others do not. 756 Perfect interoperability across all UAs is clearly not possible, but 757 by careful design, interoperability up to the limits of each UA can 758 be achieved. 760 The following guidelines suggest how the appearance number should be 761 handled in three typical user interface implementations. 763 7.1.1. Single Appearance UAs 765 These devices are constrained by only having the capability of 766 displaying status indications for a single appearance. Despite this, 767 it is important that devices of this type do not ignore the 768 appearance number. The UA should still send messages annotated with 769 an appropriate appearance number (i.e. "0"). Any call indications 770 for appearances other than for number "0" should be rejected with a 771 486 or 480 response. 773 7.1.2. Dual Appearance UAs 775 These devices are essentially single appearance phones that implement 776 call waiting. They have a very simple user interface that allows 777 them to switch between two appearances (toggle or flash hook) and 778 perhaps audible tones to indicate the status of the other appearance. 780 7.1.3. Shared Appearance UAs with Fixed Appearance Number 782 This UA is the typical 'business-class' hard-phone. A number of 783 appearances are typically configured statically and labeled on 784 buttons, and calls may be managed using these configured appearances. 785 Any calls outside this range should be ignored, and not mapped to a 786 free button. Users of these devices often select specific appearance 787 numbers for outgoing calls, and the UA will need to select the 788 appearance number and wait for confirmation from the Appearance Agent 789 before proceeding with calls. 791 7.1.4. Shared Appearance UAs with Variable Appearance Number 793 This UA is typically a soft-phone or graphically rich user interface 794 hard-phone. In these cases, even the idea of an appearance index may 795 seem unnecessary. However, for these phones to be able to interwork 796 successfully with other phone types, it is important that they still 797 use the appearance index to govern the order of appearance of calls 798 in progress. No specific guidance on presentation is given except 799 that the order should be consistent. Thought should also be given to 800 how an appearance number that has no call associated with it should 801 be rendered to the user. These devices can typically make calls 802 without waiting for confirmation from the Appearance Agent on the 803 appearance number. 805 The problems faced by each style of user interface are readily seen 806 in this example: 808 1. A call arrives at the shared appearance group, and is assigned an 809 appearance number of 0. All UAs should be able to render to the 810 user the arrival of this call. 811 2. Another call arrives at the shared appearance group, and is 812 assigned an appearance number of 1. The single appearance UA 813 should not present this call to the user. Other user agents 814 should have no problems presenting this call distinctly from the 815 first call. 816 3. The first call clears, releasing appearance number "0". The 817 single appearance UA should now be indicating no calls since it 818 is unable to manage calls other than on the first appearance. 819 Both shared appearance UAs should clearly show that appearance 820 number 0 is now free, but that there is still a call on 821 appearance number 1. 822 4. A third call arrives, and is assigned the appearance number of 0. 823 All UAs should be able to render the arrival of this new call to 824 the user. Multiple appearnce UAs should continue to indicate the 825 presence of the second call, and should also ensure that the 826 presentation order is related to the appearance number and not 827 the order of call arrival. 829 7.2. Call State Rendering 831 UAs that implement the shared appearance feature typically have a 832 user interface that provides the state of other appearances in the 833 group. As dialog state NOTIFYs from the Appearance Agent are 834 processed, this information can be rendered. Even the simplest user 835 interface typically has three states: idle, active, and hold. The 836 idle state, usually indicated by lamp off, is indicated for an 837 appearance when the appearance number is not associated with any 838 dialogs, as reported by the Appearance Agent. The active state, 839 usually indicated by a lamp on, is indicated by an appearance number 840 being associated with at least one dialog, as reported by the 841 Appearance Agent. The hold state, often indicated by a blinking 842 lamp, means the call state from the perspective of the UA in the 843 shared appearance group is hold. This can be determined by the 844 presence of the "sip+rendering=no" feature tag [RFC3840] with the 845 local target URI. Note that the hold state of the remote target URI 846 is not relevant to this display. For joined dialogs, the state is 847 rendered as hold only if all local target URIs are indicated with the 848 "sip+rendering=no" feature tag. 850 8. Interop with non-Shared Appearance UAs 852 EDITOR'S NOTE: This section needs to be reviewed in light of recent 853 changes in the specification. 855 It is desirable to allow a basic UA that does not directly support 856 shared appearance to be part of a shared appearance group. To 857 support this the Proxy must collaborate with the Appearance Agent. 858 This is not required in the basic shared appearance architecture, 859 consequently shared appearance interop with non-shared appearance UAs 860 will not be available in all shared appearance deployments. 862 First, a UA which does not support dialog events or the shared 863 appearance feature will be discussed. Then, a UA which does support 864 dialog events but not the shared appearance feature will be 865 discussed. 867 8.1. Appearance Assignment 869 A UA that has no knowledge of appearances must have appearance 870 numbers assigned by the Appearance Agent for both incoming and 871 outgoing calls. If the non-shared appearance UA does not support 872 Join or Replaces, all dialogs could be marked "exclusive" to indicate 873 that these options are not available. 875 8.2. Appearance Release 877 In all cases the Appearance Agent must be aware of dialog lifetime to 878 release appearances back into the group. 880 It is also desirable that any dialog state changes (such as hold, 881 etc) be made available to other UAs in the group through the Dialog 882 Event Package. If the Appearance Agent includes a proxy which 883 Record-Routes for dialogs from the non-shared appearance aware UA, 884 the Appearance Agent will know about the state of dialogs including 885 hold, etc. This information could be determined from inspection of 886 INVITE and re-INVITE messages and added to the dialog information 887 conveyed to other UAs. 889 8.3. UAs Supporting Dialog Events but Not Shared Appearance 891 Interoperability with UAs which support dialog events but not the 892 shared appearance feature is more straightforward. As before, all 893 appearance number assignment must be done by the Appearance Agent. 894 This type of UA will be detected by the Appearance Agent by the 895 absence of the ma event parameter in SUBSCRIBE or PUBLISH messages. 896 The Appearance Agent can include appearance information in NOTIFYs - 897 this UA will simply ignore this extra information. This type of UA 898 will ignore appearance number limitations and may attempt to Join or 899 Replace dialogs marked exclusive. As a result, the Proxy or UAs may 900 need to reject such requests. 902 The need for close cooperation between the Proxy and the Appearance 903 Agent is not needed as the Appearance Agent will learn about all 904 dialogs from the UA itself. 906 9. Provisioning Considerations 908 TBD. 910 10. Example Message Flows 912 The next section shows call flow and message examples. The flows and 913 descriptions are non-normative. 915 10.1. Registration and Subscription 917 Bob and Alice are in an appearance group identified by Alice's AOR. 918 Bob REGISTERs using contact sip:bob@ua2.example.com. Alice REGISTERs 919 with contact sip:alice@ua1.example.com. 921 User Agents for Alice and Bob subscribe to the dialog package for the 922 appearance AOR and publish dialog state to the Appearance Agent. 923 Message exchanges between the Registrar, Appearance Agent, Alice, and 924 Bob are shown below. The call flow examples below do not show the 925 authentication of subscriptions, publications, and notifications. It 926 should be noted that for security purposes, all subscriptions must be 927 authorized before the same is accepted. 929 Also note that registrations and subscriptions must all be refreshed 930 by Alice at intervals determined by the expiration intervals returned 931 by the Registrar or Appearance Agent. 933 Registrar Appearance Agent Alice 934 | | | 935 | | | 936 |<--------------------------- REGISTER F1<| 937 | | | 938 |>F2 200 OK ----------------------------->| 939 | | | 940 | |<----- SUBSCRIBE F3<| 941 | | | 942 | |>F4 202 Accepted -->| 943 | | | 944 | |>F5 NOTIFY -------->| 945 | | | 946 | |<-------- 200 OK F6<| 947 | | | 949 Figure 2. 951 F1-F2: Alice registers AOR with contact: 953 F1 Alice ----> Registrar 955 REGISTER sip:registrar.example.com SIP/2.0 956 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09 957 From: ;tag=CDF9A668-909E2BDD 958 To: 959 CSeq: 2 REGISTER 960 Call-ID: d3281184-518783de-cc23d6bb@ua1.example.com 961 Contact: 962 Max-Forwards: 70 963 Expires: 3600 964 Content-Length: 0 966 F2 Registrar ----> Alice 968 SIP/2.0 200 OK 969 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKfbf176ef7F1D5FA2 970 CSeq: 2 REGISTER 971 Call-ID: d3281184-518783de-cc23d6bb@ua1.example.com 972 From: ;tag=CDF9A668-909E2BDD 973 To: ;tag=1664573879820199 974 Contact: 975 Expires: 3600 976 Content-Length: 0 978 F3 to F6: Alice also subscribes to the events associated with the 979 Appearance AOR. Appearance Agent also notifies Alice of the status. 981 F3 Alice ----> Appearance Agent 983 SUBSCRIBE sip:alice@example.com SIP/2.0 984 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A 985 From: ;tag=925A3CAD-CEBB276E 986 To: 987 CSeq: 1 SUBSCRIBE 988 Call-ID: ef4704d9-bb68aa0b-474c9d94@ua1.example.com 989 Contact: 990 Event: dialog;shared 991 Accept: application/dialog-info+xml 992 Max-Forwards: 70 993 Expires: 3700 994 Content-Length: 0 996 F4 Appearance Agent ----> Alice 998 SIP/2.0 202 Accepted 999 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A 1000 CSeq: 1 SUBSCRIBE 1001 Call-ID: ef4704d9-bb68aa0b-474c9d94@ua1.example.com 1002 From: ;tag=925A3CAD-CEBB276E 1003 To: ;tag=1636248422222257 1004 Allow-Events: dialog 1005 Expires: 3700 1006 Contact: 1007 Content-Length: 0 1009 F5 Appearance Agent ----> Alice 1011 NOTIFY sip:alice@ua1.example.com SIP/2.0 1012 From: ;tag=1636248422222257 1013 To: ;tag=925A3CAD-CEBB276E 1014 Call-ID: ef4704d9-bb68aa0b-474c9d94@ua1.example.com 1015 CSeq: 2 NOTIFY 1016 Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1846984327225734 1017 Max-Forwards: 70 1018 Content-Type: application/dialog-info+xml 1019 Event: dialog;shared 1020 Subscription-State: active 1021 Contact: 1022 Content-Length: ... 1024 1025 1029 1031 F6 Alice ----> Appearance Agent 1033 SIP/2.0 200 OK 1034 Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1846984327225734 1035 From: ;tag=1636248422222257 1036 To: ;tag=925A3CAD-CEBB276E 1037 CSeq: 2 NOTIFY 1038 Call-ID: ef4704d9-bb68aa0b-474c9d94@ua1.example.com 1039 Contact: 1040 Event: dialog;shared 1041 Content-Length: 0 1043 10.2. Appearance Selection for Incoming Call 1045 In the call flow below Bob and Alice are in an appearance group. 1046 Carol places a call to the appearance group AOR. The Appearance 1047 Agent sends NOTIFYs to Alice and Bob telling them what appearance the 1048 call is using. Both Alice and Bob's devices are alerted of the 1049 incoming call. Bob answers the call. He then places Carol on hold. 1050 Alice picks up the held call and has a established session with 1051 Carol. Finally, Carol terminates the session. 1053 Note that it is possible that both Alice and Bob answer the call and 1054 send 200 OK responses to Carol. Alice and Bob will also both publish 1055 to the Appearance Agent indicating that the selected appearance is in 1056 use by their respective dialogs. The Appearance Agent can detect 1057 this since the Call-ID and remote-tag will be the same in both 1058 publications and should allow this for a period of time. It is up to 1059 Carol to resolve this situation. Typically, Carol will send ACKs to 1060 both 200 OKs but send a BYE to terminate one of the dialogs. As a 1061 result, either Alice or Bob will receive the BYE and publish that 1062 their dialog is over. However, if Carol answers both Alice and Bob 1063 and keeps both dialogs active, then the Appearance Agent will need to 1064 resolve the situation by moving either Alice or Bob's dialog to a 1065 different appearance. 1067 OPEN ISSUE: What if Carol answers both calls and then performs 1068 local mixing? In this case, Alice and Bob are effectively using 1069 the same appearance and the Appearance Agent does not need to move 1070 one of the dialogs. However, how does anyone know besides Carol 1071 that this is happening? 1073 All NOTIFY messages in the call flow below carry dialog events and 1074 only dialog states are mentioned for simplicity. For brevity, the 1075 details of some messages are not shown below. 1077 Forking Appearance 1078 Carol Proxy Agent Alice Bob 1079 | | | | | 1080 |>F1 INVITE >| | | | 1081 | |< - - - - - >| | | 1082 | | |>F2 NOTIFY ----------->| 1083 | | | | | 1084 | | |F4 NOTIFY ->| | 1087 | | | | | 1088 | | |<-200 OK F5-<| | 1089 |<- 100 F6 -<| | | | 1090 | |>F7 INVITE (appearance=1) ---------->| 1091 | | | | | 1092 | |>F8 INVITE (appearance=1) >| | 1093 | | | | | 1094 | |<-------------------- Ringing 180 F9<| 1095 |< 180 F10 -<| | | | 1096 | |<--------- 180 Ringing F11<| | 1097 |< 180 F12 -<| | | | 1098 | | | | | 1099 | |<------------------------ 200 OK F13<| 1100 |< 200 F14 -<| | | | 1101 | | |<--------- PUBLISH F15<| 1102 | | | | | 1103 | | |>F16 200 OK ---------->| 1104 | | | | | 1105 | |>F17 CANCEL -------------->| | 1106 | | | | | 1107 | |<-------------- 200 OK F18<| | 1108 | | | | | 1109 | |F20 ACK ----------------->| | 1112 |>F21 ACK -->| | | | 1113 | |>F22 ACK --------------------------->| 1114 | | | | | 1115 |<=============Both way RTP established===========>| 1116 | | | | | 1117 | | |>F23 NOTIFY >| | 1118 | | | | | 1119 | | |<- 200 F24 -<| | 1120 | | | | | 1121 | | |>F25 NOTIFY ---------->| 1122 | | | | | 1123 | | | Alice 1130 NOTIFY sip:alice@ua1.example.com SIP/2.0 1131 From: ;tag=151702541050937 1132 To: ;tag=18433323-C3D237CE 1133 Call-ID: 1e361d2f-a9f51109-bafe31d4@ua1.example.com 1134 CSeq: 12 NOTIFY 1135 Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK14031499568413 1136 Max-Forwards: 70 1137 Content-Type: application/dialog-info+xml 1138 Event: dialog;shared 1139 Subscription-State: active 1140 Contact: 1141 Content-Length: ... 1143 1144 1149 1153 1 1154 trying 1155 1156 sip:carol@ua.example.com 1157 1158 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.