idnits 2.17.1 draft-ietf-bliss-shared-appearances-15.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 : ---------------------------------------------------------------------------- No issues found here. 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 (January 16, 2013) is 4111 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3968' is mentioned on line 3036, but not defined == Missing Reference: 'RFC-to-be' is mentioned on line 3041, but not defined == Outdated reference: A later version (-14) exists of draft-ietf-salud-alert-info-urns-07 == Outdated reference: A later version (-15) exists of draft-worley-service-example-10 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 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: July 20, 2013 Sylantro Systems Corp 7 January 16, 2013 9 Shared Appearances of a Session Initiation Protocol (SIP) Address of 10 Record (AOR) 11 draft-ietf-bliss-shared-appearances-15 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. 28 This specification updates RFC3261 and RFC4235. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on July 20, 2013. 47 Copyright Notice 48 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . 18 95 5.3.3. Appearance Numbers and Transfer . . . . . . . . . . . 18 96 5.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . 19 97 6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 21 98 7. Alert-Info Appearance Parameter Definition . . . . . . . . . . 23 99 8. User Interface Considerations . . . . . . . . . . . . . . . . 24 100 8.1. Appearance Number Rendering . . . . . . . . . . . . . . . 24 101 8.1.1. Single Appearance UAs . . . . . . . . . . . . . . . . 24 102 8.1.2. Dual Appearance UAs . . . . . . . . . . . . . . . . . 24 103 8.1.3. Shared Appearance UAs with Fixed Appearance Number . . 25 104 8.1.4. Shared Appearance UAs with Variable Appearance 105 Number . . . . . . . . . . . . . . . . . . . . . . . . 25 106 8.1.5. Example User Interface Issues . . . . . . . . . . . . 25 107 8.2. Call State Rendering . . . . . . . . . . . . . . . . . . 26 108 9. Interoperability with non-Shared Appearance UAs . . . . . . . 26 109 9.1. Appearance Assignment . . . . . . . . . . . . . . . . . . 26 110 9.2. Appearance Release . . . . . . . . . . . . . . . . . . . 27 111 9.3. UAs Supporting Dialog Events but Not Shared Appearance . 27 112 10. Provisioning Considerations . . . . . . . . . . . . . . . . . 27 113 11. Example Message Flows . . . . . . . . . . . . . . . . . . . . 28 114 11.1. Registration and Subscription . . . . . . . . . . . . . . 28 115 11.2. Appearance Selection for Incoming Call . . . . . . . . . 32 116 11.3. Outgoing Call without Appearance Seizure . . . . . . . . 35 117 11.4. Outgoing Call with Appearance Seizure . . . . . . . . . . 38 118 11.5. Outgoing Call without using an Appearance Number . . . . 42 119 11.6. Appearance Release . . . . . . . . . . . . . . . . . . . 44 120 11.7. Appearance Pickup . . . . . . . . . . . . . . . . . . . . 45 121 11.8. Calls between UAs within the Group . . . . . . . . . . . 50 122 11.9. Consultation Hold with Appearances . . . . . . . . . . . 52 123 11.10. Joining or Bridging an Appearance . . . . . . . . . . . . 55 124 11.11. Appearance Allocation - Loss of Appearance . . . . . . . 58 125 11.12. Appearance Seizure Contention Race Condition . . . . . . 59 126 11.13. Appearance Agent Subscription to UAs . . . . . . . . . . 60 127 11.14. Appearance Pickup Race Condition Failure . . . . . . . . 62 128 11.15. Appearance Seizure Incoming/Outgoing Contention Race 129 Condition . . . . . . . . . . . . . . . . . . . . . . . . 65 130 12. Security Considerations . . . . . . . . . . . . . . . . . . . 66 131 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66 132 13.1. SIP Event Header Field Parameter: shared . . . . . . . . 66 133 13.2. SIP Alert-Info Header Field Parameter: appearance . . . . 67 134 13.3. URN Sub-Namespace Registration: sa-dialog-info . . . . . 68 135 13.4. XML Schema Registration . . . . . . . . . . . . . . . . . 68 136 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 69 137 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69 138 15.1. Normative References . . . . . . . . . . . . . . . . . . 69 139 15.2. Informative References . . . . . . . . . . . . . . . . . 70 140 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 71 142 1. Introduction 144 The feature and functionality requirements for SIP user agents (UAs) 145 supporting business telephony applications differ greatly from basic 146 SIP user agents, both in terms of services and end user experience. 147 In addition to basic SIP support [RFC3261], many of the services in a 148 business environment require the support for SIP extensions such as 149 REFER [RFC3515], SUBSCRIBE/NOTIFY primitives 150 [I-D.ietf-sipcore-rfc3265bis] PUBLISH [RFC3903], the SIP Replaces 151 [RFC3891], and Join [RFC3911] header fields, etc. Many of the 152 popular business services have been documented in the SIP Service 153 Examples [RFC5359]. 155 This specification details a method for implementing a group 156 telephony feature known variously in telephony as Bridged Line 157 Appearance (BLA) or Multiple Line Appearances (MLA), one of the more 158 popular advanced features expected of SIP IP telephony devices in a 159 business environment. Other names for this feature include Shared 160 Call/Line Appearance (SCA), Shared Call Status and Multiple Call 161 Appearance (MCA). A variant of this feature is known as Single Line 162 Extension. 164 This document looks at how this feature can be implemented using 165 standard SIP [RFC3261] in conjunction with SIP events 166 [I-D.ietf-sipcore-rfc3265bis] and publication [RFC3903] (carrying the 167 SIP dialog state event package [RFC4235]) for exchanging status among 168 user agents. 170 In traditional telephony, the line is physical. A common scenario in 171 telephony is for a number of business telephones to share a single or 172 a small number of lines. The sharing or appearance of these lines 173 between a number of phones is what gives this feature its name. A 174 common scenario in SIP is for a number of business telephones to 175 share a single or a small number of Address of Record (AOR) URIs. 177 In addition, an AOR can have multiple appearances on a single UA in 178 terms of the user interface. The appearance number relates to the 179 user interface for the telephone - typically each appearance of an 180 AOR has a visual display (lamp that can change color or blink or a 181 screen icon) and a button (used to select the appearance) where each 182 appearance number is associated with a different dialog to/from the 183 AOR. The telephony concept of line appearance is still relevant to 184 SIP due to the user interface considerations. It is important to 185 keep the appearance number construct because: 187 1. Human users are used to the concept and will expect it in 188 replacement systems (e.g. an overhead page announcement says "Joe 189 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 and 288 large numbers of UAs without introducing excessive messaging traffic. 290 REQ-6 Each call or session (incoming or outgoing) should be assigned 291 a common "appearance" number from a managed pool administered for the 292 AOR group. Once the session has terminated, the appearance number is 293 released back into the pool and can be reused by another incoming or 294 outgoing session. 296 REQ-7 Each UA in the group must be able to learn the status of all 297 appearances of the group. 299 REQ-8 There must be mechanisms to resolve appearance contention among 300 the UAs in the group. Contention in this context means an appearance 301 number being associated with multiple dialogs that are not mixed or 302 otherwise associated. 304 REQ-9 The mechanism must allow all UAs receiving an incoming session 305 request to utilize the same appearance number at the time of 306 alerting. 308 REQ-10 The mechanism must have a way of reconstructing appearance 309 state after an outage that does not result in excessive traffic and 310 processing. 312 REQ-11 The mechanism must have backwards compatibility such that a UA 313 which is unaware of the feature can still register against the group 314 AOR and make and receive calls. 316 REQ-12 The mechanism must not allow UAs outside the group to select, 317 seize or manipulate appearance numbers. 319 REQ-13 For privacy reasons, there must be a mechanism so that 320 appearance information is not leaked outside the group of UAs. (e.g. 321 "So who do you have on line 1?") 323 REQ-14 The mechanism must support a way for UAs to request 324 exclusivity on a line appearance. Exclusivity means that the UA 325 requesting it desires to have a private conversation with the 326 external party and other UAs must not be allowed to join or take the 327 call. Exclusivity may be requested at the start of an incoming or 328 outgoing session or during the session. An exclusivity request may 329 be accepted or rejected by the entity providing the shared appearance 330 service. Therefore, the mechanism must provide a way of 331 communicating the result back to the requester UA. 333 REQ-15 The mechanism should support a way for a UA to seize a 334 particular appearance number for outgoing requests prior to sending 335 the actual request. This is often called seizure. 337 REQ-16 The mechanism should support a way for a UA to seize a 338 particular appearance number and also send the request at the same 339 time. This is needed when an automatic ringdown feature (a telephone 340 configured to immediately dial a phone number when it goes off hook) 341 is combined with shared appearances - in this case, seizing the line 342 is integrated with dialing. 344 4.2. Implementation 346 This section non-normatively discusses the implementation of the 347 shared appearance feature. The normative description is in 348 Section 5. Many of the requirements for this service can be met 349 using standard SIP mechanisms such as: 351 - A SIP Forking Proxy and Registrar/Location Service meets REQ-1. 353 - The SIP Dialog Package meets REQ-2. 355 - The combination of the SIP Replaces and Join header fields meets 356 REQ-3. 358 - The use of a State Agent for the Dialog Package meets REQ-4 and 359 REQ-5. 361 REQ-6 suggests the need for an entity which manages the appearance 362 resource. Just as conferencing systems commonly have a single point 363 of control, known as a focus, a Shared Appearance group has a single 364 point of control of the appearance shared resource. This is defined 365 as an Appearance Agent for a group. While an Appearance Agent can be 366 part of a centralized server, it could also be co-resident in a 367 member User Agent that has taken on this functionality for a group. 368 The Appearance Agent knows or is able to determine the dialog state 369 of all members of the group. 371 While the appearance resource could be managed co-operatively by a 372 group of UAs without any central control, this is outside the scope 373 of this draft. It is also possible that the Appearance Agent logic 374 could be distributed in all UAs in the group. For example, rules 375 that govern assigning appearance numbers for incoming requests (e.g. 376 lowest available appearance number) and rules for contention handling 377 (e.g. when two UAs request the use of the same appearance number, 378 hash dialog identifiers and compare with the lowest hash winning) 379 would need to be defined and implemented. 381 To best meet REQ-9, the appearance number for an incoming INVITE 382 needs to be contained in the INVITE, in addition to being delivered 383 in the dialog package NOTIFY. Otherwise, if the NOTIFY is delayed or 384 lost, a UA in the group might receive an incoming INVITE but might 385 not know which appearance number to render during alerting. 387 This specification defines an extension parameter, which is 388 normatively defined in Section 7, for the Alert-Info header field in 389 RFC 3261 to carry the appearance number: 391 Alert-Info: ;appearance=1 393 The following list describes the operation of the shared appearance 394 feature. 396 1. A UA is configured with the AOR of a shared appearance group. It 397 registers against the AOR, then attempts a dialog state 398 subscription to the AOR. If the subscription fails, loops back 399 to itself, or returns an error, it knows there is no State Agent, 400 and hence no Appearance Agent and this feature is not 401 implemented. 402 2. If the subscription receives a 200 OK, the UA knows there is a 403 State Agent and that the feature is implemented. The UA then 404 follows the steps in this list. 405 3. Information learned about the dialog state of other UAs in the 406 group is rendered to the user. 407 4. Incoming calls are forked to all UAs in the group, and any may 408 answer. UAs receive the appearance number to use in rendering 409 the incoming call in a NOTIFY from the Appearance Agent and in 410 the INVITE itself. The UA will also receive a notification if 411 the call is answered by another UA in the group so this 412 information can be rendered to the user. 413 5. For outgoing calls, the operation depends on the implementation. 414 If the user seizes a particular appearance number for the call, 415 the UA publishes the trying state dialog information with the 416 desired appearance number and waits for a 2xx response before 417 sending the INVITE. 418 6. For outgoing calls, if the user does not seize a particular 419 appearance or does not care, the INVITE can be sent immediately, 420 and the appearance number learned as the call progresses from a 421 notification from the Appearance Agent. 422 7. For outgoing calls, if the user does not want an appearance 423 number assigned (such as during a consultation call or if a UA is 424 fetching 'service media' such as music on hold 425 [I-D.worley-service-example]), the UA also publishes prior to 426 sending the INVITE but does not include an appearance number in 427 the publication. 428 8. Established calls within the group may be joined (bridged) or 429 taken (picked) by another UA. Information in the dialog package 430 notifications can be used to construct Join or Replaces header 431 fields. Since the same appearance number is used for these types 432 of operations, this information is published prior to sending the 433 INVITE Join or INVITE Replaces. 434 9. The Appearance Agent may not have direct access to the complete 435 dialog state of some or all of the UAs in the group. If this is 436 the case, the Appearance Agent will subscribe to the dialog state 437 of individual UAs in the group to obtain this information. In 438 any case, the Appearance Agent will send normal notifications 439 (via the subscriptions established by the UAs in step 1) every 440 time the aggregate dialog state of the AOR changes, including 441 when calls are placed, answered, placed on and off hold, and hung 442 up. 444 5. Normative Description 446 This section normatively describes the shared appearance feature 447 extensions. The following definitions are used throughout this 448 document: 450 Appearance number: An appearance number is a positive integer 451 associated with one or more dialogs of an AOR. Appearance numbers 452 are managed by an Appearance Agent and displayed and rendered to the 453 user by UAs that support this specification. When an appearance 454 number is assigned or requested, generally the assigned number is the 455 smallest positive integer that is not currently assigned as an 456 appearance number to a dialog for this AOR. This specification does 457 not define an upper limit on appearance numbers; however, using 458 appearance numbers that are not easily represented using common 459 integer representations is likely to cause failures. 461 Seizing: An appearance can be reserved prior to a call being placed 462 by seizing the appearance. An appearance can be seized by 463 communicating an artificial state of "trying" prior to actually 464 initiating a dialog (i.e. sending the INVITE), in order to appear as 465 if it was already initiating a dialog. 467 Selecting(or Not-Seizing): An appearance is merely selected (i.e., 468 not seized) if there is no such communication of artificial state of 469 "trying" prior to initiating a dialog: i.e., the state is 470 communicated when the dialog is actually initiated. The appearance 471 number is learned after the INVITE is sent. 473 5.1. Elements 475 A complete system to implement this feature consists of: 477 1. User Agents that support publications, subscriptions, and 478 notifications for the SIP dialog event package, and the shared 479 appearance dialog package extensions and behavior. 480 2. An Appearance Agent consisting of a State Agent for the dialog 481 event package that implements an Event State Compositor (ESC) and 482 the shared appearance dialog package extensions and behavior. 483 The Appearance Agent also has logic for assigning and releasing 484 appearance numbers, and resolving appearance number contention. 485 3. A forking proxy server that can communicate with the State Agent 486 4. A registrar that supports the registration event package. 488 The behavior of these elements is described normatively in the 489 following sections after the definitions of the dialog package 490 extensions. 492 5.2. Shared Appearance Dialog Package Extensions 494 This specification defines four new elements as extensions to the SIP 495 Dialog Event package [RFC4235]. The schema is defined in Section 6. 496 The elements are , , , and 497 which are sub-elements of the element. 499 5.2.1. The element 501 The element, a child of the element, is used to 502 convey the appearance number of the dialog described by the parent 503 element. When sent by a UA in a PUBLISH with parent 504 with state attribute "trying" to the Appearance Agent, the 505 UA is requesting assignment of the given appearance number to the 506 current or future dialog with the given dialog identifiers. When an 507 element is sent by the Appearance Agent in a NOTIFY, it 508 indicates that the appearance number has been assigned to the 509 specified dialog. 511 Note that a element describes the contained dialogs 512 from the point of view of the UA (named by the "entity" attribute), 513 regardless of whether the containing request is sent by the UA or the 514 Appearance Agent. In particular, if the UA sent a request within the 515 described dialog, the To header field URI would match the 516 value and the to-tag parameter would match the remote-tag 517 attribute. Similarly, the From header field URI would match the 518 value and the from-tag parameter would match the 519 local-tag attribute. 521 5.2.2. The element 523 The element, a child of the element, is a 524 boolean, which when true, indicates that the UA is not willing to 525 accept an INVITE with a Join or Replaces header field targeted to the 526 dialog described by the element that is the parent of the 527 element. For example, some shared appearance systems 528 only allow call pickup when the call is on hold. In this case, the 529 element should be set to "false" when the call is held 530 and "true" when the call is not held, rather than having the 531 "exclusive" value implied by the hold state. 533 It is important to note that this element is a hint. In order to 534 prevent another UA from taking or joining a call, a UA can, in 535 addition to setting the tag, not report full dialog 536 information to the Appearance Agent. Not having the full dialog 537 information (Call-ID, remote-tag, and local-tag) prevents another UA 538 from constructing a Join or Replaces header field. Although a UA may 539 set exclusive to true, the UA must still be ready to reject an INVITE 540 Join relating to this dialog. If these dialog identifiers have 541 already been shared with the Appearance Agent, the UA could send an 542 INVITE Replaces to change them and then not report the new ones to 543 the Appearance Agent. 545 If the proxy knows which dialogs are marked exclusive, the proxy MAY 546 enforce this exclusivity by rejecting INVITE Join and INVITE Replaces 547 requests containing those dialog identifiers with a 403 Forbidden 548 response. 550 Note that exclusivity has nothing to do with appearance number 551 selection or seizing - instead, it is about call control 552 operations that can be performed on a dialog. 554 If the element is not present, it is assumed to be false. 556 5.2.3. The element 558 The element, a child of the element, is used 559 to convey dialog identifiers of any other dialogs which are joined 560 (mixed or bridged) with the dialog. Only the UA which is the common 561 endpoint of the mixed dialogs (and thus controlling the mixing 562 operation) should include this element in publications to the 563 Appearance Agent. Note that this element should still be used even 564 when the Join header field was not used to join the dialogs. For 565 example, two separate dialogs on a UA could be joined without any SIP 566 call control operations. Joined dialogs will share the same 567 appearance number. 569 If the element is not present, it is assumed that the 570 dialog is not joined or to be joined to any other dialog. 572 5.2.4. The element 574 The element, a child of the element, is 575 used to convey dialog identifiers of any other dialogs which will be 576 or have been replaced with this dialog. For example, a UA in the 577 group picking up a call on another UA by sending an INVITE with 578 Replaces would include this element for the replacing dialog. 579 Replaced dialogs will share the same appearance number. 581 If the element is not present, it is assumed that 582 the dialog has not replaced or is not to replace to any other dialog. 584 5.3. Shared Appearance User Agents 586 User Agents that support the Shared Appearance feature use the dialog 587 state package [RFC4235] with the shared appearance extensions and the 588 'shared' Event header field parameter defined in Section 13. 590 User Agents use the dialog package extensions in Section 5.2 along 591 with SUBSCRIBE and NOTIFY [I-D.ietf-sipcore-rfc3265bis] and PUBLISH 592 [RFC3903]. SUBSCRIBE, NOTIFY, and PUBLISH requests for the dialog 593 event package include the 'shared' Event header field parameter as 594 required by this specification. 596 The presence of the 'shared' Event header field parameter tells 597 the Appearance Agent that the UA supports this specification. 599 Upon initialization, the UA MUST subscribe to the dialog event 600 package of the AOR and refresh the subscription per the SIP Events 601 Framework. If the SUBSCRIBE request fails, then no Appearance Agent 602 may be present and this feature is not active for this AOR. The UA 603 MAY periodically retry the subscription to see if conditions have 604 changed at intervals no shorter than 4 hours. 606 Four hours was chosen to limit the subscription test to 6 per day 607 per UA. Increasing this interval would reduce this failure 608 traffic but take longer for a newly activated Appearance Agent to 609 be discovered. 611 UAs can also use the presence of the 'shared' Event header field 612 parameter in NOTIFYs to discover the presence of an Appearance Agent 613 for the AOR. 615 User Agents which implement the shared appearances feature and call 616 pickup, joining and bridging MUST support sending an INVITE with 617 Replaces [RFC3891] or Join [RFC3911]. The User Agent Client needs to 618 include the to-tag and from-tag information in the Replaces or Join 619 header so that the correct dialog will be matched by the User Agent 620 Server per the rules in RFC 3891 and RFC 3911. 622 All User Agents which implement the shared appearances feature and 623 support INVITE MUST support receiving an INVITE with a Replaces 624 [RFC3891] or a Join [RFC3911] header field. 626 When publishing or notifying dialog package information, a UA 627 includes the largest set of dialog identification available at the 628 time of publication, with the exception that a UA may omit 629 information if it wishes to prevent other UAs from joining or picking 630 up a call. Dialog identification includes local and remote target 631 URIs, call-id, to-tag, and from-tag. While this dialog 632 identification information is optional in [RFC4235], it is essential 633 in the shared appearance feature, allowing call control operations. 634 When placing calls on hold, use the "+sip.rendering=no" feature tag 635 to indicate this in dialog package notifications. Using the full SDP 636 session description instead forces the endpoint to do a lot of extra 637 parsing, unnecessarily complicating the code and inviting errors. 639 The accurate rendering of the idle/active/alerting/hold state of 640 other UAs in the group is an important part of the shared 641 appearance feature. 643 A UA that does not need to seize a particular appearance number (or 644 doesn't care) would just send an INVITE as normal to place an 645 outbound call. 647 If the call is an emergency call, a UA MUST never wait for a 648 confirmed seizure before sending an INVITE. Instead, the emergency 649 call MUST proceed without waiting for the PUBLISH transaction. 651 If a UA requires a particular appearance number, the a UA MUST send a 652 dialog package PUBLISH request and wait for a 2xx response before 653 sending the INVITE. This is required in the following situations: 655 1. When the user seizes a particular appearance number for an 656 outgoing call (e.g. seizing the appearance and going "off-hook", 657 if the UA's user interface uses this metaphor). 658 2. When the user has requested that an appearance number not be used 659 for an outgoing call (i.e. during a consultation call, a 'service 660 media' call such as for music on hold 661 [I-D.worley-service-example] or for a call not considered part of 662 the shared appearance group). 664 3. When the user has selected to join (or bridge) an existing call. 665 4. When the user has selected to replace (or take) an existing call. 667 Note that when a UA seizes an appearance prior to establishment of a 668 dialog (#1 and #2 in above list), not all dialog information will be 669 available. In particular, when a UA publishes an attempt to seize an 670 appearance prior to knowing the destination URI, minimal or no dialog 671 information may be available. For example, in some cases, only the 672 local target URI for the call will be known and no dialog 673 information. If the From tag and Call-ID were not present in the 674 initial PUBLISH, a new PUBLISH MUST be sent as soon as this 675 information is available. 677 The first publication will cause the Appearance Agent to reserve 678 the appearance number for this UA. If the publication does not 679 have any dialog identifiers (e.g. Call-ID, or local tag) the 680 Appearance Agent cannot assign the appearance number to a 681 particular dialog of the UA until the second publication which 682 will contain some dialog identifiers. 684 This publication state is refreshed as described in [RFC3903] during 685 the early dialog state or the Appearance Agent may reassign the 686 appearance number. Once the dialog has transitioned to the confirmed 687 state, no publication refreshes are necessary. 689 This specification assumes that the Appearance Agent has other 690 means besides UA publication to learn about the state of UA 691 dialogs. In this specification, PUBLISH is used to indicate 692 desired and intended appearance number operations. Once a dialog 693 transitions from early to confirmed, this role is over, and hence 694 no publication refreshes are needed. 696 Appearance numbers are a shorthand label for active and pending 697 dialogs related to an AOR. Many of the features and services built 698 using this extension rely on the correct rendering of this 699 information to the human user. In addition, the group nature of the 700 feature means that the rendering must be similar between different 701 vendors and different models. Failure to do so will greatly reduce 702 the value and usefulness of these protocol extensions. In a 703 correctly designed user interface for this feature, the appearances 704 number for each active and pending dialog is explicitly (i.e. by 705 appearance number) or implicitly (using a user interface metaphor 706 that makes the numbering and ordering clear to the user) rendered to 707 the user. The far end identity of each dialog (e.g. the remote party 708 identity) is not a useful replacement for the appearance number. The 709 state of each appearance is also be rendered (idle, active, busy, 710 joined, etc.). UAs can tell that a set of dialogs are joined 711 (bridged or mixed) together by the presence of one or more elements containing other SIP dialog identifiers. Appearance 713 numbers of dialogs can be learned by dialog package notifications 714 containing the element from the Appearance Agent or from 715 the 'appearance' Alert-Info parameter in an incoming INVITE. Should 716 they conflict, the dialog package notification takes precedence. 718 A user may select an appearance number but then abandon placing a 719 call (go back on hook). In this case, the UA frees up the appearance 720 number by removing the event state with a PUBLISH as described in 721 [RFC3903]. A failure to do this will require extra unnecessary 722 operations by the Appearance Agent, and also tie up appearance 723 numbers which could otherwise be used by other UAs in the appearance 724 group. 726 A UA SHOULD register against the AOR only if it is likely the UA will 727 be answering incoming calls. If the UA is mainly going to be 728 monitoring the status of the shared appearance group calls and 729 picking or joining calls, the UA SHOULD only subscribe to the AOR and 730 not register against the AOR. If a monitoring UA registers rather 731 than just subscribing generates large amounts of unnecessary network 732 traffic. 734 All subscribed UAs will receive dialog package NOTIFYs of trying 735 state for incoming INVITEs. 737 A UA MUST NOT insert an 'appearance' parameter into an Alert-Info 738 header field in an INVITE or other request. 740 The Appearance Agent is solely responsible for doing this. 742 5.3.1. Appearance Numbers and Call Context 744 There are cases where two separate dialogs at a UA are not mixed but 745 share the same 'context'. That is, they relate to each other and 746 should not be treated the same as any other two dialogs within the 747 group. One example of this is a 'consultation call' where a user 748 puts an existing dialog on hold, then calls another user, before 749 switching back to the original dialog. Another case, described 750 below, occurs during transfer operations, where for a transient 751 period, a UA is involved in dialogs with two other UAs, but the 752 dialogs are related, and should not be treated as independent 753 dialogs. These cases are best handled by not assigning an appearance 754 number to a newly-created dialog when it shares a context with an 755 existing dialog. But if the pre-existing dialog is terminated, its 756 appearance number should be reassigned to the newly-created dialog. 758 A UA wanting to place a call but not have an appearance number 759 assigned sends a PUBLISH before sending the INVITE. The PUBLISH does 760 not have an 'appearance' element present, but does have the 'shared' 761 Event header field parameter present. If the Appearance Agent policy 762 does not allow calls without an assigned appearance number, a 400 763 (Bad Request) response is sent by the Appearance Agent and the UA 764 will republish either selecting/seizing an appearance number or send 765 the INVITE without publishing, in which case the Appearance Agent 766 will assign one. 768 Note that if an Appearance Agent rejects calls without an 769 appearance number, certain operations such as consultation calls, 770 transfer, and music on hold may be negatively impacted. 772 5.3.2. Appearance Numbers and Call Control 774 When an INVITE is generated to attempt to bridge or take a call (i.e. 775 contains Join or Replaces with a dialog identifier of another dialog 776 in the shared appearance group), the UA MUST first send a PUBLISH to 777 the Appearance Agent. This PUBLISH will contain: 779 1. The appearance number of the joined or replaced call in the 780 element 781 2. If the dialog is being joined, the element will 782 contain the dialog information from the Join header field 783 3. If the dialog is being replaced, the element 784 will contain the dialog information from the Replaces header 785 field 787 Note that this information is provided to the Appearance Agent so 788 that it can provide proper appearance assignment behavior. If the 789 INVITE Join or Replaces was sent without publishing first, the 790 Appearance Agent might assign a new appearance number to this 791 INVITE, which would be a mistake. With Join, the publication has 792 the element to prevent the Appearance Agent from 793 generating a 400 (Bad Request) response due to the reuse of an 794 appearance number. For Replaces, the purpose of the is to prevent a race condition where the BYE could cause 796 the appearance number to be released when it should stay with the 797 replacing dialog. 799 5.3.3. Appearance Numbers and Transfer 801 During a transfer operation, it is important that the appearance 802 number not change during the operation. Consider the example of 803 Alice, a member of an appearance group, who is talking to Carol, who 804 is outside the appearance group. Carol transfers Alice to David, who 805 is also outside the appearance group. For example, if Alice is using 806 appearance 3 for the session with Carol, the resulting session with 807 David should also use appearance number 3. Otherwise, an appearance 808 number change can cause a "jump" on the UI and confusion to the user. 809 There are two possible scenarios using the terminology of RFC 5589: 810 Alice is the transferee in any type of transfer (receives the REFER) 811 or the transfer target in an attended transfer (receives the INVITE 812 with Replaces). 814 If Alice is the transferee, the triggered INVITE from the REFER is 815 treated as a consultation call. Alice SHOULD publish requesting that 816 the Appearance Agent not assign an appearance number for this INVITE. 817 When the transfer completes, Alice SHOULD publish again to move the 818 appearance number from the dialog with Carol to the dialog with 819 David. If a PUBLISH is sent to move the appearance number, the 820 publication MUST be sent prior to sending the BYE to Carol to avoid a 821 race condition where the Appearance Agent reassigns the appearance 822 number after seeing the BYE. 824 If Alice is the target, the incoming INVITE will contain a Replaces 825 header field. As a result, the Appearance Agent will have reused the 826 appearance number of the dialog with Carol, and this appearance 827 number will continue to be used after the dialog with Carol has been 828 terminated. 830 5.4. Appearance Agent 832 An Appearance Agent defined in this specification MUST implement a 833 dialog package state agent for the UAs registered against the AOR. 834 The Appearance Agent MUST support the appearance dialog package 835 extensions defined in Section 5.2 and use the 'shared' Event header 836 field parameter. The Appearance Agent MUST support publications and 837 subscriptions for this event package. 839 The Appearance Agent MUST have a way of discovering the state of all 840 dialogs associated with the AOR. If this information is not 841 available from a call stateful proxy or Back-to-Back User Agent 842 (B2BUA), the Appearance Agent can use the registration event package 843 [RFC3680] to learn of UAs associated with the AOR and subscribe to 844 their dialog event state. An Appearance Agent can also subscribe to 845 a UAs dialog event state in order to reconstruct state. As a result, 846 the registrar MUST support the registration event package. Dialog 847 package notifications are recommended by RFC 4235 to "only contain 848 information on the dialogs whose state or participation information 849 has changed." This specification extends RFC 4235 as follows. The 850 Appearance Agent SHOULD send dialog event state notifications 851 whenever the following events happen to UAs in the AOR group: 853 1. A call is received, placed, answered, or terminated. 855 2. A call is placed on or off hold. 856 3. A call is joined or replaced. 857 4. An appearance number is reserved or released. 859 The Appearance Agent MUST allocate an appearance number for all 860 incoming calls and send immediate notifications to the UAs subscribed 861 to the shared group AOR. A new appearance number is allocated except 862 for an incoming INVITE with a Join or Replaces header field. For 863 this case, the appearance number should match the appearance number 864 of the dialog being joined or replaced. If the INVITE Replaces or 865 Join comes from outside the appearance group, the Appearance Agent 866 will include a or element in the 867 NOTIFY containing the dialog information from the Replaces or Joined 868 header field. 870 The Appearance Agent MUST be able to communicate with the forking 871 proxy to learn about incoming calls and also to pass the appearance 872 number to the proxy, or otherwise ensure the Alert-Info header field 873 is included in the INVITE with the appropriate appearance number. 875 Note that UAs need to be able to handle incoming INVITEs without 876 an appearance number assigned. This could be caused by a failure 877 of the Appearance Agent or other error condition. Although the 878 proper rendering of the INVITE may not be possible, this is better 879 than ignoring or failing the INVITE. 881 An Appearance Agent SHOULD assign an appearance number to an outgoing 882 dialog if a PUBLISH has not been received selecting/seizing a 883 particular appearance number. 885 Note that if the appearance group has appearance-unaware UAs 886 making calls, the Appearance Agent will still allocate appearance 887 numbers for INVITEs sent by those UAs. 889 An Appearance Agent receiving a PUBLISH with an appearance number 890 checks to make sure the publication is valid. An appearance number 891 can be assigned to only one dialog unless there is a 892 or element indicating that the dialog will be/has 893 been replaced or joined. A 400 (Bad Request) response is returned if 894 the chosen appearance number is invalid, and an immediate NOTIFY 895 SHOULD be sent to the UA containing full dialog event state. 897 An Appearance Agent receiving a PUBLISH without an appearance number 898 but with the 'shared' Event header field parameter present interprets 899 this as a request by the UA to not assign an appearance number. If 900 the Appearance Agent policy does not allow this, a 400 (Bad Request) 901 response is returned. If policy does allow this, a 200 OK response 902 is returned and no appearance number is allocated. An Appearance 903 Agent does not have to share this dialog information (i.e. send a 904 NOTIFY) with other UAs in the group as the information will not be 905 rendered by the other UAs. 907 The Appearance Agent allocates an apperance number to a dialog from 908 the time the appearance is requested via a PUBLISH or from the 909 receipt of an INVITE, to the time when the last dialog associated 910 with the appearance is terminated, including all dialogs which are 911 joined or replaced. During the early dialog state, the Appearance 912 Agent controls the rate of dialog state publication using the Expires 913 header field in 200 OK responses to PUBLISH requests. An interval of 914 3 minutes is RECOMMENDED. After the dialog associated with the 915 publication has been confirmed, the expiration of the publication 916 state has no effect on the appearance allocation. If the publication 917 contains no dialog state information, the Appearance Agent MUST 918 reserve the appearance number for the UA but can not assign the 919 appearance to any particular dialog of the UA. When the publication 920 state is updated with any dialog information, the appearance number 921 can then be assigned to the particular dialog. A UA which has been 922 allocated an appearance number using a PUBLISH MAY free up the 923 appearance number by removing the event state with a PUBLISH as 924 described in [RFC3903]. 926 If an INVITE is sent by a member of the group to the shared AOR (i.e. 927 they call their own AOR), the Appearance Agent MUST assign two 928 appearance numbers. The first appearance number will be the one 929 selected or assigned to the outgoing INVITE. The second appearance 930 number will be another one assigned by the Appearance Agent for the 931 INVITE as it is forked back to the members of the group. 933 The is to preserve a common behavior in legacy systems. 935 If an INVITE is sent by a member of the group using the shared AOR or 936 sent to the shared AOR and no appearance number is available, the 937 proxy MAY reject the INVITE with a 403 Forbidden response code. 939 Appearance numbers are only used for dialogs in which one or more UAs 940 associated with the group AOR is a participant. If an incoming 941 INVITE to the group AOR is forwarded to another AOR, the appearance 942 number is immediately freed up and can be assigned to another dialog. 944 6. XML Schema Definition 946 The 'appearance', 'joined-dialog', 'replaced-dialog', and 'exclusive' 947 elements are defined within a new XML namespace URI. This namespace 948 is "urn:ietf:params:xml:ns:sa-dialog-info". The schema for these 949 elements is: 951 952 958 960 961 963 965 967 968 970 972 973 975 977 979 980 982 983 984 985 987 988 989 990 991 993 7. Alert-Info Appearance Parameter Definition 995 This specification extends RFC 3261 [RFC3261] to add an 'appearance' 996 parameter to the Alert-Info header field, and to also allow proxies 997 to modify or delete the Alert-Info header field. 999 The changes to RFC 3261 ABNF [RFC5234] are: 1001 alert-param = LAQUOT absoluteURI RAQUOT *( SEMI 1002 (generic-param / appearance-param) ) 1003 appearance-param = "appearance" EQUAL 1*DIGIT 1005 A proxy inserting an 'appearance' Alert-Info parameter follows normal 1006 Alert-Info policies. To indicate the appearance number for this 1007 dialog, the proxy adds the Alert-Info header field with the 1008 'appearance' parameter to the INVITE. If an Alert-Info is already 1009 present, the proxy adds the 'appearance' parameter to the Alert-Info 1010 header field. If an appearance number parameter is already present 1011 (associated with another AOR or by mistake), the value is rewritten 1012 adding the new appearance number. There MUST NOT be more than one 1013 appearance parameter in an Alert-Info header field. 1015 If no special ringtone is desired, a normal ringtone SHOULD be 1016 indicated using the urn:alert:service:normal in the Alert-Info, as 1017 per [I-D.ietf-salud-alert-info-urns]. The appearance number present 1018 in an Alert-Info header field SHOULD be rendered by the UA to the 1019 user, following the guidelines in Section 5.3. If the INVITE is 1020 forwarded to another AOR, the appearance parameter in the Alert-Info 1021 SHOULD be removed before forwarding outside the group. 1023 The determination as to what value to use in the appearance parameter 1024 can be done at the proxy that forks the incoming request to all the 1025 registered UAs. 1027 There are a variety of ways the proxy can use to determine what 1028 value it should use to populate this parameter. For example, the 1029 proxy could fetch this information by initiating a SUBSCRIBE 1030 request with Expires: 0 to the Appearance Agent for the AOR to 1031 fetch the list of lines that are in use. Alternatively, it could 1032 act like a UA that is a part of the appearance group and SUBSCRIBE 1033 to the State-Agent like any other UA. This would ensure that the 1034 active dialog information is available without having to poll on a 1035 need basis. It could keep track of the list of active calls for 1036 the appearance AOR based on how many unique INVITE requests it has 1037 forked to or received from the appearance AOR. Another approach 1038 would be for the Proxy to first send the incoming INVITE to the 1039 Appearance Agent which would redirect to the appearance group URI 1040 and escape the proper Alert-Info header field for the Proxy to 1041 recurse and distribute to the other UAs in the group. 1042 The Appearance Agent needs to know about all incoming requests to 1043 the AOR in order to seize the appearance number. One way in which 1044 this could be done is for the Appearance Agent to register against 1045 the AOR with a higher q value. This will result in the INVITE 1046 being sent to the Appearance Agent first, then being offered to 1047 the UAs in the group. 1049 8. User Interface Considerations 1051 The "appearance number" allocated to a call is an important concept 1052 that enables calls to be handled by multiple devices with 1053 heterogeneous user interfaces in a manner that still allows users to 1054 see a consistent model. Careful treatment of the appearance number 1055 is essential to meet the expectations of the users. Also, rendering 1056 the correct call/appearance state to users is also important. 1058 8.1. Appearance Number Rendering 1060 Since different UAs have different user interface capabilities, it is 1061 usual to find that some UAs have restrictions that others do not. 1062 Perfect interoperability across all UAs is clearly not possible, but 1063 by careful design, interoperability up to the limits of each UA can 1064 be achieved. 1066 The following guidelines suggest how the appearance number should be 1067 handled in three typical user interface implementations. 1069 8.1.1. Single Appearance UAs 1071 These devices are constrained by only having the capability of 1072 displaying status indications for a single appearance. The UA SHOULD 1073 still send messages annotated with appearance number "1". Any call 1074 indications for appearances other than for number "1" SHOULD be 1075 rejected with a 486 or 480 response. Note that this means that a 1076 single appearance UA cannot answer its own call to the shared AOR, 1077 since this call would use a second appearance number. 1079 8.1.2. Dual Appearance UAs 1081 These devices are essentially single appearance phones that implement 1082 call waiting. They have a very simple user interface that allows 1083 them to switch between two appearances (toggle or flash hook) and 1084 perhaps audible tones to indicate the status of the other appearance. 1085 Only appearance numbers "1" and "2" will be used by these UAs. 1087 8.1.3. Shared Appearance UAs with Fixed Appearance Number 1089 This UA is the typical 'business-class' hard-phone. A number of 1090 appearances are typically configured statically and labeled on 1091 buttons, and calls may be managed using these configured appearances. 1092 Any calls outside this range should be rejected, and not mapped to a 1093 free button. Users of these devices often seize specific appearance 1094 numbers for outgoing calls, and the UA will need to seize the 1095 appearance number and wait for confirmation from the Appearance Agent 1096 before proceeding with calls. 1098 8.1.4. Shared Appearance UAs with Variable Appearance Number 1100 This UA is typically a soft-phone or graphically rich user interface 1101 hard-phone. In these cases, even the idea of an appearance index may 1102 seem unnecessary. However, for these phones to be able to interwork 1103 successfully with other phone types, it is important that they still 1104 use the appearance index to govern the order of appearance of calls 1105 in progress. No specific guidance on presentation is given except 1106 that the order should be consistent. These devices can typically 1107 make calls without waiting for confirmation from the Appearance Agent 1108 on the appearance number. 1110 8.1.5. Example User Interface Issues 1112 The problems faced by each style of user interface are readily seen 1113 in this example: 1115 1. A call arrives at the shared appearance group, and is assigned an 1116 appearance number of "1". All UAs should be able to render to 1117 the user the arrival of this call. 1118 2. Another call arrives at the shared appearance group, and is 1119 assigned an appearance number of "2". The single appearance UA 1120 should not present this call to the user. Other user agents 1121 should have no problems presenting this call distinctly from the 1122 first call. 1123 3. The first call clears, releasing appearance number "1". The 1124 single appearance UA should now be indicating no calls since it 1125 is unable to manage calls other than on the first appearance. 1126 Both shared appearance UAs should clearly show that appearance 1127 number "1" is now free, but that there is still a call on 1128 appearance number "2". 1129 4. A third call arrives, and is assigned the appearance number of 1130 "1". All UAs should be able to render the arrival of this new 1131 call to the user. Multiple appearance UAs should continue to 1132 indicate the presence of the second call, and should also ensure 1133 that the presentation order is related to the appearance number 1134 and not the order of call arrival. 1136 8.2. Call State Rendering 1138 UAs that implement the shared appearance feature typically have a 1139 user interface that provides the state of other appearances in the 1140 group. As dialog state NOTIFYs from the Appearance Agent are 1141 processed, this information can be rendered. Even the simplest user 1142 interface typically has three states: idle, active, and hold. The 1143 idle state, usually indicated by lamp off, is indicated for an 1144 appearance when the appearance number is not associated with any 1145 dialogs, as reported by the Appearance Agent. The active state, 1146 usually indicated by a lamp on, is indicated by an appearance number 1147 being associated with at least one dialog, as reported by the 1148 Appearance Agent. The hold state, often indicated by a blinking 1149 lamp, means the call state from the perspective of the UA in the 1150 shared appearance group is hold. This can be determined by the 1151 presence of the "+sip.rendering=no" feature tag [RFC3840] with the 1152 local target URI. Note that the hold state of the remote target URI 1153 is not relevant to this display. For joined dialogs, the state is 1154 rendered as hold only if all local target URIs are indicated with the 1155 "+sip.rendering=no" feature tag. 1157 9. Interoperability with non-Shared Appearance UAs 1159 It is desirable to allow a basic UA that does not directly support 1160 shared appearance to be part of a shared appearance group. To 1161 support this the Proxy must collaborate with the Appearance Agent. 1162 This is not required in the basic shared appearance architecture, 1163 consequently shared appearance interoperability with non-shared 1164 appearance UAs will not be available in all shared appearance 1165 deployments. 1167 First, a UA which does not support dialog events or the shared 1168 appearance feature will be discussed. Then, a UA which does support 1169 dialog events but not the shared appearance feature will be 1170 discussed. 1172 9.1. Appearance Assignment 1174 A UA that has no knowledge of appearances must will only have 1175 appearance numbers for outgoing calls if assigned by the Appearance 1176 Agent. If the non-shared appearance UA does not support Join or 1177 Replaces, all dialogs SHOULD be marked "exclusive" to indicate that 1178 these options are not available. Marking these dialogs "exclusive" 1179 provides a better user experience and avoids extra SIP messaging 1180 failures. 1182 9.2. Appearance Release 1184 In all cases the Appearance Agent must be aware of dialog lifetime to 1185 release appearances back into the group. 1187 It is also desirable that any dialog state changes (such as hold, 1188 etc) be made available to other UAs in the group through the Dialog 1189 Event Package. If the Appearance Agent includes a proxy which 1190 Record-Routes for dialogs from the non-shared appearance aware UA, 1191 the Appearance Agent will know about the state of dialogs including 1192 hold, etc. This information could be determined from inspection of 1193 non-end-to-end-encrypted INVITE and re-INVITE messages and added to 1194 the dialog information conveyed to other UAs. 1196 9.3. UAs Supporting Dialog Events but Not Shared Appearance 1198 Interoperability with UAs which support dialog events but not the 1199 shared appearance feature is more straightforward. As before, all 1200 appearance number assignment must be done by the Appearance Agent. 1201 The Appearance Agent SHOULD still include appearance information in 1202 NOTIFYs - this UA will simply ignore this extra information. This 1203 type of UA will also ignore appearance number limitations and may 1204 attempt to Join or Replace dialogs marked exclusive. As a result, 1205 the Proxy or UAs need to reject such requests or the dialogs will get 1206 joined or taken. 1208 10. Provisioning Considerations 1210 UAs can automatically discover if this feature is active for an AOR 1211 by looking for the 'shared' Event header field parameter in a 1212 response to a dialog package SUBSCRIBE to the AOR, so no provisioning 1213 for this is needed. 1215 The registrar will need to be provisioned to accept either first or 1216 third party registrations for the shared AOR. First party 1217 registration means the To and From URIs in the REGISTER request are 1218 the shared AOR URI. Third party registration means the To URI is the 1219 shared AOR URI and the From URI is a different AOR, perhaps that of 1220 the individual user. Either the credentials of the shared AOR or the 1221 user MUST be accepted by the registrar and the Appearance Agent, 1222 depending on the authorization policy in place for the domain. 1224 If the Appearance Agent needs to subscribe to the dialog state of the 1225 UAs, then the Appearance Agent and the UAs need to be provisioned 1226 with credentials so the UAs can authenticate the Appearance Agent. 1228 In some cases, UAs in the shared appearance group might have a UI 1229 limitation on the number of appearances that can be rendered. 1230 Typically this will be hard phones with buttons/lamps instead of more 1231 flexible UIs. In this case, it can be useful for the Appearance 1232 Agent to know this maximum number. This can allow the Appearance 1233 Agent to apply policy when this limit is reached, e.g. deny a call. 1234 However, this mechanism does not provide any way to discover this by 1235 protocol means. 1237 11. Example Message Flows 1239 The next section shows call flow and message examples. The flows and 1240 descriptions are non-normative. Note that in these examples, all 1241 INVITEs sent by a UA in the group will be From the shared AOR 1242 (sip:HelpDesk@example.com in this case), and all INVITES sent to the 1243 group will have a Request-URI of the shared AOR. Any other requests 1244 would not apply to this feature and would be handled using normal SIP 1245 mechanisms. 1247 Note that the first twelve examples assume the Appearance Agent is 1248 aware of dialog state events. The example in Section 11.13 shows the 1249 case where this is not the case and as a result the Appearance Agent 1250 initiates a subscription to users of the shared AOR. Any of the 1251 other call flow examples could have shown this mode of operation as 1252 it is equally valid. 1254 11.1. Registration and Subscription 1256 Bob and Alice are in an appearance group identified by the shared 1257 appearance AOR sip:HelpDesk@example.com. Bob REGISTERs using contact 1258 sip:bob@ua2.example.com. Alice REGISTERs with contact 1259 sip:alice@ua1.example.com. 1261 User Agents for Alice and Bob subscribe to the dialog package for the 1262 appearance AOR and publish dialog state to the Appearance Agent. 1263 Message exchanges between the Registrar, Appearance Agent, Alice, and 1264 Bob are shown below. The call flow examples below do not show the 1265 authentication of subscriptions, publications, and notifications. It 1266 should be noted that for security purposes, all publications and 1267 subscriptions must be authorized before they are accepted. 1269 Also note that registrations and subscriptions must all be refreshed 1270 by Alice at intervals determined by the expiration intervals returned 1271 by the Registrar or Appearance Agent. 1273 Registrar Appearance Agent Alice Bob 1274 | | | | 1275 | | | | 1276 |<--------------------------- REGISTER F1<| | 1277 | | | | 1278 |>F2 200 OK ----------------------------->| | 1279 | | | | 1280 | |<----- SUBSCRIBE F3<| | 1281 | | | | 1282 | |>F4 200 OK -------->| | 1283 | | | | 1284 | |>F5 NOTIFY -------->| | 1285 | | | | 1286 | |<-------- 200 OK F6<| | 1287 | | | | 1288 |<-------------------------------------------- REGISTER F7<| 1289 | | | | 1290 |>F8 200 OK ---------------------------------------------->| 1291 | | | | 1292 | |<---------------------- SUBSCRIBE F9<| 1293 | | | | 1294 | |>F10 200 OK ------------------------>| 1295 | | | | 1296 | |>F11 NOTIFY ------------------------>| 1297 | | | | 1298 | |<------------------------ 200 OK F12<| 1299 | | | | 1301 Figure 1. 1303 F1-F2: Alice registers AOR with 1304 contact: 1306 F1 Alice ----> Registrar 1308 REGISTER sip:registrar.example.com SIP/2.0 1309 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09 1310 From: ;tag=CDF9A668-909E2BDD 1311 To: 1312 CSeq: 2 REGISTER 1313 Call-ID: d3281184-518783de-cc23d6bb 1314 Contact: 1315 Max-Forwards: 70 1316 Expires: 3600 1317 Content-Length: 0 1319 F2 Registrar ----> Alice 1321 SIP/2.0 200 OK 1322 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09 1323 CSeq: 2 REGISTER 1324 Call-ID: d3281184-518783de-cc23d6bb 1325 From: ;tag=CDF9A668-909E2BDD 1326 To: ;tag=1664573879820199 1327 Contact: ;expires=3600 1328 Content-Length: 0 1330 F3 to F6: Alice also subscribes to the events associated with the 1331 Appearance AOR. Appearance Agent notifies Alice of the status. 1333 F3 Alice ----> Appearance Agent 1335 SUBSCRIBE sip:HelpDesk@example.com SIP/2.0 1336 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A 1337 From: ;tag=925A3CAD-CEBB276E 1338 To: 1339 CSeq: 91 SUBSCRIBE 1340 Call-ID: ef4704d9-bb68aa0b-474c9d94 1341 Contact: 1342 Event: dialog;shared 1343 Accept: application/dialog-info+xml 1344 Max-Forwards: 70 1345 Expires: 3700 1346 Content-Length: 0 1348 F4 Appearance Agent ----> Alice 1350 SIP/2.0 200 OK 1351 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A 1352 CSeq: 91 SUBSCRIBE 1353 Call-ID: ef4704d9-bb68aa0b-474c9d94 1354 From: ;tag=925A3CAD-CEBB276E 1355 To: ;tag=1636248422222257 1356 Allow-Events: dialog 1357 Expires: 3700 1358 Contact: 1359 Content-Length: 0 1361 F5 Appearance Agent ----> Alice 1363 NOTIFY sip:alice@ua1.example.com SIP/2.0 1364 From: ;tag=1636248422222257 1365 To: ;tag=925A3CAD-CEBB276E 1366 Call-ID: ef4704d9-bb68aa0b-474c9d94 1367 CSeq: 232 NOTIFY 1368 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1846 1369 Max-Forwards: 70 1370 Content-Type: application/dialog-info+xml 1371 Event: dialog;shared 1372 Subscription-State: active;expires=3000 1373 Contact: 1374 Content-Length: ... 1376 1377 1381 1383 F6 Alice ----> Appearance Agent 1385 SIP/2.0 200 OK 1386 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1846 1387 From: ;tag=1636248422222257 1388 To: ;tag=925A3CAD-CEBB276E 1389 CSeq: 232 NOTIFY 1390 Call-ID: ef4704d9-bb68aa0b-474c9d94 1391 Contact: 1392 Content-Length: 0 1394 F7 Bob ----> Registrar 1396 REGISTER sip:registrar.example.com SIP/2.0 1397 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4b53b54d87B 1398 From: ;tag=34831131 1399 To: 1400 CSeq: 72 REGISTER 1401 Call-ID: 139490230230249348 1402 Contact: 1403 Max-Forwards: 70 1404 Expires: 3600 1405 Content-Length: 0 1407 F8 Registrar ----> Bob 1409 SIP/2.0 200 OK 1410 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4b53b54d87B 1411 From: ;tag=34831131 1412 To: ;tag=fkwlwqi1 1413 CSeq: 72 REGISTER 1414 Call-ID: 139490230230249348 1415 Contact: ;expires=3200 1416 Contact: ;expires=3600 1417 Content-Length: 0 1419 11.2. Appearance Selection for Incoming Call 1421 In the call flow below Bob and Alice are in an appearance group. 1422 Carol places a call to the appearance group AOR. The Appearance 1423 Agent sends NOTIFYs to Alice and Bob telling them what appearance the 1424 call is using. Both Alice and Bob's devices are alerted of the 1425 incoming call. Bob answers the call. 1427 Note that it is possible that both Alice and Bob answer the call and 1428 send 200 OK responses to Carol. It is up to Carol to resolve this 1429 situation. Typically, Carol will send ACKs to both 200 OKs but send 1430 a BYE to terminate one of the dialogs. As a result, either Alice or 1431 Bob will receive the BYE and publish that their dialog is over. 1432 However, if Carol answers both Alice and Bob and keeps both dialogs 1433 active, then the Appearance Agent will need to resolve the situation 1434 by moving either Alice or Bob's dialog to a different appearance. 1436 All NOTIFY messages in the call flow below carry dialog events and 1437 only dialog states are mentioned for simplicity. For brevity, the 1438 details of some messages are not shown below. Note that the order of 1439 F2 - F5 and F7 - F8 could be reversed. 1441 Forking Appearance 1442 Carol Proxy Agent Alice Bob 1443 | | | | | 1444 |>F1 INVITE >| | | | 1445 | |< - - - - - >| | | 1446 | | |>F2 NOTIFY ----------->| 1447 | | | | | 1448 | | |F4 NOTIFY ->| | 1451 | | | | | 1452 | | |<-200 OK F5-<| | 1453 |<- 100 F6 -<| | | | 1454 | |>F7 INVITE (appearance=1) ---------->| 1455 | | | | | 1456 | |>F8 INVITE (appearance=1) >| | 1457 | | | | | 1458 | |<-------------------- Ringing 180 F9<| 1459 |< 180 F10 -<| | | | 1460 | |<--------- 180 Ringing F11<| | 1461 |< 180 F12 -<| | | | 1462 | | | | | 1463 | |<------------------------ 200 OK F13<| 1464 |< 200 F14 -<| | | | 1465 | | | | | 1466 | |>F15 CANCEL -------------->| | 1467 | | | | | 1468 | |<-------------- 200 OK F16<| | 1469 | | | | | 1470 | |F18 ACK ----------------->| | 1473 |>F19 ACK -->| | | | 1474 | |>F20 ACK --------------------------->| 1475 | | | | | 1476 |<=============Both way RTP established===========>| 1477 | | | | | 1478 | |< - - - - - >| | | 1479 | | | | | 1480 | | |>F21 NOTIFY >| | 1481 | | | | | 1482 | | |<- 200 F22 -<| | 1483 | | | | | 1484 | | |>F23 NOTIFY ---------->| 1485 | | | | | 1486 | | | Alice 1493 NOTIFY sip:alice@ua1.example.com SIP/2.0 1494 From: ;tag=151702541050937 1495 To: ;tag=18433323-C3D237CE 1496 Call-ID: 1e361d2f-a9f51109-bafe31d4 1497 CSeq: 12 NOTIFY 1498 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1403 1499 Max-Forwards: 70 1500 Content-Type: application/dialog-info+xml 1501 Event: dialog;shared 1502 Subscription-State: active;expires=2800 1503 Contact: 1504 Content-Length: ... 1506 1507 1512 1516 1 1517 trying 1518 1519 sip:carol@ua.example.com 1520 1521 1522 1524 F7 Proxy ----> Bob 1526 INVITE sip:bob@ua2.example.com SIP/2.0 1527 Via: SIP/2.0/UDP ua3.example.com;branch=z9hG4bK4324ea 1528 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK38432ji 1529 From: ;tag=44BAD75D-E3128D42 1530 To: 1531 CSeq: 106 INVITE 1532 Call-ID: 14-1541707345 1533 Contact: 1534 Max-Forwards: 69 1535 Alert-Info: ;appearance=1 1536 Content-Type: application/sdp 1537 Content-Length: ... 1539 v=0 1540 o=- 1102980499 1102980499 IN IP4 ua3.example.com 1541 s= 1542 c=IN IP4 ua3.example.com 1543 t=0 0 1544 m=audio 2238 RTP/AVP 0 8 101 1545 a=rtpmap:0 PCMU/8000 1546 a=rtpmap:8 PCMA/8000 1547 a=rtpmap:101 telephone-event/8000 1549 F21 Appearance Agent ----> Alice 1551 NOTIFY sip:alice@ua1.example.com SIP/2.0 1552 From: ;tag=151702541050937 1553 To: ;tag=18433323-C3D237CE 1554 Call-ID: 1e361d2f-a9f51109-bafe31d4 1555 CSeq: 13 NOTIFY 1556 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK4164F03j 1557 Max-Forwards: 70 1558 Content-Type: application/dialog-info+xml 1559 Event: dialog;shared 1560 Subscription-State: active;expires=2500 1561 Contact: 1562 Content-Length: ... 1564 1565 1570 1575 1 1576 confirmed 1577 1578 sip:bob@ua2.example.com 1579 1580 1581 sip:carol@ua.example.com 1582 1583 1584 1586 11.3. Outgoing Call without Appearance Seizure 1588 In this scenario, Bob's UA places a call without first selecting/ 1589 seizing an appearance number. After Bob sends the INVITE, the 1590 appearance assigns an appearance number for it and notifies both 1591 Alice and Bob. 1593 Carol Proxy Alice Appearance Agent Bob 1594 | | | | | 1595 | | | | | 1596 | |<------------------------------------- INVITE F1<| 1597 | | | | | 1598 | |>F2 100 Trying --------------------------------->| 1599 |<-- INVITE F3<| | | | 1600 | |< - - - - - - - - - - - - - ->| | 1601 | | | | | 1602 | | |<-- NOTIFY F4<| | 1603 | | | | | 1604 | | |>F5 200 OK -->| | 1605 | | | |------- NOTIFY F6>| 1606 | | | | | 1607 | | | |F8 180 ---->| | | | 1609 | |>F9 180 Ringing -------------------------------->| 1610 | | | | | 1611 | |< - - - - - - - - - - - - - ->| | 1612 | | | | | 1613 | | |<- NOTIFY F10<| | 1614 | | | | | 1615 | | |>F11 200 OK ->| | 1616 | | | |------ NOTIFY F12>| 1617 | | | | | 1618 | | | |F14 200 OK ->| | | | 1620 | |>F15 200 OK ------------------------------------>| 1621 | | | | | 1622 | |<--------------------------------------- ACK F16<| 1623 |<---- ACK F17<| | | | 1624 | | | | | 1625 |<================= Both way RTP established ===================>| 1626 | | | | | 1627 | |< - - - - - - - - - - - - - ->| | 1628 | | | | | 1629 | | |<- NOTIFY F18<| | 1630 | | | | | 1631 | | |>F19 200 OK ->| | 1632 | | | |------ NOTIFY F20>| 1633 | | | | | 1634 | | | | Proxy 1641 INVITE sip:carol@example.com SIP/2.0 1642 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK98c87c52123A08BF 1643 From: ;tag=15A3DE7C-9283203B 1644 To: 1645 CSeq: 1 INVITE 1646 Call-ID: f3b3cbd0-a2c5775e-5df9f8d5 1647 Contact: 1648 Max-Forwards: 70 1649 Content-Type: application/sdp 1650 Content-Length: 223 1652 v=0 1653 o=- 1102980499 1102980499 IN IP4 ua2.example.com 1654 s=IP SIP UA 1655 c=IN IP4 ua2.example.com 1656 t=0 0 1657 a=sendrecv 1658 m=audio 2236 RTP/AVP 0 8 101 1659 a=rtpmap:0 PCMU/8000 1660 a=rtpmap:8 PCMA/8000 1661 a=rtpmap:101 telephone-event/8000 1663 F4 Appearance Agent ----> Alice 1665 NOTIFY sip:alice@ua1.example.com SIP/2.0 1666 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK81d84f62 1667 From: ;tag=1636248422222257 1668 To: ;tag=925A3CAD-CEBB276E 1669 Call-ID: ef4704d9-bb68aa0b-474c9d94 1670 CSeq: 233 NOTIFY 1671 Max-Forwards: 70 1672 Content-Type: application/dialog-info+xml 1673 Event: dialog;shared 1674 Subscription-State: active;expires=2200 1675 Contact: 1676 Content-Length: ... 1678 1679 1684 1687 1 1688 false 1689 trying 1690 1691 1692 1693 1694 1695 1697 F6 Appearance Agent ----> Bob 1699 NOTIFY sip:bob@ua1.example.com SIP/2.0 1700 From: ;tag=497585728578386 1701 To: ;tag=633618CF-B9C2EDA4 1702 Call-ID: a7d559db-d6d7dcad-311c9e3a 1703 CSeq: 7 NOTIFY 1704 Via: SIP/2.0/UDP appearanceagent.example.com 1705 ;branch=z9hG4bK1711759878512309 1706 Max-Forwards: 70 1707 Content-Type: application/dialog-info+xml 1708 Event: dialog;shared 1709 Subscription-State: active;expires=2000 1710 Contact: 1711 Content-Length: ... 1713 1714 1719 1722 1 1723 false 1724 trying 1725 1726 1727 1728 1729 1730 1732 11.4. Outgoing Call with Appearance Seizure 1734 In this scenario, Bob's UA sends out a dialog event PUBLISH with 1735 state (trying) selecting/seizing an appearance number before sending 1736 the INVITE. After receiving the 200 OK from the Appearance Agent 1737 confirming the appearance number, Bob's UA sends the INVITE to Carol 1738 and establishes a session. For brevity, details of some of the 1739 messages are not included in the message flows. Bob's UA puts as 1740 much of the dialog information from F7 as can be determined in 1741 advance. In this case, the minimum of the Contact URI is included 1742 which allows the Appearance Agent to correlate the INVITE with the 1743 PUBLISH. 1745 Carol Proxy Alice Appearance Agent Bob 1746 | | | | | 1747 | | | |<----- PUBLISH F1<| 1748 | | | | | 1749 | | | |>F2 200 OK ------>| 1750 | | | | | 1751 | | |<-- NOTIFY F3<| | 1752 | | | | | 1753 | | |>F4 200 OK -->| | 1754 | | | |------- NOTIFY F5>| 1755 | | | | | 1756 | | | |F8 100 Trying --------------------------------->| 1761 |<-- INVITE F9<| | | | 1762 | | | |<---- PUBLISH F10<| 1763 | | | | | 1764 | | | |>F11 200 OK ----->| 1765 | | | | | 1766 |>F12 180 --->| | | | 1767 | |>F13 180 Ringing ------------------------------->| 1768 | | | | | 1769 | |< - - - - - - - - - - - - - ->| | 1770 | | | | | 1771 | | |<- NOTIFY F14<| | 1772 | | | | | 1773 | | |>F15 200 OK ->| | 1774 | | | |------ NOTIFY F16>| 1775 | | | | | 1776 | | | |F18 200 OK ->| | | | 1778 | |>F19 200 OK ------------------------------------>| 1779 | | | | | 1780 | |<--------------------------------------- ACK F20<| 1781 |<---- ACK F21<| | | | 1782 | | | | | 1783 |<================= Both way RTP established ===================>| 1784 | | | | | 1785 | |< - - - - - - - - - - - - - ->| | 1786 | | | | | 1787 | | |<- NOTIFY F22<| | 1788 | | | | | 1789 | | |>F23 200 OK ->| | 1790 | | | |------ NOTIFY F24>| 1791 | | | | | 1792 | | | | Appearance Agent 1805 PUBLISH sip:HelpDesk@example.com SIP/2.0 1806 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 1807 From: ;tag=44150CC6-A7B7919D 1808 To: 1809 CSeq: 7 PUBLISH 1810 Call-ID: 44fwF144-F12893K38424 1811 Contact: 1812 Event: dialog;shared 1813 Max-Forwards: 70 1814 Content-Type: application/dialog-info+xml 1815 Content-Length: ... 1817 1818 1823 1824 1 1825 false 1826 trying 1827 1828 1829 1830 1831 1832 1833 F2 Appearance Agent ----> Bob 1835 SIP/2.0 200 OK 1836 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 1837 From: ;tag=44150CC6-A7B7919D 1838 To: 1839 CSeq: 7 PUBLISH 1840 Call-ID: 44fwF144-F12893K38424 1841 Contact: 1842 Event: dialog;shared 1843 SIP-Etag: 482943245 1844 Allow-Events: dialog 1845 Expires: 60 1846 Content-Length: 0 1848 F7 Bob ---> Proxy 1850 INVITE sip:carol@example.com SIP/2.0 1851 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK342122 1852 Max-Forwards: 70 1853 From: ;tag=15A3DE7C-9283203B 1854 To: 1855 Call-ID: f3b3cbd0-a2c5775e-5df9f8d5 1856 CSeq: 31 INVITE 1857 Contact: 1858 Content-Type: application/sdp 1859 Content-Length: ... 1861 (SDP Not Shown) 1863 F10 Bob ----> Appearance Agent 1865 PUBLISH sip:HelpDesk@example.com SIP/2.0 1866 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK6d644638E7 1867 From: ;tag=0CCf6-A7FdsB79D 1868 To: 1869 CSeq: 437 PUBLISH 1870 Call-ID: fwF14d4-F1FFF2F2893K38424 1871 Contact: 1872 Event: dialog;shared 1873 Max-Forwards: 70 1874 Content-Type: application/dialog-info+xml 1875 Content-Length: ... 1877 1878 1883 1887 1 1888 false 1889 trying 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1901 11.5. Outgoing Call without using an Appearance Number 1903 In this scenario, Bob's UA sends out a dialog event PUBLISH with 1904 state (trying) indicating that he does not want to utilize an 1905 appearance number for this dialog. The PUBLISH does not have an 1906 appearance element but does have the 'shared' Event header field 1907 parameter. As a result, the Appearance Agent knows the UA does not 1908 wish to use an appearance number for this call. If the Appearance 1909 Agent does not wish to allow this, it would reject the PUBLISH with a 1910 400 (Bad Request) response and the UA would know to re-PUBLISH 1911 selecting/seizing an appearance number. 1913 Carol Proxy Alice Appearance Agent Bob 1914 | | | | | 1915 | | | |<----- PUBLISH F1<| 1916 | | | | | 1917 | | | |>F2 200 OK ------>| 1918 | | | | | 1919 | | |<-- NOTIFY F3<| | 1920 | | | | | 1921 | | |>F4 200 OK -->| | 1922 | | | |------- NOTIFY F5>| 1923 | | | | | 1924 | | | |F8 100 Trying --------------------------------->| 1929 |<-- INVITE F9<| | | | 1930 | | | |<---- PUBLISH F10<| 1931 | | | | | 1932 | | | |>F11 200 OK ----->| 1933 | | | | | 1934 |>F12 180 --->| | | | 1935 | |>F13 180 Ringing ------------------------------->| 1936 | | | | | 1937 | |< - - - - - - - - - - - - - ->| | 1938 | | | | | 1939 | | |<- NOTIFY F14<| | 1940 | | | | | 1941 | | |>F15 200 OK ->| | 1942 | | | |------ NOTIFY F16>| 1943 | | | | | 1944 | | | |F18 200 OK ->| | | | 1946 | |>F19 200 OK ------------------------------------>| 1947 | | | | | 1948 | |<--------------------------------------- ACK F20<| 1949 |<---- ACK F21<| | | | 1950 | | | | | 1951 |<================= Both way RTP established ===================>| 1952 | | | | | 1953 | |< - - - - - - - - - - - - - ->| | 1954 | | | | | 1955 | | |<- NOTIFY F22<| | 1956 | | | | | 1957 | | |>F23 200 OK ->| | 1958 | | | |------ NOTIFY F24>| 1959 | | | | | 1960 | | | | Appearance Agent 1967 PUBLISH sip:appearanceagent.example.com SIP/2.0 1968 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 1969 From: ;tag=4415df82k39sf 1970 To: 1971 CSeq: 7 PUBLISH 1972 Call-ID: 44fwF144-F12893K38424 1973 Contact: 1974 Event: dialog;shared 1975 Max-Forwards: 70 1976 Content-Type: application/dialog-info+xml 1977 Content-Length: ... 1979 1980 1985 1986 false 1987 trying 1988 1989 1990 1991 1992 1993 1995 Note that F7 would be the same as the previous example. 1997 11.6. Appearance Release 1999 Bob and Carol are in a dialog, created, for example as in 2000 Section 11.3. Carol sends a BYE to Bob to terminate the dialog and 2001 the Appearance Agent de-allocates the appearance number used, sending 2002 notifications out to the UAs in the shared group. 2004 Carol Proxy Alice Appearance Agent Bob 2005 | | | | | 2006 | | | | | 2007 |<================= Both way RTP established ===================>| 2008 | | | | | 2009 |>F22 BYE ---->| | | | 2010 | |>F23 BYE --------------------------------------->| 2011 | | | | | 2012 | |<------------------------------------ 200 OK F24<| 2013 |<--200 OK F25<| | | | 2014 | |< - - - - - - - - - - - - - ->| | 2015 | | | | | 2016 | | |<- NOTIFY F26<| | 2017 | | | | | 2018 | | |>F27 200 OK ->| | 2019 | | | |------ NOTIFY F28>| 2020 | | | | | 2021 | | | | Bob 2026 NOTIFY sip:bob@ua1.example.com SIP/2.0 2027 From: ;tag=497585728578386 2028 To: 2029 Call-ID: a7d559db-d6d7dcad-311c9e3a 2030 CSeq: 7 NOTIFY 2031 Via: SIP/2.0/UDP appearanceagent.example.com 2032 ;branch=z9hG4bK759878512309 2033 Max-Forwards: 70 2034 Content-Type: application/dialog-info+xml 2035 Event: dialog;shared 2036 Subscription-State: active;expires=1800 2037 Contact: 2038 Content-Length: ... 2040 2041 2046 2051 1 2052 false 2053 terminated 2054 2055 2056 2057 2058 2059 2061 11.7. Appearance Pickup 2063 In this scenario, Bob has an established dialog with Carol created 2064 using the call flows of Figure 1 or Figure 2. Bob then places Carol 2065 on hold. Alice receives a notification of this and renders this on 2066 Alice's UI. Alice subsequently picks up the held call and has a 2067 established session with Carol. Finally, Carol hangs up. Alice must 2068 PUBLISH F32 to indicate that the INVITE F38 will be an attempt to 2069 pickup the dialog between Carol and Bob, and hence may use the same 2070 appearance number. This example also shows Secure SIP (sips) being 2071 used. 2073 Carol Proxy Alice Appearance Agent Bob 2074 | | | | | 2075 |<================= Both way RTP established ===================>| 2076 | | | | | 2077 | |<------------------------------(hold) INVITE F22<| 2078 |<- INVITE F23<| | | | 2079 | | | | | 2080 |>F24 200 OK ->| | | | 2081 | |>F25 200 OK ------------------------------------>| 2082 | | | | | 2083 | |<--------------------------------------- ACK F26<| 2084 |<---- ACK F27<| | | | 2085 | |< - - - - - - - - - - - - - ->| | 2086 | | | | | 2087 | | |<- NOTIFY F28<| | 2088 | | | | | 2089 | | |>F29 200 OK ->| | 2090 | | | |>F30 NOTIFY ----->| 2091 | | | | | 2092 | | | |<----- 200 OK F31<| 2093 | | | | | 2094 | | Alice decides to pick up the call | 2095 | | | | | 2096 | | |>F32 PUBLISH->| | 2097 | | | | | 2098 | | |<- 200 OK F33<| | 2099 | | | | | 2100 | | |<- NOTIFY F34<| | 2101 | | | | | 2102 | | |>F35 200 OK ->| | 2103 | | | |>F36 NOTIFY ----->| 2104 | | | | | 2105 | | | |<----- 200 OK F37<| 2106 | |<-- INVITE F38<| | | 2107 |<- INVITE F39<|(w/ Replaces) | | | 2108 |( w/ Replaces)| | | | 2109 |>F40 200 OK ->| | | | 2110 | |>F41 200 OK -->| | | 2111 | | | | | 2112 | |< - - - - - - - - - - - - - ->| | 2113 | | | | | 2114 | | | |>F42 NOTIFY ----->| 2115 | | | | | 2116 | | | |<----- 200 OK F43<| 2117 | | |<- NOTIFY F44<| | 2118 | | | | | 2119 | | |>F45 200 OK ->| | 2120 | | | | | 2121 | |<----- ACK F46<| | | 2122 |<---- ACK F47<| | | | 2123 | | | | | 2124 |<= Both way RTP established =>| | | 2125 | | | | | 2126 |>F48 BYE ---->| | | | 2127 | |>F49 BYE --------------------------------------->| 2128 | | | | | 2129 | |<------------------------------------ OK 200 F50<| 2130 |<- 200 OK F51<| | | | 2131 | | | | | 2132 | |< - - - - - - - - - - - - - ->| | 2133 | | | | | 2134 | | |<- NOTIFY F52<| | 2135 | | | | | 2136 | | |>F53 200 OK ->| | 2137 | | | | | 2138 | | | |>F54 NOTIFY ----->| 2139 | | | | | 2140 | | | |<----- 200 OK F55<| 2142 Figure 7. 2144 F28 Appearance ----> Alice 2146 NOTIFY sips:alice@ua1.example.com SIP/2.0 2147 From: ;tag=151702541050937 2148 To: ;tag=18433323-C3D237CE 2149 Call-ID: 1e361d2f-a9f51109-bafe31d4 2150 CSeq: 12 NOTIFY 2151 Via: SIP/2.0/TLS appearanceagent.example.com 2152 ;branch=z9hG4bK1403 2153 Max-Forwards: 70 2154 Content-Type: application/dialog-info+xml 2155 Event: dialog;shared 2156 Subscription-State: active;expires=1800 2157 Contact: 2158 Content-Length: ... 2160 2161 2166 2171 1 2172 false 2173 active 2174 2175 2176 2177 2178 2179 2180 sips:carol@example.com 2181 2182 2183 2184 2186 F32 Alice ----> Appearance Agent 2188 PUBLISH sips:HelpDesk@example.com SIP/2.0 2189 Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A 2190 From: ;tag=44150CC6-A7B7919D 2191 To: ;tag=428765950880801 2192 CSeq: 11 PUBLISH 2193 Call-ID: 87837Fkw87asfds 2194 Contact: 2195 Event: dialog;shared 2196 Max-Forwards: 70 2197 Content-Type: application/dialog-info+xml 2198 Content-Length: ... 2200 2201 2206 2209 1 2210 false 2211 2215 trying 2216 2217 2218 2219 2220 2221 2222 2223 2224 2225 2227 F38 Alice ----> Proxy 2229 INVITE sips:carol@example.com SIP/2.0 2230 Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK4ea695b5B376A60C 2231 From: ;tag=8C4183CB-BCEAB710 2232 To: 2233 CSeq: 1 INVITE 2234 Call-ID: 3d57cd17-47deb849-dca8b6c6 2235 Contact: 2236 2237 Replaces: f3b3cbd0-a2c5775e-5df9f8d5;to-tag=65a98f7c 2238 -1dd2-11b2-88c6-b03162323164+65a98f7c;from-tag=15A3DE7C-9283203B 2239 2240 Max-Forwards: 70 2241 Content-Type: application/sdp 2242 Content-Length: 223 2244 v=0 2245 o=- 1102980497 1102980497 IN IP4 ua1.example.com 2246 s=IP SIP UA 2247 c=IN IP4 ua1.example.com 2248 t=0 0 2249 a=sendrecv 2250 m=audio 2238 RTP/AVP 0 8 101 2251 a=rtpmap:0 PCMU/8000 2252 a=rtpmap:8 PCMA/8000 2253 a=rtpmap:101 telephone-event/8000 2255 11.8. Calls between UAs within the Group 2257 In this scenario, Bob calls Alice who is also in the Appearance 2258 group. Only one appearance number is used for this dialog. This 2259 example also shows the use of the 'exclusive' tag to indicate that 2260 other UAs in the group can not join or take this dialog. 2262 Carol Proxy Alice Appearance Agent Bob 2263 | | | | | 2264 | |<-------------------- INVITE (to Alice's UA) F1<| 2265 | | | | | 2266 | |< - - - - - - - - - - - - - ->| | 2267 | | | | | 2268 | | | | | 2269 | | |<-- NOTIFY F2<| | 2270 | | | | | 2271 | | |>F3 200 OK -->| | 2272 | | | |>F4 NOTIFY ------>| 2273 | | | | | 2274 | | | |<------ 200 OK F5<| 2275 | |>F6 INVITE --->| | | 2276 | | (appearance=1)| | | 2277 | | | | | 2278 | |<------ 180 F7<| | | 2279 | | | | | 2280 | |>F8 180 --------------------------------------->| 2281 | | | | | 2282 | |< - - - - - - - - - - - - - ->| | 2283 | | | | | 2284 | | |<-- NOTIFY F9<| | 2285 | | | | | 2286 | | |>F10 200 OK ->| | 2287 | | | |>F11 NOTIFY ----->| 2288 | | | | | 2289 | | | |<----- 200 OK F12<| 2290 | |<-- 200 OK F13<| | | 2291 | | | | | 2292 | |>F14 200 OK ------------------------------------>| 2293 | | | | | 2294 | |<--------------------------------------- ACK F15<| 2295 | | | | | 2296 | |>F16 ACK ----->| | | 2297 | | | | | 2298 | | |<======= RTP established =======>| 2299 | | | | | 2300 | |< - - - - - - - - - - - - - ->| | 2301 | | | | | 2302 | | |<- NOTIFY F17<| | 2303 | | | | | 2304 | | |>F18 200 OK ->| | 2305 | | | |>F19 NOTIFY ----->| 2306 | | | | | 2307 | | | |<----- 200 OK F24<| 2308 | | | | | 2310 Figure 8. 2312 F19 Appearance Agent ----> Bob 2314 NOTIFY sip:bob@ua1.example.com SIP/2.0 2315 From: ;tag=497585728578386 2316 To: ;tag=633618CF-B9C2EDA4 2317 Call-ID: a7d559db-d6d7dcad-311c9e3a 2318 CSeq: 7 NOTIFY 2319 Via: SIP/2.0/UDP appearanceagent.example.com 2320 ;branch=z9hG4bK1711759878512309 2321 Max-Forwards: 70 2322 Content-Type: application/dialog-info+xml 2323 Event: dialog;shared 2324 Subscription-State: active;expires=1500 2325 Contact: 2326 Content-Length: ... 2328 2329 2334 2339 true 2340 1 2341 confirmed 2342 2343 2344 2345 2346 2347 sip:HelpDesk@example.com 2348 2349 2351 2353 2358 true 2359 1 2360 confirmed 2361 2362 2363 2364 2365 sip:HelpDesk@example.com 2366 2367 2368 2370 2372 11.9. Consultation Hold with Appearances 2374 In this scenario, Bob has a call with Carol. Bob makes a 2375 consultation call to Alice by putting Carol on hold and calling 2376 Alice. Bob's UA chooses not to have an appearance number for the 2377 call to Alice since it is treating it as part of the call to Carol. 2378 He indicates this in the PUBLISH F32 which contains the 'shared' 2379 Event header field parameter but no element. The 2380 PUBLISH is sent before the INVITE to Alice to ensure no appearance 2381 number is assigned by the Appearance Agent. Finally, Bob hangs up 2382 with Alice and resumes the call with Carol. Dialog notifications of 2383 the consultation call are not shown, as they are not used. 2385 Note that if Carol hangs up while Bob is consulting with Alice, Bob 2386 can decide if he wants to reuse the appearance number used with Carol 2387 for the call with Alice. If not, Bob publishes the termination of 2388 the dialog with Carol and the Appearance Agent will re-allocate the 2389 appearance. If he wants to keep the appearance, Bob will publish the 2390 termination of the dialog with Carol and also publish the appearance 2391 with the dialog with Alice. This will result in Bob keeping the 2392 appearance number until he reports the dialog with Alice terminated. 2394 Note that the call flow would be similar if Bob called a music on 2395 hold server instead of Alice to implement a music on hold service as 2396 described in [I-D.worley-service-example]. 2398 Carol Proxy Alice Appearance Agent Bob 2399 | | | | | 2400 |<================= Both way RTP established ===================>| 2401 | | | | | 2402 | |<------------------------------(hold) INVITE F22<| 2403 |<- INVITE F23<| | | | 2404 | | | | | 2405 |>F24 200 OK ->| | | | 2406 | |>F25 200 OK ------------------------------------>| 2407 | | | | | 2408 | |<--------------------------------------- ACK F26<| 2409 |<---- ACK F27<| | | | 2410 | |< - - - - - - - - - - - - - ->| | 2411 | | | | | 2412 | | |<- NOTIFY F28<| | 2413 | | | | | 2414 | | |>F29 200 OK ->| | 2415 | | | |>F30 NOTIFY ----->| 2416 | | | | | 2417 | | | |<----- 200 OK F31<| 2418 | | | | | 2419 | | Bob makes a consultation call to Alice | 2420 | | | | | 2421 | | | |<---- PUBLISH F32<| 2422 | | | | | 2423 | | | |>F33 200 OK ----->| 2424 | | | | | 2425 | |<------------------------------------ INVITE F34<| 2426 | | | | | 2427 | |>F35 INVITE -->| | | 2428 | | | | | 2429 | |<-- 200 OK F36<| | | 2430 | | | | | 2431 | |>F37 200 OK ------------------------------------>| 2432 | | | | | 2433 | |<--------------------------------------- ACK F38<| 2434 | | | | | 2435 | |>F39 ACK ----->| | | 2436 | | | | | 2437 | | |<======= RTP established =======>| 2438 | | | | | 2439 | | Bob hangs up with Alice | 2440 | | | | | 2441 | |<--------------------------------------- BYE F40<| 2442 | | | | | 2443 | |>F41 BYE ----->| | | 2444 | | | | | 2445 | |<-- 200 OK F42<| | | 2446 | | | | | 2447 | |>F43 200 OK ------------------------------------>| 2448 | | | | | 2449 | |<----------------------------(unhold) INVITE F44<| 2450 |<- INVITE F45<| | | | 2451 | | | | | 2452 |>F46 200 OK ->| | | | 2453 | |>F47 200 OK ------------------------------------>| 2454 | | | | | 2455 | |<--------------------------------------- ACK F48<| 2456 |<---- ACK F49<| | | | 2457 | |< - - - - - - - - - - - - - ->| | 2458 | | | | | 2459 | | |<- NOTIFY F50<| | 2460 | | | | | 2461 | | |>F51 200 OK ->| | 2462 | | | |>F52 NOTIFY ----->| 2463 | | | | | 2464 | | | |<----- 200 OK F53<| 2465 | | | | | 2466 |<================= Both way RTP established ===================>| 2467 | | | | | 2469 Figure 9. 2471 F32 Bob ----> Appearance Agent 2473 PUBLISH sip:HelpDesk@example.com SIP/2.0 2474 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A 2475 From: ;tag=44150CC6-A7B7919D 2476 To: ;tag=428765950880801 2477 CSeq: 11 PUBLISH 2478 Call-ID: 44fwF144-F12893K38424 2479 Contact: 2480 Event: dialog;shared 2481 Max-Forwards: 70 2482 Content-Type: application/dialog-info+xml 2483 Content-Length: ... 2485 2486 2491 2496 true 2497 trying 2498 2499 2500 2501 2502 2503 sip:HelpDesk@example.com 2504 2505 2506 2507 2509 11.10. Joining or Bridging an Appearance 2511 In this call flow, a call answered by Bob is joined by Alice or 2512 "bridged". The Join header field is used by Alice to request this 2513 bridging. If Bob did not support media mixing, Bob could obtain 2514 conferencing resources as described in [RFC4579]. 2516 Carol Forking Proxy Appearance Agent Alice Bob 2517 | | | | | 2518 |<=============Both way RTP established===========>| 2519 | | | | | 2520 | | |< PUBLISH F22| | 2521 | | | | | 2522 | | |>F23 200 OK >| | 2523 | | | | | 2524 | |<---- INVITE (w/ Join) F24<| | 2525 | | | | | 2526 | |>F25 INVITE (w/Join)---------------->| 2527 | | | | | 2528 | |<---- OK 200 Contact:Bob;isfocus F26<| 2529 | | | | | 2530 | |< - - - - - >| | | 2531 | | | | | 2532 | | |>F27 NOTIFY >| | 2533 | | | | | 2534 | | |< 200 OK F28<| | 2535 | | | | | 2536 | | |>F29 NOTIFY ---------->| 2537 | | | | | 2538 | | |F31 200 OK Contact:B----->| | 2541 | | | | | 2542 | |<----------------- ACK F32<| | 2543 | | | | | 2544 | |>ACK F33---------------------------->| 2545 | | | | | 2546 | |<-----INVITE Contact:Bob;isfocus F34<| 2547 |<-INVITE F35| | | | 2548 | | | | | 2549 |>F26 200 -->| | | | 2550 | |>F37 200 OK ------------------------>| 2551 | | | | | 2552 | |<--------------------------- ACK F38<| 2553 |<--- ACK F39| | | | 2554 | | | |<==RTP==>| 2555 |<=============Both way RTP established===========>| 2556 | | | | | 2557 | |< - - - - - >| | | 2558 | | | | | 2559 | | |>F40 NOTIFY >| | 2560 | | | | | 2561 | | |< 200 OK F41<| | 2562 | | | | | 2563 | | |>F42 NOTIFY ---------->| 2564 | | | | | 2565 | | | Appearance Agent 2572 PUBLISH sip:HelpDesk@example.com SIP/2.0 2573 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A 2574 From: ;tag=44150CC6-A7B7919D 2575 To: ;tag=428765950880801 2576 CSeq: 11 PUBLISH 2577 Call-ID: 87837Fkw87asfds 2578 Contact: 2579 Event: dialog;shared 2580 Max-Forwards: 70 2581 Content-Type: application/dialog-info+xml 2582 Content-Length: ... 2584 2585 2590 2593 1 2594 false 2595 2599 trying 2600 2601 2602 2603 2604 2605 2606 2607 2608 2610 F24 Alice ----> Proxy 2612 INVITE sip:bob@ua.example.com SIP/2.0 2613 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKcc9d727c2C29BE31 2614 From: ;tag=605AD957-1F6305C2 2615 To: 2616 CSeq: 2 INVITE 2617 Call-ID: dc95da63-60db1abd-d5a74b48 2618 Contact: 2619 2620 Join: 14-1541707345;to-tag=d3b06488-1dd1-11b2-88c5 2621 -b03162323164+d3e48f4c;from-tag=44BAD75D-E3128D42 2622 2623 Max-Forwards: 70 2624 Content-Type: application/sdp 2625 Content-Length: 223 2627 v=0 2628 o=- 1103061265 1103061265 IN IP4 ua1.example.com 2629 s=IP SIP UA 2630 c=IN IP4 ua1.example.com 2631 t=0 0 2632 a=sendrecv 2633 m=audio 2236 RTP/AVP 0 8 101 2634 a=rtpmap:0 PCMU/8000 2635 a=rtpmap:8 PCMA/8000 2636 a=rtpmap:101 telephone-event/8000 2638 11.11. Appearance Allocation - Loss of Appearance 2640 Bob reserves an appearance with a PUBLISH, sends an INVITE to Carol, 2641 then becomes unreachable. When he fails to refresh his publication 2642 to the appearance agent, the Appearance Agent declares the dialog 2643 terminated and frees up the appearance using NOTIFYs F14 and F16. 2644 After retransmitting the NOTIFY to Bob (in not shown messages F17, 2645 F18, etc.), the subscription is terminated. 2647 Carol Proxy Alice Appearance Agent Bob 2648 | | | | | 2649 | | | |<----- PUBLISH F1<| 2650 | | | | | 2651 | | | |>F2 200 OK ------>| 2652 | | | | | 2653 | | |<-- NOTIFY F3<| | 2654 | | | | | 2655 | | |>F4 200 OK -->| | 2656 | | | |------- NOTIFY F5>| 2657 | | | | | 2658 | | | |F8 100 Trying --------------------------------->| 2663 |<-- INVITE F9<| | | | 2664 | | | |<---- PUBLISH F10<| 2665 | | | | | 2666 | | | |>F11 200 OK ----->| 2667 | | | | | 2668 |>F12 180 --->| | | | 2669 | |>F13 180 Ringing ------------------------------->| 2670 | | | | | 2671 | | | | Bob goes offline | 2672 | | | | | 2673 | | | Appearance selection times out | 2674 | | | | | 2675 | | |<- NOTIFY F14<| | 2676 | | | | | 2677 | | |>F15 200 OK ->| | 2678 | | | |------ NOTIFY F16>| 2679 | | | | | 2680 | | | NOTIFY is retransmitted | 2682 Figure 11. 2684 11.12. Appearance Seizure Contention Race Condition 2686 Bob and Alice both try to reserve appearance 2 by publishing at the 2687 same time. The Appearance Agent allocates the appearance to Bob by 2688 sending a 200 OK and denies it to Alice by sending a 400 (Bad 2689 Request) response. After the NOTIFY F5, Alice learns that Bob is 2690 using appearance 2. Alice then attempts to reserve appearance 3 by 2691 publishing, which is then accepted. 2693 Carol Proxy Alice Appearance Agent Bob 2694 | | | | | 2695 | | | |<----- PUBLISH F1<| 2696 | | | | (appearance=2) 2697 | | |>F2 PUBLISH ->| | 2698 | | | (appearance=2) | 2699 | | | | | 2700 | | | |>F3 200 OK ------>| 2701 | | |<---- F4 400 <| | 2702 | | | | | 2703 | | |<-- NOTIFY F5<| | 2704 | | | | | 2705 | | |>F6 200 OK -->| | 2706 | | | |------- NOTIFY F7>| 2707 | | | | | 2708 | | | |F10 100 Trying -------------------------------->| 2713 |<- INVITE F11<| | | | 2714 | | | |<---- PUBLISH F12<| 2715 | | | | (appearance=2) 2716 | | | |>F13 200 OK ----->| 2717 | | |>F14 PUBLISH->| | 2718 | | | (appearance=3) | 2719 | | | | | 2720 | | |<--- F15 200 <| | 2721 | | | | | 2722 | | |<- NOTIFY F16<| | 2723 | | | | | 2724 | |>F17 200 OK ->| | 2725 Dave | | |------ NOTIFY F18>| 2726 | | | | | 2727 | | | |F21 100 ----->| | | 2731 |<- INVITE F22<| | | | 2733 Figure 12. 2735 11.13. Appearance Agent Subscription to UAs 2737 In this scenario, the Appearance Agent does not have any way of 2738 knowing Bob's dialog state information, except through Bob. This 2739 could be because the Appearance Agent is not part of a B2BUA, or 2740 perhaps Bob is remotely registering. When Bob registers, the 2741 Appearance Agent receives a registration event package notification 2742 from the registrar. The Appearance Agent then SUBSCRIBEs to Bob's 2743 dialog event state using Event:dialog in the SUBSCRIBE. Whenever 2744 Bob's dialog state changes, Bob's UA sends a NOTIFY to the Appearance 2745 Agent which then notifies the other other UAs in the group. 2747 Carol Proxy Alice Appearance Agent Bob 2748 | | | | | 2749 | |<----------------------------------- REGISTER F1<| 2750 | | | | | 2751 | |>F2 200 OK ------------------------------------->| 2752 | | | | | 2753 | |>F3 NOTIFY ------------------>| | 2754 | | | | | 2755 | |<------------------ 200 OK F4<| | 2756 | | | |---- SUBSCRIBE F5>| 2757 | | | | | 2758 | | | |F8 200 OK ------>| 2763 | | | | | 2764 | | | |<--- SUBSCRIBE F9<| 2765 | | | | | 2766 | | | |>F10 200 OK ----->| 2767 | | | | | 2768 | | | |------ NOTIFY F11>| 2769 | | | | | 2770 | | | |F14 100 Trying -------------------------------->| 2775 |<- INVITE F15<| | | | 2776 | | | |<----- NOTIFY F16<| 2777 | | | | | 2778 | | | |>F17 200 OK ----->| 2779 | | |<- NOTIFY F18<| | 2780 | | | | | 2781 | | |>F19 200 OK ->| | 2782 | | | |------ NOTIFY F20>| 2783 | | | | | 2784 | | | |F22 180 --->| | | | 2786 | |>F23 180 Ringing ------------------------------->| 2787 | | | | | 2788 | | | |<----- NOTIFY F24<| 2789 | | | | | 2790 | | | |>F25 200 OK ----->| 2791 | | |<- NOTIFY F26<| | 2792 | | | | | 2793 | | |>F27 200 OK ->| | 2794 | | | |------ NOTIFY F28>| 2795 | | | | | 2796 | | | |F30 200 OK ->| | | | 2798 | |>F31 200 OK ------------------------------------>| 2799 | | | | | 2800 | | | |<----- NOTIFY F32<| 2801 | | | | | 2802 | | | |>F33 200 OK ----->| 2803 | | | | | 2804 | |<--------------------------------------- ACK F34<| 2805 |<---- ACK F35<| | | | 2806 | | | | | 2807 |<================= Both way RTP established ===================>| 2808 | | | | | 2809 | | |<- NOTIFY F36<| | 2810 | | | | | 2811 | | |>F37 200 OK ->| | 2812 | | | |------ NOTIFY F38>| 2813 | | | | | 2814 | | | || 2832 | | | | | 2833 | |<------------------------------(hold) INVITE F22<| 2834 |<- INVITE F23<| | | | 2835 | | | | | 2836 |>F24 200 OK ->| | | | 2837 | |>F25 200 OK ------------------------------------>| 2838 | | | | | 2839 | |<--------------------------------------- ACK F26<| 2840 |<---- ACK F27<| | | | 2841 | | | | | 2842 | |< - - - - - - - - - - - - - ->| | 2843 | | | | | 2844 | | |<- NOTIFY F28<| | 2845 | | | | | 2846 | | |>F29 200 OK ->| | 2847 | | | |>F30 NOTIFY ----->| 2848 | | | | | 2849 | | | |<----- 200 OK F31<| 2850 | | | | | 2851 | | Alice decides to pick up the call | 2852 | | | | | 2853 | | |>F32 PUBLISH->| | 2854 | | | | | 2855 | | |<- 200 OK F33<| | 2856 | | | | | 2857 | | |<- NOTIFY F34<| | 2858 | | | | | 2859 | | |>F35 200 OK ->| | 2860 | | | |>F36 NOTIFY ----->| 2861 | | | | | 2862 | | | |<----- 200 OK F37<| 2863 |>F38 BYE ---->| | | | 2864 | |>F39 BYE --------------------------------------->| 2865 | | | | | 2866 | |<------------------------------------ OK 200 F40<| 2867 |<- 200 OK F41<| | | | 2868 | |<-- INVITE F42<| | | 2869 |<- INVITE F43<|(w/ Replaces) | | | 2870 |( w/ Replaces)| | | | 2871 | | | | | 2872 |>F44 481 ---->| | | | 2873 | |>F45 481 ----->| | | 2874 |<---- ACK F46<| | | | 2875 | |<----- ACK F47<| | | 2876 | | |>F48 PUBLISH->| | 2877 | | | | | 2878 | | |<- 200 OK F49<| | 2879 | | | | | 2880 | | |<- NOTIFY F50<| | 2881 | | | | | 2882 | | |>F51 200 OK ->| | 2883 | | | |>F52 NOTIFY ----->| 2884 | | | | | 2885 | | | |<----- 200 OK F53<| 2887 Figure 14. 2889 F48 Alice ----> Appearance Agent 2891 PUBLISH sip:HelpDesk@example.com SIP/2.0 2892 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A 2893 From: ;tag=44150CC6-A7B7919D 2894 To: ;tag=428765950880801 2895 CSeq: 11 PUBLISH 2896 Call-ID: 87837Fkw87asfds 2897 Contact: 2898 Event: dialog;shared 2899 Max-Forwards: 70 2900 Content-Type: application/dialog-info+xml 2901 Content-Length: ... 2903 2904 2909 2912 1 2913 false 2914 2918 terminated 2919 2920 2921 2922 2923 2924 2925 2926 2927 2929 11.15. Appearance Seizure Incoming/Outgoing Contention Race Condition 2931 Alice tries to seize appearance 2 at the same time appearance 2 is 2932 allocated to an incoming call. The Appearance Agent resolves the 2933 conflict by sending a 400 (Bad Request) to Alice. After the NOTIFY 2934 F6, Alice learns that the incoming call is using appearance 2. Alice 2935 republishes for appearance 3, which is accepted. Note that this 2936 example shows the INVITE being received before the NOTIFY from the 2937 Appearance Agent. 2939 Carol Proxy Alice Appearance Agent Bob 2940 | | | | | 2941 |>-- INVITE F1>| | | | 2942 | |< - - - - - - - - - - - - - ->| | 2943 | | | | | 2944 | | |>F2 PUBLISH ->| | 2945 | | | (appearance=2) | 2946 | | | | | 2947 | |>F3 INVITE (appearance=2) ---------------------->| 2948 | | | | | 2949 | |>F4 INVITE | | | 2950 | |(appearance=2)>| | | 2951 | | |<---- F5 400 <| | 2952 | | | | | 2953 | | |<-- NOTIFY F6<| | 2954 | | | | | 2955 | | |>F7 200 OK -->| | 2956 | | | |------- NOTIFY F8>| 2957 | | | | | 2958 | | | |F10 PUBLISH->| | 2961 | | | (appearance=3) | 2962 | | | | | 2963 | | |< F11 200 OK <| | 2964 | | | | | 2965 | | |<- NOTIFY F12<| | 2966 | | | | | 2967 | |>F13 200 OK ->| | 2968 Dave | | |------ NOTIFY F14>| 2969 | | | | | 2970 | | | |F17 100 ----->| | | 2974 |<- INVITE F18<| | | | 2976 Figure 15. 2978 12. Security Considerations 2980 Since multiple line appearance features are implemented using 2981 semantics provided by SIP [RFC3261], the SIP Event Package for Dialog 2982 State [RFC4235], and the SIP Event Framework 2983 [I-D.ietf-sipcore-rfc3265bis] and [RFC3903], security considerations 2984 in these documents apply to this document as well. 2986 To provide confidentiality, NOTIFY or PUBLISH message bodies that 2987 provide the dialog state information and the dialog identifiers MAY 2988 be encrypted end-to-end using the standard mechanisms such as S/MIME 2989 described in [RFC3261]. Alternatively, sending the NOTIFY and 2990 PUBLISH requests over TLS also provides confidentiality, although on 2991 a hop-by-hop basis. All SUBSCRIBES and PUBLISHES between the UAs and 2992 the Appearance Agent MUST be authenticated. Without proper 2993 authentication and confidentiality, a third party could learn 2994 information about dialogs associated with a AOR and could try to use 2995 this information to hijack or manipulate those dialogs using SIP call 2996 control primitives. 2998 This feature relies on standard SIP call control primitives such as 2999 Replaces and Join. Proper access controls on their use MUST be used 3000 so that only members of the appearance group can use these 3001 mechanisms. All INVITEs with Replaces or Join header fields MUST 3002 only be accepted if the peer requesting dialog replacement or joining 3003 has been properly authenticated using a standard SIP mechanism (such 3004 as Digest or S/MIME), and authorized to request a replacement. 3005 Otherwise, a third party could disrupt or hijack existing dialogs in 3006 the appearance group. 3008 For an emergency call, a UA MUST NOT wait for a confirmed seizure of 3009 an appearance before sending an INVITE. Waiting for confirmation 3010 could inadvertently delay or block the emergency call, which by its 3011 nature needs to be placed as expeditiously as possible. Instead, a 3012 emergency call MUST proceed regardless of the status of the PUBLISH 3013 transaction. 3015 13. IANA Considerations 3017 This section registers the SIP Event header field parameter 'shared', 3018 the SIP Alert-Info header field parameter 'appearance' and the XML 3019 namespace extensions to the SIP Dialog Package. 3021 13.1. SIP Event Header Field Parameter: shared 3023 This document defines the 'shared' header field parameter to the 3024 Event header field in the "SIP Header Field Parameters and Parameter 3025 Values" registry defined by [RFC3968]. 3027 Predefined 3028 Header Field Parameter Name Values Reference 3029 ---------------------------- ------------------ ---------- --------- 3030 Event shared No [RFC-to-be] 3032 13.2. SIP Alert-Info Header Field Parameter: appearance 3034 This document defines the 'appearance' parameter to the Alert-Info 3035 header in the "SIP Header Field Parameters and Parameter Values" 3036 registry defined by [RFC3968]. 3038 Predefined 3039 Header Field Parameter Name Values Reference 3040 ---------------------- --------------- --------- --------- 3041 Alert-Info appearance No [RFC-to-be] 3043 13.3. URN Sub-Namespace Registration: sa-dialog-info 3045 This section registers a new XML namespace per the procedures 3046 in [RFC3688]. 3048 URI: urn:ietf:params:xml:ns:sa-dialog-info. 3050 Registrant Contact: IETF BLISS working group, , 3051 Alan Johnston 3053 XML: 3055 BEGIN 3056 3057 3059 3060 3061 3063 Shared Appearance Dialog Information Namespace 3064 3065 3066

Namespace for Shared Appearance Dialog Information

3067

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

3068

See 3069 RFCXXXX.

3070 3071 3072 END 3074 13.4. XML Schema Registration 3076 This section registers an XML schema per the procedures in 3077 [RFC3688]. 3079 URI: urn:ietf:params:xml:schesa:sa-dialog-info. 3081 Registrant Contact: IETF BLISS working group, , 3082 Alan Johnston 3084 The XML for this schema can be found in Section 6. 3086 14. Acknowledgements 3088 The following individuals were part of the shared appearance Design 3089 team and have provided input and text to the document (in 3090 alphabetical order): 3092 Martin Dolly, Andrew Hutton, Raj Jain, Fernando Lombardo, Derek 3093 MacDonald, Bill Mitchell, Michael Procter, Theo Zourzouvillys. 3095 Thanks to Chris Boulton for helping with the XML schema. 3097 Much of the material has been drawn from previous work by Mohsen 3098 Soroushnejad, Venkatesh Venkataramanan, Paul Pepper and Anil Kumar, 3099 who in turn received assistance from: 3101 Kent Fritz, John Weald, and Sunil Veluvali of Sylantro Systems, Steve 3102 Towlson, and Michael Procter of Citel Technologies, Rob Harder and 3103 Hong Chen of Polycom Inc, John Elwell, J D Smith of Siemens 3104 Communications, Dale R. Worley of Pingtel, Graeme Dollar of Yahoo 3105 Inc. 3107 Also thanks to Geoff Devine, Paul Kyzivat, Jerry Yin, John Elwell, 3108 Dan York, Spenser Dawkins, Martin Dolly, and Brett Tate for their 3109 comments. 3111 Thanks to Carolyn Beeton, Francois Audet, Andy Hutton, Tim Ross, Raji 3112 Chinnappa, and Harsh Mendiratta for their detailed review of the 3113 document. 3115 15. References 3117 15.1. Normative References 3119 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3120 Requirement Levels", BCP 14, RFC 2119, March 1997. 3122 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3123 A., Peterson, J., Sparks, R., Handley, M., and E. 3124 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3125 June 2002. 3127 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 3128 Specifications: ABNF", STD 68, RFC 5234, January 2008. 3130 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 3131 Method", RFC 3515, April 2003. 3133 [I-D.ietf-sipcore-rfc3265bis] 3134 Roach, A., "SIP-Specific Event Notification", 3135 draft-ietf-sipcore-rfc3265bis-09 (work in progress), 3136 April 2012. 3138 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 3139 for Event State Publication", RFC 3903, October 2004. 3141 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 3142 Protocol (SIP) "Replaces" Header", RFC 3891, 3143 September 2004. 3145 [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- 3146 Initiated Dialog Event Package for the Session Initiation 3147 Protocol (SIP)", RFC 4235, November 2005. 3149 [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol 3150 (SIP) "Join" Header", RFC 3911, October 2004. 3152 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 3153 "Indicating User Agent Capabilities in the Session 3154 Initiation Protocol (SIP)", RFC 3840, August 2004. 3156 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3157 January 2004. 3159 [I-D.ietf-salud-alert-info-urns] 3160 Liess, L., Jesske, R., Johnston, A., Worley, D., and P. 3161 Kyzivat, "Alert-Info URNs for the Session Initiation 3162 Protocol (SIP)", draft-ietf-salud-alert-info-urns-07 (work 3163 in progress), October 2012. 3165 15.2. Informative References 3167 [RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and 3168 K. Summers, "Session Initiation Protocol Service 3169 Examples", BCP 144, RFC 5359, October 2008. 3171 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol 3172 (SIP) Call Control - Conferencing for User Agents", 3173 BCP 119, RFC 4579, August 2006. 3175 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 3176 Package for Registrations", RFC 3680, March 2004. 3178 [I-D.worley-service-example] 3179 Worley, D., "Session Initiation Protocol Service Example 3180 -- Music on Hold", draft-worley-service-example-10 (work 3181 in progress), August 2012. 3183 Authors' Addresses 3185 Alan Johnston (editor) 3186 Avaya 3187 St. Louis, MO 63124 3189 Email: alan.b.johnston@gmail.com 3191 Mohsen Soroushnejad 3192 Sylantro Systems Corp 3194 Email: msoroush@gmail.com 3196 Venkatesh Venkataramanan 3197 Sylantro Systems Corp 3199 Email: vvenkatar@gmail.com