idnits 2.17.1 draft-ietf-bliss-shared-appearances-08.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 (June 3, 2011) is 4683 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 (-09) exists of draft-ietf-sipcore-rfc3265bis-02 == Outdated reference: A later version (-14) exists of draft-ietf-salud-alert-info-urns-02 == Outdated reference: A later version (-15) exists of draft-worley-service-example-06 Summary: 0 errors (**), 0 flaws (~~), 4 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: December 5, 2011 Sylantro Systems Corp 7 June 3, 2011 9 Shared Appearances of a Session Initiation Protocol (SIP) Address of 10 Record (AOR) 11 draft-ietf-bliss-shared-appearances-08 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 December 5, 2011. 46 Copyright Notice 48 Copyright (c) 2011 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 . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . 18 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 . . 24 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 . . . . . . . . . . . 49 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 . . . . . . . 57 125 11.12. Appearance Seizure Contention Race Condition . . . . . . 58 126 11.13. Appearance Agent Subscription to UAs . . . . . . . . . . 60 127 11.14. Appearance Pickup Race Condition Failure . . . . . . . . 61 128 11.15. Appearance Seizure Incoming/Outgoing Contention Race 129 Condition . . . . . . . . . . . . . . . . . . . . . . . . 64 130 12. Security Considerations . . . . . . . . . . . . . . . . . . . 65 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. Different approaches will be discussed including the 168 use of URI parameters, feature tags, and dialog package extensions 169 along with the strengths and weaknesses of the various approaches. 171 In traditional telephony, the line is physical. A common scenario in 172 telephony is for a number of business telephones to share a single or 173 a small number of lines. The sharing or appearance of these lines 174 between a number of phones is what gives this feature its name. A 175 common scenario in SIP is for a number of business telephones to 176 share a single or a small number of Address of Record (AOR) URIs. 178 In addition, an AOR can have multiple appearances on a single UA in 179 terms of the user interface. The appearance number relates to the 180 user interface for the telephone - typically each appearance of an 181 AOR has a visual display (lamp that can change color or blink or a 182 screen icon) and a button (used to select the appearance) where each 183 appearance number is associated with a different dialog to/from the 184 AOR. The telephony concept of line appearance is still relevant to 185 SIP due to the user interface considerations. It is important to 186 keep the appearance number construct because: 188 1. Human users are used to the concept and will expect it in 189 replacement systems (e.g. an overhead page announcement says "Joe 190 pickup line 3"). 191 2. It is a useful structure for user interface representation. 193 The purpose of the appearance number is to identify active calls to 194 facilitate sharing between users (e.g. passing a call from one user 195 to another). If a telephone has enough buttons/lamps, the appearance 196 number could be the positional sequence number of the button. If 197 not, it may still be desirable to present the call state, but the 198 appearance number should be displayed so that users know which call, 199 for example, is on hold on which key. 201 In this document, except for the usage scenarios in the next section, 202 we will use the term "appearance" rather than "line appearance" since 203 SIP does not have the concept of lines. Note that this does not mean 204 that a conventional telephony user interface (lamps and buttons) must 205 be used - implementations may use another metaphor as long as the 206 appearance number is readily apparent to the user. Each AOR has a 207 separate appearance numbering space. As a result, a given UA user 208 interface may have multiple occurrences of the same appearance 209 number, but they will be for different AORs. 211 2. Conventions used in this document 213 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 214 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 215 document are to be interpreted as described in RFC-2119 [RFC2119] and 216 indicate requirement levels for compliant mechanisms. 218 3. Usage Scenarios 220 The following examples are common applications of the Shared 221 Appearances feature and are mentioned here as informative use cases. 222 All these example usages can be supported by the Shared Appearances 223 feature described in this document. The main differences relate to 224 the user interface considerations of the device. 226 3.1. Executive/Assistant Arrangement 228 The appearances on the executive's UA also appear on the assistant's 229 UA. The assistant may answer incoming calls to the executive and 230 then place the call on hold for the executive to pick up. The 231 assistant can always see the state of all calls on the executive's 232 UA. 234 3.2. Call Group 236 Users with similar business needs or tasks can be assigned to 237 specific groups and share an AOR. For example, an IT department 238 staff of five might answer a help line which has three appearances on 239 each phone in the IT work area. A call answered on one phone can be 240 put on hold and picked up on another phone. A shout or an IM to 241 another staff member can result in them taking over a call on a 242 particular appearance. Another phone can request to be added/joined/ 243 bridged to an existing appearance resulting in a conference call. 245 3.3. Single Line Extension 247 In this scenario, incoming calls are offered to a group of UAs. When 248 one answers, the other UAs are informed. If another UA in the group 249 seizes the line (i.e. goes off hook), it is immediately bridged or 250 joined in with the call. This mimics the way residential telephone 251 extensions usually operate. 253 3.4. Changing UAs 255 A user is on a call on one UA and wishes to change devices and 256 continue the call on another UA. They place the call on hold, note 257 the appearance number of the call, then walk to another UA. They are 258 able to identify the same appearance number on the other UA, pickup 259 the call, and continue the conversation. 261 4. Requirements and Implementation 263 The next section details the requirements and discusses the 264 implementation of the shared appearances of an AOR feature. 266 4.1. Requirements 268 The basic requirements of the shared appearance feature can be 269 summarized as follows: 271 REQ-1 Incoming calls to the AOR must be offered to a group of UAs and 272 can be answered by any of them. 274 REQ-2 Each UA in the group must be able to learn the call status of 275 the others in the group for the purpose of rendering this information 276 to the user. 278 REQ-3 A UA must be able to join (also called bridge or conference 279 together) or pick up (take) an active call of another UA in the group 280 in a secure way. 282 REQ-4 The mechanism should require the minimal amount of 283 configuration. UAs registering against the group AOR should be able 284 to participate in the appearance group without manual configuration 285 of group members. 287 REQ-5 The mechanism must scale for large numbers of appearances, n, 288 and large numbers of UAs, N, without introducing excessive messaging 289 traffic. 291 REQ-6 Each call or session (incoming or outgoing) must be assigned a 292 common "appearance" number from a managed pool administered for the 293 AOR group. Once the session has terminated, the appearance number is 294 released back into the pool and can be reused by another incoming or 295 outgoing session. 297 REQ-7 Each UA in the group must be able to learn the status of all 298 appearances of the group. 300 REQ-8 There must be mechanisms to resolve appearance contention among 301 the UAs in the group. 303 REQ-9 The mechanism must allow all UAs receiving an incoming session 304 request to utilize the same appearance number at the time of 305 alerting. 307 REQ-10 The mechanism must have a way of reconstructing appearance 308 state after an outage that does not result in excessive traffic and 309 processing. 311 REQ-11 The mechanism must have backwards compatibility such that a UA 312 which is unaware of the feature can still register against the group 313 AOR and make and receive calls. 315 REQ-12 The mechanism must not allow UAs outside the group to select, 316 seize or manipulate appearance numbers. 318 REQ-13 For privacy reasons, there must be a mechanism so that 319 appearance information is not leaked outside the group of UAs. (e.g. 320 "So who do you have on line 1?") 322 REQ-14 The mechanism must support a way for UAs to request 323 exclusivity on a line appearance. Exclusivity means that the UA 324 requesting it desires to have a private conversation with the 325 external party and other UAs must not be allowed to join or take the 326 call. Exclusivity may be requested at the start of an incoming or 327 outgoing session or during the session. An exclusivity request may 328 be accepted or rejected by the entity providing the shared appearance 329 service. Therefore, the mechanism must provide a way of 330 communicating the result back to the requester UA. 332 REQ-15 The mechanism should support a way for a UA to seize a 333 particular appearance number for outgoing requests prior to sending 334 the actual request. This is often called seizure. 336 REQ-16 The mechanism should support a way for a UA to seize a 337 particular appearance number and also send the request at the same 338 time. This is needed when an automatic ringdown feature (a telephone 339 configured to immediately dial a phone number when it goes off hook) 340 is combined with shared appearances - in this case, seizing the line 341 is the same thing as dialing. 343 4.2. Implementation 345 This section non-normatively discusses the implementation of the 346 shared appearance feature. The normative description is in 347 Section 5. Many of the requirements for this service can be met 348 using standard SIP mechanisms such as: 350 - A SIP Forking Proxy and Registrar/Location Service meets REQ-1. 352 - The SIP Dialog Package meets REQ-2. 354 - The SIP Replaces and Join header fields meets REQ-3. 356 - The use of a State Agent for the Dialog Package meets REQ-4 and 357 REQ-5. 359 REQ-6 suggests the need for an entity which manages the appearance 360 resource. Just as conferencing systems commonly have a single point 361 of control, known as a focus, a Shared Appearance group has a single 362 point of control of the appearance shared resource. This is defined 363 as an Appearance Agent for a group. While an Appearance Agent can be 364 part of a centralized server, it could also be co-resident in a 365 member User Agent that has taken on this functionality for a group. 366 The Appearance Agent knows or is able to determine the dialog state 367 of all members of the group. 369 While the appearance resource could be managed co-operatively by a 370 group of UAs without any central control, this is outside the scope 371 of this draft. It is also possible that the Appearance Agent logic 372 could be distributed in all UAs in the group. For example, rules 373 that govern assigning appearance numbers for incoming requests (e.g. 374 lowest available appearance number) and rules for contention handling 375 (e.g. when two UAs request the use of the same appearance number, 376 hash dialog identifiers and compare with the lowest hash winning) 377 would need to be defined and implemented. 379 To best meet REQ-9, the appearance number for an incoming INVITE 380 needs to be contained in the INVITE, in addition to being delivered 381 in the dialog package NOTIFY. Otherwise, if the NOTIFY is delayed or 382 lost, a UA in the group might receive an incoming INVITE but might 383 not know which appearance number to render during alerting. 385 This specification defines an extension parameter for the Alert-Info 386 header field in RFC 3261 to carry the appearance number: 388 Alert-Info: ;appearance=1 390 The next section discusses the operations used to implement parts of 391 the shared appearance feature. 393 1. A UA is configured with the AOR of a shared appearance group. It 394 registers against the AOR, then attempts a dialog state 395 subscription to the AOR. If the subscription fails, loops back 396 to itself, or returns an error, it knows there is no State Agent, 397 and hence no Appearance Agent and this feature is not 398 implemented. 399 2. If the subscription receives a 200 OK, the UA knows there is a 400 State Agent and that the feature is implemented. The UA then 401 follows the steps in this list. 402 3. Information learned about the dialog state of other UAs in the 403 group is rendered to the user. 404 4. Incoming calls are forked to all UAs in the group, and any may 405 answer. UAs receive the appearance number to use in rendering 406 the incoming call in a NOTIFY from the Appearance Agent and in 407 the INVITE itself. The UA will also receive a notification if 408 the call is answered by another UA in the group so this 409 information can be rendered to the user. 410 5. For outgoing calls, the operation depends on the implementation. 411 If the user seizes a particular appearance number for the call, 412 the UA publishes the trying state dialog information with the 413 desired appearance number and waits for a 2xx response before 414 sending the INVITE. 415 6. For outgoing calls, if the user does not seize a particular 416 appearance or does not care, the INVITE can be sent immediately, 417 and the appearance number learned as the call progresses from a 418 notification from the Appearance Agent. 419 7. For outgoing calls, if the user does not want an appearance 420 number assigned (such as during a consultation call or if a UA is 421 fetching 'service media' such as music on hold 422 [I-D.worley-service-example]), the UA also publishes prior to 423 sending the INVITE but does not include an appearance number in 424 the publication. 426 8. Established calls within the group may be joined (bridged) or 427 taken (picked) by another UA. Information in the dialog package 428 notifications can be used to construct Join or Replaces header 429 fields. Since the same appearance number is used for these types 430 of operations, this information is published prior to sending the 431 INVITE Join or INVITE Replaces. 432 9. The Appearance Agent may not have direct access to the complete 433 dialog state of some or all of the UAs in the group. If this is 434 the case, the Appearance Agent will subscribe to the dialog state 435 of individual UAs in the group to obtain this information. In 436 any case, the Appearance Agent will send normal notifications 437 (via the subscriptions established by the UAs in step 1) every 438 time the aggregate dialog state of the AOR changes, including 439 when calls are placed, answered, placed on and off hold, and hung 440 up. 442 5. Normative Description 444 This section normatively describes the shared appearance feature 445 extensions. The following definitions are used throughout this 446 document: 448 Appearance number: An appearance number is a positive integer 449 associated with one or more dialogs of an AOR. Appearance numbers 450 are managed by an Appearance Agent and displayed and rendered to the 451 user by UAs that support this specification. When an appearance 452 number is assigned or requested, generally the assigned number is the 453 smallest positive integer that is not currently assigned as an 454 appearance number to a dialog for this AOR. 456 Seizing: An appearance can be reserved prior to a call being placed 457 by seizing the appearance. An appearance can be seized by 458 communicating an artificial state of "trying" prior to actually 459 initiating a dialog (i.e. sending the INVITE), in order to appear as 460 if it was already initiating a dialog. 462 Selecting(or Not-Seizing): An appearance is merely selected (i.e., 463 not seized) if there is no such communication of artificial state of 464 "trying" prior to initiating a dialog: i.e., the state is 465 communicated when the dialog is actually initiated. The appearance 466 number is learned after the INVITE is sent. 468 5.1. Elements 470 A complete system to implement this feature consists of: 472 1. User Agents that support publications, subscriptions, and 473 notifications for the SIP dialog event package, and the shared 474 appearance dialog package extensions and behavior. 475 2. An Appearance Agent consisting of a State Agent for the dialog 476 event package that implements an Event State Compositor (ESC) and 477 the shared appearance dialog package extensions and behavior. 478 The Appearance Agent also has logic for assigning and releasing 479 appearance numbers, and resolving appearance number contention. 480 3. A forking proxy server that can communicate with the State Agent 481 4. A registrar that supports the registration event package. 483 The behavior of these elements is described normatively in the 484 following sections after the definitions of the dialog package 485 extensions. 487 5.2. Shared Appearance Dialog Package Extensions 489 This specification defines four new elements as extensions to the SIP 490 Dialog Event package [I-D.ietf-sipcore-rfc3265bis]. The schema is 491 defined in Section 6. The elements are , , 492 , and which are sub-elements of the 493 element. 495 5.2.1. The element 497 The element, a child of the element, is used to 498 convey the appearance number of the dialog described by the parent 499 element. When sent by a UA in a PUBLISH with parent 500 with state attribute "trying" to the Appearance Agent, the 501 UA is requesting assignment of the given appearance number to the 502 current or future dialog with the given dialog identifiers. When an 503 element is sent by the Appearance Agent in a NOTIFY, it 504 indicates that the appearance number has been assigned to the 505 specified dialog. 507 Note that a element describes the contained dialogs 508 from the point of view of the UA (named by the "entity" attribute), 509 regardless of whether the containing request is sent by the UA or the 510 Appearance Agent. In particular, if the UA sent a request within the 511 described dialog, the To header field URI would match the 512 value and the to-tag parameter would match the remote-tag 513 attribute. Similarly, the From header field URI would match the 514 value and the from-tag parameter would match the 515 local-tag attribute. 517 5.2.2. The element 519 The element, a child of the element, is a 520 boolean, which when true, indicates that the UA is willing to accept 521 an INVITE with a Join or Replaces header field targeted to the dialog 522 described by the element that is the parent of the 523 element. For example, some shared appearance systems 524 only allow call pickup when the call is on hold. In this case, the 525 element should be set to "true" when the call is held and 526 "false" when the call is not held, rather than having the "exclusive" 527 value implied by the hold state. 529 It is important to note that this element is a hint. In order to 530 prevent another UA from taking or joining a call, a UA can, in 531 addition to setting the tag, not report full dialog 532 information to the Appearance Agent. Not having the full dialog 533 information (Call-ID, remote-tag, and local-tag) prevents another UA 534 from constructing a Join or Replaces header field. Although a UA may 535 set exclusive to true, the UA must still be ready to reject an INVITE 536 Join relating to this dialog. If these dialog identifiers have 537 already been shared with the Appearance Agent, the UA could send an 538 INVITE Replaces to change them and then not report the new ones to 539 the Appearance Agent. 541 If the proxy knows which dialogs are marked exclusive, the proxy MAY 542 enforce this exclusivity by rejecting INVITE Join and INVITE Replaces 543 requests containing those dialog identifiers with a 403 Forbidden 544 response. 546 Note that exclusivity has nothing to do with appearance number 547 selection or seizing - instead, it is about call control 548 operations that can be performed on a dialog. 550 If the element is not present, it is assumed to be false. 552 5.2.3. The element 554 The element, a child of the element, is used 555 to convey dialog identifiers of any other dialogs which are joined 556 (mixed or bridged) with the dialog. Only the UA which is the common 557 endpoint of the mixed dialogs (and thus controlling the mixing 558 operation) should include this element in publications to the 559 Appearance Agent. Note that this element should still be used even 560 when the Join header field was not used to join the dialogs. For 561 example, two separate dialogs on a UA could be joined without any SIP 562 call control operations. Joined dialogs will share the same 563 appearance number. 565 If the element is not present, it is assumed that the 566 dialog is not joined or to be joined to any other dialog. 568 5.2.4. The element 570 The element, a child of the element, is 571 used to convey dialog identifiers of any other dialogs which will be 572 or have been replaced with this dialog. For example, a UA in the 573 group picking up a call on another UA by sending an INVITE with 574 Replaces would include this element for the replacing dialog. 575 Replaced dialogs will share the same appearance number. 577 If the element is not present, it is assumed that 578 the dialog has not replaced or is not to replace to any other dialog. 580 5.3. Shared Appearance User Agents 582 User Agents that support the Shared Appearance feature MUST support 583 the dialog state package [RFC4235] with the shared appearance 584 extensions and the 'shared' dialog event package parameter defined in 585 Section 13. 587 User Agents MUST support the dialog package extensions in Section 5.2 588 along with SUBSCRIBE and NOTIFY [I-D.ietf-sipcore-rfc3265bis] and 589 PUBLISH [RFC3903]. SUBSCRIBE, NOTIFY, and PUBLISH requests for the 590 dialog event package MUST include the 'shared' Event header field 591 parameter. 593 The presence of the 'shared' Event package parameter tells the 594 Appearance Agent that this UA supports this specification. 596 Upon initialization, the UA MUST subscribe to the dialog event 597 package of the AOR and refresh the subscription per the SIP Events 598 Framework. If the SUBSCRIBE request fails, then no Appearance Agent 599 may be present and this feature is not active for this AOR. The UA 600 MAY periodically retry the subscription to see if conditions have 601 changed at intervals no shorter than 4 hours. 603 User Agents which implement call pickup, joining and bridging MUST 604 support sending an INVITE with Replaces [RFC3891] or Join [RFC3911]. 605 The User Agent Client needs to include the to-tag and from-tag 606 information in the Replaces or Join header so that the correct dialog 607 will be matched by the User Agent Server per the rules in RFC 3891 608 and RFC 3911. All User Agents supporting INVITE MUST support 609 receiving an INVITE with a Replaces [RFC3891] or a Join [RFC3911] 610 header field. 612 When publishing or notifying dialog package information, a UA MUST 613 include all dialog identification available at the time of 614 publication, with the exception that a UA may omit information if it 615 wishes to prevent other UAs from joining or picking up a call. 616 Dialog identification includes local and remote target URIs, call-id, 617 to-tag, and from-tag. When calls are placed on hold, the 618 "+sip.rendering=no" feature tag MUST be included in dialog package 619 notifications. 621 The accurate rendering of the idle/active/alerting/hold state of 622 other UAs in the group is an important part of the shared 623 appearance feature. 625 In the following cases, before sending the INVITE, A UA MUST send a 626 dialog package PUBLISH request and wait for a 2xx response before 627 proceeding: 629 1. When the user seizes a particular appearance number for an 630 outgoing call (e.g. seizing the appearance and going "off-hook", 631 if the UA's user interface uses this metaphor). 632 2. When the user has requested that an appearance number not be used 633 for an outgoing call (i.e. during a consultation call, a 'service 634 media' call such as for music on hold 635 [I-D.worley-service-example] or for a call not considered part of 636 the shared appearance group). 637 3. When the user has selected to join (or bridge) an existing call. 638 4. When the user has selected to replace (or take) an existing call. 640 An exception is an emergency call, when a UA MUST never wait for a 641 confirmed seizure before sending an INVITE. Instead, the emergency 642 call MUST proceed without waiting for the PUBLISH transaction. 644 Note that when a UA seizes an appearance prior to establishment of a 645 dialog (#1 and #2 in above list), not all dialog information will be 646 available. In particular, when a UA publishes an attempt to seize an 647 appearance prior to knowing the destination URI, minimal or no dialog 648 information may be available. For example, in some cases, only the 649 local target URI for the call will be known and no dialog 650 information. If the From tag and Call-ID were not present in the 651 initial PUBLISH, a new PUBLISH MUST be sent as soon as this 652 information is available. 654 The first publication will cause the Appearance Agent to reserve 655 the appearance number for this UA. If the publication does not 656 have any dialog identifiers (e.g. Call-ID, or local tag) the 657 Appearance Agent cannot assign the appearance number to a 658 particular dialog of the UA until the second publication which 659 will contain some dialog identifiers. 661 This publication state is refreshed as described in [RFC3903] during 662 the early dialog state or the Appearance Agent may reassign the 663 appearance number. Once the dialog has transitioned to the confirmed 664 state, no publication refreshes are necessary. 666 This specification assumes that the Appearance Agent has other 667 means besides UA publication to learn about the state of UA 668 dialogs. In this specification, PUBLISH is used to indicate 669 desired and intended appearance number operations. Once a dialog 670 transitions from early to confirmed, this role is over, and hence 671 no publication refreshes are needed. 673 Appearance numbers are a shorthand label for active and pending 674 dialogs related to an AOR. Many of the features and services built 675 using this extension rely on the correct rendering of this 676 information to the human user. In addition, the group nature of the 677 feature means that the rendering must be similar between different 678 vendors and different models. Failure to do so will greatly reduce 679 the value and usefulness of these protocol extensions. The 680 appearances number for each active and pending dialog SHOULD be 681 explicitly (i.e. by appearance number) or implicitly (using a user 682 interface metaphor that makes the numbering and ordering clear to the 683 user) rendered to the user. The far end identity of each dialog 684 (e.g. the remote party identity) MUST NOT be rendered in place of the 685 appearance number. The state of each appearance SHOULD also be 686 rendered (idle, active, busy, joined, etc.). UAs can tell that a set 687 of dialogs are joined (bridged or mixed) together by the presence of 688 one or more elements containing other SIP dialog 689 identifiers. Appearance numbers of dialogs can be learned by dialog 690 package notifications containing the element from the 691 Appearance Agent or from the 'appearance' Alert-Info parameter in an 692 incoming INVITE. Should they conflict, the dialog package 693 notification takes precedence. 695 A UA that does not need to seize a particular appearance number (or 696 doesn't care) would just send an INVITE as normal to place an 697 outbound call. 699 A user may select an appearance number but then abandon placing a 700 call (go back on hook). In this case, the UA MUST free up the 701 appearance number by removing the event state with a PUBLISH as 702 described in [RFC3903]. 704 A UA SHOULD register against the AOR only if it is likely the UA will 705 be answering incoming calls. If the UA is mainly going to be 706 monitoring the status of the shared appearance group calls and 707 picking or joining calls, the UA SHOULD only subscribe to the AOR and 708 not register against the AOR. 710 All subscribed UAs will receive dialog package NOTIFYs of Trying 711 state for incoming INVITEs. 713 5.3.1. Appearance Numbers and Call Context 715 There are cases where two separate dialogs at a UA are not mixed but 716 share the same 'context'. That is, they relate to each other and 717 should not be treated the same as any other two dialogs within the 718 group. One example of this is a 'consultation call' where a user 719 puts an existing dialog on hold, then calls another user, before 720 switching back to the original dialog. Another case, described 721 below, occurs during transfer operations, where for a transient 722 period, a UA is invovled in dialogs with two other UAs, but the 723 dialogs are related, and should not be treated as independent 724 dialogs. These cases are best handled by not assigning an appearance 725 number to a newly-created dialog when it shares a context with an 726 existing dialog. But if the pre-existing dialog is terminated, its 727 appearance number should be reassigned to the newly-created dialog. 729 A UA wanting to place a call but not have an appearance number 730 assigned publishes before sending the INVITE without an 'appearance' 731 element but with the 'shared' event package parameter present. If 732 the Appearance Agent policy does not allow calls without an assigned 733 appearance number, a 400 response is sent by the Appearance Agent and 734 the UA will republish either selecting/seizing an appearance number 735 or send the INVITE without publishing, in which case the Appearance 736 Agent will assign one. 738 Note that if an Appearance Agent rejects calls without an 739 appearance number, certain operations such as consultation calls, 740 transfer, and music on hold may be impacted. 742 5.3.2. Appearance Numbers and Call Control 744 When an INVITE is generated to attempt to bridge or take a call (i.e. 745 contains Join or Replaces with a dialog identifier of another dialog 746 in the shared appearance group), the UA MUST first send a PUBLISH to 747 the Appearance Agent. This PUBLISH will contain: 749 1. The appearance number of the joined or replaced call in the 750 element 751 2. If the dialog is being joined, the element will 752 contain the dialog information from the Join header field 753 3. If the dialog is being replaced, the element 754 will contain the dialog information from the Replaces header 755 field 757 Note that this information is provided to the Appearance Agent so 758 that it can provide proper appearance assignment behavior. If the 759 INVITE Join or Replaces was sent without publishing first, the 760 Appearance Agent might assign a new appearance number to this 761 INVITE, which would be a mistake. With Join, the publication has 762 the element to prevent the Appearance Agent from 763 generating a 400 response due to the reuse of an appearance 764 number. For Replaces, the purpose of the is to 765 prevent a race condition where the BYE could cause the appearance 766 number to be released when it should stay with the replacing 767 dialog. 769 5.3.3. Appearance Numbers and Transfer 771 During a transfer operation, it is important that the appearance 772 number not change during the operation. Consider the example of 773 Alice, a member of an appearance group, who is talking to Carol, who 774 is outside the appearance group. Carol transfers Alice to David, who 775 is also outside the appearance group. For example, if Alice is using 776 appearance 3 for the session with Carol, the resulting session with 777 David should also use appearance number 3. Otherwise, an appearance 778 number change can cause a "jump" on the UI and confusion to the user. 779 There are two possible scenarios using the terminology of RFC 5589: 780 Alice is the transferee in any type of transfer (receives the REFER) 781 or the transfer target in an attended transfer (receives the INVITE 782 with Replaces). 784 If Alice is the transferee, the triggered INVITE from the REFER is 785 treated as a consultation call. Alice SHOULD publish requesting that 786 the Appearance Agent not assign an appearance number for this INVITE. 787 When the transfer completes, Alice SHOULD publish again to move the 788 appearance number from the dialog with Carol to the dialog with 789 David. Note that this publication MUST be sent prior to sending the 790 BYE to Carol to avoid a race condition where the Appearance Agent 791 reassigns the appearance number after seeing the BYE. 793 If Alice is the target, the incoming INVITE will contain a Replaces 794 header field. As a result, the Appearance Agent will have reused the 795 appearance number of the dialog with Carol, and this appearance 796 number will continue to be used after the dialog with Carol has been 797 terminated. 799 5.4. Appearance Agent 801 An Appearance Agent defined in this specification MUST implement a 802 dialog package state agent for the UAs registered against the AOR. 803 The Appearance Agent MUST support the appearance dialog package 804 extensions defined in Section 5.2. The Appearance Agent MUST support 805 publications and subscriptions for this event package. 807 The Appearance Agent MUST have a way of discovering the state of all 808 dialogs associated with the AOR. If this information is not 809 available from a call stateful proxy or B2BUA, the Appearance Agent 810 MAY use the registration event package [RFC3680] to learn of UAs 811 associated with the AOR and MAY subscribe to their dialog event 812 state. Also, an Appearance Agent MAY subscribe to a UAs dialog event 813 state in order to reconstruct state. As a result, the registrar MUST 814 support the registration event package. Dialog package notifications 815 are recommended by RFC 4235 to "only contain information on the 816 dialogs whose state or participation information has changed." This 817 specification extends RFC 4235 as follows. The Appearance Agent 818 SHOULD send dialog event state notifications whenever the following 819 events happen to UAs in the AOR group: 821 1. A call is received, placed, answered, or terminated. 822 2. A call is placed on or off hold. 823 3. A call is joined or replaced. 824 4. An appearance number is reserved or released. 826 The Appearance Agent MUST allocate an appearance number for all 827 incoming calls and send immediate notifications to the UAs subscribed 828 to the shared group AOR. A new appearance number is allocated except 829 for an incoming INVITE with a Join or Replaces header field. For 830 this case, the appearance number should match the appearance number 831 of the dialog being joined or replaced. If the INVITE Replaces or 832 Join comes from outside the appearance group, the Appearance Agent 833 will include a or element in the 834 NOTIFY containing the dialog information from the Replaces or Joined 835 header field. 837 The Appearance Agent MUST be able to communicate with the forking 838 proxy to learn about incoming calls and also to pass the appearance 839 number to the proxy to insert in the Alert-Info header field. 841 Note that UAs need to be able to handle incoming INVITEs without 842 an appearance number assigned. This could be caused by a failure 843 of the Appearance Agent or other error condition. Although the 844 proper rendering of the INVITE may not be possible, this is better 845 than ignoring or failing the INVITE. 847 An Appearance Agent SHOULD assign an appearance number to an outgoing 848 dialog if a PUBLISH has not been received selecting/seizing a 849 particular appearance number. 851 Note that if the appearance group has appearance-unaware UAs 852 making calls, the Appearance Agent will still allocate appearance 853 numbers for INVITEs sent by those UAs. 855 An Appearance Agent receiving a PUBLISH with an appearance number 856 checks to make sure the publication is valid. An appearance number 857 can be assigned to only one dialog unless there is a 858 or element indicating that the dialog will be/has 859 been replaced or joined. A 400 response is returned if the chosen 860 appearance number is invalid, and an immediate NOTIFY should be sent 861 to the UA containing full dialog event state. 863 An Appearance Agent receiving a PUBLISH without an appearance number 864 but with the 'shared' event package parameter present interprets this 865 as a request by the UA to not assign an appearance number. If the 866 Appearance Agent policy does not allow this, a 400 response is 867 returned. If policy does allow this, a 200 OK response is returned 868 and no appearance number is allocated. An Appearance Agent does not 869 have to share this dialog information (i.e. send a NOTIFY) with other 870 UAs in the group as the information will not be rendered by the other 871 UAs. 873 The Appearance Agent allocates an apperance number to a dialog from 874 the time the appearance is requested via a PUBLISH or from the 875 receipt of an INVITE, to the time when the last dialog associated 876 with the appearance is terminated, including all dialogs which are 877 joined or replaced. During the early dialog state, the Appearance 878 Agent controls the rate of dialog state publication using the Expires 879 header field in 200 OK responses to PUBLISH requests. An interval of 880 3 minutes is RECOMMENDED. After the dialog associated with the 881 publication has been confirmed, the expiration of the publication 882 state has no effect on the appearance allocation. If the publication 883 contains no dialog state information, the Appearance Agent MUST 884 reserve the appearance number for the UA but can not assign the 885 appearance to any particular dialog of the UA. When the publication 886 state is updated with any dialog information, the appearance number 887 can then be assigned to the particular dialog. A UA which has been 888 allocated an appearance number using a PUBLISH MAY free up the 889 appearance number by removing the event state with a PUBLISH as 890 described in [RFC3903]. 892 If an INVITE is sent by a member of the group using the shared AOR or 893 sent to the shared AOR and no appearance number is available, the 894 proxy MAY reject the INVITE with a 403 Forbidden response code. 896 Appearance numbers are only used for dialogs in which one UA 897 associated with the group AOR is a participant. If an incoming 898 INVITE to the group AOR is forwarded to another AOR, the appearance 899 number is immediately freed up and can be assigned to another dialog. 901 6. XML Schema Definition 903 The 'appearance', 'joined-dialog', 'replaced-dialog', and 'exclusive' 904 elements are defined within a new XML namespace URI. This namespace 905 is "urn:ietf:params:xml:ns:sa-dialog-info". The schema for these 906 elements is: 908 909 915 917 918 920 922 924 925 927 929 930 932 934 936 937 939 940 941 942 944 945 946 947 948 950 7. Alert-Info Appearance Parameter Definition 952 This specification extends RFC 3261 [RFC3261] to add an 'appearance' 953 parameter to the Alert-Info header field, and to also allow proxies 954 to modify or delete the Alert-Info header field. 956 The changes to RFC 3261 ABNF are: 958 alert-param = LAQUOT absoluteURI RAQUOT *( SEMI 959 (generic-param / appearance-param) ) 960 appearance-param = "appearance" EQUAL 1*DIGIT 962 A proxy inserting an 'appearance' Alert-Info parameter follows normal 963 policies Alert-Info policies. If an Alert-Info is already present, 964 the proxy either removes the Alert-Info if it is not trusted, or adds 965 the 'appearance' parameter to the Alert-Info header field. If an 966 appearance number parameter is already present (associated with 967 another AOR or by mistake), the value is rewritten adding the new 968 appearance number. There MUST NOT be more than one appearance 969 parameter in an Alert-Info header field. 971 If no special ringtone is desired, a normal ringtone should be 972 indicated using the urn:alert:service:normal in the Alert-Info, as 973 per [I-D.ietf-salud-alert-info-urns]. The appearance number present 974 in an Alert-Info header field SHOULD be rendered by the UA to the 975 user, following the guidelines in Section 5.3. If the INVITE is 976 forwarded to another AOR, the appearance parameter in the Alert-Info 977 SHOULD be removed before forwarding outside the group. 979 The determination as to what value to use in the appearance parameter 980 can be done at the proxy that forks the incoming request to all the 981 registered UAs. 983 There are a variety of ways the proxy can use to determine what 984 value it should use to populate this parameter. For example, the 985 proxy could fetch this information by initiating a SUBSCRIBE 986 request with Expires: 0 to the Appearance Agent for the AOR to 987 fetch the list of lines that are in use. Alternatively, it could 988 act like a UA that is a part of the appearance group and SUBSCRIBE 989 to the State-Agent like any other UA. This would ensure that the 990 active dialog information is available without having to poll on a 991 need basis. It could keep track of the list of active calls for 992 the appearance AOR based on how many unique INVITE requests it has 993 forked to or received from the appearance AOR. Another approach 994 would be for the Proxy to first send the incoming INVITE to the 995 Appearance Agent which would redirect to the appearance group URI 996 and escape the proper Alert-Info header field for the Proxy to 997 recurse and distribute to the other UAs in the group. 999 The Appearance Agent needs to know about all incoming requests to 1000 the AOR in order to seize the appearance number. One way in which 1001 this could be done is for the Appearance Agent to register against 1002 the AOR with a higher q value. This will result in the INVITE 1003 being sent to the Appearance Agent first, then being offered to 1004 the UAs in the group. 1006 8. User Interface Considerations 1008 The "appearance number" allocated to a call is an important concept 1009 that enables calls to be handled by multiple devices with 1010 heterogeneous user interfaces in a manner that still allows users to 1011 see a consistent model. Careful treatment of the appearance number 1012 is essential to meet the expectations of the users. Also, rendering 1013 the correct call/appearance state to users is also important. 1015 8.1. Appearance Number Rendering 1017 Since different UAs have different user interface capabilities, it is 1018 usual to find that some UAs have restrictions that others do not. 1019 Perfect interoperability across all UAs is clearly not possible, but 1020 by careful design, interoperability up to the limits of each UA can 1021 be achieved. 1023 The following guidelines suggest how the appearance number should be 1024 handled in three typical user interface implementations. 1026 8.1.1. Single Appearance UAs 1028 These devices are constrained by only having the capability of 1029 displaying status indications for a single appearance. The UA should 1030 still send messages annotated with appearance number "1". Any call 1031 indications for appearances other than for number "1" should be 1032 rejected with a 486 or 480 response. 1034 8.1.2. Dual Appearance UAs 1036 These devices are essentially single appearance phones that implement 1037 call waiting. They have a very simple user interface that allows 1038 them to switch between two appearances (toggle or flash hook) and 1039 perhaps audible tones to indicate the status of the other appearance. 1040 Only appearance numbers "1" and "2" will be used by these UAs. 1042 8.1.3. Shared Appearance UAs with Fixed Appearance Number 1044 This UA is the typical 'business-class' hard-phone. A number of 1045 appearances are typically configured statically and labeled on 1046 buttons, and calls may be managed using these configured appearances. 1047 Any calls outside this range should be rejected, and not mapped to a 1048 free button. Users of these devices often seize specific appearance 1049 numbers for outgoing calls, and the UA will need to seize the 1050 appearance number and wait for confirmation from the Appearance Agent 1051 before proceeding with calls. 1053 8.1.4. Shared Appearance UAs with Variable Appearance Number 1055 This UA is typically a soft-phone or graphically rich user interface 1056 hard-phone. In these cases, even the idea of an appearance index may 1057 seem unnecessary. However, for these phones to be able to interwork 1058 successfully with other phone types, it is important that they still 1059 use the appearance index to govern the order of appearance of calls 1060 in progress. No specific guidance on presentation is given except 1061 that the order should be consistent. These devices can typically 1062 make calls without waiting for confirmation from the Appearance Agent 1063 on the appearance number. 1065 8.1.5. Example User Interface Issues 1067 The problems faced by each style of user interface are readily seen 1068 in this example: 1070 1. A call arrives at the shared appearance group, and is assigned an 1071 appearance number of "1". All UAs should be able to render to 1072 the user the arrival of this call. 1073 2. Another call arrives at the shared appearance group, and is 1074 assigned an appearance number of "2". The single appearance UA 1075 should not present this call to the user. Other user agents 1076 should have no problems presenting this call distinctly from the 1077 first call. 1078 3. The first call clears, releasing appearance number "1". The 1079 single appearance UA should now be indicating no calls since it 1080 is unable to manage calls other than on the first appearance. 1081 Both shared appearance UAs should clearly show that appearance 1082 number "1" is now free, but that there is still a call on 1083 appearance number "2". 1084 4. A third call arrives, and is assigned the appearance number of 1085 "1". All UAs should be able to render the arrival of this new 1086 call to the user. Multiple appearance UAs should continue to 1087 indicate the presence of the second call, and should also ensure 1088 that the presentation order is related to the appearance number 1089 and not the order of call arrival. 1091 8.2. Call State Rendering 1093 UAs that implement the shared appearance feature typically have a 1094 user interface that provides the state of other appearances in the 1095 group. As dialog state NOTIFYs from the Appearance Agent are 1096 processed, this information can be rendered. Even the simplest user 1097 interface typically has three states: idle, active, and hold. The 1098 idle state, usually indicated by lamp off, is indicated for an 1099 appearance when the appearance number is not associated with any 1100 dialogs, as reported by the Appearance Agent. The active state, 1101 usually indicated by a lamp on, is indicated by an appearance number 1102 being associated with at least one dialog, as reported by the 1103 Appearance Agent. The hold state, often indicated by a blinking 1104 lamp, means the call state from the perspective of the UA in the 1105 shared appearance group is hold. This can be determined by the 1106 presence of the "+sip.rendering=no" feature tag [RFC3840] with the 1107 local target URI. Note that the hold state of the remote target URI 1108 is not relevant to this display. For joined dialogs, the state is 1109 rendered as hold only if all local target URIs are indicated with the 1110 "+sip.rendering=no" feature tag. 1112 9. Interoperability with non-Shared Appearance UAs 1114 It is desirable to allow a basic UA that does not directly support 1115 shared appearance to be part of a shared appearance group. To 1116 support this the Proxy must collaborate with the Appearance Agent. 1117 This is not required in the basic shared appearance architecture, 1118 consequently shared appearance interoperability with non-shared 1119 appearance UAs will not be available in all shared appearance 1120 deployments. 1122 First, a UA which does not support dialog events or the shared 1123 appearance feature will be discussed. Then, a UA which does support 1124 dialog events but not the shared appearance feature will be 1125 discussed. 1127 9.1. Appearance Assignment 1129 A UA that has no knowledge of appearances must will only have 1130 appearance numbers for outgoing calls if assigned by the Appearance 1131 Agent. If the non-shared appearance UA does not support Join or 1132 Replaces, all dialogs could be marked "exclusive" to indicate that 1133 these options are not available. 1135 9.2. Appearance Release 1137 In all cases the Appearance Agent must be aware of dialog lifetime to 1138 release appearances back into the group. 1140 It is also desirable that any dialog state changes (such as hold, 1141 etc) be made available to other UAs in the group through the Dialog 1142 Event Package. If the Appearance Agent includes a proxy which 1143 Record-Routes for dialogs from the non-shared appearance aware UA, 1144 the Appearance Agent will know about the state of dialogs including 1145 hold, etc. This information could be determined from inspection of 1146 non-end-to-end-encrypted INVITE and re-INVITE messages and added to 1147 the dialog information conveyed to other UAs. 1149 9.3. UAs Supporting Dialog Events but Not Shared Appearance 1151 Interoperability with UAs which support dialog events but not the 1152 shared appearance feature is more straightforward. As before, all 1153 appearance number assignment must be done by the Appearance Agent. 1154 The Appearance Agent can include appearance information in NOTIFYs - 1155 this UA will simply ignore this extra information. This type of UA 1156 will ignore appearance number limitations and may attempt to Join or 1157 Replace dialogs marked exclusive. As a result, the Proxy or UAs need 1158 to reject such requests or the dialogs will get joined or taken. 1160 10. Provisioning Considerations 1162 UAs can automatically discover if this feature is active for an AOR 1163 by looking for the 'shared' Event header parameter in a response to a 1164 dialog package SUBSCRIBE to the AOR, so no provisioning for this is 1165 needed. 1167 The registrar will need to be provisioned to accept either first or 1168 third party registrations for the shared AOR. First party 1169 registration means the To and From URIs in the REGISTER request are 1170 the shared AOR URI. Third party registration means the To URI is the 1171 shared AOR URI and the From URI is a different AOR, perhaps that of 1172 the individual user. Either the credentials of the shared AOR or the 1173 user MUST be accepted by the registrar and the Appearance Agent, 1174 depending on the authorization policy in place for the domain. 1176 If the Appearance Agent needs to subscribe to the dialog state of the 1177 UAs, then the Appearance Agent and the UAs need to be provisioned 1178 with credentials so the UAs can authenticate the Appearance Agent. 1180 In some cases, UAs in the shared appearance group might have a UI 1181 limitation on the number of appearances that can be rendered. 1183 Typically this will be hard phones with buttons/lamps instead of more 1184 flexible UIs. In this case, it can be useful for the Appearance 1185 Agent to know this maximum number. This can allow the Appearance 1186 Agent to apply policy when this limit is reached, e.g. deny a call. 1187 However, this mechanism does not provide any way to discover this by 1188 protocol means. 1190 11. Example Message Flows 1192 The next section shows call flow and message examples. The flows and 1193 descriptions are non-normative. Note that in these examples, all 1194 INVITEs sent by a UA in the group will be From the shared AOR 1195 (sip:HelpDesk@example.com in this case), and all INVITES sent to the 1196 group will have a Request-URI of the shared AOR. Any other requests 1197 would not apply to this feature and would be handled using normal SIP 1198 mechanisms. 1200 Note that the first twelve examples assume the Appearance Agent is 1201 aware of dialog state events. The example in Section 11.13 shows the 1202 case where this is not the case and as a result the Appearance Agent 1203 initiates a subscription to users of the shared AOR. Any of the 1204 other call flow examples could have shown this mode of operation as 1205 it is equally valid. 1207 11.1. Registration and Subscription 1209 Bob and Alice are in an appearance group identified by the shared 1210 appearance AOR sip:HelpDesk@example.com. Bob REGISTERs using contact 1211 sip:bob@ua2.example.com. Alice REGISTERs with contact 1212 sip:alice@ua1.example.com. 1214 User Agents for Alice and Bob subscribe to the dialog package for the 1215 appearance AOR and publish dialog state to the Appearance Agent. 1216 Message exchanges between the Registrar, Appearance Agent, Alice, and 1217 Bob are shown below. The call flow examples below do not show the 1218 authentication of subscriptions, publications, and notifications. It 1219 should be noted that for security purposes, all subscriptions must be 1220 authorized before the SUBSCRIBE is accepted. 1222 Also note that registrations and subscriptions must all be refreshed 1223 by Alice at intervals determined by the expiration intervals returned 1224 by the Registrar or Appearance Agent. 1226 Registrar Appearance Agent Alice Bob 1227 | | | | 1228 | | | | 1229 |<--------------------------- REGISTER F1<| | 1230 | | | | 1231 |>F2 200 OK ----------------------------->| | 1232 | | | | 1233 | |<----- SUBSCRIBE F3<| | 1234 | | | | 1235 | |>F4 200 OK -------->| | 1236 | | | | 1237 | |>F5 NOTIFY -------->| | 1238 | | | | 1239 | |<-------- 200 OK F6<| | 1240 | | | | 1241 |<-------------------------------------------- REGISTER F7<| 1242 | | | | 1243 |>F8 200 OK ---------------------------------------------->| 1244 | | | | 1245 | |<---------------------- SUBSCRIBE F9<| 1246 | | | | 1247 | |>F10 200 OK ------------------------>| 1248 | | | | 1249 | |>F11 NOTIFY ------------------------>| 1250 | | | | 1251 | |<------------------------ 200 OK F12<| 1252 | | | | 1254 Figure 1. 1256 F1-F2: Alice registers AOR with 1257 contact: 1259 F1 Alice ----> Registrar 1261 REGISTER sip:registrar.example.com SIP/2.0 1262 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09 1263 From: ;tag=CDF9A668-909E2BDD 1264 To: 1265 CSeq: 2 REGISTER 1266 Call-ID: d3281184-518783de-cc23d6bb 1267 Contact: 1268 Max-Forwards: 70 1269 Expires: 3600 1270 Content-Length: 0 1272 F2 Registrar ----> Alice 1274 SIP/2.0 200 OK 1275 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09 1276 CSeq: 2 REGISTER 1277 Call-ID: d3281184-518783de-cc23d6bb 1278 From: ;tag=CDF9A668-909E2BDD 1279 To: ;tag=1664573879820199 1280 Contact: ;expires=3600 1281 Content-Length: 0 1283 F3 to F6: Alice also subscribes to the events associated with the 1284 Appearance AOR. Appearance Agent notifies Alice of the status. 1286 F3 Alice ----> Appearance Agent 1288 SUBSCRIBE sip:HelpDesk@example.com SIP/2.0 1289 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A 1290 From: ;tag=925A3CAD-CEBB276E 1291 To: 1292 CSeq: 91 SUBSCRIBE 1293 Call-ID: ef4704d9-bb68aa0b-474c9d94 1294 Contact: 1295 Event: dialog;shared 1296 Accept: application/dialog-info+xml 1297 Max-Forwards: 70 1298 Expires: 3700 1299 Content-Length: 0 1301 F4 Appearance Agent ----> Alice 1303 SIP/2.0 200 OK 1304 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A 1305 CSeq: 91 SUBSCRIBE 1306 Call-ID: ef4704d9-bb68aa0b-474c9d94 1307 From: ;tag=925A3CAD-CEBB276E 1308 To: ;tag=1636248422222257 1309 Allow-Events: dialog 1310 Expires: 3700 1311 Contact: 1312 Content-Length: 0 1314 F5 Appearance Agent ----> Alice 1316 NOTIFY sip:alice@ua1.example.com SIP/2.0 1317 From: ;tag=1636248422222257 1318 To: ;tag=925A3CAD-CEBB276E 1319 Call-ID: ef4704d9-bb68aa0b-474c9d94 1320 CSeq: 232 NOTIFY 1321 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1846 1322 Max-Forwards: 70 1323 Content-Type: application/dialog-info+xml 1324 Event: dialog;shared 1325 Subscription-State: active;expires=3000 1326 Contact: 1327 Content-Length: ... 1329 1330 1334 1336 F6 Alice ----> Appearance Agent 1338 SIP/2.0 200 OK 1339 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1846 1340 From: ;tag=1636248422222257 1341 To: ;tag=925A3CAD-CEBB276E 1342 CSeq: 232 NOTIFY 1343 Call-ID: ef4704d9-bb68aa0b-474c9d94 1344 Contact: 1345 Content-Length: 0 1347 F7 Bob ----> Registrar 1349 REGISTER sip:registrar.example.com SIP/2.0 1350 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4b53b54d87B 1351 From: ;tag=34831131 1352 To: 1353 CSeq: 72 REGISTER 1354 Call-ID: 139490230230249348 1355 Contact: 1356 Max-Forwards: 70 1357 Expires: 3600 1358 Content-Length: 0 1360 F8 Registrar ----> Bob 1362 SIP/2.0 200 OK 1363 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4b53b54d87B 1364 From: ;tag=34831131 1365 To: ;tag=fkwlwqi1 1366 CSeq: 72 REGISTER 1367 Call-ID: 139490230230249348 1368 Contact: ;expires=3200 1369 Contact: ;expires=3600 1370 Content-Length: 0 1372 11.2. Appearance Selection for Incoming Call 1374 In the call flow below Bob and Alice are in an appearance group. 1375 Carol places a call to the appearance group AOR. The Appearance 1376 Agent sends NOTIFYs to Alice and Bob telling them what appearance the 1377 call is using. Both Alice and Bob's devices are alerted of the 1378 incoming call. Bob answers the call. 1380 Note that it is possible that both Alice and Bob answer the call and 1381 send 200 OK responses to Carol. It is up to Carol to resolve this 1382 situation. Typically, Carol will send ACKs to both 200 OKs but send 1383 a BYE to terminate one of the dialogs. As a result, either Alice or 1384 Bob will receive the BYE and publish that their dialog is over. 1385 However, if Carol answers both Alice and Bob and keeps both dialogs 1386 active, then the Appearance Agent will need to resolve the situation 1387 by moving either Alice or Bob's dialog to a different appearance. 1389 All NOTIFY messages in the call flow below carry dialog events and 1390 only dialog states are mentioned for simplicity. For brevity, the 1391 details of some messages are not shown below. Note that the order of 1392 F2 - F5 and F7 - F8 could be reversed. 1394 Forking Appearance 1395 Carol Proxy Agent Alice Bob 1396 | | | | | 1397 |>F1 INVITE >| | | | 1398 | |< - - - - - >| | | 1399 | | |>F2 NOTIFY ----------->| 1400 | | | | | 1401 | | |F4 NOTIFY ->| | 1404 | | | | | 1405 | | |<-200 OK F5-<| | 1406 |<- 100 F6 -<| | | | 1407 | |>F7 INVITE (appearance=1) ---------->| 1408 | | | | | 1409 | |>F8 INVITE (appearance=1) >| | 1410 | | | | | 1411 | |<-------------------- Ringing 180 F9<| 1412 |< 180 F10 -<| | | | 1413 | |<--------- 180 Ringing F11<| | 1414 |< 180 F12 -<| | | | 1415 | | | | | 1416 | |<------------------------ 200 OK F13<| 1417 |< 200 F14 -<| | | | 1418 | | | | | 1419 | |>F15 CANCEL -------------->| | 1420 | | | | | 1421 | |<-------------- 200 OK F16<| | 1422 | | | | | 1423 | |F18 ACK ----------------->| | 1426 |>F19 ACK -->| | | | 1427 | |>F20 ACK --------------------------->| 1428 | | | | | 1429 |<=============Both way RTP established===========>| 1430 | | | | | 1431 | |< - - - - - >| | | 1432 | | | | | 1433 | | |>F21 NOTIFY >| | 1434 | | | | | 1435 | | |<- 200 F22 -<| | 1436 | | | | | 1437 | | |>F23 NOTIFY ---------->| 1438 | | | | | 1439 | | | Alice 1446 NOTIFY sip:alice@ua1.example.com SIP/2.0 1447 From: ;tag=151702541050937 1448 To: ;tag=18433323-C3D237CE 1449 Call-ID: 1e361d2f-a9f51109-bafe31d4 1450 CSeq: 12 NOTIFY 1451 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1403 1452 Max-Forwards: 70 1453 Content-Type: application/dialog-info+xml 1454 Event: dialog;shared 1455 Subscription-State: active;expires=2800 1456 Contact: 1457 Content-Length: ... 1459 1460 1465 1469 1 1470 trying 1471 1472 sip:carol@ua.example.com 1473 1474 1475 1477 F7 Proxy ----> Bob 1479 INVITE sip:bob@ua2.example.com SIP/2.0 1480 Via: SIP/2.0/UDP ua3.example.com;branch=z9hG4bK4324ea 1481 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK38432ji 1482 From: ;tag=44BAD75D-E3128D42 1483 To: 1484 CSeq: 106 INVITE 1485 Call-ID: 14-1541707345 1486 Contact: 1487 Max-Forwards: 69 1488 Alert-Info: ;appearance=1 1489 Content-Type: application/sdp 1490 Content-Length: ... 1492 v=0 1493 o=- 1102980499 1102980499 IN IP4 ua3.example.com 1494 s= 1495 c=IN IP4 ua3.example.com 1496 t=0 0 1497 m=audio 2238 RTP/AVP 0 8 101 1498 a=rtpmap:0 PCMU/8000 1499 a=rtpmap:8 PCMA/8000 1500 a=rtpmap:101 telephone-event/8000 1502 F21 Appearance Agent ----> Alice 1504 NOTIFY sip:alice@ua1.example.com SIP/2.0 1505 From: ;tag=151702541050937 1506 To: ;tag=18433323-C3D237CE 1507 Call-ID: 1e361d2f-a9f51109-bafe31d4 1508 CSeq: 13 NOTIFY 1509 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK4164F03j 1510 Max-Forwards: 70 1511 Content-Type: application/dialog-info+xml 1512 Event: dialog;shared 1513 Subscription-State: active;expires=2500 1514 Contact: 1515 Content-Length: ... 1517 1518 1523 1528 1 1529 confirmed 1530 1531 sip:bob@ua2.example.com 1532 1533 1534 sip:carol@ua.example.com 1535 1536 1537 1539 11.3. Outgoing Call without Appearance Seizure 1541 In this scenario, Bob's UA places a call without first selecting/ 1542 seizing an appearance number. After Bob sends the INVITE, the 1543 appearance assigns an appearance number for it and notifies both 1544 Alice and Bob. 1546 Carol Proxy Alice Appearance Agent Bob 1547 | | | | | 1548 | | | | | 1549 | |<------------------------------------- INVITE F1<| 1550 | | | | | 1551 | |>F2 100 Trying --------------------------------->| 1552 |<-- INVITE F3<| | | | 1553 | |< - - - - - - - - - - - - - ->| | 1554 | | | | | 1555 | | |<-- NOTIFY F4<| | 1556 | | | | | 1557 | | |>F5 200 OK -->| | 1558 | | | |------- NOTIFY F6>| 1559 | | | | | 1560 | | | |F8 180 ---->| | | | 1562 | |>F9 180 Ringing -------------------------------->| 1563 | | | | | 1564 | |< - - - - - - - - - - - - - ->| | 1565 | | | | | 1566 | | |<- NOTIFY F10<| | 1567 | | | | | 1568 | | |>F11 200 OK ->| | 1569 | | | |------ NOTIFY F12>| 1570 | | | | | 1571 | | | |F14 200 OK ->| | | | 1573 | |>F15 200 OK ------------------------------------>| 1574 | | | | | 1575 | |<--------------------------------------- ACK F16<| 1576 |<---- ACK F17<| | | | 1577 | | | | | 1578 |<================= Both way RTP established ===================>| 1579 | | | | | 1580 | |< - - - - - - - - - - - - - ->| | 1581 | | | | | 1582 | | |<- NOTIFY F18<| | 1583 | | | | | 1584 | | |>F19 200 OK ->| | 1585 | | | |------ NOTIFY F20>| 1586 | | | | | 1587 | | | | Proxy 1594 INVITE sip:carol@example.com SIP/2.0 1595 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK98c87c52123A08BF 1596 From: ;tag=15A3DE7C-9283203B 1597 To: 1598 CSeq: 1 INVITE 1599 Call-ID: f3b3cbd0-a2c5775e-5df9f8d5 1600 Contact: 1601 Max-Forwards: 70 1602 Content-Type: application/sdp 1603 Content-Length: 223 1605 v=0 1606 o=- 1102980499 1102980499 IN IP4 ua2.example.com 1607 s=IP SIP UA 1608 c=IN IP4 ua2.example.com 1609 t=0 0 1610 a=sendrecv 1611 m=audio 2236 RTP/AVP 0 8 101 1612 a=rtpmap:0 PCMU/8000 1613 a=rtpmap:8 PCMA/8000 1614 a=rtpmap:101 telephone-event/8000 1616 F4 Appearance Agent ----> Alice 1618 NOTIFY sip:alice@ua1.example.com SIP/2.0 1619 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK81d84f62 1620 From: ;tag=1636248422222257 1621 To: ;tag=925A3CAD-CEBB276E 1622 Call-ID: ef4704d9-bb68aa0b-474c9d94 1623 CSeq: 233 NOTIFY 1624 Max-Forwards: 70 1625 Content-Type: application/dialog-info+xml 1626 Event: dialog;shared 1627 Subscription-State: active;expires=2200 1628 Contact: 1629 Content-Length: ... 1631 1632 1637 1640 1 1641 false 1642 trying 1643 1644 1645 1646 1647 1648 1650 F6 Appearance Agent ----> Bob 1652 NOTIFY sip:bob@ua1.example.com SIP/2.0 1653 From: ;tag=497585728578386 1654 To: ;tag=633618CF-B9C2EDA4 1655 Call-ID: a7d559db-d6d7dcad-311c9e3a 1656 CSeq: 7 NOTIFY 1657 Via: SIP/2.0/UDP appearanceagent.example.com 1658 ;branch=z9hG4bK1711759878512309 1659 Max-Forwards: 70 1660 Content-Type: application/dialog-info+xml 1661 Event: dialog;shared 1662 Subscription-State: active;expires=2000 1663 Contact: 1664 Content-Length: ... 1666 1667 1672 1675 1 1676 false 1677 trying 1678 1679 1680 1681 1682 1683 1685 11.4. Outgoing Call with Appearance Seizure 1687 In this scenario, Bob's UA sends out a dialog event PUBLISH with 1688 state (trying) selecting/seizing an appearance number before sending 1689 the INVITE. After receiving the 200 OK from the Appearance Agent 1690 confirming the appearance number, Bob's UA sends the INVITE to Carol 1691 and establishes a session. For brevity, details of some of the 1692 messages are not included in the message flows. 1694 Carol Proxy Alice Appearance Agent Bob 1695 | | | | | 1696 | | | |<----- PUBLISH F1<| 1697 | | | | | 1698 | | | |>F2 200 OK ------>| 1699 | | | | | 1700 | | |<-- NOTIFY F3<| | 1701 | | | | | 1702 | | |>F4 200 OK -->| | 1703 | | | |------- NOTIFY F5>| 1704 | | | | | 1705 | | | |F8 100 Trying --------------------------------->| 1710 |<-- INVITE F9<| | | | 1711 | | | |<---- PUBLISH F10<| 1712 | | | | | 1713 | | | |>F11 200 OK ----->| 1714 | | | | | 1715 |>F12 180 --->| | | | 1716 | |>F13 180 Ringing ------------------------------->| 1717 | | | | | 1718 | |< - - - - - - - - - - - - - ->| | 1719 | | | | | 1720 | | |<- NOTIFY F14<| | 1721 | | | | | 1722 | | |>F15 200 OK ->| | 1723 | | | |------ NOTIFY F16>| 1724 | | | | | 1725 | | | |F18 200 OK ->| | | | 1727 | |>F19 200 OK ------------------------------------>| 1728 | | | | | 1729 | |<--------------------------------------- ACK F20<| 1730 |<---- ACK F21<| | | | 1731 | | | | | 1732 |<================= Both way RTP established ===================>| 1733 | | | | | 1734 | |< - - - - - - - - - - - - - ->| | 1735 | | | | | 1736 | | |<- NOTIFY F22<| | 1737 | | | | | 1738 | | |>F23 200 OK ->| | 1739 | | | |------ NOTIFY F24>| 1740 | | | | | 1741 | | | | Appearance Agent 1754 PUBLISH sip:HelpDesk@example.com SIP/2.0 1755 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 1756 From: ;tag=44150CC6-A7B7919D 1757 To: 1758 CSeq: 7 PUBLISH 1759 Call-ID: 44fwF144-F12893K38424 1760 Contact: 1761 Event: dialog;shared 1762 Max-Forwards: 70 1763 Content-Type: application/dialog-info+xml 1764 Content-Length: ... 1766 1767 1772 1773 1 1774 false 1775 trying 1776 1777 1778 1779 1780 1781 1783 F2 Appearance Agent ----> Bob 1785 SIP/2.0 200 OK 1786 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 1787 From: ;tag=44150CC6-A7B7919D 1788 To: 1789 CSeq: 7 PUBLISH 1790 Call-ID: 44fwF144-F12893K38424 1791 Contact: 1792 Event: dialog;shared 1793 SIP-Etag: 482943245 1794 Allow-Events: dialog 1795 Expires: 60 1796 Content-Length: 0 1798 F7 Bob ---> Proxy 1800 INVITE sip:carol@example.com SIP/2.0 1801 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK342122 1802 Max-Forwards: 70 1803 From: ;tag=15A3DE7C-9283203B 1804 To: 1805 Call-ID: f3b3cbd0-a2c5775e-5df9f8d5 1806 CSeq: 31 INVITE 1807 Contact: 1808 Content-Type: application/sdp 1809 Content-Length: ... 1811 (SDP Not Shown) 1813 F10 Bob ----> Appearance Agent 1815 PUBLISH sip:HelpDesk@example.com SIP/2.0 1816 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK6d644638E7 1817 From: ;tag=0CCf6-A7FdsB79D 1818 To: 1819 CSeq: 437 PUBLISH 1820 Call-ID: fwF14d4-F1FFF2F2893K38424 1821 Contact: 1822 Event: dialog;shared 1823 Max-Forwards: 70 1824 Content-Type: application/dialog-info+xml 1825 Content-Length: ... 1827 1828 1833 1837 1 1838 false 1839 trying 1840 1841 1842 1843 1844 1845 1846 1847 1848 1849 1851 11.5. Outgoing Call without using an Appearance Number 1853 In this scenario, Bob's UA sends out a dialog event PUBLISH with 1854 state (trying) indicating that he does not want to utilize an 1855 appearance number for this dialog. The PUBLISH does not have an 1856 appearance element but does have the 'shared' dialog event parameter. 1857 As a result, the Appearance Agent knows the UA does not wish to use 1858 an appearance number for this call. If the Appearance Agent does not 1859 wish to allow this, it would reject the PUBLISH with a 409 Conflict 1860 response and the UA would know to re-PUBLISH selecting/seizing an 1861 appearance number. 1863 Carol Proxy Alice Appearance Agent Bob 1864 | | | | | 1865 | | | |<----- PUBLISH F1<| 1866 | | | | | 1867 | | | |>F2 200 OK ------>| 1868 | | | | | 1869 | | |<-- NOTIFY F3<| | 1870 | | | | | 1871 | | |>F4 200 OK -->| | 1872 | | | |------- NOTIFY F5>| 1873 | | | | | 1874 | | | |F8 100 Trying --------------------------------->| 1879 |<-- INVITE F9<| | | | 1880 | | | |<---- PUBLISH F10<| 1881 | | | | | 1882 | | | |>F11 200 OK ----->| 1883 | | | | | 1884 |>F12 180 --->| | | | 1885 | |>F13 180 Ringing ------------------------------->| 1886 | | | | | 1887 | |< - - - - - - - - - - - - - ->| | 1888 | | | | | 1889 | | |<- NOTIFY F14<| | 1890 | | | | | 1891 | | |>F15 200 OK ->| | 1892 | | | |------ NOTIFY F16>| 1893 | | | | | 1894 | | | |F18 200 OK ->| | | | 1896 | |>F19 200 OK ------------------------------------>| 1897 | | | | | 1898 | |<--------------------------------------- ACK F20<| 1899 |<---- ACK F21<| | | | 1900 | | | | | 1901 |<================= Both way RTP established ===================>| 1902 | | | | | 1903 | |< - - - - - - - - - - - - - ->| | 1904 | | | | | 1905 | | |<- NOTIFY F22<| | 1906 | | | | | 1907 | | |>F23 200 OK ->| | 1908 | | | |------ NOTIFY F24>| 1909 | | | | | 1910 | | | | Appearance Agent 1917 PUBLISH sip:appearanceagent.example.com SIP/2.0 1918 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 1919 From: ;tag=4415df82k39sf 1920 To: 1921 CSeq: 7 PUBLISH 1922 Call-ID: 44fwF144-F12893K38424 1923 Contact: 1924 Event: dialog;shared 1925 Max-Forwards: 70 1926 Content-Type: application/dialog-info+xml 1927 Content-Length: ... 1929 1930 1935 1936 false 1937 trying 1938 1939 1940 1941 1942 1943 1945 Note that F7 would be the same as the previous example. 1947 11.6. Appearance Release 1949 Bob and Carol are in a dialog, created, for example as in 1950 Section 11.3. Carol sends a BYE to Bob to terminate the dialog and 1951 the Appearance Agent de-allocates the appearance number used, sending 1952 notifications out to the UAs in the shared group. 1954 Carol Proxy Alice Appearance Agent Bob 1955 | | | | | 1956 | | | | | 1957 |<================= Both way RTP established ===================>| 1958 | | | | | 1959 |>F22 BYE ---->| | | | 1960 | |>F23 BYE --------------------------------------->| 1961 | | | | | 1962 | |<------------------------------------ 200 OK F24<| 1963 |<--200 OK F25<| | | | 1964 | |< - - - - - - - - - - - - - ->| | 1965 | | | | | 1966 | | |<- NOTIFY F26<| | 1967 | | | | | 1968 | | |>F27 200 OK ->| | 1969 | | | |------ NOTIFY F28>| 1970 | | | | | 1971 | | | | Bob 1977 NOTIFY sip:bob@ua1.example.com SIP/2.0 1978 From: ;tag=497585728578386 1979 To: 1980 Call-ID: a7d559db-d6d7dcad-311c9e3a 1981 CSeq: 7 NOTIFY 1982 Via: SIP/2.0/UDP appearanceagent.example.com 1983 ;branch=z9hG4bK759878512309 1984 Max-Forwards: 70 1985 Content-Type: application/dialog-info+xml 1986 Event: dialog;shared 1987 Subscription-State: active;expires=1800 1988 Contact: 1989 Content-Length: ... 1991 1992 1997 2002 1 2003 false 2004 terminated 2005 2006 2007 2008 2009 2010 2012 11.7. Appearance Pickup 2014 In this scenario, Bob has an established dialog with Carol created 2015 using the call flows of Figure 1 or Figure 2. Bob then places Carol 2016 on hold. Alice receives a notification of this and renders this on 2017 Alice's UI. Alice subsequently picks up the held call and has a 2018 established session with Carol. Finally, Carol hangs up. Alice must 2019 PUBLISH F32 to indicate that the INVITE F38 will be an attempt to 2020 pickup the dialog between Carol and Bob, and hence may use the same 2021 appearance number. 2023 Carol Proxy Alice Appearance Agent Bob 2024 | | | | | 2025 |<================= Both way RTP established ===================>| 2026 | | | | | 2027 | |<------------------------------(hold) INVITE F22<| 2028 |<- INVITE F23<| | | | 2029 | | | | | 2030 |>F24 200 OK ->| | | | 2031 | |>F25 200 OK ------------------------------------>| 2032 | | | | | 2033 | |<--------------------------------------- ACK F26<| 2034 |<---- ACK F27<| | | | 2035 | |< - - - - - - - - - - - - - ->| | 2036 | | | | | 2037 | | |<- NOTIFY F28<| | 2038 | | | | | 2039 | | |>F29 200 OK ->| | 2040 | | | |>F30 NOTIFY ----->| 2041 | | | | | 2042 | | | |<----- 200 OK F31<| 2043 | | | | | 2044 | | Alice decides to pick up the call | 2045 | | | | | 2046 | | |>F32 PUBLISH->| | 2047 | | | | | 2048 | | |<- 200 OK F33<| | 2049 | | | | | 2050 | | |<- NOTIFY F34<| | 2051 | | | | | 2052 | | |>F35 200 OK ->| | 2053 | | | |>F36 NOTIFY ----->| 2054 | | | | | 2055 | | | |<----- 200 OK F37<| 2056 | |<-- INVITE F38<| | | 2057 |<- INVITE F39<|(w/ Replaces) | | | 2058 |( w/ Replaces)| | | | 2059 |>F40 200 OK ->| | | | 2060 | |>F41 200 OK -->| | | 2061 | | | | | 2062 | |< - - - - - - - - - - - - - ->| | 2063 | | | | | 2064 | | | |>F42 NOTIFY ----->| 2065 | | | | | 2066 | | | |<----- 200 OK F43<| 2067 | | |<- NOTIFY F44<| | 2068 | | | | | 2069 | | |>F45 200 OK ->| | 2070 | | | | | 2071 | |<----- ACK F46<| | | 2072 |<---- ACK F47<| | | | 2073 | | | | | 2074 |<= Both way RTP established =>| | | 2075 | | | | | 2076 |>F48 BYE ---->| | | | 2077 | |>F49 BYE --------------------------------------->| 2078 | | | | | 2079 | |<------------------------------------ OK 200 F50<| 2080 |<- 200 OK F51<| | | | 2081 | | | | | 2082 | |< - - - - - - - - - - - - - ->| | 2083 | | | | | 2084 | | |<- NOTIFY F52<| | 2085 | | | | | 2086 | | |>F53 200 OK ->| | 2087 | | | | | 2088 | | | |>F54 NOTIFY ----->| 2089 | | | | | 2090 | | | |<----- 200 OK F55<| 2092 Figure 7. 2094 F28 Appearance ----> Alice 2096 NOTIFY sip:alice@ua1.example.com SIP/2.0 2097 From: ;tag=151702541050937 2098 To: ;tag=18433323-C3D237CE 2099 Call-ID: 1e361d2f-a9f51109-bafe31d4 2100 CSeq: 12 NOTIFY 2101 Via: SIP/2.0/UDP appearanceagent.example.com 2102 ;branch=z9hG4bK1403 2103 Max-Forwards: 70 2104 Content-Type: application/dialog-info+xml 2105 Event: dialog;shared 2106 Subscription-State: active;expires=1800 2107 Contact: 2108 Content-Length: ... 2110 2111 2116 2121 1 2122 false 2123 active 2124 2125 2126 2127 2128 2129 2130 sip:carol@example.com 2131 2132 2133 2134 2136 F32 Alice ----> Appearance Agent 2138 PUBLISH sip:HelpDesk@example.com SIP/2.0 2139 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A 2140 From: ;tag=44150CC6-A7B7919D 2141 To: ;tag=428765950880801 2142 CSeq: 11 PUBLISH 2143 Call-ID: 87837Fkw87asfds 2144 Contact: 2145 Event: dialog;shared 2146 Max-Forwards: 70 2147 Content-Type: application/dialog-info+xml 2148 Content-Length: ... 2150 2151 2156 2159 1 2160 false 2161 2166 trying 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2178 F38 Alice ----> Proxy 2180 INVITE sip:carol@example.com SIP/2.0 2181 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK4ea695b5B376A60C 2182 From: ;tag=8C4183CB-BCEAB710 2183 To: 2184 CSeq: 1 INVITE 2185 Call-ID: 3d57cd17-47deb849-dca8b6c6 2186 Contact: 2187 2188 Replaces: f3b3cbd0-a2c5775e-5df9f8d5;to-tag=65a98f7c 2189 -1dd2-11b2-88c6-b03162323164+65a98f7c;from-tag=15A3DE7C-9283203B 2190 2191 Max-Forwards: 70 2192 Content-Type: application/sdp 2193 Content-Length: 223 2195 v=0 2196 o=- 1102980497 1102980497 IN IP4 ua1.example.com 2197 s=IP SIP UA 2198 c=IN IP4 ua1.example.com 2199 t=0 0 2200 a=sendrecv 2201 m=audio 2238 RTP/AVP 0 8 101 2202 a=rtpmap:0 PCMU/8000 2203 a=rtpmap:8 PCMA/8000 2204 a=rtpmap:101 telephone-event/8000 2206 11.8. Calls between UAs within the Group 2208 In this scenario, Bob calls Alice who is also in the Appearance 2209 group. Only one appearance number is used for this dialog. This 2210 example also shows the use of the 'exclusive' tag to indicate that 2211 other UAs in the group can not join or take this dialog. 2213 Carol Proxy Alice Appearance Agent Bob 2214 | | | | | 2215 | |<-------------------- INVITE (to Alice's UA) F1<| 2216 | | | | | 2217 | |< - - - - - - - - - - - - - ->| | 2218 | | | | | 2219 | | | | | 2220 | | |<-- NOTIFY F2<| | 2221 | | | | | 2222 | | |>F3 200 OK -->| | 2223 | | | |>F4 NOTIFY ------>| 2224 | | | | | 2225 | | | |<------ 200 OK F5<| 2226 | |>F6 INVITE --->| | | 2227 | | (appearance=1)| | | 2228 | | | | | 2229 | |<------ 180 F7<| | | 2230 | | | | | 2231 | |>F8 180 --------------------------------------->| 2232 | | | | | 2233 | |< - - - - - - - - - - - - - ->| | 2234 | | | | | 2235 | | |<-- NOTIFY F9<| | 2236 | | | | | 2237 | | |>F10 200 OK ->| | 2238 | | | |>F11 NOTIFY ----->| 2239 | | | | | 2240 | | | |<----- 200 OK F12<| 2241 | |<-- 200 OK F13<| | | 2242 | | | | | 2243 | |>F14 200 OK ------------------------------------>| 2244 | | | | | 2245 | |<--------------------------------------- ACK F15<| 2246 | | | | | 2247 | |>F16 ACK ----->| | | 2248 | | | | | 2249 | | |<======= RTP established =======>| 2250 | | | | | 2251 | |< - - - - - - - - - - - - - ->| | 2252 | | | | | 2253 | | |<- NOTIFY F17<| | 2254 | | | | | 2255 | | |>F18 200 OK ->| | 2256 | | | |>F19 NOTIFY ----->| 2257 | | | | | 2258 | | | |<----- 200 OK F24<| 2259 | | | | | 2261 Figure 8. 2263 F19 Appearance Agent ----> Bob 2265 NOTIFY sip:bob@ua1.example.com SIP/2.0 2266 From: ;tag=497585728578386 2267 To: ;tag=633618CF-B9C2EDA4 2268 Call-ID: a7d559db-d6d7dcad-311c9e3a 2269 CSeq: 7 NOTIFY 2270 Via: SIP/2.0/UDP appearanceagent.example.com 2271 ;branch=z9hG4bK1711759878512309 2272 Max-Forwards: 70 2273 Content-Type: application/dialog-info+xml 2274 Event: dialog;shared 2275 Subscription-State: active;expires=1500 2276 Contact: 2277 Content-Length: ... 2279 2280 2285 2290 true 2291 1 2292 confirmed 2293 2294 2295 2296 2297 2298 sip:HelpDesk@example.com 2299 2300 2301 2303 2308 true 2309 1 2310 confirmed 2311 2312 2313 2314 2315 sip:HelpDesk@example.com 2316 2317 2318 2320 2322 11.9. Consultation Hold with Appearances 2324 In this scenario, Bob has a call with Carol. Bob makes a 2325 consultation call to Alice by putting Carol on hold and calling 2326 Alice. Bob chooses not to have an appearance number for the call to 2327 Alice since he is treating it as part of the call to Carol. He 2328 indicates this in his PUBLISH F32 which contains the 'shared' Event 2329 parameter but no element. The PUBLISH is sent before 2330 the INVITE to Alice to ensure no appearance number is assigned by the 2331 Appearance Agent. Finally, Bob hangs up with Alice and resumes the 2332 call with Carol. Dialog notifications of the consultation call are 2333 not shown, as they are not used. 2335 Note that if Carol hangs up while Bob is consulting with Alice, Bob 2336 can decide if he wants to reuse the appearance number used with Carol 2337 for the call with Alice. If not, Bob publishes the termination of 2338 the dialog with Carol and the Appearance Agent will re-allocate the 2339 appearance. If he wants to keep the appearance, Bob will publish the 2340 termination of the dialog with Carol and also publish the appearance 2341 with the dialog with Alice. This will result in Bob keeping the 2342 appearance number until he reports the dialog with Alice terminated. 2344 Note that the call flow would be similar if Bob called a music on 2345 hold server instead of Alice to implement a music on hold service as 2346 described in [I-D.worley-service-example]. 2348 Carol Proxy Alice Appearance Agent Bob 2349 | | | | | 2350 |<================= Both way RTP established ===================>| 2351 | | | | | 2352 | |<------------------------------(hold) INVITE F22<| 2353 |<- INVITE F23<| | | | 2354 | | | | | 2355 |>F24 200 OK ->| | | | 2356 | |>F25 200 OK ------------------------------------>| 2357 | | | | | 2358 | |<--------------------------------------- ACK F26<| 2359 |<---- ACK F27<| | | | 2360 | |< - - - - - - - - - - - - - ->| | 2361 | | | | | 2362 | | |<- NOTIFY F28<| | 2363 | | | | | 2364 | | |>F29 200 OK ->| | 2365 | | | |>F30 NOTIFY ----->| 2366 | | | | | 2367 | | | |<----- 200 OK F31<| 2368 | | | | | 2369 | | Bob makes a consultation call to Alice | 2370 | | | | | 2371 | | | |<---- PUBLISH F32<| 2372 | | | | | 2373 | | | |>F33 200 OK ----->| 2374 | | | | | 2375 | |<------------------------------------ INVITE F34<| 2376 | | | | | 2377 | |>F35 INVITE -->| | | 2378 | | | | | 2379 | |<-- 200 OK F36<| | | 2380 | | | | | 2381 | |>F37 200 OK ------------------------------------>| 2382 | | | | | 2383 | |<--------------------------------------- ACK F38<| 2384 | | | | | 2385 | |>F39 ACK ----->| | | 2386 | | | | | 2387 | | |<======= RTP established =======>| 2388 | | | | | 2389 | | Bob hangs up with Alice | 2390 | | | | | 2391 | |<--------------------------------------- BYE F40<| 2392 | | | | | 2393 | |>F41 BYE ----->| | | 2394 | | | | | 2395 | |<-- 200 OK F42<| | | 2396 | | | | | 2397 | |>F43 200 OK ------------------------------------>| 2398 | | | | | 2399 | |<----------------------------(unhold) INVITE F44<| 2400 |<- INVITE F45<| | | | 2401 | | | | | 2402 |>F46 200 OK ->| | | | 2403 | |>F47 200 OK ------------------------------------>| 2404 | | | | | 2405 | |<--------------------------------------- ACK F48<| 2406 |<---- ACK F49<| | | | 2407 | |< - - - - - - - - - - - - - ->| | 2408 | | | | | 2409 | | |<- NOTIFY F50<| | 2410 | | | | | 2411 | | |>F51 200 OK ->| | 2412 | | | |>F52 NOTIFY ----->| 2413 | | | | | 2414 | | | |<----- 200 OK F53<| 2415 | | | | | 2416 |<================= Both way RTP established ===================>| 2417 | | | | | 2419 Figure 9. 2421 F32 Bob ----> Appearance Agent 2423 PUBLISH sip:HelpDesk@example.com SIP/2.0 2424 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A 2425 From: ;tag=44150CC6-A7B7919D 2426 To: ;tag=428765950880801 2427 CSeq: 11 PUBLISH 2428 Call-ID: 44fwF144-F12893K38424 2429 Contact: 2430 Event: dialog;shared 2431 Max-Forwards: 70 2432 Content-Type: application/dialog-info+xml 2433 Content-Length: ... 2435 2436 2441 2445 true 2446 trying 2447 2448 2449 2451 2452 2453 sip:HelpDesk@example.com 2454 2455 2456 2457 2459 11.10. Joining or Bridging an Appearance 2461 In this call flow, a call answered by Bob is joined by Alice or 2462 "bridged". The Join header field is used by Alice to request this 2463 bridging. If Bob did not support media mixing, Bob could obtain 2464 conferencing resources as described in [RFC4579]. 2466 Carol Forking Proxy Appearance Agent Alice Bob 2467 | | | | | 2468 |<=============Both way RTP established===========>| 2469 | | | | | 2470 | | |< PUBLISH F22| | 2471 | | | | | 2472 | | |>F23 200 OK >| | 2473 | | | | | 2474 | |<---- INVITE (w/ Join) F24<| | 2475 | | | | | 2476 | |>F25 INVITE (w/Join)---------------->| 2477 | | | | | 2478 | |<---- OK 200 Contact:Bob;isfocus F26<| 2479 | | | | | 2480 | |< - - - - - >| | | 2481 | | | | | 2482 | | |>F27 NOTIFY >| | 2483 | | | | | 2484 | | |< 200 OK F28<| | 2485 | | | | | 2486 | | |>F29 NOTIFY ---------->| 2487 | | | | | 2488 | | |F31 200 OK Contact:B----->| | 2491 | | | | | 2492 | |<----------------- ACK F32<| | 2493 | | | | | 2494 | |>ACK F33---------------------------->| 2495 | | | | | 2496 | |<-----INVITE Contact:Bob;isfocus F34<| 2497 |<-INVITE F35| | | | 2498 | | | | | 2499 |>F26 200 -->| | | | 2500 | |>F37 200 OK ------------------------>| 2501 | | | | | 2502 | |<--------------------------- ACK F38<| 2503 |<--- ACK F39| | | | 2504 | | | |<==RTP==>| 2505 |<=============Both way RTP established===========>| 2506 | | | | | 2507 | |< - - - - - >| | | 2508 | | | | | 2509 | | |>F40 NOTIFY >| | 2510 | | | | | 2511 | | |< 200 OK F41<| | 2512 | | | | | 2513 | | |>F42 NOTIFY ---------->| 2514 | | | | | 2515 | | | Appearance Agent 2522 PUBLISH sip:HelpDesk@example.com SIP/2.0 2523 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A 2524 From: ;tag=44150CC6-A7B7919D 2525 To: ;tag=428765950880801 2526 CSeq: 11 PUBLISH 2527 Call-ID: 87837Fkw87asfds 2528 Contact: 2529 Event: dialog;shared 2530 Max-Forwards: 70 2531 Content-Type: application/dialog-info+xml 2532 Content-Length: ... 2534 2535 2540 2543 1 2544 false 2545 2549 trying 2550 2551 2552 2553 2554 2555 2556 2557 2558 2560 F24 Alice ----> Proxy 2562 INVITE sip:bob@ua.example.com SIP/2.0 2563 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKcc9d727c2C29BE31 2564 From: ;tag=605AD957-1F6305C2 2565 To: 2566 CSeq: 2 INVITE 2567 Call-ID: dc95da63-60db1abd-d5a74b48 2568 Contact: 2569 2570 Join: 14-1541707345;to-tag=d3b06488-1dd1-11b2-88c5 2571 -b03162323164+d3e48f4c;from-tag=44BAD75D-E3128D42 2572 2573 Max-Forwards: 70 2574 Content-Type: application/sdp 2575 Content-Length: 223 2577 v=0 2578 o=- 1103061265 1103061265 IN IP4 ua1.example.com 2579 s=IP SIP UA 2580 c=IN IP4 ua1.example.com 2581 t=0 0 2582 a=sendrecv 2583 m=audio 2236 RTP/AVP 0 8 101 2584 a=rtpmap:0 PCMU/8000 2585 a=rtpmap:8 PCMA/8000 2586 a=rtpmap:101 telephone-event/8000 2588 11.11. Appearance Allocation - Loss of Appearance 2590 Bob reserves an appearance with a PUBLISH, sends an INVITE to Carol, 2591 then becomes unreachable. When he fails to refresh his publication 2592 to the appearance agent, the Appearance Agent declares the dialog 2593 terminated and frees up the appearance using NOTIFYs F14 and F16. 2595 After retransmitting the NOTIFY to Bob (in not shown messages F17, 2596 F18, etc.), the subscription is terminated. 2598 Carol Proxy Alice Appearance Agent Bob 2599 | | | | | 2600 | | | |<----- PUBLISH F1<| 2601 | | | | | 2602 | | | |>F2 200 OK ------>| 2603 | | | | | 2604 | | |<-- NOTIFY F3<| | 2605 | | | | | 2606 | | |>F4 200 OK -->| | 2607 | | | |------- NOTIFY F5>| 2608 | | | | | 2609 | | | |F8 100 Trying --------------------------------->| 2614 |<-- INVITE F9<| | | | 2615 | | | |<---- PUBLISH F10<| 2616 | | | | | 2617 | | | |>F11 200 OK ----->| 2618 | | | | | 2619 |>F12 180 --->| | | | 2620 | |>F13 180 Ringing ------------------------------->| 2621 | | | | | 2622 | | | | Bob goes offline | 2623 | | | | | 2624 | | | Appearance selection times out | 2625 | | | | | 2626 | | |<- NOTIFY F14<| | 2627 | | | | | 2628 | | |>F15 200 OK ->| | 2629 | | | |------ NOTIFY F16>| 2630 | | | | | 2631 | | | NOTIFY is retransmitted | 2633 Figure 11. 2635 11.12. Appearance Seizure Contention Race Condition 2637 Bob and Alice both try to reserve appearance 2 by publishing at the 2638 same time. The Appearance Agent allocates the appearance to Bob by 2639 sending a 200 OK and denies it to Alice by sending a 409 Conflict. 2640 After the NOTIFY F5, Alice learns that Bob is using appearance 2. 2641 Alice then attempts to reserve appearance 3 by publishing, which is 2642 then accepted. 2644 Carol Proxy Alice Appearance Agent Bob 2645 | | | | | 2646 | | | |<----- PUBLISH F1<| 2647 | | | | (appearance=2) 2648 | | |>F2 PUBLISH ->| | 2649 | | | (appearance=2) | 2650 | | | | | 2651 | | | |>F3 200 OK ------>| 2652 | | |<---- F4 409 <| | 2653 | | | | | 2654 | | |<-- NOTIFY F5<| | 2655 | | | | | 2656 | | |>F6 200 OK -->| | 2657 | | | |------- NOTIFY F7>| 2658 | | | | | 2659 | | | |F10 100 Trying -------------------------------->| 2664 |<- INVITE F11<| | | | 2665 | | | |<---- PUBLISH F12<| 2666 | | | | (appearance=2) 2667 | | | |>F13 200 OK ----->| 2668 | | |>F14 PUBLISH->| | 2669 | | | (appearance=3) | 2670 | | | | | 2671 | | |<--- F15 200 <| | 2672 | | | | | 2673 | | |<- NOTIFY F16<| | 2674 | | | | | 2675 | |>F17 200 OK ->| | 2676 Dave | | |------ NOTIFY F18>| 2677 | | | | | 2678 | | | |F21 100 ----->| | | 2682 |<- INVITE F22<| | | | 2684 Figure 12. 2686 11.13. Appearance Agent Subscription to UAs 2688 In this scenario, the Appearance Agent does not have any way of 2689 knowing Bob's dialog state information, except through Bob. This 2690 could be because the Appearance Agent is not part of a B2BUA, or 2691 perhaps Bob is remotely registering. When Bob registers, the 2692 Appearance Agent receives a registration event package notification 2693 from the registrar. The Appearance Agent then SUBSCRIBEs to Bob's 2694 dialog event state using Event:dialog in the SUBSCRIBE. Whenever 2695 Bob's dialog state changes, Bob's UA sends a NOTIFY to the Appearance 2696 Agent which then notifies the other other UAs in the group. 2698 Carol Proxy Alice Appearance Agent Bob 2699 | | | | | 2700 | |<----------------------------------- REGISTER F1<| 2701 | | | | | 2702 | |>F2 200 OK ------------------------------------->| 2703 | | | | | 2704 | |>F3 NOTIFY ------------------>| | 2705 | | | | | 2706 | |<------------------ 200 OK F4<| | 2707 | | | |---- SUBSCRIBE F5>| 2708 | | | | | 2709 | | | |F8 200 OK ------>| 2714 | | | | | 2715 | | | |<--- SUBSCRIBE F9<| 2716 | | | | | 2717 | | | |>F10 200 OK ----->| 2718 | | | | | 2719 | | | |------ NOTIFY F11>| 2720 | | | | | 2721 | | | |F14 100 Trying -------------------------------->| 2726 |<- INVITE F15<| | | | 2727 | | | |<----- NOTIFY F16<| 2728 | | | | | 2729 | | | |>F17 200 OK ----->| 2730 | | |<- NOTIFY F18<| | 2731 | | | | | 2732 | | |>F19 200 OK ->| | 2733 | | | |------ NOTIFY F20>| 2734 | | | | | 2735 | | | |F22 180 --->| | | | 2737 | |>F23 180 Ringing ------------------------------->| 2738 | | | | | 2739 | | | |<----- NOTIFY F24<| 2740 | | | | | 2741 | | | |>F25 200 OK ----->| 2742 | | |<- NOTIFY F26<| | 2743 | | | | | 2744 | | |>F27 200 OK ->| | 2745 | | | |------ NOTIFY F28>| 2746 | | | | | 2747 | | | |F30 200 OK ->| | | | 2749 | |>F31 200 OK ------------------------------------>| 2750 | | | | | 2751 | | | |<----- NOTIFY F32<| 2752 | | | | | 2753 | | | |>F33 200 OK ----->| 2754 | | | | | 2755 | |<--------------------------------------- ACK F34<| 2756 |<---- ACK F35<| | | | 2757 | | | | | 2758 |<================= Both way RTP established ===================>| 2759 | | | | | 2760 | | |<- NOTIFY F36<| | 2761 | | | | | 2762 | | |>F37 200 OK ->| | 2763 | | | |------ NOTIFY F38>| 2764 | | | | | 2765 | | | || 2783 | | | | | 2784 | |<------------------------------(hold) INVITE F22<| 2785 |<- INVITE F23<| | | | 2786 | | | | | 2787 |>F24 200 OK ->| | | | 2788 | |>F25 200 OK ------------------------------------>| 2789 | | | | | 2790 | |<--------------------------------------- ACK F26<| 2791 |<---- ACK F27<| | | | 2792 | | | | | 2793 | |< - - - - - - - - - - - - - ->| | 2794 | | | | | 2795 | | |<- NOTIFY F28<| | 2796 | | | | | 2797 | | |>F29 200 OK ->| | 2798 | | | |>F30 NOTIFY ----->| 2799 | | | | | 2800 | | | |<----- 200 OK F31<| 2801 | | | | | 2802 | | Alice decides to pick up the call | 2803 | | | | | 2804 | | |>F32 PUBLISH->| | 2805 | | | | | 2806 | | |<- 200 OK F33<| | 2807 | | | | | 2808 | | |<- NOTIFY F34<| | 2809 | | | | | 2810 | | |>F35 200 OK ->| | 2811 | | | |>F36 NOTIFY ----->| 2812 | | | | | 2813 | | | |<----- 200 OK F37<| 2814 |>F38 BYE ---->| | | | 2815 | |>F39 BYE --------------------------------------->| 2816 | | | | | 2817 | |<------------------------------------ OK 200 F40<| 2818 |<- 200 OK F41<| | | | 2819 | |<-- INVITE F42<| | | 2820 |<- INVITE F43<|(w/ Replaces) | | | 2821 |( w/ Replaces)| | | | 2822 | | | | | 2823 |>F44 481 ---->| | | | 2824 | |>F45 481 ----->| | | 2825 |<---- ACK F46<| | | | 2826 | |<----- ACK F47<| | | 2827 | | |>F48 PUBLISH->| | 2828 | | | | | 2829 | | |<- 200 OK F49<| | 2830 | | | | | 2831 | | |<- NOTIFY F50<| | 2832 | | | | | 2833 | | |>F51 200 OK ->| | 2834 | | | |>F52 NOTIFY ----->| 2835 | | | | | 2836 | | | |<----- 200 OK F53<| 2838 Figure 14. 2840 F48 Alice ----> Appearance Agent 2842 PUBLISH sip:HelpDesk@example.com SIP/2.0 2843 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A 2844 From: ;tag=44150CC6-A7B7919D 2845 To: ;tag=428765950880801 2846 CSeq: 11 PUBLISH 2847 Call-ID: 87837Fkw87asfds 2848 Contact: 2849 Event: dialog;shared 2850 Max-Forwards: 70 2851 Content-Type: application/dialog-info+xml 2852 Content-Length: ... 2854 2855 2860 2863 1 2864 false 2865 2869 terminated 2870 2871 2872 2873 2874 2875 2876 2878 2879 2881 11.15. Appearance Seizure Incoming/Outgoing Contention Race Condition 2883 Alice tries to seize appearance 2 at the same time appearance 2 is 2884 allocated to an incoming call. The Appearance Agent resolves the 2885 conflict by sending a 409 Conflict to Alice. After the NOTIFY F6, 2886 Alice learns that the incoming call is using appearance 2. Alice 2887 republishes for appearance 3, which is accepted. Note that this 2888 example shows the INVITE being received before the NOTIFY from the 2889 Appearance Agent. 2891 Carol Proxy Alice Appearance Agent Bob 2892 | | | | | 2893 |>-- INVITE F1>| | | | 2894 | |< - - - - - - - - - - - - - ->| | 2895 | | | | | 2896 | | |>F2 PUBLISH ->| | 2897 | | | (appearance=2) | 2898 | | | | | 2899 | |>F3 INVITE (appearance=2) ---------------------->| 2900 | | | | | 2901 | |>F4 INVITE | | | 2902 | |(appearance=2)>| | | 2903 | | |<---- F5 409 <| | 2904 | | | | | 2905 | | |<-- NOTIFY F6<| | 2906 | | | | | 2907 | | |>F7 200 OK -->| | 2908 | | | |------- NOTIFY F8>| 2909 | | | | | 2910 | | | |F10 PUBLISH->| | 2913 | | | (appearance=3) | 2914 | | | | | 2915 | | |< F11 200 OK <| | 2916 | | | | | 2917 | | |<- NOTIFY F12<| | 2918 | | | | | 2919 | |>F13 200 OK ->| | 2920 Dave | | |------ NOTIFY F14>| 2921 | | | | | 2922 | | | |F17 100 ----->| | | 2926 |<- INVITE F18<| | | | 2928 Figure 15. 2930 12. Security Considerations 2932 Since multiple line appearance features are implemented using 2933 semantics provided by [RFC3261], Event Package for Dialog State as 2934 define in , and Event Notification [I-D.ietf-sipcore-rfc3265bis], 2935 [RFC3903], security considerations in these documents apply to this 2936 draft as well. 2938 NOTIFY or PUBLISH message bodies that provide the dialog state 2939 information and the dialog identifiers MAY be encrypted end-to-end 2940 using the standard mechanisms. All SUBSCRIBES between the UA's and 2941 the Appearance Agent MUST be authenticated. 2943 For an emergency call, a UA MUST never wait for a confirmed seizure 2944 of an appearance before sending an INVITE. Instead, the emergency 2945 call MUST proceed regardless of the status of the PUBLISH 2946 transaction. 2948 13. IANA Considerations 2950 This section registers the SIP event package parameter 'shared', the 2951 SIP Alert-Info header field parameter "appearance" and the XML 2952 namespace extensions to the SIP Dialog Package. 2954 13.1. SIP Event Package Parameter: shared 2956 This specification defines a new event parameter 'shared' for the 2957 Dialog Package. When used in a NOTIFY, it indicates that the 2958 notifier supports the shared appearance feature. When used in a 2959 PUBLISH, it indicates that the publisher has explicit appearance 2960 information contained in the message body. If not present in a 2961 PUBLISH, the Appearance Agent MAY assign an appearance number to any 2962 new dialogs in the message body. 2964 13.2. URN Sub-Namespace Registration: sa-dialog-info 2966 This section registers a new XML namespace per the procedures 2967 in [RFC3688]. 2969 URI: urn:ietf:params:xml:ns:sa-dialog-info. 2971 Registrant Contact: IETF BLISS working group, , 2972 Alan Johnston 2974 XML: 2976 BEGIN 2977 2978 2980 2981 2982 2984 Shared Appearance Dialog Information Namespace 2985 2986 2987

Namespace for Shared Appearance Dialog Information

2988

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

2989

See 2990 RFCXXXX.

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