idnits 2.17.1 draft-ietf-bliss-shared-appearances-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3261, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4235, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3261, updated by this document, for RFC5378 checks: 2000-07-17) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 4, 2012) is 4375 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) == Outdated reference: A later version (-14) exists of draft-ietf-salud-alert-info-urns-06 == Outdated reference: A later version (-15) exists of draft-worley-service-example-09 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 4 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 Updates: 3261, 4235 (if approved) M. Soroushnejad 5 Intended status: Standards Track V. Venkataramanan 6 Expires: November 5, 2012 Sylantro Systems Corp 7 May 4, 2012 9 Shared Appearances of a Session Initiation Protocol (SIP) Address of 10 Record (AOR) 11 draft-ietf-bliss-shared-appearances-10 13 Abstract 15 This document describes the requirements and implementation of a 16 group telephony feature commonly known as Bridged Line Appearance 17 (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line 18 Appearance (SCA). When implemented using the Session Initiation 19 Protocol (SIP), it is referred to as shared appearances of an Address 20 of Record (AOR) since SIP does not have the concept of lines. This 21 feature is commonly offered in IP Centrex services and IP-PBX 22 offerings and is likely to be implemented on SIP IP telephones and 23 SIP feature servers used in a business environment. This feature 24 allows several user agents (UAs) to share a common AOR, learn about 25 calls placed and received by other UAs in the group, and pick up or 26 join calls within the group. This document discusses use cases, 27 lists requirements and defines extensions to implement this feature. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on November 5, 2012. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 2. Conventions used in this document . . . . . . . . . . . . . . 6 77 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 6 78 3.1. Executive/Assistant Arrangement . . . . . . . . . . . . . 6 79 3.2. Call Group . . . . . . . . . . . . . . . . . . . . . . . 7 80 3.3. Single Line Extension . . . . . . . . . . . . . . . . . . 7 81 3.4. Changing UAs . . . . . . . . . . . . . . . . . . . . . . 7 82 4. Requirements and Implementation . . . . . . . . . . . . . . . 7 83 4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 7 84 4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 9 85 5. Normative Description . . . . . . . . . . . . . . . . . . . . 11 86 5.1. Elements . . . . . . . . . . . . . . . . . . . . . . . . 11 87 5.2. Shared Appearance Dialog Package Extensions . . . . . . . 12 88 5.2.1. The element . . . . . . . . . . . . . . . 12 89 5.2.2. The element . . . . . . . . . . . . . . . 12 90 5.2.3. The element . . . . . . . . . . . . . 13 91 5.2.4. The element . . . . . . . . . . . . 14 92 5.3. Shared Appearance User Agents . . . . . . . . . . . . . . 14 93 5.3.1. Appearance Numbers and Call Context . . . . . . . . . 17 94 5.3.2. Appearance Numbers and Call Control . . . . . . . . . 17 95 5.3.3. Appearance Numbers and Transfer . . . . . . . . . . . 18 96 5.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . 19 97 6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 21 98 7. Alert-Info Appearance Parameter Definition . . . . . . . . . . 23 99 8. User Interface Considerations . . . . . . . . . . . . . . . . 24 100 8.1. Appearance Number Rendering . . . . . . . . . . . . . . . 24 101 8.1.1. Single Appearance UAs . . . . . . . . . . . . . . . . 24 102 8.1.2. Dual Appearance UAs . . . . . . . . . . . . . . . . . 24 103 8.1.3. Shared Appearance UAs with Fixed Appearance Number . . 25 104 8.1.4. Shared Appearance UAs with Variable Appearance 105 Number . . . . . . . . . . . . . . . . . . . . . . . . 25 106 8.1.5. Example User Interface Issues . . . . . . . . . . . . 25 107 8.2. Call State Rendering . . . . . . . . . . . . . . . . . . 26 108 9. Interoperability with non-Shared Appearance UAs . . . . . . . 26 109 9.1. Appearance Assignment . . . . . . . . . . . . . . . . . . 26 110 9.2. Appearance Release . . . . . . . . . . . . . . . . . . . 27 111 9.3. UAs Supporting Dialog Events but Not Shared Appearance . 27 112 10. Provisioning Considerations . . . . . . . . . . . . . . . . . 27 113 11. Example Message Flows . . . . . . . . . . . . . . . . . . . . 28 114 11.1. Registration and Subscription . . . . . . . . . . . . . . 28 115 11.2. Appearance Selection for Incoming Call . . . . . . . . . 32 116 11.3. Outgoing Call without Appearance Seizure . . . . . . . . 35 117 11.4. Outgoing Call with Appearance Seizure . . . . . . . . . . 38 118 11.5. Outgoing Call without using an Appearance Number . . . . 42 119 11.6. Appearance Release . . . . . . . . . . . . . . . . . . . 44 120 11.7. Appearance Pickup . . . . . . . . . . . . . . . . . . . . 45 121 11.8. Calls between UAs within the Group . . . . . . . . . . . 50 122 11.9. Consultation Hold with Appearances . . . . . . . . . . . 52 123 11.10. Joining or Bridging an Appearance . . . . . . . . . . . . 55 124 11.11. Appearance Allocation - Loss of Appearance . . . . . . . 58 125 11.12. Appearance Seizure Contention Race Condition . . . . . . 59 126 11.13. Appearance Agent Subscription to UAs . . . . . . . . . . 60 127 11.14. Appearance Pickup Race Condition Failure . . . . . . . . 62 128 11.15. Appearance Seizure Incoming/Outgoing Contention Race 129 Condition . . . . . . . . . . . . . . . . . . . . . . . . 65 130 12. Security Considerations . . . . . . . . . . . . . . . . . . . 66 131 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66 132 13.1. SIP Event Package Parameter: shared . . . . . . . . . . . 66 133 13.2. URN Sub-Namespace Registration: sa-dialog-info . . . . . 67 134 13.3. XML Schema Registration . . . . . . . . . . . . . . . . . 67 135 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 68 136 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 68 137 15.1. Normative References . . . . . . . . . . . . . . . . . . 68 138 15.2. Informative References . . . . . . . . . . . . . . . . . 69 139 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70 141 1. Introduction 143 The feature and functionality requirements for SIP user agents (UAs) 144 supporting business telephony applications differ greatly from basic 145 SIP user agents, both in terms of services and end user experience. 146 In addition to basic SIP support [RFC3261], many of the services in a 147 business environment require the support for SIP extensions such as 148 REFER [RFC3515], SUBSCRIBE/NOTIFY primitives 149 [I-D.ietf-sipcore-rfc3265bis] PUBLISH [RFC3903], the SIP Replaces 150 [RFC3891], and Join [RFC3911] header fields, etc. Many of the 151 popular business services have been documented in the SIP Service 152 Examples [RFC5359]. 154 This specification details a method for implementing a group 155 telephony feature known variously in telephony as Bridged Line 156 Appearance (BLA) or Multiple Line Appearances (MLA), one of the more 157 popular advanced features expected of SIP IP telephony devices in a 158 business environment. Other names for this feature include Shared 159 Call/Line Appearance (SCA), Shared Call Status and Multiple Call 160 Appearance (MCA). A variant of this feature is known as Single Line 161 Extension. 163 This document looks at how this feature can be implemented using 164 standard SIP [RFC3261] in conjunction with SIP events 165 [I-D.ietf-sipcore-rfc3265bis] and publication [RFC3903] (carrying the 166 SIP dialog state event package [RFC4235]) for exchanging status among 167 user agents. 169 In traditional telephony, the line is physical. A common scenario in 170 telephony is for a number of business telephones to share a single or 171 a small number of lines. The sharing or appearance of these lines 172 between a number of phones is what gives this feature its name. A 173 common scenario in SIP is for a number of business telephones to 174 share a single or a small number of Address of Record (AOR) URIs. 176 In addition, an AOR can have multiple appearances on a single UA in 177 terms of the user interface. The appearance number relates to the 178 user interface for the telephone - typically each appearance of an 179 AOR has a visual display (lamp that can change color or blink or a 180 screen icon) and a button (used to select the appearance) where each 181 appearance number is associated with a different dialog to/from the 182 AOR. The telephony concept of line appearance is still relevant to 183 SIP due to the user interface considerations. It is important to 184 keep the appearance number construct because: 186 1. Human users are used to the concept and will expect it in 187 replacement systems (e.g. an overhead page announcement says "Joe 188 pickup line 3"). 190 2. It is a useful structure for user interface representation. 192 The purpose of the appearance number is to identify active calls to 193 facilitate sharing between users (e.g. passing a call from one user 194 to another). If a telephone has enough buttons/lamps, the appearance 195 number could be the positional sequence number of the button. If 196 not, it may still be desirable to present the call state, but the 197 appearance number should be displayed so that users know which call, 198 for example, is on hold on which key. 200 In this document, except for the usage scenarios in the next section, 201 we will use the term "appearance" rather than "line appearance" since 202 SIP does not have the concept of lines. Note that this does not mean 203 that a conventional telephony user interface (lamps and buttons) must 204 be used - implementations may use another metaphor as long as the 205 appearance number is readily apparent to the user. Each AOR has a 206 separate appearance numbering space. As a result, a given UA user 207 interface may have multiple occurrences of the same appearance 208 number, but they will be for different AORs. 210 2. Conventions used in this document 212 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 213 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 214 document are to be interpreted as described in RFC-2119 [RFC2119] and 215 indicate requirement levels for compliant mechanisms. 217 3. Usage Scenarios 219 The following examples are common applications of the Shared 220 Appearances feature and are mentioned here as informative use cases. 221 All these example usages can be supported by the Shared Appearances 222 feature described in this document. The main differences relate to 223 the user interface considerations of the device. 225 3.1. Executive/Assistant Arrangement 227 The appearances on the executive's UA also appear on the assistant's 228 UA. The assistant may answer incoming calls to the executive and 229 then place the call on hold for the executive to pick up. The 230 assistant can always see the state of all calls on the executive's 231 UA. 233 3.2. Call Group 235 Users with similar business needs or tasks can be assigned to 236 specific groups and share an AOR. For example, an IT department 237 staff of five might answer a help line which has three appearances on 238 each phone in the IT work area. A call answered on one phone can be 239 put on hold and picked up on another phone. A shout or an IM to 240 another staff member can result in them taking over a call on a 241 particular appearance. Another phone can request to be added/joined/ 242 bridged to an existing appearance resulting in a conference call. 244 3.3. Single Line Extension 246 In this scenario, incoming calls are offered to a group of UAs. When 247 one answers, the other UAs are informed. If another UA in the group 248 seizes the line (i.e. goes off hook), it is immediately bridged or 249 joined in with the call. This mimics the way residential telephone 250 extensions usually operate. 252 3.4. Changing UAs 254 A user is on a call on one UA and wishes to change devices and 255 continue the call on another UA. They place the call on hold, note 256 the appearance number of the call, then walk to another UA. They are 257 able to identify the same appearance number on the other UA, pickup 258 the call, and continue the conversation. 260 4. Requirements and Implementation 262 The next section details the requirements and discusses the 263 implementation of the shared appearances of an AOR feature. 265 4.1. Requirements 267 The basic requirements of the shared appearance feature can be 268 summarized as follows: 270 REQ-1 Incoming calls to the AOR must be offered to a group of UAs and 271 can be answered by any of them. 273 REQ-2 Each UA in the group must be able to learn the call status of 274 the others in the group for the purpose of rendering this information 275 to the user. 277 REQ-3 A UA must be able to join (also called bridge or conference 278 together) or pick up (take) an active call of another UA in the group 279 in a secure way. 281 REQ-4 The mechanism should require the minimal amount of 282 configuration. UAs registering against the group AOR should be able 283 to participate in the appearance group without manual configuration 284 of group members. 286 REQ-5 The mechanism must scale for large numbers of appearances, n, 287 and large numbers of UAs, N, without introducing excessive messaging 288 traffic. 290 REQ-6 Each call or session (incoming or outgoing) should be assigned 291 a common "appearance" number from a managed pool administered for the 292 AOR group. Once the session has terminated, the appearance number is 293 released back into the pool and can be reused by another incoming or 294 outgoing session. 296 REQ-7 Each UA in the group must be able to learn the status of all 297 appearances of the group. 299 REQ-8 There must be mechanisms to resolve appearance contention among 300 the UAs in the group. 302 REQ-9 The mechanism must allow all UAs receiving an incoming session 303 request to utilize the same appearance number at the time of 304 alerting. 306 REQ-10 The mechanism must have a way of reconstructing appearance 307 state after an outage that does not result in excessive traffic and 308 processing. 310 REQ-11 The mechanism must have backwards compatibility such that a UA 311 which is unaware of the feature can still register against the group 312 AOR and make and receive calls. 314 REQ-12 The mechanism must not allow UAs outside the group to select, 315 seize or manipulate appearance numbers. 317 REQ-13 For privacy reasons, there must be a mechanism so that 318 appearance information is not leaked outside the group of UAs. (e.g. 319 "So who do you have on line 1?") 321 REQ-14 The mechanism must support a way for UAs to request 322 exclusivity on a line appearance. Exclusivity means that the UA 323 requesting it desires to have a private conversation with the 324 external party and other UAs must not be allowed to join or take the 325 call. Exclusivity may be requested at the start of an incoming or 326 outgoing session or during the session. An exclusivity request may 327 be accepted or rejected by the entity providing the shared appearance 328 service. Therefore, the mechanism must provide a way of 329 communicating the result back to the requester UA. 331 REQ-15 The mechanism should support a way for a UA to seize a 332 particular appearance number for outgoing requests prior to sending 333 the actual request. This is often called seizure. 335 REQ-16 The mechanism should support a way for a UA to seize a 336 particular appearance number and also send the request at the same 337 time. This is needed when an automatic ringdown feature (a telephone 338 configured to immediately dial a phone number when it goes off hook) 339 is combined with shared appearances - in this case, seizing the line 340 is the same thing as dialing. 342 4.2. Implementation 344 This section non-normatively discusses the implementation of the 345 shared appearance feature. The normative description is in 346 Section 5. Many of the requirements for this service can be met 347 using standard SIP mechanisms such as: 349 - A SIP Forking Proxy and Registrar/Location Service meets REQ-1. 351 - The SIP Dialog Package meets REQ-2. 353 - The SIP Replaces and Join header fields meets REQ-3. 355 - The use of a State Agent for the Dialog Package meets REQ-4 and 356 REQ-5. 358 REQ-6 suggests the need for an entity which manages the appearance 359 resource. Just as conferencing systems commonly have a single point 360 of control, known as a focus, a Shared Appearance group has a single 361 point of control of the appearance shared resource. This is defined 362 as an Appearance Agent for a group. While an Appearance Agent can be 363 part of a centralized server, it could also be co-resident in a 364 member User Agent that has taken on this functionality for a group. 365 The Appearance Agent knows or is able to determine the dialog state 366 of all members of the group. 368 While the appearance resource could be managed co-operatively by a 369 group of UAs without any central control, this is outside the scope 370 of this draft. It is also possible that the Appearance Agent logic 371 could be distributed in all UAs in the group. For example, rules 372 that govern assigning appearance numbers for incoming requests (e.g. 373 lowest available appearance number) and rules for contention handling 374 (e.g. when two UAs request the use of the same appearance number, 375 hash dialog identifiers and compare with the lowest hash winning) 376 would need to be defined and implemented. 378 To best meet REQ-9, the appearance number for an incoming INVITE 379 needs to be contained in the INVITE, in addition to being delivered 380 in the dialog package NOTIFY. Otherwise, if the NOTIFY is delayed or 381 lost, a UA in the group might receive an incoming INVITE but might 382 not know which appearance number to render during alerting. 384 This specification defines an extension parameter for the Alert-Info 385 header field in RFC 3261 to carry the appearance number: 387 Alert-Info: ;appearance=1 389 The next section discusses the operations used to implement parts of 390 the shared appearance feature. 392 1. A UA is configured with the AOR of a shared appearance group. It 393 registers against the AOR, then attempts a dialog state 394 subscription to the AOR. If the subscription fails, loops back 395 to itself, or returns an error, it knows there is no State Agent, 396 and hence no Appearance Agent and this feature is not 397 implemented. 398 2. If the subscription receives a 200 OK, the UA knows there is a 399 State Agent and that the feature is implemented. The UA then 400 follows the steps in this list. 401 3. Information learned about the dialog state of other UAs in the 402 group is rendered to the user. 403 4. Incoming calls are forked to all UAs in the group, and any may 404 answer. UAs receive the appearance number to use in rendering 405 the incoming call in a NOTIFY from the Appearance Agent and in 406 the INVITE itself. The UA will also receive a notification if 407 the call is answered by another UA in the group so this 408 information can be rendered to the user. 409 5. For outgoing calls, the operation depends on the implementation. 410 If the user seizes a particular appearance number for the call, 411 the UA publishes the trying state dialog information with the 412 desired appearance number and waits for a 2xx response before 413 sending the INVITE. 414 6. For outgoing calls, if the user does not seize a particular 415 appearance or does not care, the INVITE can be sent immediately, 416 and the appearance number learned as the call progresses from a 417 notification from the Appearance Agent. 418 7. For outgoing calls, if the user does not want an appearance 419 number assigned (such as during a consultation call or if a UA is 420 fetching 'service media' such as music on hold 421 [I-D.worley-service-example]), the UA also publishes prior to 422 sending the INVITE but does not include an appearance number in 423 the publication. 425 8. Established calls within the group may be joined (bridged) or 426 taken (picked) by another UA. Information in the dialog package 427 notifications can be used to construct Join or Replaces header 428 fields. Since the same appearance number is used for these types 429 of operations, this information is published prior to sending the 430 INVITE Join or INVITE Replaces. 431 9. The Appearance Agent may not have direct access to the complete 432 dialog state of some or all of the UAs in the group. If this is 433 the case, the Appearance Agent will subscribe to the dialog state 434 of individual UAs in the group to obtain this information. In 435 any case, the Appearance Agent will send normal notifications 436 (via the subscriptions established by the UAs in step 1) every 437 time the aggregate dialog state of the AOR changes, including 438 when calls are placed, answered, placed on and off hold, and hung 439 up. 441 5. Normative Description 443 This section normatively describes the shared appearance feature 444 extensions. The following definitions are used throughout this 445 document: 447 Appearance number: An appearance number is a positive integer 448 associated with one or more dialogs of an AOR. Appearance numbers 449 are managed by an Appearance Agent and displayed and rendered to the 450 user by UAs that support this specification. When an appearance 451 number is assigned or requested, generally the assigned number is the 452 smallest positive integer that is not currently assigned as an 453 appearance number to a dialog for this AOR. 455 Seizing: An appearance can be reserved prior to a call being placed 456 by seizing the appearance. An appearance can be seized by 457 communicating an artificial state of "trying" prior to actually 458 initiating a dialog (i.e. sending the INVITE), in order to appear as 459 if it was already initiating a dialog. 461 Selecting(or Not-Seizing): An appearance is merely selected (i.e., 462 not seized) if there is no such communication of artificial state of 463 "trying" prior to initiating a dialog: i.e., the state is 464 communicated when the dialog is actually initiated. The appearance 465 number is learned after the INVITE is sent. 467 5.1. Elements 469 A complete system to implement this feature consists of: 471 1. User Agents that support publications, subscriptions, and 472 notifications for the SIP dialog event package, and the shared 473 appearance dialog package extensions and behavior. 474 2. An Appearance Agent consisting of a State Agent for the dialog 475 event package that implements an Event State Compositor (ESC) and 476 the shared appearance dialog package extensions and behavior. 477 The Appearance Agent also has logic for assigning and releasing 478 appearance numbers, and resolving appearance number contention. 479 3. A forking proxy server that can communicate with the State Agent 480 4. A registrar that supports the registration event package. 482 The behavior of these elements is described normatively in the 483 following sections after the definitions of the dialog package 484 extensions. 486 5.2. Shared Appearance Dialog Package Extensions 488 This specification defines four new elements as extensions to the SIP 489 Dialog Event package [RFC4235]. The schema is defined in Section 6. 490 The elements are , , , and 491 which are sub-elements of the element. 493 5.2.1. The element 495 The element, a child of the element, is used to 496 convey the appearance number of the dialog described by the parent 497 element. When sent by a UA in a PUBLISH with parent 498 with state attribute "trying" to the Appearance Agent, the 499 UA is requesting assignment of the given appearance number to the 500 current or future dialog with the given dialog identifiers. When an 501 element is sent by the Appearance Agent in a NOTIFY, it 502 indicates that the appearance number has been assigned to the 503 specified dialog. 505 Note that a element describes the contained dialogs 506 from the point of view of the UA (named by the "entity" attribute), 507 regardless of whether the containing request is sent by the UA or the 508 Appearance Agent. In particular, if the UA sent a request within the 509 described dialog, the To header field URI would match the 510 value and the to-tag parameter would match the remote-tag 511 attribute. Similarly, the From header field URI would match the 512 value and the from-tag parameter would match the 513 local-tag attribute. 515 5.2.2. The element 517 The element, a child of the element, is a 518 boolean, which when true, indicates that the UA is not willing to 519 accept an INVITE with a Join or Replaces header field targeted to the 520 dialog described by the element that is the parent of the 521 element. For example, some shared appearance systems 522 only allow call pickup when the call is on hold. In this case, the 523 element should be set to "false" when the call is held 524 and "true" when the call is not held, rather than having the 525 "exclusive" value implied by the hold state. 527 It is important to note that this element is a hint. In order to 528 prevent another UA from taking or joining a call, a UA can, in 529 addition to setting the tag, not report full dialog 530 information to the Appearance Agent. Not having the full dialog 531 information (Call-ID, remote-tag, and local-tag) prevents another UA 532 from constructing a Join or Replaces header field. Although a UA may 533 set exclusive to true, the UA must still be ready to reject an INVITE 534 Join relating to this dialog. If these dialog identifiers have 535 already been shared with the Appearance Agent, the UA could send an 536 INVITE Replaces to change them and then not report the new ones to 537 the Appearance Agent. 539 If the proxy knows which dialogs are marked exclusive, the proxy MAY 540 enforce this exclusivity by rejecting INVITE Join and INVITE Replaces 541 requests containing those dialog identifiers with a 403 Forbidden 542 response. 544 Note that exclusivity has nothing to do with appearance number 545 selection or seizing - instead, it is about call control 546 operations that can be performed on a dialog. 548 If the element is not present, it is assumed to be false. 550 5.2.3. The element 552 The element, a child of the element, is used 553 to convey dialog identifiers of any other dialogs which are joined 554 (mixed or bridged) with the dialog. Only the UA which is the common 555 endpoint of the mixed dialogs (and thus controlling the mixing 556 operation) should include this element in publications to the 557 Appearance Agent. Note that this element should still be used even 558 when the Join header field was not used to join the dialogs. For 559 example, two separate dialogs on a UA could be joined without any SIP 560 call control operations. Joined dialogs will share the same 561 appearance number. 563 If the element is not present, it is assumed that the 564 dialog is not joined or to be joined to any other dialog. 566 5.2.4. The element 568 The element, a child of the element, is 569 used to convey dialog identifiers of any other dialogs which will be 570 or have been replaced with this dialog. For example, a UA in the 571 group picking up a call on another UA by sending an INVITE with 572 Replaces would include this element for the replacing dialog. 573 Replaced dialogs will share the same appearance number. 575 If the element is not present, it is assumed that 576 the dialog has not replaced or is not to replace to any other dialog. 578 5.3. Shared Appearance User Agents 580 User Agents that support the Shared Appearance feature MUST support 581 the dialog state package [RFC4235] with the shared appearance 582 extensions and the 'shared' dialog event package parameter defined in 583 Section 13. 585 User Agents MUST support the dialog package extensions in Section 5.2 586 along with SUBSCRIBE and NOTIFY [I-D.ietf-sipcore-rfc3265bis] and 587 PUBLISH [RFC3903]. SUBSCRIBE, NOTIFY, and PUBLISH requests for the 588 dialog event package MUST include the 'shared' Event header field 589 parameter. 591 The presence of the 'shared' Event package parameter tells the 592 Appearance Agent that this UA supports this specification. 594 Upon initialization, the UA MUST subscribe to the dialog event 595 package of the AOR and refresh the subscription per the SIP Events 596 Framework. If the SUBSCRIBE request fails, then no Appearance Agent 597 may be present and this feature is not active for this AOR. The UA 598 MAY periodically retry the subscription to see if conditions have 599 changed at intervals no shorter than 4 hours. 601 Four hours was chosen to limit the subscription test to 6 per day 602 per UA. Increading this interval would reduce this failure 603 traffic but take longer for a newly activated Appearance Agent to 604 be discovered. 606 User Agents which implement the shared appearances feature and call 607 pickup, joining and bridging MUST support sending an INVITE with 608 Replaces [RFC3891] or Join [RFC3911]. The User Agent Client needs to 609 include the to-tag and from-tag information in the Replaces or Join 610 header so that the correct dialog will be matched by the User Agent 611 Server per the rules in RFC 3891 and RFC 3911. 613 All User Agents which implement the shared appearances feature and 614 support INVITE MUST support receiving an INVITE with a Replaces 615 [RFC3891] or a Join [RFC3911] header field. 617 When publishing or notifying dialog package information, a UA MUST 618 include all dialog identification available at the time of 619 publication, with the exception that a UA may omit information if it 620 wishes to prevent other UAs from joining or picking up a call. 621 Dialog identification includes local and remote target URIs, call-id, 622 to-tag, and from-tag. When calls are placed on hold, the 623 "+sip.rendering=no" feature tag MUST be included in dialog package 624 notifications. 626 The accurate rendering of the idle/active/alerting/hold state of 627 other UAs in the group is an important part of the shared 628 appearance feature. 630 In the following cases, before sending the INVITE, A UA MUST send a 631 dialog package PUBLISH request and wait for a 2xx response before 632 proceeding: 634 1. When the user seizes a particular appearance number for an 635 outgoing call (e.g. seizing the appearance and going "off-hook", 636 if the UA's user interface uses this metaphor). 637 2. When the user has requested that an appearance number not be used 638 for an outgoing call (i.e. during a consultation call, a 'service 639 media' call such as for music on hold 640 [I-D.worley-service-example] or for a call not considered part of 641 the shared appearance group). 642 3. When the user has selected to join (or bridge) an existing call. 643 4. When the user has selected to replace (or take) an existing call. 645 An exception is an emergency call, when a UA MUST never wait for a 646 confirmed seizure before sending an INVITE. Instead, the emergency 647 call MUST proceed without waiting for the PUBLISH transaction. 649 Note that when a UA seizes an appearance prior to establishment of a 650 dialog (#1 and #2 in above list), not all dialog information will be 651 available. In particular, when a UA publishes an attempt to seize an 652 appearance prior to knowing the destination URI, minimal or no dialog 653 information may be available. For example, in some cases, only the 654 local target URI for the call will be known and no dialog 655 information. If the From tag and Call-ID were not present in the 656 initial PUBLISH, a new PUBLISH MUST be sent as soon as this 657 information is available. 659 The first publication will cause the Appearance Agent to reserve 660 the appearance number for this UA. If the publication does not 661 have any dialog identifiers (e.g. Call-ID, or local tag) the 662 Appearance Agent cannot assign the appearance number to a 663 particular dialog of the UA until the second publication which 664 will contain some dialog identifiers. 666 This publication state is refreshed as described in [RFC3903] during 667 the early dialog state or the Appearance Agent may reassign the 668 appearance number. Once the dialog has transitioned to the confirmed 669 state, no publication refreshes are necessary. 671 This specification assumes that the Appearance Agent has other 672 means besides UA publication to learn about the state of UA 673 dialogs. In this specification, PUBLISH is used to indicate 674 desired and intended appearance number operations. Once a dialog 675 transitions from early to confirmed, this role is over, and hence 676 no publication refreshes are needed. 678 Appearance numbers are a shorthand label for active and pending 679 dialogs related to an AOR. Many of the features and services built 680 using this extension rely on the correct rendering of this 681 information to the human user. In addition, the group nature of the 682 feature means that the rendering must be similar between different 683 vendors and different models. Failure to do so will greatly reduce 684 the value and usefulness of these protocol extensions. The 685 appearances number for each active and pending dialog SHOULD be 686 explicitly (i.e. by appearance number) or implicitly (using a user 687 interface metaphor that makes the numbering and ordering clear to the 688 user) rendered to the user. The far end identity of each dialog 689 (e.g. the remote party identity) MUST NOT be rendered in place of the 690 appearance number. The state of each appearance SHOULD also be 691 rendered (idle, active, busy, joined, etc.). UAs can tell that a set 692 of dialogs are joined (bridged or mixed) together by the presence of 693 one or more elements containing other SIP dialog 694 identifiers. Appearance numbers of dialogs can be learned by dialog 695 package notifications containing the element from the 696 Appearance Agent or from the 'appearance' Alert-Info parameter in an 697 incoming INVITE. Should they conflict, the dialog package 698 notification takes precedence. 700 A UA that does not need to seize a particular appearance number (or 701 doesn't care) would just send an INVITE as normal to place an 702 outbound call. 704 A user may select an appearance number but then abandon placing a 705 call (go back on hook). In this case, the UA MUST free up the 706 appearance number by removing the event state with a PUBLISH as 707 described in [RFC3903]. 709 A UA SHOULD register against the AOR only if it is likely the UA will 710 be answering incoming calls. If the UA is mainly going to be 711 monitoring the status of the shared appearance group calls and 712 picking or joining calls, the UA SHOULD only subscribe to the AOR and 713 not register against the AOR. 715 All subscribed UAs will receive dialog package NOTIFYs of trying 716 state for incoming INVITEs. 718 A UA MUST NOT insert an 'appearance' parameter into an Alert-Info 719 header field in an INVITE or other request. 721 The Appearance Agent is solely responsible for doing this. 723 5.3.1. Appearance Numbers and Call Context 725 There are cases where two separate dialogs at a UA are not mixed but 726 share the same 'context'. That is, they relate to each other and 727 should not be treated the same as any other two dialogs within the 728 group. One example of this is a 'consultation call' where a user 729 puts an existing dialog on hold, then calls another user, before 730 switching back to the original dialog. Another case, described 731 below, occurs during transfer operations, where for a transient 732 period, a UA is involved in dialogs with two other UAs, but the 733 dialogs are related, and should not be treated as independent 734 dialogs. These cases are best handled by not assigning an appearance 735 number to a newly-created dialog when it shares a context with an 736 existing dialog. But if the pre-existing dialog is terminated, its 737 appearance number should be reassigned to the newly-created dialog. 739 A UA wanting to place a call but not have an appearance number 740 assigned publishes before sending the INVITE without an 'appearance' 741 element but with the 'shared' event package parameter present. If 742 the Appearance Agent policy does not allow calls without an assigned 743 appearance number, a 400 response is sent by the Appearance Agent and 744 the UA will republish either selecting/seizing an appearance number 745 or send the INVITE without publishing, in which case the Appearance 746 Agent will assign one. 748 Note that if an Appearance Agent rejects calls without an 749 appearance number, certain operations such as consultation calls, 750 transfer, and music on hold may be negatively impacted. 752 5.3.2. Appearance Numbers and Call Control 754 When an INVITE is generated to attempt to bridge or take a call (i.e. 755 contains Join or Replaces with a dialog identifier of another dialog 756 in the shared appearance group), the UA MUST first send a PUBLISH to 757 the Appearance Agent. This PUBLISH will contain: 759 1. The appearance number of the joined or replaced call in the 760 element 761 2. If the dialog is being joined, the element will 762 contain the dialog information from the Join header field 763 3. If the dialog is being replaced, the element 764 will contain the dialog information from the Replaces header 765 field 767 Note that this information is provided to the Appearance Agent so 768 that it can provide proper appearance assignment behavior. If the 769 INVITE Join or Replaces was sent without publishing first, the 770 Appearance Agent might assign a new appearance number to this 771 INVITE, which would be a mistake. With Join, the publication has 772 the element to prevent the Appearance Agent from 773 generating a 400 response due to the reuse of an appearance 774 number. For Replaces, the purpose of the is to 775 prevent a race condition where the BYE could cause the appearance 776 number to be released when it should stay with the replacing 777 dialog. 779 5.3.3. Appearance Numbers and Transfer 781 During a transfer operation, it is important that the appearance 782 number not change during the operation. Consider the example of 783 Alice, a member of an appearance group, who is talking to Carol, who 784 is outside the appearance group. Carol transfers Alice to David, who 785 is also outside the appearance group. For example, if Alice is using 786 appearance 3 for the session with Carol, the resulting session with 787 David should also use appearance number 3. Otherwise, an appearance 788 number change can cause a "jump" on the UI and confusion to the user. 789 There are two possible scenarios using the terminology of RFC 5589: 790 Alice is the transferee in any type of transfer (receives the REFER) 791 or the transfer target in an attended transfer (receives the INVITE 792 with Replaces). 794 If Alice is the transferee, the triggered INVITE from the REFER is 795 treated as a consultation call. Alice SHOULD publish requesting that 796 the Appearance Agent not assign an appearance number for this INVITE. 797 When the transfer completes, Alice SHOULD publish again to move the 798 appearance number from the dialog with Carol to the dialog with 799 David. Note that this publication MUST be sent prior to sending the 800 BYE to Carol to avoid a race condition where the Appearance Agent 801 reassigns the appearance number after seeing the BYE. 803 If Alice is the target, the incoming INVITE will contain a Replaces 804 header field. As a result, the Appearance Agent will have reused the 805 appearance number of the dialog with Carol, and this appearance 806 number will continue to be used after the dialog with Carol has been 807 terminated. 809 5.4. Appearance Agent 811 An Appearance Agent defined in this specification MUST implement a 812 dialog package state agent for the UAs registered against the AOR. 813 The Appearance Agent MUST support the appearance dialog package 814 extensions defined in Section 5.2. The Appearance Agent MUST support 815 publications and subscriptions for this event package. 817 The Appearance Agent MUST have a way of discovering the state of all 818 dialogs associated with the AOR. If this information is not 819 available from a call stateful proxy or B2BUA, the Appearance Agent 820 MAY use the registration event package [RFC3680] to learn of UAs 821 associated with the AOR and MAY subscribe to their dialog event 822 state. Also, an Appearance Agent MAY subscribe to a UAs dialog event 823 state in order to reconstruct state. As a result, the registrar MUST 824 support the registration event package. Dialog package notifications 825 are recommended by RFC 4235 to "only contain information on the 826 dialogs whose state or participation information has changed." This 827 specification extends RFC 4235 as follows. The Appearance Agent 828 SHOULD send dialog event state notifications whenever the following 829 events happen to UAs in the AOR group: 831 1. A call is received, placed, answered, or terminated. 832 2. A call is placed on or off hold. 833 3. A call is joined or replaced. 834 4. An appearance number is reserved or released. 836 The Appearance Agent MUST allocate an appearance number for all 837 incoming calls and send immediate notifications to the UAs subscribed 838 to the shared group AOR. A new appearance number is allocated except 839 for an incoming INVITE with a Join or Replaces header field. For 840 this case, the appearance number should match the appearance number 841 of the dialog being joined or replaced. If the INVITE Replaces or 842 Join comes from outside the appearance group, the Appearance Agent 843 will include a or element in the 844 NOTIFY containing the dialog information from the Replaces or Joined 845 header field. 847 The Appearance Agent MUST be able to communicate with the forking 848 proxy to learn about incoming calls and also to pass the appearance 849 number to the proxy to insert in the Alert-Info header field. 851 Note that UAs need to be able to handle incoming INVITEs without 852 an appearance number assigned. This could be caused by a failure 853 of the Appearance Agent or other error condition. Although the 854 proper rendering of the INVITE may not be possible, this is better 855 than ignoring or failing the INVITE. 857 An Appearance Agent SHOULD assign an appearance number to an outgoing 858 dialog if a PUBLISH has not been received selecting/seizing a 859 particular appearance number. 861 Note that if the appearance group has appearance-unaware UAs 862 making calls, the Appearance Agent will still allocate appearance 863 numbers for INVITEs sent by those UAs. 865 An Appearance Agent receiving a PUBLISH with an appearance number 866 checks to make sure the publication is valid. An appearance number 867 can be assigned to only one dialog unless there is a 868 or element indicating that the dialog will be/has 869 been replaced or joined. A 400 response is returned if the chosen 870 appearance number is invalid, and an immediate NOTIFY should be sent 871 to the UA containing full dialog event state. 873 An Appearance Agent receiving a PUBLISH without an appearance number 874 but with the 'shared' event package parameter present interprets this 875 as a request by the UA to not assign an appearance number. If the 876 Appearance Agent policy does not allow this, a 400 response is 877 returned. If policy does allow this, a 200 OK response is returned 878 and no appearance number is allocated. An Appearance Agent does not 879 have to share this dialog information (i.e. send a NOTIFY) with other 880 UAs in the group as the information will not be rendered by the other 881 UAs. 883 The Appearance Agent allocates an apperance number to a dialog from 884 the time the appearance is requested via a PUBLISH or from the 885 receipt of an INVITE, to the time when the last dialog associated 886 with the appearance is terminated, including all dialogs which are 887 joined or replaced. During the early dialog state, the Appearance 888 Agent controls the rate of dialog state publication using the Expires 889 header field in 200 OK responses to PUBLISH requests. An interval of 890 3 minutes is RECOMMENDED. After the dialog associated with the 891 publication has been confirmed, the expiration of the publication 892 state has no effect on the appearance allocation. If the publication 893 contains no dialog state information, the Appearance Agent MUST 894 reserve the appearance number for the UA but can not assign the 895 appearance to any particular dialog of the UA. When the publication 896 state is updated with any dialog information, the appearance number 897 can then be assigned to the particular dialog. A UA which has been 898 allocated an appearance number using a PUBLISH MAY free up the 899 appearance number by removing the event state with a PUBLISH as 900 described in [RFC3903]. 902 If an INVITE is sent by a member of the group to the shared AOR (i.e. 904 they call their own AOR), the Appearance Agent MUST assign two 905 appearance numbers. The first appearance number will be the one 906 selected or assigned to the outgoing INVITE. The second appearance 907 number will be another one assigned by the Appearance Agent for the 908 INVITE as it is forked back to the members of the group. 910 The is to preserve a common behavior in legacy systems. 912 If an INVITE is sent by a member of the group using the shared AOR or 913 sent to the shared AOR and no appearance number is available, the 914 proxy MAY reject the INVITE with a 403 Forbidden response code. 916 Appearance numbers are only used for dialogs in which one or more UAs 917 associated with the group AOR is a participant. If an incoming 918 INVITE to the group AOR is forwarded to another AOR, the appearance 919 number is immediately freed up and can be assigned to another dialog. 921 6. XML Schema Definition 923 The 'appearance', 'joined-dialog', 'replaced-dialog', and 'exclusive' 924 elements are defined within a new XML namespace URI. This namespace 925 is "urn:ietf:params:xml:ns:sa-dialog-info". The schema for these 926 elements is: 928 929 935 937 938 940 942 944 945 947 949 950 952 954 956 957 959 960 961 962 964 965 966 967 968 970 7. Alert-Info Appearance Parameter Definition 972 This specification extends RFC 3261 [RFC3261] to add an 'appearance' 973 parameter to the Alert-Info header field, and to also allow proxies 974 to modify or delete the Alert-Info header field. 976 The changes to RFC 3261 ABNF are: 978 alert-param = LAQUOT absoluteURI RAQUOT *( SEMI 979 (generic-param / appearance-param) ) 980 appearance-param = "appearance" EQUAL 1*DIGIT 982 A proxy inserting an 'appearance' Alert-Info parameter follows normal 983 Alert-Info policies. To indicate the appearance number for this 984 dialog, the proxy adds the Alert-Info header field with the 985 'appearance' parameter to the INVITE. If an Alert-Info is already 986 present, the proxy adds the 'appearance' parameter to the Alert-Info 987 header field. If an appearance number parameter is already present 988 (associated with another AOR or by mistake), the value is rewritten 989 adding the new appearance number. There MUST NOT be more than one 990 appearance parameter in an Alert-Info header field. 992 If no special ringtone is desired, a normal ringtone should be 993 indicated using the urn:alert:service:normal in the Alert-Info, as 994 per [I-D.ietf-salud-alert-info-urns]. The appearance number present 995 in an Alert-Info header field SHOULD be rendered by the UA to the 996 user, following the guidelines in Section 5.3. If the INVITE is 997 forwarded to another AOR, the appearance parameter in the Alert-Info 998 SHOULD be removed before forwarding outside the group. 1000 The determination as to what value to use in the appearance parameter 1001 can be done at the proxy that forks the incoming request to all the 1002 registered UAs. 1004 There are a variety of ways the proxy can use to determine what 1005 value it should use to populate this parameter. For example, the 1006 proxy could fetch this information by initiating a SUBSCRIBE 1007 request with Expires: 0 to the Appearance Agent for the AOR to 1008 fetch the list of lines that are in use. Alternatively, it could 1009 act like a UA that is a part of the appearance group and SUBSCRIBE 1010 to the State-Agent like any other UA. This would ensure that the 1011 active dialog information is available without having to poll on a 1012 need basis. It could keep track of the list of active calls for 1013 the appearance AOR based on how many unique INVITE requests it has 1014 forked to or received from the appearance AOR. Another approach 1015 would be for the Proxy to first send the incoming INVITE to the 1016 Appearance Agent which would redirect to the appearance group URI 1017 and escape the proper Alert-Info header field for the Proxy to 1018 recurse and distribute to the other UAs in the group. 1019 The Appearance Agent needs to know about all incoming requests to 1020 the AOR in order to seize the appearance number. One way in which 1021 this could be done is for the Appearance Agent to register against 1022 the AOR with a higher q value. This will result in the INVITE 1023 being sent to the Appearance Agent first, then being offered to 1024 the UAs in the group. 1026 8. User Interface Considerations 1028 The "appearance number" allocated to a call is an important concept 1029 that enables calls to be handled by multiple devices with 1030 heterogeneous user interfaces in a manner that still allows users to 1031 see a consistent model. Careful treatment of the appearance number 1032 is essential to meet the expectations of the users. Also, rendering 1033 the correct call/appearance state to users is also important. 1035 8.1. Appearance Number Rendering 1037 Since different UAs have different user interface capabilities, it is 1038 usual to find that some UAs have restrictions that others do not. 1039 Perfect interoperability across all UAs is clearly not possible, but 1040 by careful design, interoperability up to the limits of each UA can 1041 be achieved. 1043 The following guidelines suggest how the appearance number should be 1044 handled in three typical user interface implementations. 1046 8.1.1. Single Appearance UAs 1048 These devices are constrained by only having the capability of 1049 displaying status indications for a single appearance. The UA should 1050 still send messages annotated with appearance number "1". Any call 1051 indications for appearances other than for number "1" should be 1052 rejected with a 486 or 480 response. 1054 8.1.2. Dual Appearance UAs 1056 These devices are essentially single appearance phones that implement 1057 call waiting. They have a very simple user interface that allows 1058 them to switch between two appearances (toggle or flash hook) and 1059 perhaps audible tones to indicate the status of the other appearance. 1060 Only appearance numbers "1" and "2" will be used by these UAs. 1062 8.1.3. Shared Appearance UAs with Fixed Appearance Number 1064 This UA is the typical 'business-class' hard-phone. A number of 1065 appearances are typically configured statically and labeled on 1066 buttons, and calls may be managed using these configured appearances. 1067 Any calls outside this range should be rejected, and not mapped to a 1068 free button. Users of these devices often seize specific appearance 1069 numbers for outgoing calls, and the UA will need to seize the 1070 appearance number and wait for confirmation from the Appearance Agent 1071 before proceeding with calls. 1073 8.1.4. Shared Appearance UAs with Variable Appearance Number 1075 This UA is typically a soft-phone or graphically rich user interface 1076 hard-phone. In these cases, even the idea of an appearance index may 1077 seem unnecessary. However, for these phones to be able to interwork 1078 successfully with other phone types, it is important that they still 1079 use the appearance index to govern the order of appearance of calls 1080 in progress. No specific guidance on presentation is given except 1081 that the order should be consistent. These devices can typically 1082 make calls without waiting for confirmation from the Appearance Agent 1083 on the appearance number. 1085 8.1.5. Example User Interface Issues 1087 The problems faced by each style of user interface are readily seen 1088 in this example: 1090 1. A call arrives at the shared appearance group, and is assigned an 1091 appearance number of "1". All UAs should be able to render to 1092 the user the arrival of this call. 1093 2. Another call arrives at the shared appearance group, and is 1094 assigned an appearance number of "2". The single appearance UA 1095 should not present this call to the user. Other user agents 1096 should have no problems presenting this call distinctly from the 1097 first call. 1098 3. The first call clears, releasing appearance number "1". The 1099 single appearance UA should now be indicating no calls since it 1100 is unable to manage calls other than on the first appearance. 1101 Both shared appearance UAs should clearly show that appearance 1102 number "1" is now free, but that there is still a call on 1103 appearance number "2". 1104 4. A third call arrives, and is assigned the appearance number of 1105 "1". All UAs should be able to render the arrival of this new 1106 call to the user. Multiple appearance UAs should continue to 1107 indicate the presence of the second call, and should also ensure 1108 that the presentation order is related to the appearance number 1109 and not the order of call arrival. 1111 8.2. Call State Rendering 1113 UAs that implement the shared appearance feature typically have a 1114 user interface that provides the state of other appearances in the 1115 group. As dialog state NOTIFYs from the Appearance Agent are 1116 processed, this information can be rendered. Even the simplest user 1117 interface typically has three states: idle, active, and hold. The 1118 idle state, usually indicated by lamp off, is indicated for an 1119 appearance when the appearance number is not associated with any 1120 dialogs, as reported by the Appearance Agent. The active state, 1121 usually indicated by a lamp on, is indicated by an appearance number 1122 being associated with at least one dialog, as reported by the 1123 Appearance Agent. The hold state, often indicated by a blinking 1124 lamp, means the call state from the perspective of the UA in the 1125 shared appearance group is hold. This can be determined by the 1126 presence of the "+sip.rendering=no" feature tag [RFC3840] with the 1127 local target URI. Note that the hold state of the remote target URI 1128 is not relevant to this display. For joined dialogs, the state is 1129 rendered as hold only if all local target URIs are indicated with the 1130 "+sip.rendering=no" feature tag. 1132 9. Interoperability with non-Shared Appearance UAs 1134 It is desirable to allow a basic UA that does not directly support 1135 shared appearance to be part of a shared appearance group. To 1136 support this the Proxy must collaborate with the Appearance Agent. 1137 This is not required in the basic shared appearance architecture, 1138 consequently shared appearance interoperability with non-shared 1139 appearance UAs will not be available in all shared appearance 1140 deployments. 1142 First, a UA which does not support dialog events or the shared 1143 appearance feature will be discussed. Then, a UA which does support 1144 dialog events but not the shared appearance feature will be 1145 discussed. 1147 9.1. Appearance Assignment 1149 A UA that has no knowledge of appearances must will only have 1150 appearance numbers for outgoing calls if assigned by the Appearance 1151 Agent. If the non-shared appearance UA does not support Join or 1152 Replaces, all dialogs could be marked "exclusive" to indicate that 1153 these options are not available. 1155 9.2. Appearance Release 1157 In all cases the Appearance Agent must be aware of dialog lifetime to 1158 release appearances back into the group. 1160 It is also desirable that any dialog state changes (such as hold, 1161 etc) be made available to other UAs in the group through the Dialog 1162 Event Package. If the Appearance Agent includes a proxy which 1163 Record-Routes for dialogs from the non-shared appearance aware UA, 1164 the Appearance Agent will know about the state of dialogs including 1165 hold, etc. This information could be determined from inspection of 1166 non-end-to-end-encrypted INVITE and re-INVITE messages and added to 1167 the dialog information conveyed to other UAs. 1169 9.3. UAs Supporting Dialog Events but Not Shared Appearance 1171 Interoperability with UAs which support dialog events but not the 1172 shared appearance feature is more straightforward. As before, all 1173 appearance number assignment must be done by the Appearance Agent. 1174 The Appearance Agent can include appearance information in NOTIFYs - 1175 this UA will simply ignore this extra information. This type of UA 1176 will ignore appearance number limitations and may attempt to Join or 1177 Replace dialogs marked exclusive. As a result, the Proxy or UAs need 1178 to reject such requests or the dialogs will get joined or taken. 1180 10. Provisioning Considerations 1182 UAs can automatically discover if this feature is active for an AOR 1183 by looking for the 'shared' Event header parameter in a response to a 1184 dialog package SUBSCRIBE to the AOR, so no provisioning for this is 1185 needed. 1187 The registrar will need to be provisioned to accept either first or 1188 third party registrations for the shared AOR. First party 1189 registration means the To and From URIs in the REGISTER request are 1190 the shared AOR URI. Third party registration means the To URI is the 1191 shared AOR URI and the From URI is a different AOR, perhaps that of 1192 the individual user. Either the credentials of the shared AOR or the 1193 user MUST be accepted by the registrar and the Appearance Agent, 1194 depending on the authorization policy in place for the domain. 1196 If the Appearance Agent needs to subscribe to the dialog state of the 1197 UAs, then the Appearance Agent and the UAs need to be provisioned 1198 with credentials so the UAs can authenticate the Appearance Agent. 1200 In some cases, UAs in the shared appearance group might have a UI 1201 limitation on the number of appearances that can be rendered. 1203 Typically this will be hard phones with buttons/lamps instead of more 1204 flexible UIs. In this case, it can be useful for the Appearance 1205 Agent to know this maximum number. This can allow the Appearance 1206 Agent to apply policy when this limit is reached, e.g. deny a call. 1207 However, this mechanism does not provide any way to discover this by 1208 protocol means. 1210 11. Example Message Flows 1212 The next section shows call flow and message examples. The flows and 1213 descriptions are non-normative. Note that in these examples, all 1214 INVITEs sent by a UA in the group will be From the shared AOR 1215 (sip:HelpDesk@example.com in this case), and all INVITES sent to the 1216 group will have a Request-URI of the shared AOR. Any other requests 1217 would not apply to this feature and would be handled using normal SIP 1218 mechanisms. 1220 Note that the first twelve examples assume the Appearance Agent is 1221 aware of dialog state events. The example in Section 11.13 shows the 1222 case where this is not the case and as a result the Appearance Agent 1223 initiates a subscription to users of the shared AOR. Any of the 1224 other call flow examples could have shown this mode of operation as 1225 it is equally valid. 1227 11.1. Registration and Subscription 1229 Bob and Alice are in an appearance group identified by the shared 1230 appearance AOR sip:HelpDesk@example.com. Bob REGISTERs using contact 1231 sip:bob@ua2.example.com. Alice REGISTERs with contact 1232 sip:alice@ua1.example.com. 1234 User Agents for Alice and Bob subscribe to the dialog package for the 1235 appearance AOR and publish dialog state to the Appearance Agent. 1236 Message exchanges between the Registrar, Appearance Agent, Alice, and 1237 Bob are shown below. The call flow examples below do not show the 1238 authentication of subscriptions, publications, and notifications. It 1239 should be noted that for security purposes, all publications and 1240 subscriptions must be authorized before the SUBSCRIBE is accepted. 1242 Also note that registrations and subscriptions must all be refreshed 1243 by Alice at intervals determined by the expiration intervals returned 1244 by the Registrar or Appearance Agent. 1246 Registrar Appearance Agent Alice Bob 1247 | | | | 1248 | | | | 1249 |<--------------------------- REGISTER F1<| | 1250 | | | | 1251 |>F2 200 OK ----------------------------->| | 1252 | | | | 1253 | |<----- SUBSCRIBE F3<| | 1254 | | | | 1255 | |>F4 200 OK -------->| | 1256 | | | | 1257 | |>F5 NOTIFY -------->| | 1258 | | | | 1259 | |<-------- 200 OK F6<| | 1260 | | | | 1261 |<-------------------------------------------- REGISTER F7<| 1262 | | | | 1263 |>F8 200 OK ---------------------------------------------->| 1264 | | | | 1265 | |<---------------------- SUBSCRIBE F9<| 1266 | | | | 1267 | |>F10 200 OK ------------------------>| 1268 | | | | 1269 | |>F11 NOTIFY ------------------------>| 1270 | | | | 1271 | |<------------------------ 200 OK F12<| 1272 | | | | 1274 Figure 1. 1276 F1-F2: Alice registers AOR with 1277 contact: 1279 F1 Alice ----> Registrar 1281 REGISTER sip:registrar.example.com SIP/2.0 1282 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09 1283 From: ;tag=CDF9A668-909E2BDD 1284 To: 1285 CSeq: 2 REGISTER 1286 Call-ID: d3281184-518783de-cc23d6bb 1287 Contact: 1288 Max-Forwards: 70 1289 Expires: 3600 1290 Content-Length: 0 1292 F2 Registrar ----> Alice 1294 SIP/2.0 200 OK 1295 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09 1296 CSeq: 2 REGISTER 1297 Call-ID: d3281184-518783de-cc23d6bb 1298 From: ;tag=CDF9A668-909E2BDD 1299 To: ;tag=1664573879820199 1300 Contact: ;expires=3600 1301 Content-Length: 0 1303 F3 to F6: Alice also subscribes to the events associated with the 1304 Appearance AOR. Appearance Agent notifies Alice of the status. 1306 F3 Alice ----> Appearance Agent 1308 SUBSCRIBE sip:HelpDesk@example.com SIP/2.0 1309 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A 1310 From: ;tag=925A3CAD-CEBB276E 1311 To: 1312 CSeq: 91 SUBSCRIBE 1313 Call-ID: ef4704d9-bb68aa0b-474c9d94 1314 Contact: 1315 Event: dialog;shared 1316 Accept: application/dialog-info+xml 1317 Max-Forwards: 70 1318 Expires: 3700 1319 Content-Length: 0 1321 F4 Appearance Agent ----> Alice 1323 SIP/2.0 200 OK 1324 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A 1325 CSeq: 91 SUBSCRIBE 1326 Call-ID: ef4704d9-bb68aa0b-474c9d94 1327 From: ;tag=925A3CAD-CEBB276E 1328 To: ;tag=1636248422222257 1329 Allow-Events: dialog 1330 Expires: 3700 1331 Contact: 1332 Content-Length: 0 1334 F5 Appearance Agent ----> Alice 1336 NOTIFY sip:alice@ua1.example.com SIP/2.0 1337 From: ;tag=1636248422222257 1338 To: ;tag=925A3CAD-CEBB276E 1339 Call-ID: ef4704d9-bb68aa0b-474c9d94 1340 CSeq: 232 NOTIFY 1341 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1846 1342 Max-Forwards: 70 1343 Content-Type: application/dialog-info+xml 1344 Event: dialog;shared 1345 Subscription-State: active;expires=3000 1346 Contact: 1347 Content-Length: ... 1349 1350 1354 1356 F6 Alice ----> Appearance Agent 1358 SIP/2.0 200 OK 1359 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1846 1360 From: ;tag=1636248422222257 1361 To: ;tag=925A3CAD-CEBB276E 1362 CSeq: 232 NOTIFY 1363 Call-ID: ef4704d9-bb68aa0b-474c9d94 1364 Contact: 1365 Content-Length: 0 1367 F7 Bob ----> Registrar 1369 REGISTER sip:registrar.example.com SIP/2.0 1370 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4b53b54d87B 1371 From: ;tag=34831131 1372 To: 1373 CSeq: 72 REGISTER 1374 Call-ID: 139490230230249348 1375 Contact: 1376 Max-Forwards: 70 1377 Expires: 3600 1378 Content-Length: 0 1380 F8 Registrar ----> Bob 1382 SIP/2.0 200 OK 1383 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4b53b54d87B 1384 From: ;tag=34831131 1385 To: ;tag=fkwlwqi1 1386 CSeq: 72 REGISTER 1387 Call-ID: 139490230230249348 1388 Contact: ;expires=3200 1389 Contact: ;expires=3600 1390 Content-Length: 0 1392 11.2. Appearance Selection for Incoming Call 1394 In the call flow below Bob and Alice are in an appearance group. 1395 Carol places a call to the appearance group AOR. The Appearance 1396 Agent sends NOTIFYs to Alice and Bob telling them what appearance the 1397 call is using. Both Alice and Bob's devices are alerted of the 1398 incoming call. Bob answers the call. 1400 Note that it is possible that both Alice and Bob answer the call and 1401 send 200 OK responses to Carol. It is up to Carol to resolve this 1402 situation. Typically, Carol will send ACKs to both 200 OKs but send 1403 a BYE to terminate one of the dialogs. As a result, either Alice or 1404 Bob will receive the BYE and publish that their dialog is over. 1405 However, if Carol answers both Alice and Bob and keeps both dialogs 1406 active, then the Appearance Agent will need to resolve the situation 1407 by moving either Alice or Bob's dialog to a different appearance. 1409 All NOTIFY messages in the call flow below carry dialog events and 1410 only dialog states are mentioned for simplicity. For brevity, the 1411 details of some messages are not shown below. Note that the order of 1412 F2 - F5 and F7 - F8 could be reversed. 1414 Forking Appearance 1415 Carol Proxy Agent Alice Bob 1416 | | | | | 1417 |>F1 INVITE >| | | | 1418 | |< - - - - - >| | | 1419 | | |>F2 NOTIFY ----------->| 1420 | | | | | 1421 | | |F4 NOTIFY ->| | 1424 | | | | | 1425 | | |<-200 OK F5-<| | 1426 |<- 100 F6 -<| | | | 1427 | |>F7 INVITE (appearance=1) ---------->| 1428 | | | | | 1429 | |>F8 INVITE (appearance=1) >| | 1430 | | | | | 1431 | |<-------------------- Ringing 180 F9<| 1432 |< 180 F10 -<| | | | 1433 | |<--------- 180 Ringing F11<| | 1434 |< 180 F12 -<| | | | 1435 | | | | | 1436 | |<------------------------ 200 OK F13<| 1437 |< 200 F14 -<| | | | 1438 | | | | | 1439 | |>F15 CANCEL -------------->| | 1440 | | | | | 1441 | |<-------------- 200 OK F16<| | 1442 | | | | | 1443 | |F18 ACK ----------------->| | 1446 |>F19 ACK -->| | | | 1447 | |>F20 ACK --------------------------->| 1448 | | | | | 1449 |<=============Both way RTP established===========>| 1450 | | | | | 1451 | |< - - - - - >| | | 1452 | | | | | 1453 | | |>F21 NOTIFY >| | 1454 | | | | | 1455 | | |<- 200 F22 -<| | 1456 | | | | | 1457 | | |>F23 NOTIFY ---------->| 1458 | | | | | 1459 | | | Alice 1466 NOTIFY sip:alice@ua1.example.com SIP/2.0 1467 From: ;tag=151702541050937 1468 To: ;tag=18433323-C3D237CE 1469 Call-ID: 1e361d2f-a9f51109-bafe31d4 1470 CSeq: 12 NOTIFY 1471 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1403 1472 Max-Forwards: 70 1473 Content-Type: application/dialog-info+xml 1474 Event: dialog;shared 1475 Subscription-State: active;expires=2800 1476 Contact: 1477 Content-Length: ... 1479 1480 1485 1489 1 1490 trying 1491 1492 sip:carol@ua.example.com 1493 1494 1495 1497 F7 Proxy ----> Bob 1499 INVITE sip:bob@ua2.example.com SIP/2.0 1500 Via: SIP/2.0/UDP ua3.example.com;branch=z9hG4bK4324ea 1501 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK38432ji 1502 From: ;tag=44BAD75D-E3128D42 1503 To: 1504 CSeq: 106 INVITE 1505 Call-ID: 14-1541707345 1506 Contact: 1507 Max-Forwards: 69 1508 Alert-Info: ;appearance=1 1509 Content-Type: application/sdp 1510 Content-Length: ... 1512 v=0 1513 o=- 1102980499 1102980499 IN IP4 ua3.example.com 1514 s= 1515 c=IN IP4 ua3.example.com 1516 t=0 0 1517 m=audio 2238 RTP/AVP 0 8 101 1518 a=rtpmap:0 PCMU/8000 1519 a=rtpmap:8 PCMA/8000 1520 a=rtpmap:101 telephone-event/8000 1522 F21 Appearance Agent ----> Alice 1524 NOTIFY sip:alice@ua1.example.com SIP/2.0 1525 From: ;tag=151702541050937 1526 To: ;tag=18433323-C3D237CE 1527 Call-ID: 1e361d2f-a9f51109-bafe31d4 1528 CSeq: 13 NOTIFY 1529 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK4164F03j 1530 Max-Forwards: 70 1531 Content-Type: application/dialog-info+xml 1532 Event: dialog;shared 1533 Subscription-State: active;expires=2500 1534 Contact: 1535 Content-Length: ... 1537 1538 1543 1548 1 1549 confirmed 1550 1551 sip:bob@ua2.example.com 1552 1553 1554 sip:carol@ua.example.com 1555 1556 1557 1559 11.3. Outgoing Call without Appearance Seizure 1561 In this scenario, Bob's UA places a call without first selecting/ 1562 seizing an appearance number. After Bob sends the INVITE, the 1563 appearance assigns an appearance number for it and notifies both 1564 Alice and Bob. 1566 Carol Proxy Alice Appearance Agent Bob 1567 | | | | | 1568 | | | | | 1569 | |<------------------------------------- INVITE F1<| 1570 | | | | | 1571 | |>F2 100 Trying --------------------------------->| 1572 |<-- INVITE F3<| | | | 1573 | |< - - - - - - - - - - - - - ->| | 1574 | | | | | 1575 | | |<-- NOTIFY F4<| | 1576 | | | | | 1577 | | |>F5 200 OK -->| | 1578 | | | |------- NOTIFY F6>| 1579 | | | | | 1580 | | | |F8 180 ---->| | | | 1582 | |>F9 180 Ringing -------------------------------->| 1583 | | | | | 1584 | |< - - - - - - - - - - - - - ->| | 1585 | | | | | 1586 | | |<- NOTIFY F10<| | 1587 | | | | | 1588 | | |>F11 200 OK ->| | 1589 | | | |------ NOTIFY F12>| 1590 | | | | | 1591 | | | |F14 200 OK ->| | | | 1593 | |>F15 200 OK ------------------------------------>| 1594 | | | | | 1595 | |<--------------------------------------- ACK F16<| 1596 |<---- ACK F17<| | | | 1597 | | | | | 1598 |<================= Both way RTP established ===================>| 1599 | | | | | 1600 | |< - - - - - - - - - - - - - ->| | 1601 | | | | | 1602 | | |<- NOTIFY F18<| | 1603 | | | | | 1604 | | |>F19 200 OK ->| | 1605 | | | |------ NOTIFY F20>| 1606 | | | | | 1607 | | | | Proxy 1614 INVITE sip:carol@example.com SIP/2.0 1615 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK98c87c52123A08BF 1616 From: ;tag=15A3DE7C-9283203B 1617 To: 1618 CSeq: 1 INVITE 1619 Call-ID: f3b3cbd0-a2c5775e-5df9f8d5 1620 Contact: 1621 Max-Forwards: 70 1622 Content-Type: application/sdp 1623 Content-Length: 223 1625 v=0 1626 o=- 1102980499 1102980499 IN IP4 ua2.example.com 1627 s=IP SIP UA 1628 c=IN IP4 ua2.example.com 1629 t=0 0 1630 a=sendrecv 1631 m=audio 2236 RTP/AVP 0 8 101 1632 a=rtpmap:0 PCMU/8000 1633 a=rtpmap:8 PCMA/8000 1634 a=rtpmap:101 telephone-event/8000 1636 F4 Appearance Agent ----> Alice 1638 NOTIFY sip:alice@ua1.example.com SIP/2.0 1639 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK81d84f62 1640 From: ;tag=1636248422222257 1641 To: ;tag=925A3CAD-CEBB276E 1642 Call-ID: ef4704d9-bb68aa0b-474c9d94 1643 CSeq: 233 NOTIFY 1644 Max-Forwards: 70 1645 Content-Type: application/dialog-info+xml 1646 Event: dialog;shared 1647 Subscription-State: active;expires=2200 1648 Contact: 1649 Content-Length: ... 1651 1652 1657 1660 1 1661 false 1662 trying 1663 1664 1665 1666 1667 1668 1670 F6 Appearance Agent ----> Bob 1672 NOTIFY sip:bob@ua1.example.com SIP/2.0 1673 From: ;tag=497585728578386 1674 To: ;tag=633618CF-B9C2EDA4 1675 Call-ID: a7d559db-d6d7dcad-311c9e3a 1676 CSeq: 7 NOTIFY 1677 Via: SIP/2.0/UDP appearanceagent.example.com 1678 ;branch=z9hG4bK1711759878512309 1679 Max-Forwards: 70 1680 Content-Type: application/dialog-info+xml 1681 Event: dialog;shared 1682 Subscription-State: active;expires=2000 1683 Contact: 1684 Content-Length: ... 1686 1687 1692 1695 1 1696 false 1697 trying 1698 1699 1700 1701 1702 1703 1705 11.4. Outgoing Call with Appearance Seizure 1707 In this scenario, Bob's UA sends out a dialog event PUBLISH with 1708 state (trying) selecting/seizing an appearance number before sending 1709 the INVITE. After receiving the 200 OK from the Appearance Agent 1710 confirming the appearance number, Bob's UA sends the INVITE to Carol 1711 and establishes a session. For brevity, details of some of the 1712 messages are not included in the message flows. Bob's UA puts as 1713 much of the dialog information from F7 as can be determined in 1714 advance. In this case, the minimum of the Contact URI is included 1715 which allows the Appearance Agent to correlate the INVITE with the 1716 PUBLISH. 1718 Carol Proxy Alice Appearance Agent Bob 1719 | | | | | 1720 | | | |<----- PUBLISH F1<| 1721 | | | | | 1722 | | | |>F2 200 OK ------>| 1723 | | | | | 1724 | | |<-- NOTIFY F3<| | 1725 | | | | | 1726 | | |>F4 200 OK -->| | 1727 | | | |------- NOTIFY F5>| 1728 | | | | | 1729 | | | |F8 100 Trying --------------------------------->| 1734 |<-- INVITE F9<| | | | 1735 | | | |<---- PUBLISH F10<| 1736 | | | | | 1737 | | | |>F11 200 OK ----->| 1738 | | | | | 1739 |>F12 180 --->| | | | 1740 | |>F13 180 Ringing ------------------------------->| 1741 | | | | | 1742 | |< - - - - - - - - - - - - - ->| | 1743 | | | | | 1744 | | |<- NOTIFY F14<| | 1745 | | | | | 1746 | | |>F15 200 OK ->| | 1747 | | | |------ NOTIFY F16>| 1748 | | | | | 1749 | | | |F18 200 OK ->| | | | 1751 | |>F19 200 OK ------------------------------------>| 1752 | | | | | 1753 | |<--------------------------------------- ACK F20<| 1754 |<---- ACK F21<| | | | 1755 | | | | | 1756 |<================= Both way RTP established ===================>| 1757 | | | | | 1758 | |< - - - - - - - - - - - - - ->| | 1759 | | | | | 1760 | | |<- NOTIFY F22<| | 1761 | | | | | 1762 | | |>F23 200 OK ->| | 1763 | | | |------ NOTIFY F24>| 1764 | | | | | 1765 | | | | Appearance Agent 1778 PUBLISH sip:HelpDesk@example.com SIP/2.0 1779 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 1780 From: ;tag=44150CC6-A7B7919D 1781 To: 1782 CSeq: 7 PUBLISH 1783 Call-ID: 44fwF144-F12893K38424 1784 Contact: 1785 Event: dialog;shared 1786 Max-Forwards: 70 1787 Content-Type: application/dialog-info+xml 1788 Content-Length: ... 1790 1791 1796 1797 1 1798 false 1799 trying 1800 1801 1802 1803 1804 1805 1806 F2 Appearance Agent ----> Bob 1808 SIP/2.0 200 OK 1809 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 1810 From: ;tag=44150CC6-A7B7919D 1811 To: 1812 CSeq: 7 PUBLISH 1813 Call-ID: 44fwF144-F12893K38424 1814 Contact: 1815 Event: dialog;shared 1816 SIP-Etag: 482943245 1817 Allow-Events: dialog 1818 Expires: 60 1819 Content-Length: 0 1821 F7 Bob ---> Proxy 1823 INVITE sip:carol@example.com SIP/2.0 1824 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK342122 1825 Max-Forwards: 70 1826 From: ;tag=15A3DE7C-9283203B 1827 To: 1828 Call-ID: f3b3cbd0-a2c5775e-5df9f8d5 1829 CSeq: 31 INVITE 1830 Contact: 1831 Content-Type: application/sdp 1832 Content-Length: ... 1834 (SDP Not Shown) 1836 F10 Bob ----> Appearance Agent 1838 PUBLISH sip:HelpDesk@example.com SIP/2.0 1839 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK6d644638E7 1840 From: ;tag=0CCf6-A7FdsB79D 1841 To: 1842 CSeq: 437 PUBLISH 1843 Call-ID: fwF14d4-F1FFF2F2893K38424 1844 Contact: 1845 Event: dialog;shared 1846 Max-Forwards: 70 1847 Content-Type: application/dialog-info+xml 1848 Content-Length: ... 1850 1851 1856 1860 1 1861 false 1862 trying 1863 1864 1865 1866 1867 1868 1869 1870 1871 1872 1874 11.5. Outgoing Call without using an Appearance Number 1876 In this scenario, Bob's UA sends out a dialog event PUBLISH with 1877 state (trying) indicating that he does not want to utilize an 1878 appearance number for this dialog. The PUBLISH does not have an 1879 appearance element but does have the 'shared' dialog event parameter. 1880 As a result, the Appearance Agent knows the UA does not wish to use 1881 an appearance number for this call. If the Appearance Agent does not 1882 wish to allow this, it would reject the PUBLISH with a 400 response 1883 and the UA would know to re-PUBLISH selecting/seizing an appearance 1884 number. 1886 Carol Proxy Alice Appearance Agent Bob 1887 | | | | | 1888 | | | |<----- PUBLISH F1<| 1889 | | | | | 1890 | | | |>F2 200 OK ------>| 1891 | | | | | 1892 | | |<-- NOTIFY F3<| | 1893 | | | | | 1894 | | |>F4 200 OK -->| | 1895 | | | |------- NOTIFY F5>| 1896 | | | | | 1897 | | | |F8 100 Trying --------------------------------->| 1902 |<-- INVITE F9<| | | | 1903 | | | |<---- PUBLISH F10<| 1904 | | | | | 1905 | | | |>F11 200 OK ----->| 1906 | | | | | 1907 |>F12 180 --->| | | | 1908 | |>F13 180 Ringing ------------------------------->| 1909 | | | | | 1910 | |< - - - - - - - - - - - - - ->| | 1911 | | | | | 1912 | | |<- NOTIFY F14<| | 1913 | | | | | 1914 | | |>F15 200 OK ->| | 1915 | | | |------ NOTIFY F16>| 1916 | | | | | 1917 | | | |F18 200 OK ->| | | | 1919 | |>F19 200 OK ------------------------------------>| 1920 | | | | | 1921 | |<--------------------------------------- ACK F20<| 1922 |<---- ACK F21<| | | | 1923 | | | | | 1924 |<================= Both way RTP established ===================>| 1925 | | | | | 1926 | |< - - - - - - - - - - - - - ->| | 1927 | | | | | 1928 | | |<- NOTIFY F22<| | 1929 | | | | | 1930 | | |>F23 200 OK ->| | 1931 | | | |------ NOTIFY F24>| 1932 | | | | | 1933 | | | | Appearance Agent 1940 PUBLISH sip:appearanceagent.example.com SIP/2.0 1941 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 1942 From: ;tag=4415df82k39sf 1943 To: 1944 CSeq: 7 PUBLISH 1945 Call-ID: 44fwF144-F12893K38424 1946 Contact: 1947 Event: dialog;shared 1948 Max-Forwards: 70 1949 Content-Type: application/dialog-info+xml 1950 Content-Length: ... 1952 1953 1958 1959 false 1960 trying 1961 1962 1963 1964 1965 1966 1968 Note that F7 would be the same as the previous example. 1970 11.6. Appearance Release 1972 Bob and Carol are in a dialog, created, for example as in 1973 Section 11.3. Carol sends a BYE to Bob to terminate the dialog and 1974 the Appearance Agent de-allocates the appearance number used, sending 1975 notifications out to the UAs in the shared group. 1977 Carol Proxy Alice Appearance Agent Bob 1978 | | | | | 1979 | | | | | 1980 |<================= Both way RTP established ===================>| 1981 | | | | | 1982 |>F22 BYE ---->| | | | 1983 | |>F23 BYE --------------------------------------->| 1984 | | | | | 1985 | |<------------------------------------ 200 OK F24<| 1986 |<--200 OK F25<| | | | 1987 | |< - - - - - - - - - - - - - ->| | 1988 | | | | | 1989 | | |<- NOTIFY F26<| | 1990 | | | | | 1991 | | |>F27 200 OK ->| | 1992 | | | |------ NOTIFY F28>| 1993 | | | | | 1994 | | | | Bob 1999 NOTIFY sip:bob@ua1.example.com SIP/2.0 2000 From: ;tag=497585728578386 2001 To: 2002 Call-ID: a7d559db-d6d7dcad-311c9e3a 2003 CSeq: 7 NOTIFY 2004 Via: SIP/2.0/UDP appearanceagent.example.com 2005 ;branch=z9hG4bK759878512309 2006 Max-Forwards: 70 2007 Content-Type: application/dialog-info+xml 2008 Event: dialog;shared 2009 Subscription-State: active;expires=1800 2010 Contact: 2011 Content-Length: ... 2013 2014 2019 2024 1 2025 false 2026 terminated 2027 2028 2029 2030 2031 2032 2034 11.7. Appearance Pickup 2036 In this scenario, Bob has an established dialog with Carol created 2037 using the call flows of Figure 1 or Figure 2. Bob then places Carol 2038 on hold. Alice receives a notification of this and renders this on 2039 Alice's UI. Alice subsequently picks up the held call and has a 2040 established session with Carol. Finally, Carol hangs up. Alice must 2041 PUBLISH F32 to indicate that the INVITE F38 will be an attempt to 2042 pickup the dialog between Carol and Bob, and hence may use the same 2043 appearance number. 2045 Carol Proxy Alice Appearance Agent Bob 2046 | | | | | 2047 |<================= Both way RTP established ===================>| 2048 | | | | | 2049 | |<------------------------------(hold) INVITE F22<| 2050 |<- INVITE F23<| | | | 2051 | | | | | 2052 |>F24 200 OK ->| | | | 2053 | |>F25 200 OK ------------------------------------>| 2054 | | | | | 2055 | |<--------------------------------------- ACK F26<| 2056 |<---- ACK F27<| | | | 2057 | |< - - - - - - - - - - - - - ->| | 2058 | | | | | 2059 | | |<- NOTIFY F28<| | 2060 | | | | | 2061 | | |>F29 200 OK ->| | 2062 | | | |>F30 NOTIFY ----->| 2063 | | | | | 2064 | | | |<----- 200 OK F31<| 2065 | | | | | 2066 | | Alice decides to pick up the call | 2067 | | | | | 2068 | | |>F32 PUBLISH->| | 2069 | | | | | 2070 | | |<- 200 OK F33<| | 2071 | | | | | 2072 | | |<- NOTIFY F34<| | 2073 | | | | | 2074 | | |>F35 200 OK ->| | 2075 | | | |>F36 NOTIFY ----->| 2076 | | | | | 2077 | | | |<----- 200 OK F37<| 2078 | |<-- INVITE F38<| | | 2079 |<- INVITE F39<|(w/ Replaces) | | | 2080 |( w/ Replaces)| | | | 2081 |>F40 200 OK ->| | | | 2082 | |>F41 200 OK -->| | | 2083 | | | | | 2084 | |< - - - - - - - - - - - - - ->| | 2085 | | | | | 2086 | | | |>F42 NOTIFY ----->| 2087 | | | | | 2088 | | | |<----- 200 OK F43<| 2089 | | |<- NOTIFY F44<| | 2090 | | | | | 2091 | | |>F45 200 OK ->| | 2092 | | | | | 2093 | |<----- ACK F46<| | | 2094 |<---- ACK F47<| | | | 2095 | | | | | 2096 |<= Both way RTP established =>| | | 2097 | | | | | 2098 |>F48 BYE ---->| | | | 2099 | |>F49 BYE --------------------------------------->| 2100 | | | | | 2101 | |<------------------------------------ OK 200 F50<| 2102 |<- 200 OK F51<| | | | 2103 | | | | | 2104 | |< - - - - - - - - - - - - - ->| | 2105 | | | | | 2106 | | |<- NOTIFY F52<| | 2107 | | | | | 2108 | | |>F53 200 OK ->| | 2109 | | | | | 2110 | | | |>F54 NOTIFY ----->| 2111 | | | | | 2112 | | | |<----- 200 OK F55<| 2114 Figure 7. 2116 F28 Appearance ----> Alice 2118 NOTIFY sip:alice@ua1.example.com SIP/2.0 2119 From: ;tag=151702541050937 2120 To: ;tag=18433323-C3D237CE 2121 Call-ID: 1e361d2f-a9f51109-bafe31d4 2122 CSeq: 12 NOTIFY 2123 Via: SIP/2.0/UDP appearanceagent.example.com 2124 ;branch=z9hG4bK1403 2125 Max-Forwards: 70 2126 Content-Type: application/dialog-info+xml 2127 Event: dialog;shared 2128 Subscription-State: active;expires=1800 2129 Contact: 2130 Content-Length: ... 2132 2133 2138 2143 1 2144 false 2145 active 2146 2147 2148 2149 2150 2151 2152 sip:carol@example.com 2153 2154 2155 2156 2158 F32 Alice ----> Appearance Agent 2160 PUBLISH sip:HelpDesk@example.com SIP/2.0 2161 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A 2162 From: ;tag=44150CC6-A7B7919D 2163 To: ;tag=428765950880801 2164 CSeq: 11 PUBLISH 2165 Call-ID: 87837Fkw87asfds 2166 Contact: 2167 Event: dialog;shared 2168 Max-Forwards: 70 2169 Content-Type: application/dialog-info+xml 2170 Content-Length: ... 2172 2173 2178 2181 1 2182 false 2183 2187 trying 2188 2189 2190 2191 2192 2193 2194 2195 2196 2197 2199 F38 Alice ----> Proxy 2201 INVITE sip:carol@example.com SIP/2.0 2202 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK4ea695b5B376A60C 2203 From: ;tag=8C4183CB-BCEAB710 2204 To: 2205 CSeq: 1 INVITE 2206 Call-ID: 3d57cd17-47deb849-dca8b6c6 2207 Contact: 2208 2209 Replaces: f3b3cbd0-a2c5775e-5df9f8d5;to-tag=65a98f7c 2210 -1dd2-11b2-88c6-b03162323164+65a98f7c;from-tag=15A3DE7C-9283203B 2211 2212 Max-Forwards: 70 2213 Content-Type: application/sdp 2214 Content-Length: 223 2216 v=0 2217 o=- 1102980497 1102980497 IN IP4 ua1.example.com 2218 s=IP SIP UA 2219 c=IN IP4 ua1.example.com 2220 t=0 0 2221 a=sendrecv 2222 m=audio 2238 RTP/AVP 0 8 101 2223 a=rtpmap:0 PCMU/8000 2224 a=rtpmap:8 PCMA/8000 2225 a=rtpmap:101 telephone-event/8000 2227 11.8. Calls between UAs within the Group 2229 In this scenario, Bob calls Alice who is also in the Appearance 2230 group. Only one appearance number is used for this dialog. This 2231 example also shows the use of the 'exclusive' tag to indicate that 2232 other UAs in the group can not join or take this dialog. 2234 Carol Proxy Alice Appearance Agent Bob 2235 | | | | | 2236 | |<-------------------- INVITE (to Alice's UA) F1<| 2237 | | | | | 2238 | |< - - - - - - - - - - - - - ->| | 2239 | | | | | 2240 | | | | | 2241 | | |<-- NOTIFY F2<| | 2242 | | | | | 2243 | | |>F3 200 OK -->| | 2244 | | | |>F4 NOTIFY ------>| 2245 | | | | | 2246 | | | |<------ 200 OK F5<| 2247 | |>F6 INVITE --->| | | 2248 | | (appearance=1)| | | 2249 | | | | | 2250 | |<------ 180 F7<| | | 2251 | | | | | 2252 | |>F8 180 --------------------------------------->| 2253 | | | | | 2254 | |< - - - - - - - - - - - - - ->| | 2255 | | | | | 2256 | | |<-- NOTIFY F9<| | 2257 | | | | | 2258 | | |>F10 200 OK ->| | 2259 | | | |>F11 NOTIFY ----->| 2260 | | | | | 2261 | | | |<----- 200 OK F12<| 2262 | |<-- 200 OK F13<| | | 2263 | | | | | 2264 | |>F14 200 OK ------------------------------------>| 2265 | | | | | 2266 | |<--------------------------------------- ACK F15<| 2267 | | | | | 2268 | |>F16 ACK ----->| | | 2269 | | | | | 2270 | | |<======= RTP established =======>| 2271 | | | | | 2272 | |< - - - - - - - - - - - - - ->| | 2273 | | | | | 2274 | | |<- NOTIFY F17<| | 2275 | | | | | 2276 | | |>F18 200 OK ->| | 2277 | | | |>F19 NOTIFY ----->| 2278 | | | | | 2279 | | | |<----- 200 OK F24<| 2280 | | | | | 2282 Figure 8. 2284 F19 Appearance Agent ----> Bob 2286 NOTIFY sip:bob@ua1.example.com SIP/2.0 2287 From: ;tag=497585728578386 2288 To: ;tag=633618CF-B9C2EDA4 2289 Call-ID: a7d559db-d6d7dcad-311c9e3a 2290 CSeq: 7 NOTIFY 2291 Via: SIP/2.0/UDP appearanceagent.example.com 2292 ;branch=z9hG4bK1711759878512309 2293 Max-Forwards: 70 2294 Content-Type: application/dialog-info+xml 2295 Event: dialog;shared 2296 Subscription-State: active;expires=1500 2297 Contact: 2298 Content-Length: ... 2300 2301 2306 2311 true 2312 1 2313 confirmed 2314 2315 2316 2317 2318 2319 sip:HelpDesk@example.com 2320 2321 2323 2325 2330 true 2331 1 2332 confirmed 2333 2334 2335 2336 2337 sip:HelpDesk@example.com 2338 2339 2340 2342 2344 11.9. Consultation Hold with Appearances 2346 In this scenario, Bob has a call with Carol. Bob makes a 2347 consultation call to Alice by putting Carol on hold and calling 2348 Alice. Bob's UA chooses not to have an appearance number for the 2349 call to Alice since it is treating it as part of the call to Carol. 2350 He indicates this in the PUBLISH F32 which contains the 'shared' 2351 Event parameter but no element. The PUBLISH is sent 2352 before the INVITE to Alice to ensure no appearance number is assigned 2353 by the Appearance Agent. Finally, Bob hangs up with Alice and 2354 resumes the call with Carol. Dialog notifications of the 2355 consultation call are not shown, as they are not used. 2357 Note that if Carol hangs up while Bob is consulting with Alice, Bob 2358 can decide if he wants to reuse the appearance number used with Carol 2359 for the call with Alice. If not, Bob publishes the termination of 2360 the dialog with Carol and the Appearance Agent will re-allocate the 2361 appearance. If he wants to keep the appearance, Bob will publish the 2362 termination of the dialog with Carol and also publish the appearance 2363 with the dialog with Alice. This will result in Bob keeping the 2364 appearance number until he reports the dialog with Alice terminated. 2366 Note that the call flow would be similar if Bob called a music on 2367 hold server instead of Alice to implement a music on hold service as 2368 described in [I-D.worley-service-example]. 2370 Carol Proxy Alice Appearance Agent Bob 2371 | | | | | 2372 |<================= Both way RTP established ===================>| 2373 | | | | | 2374 | |<------------------------------(hold) INVITE F22<| 2375 |<- INVITE F23<| | | | 2376 | | | | | 2377 |>F24 200 OK ->| | | | 2378 | |>F25 200 OK ------------------------------------>| 2379 | | | | | 2380 | |<--------------------------------------- ACK F26<| 2381 |<---- ACK F27<| | | | 2382 | |< - - - - - - - - - - - - - ->| | 2383 | | | | | 2384 | | |<- NOTIFY F28<| | 2385 | | | | | 2386 | | |>F29 200 OK ->| | 2387 | | | |>F30 NOTIFY ----->| 2388 | | | | | 2389 | | | |<----- 200 OK F31<| 2390 | | | | | 2391 | | Bob makes a consultation call to Alice | 2392 | | | | | 2393 | | | |<---- PUBLISH F32<| 2394 | | | | | 2395 | | | |>F33 200 OK ----->| 2396 | | | | | 2397 | |<------------------------------------ INVITE F34<| 2398 | | | | | 2399 | |>F35 INVITE -->| | | 2400 | | | | | 2401 | |<-- 200 OK F36<| | | 2402 | | | | | 2403 | |>F37 200 OK ------------------------------------>| 2404 | | | | | 2405 | |<--------------------------------------- ACK F38<| 2406 | | | | | 2407 | |>F39 ACK ----->| | | 2408 | | | | | 2409 | | |<======= RTP established =======>| 2410 | | | | | 2411 | | Bob hangs up with Alice | 2412 | | | | | 2413 | |<--------------------------------------- BYE F40<| 2414 | | | | | 2415 | |>F41 BYE ----->| | | 2416 | | | | | 2417 | |<-- 200 OK F42<| | | 2418 | | | | | 2419 | |>F43 200 OK ------------------------------------>| 2420 | | | | | 2421 | |<----------------------------(unhold) INVITE F44<| 2422 |<- INVITE F45<| | | | 2423 | | | | | 2424 |>F46 200 OK ->| | | | 2425 | |>F47 200 OK ------------------------------------>| 2426 | | | | | 2427 | |<--------------------------------------- ACK F48<| 2428 |<---- ACK F49<| | | | 2429 | |< - - - - - - - - - - - - - ->| | 2430 | | | | | 2431 | | |<- NOTIFY F50<| | 2432 | | | | | 2433 | | |>F51 200 OK ->| | 2434 | | | |>F52 NOTIFY ----->| 2435 | | | | | 2436 | | | |<----- 200 OK F53<| 2437 | | | | | 2438 |<================= Both way RTP established ===================>| 2439 | | | | | 2441 Figure 9. 2443 F32 Bob ----> Appearance Agent 2445 PUBLISH sip:HelpDesk@example.com SIP/2.0 2446 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A 2447 From: ;tag=44150CC6-A7B7919D 2448 To: ;tag=428765950880801 2449 CSeq: 11 PUBLISH 2450 Call-ID: 44fwF144-F12893K38424 2451 Contact: 2452 Event: dialog;shared 2453 Max-Forwards: 70 2454 Content-Type: application/dialog-info+xml 2455 Content-Length: ... 2457 2458 2463 2468 true 2469 trying 2470 2471 2472 2473 2474 2475 sip:HelpDesk@example.com 2476 2477 2478 2479 2481 11.10. Joining or Bridging an Appearance 2483 In this call flow, a call answered by Bob is joined by Alice or 2484 "bridged". The Join header field is used by Alice to request this 2485 bridging. If Bob did not support media mixing, Bob could obtain 2486 conferencing resources as described in [RFC4579]. 2488 Carol Forking Proxy Appearance Agent Alice Bob 2489 | | | | | 2490 |<=============Both way RTP established===========>| 2491 | | | | | 2492 | | |< PUBLISH F22| | 2493 | | | | | 2494 | | |>F23 200 OK >| | 2495 | | | | | 2496 | |<---- INVITE (w/ Join) F24<| | 2497 | | | | | 2498 | |>F25 INVITE (w/Join)---------------->| 2499 | | | | | 2500 | |<---- OK 200 Contact:Bob;isfocus F26<| 2501 | | | | | 2502 | |< - - - - - >| | | 2503 | | | | | 2504 | | |>F27 NOTIFY >| | 2505 | | | | | 2506 | | |< 200 OK F28<| | 2507 | | | | | 2508 | | |>F29 NOTIFY ---------->| 2509 | | | | | 2510 | | |F31 200 OK Contact:B----->| | 2513 | | | | | 2514 | |<----------------- ACK F32<| | 2515 | | | | | 2516 | |>ACK F33---------------------------->| 2517 | | | | | 2518 | |<-----INVITE Contact:Bob;isfocus F34<| 2519 |<-INVITE F35| | | | 2520 | | | | | 2521 |>F26 200 -->| | | | 2522 | |>F37 200 OK ------------------------>| 2523 | | | | | 2524 | |<--------------------------- ACK F38<| 2525 |<--- ACK F39| | | | 2526 | | | |<==RTP==>| 2527 |<=============Both way RTP established===========>| 2528 | | | | | 2529 | |< - - - - - >| | | 2530 | | | | | 2531 | | |>F40 NOTIFY >| | 2532 | | | | | 2533 | | |< 200 OK F41<| | 2534 | | | | | 2535 | | |>F42 NOTIFY ---------->| 2536 | | | | | 2537 | | | Appearance Agent 2544 PUBLISH sip:HelpDesk@example.com SIP/2.0 2545 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A 2546 From: ;tag=44150CC6-A7B7919D 2547 To: ;tag=428765950880801 2548 CSeq: 11 PUBLISH 2549 Call-ID: 87837Fkw87asfds 2550 Contact: 2551 Event: dialog;shared 2552 Max-Forwards: 70 2553 Content-Type: application/dialog-info+xml 2554 Content-Length: ... 2556 2557 2562 2565 1 2566 false 2567 2571 trying 2572 2573 2574 2575 2576 2577 2578 2579 2580 2582 F24 Alice ----> Proxy 2584 INVITE sip:bob@ua.example.com SIP/2.0 2585 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKcc9d727c2C29BE31 2586 From: ;tag=605AD957-1F6305C2 2587 To: 2588 CSeq: 2 INVITE 2589 Call-ID: dc95da63-60db1abd-d5a74b48 2590 Contact: 2591 2592 Join: 14-1541707345;to-tag=d3b06488-1dd1-11b2-88c5 2593 -b03162323164+d3e48f4c;from-tag=44BAD75D-E3128D42 2594 2595 Max-Forwards: 70 2596 Content-Type: application/sdp 2597 Content-Length: 223 2599 v=0 2600 o=- 1103061265 1103061265 IN IP4 ua1.example.com 2601 s=IP SIP UA 2602 c=IN IP4 ua1.example.com 2603 t=0 0 2604 a=sendrecv 2605 m=audio 2236 RTP/AVP 0 8 101 2606 a=rtpmap:0 PCMU/8000 2607 a=rtpmap:8 PCMA/8000 2608 a=rtpmap:101 telephone-event/8000 2610 11.11. Appearance Allocation - Loss of Appearance 2612 Bob reserves an appearance with a PUBLISH, sends an INVITE to Carol, 2613 then becomes unreachable. When he fails to refresh his publication 2614 to the appearance agent, the Appearance Agent declares the dialog 2615 terminated and frees up the appearance using NOTIFYs F14 and F16. 2616 After retransmitting the NOTIFY to Bob (in not shown messages F17, 2617 F18, etc.), the subscription is terminated. 2619 Carol Proxy Alice Appearance Agent Bob 2620 | | | | | 2621 | | | |<----- PUBLISH F1<| 2622 | | | | | 2623 | | | |>F2 200 OK ------>| 2624 | | | | | 2625 | | |<-- NOTIFY F3<| | 2626 | | | | | 2627 | | |>F4 200 OK -->| | 2628 | | | |------- NOTIFY F5>| 2629 | | | | | 2630 | | | |F8 100 Trying --------------------------------->| 2635 |<-- INVITE F9<| | | | 2636 | | | |<---- PUBLISH F10<| 2637 | | | | | 2638 | | | |>F11 200 OK ----->| 2639 | | | | | 2640 |>F12 180 --->| | | | 2641 | |>F13 180 Ringing ------------------------------->| 2642 | | | | | 2643 | | | | Bob goes offline | 2644 | | | | | 2645 | | | Appearance selection times out | 2646 | | | | | 2647 | | |<- NOTIFY F14<| | 2648 | | | | | 2649 | | |>F15 200 OK ->| | 2650 | | | |------ NOTIFY F16>| 2651 | | | | | 2652 | | | NOTIFY is retransmitted | 2654 Figure 11. 2656 11.12. Appearance Seizure Contention Race Condition 2658 Bob and Alice both try to reserve appearance 2 by publishing at the 2659 same time. The Appearance Agent allocates the appearance to Bob by 2660 sending a 200 OK and denies it to Alice by sending a 400 response. 2661 After the NOTIFY F5, Alice learns that Bob is using appearance 2. 2662 Alice then attempts to reserve appearance 3 by publishing, which is 2663 then accepted. 2665 Carol Proxy Alice Appearance Agent Bob 2666 | | | | | 2667 | | | |<----- PUBLISH F1<| 2668 | | | | (appearance=2) 2669 | | |>F2 PUBLISH ->| | 2670 | | | (appearance=2) | 2671 | | | | | 2672 | | | |>F3 200 OK ------>| 2673 | | |<---- F4 400 <| | 2674 | | | | | 2675 | | |<-- NOTIFY F5<| | 2676 | | | | | 2677 | | |>F6 200 OK -->| | 2678 | | | |------- NOTIFY F7>| 2679 | | | | | 2680 | | | |F10 100 Trying -------------------------------->| 2685 |<- INVITE F11<| | | | 2686 | | | |<---- PUBLISH F12<| 2687 | | | | (appearance=2) 2688 | | | |>F13 200 OK ----->| 2689 | | |>F14 PUBLISH->| | 2690 | | | (appearance=3) | 2691 | | | | | 2692 | | |<--- F15 200 <| | 2693 | | | | | 2694 | | |<- NOTIFY F16<| | 2695 | | | | | 2696 | |>F17 200 OK ->| | 2697 Dave | | |------ NOTIFY F18>| 2698 | | | | | 2699 | | | |F21 100 ----->| | | 2703 |<- INVITE F22<| | | | 2705 Figure 12. 2707 11.13. Appearance Agent Subscription to UAs 2709 In this scenario, the Appearance Agent does not have any way of 2710 knowing Bob's dialog state information, except through Bob. This 2711 could be because the Appearance Agent is not part of a B2BUA, or 2712 perhaps Bob is remotely registering. When Bob registers, the 2713 Appearance Agent receives a registration event package notification 2714 from the registrar. The Appearance Agent then SUBSCRIBEs to Bob's 2715 dialog event state using Event:dialog in the SUBSCRIBE. Whenever 2716 Bob's dialog state changes, Bob's UA sends a NOTIFY to the Appearance 2717 Agent which then notifies the other other UAs in the group. 2719 Carol Proxy Alice Appearance Agent Bob 2720 | | | | | 2721 | |<----------------------------------- REGISTER F1<| 2722 | | | | | 2723 | |>F2 200 OK ------------------------------------->| 2724 | | | | | 2725 | |>F3 NOTIFY ------------------>| | 2726 | | | | | 2727 | |<------------------ 200 OK F4<| | 2728 | | | |---- SUBSCRIBE F5>| 2729 | | | | | 2730 | | | |F8 200 OK ------>| 2735 | | | | | 2736 | | | |<--- SUBSCRIBE F9<| 2737 | | | | | 2738 | | | |>F10 200 OK ----->| 2739 | | | | | 2740 | | | |------ NOTIFY F11>| 2741 | | | | | 2742 | | | |F14 100 Trying -------------------------------->| 2747 |<- INVITE F15<| | | | 2748 | | | |<----- NOTIFY F16<| 2749 | | | | | 2750 | | | |>F17 200 OK ----->| 2751 | | |<- NOTIFY F18<| | 2752 | | | | | 2753 | | |>F19 200 OK ->| | 2754 | | | |------ NOTIFY F20>| 2755 | | | | | 2756 | | | |F22 180 --->| | | | 2758 | |>F23 180 Ringing ------------------------------->| 2759 | | | | | 2760 | | | |<----- NOTIFY F24<| 2761 | | | | | 2762 | | | |>F25 200 OK ----->| 2763 | | |<- NOTIFY F26<| | 2764 | | | | | 2765 | | |>F27 200 OK ->| | 2766 | | | |------ NOTIFY F28>| 2767 | | | | | 2768 | | | |F30 200 OK ->| | | | 2770 | |>F31 200 OK ------------------------------------>| 2771 | | | | | 2772 | | | |<----- NOTIFY F32<| 2773 | | | | | 2774 | | | |>F33 200 OK ----->| 2775 | | | | | 2776 | |<--------------------------------------- ACK F34<| 2777 |<---- ACK F35<| | | | 2778 | | | | | 2779 |<================= Both way RTP established ===================>| 2780 | | | | | 2781 | | |<- NOTIFY F36<| | 2782 | | | | | 2783 | | |>F37 200 OK ->| | 2784 | | | |------ NOTIFY F38>| 2785 | | | | | 2786 | | | || 2804 | | | | | 2805 | |<------------------------------(hold) INVITE F22<| 2806 |<- INVITE F23<| | | | 2807 | | | | | 2808 |>F24 200 OK ->| | | | 2809 | |>F25 200 OK ------------------------------------>| 2810 | | | | | 2811 | |<--------------------------------------- ACK F26<| 2812 |<---- ACK F27<| | | | 2813 | | | | | 2814 | |< - - - - - - - - - - - - - ->| | 2815 | | | | | 2816 | | |<- NOTIFY F28<| | 2817 | | | | | 2818 | | |>F29 200 OK ->| | 2819 | | | |>F30 NOTIFY ----->| 2820 | | | | | 2821 | | | |<----- 200 OK F31<| 2822 | | | | | 2823 | | Alice decides to pick up the call | 2824 | | | | | 2825 | | |>F32 PUBLISH->| | 2826 | | | | | 2827 | | |<- 200 OK F33<| | 2828 | | | | | 2829 | | |<- NOTIFY F34<| | 2830 | | | | | 2831 | | |>F35 200 OK ->| | 2832 | | | |>F36 NOTIFY ----->| 2833 | | | | | 2834 | | | |<----- 200 OK F37<| 2835 |>F38 BYE ---->| | | | 2836 | |>F39 BYE --------------------------------------->| 2837 | | | | | 2838 | |<------------------------------------ OK 200 F40<| 2839 |<- 200 OK F41<| | | | 2840 | |<-- INVITE F42<| | | 2841 |<- INVITE F43<|(w/ Replaces) | | | 2842 |( w/ Replaces)| | | | 2843 | | | | | 2844 |>F44 481 ---->| | | | 2845 | |>F45 481 ----->| | | 2846 |<---- ACK F46<| | | | 2847 | |<----- ACK F47<| | | 2848 | | |>F48 PUBLISH->| | 2849 | | | | | 2850 | | |<- 200 OK F49<| | 2851 | | | | | 2852 | | |<- NOTIFY F50<| | 2853 | | | | | 2854 | | |>F51 200 OK ->| | 2855 | | | |>F52 NOTIFY ----->| 2856 | | | | | 2857 | | | |<----- 200 OK F53<| 2859 Figure 14. 2861 F48 Alice ----> Appearance Agent 2863 PUBLISH sip:HelpDesk@example.com SIP/2.0 2864 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A 2865 From: ;tag=44150CC6-A7B7919D 2866 To: ;tag=428765950880801 2867 CSeq: 11 PUBLISH 2868 Call-ID: 87837Fkw87asfds 2869 Contact: 2870 Event: dialog;shared 2871 Max-Forwards: 70 2872 Content-Type: application/dialog-info+xml 2873 Content-Length: ... 2875 2876 2881 2884 1 2885 false 2886 2890 terminated 2891 2892 2893 2894 2895 2896 2897 2898 2899 2901 11.15. Appearance Seizure Incoming/Outgoing Contention Race Condition 2903 Alice tries to seize appearance 2 at the same time appearance 2 is 2904 allocated to an incoming call. The Appearance Agent resolves the 2905 conflict by sending a 400 to Alice. After the NOTIFY F6, Alice 2906 learns that the incoming call is using appearance 2. Alice 2907 republishes for appearance 3, which is accepted. Note that this 2908 example shows the INVITE being received before the NOTIFY from the 2909 Appearance Agent. 2911 Carol Proxy Alice Appearance Agent Bob 2912 | | | | | 2913 |>-- INVITE F1>| | | | 2914 | |< - - - - - - - - - - - - - ->| | 2915 | | | | | 2916 | | |>F2 PUBLISH ->| | 2917 | | | (appearance=2) | 2918 | | | | | 2919 | |>F3 INVITE (appearance=2) ---------------------->| 2920 | | | | | 2921 | |>F4 INVITE | | | 2922 | |(appearance=2)>| | | 2923 | | |<---- F5 400 <| | 2924 | | | | | 2925 | | |<-- NOTIFY F6<| | 2926 | | | | | 2927 | | |>F7 200 OK -->| | 2928 | | | |------- NOTIFY F8>| 2929 | | | | | 2930 | | | |F10 PUBLISH->| | 2933 | | | (appearance=3) | 2934 | | | | | 2935 | | |< F11 200 OK <| | 2936 | | | | | 2937 | | |<- NOTIFY F12<| | 2938 | | | | | 2939 | |>F13 200 OK ->| | 2940 Dave | | |------ NOTIFY F14>| 2941 | | | | | 2942 | | | |F17 100 ----->| | | 2946 |<- INVITE F18<| | | | 2948 Figure 15. 2950 12. Security Considerations 2952 Since multiple line appearance features are implemented using 2953 semantics provided by [RFC3261], Event Package for Dialog State as 2954 define in , and Event Notification [I-D.ietf-sipcore-rfc3265bis], 2955 [RFC3903], security considerations in these documents apply to this 2956 draft as well. 2958 NOTIFY or PUBLISH message bodies that provide the dialog state 2959 information and the dialog identifiers MAY be encrypted end-to-end 2960 using the standard mechanisms. All SUBSCRIBES and PUBLISHES between 2961 the UAs and the Appearance Agent MUST be authenticated. 2963 All INVITEs with Replaces or Join header fields MUST only be accepted 2964 if the peer requesting dialog replacement or joining has been 2965 properly authenticated using a standard SIP mechanism (such as Digest 2966 or S/MIME), and authorized to request a replacement. 2968 For an emergency call, a UA MUST never wait for a confirmed seizure 2969 of an appearance before sending an INVITE. Instead, the emergency 2970 call MUST proceed regardless of the status of the PUBLISH 2971 transaction. 2973 13. IANA Considerations 2975 This section registers the SIP event package parameter 'shared', the 2976 SIP Alert-Info header field parameter "appearance" and the XML 2977 namespace extensions to the SIP Dialog Package. 2979 13.1. SIP Event Package Parameter: shared 2981 This specification defines a new event parameter 'shared' for the 2982 Dialog Package. When used in a NOTIFY, it indicates that the 2983 notifier supports the shared appearance feature. When used in a 2984 PUBLISH, it indicates that the publisher has explicit appearance 2985 information contained in the message body. If not present in a 2986 PUBLISH, the Appearance Agent MAY assign an appearance number to any 2987 new dialogs in the message body. 2989 13.2. URN Sub-Namespace Registration: sa-dialog-info 2991 This section registers a new XML namespace per the procedures 2992 in [RFC3688]. 2994 URI: urn:ietf:params:xml:ns:sa-dialog-info. 2996 Registrant Contact: IETF BLISS working group, , 2997 Alan Johnston 2999 XML: 3001 BEGIN 3002 3003 3005 3006 3007 3009 Shared Appearance Dialog Information Namespace 3010 3011 3012

Namespace for Shared Appearance Dialog Information

3013

urn:ietf:params:xml:ns:dialog-info

3014

See 3015 RFCXXXX.

3016 3017 3018 END 3020 13.3. XML Schema Registration 3022 This section registers an XML schema per the procedures in 3023 [RFC3688]. 3025 URI: urn:ietf:params:xml:schesa:sa-dialog-info. 3027 Registrant Contact: IETF BLISS working group, , 3028 Alan Johnston 3030 The XML for this schema can be found in Section 6. 3032 14. Acknowledgements 3034 The following individuals were part of the shared appearance Design 3035 team and have provided input and text to the document (in 3036 alphabetical order): 3038 Martin Dolly, Andrew Hutton, Raj Jain, Fernando Lombardo, Derek 3039 MacDonald, Bill Mitchell, Michael Procter, Theo Zowzouvillys. 3041 Thanks to Chris Boulton for helping with the XML schema. 3043 Much of the material has been drawn from previous work by Mohsen 3044 Soroushnejad, Venkatesh Venkataramanan, Paul Pepper and Anil Kumar, 3045 who in turn received assistance from: 3047 Kent Fritz, John Weald, and Sunil Veluvali of Sylantro Systems, Steve 3048 Towlson, and Michael Procter of Citel Technologies, Rob Harder and 3049 Hong Chen of Polycom Inc, John Elwell, J D Smith of Siemens 3050 Communications, Dale R. Worley of Pingtel, Graeme Dollar of Yahoo 3051 Inc. 3053 Also thanks to Geoff Devine, Paul Kyzivat, Jerry Yin, John Elwell, 3054 Dan York, Spenser Dawkins, Martin Dolly, and Brett Tate for their 3055 comments. 3057 Thanks to Carolyn Beeton, Francois Audet, Andy Hutton, Tim Ross, Raji 3058 Chinnappa, and Harsh Mendiratta for their detailed review of the 3059 document. 3061 15. References 3063 15.1. Normative References 3065 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3066 Requirement Levels", BCP 14, RFC 2119, March 1997. 3068 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3069 A., Peterson, J., Sparks, R., Handley, M., and E. 3070 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3071 June 2002. 3073 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 3074 Method", RFC 3515, April 2003. 3076 [I-D.ietf-sipcore-rfc3265bis] 3077 Roach, A., "SIP-Specific Event Notification", 3078 draft-ietf-sipcore-rfc3265bis-09 (work in progress), 3079 April 2012. 3081 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 3082 for Event State Publication", RFC 3903, October 2004. 3084 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 3085 Protocol (SIP) "Replaces" Header", RFC 3891, 3086 September 2004. 3088 [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- 3089 Initiated Dialog Event Package for the Session Initiation 3090 Protocol (SIP)", RFC 4235, November 2005. 3092 [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol 3093 (SIP) "Join" Header", RFC 3911, October 2004. 3095 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 3096 "Indicating User Agent Capabilities in the Session 3097 Initiation Protocol (SIP)", RFC 3840, August 2004. 3099 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3100 January 2004. 3102 [I-D.ietf-salud-alert-info-urns] 3103 Liess, L., Jesske, R., Johnston, A., Worley, D., and P. 3104 Kyzivat, "Alert-Info URNs for the Session Initiation 3105 Protocol (SIP)", draft-ietf-salud-alert-info-urns-06 (work 3106 in progress), April 2012. 3108 15.2. Informative References 3110 [RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and 3111 K. Summers, "Session Initiation Protocol Service 3112 Examples", BCP 144, RFC 5359, October 2008. 3114 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol 3115 (SIP) Call Control - Conferencing for User Agents", 3116 BCP 119, RFC 4579, August 2006. 3118 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 3119 Package for Registrations", RFC 3680, March 2004. 3121 [I-D.worley-service-example] 3122 Worley, D., "Session Initiation Protocol Service Example 3123 -- Music on Hold", draft-worley-service-example-09 (work 3124 in progress), February 2012. 3126 Authors' Addresses 3128 Alan Johnston (editor) 3129 Avaya 3130 St. Louis, MO 63124 3132 Email: alan.b.johnston@gmail.com 3134 Mohsen Soroushnejad 3135 Sylantro Systems Corp 3137 Email: mohsen.soroush@sylantro.com 3139 Venkatesh Venkataramanan 3140 Sylantro Systems Corp 3142 Email: vvenkatar@gmail.com