idnits 2.17.1 draft-ietf-bliss-shared-appearances-13.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. 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 (July 30, 2012) is 4259 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 3006, but not defined == Missing Reference: 'RFC-to-be' is mentioned on line 3020, but not defined == Outdated reference: A later version (-14) exists of draft-ietf-salud-alert-info-urns-06 == Outdated reference: A later version (-15) exists of draft-worley-service-example-09 Summary: 1 error (**), 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: January 31, 2013 Sylantro Systems Corp 7 July 30, 2012 9 Shared Appearances of a Session Initiation Protocol (SIP) Address of 10 Record (AOR) 11 draft-ietf-bliss-shared-appearances-13 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 January 31, 2013. 47 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 2. Conventions used in this document . . . . . . . . . . . . . . 6 77 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 6 78 3.1. Executive/Assistant Arrangement . . . . . . . . . . . . . 6 79 3.2. Call Group . . . . . . . . . . . . . . . . . . . . . . . 7 80 3.3. Single Line Extension . . . . . . . . . . . . . . . . . . 7 81 3.4. Changing UAs . . . . . . . . . . . . . . . . . . . . . . 7 82 4. Requirements and Implementation . . . . . . . . . . . . . . . 7 83 4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 7 84 4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 9 85 5. Normative Description . . . . . . . . . . . . . . . . . . . . 11 86 5.1. Elements . . . . . . . . . . . . . . . . . . . . . . . . 11 87 5.2. Shared Appearance Dialog Package Extensions . . . . . . . 12 88 5.2.1. The element . . . . . . . . . . . . . . . 12 89 5.2.2. The element . . . . . . . . . . . . . . . 12 90 5.2.3. The element . . . . . . . . . . . . . 13 91 5.2.4. The element . . . . . . . . . . . . 14 92 5.3. Shared Appearance User Agents . . . . . . . . . . . . . . 14 93 5.3.1. Appearance Numbers and Call Context . . . . . . . . . 17 94 5.3.2. Appearance Numbers and Call Control . . . . . . . . . 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 . . . . . 67 135 13.4. XML Schema Registration . . . . . . . . . . . . . . . . . 68 136 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 68 137 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69 138 15.1. Normative References . . . . . . . . . . . . . . . . . . 69 139 15.2. Informative References . . . . . . . . . . . . . . . . . 70 140 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70 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, n, 288 and large numbers of UAs, N, without introducing excessive messaging 289 traffic. 291 REQ-6 Each call or session (incoming or outgoing) should be assigned 292 a common "appearance" number from a managed pool administered for the 293 AOR group. Once the session has terminated, the appearance number is 294 released back into the pool and can be reused by another incoming or 295 outgoing session. 297 REQ-7 Each UA in the group must be able to learn the status of all 298 appearances of the group. 300 REQ-8 There must be mechanisms to resolve appearance contention among 301 the UAs in the group. 303 REQ-9 The mechanism must allow all UAs receiving an incoming session 304 request to utilize the same appearance number at the time of 305 alerting. 307 REQ-10 The mechanism must have a way of reconstructing appearance 308 state after an outage that does not result in excessive traffic and 309 processing. 311 REQ-11 The mechanism must have backwards compatibility such that a UA 312 which is unaware of the feature can still register against the group 313 AOR and make and receive calls. 315 REQ-12 The mechanism must not allow UAs outside the group to select, 316 seize or manipulate appearance numbers. 318 REQ-13 For privacy reasons, there must be a mechanism so that 319 appearance information is not leaked outside the group of UAs. (e.g. 320 "So who do you have on line 1?") 322 REQ-14 The mechanism must support a way for UAs to request 323 exclusivity on a line appearance. Exclusivity means that the UA 324 requesting it desires to have a private conversation with the 325 external party and other UAs must not be allowed to join or take the 326 call. Exclusivity may be requested at the start of an incoming or 327 outgoing session or during the session. An exclusivity request may 328 be accepted or rejected by the entity providing the shared appearance 329 service. Therefore, the mechanism must provide a way of 330 communicating the result back to the requester UA. 332 REQ-15 The mechanism should support a way for a UA to seize a 333 particular appearance number for outgoing requests prior to sending 334 the actual request. This is often called seizure. 336 REQ-16 The mechanism should support a way for a UA to seize a 337 particular appearance number and also send the request at the same 338 time. This is needed when an automatic ringdown feature (a telephone 339 configured to immediately dial a phone number when it goes off hook) 340 is combined with shared appearances - in this case, seizing the line 341 is integrated with dialing. 343 4.2. Implementation 345 This section non-normatively discusses the implementation of the 346 shared appearance feature. The normative description is in 347 Section 5. Many of the requirements for this service can be met 348 using standard SIP mechanisms such as: 350 - A SIP Forking Proxy and Registrar/Location Service meets REQ-1. 352 - The SIP Dialog Package meets REQ-2. 354 - The SIP Replaces and Join header fields meets REQ-3. 356 - The use of a State Agent for the Dialog Package meets REQ-4 and 357 REQ-5. 359 REQ-6 suggests the need for an entity which manages the appearance 360 resource. Just as conferencing systems commonly have a single point 361 of control, known as a focus, a Shared Appearance group has a single 362 point of control of the appearance shared resource. This is defined 363 as an Appearance Agent for a group. While an Appearance Agent can be 364 part of a centralized server, it could also be co-resident in a 365 member User Agent that has taken on this functionality for a group. 366 The Appearance Agent knows or is able to determine the dialog state 367 of all members of the group. 369 While the appearance resource could be managed co-operatively by a 370 group of UAs without any central control, this is outside the scope 371 of this draft. It is also possible that the Appearance Agent logic 372 could be distributed in all UAs in the group. For example, rules 373 that govern assigning appearance numbers for incoming requests (e.g. 374 lowest available appearance number) and rules for contention handling 375 (e.g. when two UAs request the use of the same appearance number, 376 hash dialog identifiers and compare with the lowest hash winning) 377 would need to be defined and implemented. 379 To best meet REQ-9, the appearance number for an incoming INVITE 380 needs to be contained in the INVITE, in addition to being delivered 381 in the dialog package NOTIFY. Otherwise, if the NOTIFY is delayed or 382 lost, a UA in the group might receive an incoming INVITE but might 383 not know which appearance number to render during alerting. 385 This specification defines an extension parameter for the Alert-Info 386 header field in RFC 3261 to carry the appearance number: 388 Alert-Info: ;appearance=1 390 The following list describes the operation of the shared appearance 391 feature. 393 1. A UA is configured with the AOR of a shared appearance group. It 394 registers against the AOR, then attempts a dialog state 395 subscription to the AOR. If the subscription fails, loops back 396 to itself, or returns an error, it knows there is no State Agent, 397 and hence no Appearance Agent and this feature is not 398 implemented. 399 2. If the subscription receives a 200 OK, the UA knows there is a 400 State Agent and that the feature is implemented. The UA then 401 follows the steps in this list. 402 3. Information learned about the dialog state of other UAs in the 403 group is rendered to the user. 404 4. Incoming calls are forked to all UAs in the group, and any may 405 answer. UAs receive the appearance number to use in rendering 406 the incoming call in a NOTIFY from the Appearance Agent and in 407 the INVITE itself. The UA will also receive a notification if 408 the call is answered by another UA in the group so this 409 information can be rendered to the user. 410 5. For outgoing calls, the operation depends on the implementation. 411 If the user seizes a particular appearance number for the call, 412 the UA publishes the trying state dialog information with the 413 desired appearance number and waits for a 2xx response before 414 sending the INVITE. 415 6. For outgoing calls, if the user does not seize a particular 416 appearance or does not care, the INVITE can be sent immediately, 417 and the appearance number learned as the call progresses from a 418 notification from the Appearance Agent. 419 7. For outgoing calls, if the user does not want an appearance 420 number assigned (such as during a consultation call or if a UA is 421 fetching 'service media' such as music on hold 422 [I-D.worley-service-example]), the UA also publishes prior to 423 sending the INVITE but does not include an appearance number in 424 the publication. 426 8. Established calls within the group may be joined (bridged) or 427 taken (picked) by another UA. Information in the dialog package 428 notifications can be used to construct Join or Replaces header 429 fields. Since the same appearance number is used for these types 430 of operations, this information is published prior to sending the 431 INVITE Join or INVITE Replaces. 432 9. The Appearance Agent may not have direct access to the complete 433 dialog state of some or all of the UAs in the group. If this is 434 the case, the Appearance Agent will subscribe to the dialog state 435 of individual UAs in the group to obtain this information. In 436 any case, the Appearance Agent will send normal notifications 437 (via the subscriptions established by the UAs in step 1) every 438 time the aggregate dialog state of the AOR changes, including 439 when calls are placed, answered, placed on and off hold, and hung 440 up. 442 5. Normative Description 444 This section normatively describes the shared appearance feature 445 extensions. The following definitions are used throughout this 446 document: 448 Appearance number: An appearance number is a positive integer 449 associated with one or more dialogs of an AOR. Appearance numbers 450 are managed by an Appearance Agent and displayed and rendered to the 451 user by UAs that support this specification. When an appearance 452 number is assigned or requested, generally the assigned number is the 453 smallest positive integer that is not currently assigned as an 454 appearance number to a dialog for this AOR. 456 Seizing: An appearance can be reserved prior to a call being placed 457 by seizing the appearance. An appearance can be seized by 458 communicating an artificial state of "trying" prior to actually 459 initiating a dialog (i.e. sending the INVITE), in order to appear as 460 if it was already initiating a dialog. 462 Selecting(or Not-Seizing): An appearance is merely selected (i.e., 463 not seized) if there is no such communication of artificial state of 464 "trying" prior to initiating a dialog: i.e., the state is 465 communicated when the dialog is actually initiated. The appearance 466 number is learned after the INVITE is sent. 468 5.1. Elements 470 A complete system to implement this feature consists of: 472 1. User Agents that support publications, subscriptions, and 473 notifications for the SIP dialog event package, and the shared 474 appearance dialog package extensions and behavior. 475 2. An Appearance Agent consisting of a State Agent for the dialog 476 event package that implements an Event State Compositor (ESC) and 477 the shared appearance dialog package extensions and behavior. 478 The Appearance Agent also has logic for assigning and releasing 479 appearance numbers, and resolving appearance number contention. 480 3. A forking proxy server that can communicate with the State Agent 481 4. A registrar that supports the registration event package. 483 The behavior of these elements is described normatively in the 484 following sections after the definitions of the dialog package 485 extensions. 487 5.2. Shared Appearance Dialog Package Extensions 489 This specification defines four new elements as extensions to the SIP 490 Dialog Event package [RFC4235]. The schema is defined in Section 6. 491 The elements are , , , and 492 which are sub-elements of the element. 494 5.2.1. The element 496 The element, a child of the element, is used to 497 convey the appearance number of the dialog described by the parent 498 element. When sent by a UA in a PUBLISH with parent 499 with state attribute "trying" to the Appearance Agent, the 500 UA is requesting assignment of the given appearance number to the 501 current or future dialog with the given dialog identifiers. When an 502 element is sent by the Appearance Agent in a NOTIFY, it 503 indicates that the appearance number has been assigned to the 504 specified dialog. 506 Note that a element describes the contained dialogs 507 from the point of view of the UA (named by the "entity" attribute), 508 regardless of whether the containing request is sent by the UA or the 509 Appearance Agent. In particular, if the UA sent a request within the 510 described dialog, the To header field URI would match the 511 value and the to-tag parameter would match the remote-tag 512 attribute. Similarly, the From header field URI would match the 513 value and the from-tag parameter would match the 514 local-tag attribute. 516 5.2.2. The element 518 The element, a child of the element, is a 519 boolean, which when true, indicates that the UA is not willing to 520 accept an INVITE with a Join or Replaces header field targeted to the 521 dialog described by the element that is the parent of the 522 element. For example, some shared appearance systems 523 only allow call pickup when the call is on hold. In this case, the 524 element should be set to "false" when the call is held 525 and "true" when the call is not held, rather than having the 526 "exclusive" value implied by the hold state. 528 It is important to note that this element is a hint. In order to 529 prevent another UA from taking or joining a call, a UA can, in 530 addition to setting the tag, not report full dialog 531 information to the Appearance Agent. Not having the full dialog 532 information (Call-ID, remote-tag, and local-tag) prevents another UA 533 from constructing a Join or Replaces header field. Although a UA may 534 set exclusive to true, the UA must still be ready to reject an INVITE 535 Join relating to this dialog. If these dialog identifiers have 536 already been shared with the Appearance Agent, the UA could send an 537 INVITE Replaces to change them and then not report the new ones to 538 the Appearance Agent. 540 If the proxy knows which dialogs are marked exclusive, the proxy MAY 541 enforce this exclusivity by rejecting INVITE Join and INVITE Replaces 542 requests containing those dialog identifiers with a 403 Forbidden 543 response. 545 Note that exclusivity has nothing to do with appearance number 546 selection or seizing - instead, it is about call control 547 operations that can be performed on a dialog. 549 If the element is not present, it is assumed to be false. 551 5.2.3. The element 553 The element, a child of the element, is used 554 to convey dialog identifiers of any other dialogs which are joined 555 (mixed or bridged) with the dialog. Only the UA which is the common 556 endpoint of the mixed dialogs (and thus controlling the mixing 557 operation) should include this element in publications to the 558 Appearance Agent. Note that this element should still be used even 559 when the Join header field was not used to join the dialogs. For 560 example, two separate dialogs on a UA could be joined without any SIP 561 call control operations. Joined dialogs will share the same 562 appearance number. 564 If the element is not present, it is assumed that the 565 dialog is not joined or to be joined to any other dialog. 567 5.2.4. The element 569 The element, a child of the element, is 570 used to convey dialog identifiers of any other dialogs which will be 571 or have been replaced with this dialog. For example, a UA in the 572 group picking up a call on another UA by sending an INVITE with 573 Replaces would include this element for the replacing dialog. 574 Replaced dialogs will share the same appearance number. 576 If the element is not present, it is assumed that 577 the dialog has not replaced or is not to replace to any other dialog. 579 5.3. Shared Appearance User Agents 581 User Agents that support the Shared Appearance feature MUST support 582 the dialog state package [RFC4235] with the shared appearance 583 extensions and the 'shared' Event header field parameter defined in 584 Section 13. 586 User Agents MUST support the dialog package extensions in Section 5.2 587 along with SUBSCRIBE and NOTIFY [I-D.ietf-sipcore-rfc3265bis] and 588 PUBLISH [RFC3903]. SUBSCRIBE, NOTIFY, and PUBLISH requests for the 589 dialog event package include the 'shared' Event header field 590 parameter as required by this specification. 592 The presence of the 'shared' Event header field parameter tells 593 the Appearance Agent that the UA supports this specification. 595 Upon initialization, the UA MUST subscribe to the dialog event 596 package of the AOR and refresh the subscription per the SIP Events 597 Framework. If the SUBSCRIBE request fails, then no Appearance Agent 598 may be present and this feature is not active for this AOR. The UA 599 MAY periodically retry the subscription to see if conditions have 600 changed at intervals no shorter than 4 hours. 602 Four hours was chosen to limit the subscription test to 6 per day 603 per UA. Increading this interval would reduce this failure 604 traffic but take longer for a newly activated Appearance Agent to 605 be discovered. 607 UAs can also use the presence of the 'shared' Event header field 608 parameter in NOTIFYs to discover the presence of an Appearance Agent 609 for the AOR. 611 User Agents which implement the shared appearances feature and call 612 pickup, joining and bridging MUST support sending an INVITE with 613 Replaces [RFC3891] or Join [RFC3911]. The User Agent Client needs to 614 include the to-tag and from-tag information in the Replaces or Join 615 header so that the correct dialog will be matched by the User Agent 616 Server per the rules in RFC 3891 and RFC 3911. 618 All User Agents which implement the shared appearances feature and 619 support INVITE MUST support receiving an INVITE with a Replaces 620 [RFC3891] or a Join [RFC3911] header field. 622 When publishing or notifying dialog package information, a UA MUST 623 include all dialog identification available at the time of 624 publication, with the exception that a UA may omit information if it 625 wishes to prevent other UAs from joining or picking up a call. 626 Dialog identification includes local and remote target URIs, call-id, 627 to-tag, and from-tag. When calls are placed on hold, the 628 "+sip.rendering=no" feature tag MUST be included in dialog package 629 notifications. 631 The accurate rendering of the idle/active/alerting/hold state of 632 other UAs in the group is an important part of the shared 633 appearance feature. 635 In the following cases, before sending the INVITE, A UA MUST send a 636 dialog package PUBLISH request and wait for a 2xx response before 637 proceeding: 639 1. When the user seizes a particular appearance number for an 640 outgoing call (e.g. seizing the appearance and going "off-hook", 641 if the UA's user interface uses this metaphor). 642 2. When the user has requested that an appearance number not be used 643 for an outgoing call (i.e. during a consultation call, a 'service 644 media' call such as for music on hold 645 [I-D.worley-service-example] or for a call not considered part of 646 the shared appearance group). 647 3. When the user has selected to join (or bridge) an existing call. 648 4. When the user has selected to replace (or take) an existing call. 650 An exception is an emergency call, when a UA MUST never wait for a 651 confirmed seizure before sending an INVITE. Instead, the emergency 652 call MUST proceed without waiting for the PUBLISH transaction. 654 Note that when a UA seizes an appearance prior to establishment of a 655 dialog (#1 and #2 in above list), not all dialog information will be 656 available. In particular, when a UA publishes an attempt to seize an 657 appearance prior to knowing the destination URI, minimal or no dialog 658 information may be available. For example, in some cases, only the 659 local target URI for the call will be known and no dialog 660 information. If the From tag and Call-ID were not present in the 661 initial PUBLISH, a new PUBLISH MUST be sent as soon as this 662 information is available. 664 The first publication will cause the Appearance Agent to reserve 665 the appearance number for this UA. If the publication does not 666 have any dialog identifiers (e.g. Call-ID, or local tag) the 667 Appearance Agent cannot assign the appearance number to a 668 particular dialog of the UA until the second publication which 669 will contain some dialog identifiers. 671 This publication state is refreshed as described in [RFC3903] during 672 the early dialog state or the Appearance Agent may reassign the 673 appearance number. Once the dialog has transitioned to the confirmed 674 state, no publication refreshes are necessary. 676 This specification assumes that the Appearance Agent has other 677 means besides UA publication to learn about the state of UA 678 dialogs. In this specification, PUBLISH is used to indicate 679 desired and intended appearance number operations. Once a dialog 680 transitions from early to confirmed, this role is over, and hence 681 no publication refreshes are needed. 683 Appearance numbers are a shorthand label for active and pending 684 dialogs related to an AOR. Many of the features and services built 685 using this extension rely on the correct rendering of this 686 information to the human user. In addition, the group nature of the 687 feature means that the rendering must be similar between different 688 vendors and different models. Failure to do so will greatly reduce 689 the value and usefulness of these protocol extensions. The 690 appearances number for each active and pending dialog SHOULD be 691 explicitly (i.e. by appearance number) or implicitly (using a user 692 interface metaphor that makes the numbering and ordering clear to the 693 user) rendered to the user. The far end identity of each dialog 694 (e.g. the remote party identity) MUST NOT be rendered in place of the 695 appearance number. The state of each appearance SHOULD also be 696 rendered (idle, active, busy, joined, etc.). UAs can tell that a set 697 of dialogs are joined (bridged or mixed) together by the presence of 698 one or more elements containing other SIP dialog 699 identifiers. Appearance numbers of dialogs can be learned by dialog 700 package notifications containing the element from the 701 Appearance Agent or from the 'appearance' Alert-Info parameter in an 702 incoming INVITE. Should they conflict, the dialog package 703 notification takes precedence. 705 A UA that does not need to seize a particular appearance number (or 706 doesn't care) would just send an INVITE as normal to place an 707 outbound call. 709 A user may select an appearance number but then abandon placing a 710 call (go back on hook). In this case, the UA MUST free up the 711 appearance number by removing the event state with a PUBLISH as 712 described in [RFC3903]. 714 A UA SHOULD register against the AOR only if it is likely the UA will 715 be answering incoming calls. If the UA is mainly going to be 716 monitoring the status of the shared appearance group calls and 717 picking or joining calls, the UA SHOULD only subscribe to the AOR and 718 not register against the AOR. 720 All subscribed UAs will receive dialog package NOTIFYs of trying 721 state for incoming INVITEs. 723 A UA MUST NOT insert an 'appearance' parameter into an Alert-Info 724 header field in an INVITE or other request. 726 The Appearance Agent is solely responsible for doing this. 728 5.3.1. Appearance Numbers and Call Context 730 There are cases where two separate dialogs at a UA are not mixed but 731 share the same 'context'. That is, they relate to each other and 732 should not be treated the same as any other two dialogs within the 733 group. One example of this is a 'consultation call' where a user 734 puts an existing dialog on hold, then calls another user, before 735 switching back to the original dialog. Another case, described 736 below, occurs during transfer operations, where for a transient 737 period, a UA is involved in dialogs with two other UAs, but the 738 dialogs are related, and should not be treated as independent 739 dialogs. These cases are best handled by not assigning an appearance 740 number to a newly-created dialog when it shares a context with an 741 existing dialog. But if the pre-existing dialog is terminated, its 742 appearance number should be reassigned to the newly-created dialog. 744 A UA wanting to place a call but not have an appearance number 745 assigned sends a PUBLISH before sending the INVITE. The PUBLISH does 746 not have an 'appearance' element present, but does have the 'shared' 747 Event header field parameter present. If the Appearance Agent policy 748 does not allow calls without an assigned appearance number, a 400 749 (Bad Request) response is sent by the Appearance Agent and the UA 750 will republish either selecting/seizing an appearance number or send 751 the INVITE without publishing, in which case the Appearance Agent 752 will assign one. 754 Note that if an Appearance Agent rejects calls without an 755 appearance number, certain operations such as consultation calls, 756 transfer, and music on hold may be negatively impacted. 758 5.3.2. Appearance Numbers and Call Control 760 When an INVITE is generated to attempt to bridge or take a call (i.e. 761 contains Join or Replaces with a dialog identifier of another dialog 762 in the shared appearance group), the UA MUST first send a PUBLISH to 763 the Appearance Agent. This PUBLISH will contain: 765 1. The appearance number of the joined or replaced call in the 766 element 767 2. If the dialog is being joined, the element will 768 contain the dialog information from the Join header field 769 3. If the dialog is being replaced, the element 770 will contain the dialog information from the Replaces header 771 field 773 Note that this information is provided to the Appearance Agent so 774 that it can provide proper appearance assignment behavior. If the 775 INVITE Join or Replaces was sent without publishing first, the 776 Appearance Agent might assign a new appearance number to this 777 INVITE, which would be a mistake. With Join, the publication has 778 the element to prevent the Appearance Agent from 779 generating a 400 (Bad Request) response due to the reuse of an 780 appearance number. For Replaces, the purpose of the is to prevent a race condition where the BYE could cause 782 the appearance number to be released when it should stay with the 783 replacing dialog. 785 5.3.3. Appearance Numbers and Transfer 787 During a transfer operation, it is important that the appearance 788 number not change during the operation. Consider the example of 789 Alice, a member of an appearance group, who is talking to Carol, who 790 is outside the appearance group. Carol transfers Alice to David, who 791 is also outside the appearance group. For example, if Alice is using 792 appearance 3 for the session with Carol, the resulting session with 793 David should also use appearance number 3. Otherwise, an appearance 794 number change can cause a "jump" on the UI and confusion to the user. 795 There are two possible scenarios using the terminology of RFC 5589: 796 Alice is the transferee in any type of transfer (receives the REFER) 797 or the transfer target in an attended transfer (receives the INVITE 798 with Replaces). 800 If Alice is the transferee, the triggered INVITE from the REFER is 801 treated as a consultation call. Alice SHOULD publish requesting that 802 the Appearance Agent not assign an appearance number for this INVITE. 803 When the transfer completes, Alice SHOULD publish again to move the 804 appearance number from the dialog with Carol to the dialog with 805 David. Note that this publication MUST be sent prior to sending the 806 BYE to Carol to avoid a race condition where the Appearance Agent 807 reassigns the appearance number after seeing the BYE. 809 If Alice is the target, the incoming INVITE will contain a Replaces 810 header field. As a result, the Appearance Agent will have reused the 811 appearance number of the dialog with Carol, and this appearance 812 number will continue to be used after the dialog with Carol has been 813 terminated. 815 5.4. Appearance Agent 817 An Appearance Agent defined in this specification MUST implement a 818 dialog package state agent for the UAs registered against the AOR. 819 The Appearance Agent MUST support the appearance dialog package 820 extensions defined in Section 5.2 and use the 'shared' Event header 821 field parameter. The Appearance Agent MUST support publications and 822 subscriptions for this event package. 824 The Appearance Agent MUST have a way of discovering the state of all 825 dialogs associated with the AOR. If this information is not 826 available from a call stateful proxy or Back-to-Back User Agent 827 (B2BUA), the Appearance Agent MAY use the registration event package 828 [RFC3680] to learn of UAs associated with the AOR and MAY subscribe 829 to their dialog event state. Also, an Appearance Agent MAY subscribe 830 to a UAs dialog event state in order to reconstruct state. As a 831 result, the registrar MUST support the registration event package. 832 Dialog package notifications are recommended by RFC 4235 to "only 833 contain information on the dialogs whose state or participation 834 information has changed." This specification extends RFC 4235 as 835 follows. The Appearance Agent SHOULD send dialog event state 836 notifications whenever the following events happen to UAs in the AOR 837 group: 839 1. A call is received, placed, answered, or terminated. 840 2. A call is placed on or off hold. 841 3. A call is joined or replaced. 842 4. An appearance number is reserved or released. 844 The Appearance Agent MUST allocate an appearance number for all 845 incoming calls and send immediate notifications to the UAs subscribed 846 to the shared group AOR. A new appearance number is allocated except 847 for an incoming INVITE with a Join or Replaces header field. For 848 this case, the appearance number should match the appearance number 849 of the dialog being joined or replaced. If the INVITE Replaces or 850 Join comes from outside the appearance group, the Appearance Agent 851 will include a or element in the 852 NOTIFY containing the dialog information from the Replaces or Joined 853 header field. 855 The Appearance Agent MUST be able to communicate with the forking 856 proxy to learn about incoming calls and also to pass the appearance 857 number to the proxy, or otherwise ensure the Alert-Info header field 858 is included in the INVITE with the appropriate appearance number. 860 Note that UAs need to be able to handle incoming INVITEs without 861 an appearance number assigned. This could be caused by a failure 862 of the Appearance Agent or other error condition. Although the 863 proper rendering of the INVITE may not be possible, this is better 864 than ignoring or failing the INVITE. 866 An Appearance Agent SHOULD assign an appearance number to an outgoing 867 dialog if a PUBLISH has not been received selecting/seizing a 868 particular appearance number. 870 Note that if the appearance group has appearance-unaware UAs 871 making calls, the Appearance Agent will still allocate appearance 872 numbers for INVITEs sent by those UAs. 874 An Appearance Agent receiving a PUBLISH with an appearance number 875 checks to make sure the publication is valid. An appearance number 876 can be assigned to only one dialog unless there is a 877 or element indicating that the dialog will be/has 878 been replaced or joined. A 400 (Bad Request) response is returned if 879 the chosen appearance number is invalid, and an immediate NOTIFY 880 should be sent to the UA containing full dialog event state. 882 An Appearance Agent receiving a PUBLISH without an appearance number 883 but with the 'shared' Event header field parameter present interprets 884 this as a request by the UA to not assign an appearance number. If 885 the Appearance Agent policy does not allow this, a 400 (Bad Request) 886 response is returned. If policy does allow this, a 200 OK response 887 is returned and no appearance number is allocated. An Appearance 888 Agent does not have to share this dialog information (i.e. send a 889 NOTIFY) with other UAs in the group as the information will not be 890 rendered by the other UAs. 892 The Appearance Agent allocates an apperance number to a dialog from 893 the time the appearance is requested via a PUBLISH or from the 894 receipt of an INVITE, to the time when the last dialog associated 895 with the appearance is terminated, including all dialogs which are 896 joined or replaced. During the early dialog state, the Appearance 897 Agent controls the rate of dialog state publication using the Expires 898 header field in 200 OK responses to PUBLISH requests. An interval of 899 3 minutes is RECOMMENDED. After the dialog associated with the 900 publication has been confirmed, the expiration of the publication 901 state has no effect on the appearance allocation. If the publication 902 contains no dialog state information, the Appearance Agent MUST 903 reserve the appearance number for the UA but can not assign the 904 appearance to any particular dialog of the UA. When the publication 905 state is updated with any dialog information, the appearance number 906 can then be assigned to the particular dialog. A UA which has been 907 allocated an appearance number using a PUBLISH MAY free up the 908 appearance number by removing the event state with a PUBLISH as 909 described in [RFC3903]. 911 If an INVITE is sent by a member of the group to the shared AOR (i.e. 912 they call their own AOR), the Appearance Agent MUST assign two 913 appearance numbers. The first appearance number will be the one 914 selected or assigned to the outgoing INVITE. The second appearance 915 number will be another one assigned by the Appearance Agent for the 916 INVITE as it is forked back to the members of the group. 918 The is to preserve a common behavior in legacy systems. 920 If an INVITE is sent by a member of the group using the shared AOR or 921 sent to the shared AOR and no appearance number is available, the 922 proxy MAY reject the INVITE with a 403 Forbidden response code. 924 Appearance numbers are only used for dialogs in which one or more UAs 925 associated with the group AOR is a participant. If an incoming 926 INVITE to the group AOR is forwarded to another AOR, the appearance 927 number is immediately freed up and can be assigned to another dialog. 929 6. XML Schema Definition 931 The 'appearance', 'joined-dialog', 'replaced-dialog', and 'exclusive' 932 elements are defined within a new XML namespace URI. This namespace 933 is "urn:ietf:params:xml:ns:sa-dialog-info". The schema for these 934 elements is: 936 937 943 945 946 948 950 952 953 955 957 958 960 962 964 965 967 968 969 970 972 973 974 975 976 978 7. Alert-Info Appearance Parameter Definition 980 This specification extends RFC 3261 [RFC3261] to add an 'appearance' 981 parameter to the Alert-Info header field, and to also allow proxies 982 to modify or delete the Alert-Info header field. 984 The changes to RFC 3261 ABNF are: 986 alert-param = LAQUOT absoluteURI RAQUOT *( SEMI 987 (generic-param / appearance-param) ) 988 appearance-param = "appearance" EQUAL 1*DIGIT 990 A proxy inserting an 'appearance' Alert-Info parameter follows normal 991 Alert-Info policies. To indicate the appearance number for this 992 dialog, the proxy adds the Alert-Info header field with the 993 'appearance' parameter to the INVITE. If an Alert-Info is already 994 present, the proxy adds the 'appearance' parameter to the Alert-Info 995 header field. If an appearance number parameter is already present 996 (associated with another AOR or by mistake), the value is rewritten 997 adding the new appearance number. There MUST NOT be more than one 998 appearance parameter in an Alert-Info header field. 1000 If no special ringtone is desired, a normal ringtone should be 1001 indicated using the urn:alert:service:normal in the Alert-Info, as 1002 per [I-D.ietf-salud-alert-info-urns]. The appearance number present 1003 in an Alert-Info header field SHOULD be rendered by the UA to the 1004 user, following the guidelines in Section 5.3. If the INVITE is 1005 forwarded to another AOR, the appearance parameter in the Alert-Info 1006 SHOULD be removed before forwarding outside the group. 1008 The determination as to what value to use in the appearance parameter 1009 can be done at the proxy that forks the incoming request to all the 1010 registered UAs. 1012 There are a variety of ways the proxy can use to determine what 1013 value it should use to populate this parameter. For example, the 1014 proxy could fetch this information by initiating a SUBSCRIBE 1015 request with Expires: 0 to the Appearance Agent for the AOR to 1016 fetch the list of lines that are in use. Alternatively, it could 1017 act like a UA that is a part of the appearance group and SUBSCRIBE 1018 to the State-Agent like any other UA. This would ensure that the 1019 active dialog information is available without having to poll on a 1020 need basis. It could keep track of the list of active calls for 1021 the appearance AOR based on how many unique INVITE requests it has 1022 forked to or received from the appearance AOR. Another approach 1023 would be for the Proxy to first send the incoming INVITE to the 1024 Appearance Agent which would redirect to the appearance group URI 1025 and escape the proper Alert-Info header field for the Proxy to 1026 recurse and distribute to the other UAs in the group. 1027 The Appearance Agent needs to know about all incoming requests to 1028 the AOR in order to seize the appearance number. One way in which 1029 this could be done is for the Appearance Agent to register against 1030 the AOR with a higher q value. This will result in the INVITE 1031 being sent to the Appearance Agent first, then being offered to 1032 the UAs in the group. 1034 8. User Interface Considerations 1036 The "appearance number" allocated to a call is an important concept 1037 that enables calls to be handled by multiple devices with 1038 heterogeneous user interfaces in a manner that still allows users to 1039 see a consistent model. Careful treatment of the appearance number 1040 is essential to meet the expectations of the users. Also, rendering 1041 the correct call/appearance state to users is also important. 1043 8.1. Appearance Number Rendering 1045 Since different UAs have different user interface capabilities, it is 1046 usual to find that some UAs have restrictions that others do not. 1047 Perfect interoperability across all UAs is clearly not possible, but 1048 by careful design, interoperability up to the limits of each UA can 1049 be achieved. 1051 The following guidelines suggest how the appearance number should be 1052 handled in three typical user interface implementations. 1054 8.1.1. Single Appearance UAs 1056 These devices are constrained by only having the capability of 1057 displaying status indications for a single appearance. The UA should 1058 still send messages annotated with appearance number "1". Any call 1059 indications for appearances other than for number "1" should be 1060 rejected with a 486 or 480 response. Note that this means that a 1061 single appearance UA cannot answer its own call to the shared AOR, 1062 since this call would use a second appearance number. 1064 8.1.2. Dual Appearance UAs 1066 These devices are essentially single appearance phones that implement 1067 call waiting. They have a very simple user interface that allows 1068 them to switch between two appearances (toggle or flash hook) and 1069 perhaps audible tones to indicate the status of the other appearance. 1070 Only appearance numbers "1" and "2" will be used by these UAs. 1072 8.1.3. Shared Appearance UAs with Fixed Appearance Number 1074 This UA is the typical 'business-class' hard-phone. A number of 1075 appearances are typically configured statically and labeled on 1076 buttons, and calls may be managed using these configured appearances. 1077 Any calls outside this range should be rejected, and not mapped to a 1078 free button. Users of these devices often seize specific appearance 1079 numbers for outgoing calls, and the UA will need to seize the 1080 appearance number and wait for confirmation from the Appearance Agent 1081 before proceeding with calls. 1083 8.1.4. Shared Appearance UAs with Variable Appearance Number 1085 This UA is typically a soft-phone or graphically rich user interface 1086 hard-phone. In these cases, even the idea of an appearance index may 1087 seem unnecessary. However, for these phones to be able to interwork 1088 successfully with other phone types, it is important that they still 1089 use the appearance index to govern the order of appearance of calls 1090 in progress. No specific guidance on presentation is given except 1091 that the order should be consistent. These devices can typically 1092 make calls without waiting for confirmation from the Appearance Agent 1093 on the appearance number. 1095 8.1.5. Example User Interface Issues 1097 The problems faced by each style of user interface are readily seen 1098 in this example: 1100 1. A call arrives at the shared appearance group, and is assigned an 1101 appearance number of "1". All UAs should be able to render to 1102 the user the arrival of this call. 1103 2. Another call arrives at the shared appearance group, and is 1104 assigned an appearance number of "2". The single appearance UA 1105 should not present this call to the user. Other user agents 1106 should have no problems presenting this call distinctly from the 1107 first call. 1108 3. The first call clears, releasing appearance number "1". The 1109 single appearance UA should now be indicating no calls since it 1110 is unable to manage calls other than on the first appearance. 1111 Both shared appearance UAs should clearly show that appearance 1112 number "1" is now free, but that there is still a call on 1113 appearance number "2". 1114 4. A third call arrives, and is assigned the appearance number of 1115 "1". All UAs should be able to render the arrival of this new 1116 call to the user. Multiple appearance UAs should continue to 1117 indicate the presence of the second call, and should also ensure 1118 that the presentation order is related to the appearance number 1119 and not the order of call arrival. 1121 8.2. Call State Rendering 1123 UAs that implement the shared appearance feature typically have a 1124 user interface that provides the state of other appearances in the 1125 group. As dialog state NOTIFYs from the Appearance Agent are 1126 processed, this information can be rendered. Even the simplest user 1127 interface typically has three states: idle, active, and hold. The 1128 idle state, usually indicated by lamp off, is indicated for an 1129 appearance when the appearance number is not associated with any 1130 dialogs, as reported by the Appearance Agent. The active state, 1131 usually indicated by a lamp on, is indicated by an appearance number 1132 being associated with at least one dialog, as reported by the 1133 Appearance Agent. The hold state, often indicated by a blinking 1134 lamp, means the call state from the perspective of the UA in the 1135 shared appearance group is hold. This can be determined by the 1136 presence of the "+sip.rendering=no" feature tag [RFC3840] with the 1137 local target URI. Note that the hold state of the remote target URI 1138 is not relevant to this display. For joined dialogs, the state is 1139 rendered as hold only if all local target URIs are indicated with the 1140 "+sip.rendering=no" feature tag. 1142 9. Interoperability with non-Shared Appearance UAs 1144 It is desirable to allow a basic UA that does not directly support 1145 shared appearance to be part of a shared appearance group. To 1146 support this the Proxy must collaborate with the Appearance Agent. 1147 This is not required in the basic shared appearance architecture, 1148 consequently shared appearance interoperability with non-shared 1149 appearance UAs will not be available in all shared appearance 1150 deployments. 1152 First, a UA which does not support dialog events or the shared 1153 appearance feature will be discussed. Then, a UA which does support 1154 dialog events but not the shared appearance feature will be 1155 discussed. 1157 9.1. Appearance Assignment 1159 A UA that has no knowledge of appearances must will only have 1160 appearance numbers for outgoing calls if assigned by the Appearance 1161 Agent. If the non-shared appearance UA does not support Join or 1162 Replaces, all dialogs SHOULD be marked "exclusive" to indicate that 1163 these options are not available. Marking these dialogs "exclusive" 1164 provides a better user experience and avoids extra SIP messaging 1165 failures. 1167 9.2. Appearance Release 1169 In all cases the Appearance Agent must be aware of dialog lifetime to 1170 release appearances back into the group. 1172 It is also desirable that any dialog state changes (such as hold, 1173 etc) be made available to other UAs in the group through the Dialog 1174 Event Package. If the Appearance Agent includes a proxy which 1175 Record-Routes for dialogs from the non-shared appearance aware UA, 1176 the Appearance Agent will know about the state of dialogs including 1177 hold, etc. This information could be determined from inspection of 1178 non-end-to-end-encrypted INVITE and re-INVITE messages and added to 1179 the dialog information conveyed to other UAs. 1181 9.3. UAs Supporting Dialog Events but Not Shared Appearance 1183 Interoperability with UAs which support dialog events but not the 1184 shared appearance feature is more straightforward. As before, all 1185 appearance number assignment must be done by the Appearance Agent. 1186 The Appearance Agent SHOULD still include appearance information in 1187 NOTIFYs - this UA will simply ignore this extra information. This 1188 type of UA will also ignore appearance number limitations and may 1189 attempt to Join or Replace dialogs marked exclusive. As a result, 1190 the Proxy or UAs need to reject such requests or the dialogs will get 1191 joined or taken. 1193 10. Provisioning Considerations 1195 UAs can automatically discover if this feature is active for an AOR 1196 by looking for the 'shared' Event header field parameter in a 1197 response to a dialog package SUBSCRIBE to the AOR, so no provisioning 1198 for this is needed. 1200 The registrar will need to be provisioned to accept either first or 1201 third party registrations for the shared AOR. First party 1202 registration means the To and From URIs in the REGISTER request are 1203 the shared AOR URI. Third party registration means the To URI is the 1204 shared AOR URI and the From URI is a different AOR, perhaps that of 1205 the individual user. Either the credentials of the shared AOR or the 1206 user MUST be accepted by the registrar and the Appearance Agent, 1207 depending on the authorization policy in place for the domain. 1209 If the Appearance Agent needs to subscribe to the dialog state of the 1210 UAs, then the Appearance Agent and the UAs need to be provisioned 1211 with credentials so the UAs can authenticate the Appearance Agent. 1213 In some cases, UAs in the shared appearance group might have a UI 1214 limitation on the number of appearances that can be rendered. 1215 Typically this will be hard phones with buttons/lamps instead of more 1216 flexible UIs. In this case, it can be useful for the Appearance 1217 Agent to know this maximum number. This can allow the Appearance 1218 Agent to apply policy when this limit is reached, e.g. deny a call. 1219 However, this mechanism does not provide any way to discover this by 1220 protocol means. 1222 11. Example Message Flows 1224 The next section shows call flow and message examples. The flows and 1225 descriptions are non-normative. Note that in these examples, all 1226 INVITEs sent by a UA in the group will be From the shared AOR 1227 (sip:HelpDesk@example.com in this case), and all INVITES sent to the 1228 group will have a Request-URI of the shared AOR. Any other requests 1229 would not apply to this feature and would be handled using normal SIP 1230 mechanisms. 1232 Note that the first twelve examples assume the Appearance Agent is 1233 aware of dialog state events. The example in Section 11.13 shows the 1234 case where this is not the case and as a result the Appearance Agent 1235 initiates a subscription to users of the shared AOR. Any of the 1236 other call flow examples could have shown this mode of operation as 1237 it is equally valid. 1239 11.1. Registration and Subscription 1241 Bob and Alice are in an appearance group identified by the shared 1242 appearance AOR sip:HelpDesk@example.com. Bob REGISTERs using contact 1243 sip:bob@ua2.example.com. Alice REGISTERs with contact 1244 sip:alice@ua1.example.com. 1246 User Agents for Alice and Bob subscribe to the dialog package for the 1247 appearance AOR and publish dialog state to the Appearance Agent. 1248 Message exchanges between the Registrar, Appearance Agent, Alice, and 1249 Bob are shown below. The call flow examples below do not show the 1250 authentication of subscriptions, publications, and notifications. It 1251 should be noted that for security purposes, all publications and 1252 subscriptions must be authorized before they are accepted. 1254 Also note that registrations and subscriptions must all be refreshed 1255 by Alice at intervals determined by the expiration intervals returned 1256 by the Registrar or Appearance Agent. 1258 Registrar Appearance Agent Alice Bob 1259 | | | | 1260 | | | | 1261 |<--------------------------- REGISTER F1<| | 1262 | | | | 1263 |>F2 200 OK ----------------------------->| | 1264 | | | | 1265 | |<----- SUBSCRIBE F3<| | 1266 | | | | 1267 | |>F4 200 OK -------->| | 1268 | | | | 1269 | |>F5 NOTIFY -------->| | 1270 | | | | 1271 | |<-------- 200 OK F6<| | 1272 | | | | 1273 |<-------------------------------------------- REGISTER F7<| 1274 | | | | 1275 |>F8 200 OK ---------------------------------------------->| 1276 | | | | 1277 | |<---------------------- SUBSCRIBE F9<| 1278 | | | | 1279 | |>F10 200 OK ------------------------>| 1280 | | | | 1281 | |>F11 NOTIFY ------------------------>| 1282 | | | | 1283 | |<------------------------ 200 OK F12<| 1284 | | | | 1286 Figure 1. 1288 F1-F2: Alice registers AOR with 1289 contact: 1291 F1 Alice ----> Registrar 1293 REGISTER sip:registrar.example.com SIP/2.0 1294 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09 1295 From: ;tag=CDF9A668-909E2BDD 1296 To: 1297 CSeq: 2 REGISTER 1298 Call-ID: d3281184-518783de-cc23d6bb 1299 Contact: 1300 Max-Forwards: 70 1301 Expires: 3600 1302 Content-Length: 0 1304 F2 Registrar ----> Alice 1306 SIP/2.0 200 OK 1307 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09 1308 CSeq: 2 REGISTER 1309 Call-ID: d3281184-518783de-cc23d6bb 1310 From: ;tag=CDF9A668-909E2BDD 1311 To: ;tag=1664573879820199 1312 Contact: ;expires=3600 1313 Content-Length: 0 1315 F3 to F6: Alice also subscribes to the events associated with the 1316 Appearance AOR. Appearance Agent notifies Alice of the status. 1318 F3 Alice ----> Appearance Agent 1320 SUBSCRIBE sip:HelpDesk@example.com SIP/2.0 1321 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A 1322 From: ;tag=925A3CAD-CEBB276E 1323 To: 1324 CSeq: 91 SUBSCRIBE 1325 Call-ID: ef4704d9-bb68aa0b-474c9d94 1326 Contact: 1327 Event: dialog;shared 1328 Accept: application/dialog-info+xml 1329 Max-Forwards: 70 1330 Expires: 3700 1331 Content-Length: 0 1333 F4 Appearance Agent ----> Alice 1335 SIP/2.0 200 OK 1336 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A 1337 CSeq: 91 SUBSCRIBE 1338 Call-ID: ef4704d9-bb68aa0b-474c9d94 1339 From: ;tag=925A3CAD-CEBB276E 1340 To: ;tag=1636248422222257 1341 Allow-Events: dialog 1342 Expires: 3700 1343 Contact: 1344 Content-Length: 0 1346 F5 Appearance Agent ----> Alice 1348 NOTIFY sip:alice@ua1.example.com SIP/2.0 1349 From: ;tag=1636248422222257 1350 To: ;tag=925A3CAD-CEBB276E 1351 Call-ID: ef4704d9-bb68aa0b-474c9d94 1352 CSeq: 232 NOTIFY 1353 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1846 1354 Max-Forwards: 70 1355 Content-Type: application/dialog-info+xml 1356 Event: dialog;shared 1357 Subscription-State: active;expires=3000 1358 Contact: 1359 Content-Length: ... 1361 1362 1366 1368 F6 Alice ----> Appearance Agent 1370 SIP/2.0 200 OK 1371 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1846 1372 From: ;tag=1636248422222257 1373 To: ;tag=925A3CAD-CEBB276E 1374 CSeq: 232 NOTIFY 1375 Call-ID: ef4704d9-bb68aa0b-474c9d94 1376 Contact: 1377 Content-Length: 0 1379 F7 Bob ----> Registrar 1381 REGISTER sip:registrar.example.com SIP/2.0 1382 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4b53b54d87B 1383 From: ;tag=34831131 1384 To: 1385 CSeq: 72 REGISTER 1386 Call-ID: 139490230230249348 1387 Contact: 1388 Max-Forwards: 70 1389 Expires: 3600 1390 Content-Length: 0 1392 F8 Registrar ----> Bob 1394 SIP/2.0 200 OK 1395 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4b53b54d87B 1396 From: ;tag=34831131 1397 To: ;tag=fkwlwqi1 1398 CSeq: 72 REGISTER 1399 Call-ID: 139490230230249348 1400 Contact: ;expires=3200 1401 Contact: ;expires=3600 1402 Content-Length: 0 1404 11.2. Appearance Selection for Incoming Call 1406 In the call flow below Bob and Alice are in an appearance group. 1407 Carol places a call to the appearance group AOR. The Appearance 1408 Agent sends NOTIFYs to Alice and Bob telling them what appearance the 1409 call is using. Both Alice and Bob's devices are alerted of the 1410 incoming call. Bob answers the call. 1412 Note that it is possible that both Alice and Bob answer the call and 1413 send 200 OK responses to Carol. It is up to Carol to resolve this 1414 situation. Typically, Carol will send ACKs to both 200 OKs but send 1415 a BYE to terminate one of the dialogs. As a result, either Alice or 1416 Bob will receive the BYE and publish that their dialog is over. 1417 However, if Carol answers both Alice and Bob and keeps both dialogs 1418 active, then the Appearance Agent will need to resolve the situation 1419 by moving either Alice or Bob's dialog to a different appearance. 1421 All NOTIFY messages in the call flow below carry dialog events and 1422 only dialog states are mentioned for simplicity. For brevity, the 1423 details of some messages are not shown below. Note that the order of 1424 F2 - F5 and F7 - F8 could be reversed. 1426 Forking Appearance 1427 Carol Proxy Agent Alice Bob 1428 | | | | | 1429 |>F1 INVITE >| | | | 1430 | |< - - - - - >| | | 1431 | | |>F2 NOTIFY ----------->| 1432 | | | | | 1433 | | |F4 NOTIFY ->| | 1436 | | | | | 1437 | | |<-200 OK F5-<| | 1438 |<- 100 F6 -<| | | | 1439 | |>F7 INVITE (appearance=1) ---------->| 1440 | | | | | 1441 | |>F8 INVITE (appearance=1) >| | 1442 | | | | | 1443 | |<-------------------- Ringing 180 F9<| 1444 |< 180 F10 -<| | | | 1445 | |<--------- 180 Ringing F11<| | 1446 |< 180 F12 -<| | | | 1447 | | | | | 1448 | |<------------------------ 200 OK F13<| 1449 |< 200 F14 -<| | | | 1450 | | | | | 1451 | |>F15 CANCEL -------------->| | 1452 | | | | | 1453 | |<-------------- 200 OK F16<| | 1454 | | | | | 1455 | |F18 ACK ----------------->| | 1458 |>F19 ACK -->| | | | 1459 | |>F20 ACK --------------------------->| 1460 | | | | | 1461 |<=============Both way RTP established===========>| 1462 | | | | | 1463 | |< - - - - - >| | | 1464 | | | | | 1465 | | |>F21 NOTIFY >| | 1466 | | | | | 1467 | | |<- 200 F22 -<| | 1468 | | | | | 1469 | | |>F23 NOTIFY ---------->| 1470 | | | | | 1471 | | | Alice 1478 NOTIFY sip:alice@ua1.example.com SIP/2.0 1479 From: ;tag=151702541050937 1480 To: ;tag=18433323-C3D237CE 1481 Call-ID: 1e361d2f-a9f51109-bafe31d4 1482 CSeq: 12 NOTIFY 1483 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1403 1484 Max-Forwards: 70 1485 Content-Type: application/dialog-info+xml 1486 Event: dialog;shared 1487 Subscription-State: active;expires=2800 1488 Contact: 1489 Content-Length: ... 1491 1492 1497 1501 1 1502 trying 1503 1504 sip:carol@ua.example.com 1505 1506 1507 1509 F7 Proxy ----> Bob 1511 INVITE sip:bob@ua2.example.com SIP/2.0 1512 Via: SIP/2.0/UDP ua3.example.com;branch=z9hG4bK4324ea 1513 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK38432ji 1514 From: ;tag=44BAD75D-E3128D42 1515 To: 1516 CSeq: 106 INVITE 1517 Call-ID: 14-1541707345 1518 Contact: 1519 Max-Forwards: 69 1520 Alert-Info: ;appearance=1 1521 Content-Type: application/sdp 1522 Content-Length: ... 1524 v=0 1525 o=- 1102980499 1102980499 IN IP4 ua3.example.com 1526 s= 1527 c=IN IP4 ua3.example.com 1528 t=0 0 1529 m=audio 2238 RTP/AVP 0 8 101 1530 a=rtpmap:0 PCMU/8000 1531 a=rtpmap:8 PCMA/8000 1532 a=rtpmap:101 telephone-event/8000 1534 F21 Appearance Agent ----> Alice 1536 NOTIFY sip:alice@ua1.example.com SIP/2.0 1537 From: ;tag=151702541050937 1538 To: ;tag=18433323-C3D237CE 1539 Call-ID: 1e361d2f-a9f51109-bafe31d4 1540 CSeq: 13 NOTIFY 1541 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK4164F03j 1542 Max-Forwards: 70 1543 Content-Type: application/dialog-info+xml 1544 Event: dialog;shared 1545 Subscription-State: active;expires=2500 1546 Contact: 1547 Content-Length: ... 1549 1550 1555 1560 1 1561 confirmed 1562 1563 sip:bob@ua2.example.com 1564 1565 1566 sip:carol@ua.example.com 1567 1568 1569 1571 11.3. Outgoing Call without Appearance Seizure 1573 In this scenario, Bob's UA places a call without first selecting/ 1574 seizing an appearance number. After Bob sends the INVITE, the 1575 appearance assigns an appearance number for it and notifies both 1576 Alice and Bob. 1578 Carol Proxy Alice Appearance Agent Bob 1579 | | | | | 1580 | | | | | 1581 | |<------------------------------------- INVITE F1<| 1582 | | | | | 1583 | |>F2 100 Trying --------------------------------->| 1584 |<-- INVITE F3<| | | | 1585 | |< - - - - - - - - - - - - - ->| | 1586 | | | | | 1587 | | |<-- NOTIFY F4<| | 1588 | | | | | 1589 | | |>F5 200 OK -->| | 1590 | | | |------- NOTIFY F6>| 1591 | | | | | 1592 | | | |F8 180 ---->| | | | 1594 | |>F9 180 Ringing -------------------------------->| 1595 | | | | | 1596 | |< - - - - - - - - - - - - - ->| | 1597 | | | | | 1598 | | |<- NOTIFY F10<| | 1599 | | | | | 1600 | | |>F11 200 OK ->| | 1601 | | | |------ NOTIFY F12>| 1602 | | | | | 1603 | | | |F14 200 OK ->| | | | 1605 | |>F15 200 OK ------------------------------------>| 1606 | | | | | 1607 | |<--------------------------------------- ACK F16<| 1608 |<---- ACK F17<| | | | 1609 | | | | | 1610 |<================= Both way RTP established ===================>| 1611 | | | | | 1612 | |< - - - - - - - - - - - - - ->| | 1613 | | | | | 1614 | | |<- NOTIFY F18<| | 1615 | | | | | 1616 | | |>F19 200 OK ->| | 1617 | | | |------ NOTIFY F20>| 1618 | | | | | 1619 | | | | Proxy 1626 INVITE sip:carol@example.com SIP/2.0 1627 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK98c87c52123A08BF 1628 From: ;tag=15A3DE7C-9283203B 1629 To: 1630 CSeq: 1 INVITE 1631 Call-ID: f3b3cbd0-a2c5775e-5df9f8d5 1632 Contact: 1633 Max-Forwards: 70 1634 Content-Type: application/sdp 1635 Content-Length: 223 1637 v=0 1638 o=- 1102980499 1102980499 IN IP4 ua2.example.com 1639 s=IP SIP UA 1640 c=IN IP4 ua2.example.com 1641 t=0 0 1642 a=sendrecv 1643 m=audio 2236 RTP/AVP 0 8 101 1644 a=rtpmap:0 PCMU/8000 1645 a=rtpmap:8 PCMA/8000 1646 a=rtpmap:101 telephone-event/8000 1648 F4 Appearance Agent ----> Alice 1650 NOTIFY sip:alice@ua1.example.com SIP/2.0 1651 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK81d84f62 1652 From: ;tag=1636248422222257 1653 To: ;tag=925A3CAD-CEBB276E 1654 Call-ID: ef4704d9-bb68aa0b-474c9d94 1655 CSeq: 233 NOTIFY 1656 Max-Forwards: 70 1657 Content-Type: application/dialog-info+xml 1658 Event: dialog;shared 1659 Subscription-State: active;expires=2200 1660 Contact: 1661 Content-Length: ... 1663 1664 1669 1672 1 1673 false 1674 trying 1675 1676 1677 1678 1679 1680 1682 F6 Appearance Agent ----> Bob 1684 NOTIFY sip:bob@ua1.example.com SIP/2.0 1685 From: ;tag=497585728578386 1686 To: ;tag=633618CF-B9C2EDA4 1687 Call-ID: a7d559db-d6d7dcad-311c9e3a 1688 CSeq: 7 NOTIFY 1689 Via: SIP/2.0/UDP appearanceagent.example.com 1690 ;branch=z9hG4bK1711759878512309 1691 Max-Forwards: 70 1692 Content-Type: application/dialog-info+xml 1693 Event: dialog;shared 1694 Subscription-State: active;expires=2000 1695 Contact: 1696 Content-Length: ... 1698 1699 1704 1707 1 1708 false 1709 trying 1710 1711 1712 1713 1714 1715 1717 11.4. Outgoing Call with Appearance Seizure 1719 In this scenario, Bob's UA sends out a dialog event PUBLISH with 1720 state (trying) selecting/seizing an appearance number before sending 1721 the INVITE. After receiving the 200 OK from the Appearance Agent 1722 confirming the appearance number, Bob's UA sends the INVITE to Carol 1723 and establishes a session. For brevity, details of some of the 1724 messages are not included in the message flows. Bob's UA puts as 1725 much of the dialog information from F7 as can be determined in 1726 advance. In this case, the minimum of the Contact URI is included 1727 which allows the Appearance Agent to correlate the INVITE with the 1728 PUBLISH. 1730 Carol Proxy Alice Appearance Agent Bob 1731 | | | | | 1732 | | | |<----- PUBLISH F1<| 1733 | | | | | 1734 | | | |>F2 200 OK ------>| 1735 | | | | | 1736 | | |<-- NOTIFY F3<| | 1737 | | | | | 1738 | | |>F4 200 OK -->| | 1739 | | | |------- NOTIFY F5>| 1740 | | | | | 1741 | | | |F8 100 Trying --------------------------------->| 1746 |<-- INVITE F9<| | | | 1747 | | | |<---- PUBLISH F10<| 1748 | | | | | 1749 | | | |>F11 200 OK ----->| 1750 | | | | | 1751 |>F12 180 --->| | | | 1752 | |>F13 180 Ringing ------------------------------->| 1753 | | | | | 1754 | |< - - - - - - - - - - - - - ->| | 1755 | | | | | 1756 | | |<- NOTIFY F14<| | 1757 | | | | | 1758 | | |>F15 200 OK ->| | 1759 | | | |------ NOTIFY F16>| 1760 | | | | | 1761 | | | |F18 200 OK ->| | | | 1763 | |>F19 200 OK ------------------------------------>| 1764 | | | | | 1765 | |<--------------------------------------- ACK F20<| 1766 |<---- ACK F21<| | | | 1767 | | | | | 1768 |<================= Both way RTP established ===================>| 1769 | | | | | 1770 | |< - - - - - - - - - - - - - ->| | 1771 | | | | | 1772 | | |<- NOTIFY F22<| | 1773 | | | | | 1774 | | |>F23 200 OK ->| | 1775 | | | |------ NOTIFY F24>| 1776 | | | | | 1777 | | | | Appearance Agent 1790 PUBLISH sip:HelpDesk@example.com SIP/2.0 1791 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 1792 From: ;tag=44150CC6-A7B7919D 1793 To: 1794 CSeq: 7 PUBLISH 1795 Call-ID: 44fwF144-F12893K38424 1796 Contact: 1797 Event: dialog;shared 1798 Max-Forwards: 70 1799 Content-Type: application/dialog-info+xml 1800 Content-Length: ... 1802 1803 1808 1809 1 1810 false 1811 trying 1812 1813 1814 1815 1816 1817 1818 F2 Appearance Agent ----> Bob 1820 SIP/2.0 200 OK 1821 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 1822 From: ;tag=44150CC6-A7B7919D 1823 To: 1824 CSeq: 7 PUBLISH 1825 Call-ID: 44fwF144-F12893K38424 1826 Contact: 1827 Event: dialog;shared 1828 SIP-Etag: 482943245 1829 Allow-Events: dialog 1830 Expires: 60 1831 Content-Length: 0 1833 F7 Bob ---> Proxy 1835 INVITE sip:carol@example.com SIP/2.0 1836 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK342122 1837 Max-Forwards: 70 1838 From: ;tag=15A3DE7C-9283203B 1839 To: 1840 Call-ID: f3b3cbd0-a2c5775e-5df9f8d5 1841 CSeq: 31 INVITE 1842 Contact: 1843 Content-Type: application/sdp 1844 Content-Length: ... 1846 (SDP Not Shown) 1848 F10 Bob ----> Appearance Agent 1850 PUBLISH sip:HelpDesk@example.com SIP/2.0 1851 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK6d644638E7 1852 From: ;tag=0CCf6-A7FdsB79D 1853 To: 1854 CSeq: 437 PUBLISH 1855 Call-ID: fwF14d4-F1FFF2F2893K38424 1856 Contact: 1857 Event: dialog;shared 1858 Max-Forwards: 70 1859 Content-Type: application/dialog-info+xml 1860 Content-Length: ... 1862 1863 1868 1872 1 1873 false 1874 trying 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1886 11.5. Outgoing Call without using an Appearance Number 1888 In this scenario, Bob's UA sends out a dialog event PUBLISH with 1889 state (trying) indicating that he does not want to utilize an 1890 appearance number for this dialog. The PUBLISH does not have an 1891 appearance element but does have the 'shared' Event header field 1892 parameter. As a result, the Appearance Agent knows the UA does not 1893 wish to use an appearance number for this call. If the Appearance 1894 Agent does not wish to allow this, it would reject the PUBLISH with a 1895 400 (Bad Request) response and the UA would know to re-PUBLISH 1896 selecting/seizing an appearance number. 1898 Carol Proxy Alice Appearance Agent Bob 1899 | | | | | 1900 | | | |<----- PUBLISH F1<| 1901 | | | | | 1902 | | | |>F2 200 OK ------>| 1903 | | | | | 1904 | | |<-- NOTIFY F3<| | 1905 | | | | | 1906 | | |>F4 200 OK -->| | 1907 | | | |------- NOTIFY F5>| 1908 | | | | | 1909 | | | |F8 100 Trying --------------------------------->| 1914 |<-- INVITE F9<| | | | 1915 | | | |<---- PUBLISH F10<| 1916 | | | | | 1917 | | | |>F11 200 OK ----->| 1918 | | | | | 1919 |>F12 180 --->| | | | 1920 | |>F13 180 Ringing ------------------------------->| 1921 | | | | | 1922 | |< - - - - - - - - - - - - - ->| | 1923 | | | | | 1924 | | |<- NOTIFY F14<| | 1925 | | | | | 1926 | | |>F15 200 OK ->| | 1927 | | | |------ NOTIFY F16>| 1928 | | | | | 1929 | | | |F18 200 OK ->| | | | 1931 | |>F19 200 OK ------------------------------------>| 1932 | | | | | 1933 | |<--------------------------------------- ACK F20<| 1934 |<---- ACK F21<| | | | 1935 | | | | | 1936 |<================= Both way RTP established ===================>| 1937 | | | | | 1938 | |< - - - - - - - - - - - - - ->| | 1939 | | | | | 1940 | | |<- NOTIFY F22<| | 1941 | | | | | 1942 | | |>F23 200 OK ->| | 1943 | | | |------ NOTIFY F24>| 1944 | | | | | 1945 | | | | Appearance Agent 1952 PUBLISH sip:appearanceagent.example.com SIP/2.0 1953 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 1954 From: ;tag=4415df82k39sf 1955 To: 1956 CSeq: 7 PUBLISH 1957 Call-ID: 44fwF144-F12893K38424 1958 Contact: 1959 Event: dialog;shared 1960 Max-Forwards: 70 1961 Content-Type: application/dialog-info+xml 1962 Content-Length: ... 1964 1965 1970 1971 false 1972 trying 1973 1974 1975 1976 1977 1978 1980 Note that F7 would be the same as the previous example. 1982 11.6. Appearance Release 1984 Bob and Carol are in a dialog, created, for example as in 1985 Section 11.3. Carol sends a BYE to Bob to terminate the dialog and 1986 the Appearance Agent de-allocates the appearance number used, sending 1987 notifications out to the UAs in the shared group. 1989 Carol Proxy Alice Appearance Agent Bob 1990 | | | | | 1991 | | | | | 1992 |<================= Both way RTP established ===================>| 1993 | | | | | 1994 |>F22 BYE ---->| | | | 1995 | |>F23 BYE --------------------------------------->| 1996 | | | | | 1997 | |<------------------------------------ 200 OK F24<| 1998 |<--200 OK F25<| | | | 1999 | |< - - - - - - - - - - - - - ->| | 2000 | | | | | 2001 | | |<- NOTIFY F26<| | 2002 | | | | | 2003 | | |>F27 200 OK ->| | 2004 | | | |------ NOTIFY F28>| 2005 | | | | | 2006 | | | | Bob 2011 NOTIFY sip:bob@ua1.example.com SIP/2.0 2012 From: ;tag=497585728578386 2013 To: 2014 Call-ID: a7d559db-d6d7dcad-311c9e3a 2015 CSeq: 7 NOTIFY 2016 Via: SIP/2.0/UDP appearanceagent.example.com 2017 ;branch=z9hG4bK759878512309 2018 Max-Forwards: 70 2019 Content-Type: application/dialog-info+xml 2020 Event: dialog;shared 2021 Subscription-State: active;expires=1800 2022 Contact: 2023 Content-Length: ... 2025 2026 2031 2036 1 2037 false 2038 terminated 2039 2040 2041 2042 2043 2044 2046 11.7. Appearance Pickup 2048 In this scenario, Bob has an established dialog with Carol created 2049 using the call flows of Figure 1 or Figure 2. Bob then places Carol 2050 on hold. Alice receives a notification of this and renders this on 2051 Alice's UI. Alice subsequently picks up the held call and has a 2052 established session with Carol. Finally, Carol hangs up. Alice must 2053 PUBLISH F32 to indicate that the INVITE F38 will be an attempt to 2054 pickup the dialog between Carol and Bob, and hence may use the same 2055 appearance number. 2057 Carol Proxy Alice Appearance Agent Bob 2058 | | | | | 2059 |<================= Both way RTP established ===================>| 2060 | | | | | 2061 | |<------------------------------(hold) INVITE F22<| 2062 |<- INVITE F23<| | | | 2063 | | | | | 2064 |>F24 200 OK ->| | | | 2065 | |>F25 200 OK ------------------------------------>| 2066 | | | | | 2067 | |<--------------------------------------- ACK F26<| 2068 |<---- ACK F27<| | | | 2069 | |< - - - - - - - - - - - - - ->| | 2070 | | | | | 2071 | | |<- NOTIFY F28<| | 2072 | | | | | 2073 | | |>F29 200 OK ->| | 2074 | | | |>F30 NOTIFY ----->| 2075 | | | | | 2076 | | | |<----- 200 OK F31<| 2077 | | | | | 2078 | | Alice decides to pick up the call | 2079 | | | | | 2080 | | |>F32 PUBLISH->| | 2081 | | | | | 2082 | | |<- 200 OK F33<| | 2083 | | | | | 2084 | | |<- NOTIFY F34<| | 2085 | | | | | 2086 | | |>F35 200 OK ->| | 2087 | | | |>F36 NOTIFY ----->| 2088 | | | | | 2089 | | | |<----- 200 OK F37<| 2090 | |<-- INVITE F38<| | | 2091 |<- INVITE F39<|(w/ Replaces) | | | 2092 |( w/ Replaces)| | | | 2093 |>F40 200 OK ->| | | | 2094 | |>F41 200 OK -->| | | 2095 | | | | | 2096 | |< - - - - - - - - - - - - - ->| | 2097 | | | | | 2098 | | | |>F42 NOTIFY ----->| 2099 | | | | | 2100 | | | |<----- 200 OK F43<| 2101 | | |<- NOTIFY F44<| | 2102 | | | | | 2103 | | |>F45 200 OK ->| | 2104 | | | | | 2105 | |<----- ACK F46<| | | 2106 |<---- ACK F47<| | | | 2107 | | | | | 2108 |<= Both way RTP established =>| | | 2109 | | | | | 2110 |>F48 BYE ---->| | | | 2111 | |>F49 BYE --------------------------------------->| 2112 | | | | | 2113 | |<------------------------------------ OK 200 F50<| 2114 |<- 200 OK F51<| | | | 2115 | | | | | 2116 | |< - - - - - - - - - - - - - ->| | 2117 | | | | | 2118 | | |<- NOTIFY F52<| | 2119 | | | | | 2120 | | |>F53 200 OK ->| | 2121 | | | | | 2122 | | | |>F54 NOTIFY ----->| 2123 | | | | | 2124 | | | |<----- 200 OK F55<| 2126 Figure 7. 2128 F28 Appearance ----> Alice 2130 NOTIFY sip:alice@ua1.example.com SIP/2.0 2131 From: ;tag=151702541050937 2132 To: ;tag=18433323-C3D237CE 2133 Call-ID: 1e361d2f-a9f51109-bafe31d4 2134 CSeq: 12 NOTIFY 2135 Via: SIP/2.0/UDP appearanceagent.example.com 2136 ;branch=z9hG4bK1403 2137 Max-Forwards: 70 2138 Content-Type: application/dialog-info+xml 2139 Event: dialog;shared 2140 Subscription-State: active;expires=1800 2141 Contact: 2142 Content-Length: ... 2144 2145 2150 2155 1 2156 false 2157 active 2158 2159 2160 2161 2162 2163 2164 sip:carol@example.com 2165 2166 2167 2168 2170 F32 Alice ----> Appearance Agent 2172 PUBLISH sip:HelpDesk@example.com SIP/2.0 2173 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A 2174 From: ;tag=44150CC6-A7B7919D 2175 To: ;tag=428765950880801 2176 CSeq: 11 PUBLISH 2177 Call-ID: 87837Fkw87asfds 2178 Contact: 2179 Event: dialog;shared 2180 Max-Forwards: 70 2181 Content-Type: application/dialog-info+xml 2182 Content-Length: ... 2184 2185 2190 2193 1 2194 false 2195 2199 trying 2200 2201 2202 2203 2204 2205 2206 2207 2208 2209 2211 F38 Alice ----> Proxy 2213 INVITE sip:carol@example.com SIP/2.0 2214 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK4ea695b5B376A60C 2215 From: ;tag=8C4183CB-BCEAB710 2216 To: 2217 CSeq: 1 INVITE 2218 Call-ID: 3d57cd17-47deb849-dca8b6c6 2219 Contact: 2220 2221 Replaces: f3b3cbd0-a2c5775e-5df9f8d5;to-tag=65a98f7c 2222 -1dd2-11b2-88c6-b03162323164+65a98f7c;from-tag=15A3DE7C-9283203B 2223 2224 Max-Forwards: 70 2225 Content-Type: application/sdp 2226 Content-Length: 223 2228 v=0 2229 o=- 1102980497 1102980497 IN IP4 ua1.example.com 2230 s=IP SIP UA 2231 c=IN IP4 ua1.example.com 2232 t=0 0 2233 a=sendrecv 2234 m=audio 2238 RTP/AVP 0 8 101 2235 a=rtpmap:0 PCMU/8000 2236 a=rtpmap:8 PCMA/8000 2237 a=rtpmap:101 telephone-event/8000 2239 11.8. Calls between UAs within the Group 2241 In this scenario, Bob calls Alice who is also in the Appearance 2242 group. Only one appearance number is used for this dialog. This 2243 example also shows the use of the 'exclusive' tag to indicate that 2244 other UAs in the group can not join or take this dialog. 2246 Carol Proxy Alice Appearance Agent Bob 2247 | | | | | 2248 | |<-------------------- INVITE (to Alice's UA) F1<| 2249 | | | | | 2250 | |< - - - - - - - - - - - - - ->| | 2251 | | | | | 2252 | | | | | 2253 | | |<-- NOTIFY F2<| | 2254 | | | | | 2255 | | |>F3 200 OK -->| | 2256 | | | |>F4 NOTIFY ------>| 2257 | | | | | 2258 | | | |<------ 200 OK F5<| 2259 | |>F6 INVITE --->| | | 2260 | | (appearance=1)| | | 2261 | | | | | 2262 | |<------ 180 F7<| | | 2263 | | | | | 2264 | |>F8 180 --------------------------------------->| 2265 | | | | | 2266 | |< - - - - - - - - - - - - - ->| | 2267 | | | | | 2268 | | |<-- NOTIFY F9<| | 2269 | | | | | 2270 | | |>F10 200 OK ->| | 2271 | | | |>F11 NOTIFY ----->| 2272 | | | | | 2273 | | | |<----- 200 OK F12<| 2274 | |<-- 200 OK F13<| | | 2275 | | | | | 2276 | |>F14 200 OK ------------------------------------>| 2277 | | | | | 2278 | |<--------------------------------------- ACK F15<| 2279 | | | | | 2280 | |>F16 ACK ----->| | | 2281 | | | | | 2282 | | |<======= RTP established =======>| 2283 | | | | | 2284 | |< - - - - - - - - - - - - - ->| | 2285 | | | | | 2286 | | |<- NOTIFY F17<| | 2287 | | | | | 2288 | | |>F18 200 OK ->| | 2289 | | | |>F19 NOTIFY ----->| 2290 | | | | | 2291 | | | |<----- 200 OK F24<| 2292 | | | | | 2294 Figure 8. 2296 F19 Appearance Agent ----> Bob 2298 NOTIFY sip:bob@ua1.example.com SIP/2.0 2299 From: ;tag=497585728578386 2300 To: ;tag=633618CF-B9C2EDA4 2301 Call-ID: a7d559db-d6d7dcad-311c9e3a 2302 CSeq: 7 NOTIFY 2303 Via: SIP/2.0/UDP appearanceagent.example.com 2304 ;branch=z9hG4bK1711759878512309 2305 Max-Forwards: 70 2306 Content-Type: application/dialog-info+xml 2307 Event: dialog;shared 2308 Subscription-State: active;expires=1500 2309 Contact: 2310 Content-Length: ... 2312 2313 2318 2323 true 2324 1 2325 confirmed 2326 2327 2328 2329 2330 2331 sip:HelpDesk@example.com 2332 2333 2335 2337 2342 true 2343 1 2344 confirmed 2345 2346 2347 2348 2349 sip:HelpDesk@example.com 2350 2351 2352 2354 2356 11.9. Consultation Hold with Appearances 2358 In this scenario, Bob has a call with Carol. Bob makes a 2359 consultation call to Alice by putting Carol on hold and calling 2360 Alice. Bob's UA chooses not to have an appearance number for the 2361 call to Alice since it is treating it as part of the call to Carol. 2362 He indicates this in the PUBLISH F32 which contains the 'shared' 2363 Event header field parameter but no element. The 2364 PUBLISH is sent before the INVITE to Alice to ensure no appearance 2365 number is assigned by the Appearance Agent. Finally, Bob hangs up 2366 with Alice and resumes the call with Carol. Dialog notifications of 2367 the consultation call are not shown, as they are not used. 2369 Note that if Carol hangs up while Bob is consulting with Alice, Bob 2370 can decide if he wants to reuse the appearance number used with Carol 2371 for the call with Alice. If not, Bob publishes the termination of 2372 the dialog with Carol and the Appearance Agent will re-allocate the 2373 appearance. If he wants to keep the appearance, Bob will publish the 2374 termination of the dialog with Carol and also publish the appearance 2375 with the dialog with Alice. This will result in Bob keeping the 2376 appearance number until he reports the dialog with Alice terminated. 2378 Note that the call flow would be similar if Bob called a music on 2379 hold server instead of Alice to implement a music on hold service as 2380 described in [I-D.worley-service-example]. 2382 Carol Proxy Alice Appearance Agent Bob 2383 | | | | | 2384 |<================= Both way RTP established ===================>| 2385 | | | | | 2386 | |<------------------------------(hold) INVITE F22<| 2387 |<- INVITE F23<| | | | 2388 | | | | | 2389 |>F24 200 OK ->| | | | 2390 | |>F25 200 OK ------------------------------------>| 2391 | | | | | 2392 | |<--------------------------------------- ACK F26<| 2393 |<---- ACK F27<| | | | 2394 | |< - - - - - - - - - - - - - ->| | 2395 | | | | | 2396 | | |<- NOTIFY F28<| | 2397 | | | | | 2398 | | |>F29 200 OK ->| | 2399 | | | |>F30 NOTIFY ----->| 2400 | | | | | 2401 | | | |<----- 200 OK F31<| 2402 | | | | | 2403 | | Bob makes a consultation call to Alice | 2404 | | | | | 2405 | | | |<---- PUBLISH F32<| 2406 | | | | | 2407 | | | |>F33 200 OK ----->| 2408 | | | | | 2409 | |<------------------------------------ INVITE F34<| 2410 | | | | | 2411 | |>F35 INVITE -->| | | 2412 | | | | | 2413 | |<-- 200 OK F36<| | | 2414 | | | | | 2415 | |>F37 200 OK ------------------------------------>| 2416 | | | | | 2417 | |<--------------------------------------- ACK F38<| 2418 | | | | | 2419 | |>F39 ACK ----->| | | 2420 | | | | | 2421 | | |<======= RTP established =======>| 2422 | | | | | 2423 | | Bob hangs up with Alice | 2424 | | | | | 2425 | |<--------------------------------------- BYE F40<| 2426 | | | | | 2427 | |>F41 BYE ----->| | | 2428 | | | | | 2429 | |<-- 200 OK F42<| | | 2430 | | | | | 2431 | |>F43 200 OK ------------------------------------>| 2432 | | | | | 2433 | |<----------------------------(unhold) INVITE F44<| 2434 |<- INVITE F45<| | | | 2435 | | | | | 2436 |>F46 200 OK ->| | | | 2437 | |>F47 200 OK ------------------------------------>| 2438 | | | | | 2439 | |<--------------------------------------- ACK F48<| 2440 |<---- ACK F49<| | | | 2441 | |< - - - - - - - - - - - - - ->| | 2442 | | | | | 2443 | | |<- NOTIFY F50<| | 2444 | | | | | 2445 | | |>F51 200 OK ->| | 2446 | | | |>F52 NOTIFY ----->| 2447 | | | | | 2448 | | | |<----- 200 OK F53<| 2449 | | | | | 2450 |<================= Both way RTP established ===================>| 2451 | | | | | 2453 Figure 9. 2455 F32 Bob ----> Appearance Agent 2457 PUBLISH sip:HelpDesk@example.com SIP/2.0 2458 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A 2459 From: ;tag=44150CC6-A7B7919D 2460 To: ;tag=428765950880801 2461 CSeq: 11 PUBLISH 2462 Call-ID: 44fwF144-F12893K38424 2463 Contact: 2464 Event: dialog;shared 2465 Max-Forwards: 70 2466 Content-Type: application/dialog-info+xml 2467 Content-Length: ... 2469 2470 2475 2480 true 2481 trying 2482 2483 2484 2485 2486 2487 sip:HelpDesk@example.com 2488 2489 2490 2491 2493 11.10. Joining or Bridging an Appearance 2495 In this call flow, a call answered by Bob is joined by Alice or 2496 "bridged". The Join header field is used by Alice to request this 2497 bridging. If Bob did not support media mixing, Bob could obtain 2498 conferencing resources as described in [RFC4579]. 2500 Carol Forking Proxy Appearance Agent Alice Bob 2501 | | | | | 2502 |<=============Both way RTP established===========>| 2503 | | | | | 2504 | | |< PUBLISH F22| | 2505 | | | | | 2506 | | |>F23 200 OK >| | 2507 | | | | | 2508 | |<---- INVITE (w/ Join) F24<| | 2509 | | | | | 2510 | |>F25 INVITE (w/Join)---------------->| 2511 | | | | | 2512 | |<---- OK 200 Contact:Bob;isfocus F26<| 2513 | | | | | 2514 | |< - - - - - >| | | 2515 | | | | | 2516 | | |>F27 NOTIFY >| | 2517 | | | | | 2518 | | |< 200 OK F28<| | 2519 | | | | | 2520 | | |>F29 NOTIFY ---------->| 2521 | | | | | 2522 | | |F31 200 OK Contact:B----->| | 2525 | | | | | 2526 | |<----------------- ACK F32<| | 2527 | | | | | 2528 | |>ACK F33---------------------------->| 2529 | | | | | 2530 | |<-----INVITE Contact:Bob;isfocus F34<| 2531 |<-INVITE F35| | | | 2532 | | | | | 2533 |>F26 200 -->| | | | 2534 | |>F37 200 OK ------------------------>| 2535 | | | | | 2536 | |<--------------------------- ACK F38<| 2537 |<--- ACK F39| | | | 2538 | | | |<==RTP==>| 2539 |<=============Both way RTP established===========>| 2540 | | | | | 2541 | |< - - - - - >| | | 2542 | | | | | 2543 | | |>F40 NOTIFY >| | 2544 | | | | | 2545 | | |< 200 OK F41<| | 2546 | | | | | 2547 | | |>F42 NOTIFY ---------->| 2548 | | | | | 2549 | | | Appearance Agent 2556 PUBLISH sip:HelpDesk@example.com SIP/2.0 2557 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A 2558 From: ;tag=44150CC6-A7B7919D 2559 To: ;tag=428765950880801 2560 CSeq: 11 PUBLISH 2561 Call-ID: 87837Fkw87asfds 2562 Contact: 2563 Event: dialog;shared 2564 Max-Forwards: 70 2565 Content-Type: application/dialog-info+xml 2566 Content-Length: ... 2568 2569 2574 2577 1 2578 false 2579 2583 trying 2584 2585 2586 2587 2588 2589 2590 2591 2592 2594 F24 Alice ----> Proxy 2596 INVITE sip:bob@ua.example.com SIP/2.0 2597 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKcc9d727c2C29BE31 2598 From: ;tag=605AD957-1F6305C2 2599 To: 2600 CSeq: 2 INVITE 2601 Call-ID: dc95da63-60db1abd-d5a74b48 2602 Contact: 2603 2604 Join: 14-1541707345;to-tag=d3b06488-1dd1-11b2-88c5 2605 -b03162323164+d3e48f4c;from-tag=44BAD75D-E3128D42 2606 2607 Max-Forwards: 70 2608 Content-Type: application/sdp 2609 Content-Length: 223 2611 v=0 2612 o=- 1103061265 1103061265 IN IP4 ua1.example.com 2613 s=IP SIP UA 2614 c=IN IP4 ua1.example.com 2615 t=0 0 2616 a=sendrecv 2617 m=audio 2236 RTP/AVP 0 8 101 2618 a=rtpmap:0 PCMU/8000 2619 a=rtpmap:8 PCMA/8000 2620 a=rtpmap:101 telephone-event/8000 2622 11.11. Appearance Allocation - Loss of Appearance 2624 Bob reserves an appearance with a PUBLISH, sends an INVITE to Carol, 2625 then becomes unreachable. When he fails to refresh his publication 2626 to the appearance agent, the Appearance Agent declares the dialog 2627 terminated and frees up the appearance using NOTIFYs F14 and F16. 2628 After retransmitting the NOTIFY to Bob (in not shown messages F17, 2629 F18, etc.), the subscription is terminated. 2631 Carol Proxy Alice Appearance Agent Bob 2632 | | | | | 2633 | | | |<----- PUBLISH F1<| 2634 | | | | | 2635 | | | |>F2 200 OK ------>| 2636 | | | | | 2637 | | |<-- NOTIFY F3<| | 2638 | | | | | 2639 | | |>F4 200 OK -->| | 2640 | | | |------- NOTIFY F5>| 2641 | | | | | 2642 | | | |F8 100 Trying --------------------------------->| 2647 |<-- INVITE F9<| | | | 2648 | | | |<---- PUBLISH F10<| 2649 | | | | | 2650 | | | |>F11 200 OK ----->| 2651 | | | | | 2652 |>F12 180 --->| | | | 2653 | |>F13 180 Ringing ------------------------------->| 2654 | | | | | 2655 | | | | Bob goes offline | 2656 | | | | | 2657 | | | Appearance selection times out | 2658 | | | | | 2659 | | |<- NOTIFY F14<| | 2660 | | | | | 2661 | | |>F15 200 OK ->| | 2662 | | | |------ NOTIFY F16>| 2663 | | | | | 2664 | | | NOTIFY is retransmitted | 2666 Figure 11. 2668 11.12. Appearance Seizure Contention Race Condition 2670 Bob and Alice both try to reserve appearance 2 by publishing at the 2671 same time. The Appearance Agent allocates the appearance to Bob by 2672 sending a 200 OK and denies it to Alice by sending a 400 (Bad 2673 Request) response. After the NOTIFY F5, Alice learns that Bob is 2674 using appearance 2. Alice then attempts to reserve appearance 3 by 2675 publishing, which is then accepted. 2677 Carol Proxy Alice Appearance Agent Bob 2678 | | | | | 2679 | | | |<----- PUBLISH F1<| 2680 | | | | (appearance=2) 2681 | | |>F2 PUBLISH ->| | 2682 | | | (appearance=2) | 2683 | | | | | 2684 | | | |>F3 200 OK ------>| 2685 | | |<---- F4 400 <| | 2686 | | | | | 2687 | | |<-- NOTIFY F5<| | 2688 | | | | | 2689 | | |>F6 200 OK -->| | 2690 | | | |------- NOTIFY F7>| 2691 | | | | | 2692 | | | |F10 100 Trying -------------------------------->| 2697 |<- INVITE F11<| | | | 2698 | | | |<---- PUBLISH F12<| 2699 | | | | (appearance=2) 2700 | | | |>F13 200 OK ----->| 2701 | | |>F14 PUBLISH->| | 2702 | | | (appearance=3) | 2703 | | | | | 2704 | | |<--- F15 200 <| | 2705 | | | | | 2706 | | |<- NOTIFY F16<| | 2707 | | | | | 2708 | |>F17 200 OK ->| | 2709 Dave | | |------ NOTIFY F18>| 2710 | | | | | 2711 | | | |F21 100 ----->| | | 2715 |<- INVITE F22<| | | | 2717 Figure 12. 2719 11.13. Appearance Agent Subscription to UAs 2721 In this scenario, the Appearance Agent does not have any way of 2722 knowing Bob's dialog state information, except through Bob. This 2723 could be because the Appearance Agent is not part of a B2BUA, or 2724 perhaps Bob is remotely registering. When Bob registers, the 2725 Appearance Agent receives a registration event package notification 2726 from the registrar. The Appearance Agent then SUBSCRIBEs to Bob's 2727 dialog event state using Event:dialog in the SUBSCRIBE. Whenever 2728 Bob's dialog state changes, Bob's UA sends a NOTIFY to the Appearance 2729 Agent which then notifies the other other UAs in the group. 2731 Carol Proxy Alice Appearance Agent Bob 2732 | | | | | 2733 | |<----------------------------------- REGISTER F1<| 2734 | | | | | 2735 | |>F2 200 OK ------------------------------------->| 2736 | | | | | 2737 | |>F3 NOTIFY ------------------>| | 2738 | | | | | 2739 | |<------------------ 200 OK F4<| | 2740 | | | |---- SUBSCRIBE F5>| 2741 | | | | | 2742 | | | |F8 200 OK ------>| 2747 | | | | | 2748 | | | |<--- SUBSCRIBE F9<| 2749 | | | | | 2750 | | | |>F10 200 OK ----->| 2751 | | | | | 2752 | | | |------ NOTIFY F11>| 2753 | | | | | 2754 | | | |F14 100 Trying -------------------------------->| 2759 |<- INVITE F15<| | | | 2760 | | | |<----- NOTIFY F16<| 2761 | | | | | 2762 | | | |>F17 200 OK ----->| 2763 | | |<- NOTIFY F18<| | 2764 | | | | | 2765 | | |>F19 200 OK ->| | 2766 | | | |------ NOTIFY F20>| 2767 | | | | | 2768 | | | |F22 180 --->| | | | 2770 | |>F23 180 Ringing ------------------------------->| 2771 | | | | | 2772 | | | |<----- NOTIFY F24<| 2773 | | | | | 2774 | | | |>F25 200 OK ----->| 2775 | | |<- NOTIFY F26<| | 2776 | | | | | 2777 | | |>F27 200 OK ->| | 2778 | | | |------ NOTIFY F28>| 2779 | | | | | 2780 | | | |F30 200 OK ->| | | | 2782 | |>F31 200 OK ------------------------------------>| 2783 | | | | | 2784 | | | |<----- NOTIFY F32<| 2785 | | | | | 2786 | | | |>F33 200 OK ----->| 2787 | | | | | 2788 | |<--------------------------------------- ACK F34<| 2789 |<---- ACK F35<| | | | 2790 | | | | | 2791 |<================= Both way RTP established ===================>| 2792 | | | | | 2793 | | |<- NOTIFY F36<| | 2794 | | | | | 2795 | | |>F37 200 OK ->| | 2796 | | | |------ NOTIFY F38>| 2797 | | | | | 2798 | | | || 2816 | | | | | 2817 | |<------------------------------(hold) INVITE F22<| 2818 |<- INVITE F23<| | | | 2819 | | | | | 2820 |>F24 200 OK ->| | | | 2821 | |>F25 200 OK ------------------------------------>| 2822 | | | | | 2823 | |<--------------------------------------- ACK F26<| 2824 |<---- ACK F27<| | | | 2825 | | | | | 2826 | |< - - - - - - - - - - - - - ->| | 2827 | | | | | 2828 | | |<- NOTIFY F28<| | 2829 | | | | | 2830 | | |>F29 200 OK ->| | 2831 | | | |>F30 NOTIFY ----->| 2832 | | | | | 2833 | | | |<----- 200 OK F31<| 2834 | | | | | 2835 | | Alice decides to pick up the call | 2836 | | | | | 2837 | | |>F32 PUBLISH->| | 2838 | | | | | 2839 | | |<- 200 OK F33<| | 2840 | | | | | 2841 | | |<- NOTIFY F34<| | 2842 | | | | | 2843 | | |>F35 200 OK ->| | 2844 | | | |>F36 NOTIFY ----->| 2845 | | | | | 2846 | | | |<----- 200 OK F37<| 2847 |>F38 BYE ---->| | | | 2848 | |>F39 BYE --------------------------------------->| 2849 | | | | | 2850 | |<------------------------------------ OK 200 F40<| 2851 |<- 200 OK F41<| | | | 2852 | |<-- INVITE F42<| | | 2853 |<- INVITE F43<|(w/ Replaces) | | | 2854 |( w/ Replaces)| | | | 2855 | | | | | 2856 |>F44 481 ---->| | | | 2857 | |>F45 481 ----->| | | 2858 |<---- ACK F46<| | | | 2859 | |<----- ACK F47<| | | 2860 | | |>F48 PUBLISH->| | 2861 | | | | | 2862 | | |<- 200 OK F49<| | 2863 | | | | | 2864 | | |<- NOTIFY F50<| | 2865 | | | | | 2866 | | |>F51 200 OK ->| | 2867 | | | |>F52 NOTIFY ----->| 2868 | | | | | 2869 | | | |<----- 200 OK F53<| 2871 Figure 14. 2873 F48 Alice ----> Appearance Agent 2875 PUBLISH sip:HelpDesk@example.com SIP/2.0 2876 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A 2877 From: ;tag=44150CC6-A7B7919D 2878 To: ;tag=428765950880801 2879 CSeq: 11 PUBLISH 2880 Call-ID: 87837Fkw87asfds 2881 Contact: 2882 Event: dialog;shared 2883 Max-Forwards: 70 2884 Content-Type: application/dialog-info+xml 2885 Content-Length: ... 2887 2888 2893 2896 1 2897 false 2898 2902 terminated 2903 2904 2905 2906 2907 2908 2909 2910 2911 2913 11.15. Appearance Seizure Incoming/Outgoing Contention Race Condition 2915 Alice tries to seize appearance 2 at the same time appearance 2 is 2916 allocated to an incoming call. The Appearance Agent resolves the 2917 conflict by sending a 400 (Bad Request) to Alice. After the NOTIFY 2918 F6, Alice learns that the incoming call is using appearance 2. Alice 2919 republishes for appearance 3, which is accepted. Note that this 2920 example shows the INVITE being received before the NOTIFY from the 2921 Appearance Agent. 2923 Carol Proxy Alice Appearance Agent Bob 2924 | | | | | 2925 |>-- INVITE F1>| | | | 2926 | |< - - - - - - - - - - - - - ->| | 2927 | | | | | 2928 | | |>F2 PUBLISH ->| | 2929 | | | (appearance=2) | 2930 | | | | | 2931 | |>F3 INVITE (appearance=2) ---------------------->| 2932 | | | | | 2933 | |>F4 INVITE | | | 2934 | |(appearance=2)>| | | 2935 | | |<---- F5 400 <| | 2936 | | | | | 2937 | | |<-- NOTIFY F6<| | 2938 | | | | | 2939 | | |>F7 200 OK -->| | 2940 | | | |------- NOTIFY F8>| 2941 | | | | | 2942 | | | |F10 PUBLISH->| | 2945 | | | (appearance=3) | 2946 | | | | | 2947 | | |< F11 200 OK <| | 2948 | | | | | 2949 | | |<- NOTIFY F12<| | 2950 | | | | | 2951 | |>F13 200 OK ->| | 2952 Dave | | |------ NOTIFY F14>| 2953 | | | | | 2954 | | | |F17 100 ----->| | | 2958 |<- INVITE F18<| | | | 2960 Figure 15. 2962 12. Security Considerations 2964 Since multiple line appearance features are implemented using 2965 semantics provided by SIP [RFC3261], the SIP Event Package for Dialog 2966 State [RFC4235], and the SIP Event Framework 2967 [I-D.ietf-sipcore-rfc3265bis] and [RFC3903], security considerations 2968 in these documents apply to this document as well. 2970 To provide confidentiality, NOTIFY or PUBLISH message bodies that 2971 provide the dialog state information and the dialog identifiers MAY 2972 be encrypted end-to-end using the standard mechanisms such as S/MIME 2973 described in [RFC3261]. Alternatively, sending the NOTIFY and 2974 PUBLISH requests over TLS also provides confidentiality, although on 2975 a hop-by-hop basis. All SUBSCRIBES and PUBLISHES between the UAs and 2976 the Appearance Agent MUST be authenticated. Without proper 2977 authentication and confidentiality, a third party could learn 2978 information about dialogs associated with a AOR and could try to use 2979 this information to hijack or manipulate those dialogs using SIP call 2980 control primitives. 2982 All INVITEs with Replaces or Join header fields MUST only be accepted 2983 if the peer requesting dialog replacement or joining has been 2984 properly authenticated using a standard SIP mechanism (such as Digest 2985 or S/MIME), and authorized to request a replacement. Otherwise, a 2986 third party could disrupt or hijack existing dialogs in the 2987 appearance group. 2989 For an emergency call, a UA MUST NOT wait for a confirmed seizure of 2990 an appearance before sending an INVITE. Waiting for confirmation 2991 could inadvertently delay or block the emergency call, which by its 2992 nature needs to be placed as expeditiously as possible. Instead, a 2993 emergency call MUST proceed regardless of the status of the PUBLISH 2994 transaction. 2996 13. IANA Considerations 2998 This section registers the SIP Event header field parameter 'shared', 2999 the SIP Alert-Info header field parameter 'appearance' and the XML 3000 namespace extensions to the SIP Dialog Package. 3002 13.1. SIP Event Header Field Parameter: shared 3004 This document defines the 'shared' header field parameter to the 3005 Event header field in the "SIP Header Field Parameters and Parameter 3006 Values" registry defined by [RFC3968] 3007 Predefined 3008 Header Field Parameter Name Values Reference 3009 ---------------------------- ------------------ ---------- --------- 3010 Event shared No [RFC-to-be] 3012 13.2. SIP Alert-Info Header Field Parameter: appearance 3014 This document defines the 'appearance' parameter to the Alert-Info 3015 header in the SIP Parameters registry. 3017 Predefined 3018 Header Field Parameter Name Values Reference 3019 ---------------------- --------------- --------- --------- 3020 Alert-Info appearance No [RFC-to-be] 3022 13.3. URN Sub-Namespace Registration: sa-dialog-info 3024 This section registers a new XML namespace per the procedures 3025 in [RFC3688]. 3027 URI: urn:ietf:params:xml:ns:sa-dialog-info. 3029 Registrant Contact: IETF BLISS working group, , 3030 Alan Johnston 3032 XML: 3034 BEGIN 3035 3036 3038 3039 3040 3042 Shared Appearance Dialog Information Namespace 3043 3044 3045

Namespace for Shared Appearance Dialog Information

3046

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

3047

See 3048 RFCXXXX.

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