idnits 2.17.1 draft-ietf-bliss-shared-appearances-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3261, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4235, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3261, updated by this document, for RFC5378 checks: 2000-07-17) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 14, 2011) is 4791 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-09) exists of draft-ietf-sipcore-rfc3265bis-02 == Outdated reference: A later version (-14) exists of draft-ietf-salud-alert-info-urns-00 == Outdated reference: A later version (-15) exists of draft-worley-service-example-06 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BLISS A. Johnston, Ed. 3 Internet-Draft Avaya 4 Updates: 3261, 4235 M. Soroushnejad 5 (if approved) V. Venkataramanan 6 Intended status: Standards Track Sylantro Systems Corp 7 Expires: September 15, 2011 March 14, 2011 9 Shared Appearances of a Session Initiation Protocol (SIP) Address of 10 Record (AOR) 11 draft-ietf-bliss-shared-appearances-07 13 Abstract 15 This document describes the requirements and implementation of a 16 group telephony feature commonly known as Bridged Line Appearance 17 (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line 18 Appearance (SCA). When implemented using the Session Initiation 19 Protocol (SIP), it is referred to as shared appearances of an Address 20 of Record (AOR) since SIP does not have the concept of lines. This 21 feature is commonly offered in IP Centrex services and IP-PBX 22 offerings and is likely to be implemented on SIP IP telephones and 23 SIP feature servers used in a business environment. This feature 24 allows several user agents (UAs) to share a common AOR, learn about 25 calls placed and received by other UAs in the group, and pick up or 26 join calls within the group. This document discusses use cases, 27 lists requirements and defines extensions to implement this feature. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 15, 2011. 46 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 2. Conventions used in this document . . . . . . . . . . . . . . 6 77 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 6 78 3.1. Executive/Assistant Arrangement . . . . . . . . . . . . . 6 79 3.2. Call Group . . . . . . . . . . . . . . . . . . . . . . . 7 80 3.3. Single Line Extension . . . . . . . . . . . . . . . . . . 7 81 3.4. Changing UAs . . . . . . . . . . . . . . . . . . . . . . 7 82 4. Requirements and Implementation . . . . . . . . . . . . . . . 7 83 4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 7 84 4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 9 85 5. Normative Description . . . . . . . . . . . . . . . . . . . . 11 86 5.1. Elements . . . . . . . . . . . . . . . . . . . . . . . . 11 87 5.2. Shared Appearance Dialog Package Extensions . . . . . . . 12 88 5.2.1. The element . . . . . . . . . . . . . . . 12 89 5.2.2. The element . . . . . . . . . . . . . . . 12 90 5.2.3. The element . . . . . . . . . . . . . 13 91 5.2.4. The element . . . . . . . . . . . . 13 92 5.3. Shared Appearance User Agents . . . . . . . . . . . . . . 13 93 5.3.1. Appearance Numbers and Call Context . . . . . . . . . 16 94 5.3.2. Appearance Numbers and Call Control . . . . . . . . . 16 95 5.3.3. Appearance Numbers and Transfer . . . . . . . . . . . 17 96 5.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . 17 97 6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 19 98 7. Alert-Info Appearance Parameter Definition . . . . . . . . . . 21 99 8. User Interface Considerations . . . . . . . . . . . . . . . . 22 100 8.1. Appearance Number Rendering . . . . . . . . . . . . . . . 22 101 8.1.1. Single Appearance UAs . . . . . . . . . . . . . . . . 22 102 8.1.2. Dual Appearance UAs . . . . . . . . . . . . . . . . . 22 103 8.1.3. Shared Appearance UAs with Fixed Appearance Number . . 23 104 8.1.4. Shared Appearance UAs with Variable Appearance 105 Number . . . . . . . . . . . . . . . . . . . . . . . . 23 106 8.1.5. Example User Interface Issues . . . . . . . . . . . . 23 107 8.2. Call State Rendering . . . . . . . . . . . . . . . . . . 24 108 9. Interop with non-Shared Appearance UAs . . . . . . . . . . . . 24 109 9.1. Appearance Assignment . . . . . . . . . . . . . . . . . . 24 110 9.2. Appearance Release . . . . . . . . . . . . . . . . . . . 24 111 9.3. UAs Supporting Dialog Events but Not Shared Appearance . 25 112 10. Provisioning Considerations . . . . . . . . . . . . . . . . . 25 113 11. Example Message Flows . . . . . . . . . . . . . . . . . . . . 26 114 11.1. Registration and Subscription . . . . . . . . . . . . . . 26 115 11.2. Appearance Selection for Incoming Call . . . . . . . . . 30 116 11.3. Outgoing Call without Appearance Seizure . . . . . . . . 33 117 11.4. Outgoing Call with Appearance Seizure . . . . . . . . . . 36 118 11.5. Outgoing Call without using an Appearance Number . . . . 40 119 11.6. Appearance Release . . . . . . . . . . . . . . . . . . . 42 120 11.7. Appearance Pickup . . . . . . . . . . . . . . . . . . . . 43 121 11.8. Calls between UAs within the Group . . . . . . . . . . . 47 122 11.9. Consultation Hold with Appearances . . . . . . . . . . . 50 123 11.10. Joining or Bridging an Appearance . . . . . . . . . . . . 53 124 11.11. Appearance Allocation - Loss of Appearance . . . . . . . 55 125 11.12. Appearance Seizure Contention Race Condition . . . . . . 56 126 11.13. Appearance Agent Subscription to UAs . . . . . . . . . . 57 127 11.14. Appearance Pickup Race Condition Failure . . . . . . . . 59 128 11.15. Appearance Seizure Incoming/Outgoing Contention Race 129 Condition . . . . . . . . . . . . . . . . . . . . . . . . 62 130 12. Security Considerations . . . . . . . . . . . . . . . . . . . 63 131 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63 132 13.1. SIP Event Package Parameter: shared . . . . . . . . . . . 63 133 13.2. URN Sub-Namespace Registration: sa-dialog-info . . . . . 64 134 13.3. XML Schema Registration . . . . . . . . . . . . . . . . . 64 135 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 65 136 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65 137 15.1. Normative References . . . . . . . . . . . . . . . . . . 65 138 15.2. Informative References . . . . . . . . . . . . . . . . . 66 139 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67 141 1. Introduction 143 The feature and functionality requirements for SIP user agents (UAs) 144 supporting business telephony applications differ greatly from basic 145 SIP user agents, both in terms of services and end user experience. 146 In addition to basic SIP support [RFC3261], many of the services in a 147 business environment require the support for SIP extensions such as 148 REFER [RFC3515], SUBSCRIBE/NOTIFY primitives 149 [I-D.ietf-sipcore-rfc3265bis] PUBLISH [RFC3903], the SIP Replaces 150 [RFC3891], and Join [RFC3911] header fields, etc. Many of the 151 popular business services have been documented in the SIP Service 152 Examples [RFC5359]. 154 This specification details a method for implementing a group 155 telephony feature known variously in telephony as Bridged Line 156 Appearance (BLA) or Multiple Line Appearances (MLA), one of the more 157 popular advanced features expected of SIP IP telephony devices in a 158 business environment. Other names for this feature include Shared 159 Call/Line Appearance (SCA), Shared Call Status and Multiple Call 160 Appearance (MCA). A variant of this feature is known as Single Line 161 Extension. 163 This document looks at how this feature can be implemented using 164 standard SIP [RFC3261] in conjunction with SIP events 165 [I-D.ietf-sipcore-rfc3265bis] and publication [RFC3903] for 166 exchanging status among user agents, and the SIP dialog state event 167 package [RFC4235] to exchange dialog state information to achieve the 168 same. Different approaches will be discussed including the use of 169 URI parameters, feature tags, and dialog package extensions along 170 with the strengths and weaknesses of the various approaches. 172 In traditional telephony, the line is physical. A common scenario in 173 telephony is for a number of business telephones to share a single or 174 a small number of lines. The sharing or appearance of these lines 175 between a number of phones is what gives this feature its name. A 176 common scenario in SIP is for a number of business telephones to 177 share a single or a small number of Address of Record (AOR) URIs. 179 In addition, an AOR can have multiple appearances on a single UA in 180 terms of the user interface. The appearance number relates to the 181 user interface for the telephone - typically each appearance of an 182 AOR has a visual display (lamp that can change color or blink or a 183 screen icon) and a button (used to select the appearance). The 184 telephony concept of line appearance is still relevant to SIP due to 185 the user interface considerations. It is important to keep the 186 appearance number construct because: 188 1. Human users are used to the concept and will expect it in 189 replacement systems (e.g. an overhead page announcement says "Joe 190 pickup line 3"). 191 2. It is a useful structure for user interface representation. 193 The purpose of the appearance number is to identify active calls to 194 facilitate sharing between users (e.g. passing a call from one user 195 to another). If a telephone has enough buttons/lamps, calls could be 196 presented on the nth button. If not, it may still be desirable to 197 present the call state, but the appearance number should be displayed 198 so that users know which call, for example, is on hold on which key. 200 In this document, except for the usage scenarios in the next section, 201 we will use the term "appearance" rather than "line appearance" since 202 SIP does not have the concept of lines. Note that this does not mean 203 that a conventional telephony user interface (lamps and buttons) must 204 be used - implementations may use another metaphor as long as the 205 appearance number is readily apparent to the user. Each AOR has a 206 separate appearance numbering space. As a result, a given UA user 207 interface may have multiple occurrences of the same appearance 208 number, but they will be for different AORs. 210 2. Conventions used in this document 212 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 213 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 214 document are to be interpreted as described in RFC-2119 [RFC2119] and 215 indicate requirement levels for compliant mechanisms. 217 3. Usage Scenarios 219 The following examples are common applications of the Shared 220 Appearances feature and are mentioned here as informative use cases. 221 All these example usages can be supported by the Shared Appearances 222 feature described in this document. The main differences relate to 223 the user interface considerations of the device. 225 3.1. Executive/Assistant Arrangement 227 The appearances on the executive's UA also appear on the assistant's 228 UA. The assistant may answer incoming calls to the executive and 229 then place the call on hold for the executive to pick up. The 230 assistant can always see the state of all calls on the executive's 231 UA. 233 3.2. Call Group 235 Users with similar business needs or tasks can be assigned to 236 specific groups and share an AOR. For example, an IT department 237 staff of five might answer a help line which has three appearances on 238 each phone in the IT work area. A call answered on one phone can be 239 put on hold and picked up on another phone. A shout or an IM to 240 another staff member can result in them taking over a call on a 241 particular appearance. Another phone can request to be added/joined/ 242 bridged to an existing appearance resulting in a conference call. 244 3.3. Single Line Extension 246 In this scenario, incoming calls are offered to a group of UAs. When 247 one answers, the other UAs are informed. If another UA in the group 248 seizes the line (i.e. goes off hook), it is immediately bridged or 249 joined in with the call. This mimics the way residential telephone 250 extensions usually operate. 252 3.4. Changing UAs 254 A user is on a call on one UA and wishes to change devices and 255 continue the call on another UA. They place the call on hold, note 256 the appearance number of the call, then walk to another UA. They are 257 able to identify the same appearance number on the other UA, pickup 258 the call, and continue the conversation. 260 4. Requirements and Implementation 262 The next section details the requirements and discusses the 263 implementation of the shared appearances of an AOR feature. 265 4.1. Requirements 267 The basic requirements of the shared appearance feature can be 268 summarized as follows: 270 REQ-1 Incoming calls to the AOR must be offered to a group of UAs and 271 can be answered by any of them. 273 REQ-2 Each UA in the group must be able to learn the call status of 274 the others in the group for the purpose of rendering this information 275 to the user. 277 REQ-3 A UA must be able to join (also called bridge or conference 278 together) or pick up (take) an active call of another UA in the group 279 in a secure way. 281 REQ-4 The mechanism should require the minimal amount of 282 configuration. UAs registering against the group AOR should be able 283 to participate in the appearance group without manual configuration 284 of group members. 286 REQ-5 The mechanism must scale for large numbers of appearances, n, 287 and large numbers of UAs, N, without introducing excessive messaging 288 traffic. 290 REQ-6 Each call or session (incoming or outgoing) must be assigned a 291 common "appearance" number from a managed pool administered for the 292 AOR group. Once the session has terminated, the appearance number is 293 released back into the pool and can be reused by another incoming or 294 outgoing session. 296 REQ-7 Each UA in the group must be able to learn the status of all 297 appearances of the group. 299 REQ-8 There must be mechanisms to resolve appearance contention among 300 the UAs in the group. 302 REQ-9 The mechanism must allow all UAs receiving an incoming session 303 request to utilize the same appearance number at the time of 304 alerting. 306 REQ-10 The mechanism must have a way of reconstructing appearance 307 state after an outage that does not result in excessive traffic and 308 processing. 310 REQ-11 The mechanism must have backwards compatibility such that a UA 311 which is unaware of the feature can still register against the group 312 AOR and make and receive calls. 314 REQ-12 The mechanism must not allow UAs outside the group to select, 315 seize or manipulate appearance numbers. 317 REQ-13 For privacy reasons, there must be a mechanism so that 318 appearance information is not leaked outside the group of UAs. (e.g. 319 "So who do you have on line 1?") 321 REQ-14 The mechanism must support a way for UAs to request 322 exclusivity on a line appearance. Exclusivity means that the UA 323 requesting it desires to have a private conversation with the 324 external party and other UAs must not be allowed to be joined or 325 taken. Exclusivity may be requested at the start of an incoming or 326 outgoing session or during the session. An exclusivity request may 327 be accepted or rejected by the entity providing the shared appearance 328 service. Therefore, the mechanism must provide a way of 329 communicating the result back to the requester UA. 331 REQ-15 The mechanism should support a way for a UA to seize a 332 particular appearance number for outgoing requests prior to sending 333 the actual request. This is often called seizure. 335 REQ-16 The mechanism should support a way for a UA to seize a 336 particular appearance number and also send the request at the same 337 time. This is needed when an automatic ringdown feature (a telephone 338 configured to immediately dial a phone number when it goes off hook) 339 is combined with shared appearances - in this case, seizing the line 340 is the same thing as dialing. 342 4.2. Implementation 344 This section non-normatively discusses the implementation of the 345 shared appearance feature. The normative description is in 346 Section 5. Many of the requirements for this service can be met 347 using standard SIP mechanisms such as: 349 - A SIP Forking Proxy and Registrar/Location Service meets REQ-1. 351 - The SIP Dialog Package meets REQ-2. 353 - The SIP Replaces and Join header fields meets REQ-3. 355 - The use of a State Agent for the Dialog Package meets REQ-4 and 356 REQ-5. 358 REQ-6 suggests the need for an entity which manages the appearance 359 resource. Just as conferencing systems commonly have a single point 360 of control, known as a focus, a Shared Appearance group has a single 361 point of control of the appearance shared resource. This is defined 362 as an Appearance Agent for a group. While an Appearance Agent can be 363 part of a centralized server, it could also be co-resident in a 364 member User Agent who has taken on this functionality for a group. 365 The Appearance Agent knows or is able to determine the dialog state 366 of all members of the group. 368 While the appearance resource could be managed co-operatively by a 369 group of UAs without any central control, this is outside the scope 370 of this draft. It is also possible that the Appearance Agent logic 371 could be distributed in all UAs in the group. For example, rules 372 that govern assigning appearance numbers for incoming requests (e.g. 373 lowest available appearance number) and rules for contention handling 374 (e.g. when two UAs request the use of the same appearance number, 375 hash dialog identifiers and compare with the lowest hash winning) 376 would need to be defined and implemented. 378 To best meet REQ-9, the appearance number for an incoming INVITE 379 needs to be contained in the INVITE, in addition to being delivered 380 in the dialog package NOTIFY. Otherwise, if the NOTIFY is delayed or 381 lost, a UA in the group might receive an incoming INVITE but might 382 not know which appearance number to render during alerting. 384 This specification defines an extension parameter for the Alert-Info 385 header field in RFC 3261 to carry the appearance number: 387 Alert-Info: ;appearance=1 389 The next section discusses the operations used to implement parts of 390 the shared appearance feature. 392 1. A UA is configured with the AOR of a shared appearance group. It 393 registers against the AOR, then attempts a dialog state 394 subscription to the AOR. If the subscription fails, loops back 395 to itself, or returns an error, it knows there is no State Agent, 396 and hence no Appearance Agent and this feature is not 397 implemented. 398 2. If the subscription receives a 200 OK, the UA knows there is a 399 State Agent and that the feature is implemented. The UA then 400 follows the steps in this list. 401 3. Information learned about the dialog state of other UAs in the 402 group is rendered to the user. 403 4. Incoming calls are forked to all UAs in the group, and any may 404 answer. UAs receive the appearance number to use in rendering 405 the incoming call in a NOTIFY from the Appearance Agent and in 406 the INVITE itself. The UA will also receive a notification if 407 the call is answered by another UA in the group so this 408 information can be rendered to the user. 409 5. For outgoing calls, the operation depends on the implementation. 410 If the user seizes a particular appearance number for the call, 411 the UA publishes the 100 Trying state dialog information without 412 an appearance number and waits for a 200 OK before sending the 413 INVITE. 414 6. For outgoing calls, if the user does not seize a particular 415 appearance or does not care, the INVITE can be sent immediately, 416 and the appearance number learned as the call progresses from a 417 notification from the Appearance Agent. 418 7. For outgoing calls, if the user does not wish to seize an 419 appearance (such as during a consultation call or if a UA is 420 fetching 'service media' such as music on hold 421 [I-D.worley-service-example]), the UA also publishes this prior 422 to sending the INVITE. 423 8. Established calls within the group may be joined (bridged) or 424 taken (picked) by another UA. Information in the dialog package 425 notifications can be used to construct Join or Replaces header 426 fields. Since the same appearance number is used for these types 427 of operations, this information is published prior to sending the 428 INVITE Join or INVITE Replaces. 429 9. The Appearance Agent may not have full access to the complete 430 dialog state of some or all of the UAs in the group. If this is 431 the case, the Appearance Agent will subscribe to the dialog state 432 of individual UAs in the group to obtain this information. 433 Normal notifications will be sent every time the dialog state 434 changes, including calls placed, answered, placed on and off 435 hold, and hangups. 437 5. Normative Description 439 This section normatively describes the shared appearance feature 440 extensions. The following definitions are used throughout this 441 document: 443 Seizing: An appearance can be reserved prior to a call being placed 444 by seizing the appearance. An appearance can be seized by 445 communicating an artificial state of "trying" prior to actually 446 initiating a dialog, in order to appear as it was already initiating 447 a dialog. The appearance number is confirmed prior to sending the 448 INVITE. 450 Selecting(or Not-Seizing): An appearance is merely selected (i.e., 451 not seized) if there is no such communication of artificial state of 452 "trying" prior to initiating a dialog: i.e., the state is 453 communicated when the dialog is actually initiated. The appearance 454 number is learned after the INVITE is sent. This is a user interface 455 only issue. 457 5.1. Elements 459 A complete system to implement this feature consists of: 461 1. User Agents that support publications, subscriptions, and 462 notifications for the SIP dialog event package, and the shared 463 appearance dialog package extensions and behavior. 464 2. An Appearance Agent consisting of a State Agent for the dialog 465 event package that implements an Event State Compositor (ESC) and 466 the shared appearance dialog package extensions and behavior. 467 The Appearance Agent also has logic for assigning and releasing 468 appearance numbers, and resolving appearance number contention. 469 3. A forking proxy server that can communicate with the State Agent 470 4. A registrar that supports the registration event package. 472 The behavior of these elements is described normatively in the 473 following sections after the definitions of the dialog package 474 extensions. 476 5.2. Shared Appearance Dialog Package Extensions 478 This specification defines four new elements as extensions to the SIP 479 Dialog Event package [I-D.ietf-sipcore-rfc3265bis]. The schema is 480 defined in Section 6. The elements are , , 481 , and which are sub-elements of the 482 element. 484 5.2.1. The element 486 The element is used to convey the appearance number. 487 The appearance number is a positive integer. When sent in a 488 publication in state Trying to the Appearance Agent, it is used to 489 request an appearance number. When sent by the Appearance Agent, it 490 indicates that the appearance number is associated with a dialog. 491 The UA generating the to-tag and from-tag parameters treats them from 492 a local perspective. In other words, if the UA sent out a request 493 within the dialog, the to-tag parameter would match the remote tag, 494 and the from-tag parameter would match the local tag. 496 5.2.2. The element 498 The element is a boolean used to indicate whether the UA 499 will accept Join or Replaces INVITEs for this dialog. For example, 500 some shared appearance systems only allow call pickup when the call 501 is on hold. In this case, the element should be used to 502 explicitly indicate this, rather than implicitly by the hold state. 504 It is important to note that this element is a hint. In order to 505 prevent another UA from taking or joining a call, a UA can, in 506 addition to setting the tag, not report full dialog 507 information to the Appearance Agent. Not having the full dialog 508 information (Call-ID, remote-tag, and local-tag) prevents another UA 509 from constructing a Join or Replaces header field. Although a UA may 510 set exclusive to true, the UA must still be ready to reject an INVITE 511 Join relating to this dialog. If these dialog identifiers have 512 already been shared with the Appearance Agent, the UA could send an 513 INVITE Replaces to change them and then not report the new ones to 514 the Appearance Agent. 516 If the proxy knows which dialogs are marked exclusive, the proxy MAY 517 enforce this exclusivity by rejecting INVITE Join and INVITE Replaces 518 requests containing those dialog identifiers with a 403 Forbidden 519 response. 521 Note that exclusivity has nothing to do with appearance number 522 selection or seizing - instead, it is about call control 523 operations that can be performed on a dialog. 525 5.2.3. The element 527 The element is used to convey dialog identifiers of 528 any other dialogs which are joined (mixed or bridged) with the 529 dialog. Only the UA which is performing the actual media mixing 530 should include this element in publications to the Appearance Agent. 531 Note that this element should still be used even when the Join header 532 field was not used to join the dialogs. For example, two separate 533 dialogs on a UA could be joined without any SIP call control 534 operations. Joined dialogs will share the same appearance number. 536 5.2.4. The element 538 The element is used to convey dialog identifiers of 539 any other dialogs which will be or have been replaced with this 540 dialog. For example, a UA in the group picking up a call on another 541 UA by sending an INVITE with Replaces would include this element for 542 the replacing dialog. Replaced dialogs will share the same 543 appearance number. 545 5.3. Shared Appearance User Agents 547 User Agents that support the Shared Appearance feature MUST support 548 the dialog state package [RFC4235] with the shared appearance 549 extensions and the 'shared' dialog event package parameter defined in 550 Section 13. 552 User Agents MUST support the dialog package extensions in Section 5.2 553 along with SUBSCRIBE and NOTIFY [I-D.ietf-sipcore-rfc3265bis] and 554 PUBLISH [RFC3903]. SUBSCRIBE, NOTIFY, and PUBLISH requests for the 555 dialog event package MUST include the 'shared' Event header field 556 parameter. 558 The presence of the 'shared' Event package parameter tells the 559 Appearance Agent that this UA supports this specification. 561 Upon initialization, the UA MUST subscribe to the dialog event 562 package of the AOR and refresh the subscription per the SIP Events 563 Framework. If the SUBSCRIBE request fails, then no Appearance Agent 564 may be present and this feature is not active for this AOR. The UA 565 MAY periodically retry the subscription to see if conditions have 566 changed at intervals no shorter than 4 hours. 568 User Agents which implement call pickup, joining and bridging MUST 569 support sending an INVITE with Replaces [RFC3891] or Join [RFC3911]. 570 The User Agent Client needs to include the to-tag and from-tag 571 information in the Replaces or Join header so that the correct dialog 572 will be matched by the User Agent Server per the rules in RFC 3891 573 and RFC 3911. All User Agents supporting INVITE MUST support 574 receiving an INVITE with a Replaces [RFC3891] or a Join [RFC3911] 575 header field. 577 When publishing or notifying dialog package information, a UA MUST 578 include all dialog identification available at the time of 579 publication, with the exception that a UA may omit information if it 580 wishes to prevent other UAs from joining or picking up a call. 581 Dialog identification includes local and remote target URIs, call-id, 582 to-tag, and from-tag. When calls are placed on hold, the 583 "+sip.rendering=no" feature tag MUST be included in dialog package 584 notifications. 586 The accurate rendering of the idle/active/alerting/hold state of 587 other UAs in the group is an important part of the shared 588 appearance feature. 590 A UA MUST send dialog package PUBLISH requests in the following 591 situations: 593 1. When the user seizes a particular appearance number for an 594 outgoing call (i.e. seizing the appearance and going "off-hook", 595 if the UA's user interface uses this metaphor). 596 2. When the user has requested that an appearance number not be used 597 for an outgoing call (i.e. during a consultation call, a 'service 598 media' call such as for music on hold 599 [I-D.worley-service-example] or for a call not considered part of 600 the shared appearance group). 601 3. When the user has selected to join (or bridge) an existing call. 602 4. When the user has selected to replace (or take) an existing call. 604 In all these cases, the INVITE SHOULD NOT be sent until the 200 OK 605 response to the PUBLISH has been received, except for an emergency 606 call, when a UA MUST never wait for a confirmed seizure before 607 sending an INVITE. Instead, the emergency call MUST proceed 608 regardless of the status of PUBLISH transaction. 610 Note that when a UA seizes an appearance prior to establishment of a 611 dialog (#1 and #2 in above list), not all dialog information will be 612 available. In particular, when a UA publishes an attempt to seize an 613 appearance prior to knowing the destination URI, minimal or no dialog 614 information may be available. For example, in some cases, only the 615 local target URI for the call will be known and no dialog 616 information. If no dialog identification information is present in 617 the initial PUBLISH, the UA MUST PUBLISH again after receiving the 618 100 Trying response. 620 The first publication will cause the Appearance Agent to reserve 621 the appearance number for this UA. If the publication does not 622 have any dialog identifiers (e.g. Call-ID, or local tag) the 623 Appearance Agent cannot assign the appearance number to a 624 particular dialog of the UA until the second publication which 625 will contain some dialog identifiers. 627 This publication state is refreshed as described in [RFC3903] during 628 the early dialog state or the Appearance Agent may reassign the 629 appearance number. Once the dialog has transitioned to the confirmed 630 state, no publication refreshes are necessary. 632 Appearance numbers are a shorthand label for active and pending 633 dialogs related to an AOR. Many of the features and services built 634 using this extension rely on the correct rendering of this 635 information to the human user. In addition, the group nature of the 636 feature means that the rendering must be similar between different 637 vendors and different models. Failure to do so will greatly reduce 638 the value and usefulness of these protocol extensions. The 639 appearances number for each active and pending dialog SHOULD be 640 explicitly (i.e. by appearance number) or implicitly (using a user 641 interface metaphor that makes the numbering and ordering clear to the 642 user) rendered to the user. The far end identity of each dialog 643 (e.g. the remote party identity) MUST NOT be rendered in place of the 644 appearance number. The state of each appearance SHOULD also be 645 rendered (idle, active, busy, joined, etc.). UAs can tell that a set 646 of dialogs are joined (bridged or mixed) together by the presence of 647 one or more elements containing other SIP dialog 648 identifiers. Appearance numbers of dialogs can be learned by dialog 649 package notifications containing the element from the 650 Appearance Agent or from the 'appearance' Alert-Info parameter in an 651 incoming INVITE. Should they conflict, the dialog package 652 notification takes precedence. 654 A UA that does not need to seize a particular appearance number (or 655 doesn't care) would just send an INVITE as normal to place an 656 outbound call. 658 A user may select an appearance number but then abandon placing a 659 call (go back on hook). In this case, the UA SHOULD free up the 660 appearance number by removing the event state with a PUBLISH as 661 described in [RFC3903]. 663 A UA SHOULD register against the AOR only if it is likely the UA will 664 be answering incoming calls. If the UA is mainly going to be 665 monitoring the status of the shared appearance group calls and 666 picking or joining calls, the UA SHOULD only subscribe to the AOR and 667 not register against the AOR. 669 All subscribed UAs will receive dialog package NOTIFYs of Trying 670 state for incoming INVITEs. 672 5.3.1. Appearance Numbers and Call Context 674 There are cases where two separate dialogs at a UA (non-mixed) share 675 the same 'context'. That is, they relate to each other and should 676 not be treated the same as any other two dialogs within the group. 677 One example of this is a 'consultation call' where a user puts an 678 existing dialog on hold, then calls another user, before switching 679 back to the original dialog. Another case, described below, occurs 680 during transfer operations, where for a transient period, a UA is 681 invovled in dialogs with two other UAs, but the dialogs are related, 682 and should not be treated as independent dialogs. These cases are 683 best handled by having these dialogs that share a context with an 684 existing dialog not have an an appearance number assigned to them. 686 A UA wanting to place a call but not have an appearance number 687 assigned publishes before sending the INVITE without an 'appearance' 688 element but with the 'shared' event package parameter present. If 689 the Appearance Agent policy does not allow calls without an assigned 690 appearance number, a 400 response with the reason phrase "Appearance 691 Number Conflict" will be received, and the UA will republish either 692 selecting/seizing an appearance number or send the INVITE without 693 publishing, in which case the Appearance Agent will assign one. 695 Note that if an Appearance Agent rejects calls without an 696 appearance number, certain operations such as consultation calls, 697 transfer, and music on hold may be impacted. 699 5.3.2. Appearance Numbers and Call Control 701 When an INVITE is generated to attempt to bridge or take a call (i.e. 702 contains Join or Replaces with a dialog identifier of another dialog 703 in the shared appearance group), the appearance number of the joined 704 or replaced call SHOULD be published. The publication MUST contain 705 the appearance number of the dialog to be joined or replaced and the 706 dialog identifier in the 'joined-dialog' or 'replaced-dialog' 707 elements. 709 Note that this information is provided to the Appearance Agent so 710 that it can provide proper appearance assignment behavior. If the 711 INVITE Join or Replaces was sent without publishing first, the 712 Appearance Agent might assign a new appearance number to this 713 INVITE, which would be a mistake. With Join, the publication has 714 the 'joined-dialog' element to prevent the Appearance Agent from 715 generating a 400 Appearance Number Conflict response due to the 716 reuse of an appearance number. For Replaces, the purpose of the 717 'replaced-dialog' is to prevent a race condition where the BYE 718 could cause the appearance number to be released when it should 719 stay with the replacing dialog. 721 5.3.3. Appearance Numbers and Transfer 723 During a transfer operation, it is important that the appearance 724 number not change during the operation. Consider the example of 725 Alice, a member of an appearance group, who is talking to Carol, who 726 is outside the appearance group. Carol transfers Alice to David, who 727 is also outside the appearance group. For example, if Alice is using 728 appearance 3 for the session with Carol, the resulting session with 729 David should also use appearance number 3. Otherwise, an appearance 730 number change can cause a "jump" on the UI and confusion to the user. 731 There are two possible scenarios using the terminology of RFC 5589: 732 Alice is the transferee in any type of transfer (receives the REFER) 733 or the transfer target in an attended transfer (receives the INVITE 734 with Replaces). 736 If Alice is the transferee, the triggered INVITE from the REFER 737 should be treated as a consultation call, and should not use a new 738 appearance number. When the transfer completes, the appearance 739 number associated with the dialog with Carol is moved to the dialog 740 associated with David. 742 If Alice is the target, the incoming INVITE should not have a new 743 appearance number assigned. Instead, it should reuse the appearance 744 number associated with the dialog being replaced. If the Appearance 745 Agent does assign a different appearance number, when the transfer 746 completes, Alice should release that appearance number and use the 747 original appearance number associated with the dialog with Carol. 749 5.4. Appearance Agent 751 An Appearance Agent defined in this specification MUST implement a 752 dialog package state agent for the UAs registered against the AOR. 753 The Appearance Agent MUST support the appearance dialog package 754 extensions defined in Section 5.2. The Appearance Agent MUST support 755 publications and subscriptions for this event package. 757 The Appearance Agent MUST have a way of discovering the state of all 758 dialogs associated with the AOR. If this information is not 759 available from a call stateful proxy or B2BUA, the Appearance Agent 760 MAY use the registration event package [RFC3680] to learn of UAs 761 associated with the AOR and MAY subscribe to their dialog event 762 state. Also, an Appearance Agent MAY subscribe to a UAs dialog event 763 state in order to reconstruct state. As a result, the registrar MUST 764 support the registration event package. Dialog package notifications 765 are recommended by RFC 4235 to "only contain information on the 766 dialogs whose state or participation information has changed." This 767 specification extends RFC 4235 as follows. The Appearance Agent 768 SHOULD send dialog event state notifications whenever the following 769 events happen to UAs in the AOR group: 771 1. A call is received, placed, answered, or terminated. 772 2. A call is placed on or off hold. 773 3. A call is joined or replaced. 774 4. An appearance number is reserved or released. 776 The Appearance Agent MUST allocate an appearance number for all 777 incoming calls and send immediate notifications to the UAs subscribed 778 to the shared group AOR. A new appearance number is allocated except 779 for an incoming INVITE with a Join or Replaces header field. For 780 this case, the appearance number should match the appearance number 781 of the dialog being joined or replaced. The Appearance Agent MUST be 782 able to communicate with the forking proxy to learn about incoming 783 calls and also to pass the appearance number to the proxy to insert 784 in the Alert-Info header field. 786 Note that UAs need to be able to handle incoming INVITEs without 787 an appearance number assigned. This could be caused by a failure 788 of the Appearance Agent or other error condition. Although the 789 proper rendering of the INVITE may not be possible, this is better 790 than ignoring or failing the INVITE. 792 An Appearance Agent SHOULD assign an appearance number to an outgoing 793 dialog if a PUBLISH has not been received selecting/seizing a 794 particular appearance number. 796 Note that if the appearance group has appearance-unaware UAs 797 making calls, the Appearance Agent will still allocate appearance 798 numbers for INVITEs sent by those UAs. 800 An Appearance Agent receiving a PUBLISH with an appearance number 801 checks to make sure the publication is valid. An appearance number 802 can be assigned to only one dialog unless there is a 'joined-dialog' 803 or 'replaced-dialog' element indicating that the dialog will be/has 804 been replaced or joined. A 400 response with the reason phrase 805 "Appearance Number Conflict" is returned if the chosen appearance 806 number is invalid, and an immediate NOTIFY should be sent to the UA 807 containing full dialog event state. 809 An Appearance Agent receiving a PUBLISH without an appearance number 810 but with the 'shared' event package parameter present interprets this 811 as a request by the UA to not assign an appearance number. If the 812 Appearance Agent policy does not allow this, a 400 Appearance Number 813 Conflict response is returned. If policy does allow this, a 200 OK 814 response is returned and no appearance number is allocated. An 815 Appearance Agent does not have to share this dialog information (i.e. 816 send a NOTIFY) with other UAs in the group as the information will 817 not be rendered by the other UAs. 819 The Appearance Agent allocates an apperance number to a dialog from 820 the time the appearance is requested via a PUBLISH or from the 821 receipt of an INVITE, to the time when the last dialog associated 822 with the appearance is terminated, including all dialogs which are 823 joined or replaced. During the early dialog state, the Appearance 824 Agent controls the rate of dialog state publication using the Expires 825 header field in 200 OK responses to PUBLISH requests. An interval of 826 3 minutes is RECOMMENDED. After the dialog associated with the 827 publication has been confirmed, the expiration of the publication 828 state has no effect on the appearance allocation. If the publication 829 contains no dialog state information, the Appearance Agent MUST 830 reserve the appearance number for the UA but can not assign the 831 appearance to any particular dialog of the UA. When the publication 832 state is updated with any dialog information, the appearance number 833 can then be assigned to the particular dialog. A UA which has been 834 allocated an appearance number using a PUBLISH MAY free up the 835 appearance number by removing the event state with a PUBLISH as 836 described in [RFC3903]. 838 If an INVITE is sent by a member of the group using the shared AOR or 839 sent to the shared AOR and no appearance number is available, the 840 proxy MAY reject the INVITE with a 403 Forbidden response code. 842 Appearance numbers are only used for dialogs in which one UA 843 associated with the group AOR is a participant. If an incoming 844 INVITE to the group AOR is forwarded to another AOR, the appearance 845 number is immediately freed up and can be assigned to another dialog. 847 6. XML Schema Definition 849 The 'appearance', 'joined-dialog', 'replaced-dialog', and 'exclusive' 850 elements are defined within a new XML namespace URI. This namespace 851 is "urn:ietf:params:xml:ns:sa-dialog-info". The schema for these 852 elements is: 854 855 861 863 864 866 868 870 871 873 875 876 878 880 882 883 885 886 887 888 890 891 892 893 894 896 7. Alert-Info Appearance Parameter Definition 898 This specification extends RFC 3261 [RFC3261] to add an 'appearance' 899 parameter to the Alert-Info header field, and to also allow proxies 900 to modify or delete the Alert-Info header field. 902 The changes to RFC 3261 ABNF are: 904 alert-param = LAQUOT absoluteURI RAQUOT *( SEMI 905 (generic-param / appearance-param) ) 906 appearance-param = "appearance" EQUAL *DIGIT 908 A proxy inserting an 'appearance' Alert-Info parameter follows normal 909 policies Alert-Info policies. If an Alert-Info is already present, 910 the proxy either removes the Alert-Info if it is not trusted, or adds 911 the 'appearance' parameter to the Alert-Info header field. If an 912 appearance number parameter is already present (associated with 913 another AOR or by mistake), the value is rewritten adding the new 914 appearance number. There MUST NOT be more than one appearance 915 parameter in an Alert-Info header field. 917 If no special ringtone is desired, a normal ringtone should be 918 indicated using the urn:alert:service:normal in the Alert-Info, as 919 per [I-D.ietf-salud-alert-info-urns]. The appearance number present 920 in an Alert-Info header field SHOULD be rendered by the UA to the 921 user, following the guidelines in Section 5.3. If the INVITE is 922 forwarded to another AOR, the appearance parameter in the Alert-Info 923 SHOULD be removed before forwarding outside the group. 925 The determination as to what value to use in the appearance parameter 926 can be done at the proxy that forks the incoming request to all the 927 registered UAs. 929 There are a variety of ways the proxy can use to determine what 930 value it should use to populate this parameter. For example, the 931 proxy could fetch this information by initiating a SUBSCRIBE 932 request with Expires: 0 to the Appearance Agent for the AOR to 933 fetch the list of lines that are in use. Alternatively, it could 934 act like a UA that is a part of the appearance group and SUBSCRIBE 935 to the State-Agent like any other UA. This would ensure that the 936 active dialog information is available without having to poll on a 937 need basis. It could keep track of the list of active calls for 938 the appearance AOR based on how many unique INVITE requests it has 939 forked to or received from the appearance AOR. Another approach 940 would be for the Proxy to first send the incoming INVITE to the 941 Appearance Agent which would redirect to the appearance group URI 942 and escape the proper Alert-Info header field for the Proxy to 943 recurse and distribute to the other UAs in the group. 945 The Appearance Agent needs to know about all incoming requests to 946 the AOR in order to seize the appearance number. One way in which 947 this could be done is for the Appearance Agent to register against 948 the AOR with a higher q value. This will result in the INVITE 949 being sent to the Appearance Agent first, then being offered to 950 the UAs in the group. 952 8. User Interface Considerations 954 The "appearance number" allocated to a call is an important concept 955 that enables calls to be handled by multiple devices with 956 heterogeneous user interfaces in a manner that still allows users to 957 see a consistent model. Careful treatment of the appearance number 958 is essential to meet the expectations of the users. Also, rendering 959 the correct call/appearance state to users is also important. 961 8.1. Appearance Number Rendering 963 Since different UAs have different user interface capabilities, it is 964 usual to find that some UAs have restrictions that others do not. 965 Perfect interoperability across all UAs is clearly not possible, but 966 by careful design, interoperability up to the limits of each UA can 967 be achieved. 969 The following guidelines suggest how the appearance number should be 970 handled in three typical user interface implementations. 972 8.1.1. Single Appearance UAs 974 These devices are constrained by only having the capability of 975 displaying status indications for a single appearance. Despite this, 976 it is important that devices of this type do not ignore the 977 appearance number. The UA should still send messages annotated with 978 an appropriate appearance number (i.e. "0"). Any call indications 979 for appearances other than for number "0" should be rejected with a 980 486 or 480 response. 982 8.1.2. Dual Appearance UAs 984 These devices are essentially single appearance phones that implement 985 call waiting. They have a very simple user interface that allows 986 them to switch between two appearances (toggle or flash hook) and 987 perhaps audible tones to indicate the status of the other appearance. 988 Only appearance numbers "0" and "1" will be used by these UAs. 990 8.1.3. Shared Appearance UAs with Fixed Appearance Number 992 This UA is the typical 'business-class' hard-phone. A number of 993 appearances are typically configured statically and labeled on 994 buttons, and calls may be managed using these configured appearances. 995 Any calls outside this range should be rejected, and not mapped to a 996 free button. Users of these devices often seize specific appearance 997 numbers for outgoing calls, and the UA will need to seize the 998 appearance number and wait for confirmation from the Appearance Agent 999 before proceeding with calls. 1001 8.1.4. Shared Appearance UAs with Variable Appearance Number 1003 This UA is typically a soft-phone or graphically rich user interface 1004 hard-phone. In these cases, even the idea of an appearance index may 1005 seem unnecessary. However, for these phones to be able to interwork 1006 successfully with other phone types, it is important that they still 1007 use the appearance index to govern the order of appearance of calls 1008 in progress. No specific guidance on presentation is given except 1009 that the order should be consistent. These devices can typically 1010 make calls without waiting for confirmation from the Appearance Agent 1011 on the appearance number. 1013 8.1.5. Example User Interface Issues 1015 The problems faced by each style of user interface are readily seen 1016 in this example: 1018 1. A call arrives at the shared appearance group, and is assigned an 1019 appearance number of 0. All UAs should be able to render to the 1020 user the arrival of this call. 1021 2. Another call arrives at the shared appearance group, and is 1022 assigned an appearance number of 1. The single appearance UA 1023 should not present this call to the user. Other user agents 1024 should have no problems presenting this call distinctly from the 1025 first call. 1026 3. The first call clears, releasing appearance number "0". The 1027 single appearance UA should now be indicating no calls since it 1028 is unable to manage calls other than on the first appearance. 1029 Both shared appearance UAs should clearly show that appearance 1030 number 0 is now free, but that there is still a call on 1031 appearance number 1. 1032 4. A third call arrives, and is assigned the appearance number of 0. 1033 All UAs should be able to render the arrival of this new call to 1034 the user. Multiple appearance UAs should continue to indicate 1035 the presence of the second call, and should also ensure that the 1036 presentation order is related to the appearance number and not 1037 the order of call arrival. 1039 8.2. Call State Rendering 1041 UAs that implement the shared appearance feature typically have a 1042 user interface that provides the state of other appearances in the 1043 group. As dialog state NOTIFYs from the Appearance Agent are 1044 processed, this information can be rendered. Even the simplest user 1045 interface typically has three states: idle, active, and hold. The 1046 idle state, usually indicated by lamp off, is indicated for an 1047 appearance when the appearance number is not associated with any 1048 dialogs, as reported by the Appearance Agent. The active state, 1049 usually indicated by a lamp on, is indicated by an appearance number 1050 being associated with at least one dialog, as reported by the 1051 Appearance Agent. The hold state, often indicated by a blinking 1052 lamp, means the call state from the perspective of the UA in the 1053 shared appearance group is hold. This can be determined by the 1054 presence of the "sip+rendering=no" feature tag [RFC3840] with the 1055 local target URI. Note that the hold state of the remote target URI 1056 is not relevant to this display. For joined dialogs, the state is 1057 rendered as hold only if all local target URIs are indicated with the 1058 "sip+rendering=no" feature tag. 1060 9. Interop with non-Shared Appearance UAs 1062 It is desirable to allow a basic UA that does not directly support 1063 shared appearance to be part of a shared appearance group. To 1064 support this the Proxy must collaborate with the Appearance Agent. 1065 This is not required in the basic shared appearance architecture, 1066 consequently shared appearance interop with non-shared appearance UAs 1067 will not be available in all shared appearance deployments. 1069 First, a UA which does not support dialog events or the shared 1070 appearance feature will be discussed. Then, a UA which does support 1071 dialog events but not the shared appearance feature will be 1072 discussed. 1074 9.1. Appearance Assignment 1076 A UA that has no knowledge of appearances must will only have 1077 appearance numbers for outgoing calls if assigned by the Appearance 1078 Agent. If the non-shared appearance UA does not support Join or 1079 Replaces, all dialogs could be marked "exclusive" to indicate that 1080 these options are not available. 1082 9.2. Appearance Release 1084 In all cases the Appearance Agent must be aware of dialog lifetime to 1085 release appearances back into the group. 1087 It is also desirable that any dialog state changes (such as hold, 1088 etc) be made available to other UAs in the group through the Dialog 1089 Event Package. If the Appearance Agent includes a proxy which 1090 Record-Routes for dialogs from the non-shared appearance aware UA, 1091 the Appearance Agent will know about the state of dialogs including 1092 hold, etc. This information could be determined from inspection of 1093 non-end-to-end-encrypted INVITE and re-INVITE messages and added to 1094 the dialog information conveyed to other UAs. 1096 9.3. UAs Supporting Dialog Events but Not Shared Appearance 1098 Interoperability with UAs which support dialog events but not the 1099 shared appearance feature is more straightforward. As before, all 1100 appearance number assignment must be done by the Appearance Agent. 1101 The Appearance Agent can include appearance information in NOTIFYs - 1102 this UA will simply ignore this extra information. This type of UA 1103 will ignore appearance number limitations and may attempt to Join or 1104 Replace dialogs marked exclusive. As a result, the Proxy or UAs need 1105 to reject such requests or the dialogs will get joined or taken. 1107 10. Provisioning Considerations 1109 UAs can automatically discover if this feature is active for an AOR 1110 by looking for the 'shared' Event header parameter in a response to a 1111 dialog package SUBSCRIBE to the AOR, so no provisioning for this is 1112 needed. 1114 The registrar will need to be provisioned to accept either first or 1115 third party registrations for the shared AOR. First party 1116 registration means the To and From URIs in the REGISTER request are 1117 the shared AOR URI. Third party registration means the To URI is the 1118 shared AOR URI and the From URI is a different AOR, perhaps that of 1119 the individual user. Either the credentials of the shared AOR or the 1120 user MUST be accepted by the registrar and the Appearance Agent, 1121 depending on the authorization policy in place for the domain. 1123 If the Appearance Agent needs to subscribe to the dialog state of the 1124 UAs, then the Appearance Agent and the UAs need to be provisioned 1125 with credentials so the UAs can authenticate the Appearance Agent. 1127 In some cases, UAs in the shared appearance group might have a UI 1128 limitation on the number of appearances that can be rendered. 1129 Typically this will be hard phones with buttons/lamps instead of more 1130 flexible UIs. In this case, it can be useful for the Appearance 1131 Agent to know this maximum number. This can allow the Appearance 1132 Agent to apply policy when this limit is reached, e.g. deny a call. 1133 However, this mechanism does not provide any way to discover this by 1134 protocol means. 1136 11. Example Message Flows 1138 The next section shows call flow and message examples. The flows and 1139 descriptions are non-normative. Note that in these examples, all 1140 INVITEs sent by a UA in the group will be From the shared AOR 1141 (sip:HelpDesk@example.com in this case), and all INVITES sent to the 1142 group will have a Request-URI of the shared AOR. Any other requests 1143 would not apply to this feature and would be handled using normal SIP 1144 mechanisms. 1146 Note that the first twelve examples assume the Appearance Agent is 1147 aware of dialog state events. The example in Section 11.13 shows the 1148 case where this is not the case and as a result the Appearance Agent 1149 initiates a subscription to users of the shared AOR. Any of the 1150 other call flow examples could have shown this mode of operation as 1151 it is equally valid. 1153 11.1. Registration and Subscription 1155 Bob and Alice are in an appearance group identified by the shared 1156 appearance AOR sip:HelpDesk@example.com. Bob REGISTERs using contact 1157 sip:bob@ua2.example.com. Alice REGISTERs with contact 1158 sip:alice@ua1.example.com. 1160 User Agents for Alice and Bob subscribe to the dialog package for the 1161 appearance AOR and publish dialog state to the Appearance Agent. 1162 Message exchanges between the Registrar, Appearance Agent, Alice, and 1163 Bob are shown below. The call flow examples below do not show the 1164 authentication of subscriptions, publications, and notifications. It 1165 should be noted that for security purposes, all subscriptions must be 1166 authorized before the SUBSCRIBE is accepted. 1168 Also note that registrations and subscriptions must all be refreshed 1169 by Alice at intervals determined by the expiration intervals returned 1170 by the Registrar or Appearance Agent. 1172 Registrar Appearance Agent Alice Bob 1173 | | | | 1174 | | | | 1175 |<--------------------------- REGISTER F1<| | 1176 | | | | 1177 |>F2 200 OK ----------------------------->| | 1178 | | | | 1179 | |<----- SUBSCRIBE F3<| | 1180 | | | | 1181 | |>F4 200 OK -------->| | 1182 | | | | 1183 | |>F5 NOTIFY -------->| | 1184 | | | | 1185 | |<-------- 200 OK F6<| | 1186 | | | | 1187 |<-------------------------------------------- REGISTER F7<| 1188 | | | | 1189 |>F8 200 OK ---------------------------------------------->| 1190 | | | | 1191 | |<---------------------- SUBSCRIBE F9<| 1192 | | | | 1193 | |>F10 200 OK ------------------------>| 1194 | | | | 1195 | |>F11 NOTIFY ------------------------>| 1196 | | | | 1197 | |<------------------------ 200 OK F12<| 1198 | | | | 1200 Figure 1. 1202 F1-F2: Alice registers AOR with 1203 contact: 1205 F1 Alice ----> Registrar 1207 REGISTER sip:registrar.example.com SIP/2.0 1208 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09 1209 From: ;tag=CDF9A668-909E2BDD 1210 To: 1211 CSeq: 2 REGISTER 1212 Call-ID: d3281184-518783de-cc23d6bb 1213 Contact: 1214 Max-Forwards: 70 1215 Expires: 3600 1216 Content-Length: 0 1218 F2 Registrar ----> Alice 1220 SIP/2.0 200 OK 1221 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09 1222 CSeq: 2 REGISTER 1223 Call-ID: d3281184-518783de-cc23d6bb 1224 From: ;tag=CDF9A668-909E2BDD 1225 To: ;tag=1664573879820199 1226 Contact: ;expires=3600 1227 Content-Length: 0 1228 F3 to F6: Alice also subscribes to the events associated with the 1229 Appearance AOR. Appearance Agent notifies Alice of the status. 1231 F3 Alice ----> Appearance Agent 1233 SUBSCRIBE sip:HelpDesk@example.com SIP/2.0 1234 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A 1235 From: ;tag=925A3CAD-CEBB276E 1236 To: 1237 CSeq: 91 SUBSCRIBE 1238 Call-ID: ef4704d9-bb68aa0b-474c9d94 1239 Contact: 1240 Event: dialog;shared 1241 Accept: application/dialog-info+xml 1242 Max-Forwards: 70 1243 Expires: 3700 1244 Content-Length: 0 1246 F4 Appearance Agent ----> Alice 1248 SIP/2.0 200 OK 1249 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A 1250 CSeq: 91 SUBSCRIBE 1251 Call-ID: ef4704d9-bb68aa0b-474c9d94 1252 From: ;tag=925A3CAD-CEBB276E 1253 To: ;tag=1636248422222257 1254 Allow-Events: dialog 1255 Expires: 3700 1256 Contact: 1257 Content-Length: 0 1259 F5 Appearance Agent ----> Alice 1261 NOTIFY sip:alice@ua1.example.com SIP/2.0 1262 From: ;tag=1636248422222257 1263 To: ;tag=925A3CAD-CEBB276E 1264 Call-ID: ef4704d9-bb68aa0b-474c9d94 1265 CSeq: 232 NOTIFY 1266 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1846 1267 Max-Forwards: 70 1268 Content-Type: application/dialog-info+xml 1269 Event: dialog;shared 1270 Subscription-State: active;expires=3000 1271 Contact: 1272 Content-Length: ... 1274 1275 1279 1281 F6 Alice ----> Appearance Agent 1283 SIP/2.0 200 OK 1284 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1846 1285 From: ;tag=1636248422222257 1286 To: ;tag=925A3CAD-CEBB276E 1287 CSeq: 232 NOTIFY 1288 Call-ID: ef4704d9-bb68aa0b-474c9d94 1289 Contact: 1290 Content-Length: 0 1292 F7 Bob ----> Registrar 1294 REGISTER sip:registrar.example.com SIP/2.0 1295 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4b53b54d87B 1296 From: ;tag=34831131 1297 To: 1298 CSeq: 72 REGISTER 1299 Call-ID: 139490230230249348 1300 Contact: 1301 Max-Forwards: 70 1302 Expires: 3600 1303 Content-Length: 0 1305 F8 Registrar ----> Bob 1307 SIP/2.0 200 OK 1308 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4b53b54d87B 1309 From: ;tag=34831131 1310 To: ;tag=fkwlwqi1 1311 CSeq: 72 REGISTER 1312 Call-ID: 139490230230249348 1313 Contact: ;expires=3200 1314 Contact: ;expires=3600 1315 Content-Length: 0 1317 11.2. Appearance Selection for Incoming Call 1319 In the call flow below Bob and Alice are in an appearance group. 1320 Carol places a call to the appearance group AOR. The Appearance 1321 Agent sends NOTIFYs to Alice and Bob telling them what appearance the 1322 call is using. Both Alice and Bob's devices are alerted of the 1323 incoming call. Bob answers the call. 1325 Note that it is possible that both Alice and Bob answer the call and 1326 send 200 OK responses to Carol. It is up to Carol to resolve this 1327 situation. Typically, Carol will send ACKs to both 200 OKs but send 1328 a BYE to terminate one of the dialogs. As a result, either Alice or 1329 Bob will receive the BYE and publish that their dialog is over. 1330 However, if Carol answers both Alice and Bob and keeps both dialogs 1331 active, then the Appearance Agent will need to resolve the situation 1332 by moving either Alice or Bob's dialog to a different appearance. 1334 All NOTIFY messages in the call flow below carry dialog events and 1335 only dialog states are mentioned for simplicity. For brevity, the 1336 details of some messages are not shown below. Note that the order of 1337 F2 - F5 and F7 - F8 could be reversed. 1339 Forking Appearance 1340 Carol Proxy Agent Alice Bob 1341 | | | | | 1342 |>F1 INVITE >| | | | 1343 | |< - - - - - >| | | 1344 | | |>F2 NOTIFY ----------->| 1345 | | | | | 1346 | | |F4 NOTIFY ->| | 1349 | | | | | 1350 | | |<-200 OK F5-<| | 1351 |<- 100 F6 -<| | | | 1352 | |>F7 INVITE (appearance=1) ---------->| 1353 | | | | | 1354 | |>F8 INVITE (appearance=1) >| | 1355 | | | | | 1356 | |<-------------------- Ringing 180 F9<| 1357 |< 180 F10 -<| | | | 1358 | |<--------- 180 Ringing F11<| | 1359 |< 180 F12 -<| | | | 1360 | | | | | 1361 | |<------------------------ 200 OK F13<| 1362 |< 200 F14 -<| | | | 1363 | | | | | 1364 | |>F15 CANCEL -------------->| | 1365 | | | | | 1366 | |<-------------- 200 OK F16<| | 1367 | | | | | 1368 | |F18 ACK ----------------->| | 1371 |>F19 ACK -->| | | | 1372 | |>F20 ACK --------------------------->| 1373 | | | | | 1374 |<=============Both way RTP established===========>| 1375 | | | | | 1376 | |< - - - - - >| | | 1377 | | | | | 1378 | | |>F21 NOTIFY >| | 1379 | | | | | 1380 | | |<- 200 F22 -<| | 1381 | | | | | 1382 | | |>F23 NOTIFY ---------->| 1383 | | | | | 1384 | | | Alice 1391 NOTIFY sip:alice@ua1.example.com SIP/2.0 1392 From: ;tag=151702541050937 1393 To: ;tag=18433323-C3D237CE 1394 Call-ID: 1e361d2f-a9f51109-bafe31d4 1395 CSeq: 12 NOTIFY 1396 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1403 1397 Max-Forwards: 70 1398 Content-Type: application/dialog-info+xml 1399 Event: dialog;shared 1400 Subscription-State: active;expires=2800 1401 Contact: 1402 Content-Length: ... 1404 1405 1410 1414 1 1415 trying 1416 1417 sip:carol@ua.example.com 1418 1419 1420 1422 F7 Proxy ----> Bob 1424 INVITE sip:bob@ua2.example.com SIP/2.0 1425 Via: SIP/2.0/UDP ua3.example.com;branch=z9hG4bK4324ea 1426 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK38432ji 1427 From: ;tag=44BAD75D-E3128D42 1428 To: 1429 CSeq: 106 INVITE 1430 Call-ID: 14-1541707345 1431 Contact: 1432 Max-Forwards: 69 1433 Alert-Info: ;appearance=1 1434 Content-Type: application/sdp 1435 Content-Length: ... 1437 v=0 1438 o=- 1102980499 1102980499 IN IP4 ua3.example.com 1439 s= 1440 c=IN IP4 ua3.example.com 1441 t=0 0 1442 m=audio 2238 RTP/AVP 0 8 101 1443 a=rtpmap:0 PCMU/8000 1444 a=rtpmap:8 PCMA/8000 1445 a=rtpmap:101 telephone-event/8000 1447 F21 Appearance Agent ----> Alice 1449 NOTIFY sip:alice@ua1.example.com SIP/2.0 1450 From: ;tag=151702541050937 1451 To: ;tag=18433323-C3D237CE 1452 Call-ID: 1e361d2f-a9f51109-bafe31d4 1453 CSeq: 13 NOTIFY 1454 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK4164F03j 1455 Max-Forwards: 70 1456 Content-Type: application/dialog-info+xml 1457 Event: dialog;shared 1458 Subscription-State: active;expires=2500 1459 Contact: 1460 Content-Length: ... 1462 1463 1468 1473 1 1474 confirmed 1475 1476 sip:bob@ua2.example.com 1477 1478 1479 sip:carol@ua.example.com 1480 1481 1482 1484 11.3. Outgoing Call without Appearance Seizure 1486 In this scenario, Bob's UA places a call without first selecting/ 1487 seizing an appearance number. After Bob sends the INVITE, the 1488 appearance assigns an appearance number for it and notifies both 1489 Alice and Bob. 1491 Carol Proxy Alice Appearance Agent Bob 1492 | | | | | 1493 | | | | | 1494 | |<------------------------------------- INVITE F1<| 1495 | | | | | 1496 | |>F2 100 Trying --------------------------------->| 1497 |<-- INVITE F3<| | | | 1498 | |< - - - - - - - - - - - - - ->| | 1499 | | | | | 1500 | | |<-- NOTIFY F4<| | 1501 | | | | | 1502 | | |>F5 200 OK -->| | 1503 | | | |------- NOTIFY F6>| 1504 | | | | | 1505 | | | |F8 180 ---->| | | | 1507 | |>F9 180 Ringing -------------------------------->| 1508 | | | | | 1509 | |< - - - - - - - - - - - - - ->| | 1510 | | | | | 1511 | | |<- NOTIFY F10<| | 1512 | | | | | 1513 | | |>F11 200 OK ->| | 1514 | | | |------ NOTIFY F12>| 1515 | | | | | 1516 | | | |F14 200 OK ->| | | | 1518 | |>F15 200 OK ------------------------------------>| 1519 | | | | | 1520 | |<--------------------------------------- ACK F16<| 1521 |<---- ACK F17<| | | | 1522 | | | | | 1523 |<================= Both way RTP established ===================>| 1524 | | | | | 1525 | |< - - - - - - - - - - - - - ->| | 1526 | | | | | 1527 | | |<- NOTIFY F18<| | 1528 | | | | | 1529 | | |>F19 200 OK ->| | 1530 | | | |------ NOTIFY F20>| 1531 | | | | | 1532 | | | | Proxy 1539 INVITE sip:carol@example.com SIP/2.0 1540 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK98c87c52123A08BF 1541 From: ;tag=15A3DE7C-9283203B 1542 To: 1543 CSeq: 1 INVITE 1544 Call-ID: f3b3cbd0-a2c5775e-5df9f8d5 1545 Contact: 1546 Max-Forwards: 70 1547 Content-Type: application/sdp 1548 Content-Length: 223 1550 v=0 1551 o=- 1102980499 1102980499 IN IP4 ua2.example.com 1552 s=IP SIP UA 1553 c=IN IP4 ua2.example.com 1554 t=0 0 1555 a=sendrecv 1556 m=audio 2236 RTP/AVP 0 8 101 1557 a=rtpmap:0 PCMU/8000 1558 a=rtpmap:8 PCMA/8000 1559 a=rtpmap:101 telephone-event/8000 1561 F4 Appearance Agent ----> Alice 1563 NOTIFY sip:alice@ua1.example.com SIP/2.0 1564 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK81d84f62 1565 From: ;tag=1636248422222257 1566 To: ;tag=925A3CAD-CEBB276E 1567 Call-ID: ef4704d9-bb68aa0b-474c9d94 1568 CSeq: 233 NOTIFY 1569 Max-Forwards: 70 1570 Content-Type: application/dialog-info+xml 1571 Event: dialog;shared 1572 Subscription-State: active;expires=2200 1573 Contact: 1574 Content-Length: ... 1576 1577 1582 1585 1 1586 false 1587 trying 1588 1589 1590 1591 1592 1593 1595 F6 Appearance Agent ----> Bob 1596 NOTIFY sip:bob@ua1.example.com SIP/2.0 1597 From: ;tag=497585728578386 1598 To: ;tag=633618CF-B9C2EDA4 1599 Call-ID: a7d559db-d6d7dcad-311c9e3a 1600 CSeq: 7 NOTIFY 1601 Via: SIP/2.0/UDP appearanceagent.example.com 1602 ;branch=z9hG4bK1711759878512309 1603 Max-Forwards: 70 1604 Content-Type: application/dialog-info+xml 1605 Event: dialog;shared 1606 Subscription-State: active;expires=2000 1607 Contact: 1608 Content-Length: ... 1610 1611 1616 1619 1 1620 false 1621 trying 1622 1623 1624 1625 1626 1627 1629 11.4. Outgoing Call with Appearance Seizure 1631 In this scenario, Bob's UA sends out a dialog event PUBLISH with 1632 state (trying) selecting/seizing an appearance number before sending 1633 the INVITE. After receiving the 200 OK from the Appearance Agent 1634 confirming the appearance number, Bob's UA sends the INVITE to Carol 1635 and establishes a session. For brevity, details of some of the 1636 messages are not included in the message flows. 1638 Carol Proxy Alice Appearance Agent Bob 1639 | | | | | 1640 | | | |<----- PUBLISH F1<| 1641 | | | | | 1642 | | | |>F2 200 OK ------>| 1643 | | | | | 1644 | | |<-- NOTIFY F3<| | 1645 | | | | | 1646 | | |>F4 200 OK -->| | 1647 | | | |------- NOTIFY F5>| 1648 | | | | | 1649 | | | |F8 100 Trying --------------------------------->| 1654 |<-- INVITE F9<| | | | 1655 | | | |<---- PUBLISH F10<| 1656 | | | | | 1657 | | | |>F11 200 OK ----->| 1658 | | | | | 1659 |>F12 180 --->| | | | 1660 | |>F13 180 Ringing ------------------------------->| 1661 | | | | | 1662 | |< - - - - - - - - - - - - - ->| | 1663 | | | | | 1664 | | |<- NOTIFY F14<| | 1665 | | | | | 1666 | | |>F15 200 OK ->| | 1667 | | | |------ NOTIFY F16>| 1668 | | | | | 1669 | | | |F18 200 OK ->| | | | 1671 | |>F19 200 OK ------------------------------------>| 1672 | | | | | 1673 | |<--------------------------------------- ACK F20<| 1674 |<---- ACK F21<| | | | 1675 | | | | | 1676 |<================= Both way RTP established ===================>| 1677 | | | | | 1678 | |< - - - - - - - - - - - - - ->| | 1679 | | | | | 1680 | | |<- NOTIFY F22<| | 1681 | | | | | 1682 | | |>F23 200 OK ->| | 1683 | | | |------ NOTIFY F24>| 1684 | | | | | 1685 | | | | Appearance Agent 1698 PUBLISH sip:HelpDesk@example.com SIP/2.0 1699 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 1700 From: ;tag=44150CC6-A7B7919D 1701 To: 1702 CSeq: 7 PUBLISH 1703 Call-ID: 44fwF144-F12893K38424 1704 Contact: 1705 Event: dialog;shared 1706 Max-Forwards: 70 1707 Content-Type: application/dialog-info+xml 1708 Content-Length: ... 1710 1711 1716 1717 1 1718 false 1719 trying 1720 1721 1722 1723 1724 1725 1727 F2 Appearance Agent ----> Bob 1729 SIP/2.0 200 OK 1730 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 1731 From: ;tag=44150CC6-A7B7919D 1732 To: 1733 CSeq: 7 PUBLISH 1734 Call-ID: 44fwF144-F12893K38424 1735 Contact: 1736 Event: dialog;shared 1737 SIP-Etag: 482943245 1738 Allow-Events: dialog 1739 Expires: 60 1740 Content-Length: 0 1742 F7 Bob ---> Proxy 1744 INVITE sip:carol@example.com SIP/2.0 1745 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK342122 1746 Max-Forwards: 70 1747 From: ;tag=15A3DE7C-9283203B 1748 To: 1749 Call-ID: f3b3cbd0-a2c5775e-5df9f8d5 1750 CSeq: 31 INVITE 1751 Contact: 1752 Content-Type: application/sdp 1753 Content-Length: ... 1755 (SDP Not Shown) 1757 F10 Bob ----> Appearance Agent 1759 PUBLISH sip:HelpDesk@example.com SIP/2.0 1760 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK6d644638E7 1761 From: ;tag=0CCf6-A7FdsB79D 1762 To: 1763 CSeq: 437 PUBLISH 1764 Call-ID: fwF14d4-F1FFF2F2893K38424 1765 Contact: 1766 Event: dialog;shared 1767 Max-Forwards: 70 1768 Content-Type: application/dialog-info+xml 1769 Content-Length: ... 1771 1772 1777 1781 1 1782 false 1783 trying 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1795 11.5. Outgoing Call without using an Appearance Number 1797 In this scenario, Bob's UA sends out a dialog event PUBLISH with 1798 state (trying) indicating that he does not want to utilize an 1799 appearance number for this dialog. The PUBLISH does not have an 1800 appearance element but does have the 'shared' dialog event parameter. 1801 As a result, the Appearance Agent knows the UA does not wish to use 1802 an appearance number for this call. If the Appearance Agent does not 1803 wish to allow this, it would reject the PUBLISH with a 409 Conflict 1804 response and the UA would know to re-PUBLISH selecting/seizing an 1805 appearance number. 1807 Carol Proxy Alice Appearance Agent Bob 1808 | | | | | 1809 | | | |<----- PUBLISH F1<| 1810 | | | | | 1811 | | | |>F2 200 OK ------>| 1812 | | | | | 1813 | | |<-- NOTIFY F3<| | 1814 | | | | | 1815 | | |>F4 200 OK -->| | 1816 | | | |------- NOTIFY F5>| 1817 | | | | | 1818 | | | |F8 100 Trying --------------------------------->| 1823 |<-- INVITE F9<| | | | 1824 | | | |<---- PUBLISH F10<| 1825 | | | | | 1826 | | | |>F11 200 OK ----->| 1827 | | | | | 1828 |>F12 180 --->| | | | 1829 | |>F13 180 Ringing ------------------------------->| 1830 | | | | | 1831 | |< - - - - - - - - - - - - - ->| | 1832 | | | | | 1833 | | |<- NOTIFY F14<| | 1834 | | | | | 1835 | | |>F15 200 OK ->| | 1836 | | | |------ NOTIFY F16>| 1837 | | | | | 1838 | | | |F18 200 OK ->| | | | 1840 | |>F19 200 OK ------------------------------------>| 1841 | | | | | 1842 | |<--------------------------------------- ACK F20<| 1843 |<---- ACK F21<| | | | 1844 | | | | | 1845 |<================= Both way RTP established ===================>| 1846 | | | | | 1847 | |< - - - - - - - - - - - - - ->| | 1848 | | | | | 1849 | | |<- NOTIFY F22<| | 1850 | | | | | 1851 | | |>F23 200 OK ->| | 1852 | | | |------ NOTIFY F24>| 1853 | | | | | 1854 | | | | Appearance Agent 1861 PUBLISH sip:appearanceagent.example.com SIP/2.0 1862 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 1863 From: ;tag=4415df82k39sf 1864 To: 1865 CSeq: 7 PUBLISH 1866 Call-ID: 44fwF144-F12893K38424 1867 Contact: 1868 Event: dialog;shared 1869 Max-Forwards: 70 1870 Content-Type: application/dialog-info+xml 1871 Content-Length: ... 1873 1874 1880 1881 false 1882 trying 1883 1884 1885 1886 1887 1888 1890 Note that F7 would be the same as the previous example. 1892 11.6. Appearance Release 1894 Bob and Carol are in a dialog, created, for example as in 1895 Section 11.3. Carol sends a BYE to Bob to terminate the dialog and 1896 the Appearance Agent de-allocates the appearance number used, sending 1897 notifications out to the UAs in the shared group. 1899 Carol Proxy Alice Appearance Agent Bob 1900 | | | | | 1901 | | | | | 1902 |<================= Both way RTP established ===================>| 1903 | | | | | 1904 |>F22 BYE ---->| | | | 1905 | |>F23 BYE --------------------------------------->| 1906 | | | | | 1907 | |<------------------------------------ 200 OK F24<| 1908 |<--200 OK F25<| | | | 1909 | |< - - - - - - - - - - - - - ->| | 1910 | | | | | 1911 | | |<- NOTIFY F26<| | 1912 | | | | | 1913 | | |>F27 200 OK ->| | 1914 | | | |------ NOTIFY F28>| 1915 | | | | | 1916 | | | | Bob 1922 NOTIFY sip:bob@ua1.example.com SIP/2.0 1923 From: ;tag=497585728578386 1924 To: 1925 Call-ID: a7d559db-d6d7dcad-311c9e3a 1926 CSeq: 7 NOTIFY 1927 Via: SIP/2.0/UDP appearanceagent.example.com 1928 ;branch=z9hG4bK759878512309 1929 Max-Forwards: 70 1930 Content-Type: application/dialog-info+xml 1931 Event: dialog;shared 1932 Subscription-State: active;expires=1800 1933 Contact: 1934 Content-Length: ... 1936 1937 1942 1947 1 1948 false 1949 terminated 1950 1951 1952 1953 1954 1955 1957 11.7. Appearance Pickup 1959 In this scenario, Bob has an established dialog with Carol created 1960 using the call flows of Figure 1 or Figure 2. Bob then places Carol 1961 on hold. Alice receives a notification of this and renders this on 1962 Alice's UI. Alice subsequently picks up the held call and has a 1963 established session with Carol. Finally, Carol hangs up. Alice must 1964 PUBLISH F32 to indicate that the INVITE F38 will be an attempt to 1965 pickup the dialog between Carol and Bob, and hence may use the same 1966 appearance number. 1968 Carol Proxy Alice Appearance Agent Bob 1969 | | | | | 1970 |<================= Both way RTP established ===================>| 1971 | | | | | 1972 | |<------------------------------(hold) INVITE F22<| 1973 |<- INVITE F23<| | | | 1974 | | | | | 1975 |>F24 200 OK ->| | | | 1976 | |>F25 200 OK ------------------------------------>| 1977 | | | | | 1978 | |<--------------------------------------- ACK F26<| 1979 |<---- ACK F27<| | | | 1980 | |< - - - - - - - - - - - - - ->| | 1981 | | | | | 1982 | | |<- NOTIFY F28<| | 1983 | | | | | 1984 | | |>F29 200 OK ->| | 1985 | | | |>F30 NOTIFY ----->| 1986 | | | | | 1987 | | | |<----- 200 OK F31<| 1988 | | | | | 1989 | | Alice decides to pick up the call | 1990 | | | | | 1991 | | |>F32 PUBLISH->| | 1992 | | | | | 1993 | | |<- 200 OK F33<| | 1994 | | | | | 1995 | | |<- NOTIFY F34<| | 1996 | | | | | 1997 | | |>F35 200 OK ->| | 1998 | | | |>F36 NOTIFY ----->| 1999 | | | | | 2000 | | | |<----- 200 OK F37<| 2001 | |<-- INVITE F38<| | | 2002 |<- INVITE F39<|(w/ Replaces) | | | 2003 |( w/ Replaces)| | | | 2004 |>F40 200 OK ->| | | | 2005 | |>F41 200 OK -->| | | 2006 | | | | | 2007 | |< - - - - - - - - - - - - - ->| | 2008 | | | | | 2009 | | | |>F42 NOTIFY ----->| 2010 | | | | | 2011 | | | |<----- 200 OK F43<| 2012 | | |<- NOTIFY F44<| | 2013 | | | | | 2014 | | |>F45 200 OK ->| | 2015 | | | | | 2016 | |<----- ACK F46<| | | 2017 |<---- ACK F47<| | | | 2018 | | | | | 2019 |<= Both way RTP established =>| | | 2020 | | | | | 2021 |>F48 BYE ---->| | | | 2022 | |>F49 BYE --------------------------------------->| 2023 | | | | | 2024 | |<------------------------------------ OK 200 F50<| 2025 |<- 200 OK F51<| | | | 2026 | | | | | 2027 | |< - - - - - - - - - - - - - ->| | 2028 | | | | | 2029 | | |<- NOTIFY F52<| | 2030 | | | | | 2031 | | |>F53 200 OK ->| | 2032 | | | | | 2033 | | | |>F54 NOTIFY ----->| 2034 | | | | | 2035 | | | |<----- 200 OK F55<| 2037 Figure 7. 2039 F28 Appearance ----> Alice 2041 NOTIFY sip:alice@ua1.example.com SIP/2.0 2042 From: ;tag=151702541050937 2043 To: ;tag=18433323-C3D237CE 2044 Call-ID: 1e361d2f-a9f51109-bafe31d4 2045 CSeq: 12 NOTIFY 2046 Via: SIP/2.0/UDP appearanceagent.example.com 2047 ;branch=z9hG4bK1403 2048 Max-Forwards: 70 2049 Content-Type: application/dialog-info+xml 2050 Event: dialog;shared 2051 Subscription-State: active;expires=1800 2052 Contact: 2053 Content-Length: ... 2055 2056 2061 2066 1 2067 false 2068 active 2069 2070 2071 2072 2073 2074 2075 sip:carol@example.com 2076 2077 2078 2079 2081 F32 Alice ----> Appearance Agent 2083 PUBLISH sip:HelpDesk@example.com SIP/2.0 2084 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A 2085 From: ;tag=44150CC6-A7B7919D 2086 To: ;tag=428765950880801 2087 CSeq: 11 PUBLISH 2088 Call-ID: 87837Fkw87asfds 2089 Contact: 2090 Event: dialog;shared 2091 Max-Forwards: 70 2092 Content-Type: application/dialog-info+xml 2093 Content-Length: ... 2095 2096 2101 2104 1 2105 false 2106 2110 trying 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2122 F38 Alice ----> Proxy 2124 INVITE sip:carol@example.com SIP/2.0 2125 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK4ea695b5B376A60C 2126 From: ;tag=8C4183CB-BCEAB710 2127 To: 2128 CSeq: 1 INVITE 2129 Call-ID: 3d57cd17-47deb849-dca8b6c6 2130 Contact: 2131 2132 Replaces: f3b3cbd0-a2c5775e-5df9f8d5;to-tag=65a98f7c 2133 -1dd2-11b2-88c6-b03162323164+65a98f7c;from-tag=15A3DE7C-9283203B 2134 2135 Max-Forwards: 70 2136 Content-Type: application/sdp 2137 Content-Length: 223 2139 v=0 2140 o=- 1102980497 1102980497 IN IP4 ua1.example.com 2141 s=IP SIP UA 2142 c=IN IP4 ua1.example.com 2143 t=0 0 2144 a=sendrecv 2145 m=audio 2238 RTP/AVP 0 8 101 2146 a=rtpmap:0 PCMU/8000 2147 a=rtpmap:8 PCMA/8000 2148 a=rtpmap:101 telephone-event/8000 2150 11.8. Calls between UAs within the Group 2152 In this scenario, Bob calls Alice who is also in the Appearance 2153 group. Only one appearance number is used for this dialog. This 2154 example also shows the use of the 'exclusive' tag to indicate that 2155 other UAs in the group can not join or take this dialog. 2157 Carol Proxy Alice Appearance Agent Bob 2158 | | | | | 2159 | |<-------------------- INVITE (to Alice's UA) F1<| 2160 | | | | | 2161 | |< - - - - - - - - - - - - - ->| | 2162 | | | | | 2163 | | | | | 2164 | | |<-- NOTIFY F2<| | 2165 | | | | | 2166 | | |>F3 200 OK -->| | 2167 | | | |>F4 NOTIFY ------>| 2168 | | | | | 2169 | | | |<------ 200 OK F5<| 2170 | |>F6 INVITE --->| | | 2171 | | (appearance=1)| | | 2172 | | | | | 2173 | |<------ 180 F7<| | | 2174 | | | | | 2175 | |>F8 180 --------------------------------------->| 2176 | | | | | 2177 | |< - - - - - - - - - - - - - ->| | 2178 | | | | | 2179 | | |<-- NOTIFY F9<| | 2180 | | | | | 2181 | | |>F10 200 OK ->| | 2182 | | | |>F11 NOTIFY ----->| 2183 | | | | | 2184 | | | |<----- 200 OK F12<| 2185 | |<-- 200 OK F13<| | | 2186 | | | | | 2187 | |>F14 200 OK ------------------------------------>| 2188 | | | | | 2189 | |<--------------------------------------- ACK F15<| 2190 | | | | | 2191 | |>F16 ACK ----->| | | 2192 | | | | | 2193 | | |<======= RTP established =======>| 2194 | | | | | 2195 | |< - - - - - - - - - - - - - ->| | 2196 | | | | | 2197 | | |<- NOTIFY F17<| | 2198 | | | | | 2199 | | |>F18 200 OK ->| | 2200 | | | |>F19 NOTIFY ----->| 2201 | | | | | 2202 | | | |<----- 200 OK F24<| 2203 | | | | | 2205 Figure 8. 2207 F19 Appearance Agent ----> Bob 2208 NOTIFY sip:bob@ua1.example.com SIP/2.0 2209 From: ;tag=497585728578386 2210 To: ;tag=633618CF-B9C2EDA4 2211 Call-ID: a7d559db-d6d7dcad-311c9e3a 2212 CSeq: 7 NOTIFY 2213 Via: SIP/2.0/UDP appearanceagent.example.com 2214 ;branch=z9hG4bK1711759878512309 2215 Max-Forwards: 70 2216 Content-Type: application/dialog-info+xml 2217 Event: dialog;shared 2218 Subscription-State: active;expires=1500 2219 Contact: 2220 Content-Length: ... 2222 2223 2228 2233 true 2234 1 2235 confirmed 2236 2237 2238 2239 2240 2241 sip:HelpDesk@example.com 2242 2243 2244 2246 2251 true 2252 1 2253 confirmed 2254 2255 2257 2258 2259 sip:HelpDesk@example.com 2260 2261 2262 2264 2266 11.9. Consultation Hold with Appearances 2268 In this scenario, Bob has a call with Carol. Bob makes a 2269 consultation call to Alice by putting Carol on hold and calling 2270 Alice. Bob chooses not to have an appearance number for the call to 2271 Alice since he is treating it as part of the call to Carol. He 2272 indicates this in his PUBLISH F32 which contains the 'shared' Event 2273 parameter but no element. The PUBLISH is sent before 2274 the INVITE to Alice to ensure no appearance number is assigned by the 2275 Appearance Agent. Finally, Bob hangs up with Alice and resumes the 2276 call with Carol. Dialog notifications of the consultation call are 2277 not shown, as they are not used. 2279 Note that if Carol hangs up while Bob is consulting with Alice, Bob 2280 can decide if he wants to reuse the appearance number used with Carol 2281 for the call with Alice. If not, Bob publishes the termination of 2282 the dialog with Carol and the Appearance Agent will re-allocate the 2283 appearance. If he wants to keep the appearance, Bob will publish the 2284 termination of the dialog with Carol and also publish the appearance 2285 with the dialog with Alice. This will result in Bob keeping the 2286 appearance number until he reports the dialog with Alice terminated. 2288 Note that the call flow would be similar if Bob called a music on 2289 hold server instead of Alice to implement a music on hold service as 2290 described in [I-D.worley-service-example]. 2292 Carol Proxy Alice Appearance Agent Bob 2293 | | | | | 2294 |<================= Both way RTP established ===================>| 2295 | | | | | 2296 | |<------------------------------(hold) INVITE F22<| 2297 |<- INVITE F23<| | | | 2298 | | | | | 2299 |>F24 200 OK ->| | | | 2300 | |>F25 200 OK ------------------------------------>| 2301 | | | | | 2302 | |<--------------------------------------- ACK F26<| 2303 |<---- ACK F27<| | | | 2304 | |< - - - - - - - - - - - - - ->| | 2305 | | | | | 2306 | | |<- NOTIFY F28<| | 2307 | | | | | 2308 | | |>F29 200 OK ->| | 2309 | | | |>F30 NOTIFY ----->| 2310 | | | | | 2311 | | | |<----- 200 OK F31<| 2312 | | | | | 2313 | | Bob makes a consultation call to Alice | 2314 | | | | | 2315 | | | |<---- PUBLISH F32<| 2316 | | | | | 2317 | | | |>F33 200 OK ----->| 2318 | | | | | 2319 | |<------------------------------------ INVITE F34<| 2320 | | | | | 2321 | |>F35 INVITE -->| | | 2322 | | | | | 2323 | |<-- 200 OK F36<| | | 2324 | | | | | 2325 | |>F37 200 OK ------------------------------------>| 2326 | | | | | 2327 | |<--------------------------------------- ACK F38<| 2328 | | | | | 2329 | |>F39 ACK ----->| | | 2330 | | | | | 2331 | | |<======= RTP established =======>| 2332 | | | | | 2333 | | Bob hangs up with Alice | 2334 | | | | | 2335 | |<--------------------------------------- BYE F40<| 2336 | | | | | 2337 | |>F41 BYE ----->| | | 2338 | | | | | 2339 | |<-- 200 OK F42<| | | 2340 | | | | | 2341 | |>F43 200 OK ------------------------------------>| 2342 | | | | | 2343 | |<----------------------------(unhold) INVITE F44<| 2344 |<- INVITE F45<| | | | 2345 | | | | | 2346 |>F46 200 OK ->| | | | 2347 | |>F47 200 OK ------------------------------------>| 2348 | | | | | 2349 | |<--------------------------------------- ACK F48<| 2350 |<---- ACK F49<| | | | 2351 | |< - - - - - - - - - - - - - ->| | 2352 | | | | | 2353 | | |<- NOTIFY F50<| | 2354 | | | | | 2355 | | |>F51 200 OK ->| | 2356 | | | |>F52 NOTIFY ----->| 2357 | | | | | 2358 | | | |<----- 200 OK F53<| 2359 | | | | | 2360 |<================= Both way RTP established ===================>| 2361 | | | | | 2363 Figure 9. 2365 F32 Bob ----> Appearance Agent 2367 PUBLISH sip:HelpDesk@example.com SIP/2.0 2368 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A 2369 From: ;tag=44150CC6-A7B7919D 2370 To: ;tag=428765950880801 2371 CSeq: 11 PUBLISH 2372 Call-ID: 44fwF144-F12893K38424 2373 Contact: 2374 Event: dialog;shared 2375 Max-Forwards: 70 2376 Content-Type: application/dialog-info+xml 2377 Content-Length: ... 2379 2380 2385 2389 true 2390 trying 2391 2392 2393 2394 2395 2396 sip:HelpDesk@example.com 2397 2398 2399 2400 2402 11.10. Joining or Bridging an Appearance 2404 In this call flow, a call answered by Bob is joined by Alice or 2405 "bridged". The Join header field is used by Alice to request this 2406 bridging. If Bob did not support media mixing, Bob could obtain 2407 conferencing resources as described in [RFC4579]. 2409 Carol Forking Proxy Appearance Agent Alice Bob 2410 | | | | | 2411 |<=============Both way RTP established===========>| 2412 | | | | | 2413 | | |< PUBLISH F22| | 2414 | | | | | 2415 | | |>F23 200 OK >| | 2416 | | | | | 2417 | |<---- INVITE (w/ Join) F24<| | 2418 | | | | | 2419 | |>F25 INVITE (w/Join)---------------->| 2420 | | | | | 2421 | |<---- OK 200 Contact:Bob;isfocus F26<| 2422 | | | | | 2423 | |< - - - - - >| | | 2424 | | | | | 2425 | | |>F27 NOTIFY >| | 2426 | | | | | 2427 | | |< 200 OK F28<| | 2428 | | | | | 2429 | | |>F29 NOTIFY ---------->| 2430 | | | | | 2431 | | |F31 200 OK Contact:B----->| | 2434 | | | | | 2435 | |<----------------- ACK F32<| | 2436 | | | | | 2437 | |>ACK F33---------------------------->| 2438 | | | | | 2439 | |<-----INVITE Contact:Bob;isfocus F34<| 2440 |<-INVITE F35| | | | 2441 | | | | | 2442 |>F26 200 -->| | | | 2443 | |>F37 200 OK ------------------------>| 2444 | | | | | 2445 | |<--------------------------- ACK F38<| 2446 |<--- ACK F39| | | | 2447 | | | |<==RTP==>| 2448 |<=============Both way RTP established===========>| 2449 | | | | | 2450 | |< - - - - - >| | | 2451 | | | | | 2452 | | |>F40 NOTIFY >| | 2453 | | | | | 2454 | | |< 200 OK F41<| | 2455 | | | | | 2456 | | |>F42 NOTIFY ---------->| 2457 | | | | | 2458 | | | Appearance Agent 2465 PUBLISH sip:HelpDesk@example.com SIP/2.0 2466 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A 2467 From: ;tag=44150CC6-A7B7919D 2468 To: ;tag=428765950880801 2469 CSeq: 11 PUBLISH 2470 Call-ID: 87837Fkw87asfds 2471 Contact: 2472 Event: dialog;shared 2473 Max-Forwards: 70 2474 Content-Type: application/dialog-info+xml 2475 Content-Length: ... 2477 2478 2483 2486 1 2487 false 2488 2492 trying 2493 2494 2495 2496 2497 2498 2499 2500 2501 2503 F24 Alice ----> Proxy 2505 INVITE sip:bob@ua.example.com SIP/2.0 2506 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKcc9d727c2C29BE31 2507 From: ;tag=605AD957-1F6305C2 2508 To: 2509 CSeq: 2 INVITE 2510 Call-ID: dc95da63-60db1abd-d5a74b48 2511 Contact: 2512 2513 Join: 14-1541707345;to-tag=d3b06488-1dd1-11b2-88c5 2514 -b03162323164+d3e48f4c;from-tag=44BAD75D-E3128D42 2515 2516 Max-Forwards: 70 2517 Content-Type: application/sdp 2518 Content-Length: 223 2520 v=0 2521 o=- 1103061265 1103061265 IN IP4 ua1.example.com 2522 s=IP SIP UA 2523 c=IN IP4 ua1.example.com 2524 t=0 0 2525 a=sendrecv 2526 m=audio 2236 RTP/AVP 0 8 101 2527 a=rtpmap:0 PCMU/8000 2528 a=rtpmap:8 PCMA/8000 2529 a=rtpmap:101 telephone-event/8000 2531 11.11. Appearance Allocation - Loss of Appearance 2533 Bob reserves an appearance with a PUBLISH, sends an INVITE to Carol, 2534 then becomes unreachable. When he fails to refresh his publication 2535 to the appearance agent, the Appearance Agent declares the dialog 2536 terminated and frees up the appearance using NOTIFYs F14 and F16. 2537 After retransmitting the NOTIFY to Bob (in not shown messages F17, 2538 F18, etc.), the subscription is terminated. 2540 Carol Proxy Alice Appearance Agent Bob 2541 | | | | | 2542 | | | |<----- PUBLISH F1<| 2543 | | | | | 2544 | | | |>F2 200 OK ------>| 2545 | | | | | 2546 | | |<-- NOTIFY F3<| | 2547 | | | | | 2548 | | |>F4 200 OK -->| | 2549 | | | |------- NOTIFY F5>| 2550 | | | | | 2551 | | | |F8 100 Trying --------------------------------->| 2556 |<-- INVITE F9<| | | | 2557 | | | |<---- PUBLISH F10<| 2558 | | | | | 2559 | | | |>F11 200 OK ----->| 2560 | | | | | 2561 |>F12 180 --->| | | | 2562 | |>F13 180 Ringing ------------------------------->| 2563 | | | | | 2564 | | | | Bob goes offline | 2565 | | | | | 2566 | | | Appearance selection times out | 2567 | | | | | 2568 | | |<- NOTIFY F14<| | 2569 | | | | | 2570 | | |>F15 200 OK ->| | 2571 | | | |------ NOTIFY F16>| 2572 | | | | | 2573 | | | NOTIFY is retransmitted | 2575 Figure 11. 2577 11.12. Appearance Seizure Contention Race Condition 2579 Bob and Alice both try to reserve appearance 2 by publishing at the 2580 same time. The Appearance Agent allocates the appearance to Bob by 2581 sending a 200 OK and denies it to Alice by sending a 409 Conflict. 2582 After the NOTIFY F5, Alice learns that Bob is using appearance 2. 2583 Alice then attempts to reserve appearance 3 by publishing, which is 2584 then accepted. 2586 Carol Proxy Alice Appearance Agent Bob 2587 | | | | | 2588 | | | |<----- PUBLISH F1<| 2589 | | | | (appearance=2) 2590 | | |>F2 PUBLISH ->| | 2591 | | | (appearance=2) | 2592 | | | | | 2593 | | | |>F3 200 OK ------>| 2594 | | |<---- F4 409 <| | 2595 | | | | | 2596 | | |<-- NOTIFY F5<| | 2597 | | | | | 2598 | | |>F6 200 OK -->| | 2599 | | | |------- NOTIFY F7>| 2600 | | | | | 2601 | | | |F10 100 Trying -------------------------------->| 2606 |<- INVITE F11<| | | | 2607 | | | |<---- PUBLISH F12<| 2608 | | | | (appearance=2) 2609 | | | |>F13 200 OK ----->| 2610 | | |>F14 PUBLISH->| | 2611 | | | (appearance=3) | 2612 | | | | | 2613 | | |<--- F15 200 <| | 2614 | | | | | 2615 | | |<- NOTIFY F16<| | 2616 | | | | | 2617 | |>F17 200 OK ->| | 2618 Dave | | |------ NOTIFY F18>| 2619 | | | | | 2620 | | | |F21 100 ----->| | | 2624 |<- INVITE F22<| | | | 2626 Figure 12. 2628 11.13. Appearance Agent Subscription to UAs 2630 In this scenario, the Appearance Agent does not have any way of 2631 knowing Bob's dialog state information, except through Bob. This 2632 could be because the Appearance Agent is not part of a B2BUA, or 2633 perhaps Bob is remotely registering. When Bob registers, the 2634 Appearance Agent receives a registration event package notification 2635 from the registrar. The Appearance Agent then SUBSCRIBEs to Bob's 2636 dialog event state using Event:dialog in the SUBSCRIBE. Whenever 2637 Bob's dialog state changes, a NOTIFY is sent to the Appearance Agent 2638 who then notifies the other other UAs in the group. 2640 Carol Proxy Alice Appearance Agent Bob 2641 | | | | | 2642 | |<----------------------------------- REGISTER F1<| 2643 | | | | | 2644 | |>F2 200 OK ------------------------------------->| 2645 | | | | | 2646 | |>F3 NOTIFY ------------------>| | 2647 | | | | | 2648 | |<------------------ 200 OK F4<| | 2649 | | | |---- SUBSCRIBE F5>| 2650 | | | | | 2651 | | | |F8 200 OK ------>| 2656 | | | | | 2657 | | | |<--- SUBSCRIBE F9<| 2658 | | | | | 2659 | | | |>F10 200 OK ----->| 2660 | | | | | 2661 | | | |------ NOTIFY F11>| 2662 | | | | | 2663 | | | |F14 100 Trying -------------------------------->| 2668 |<- INVITE F15<| | | | 2669 | | | |<----- NOTIFY F16<| 2670 | | | | | 2671 | | | |>F17 200 OK ----->| 2672 | | |<- NOTIFY F18<| | 2673 | | | | | 2674 | | |>F19 200 OK ->| | 2675 | | | |------ NOTIFY F20>| 2676 | | | | | 2677 | | | |F22 180 --->| | | | 2679 | |>F23 180 Ringing ------------------------------->| 2680 | | | | | 2681 | | | |<----- NOTIFY F24<| 2682 | | | | | 2683 | | | |>F25 200 OK ----->| 2684 | | |<- NOTIFY F26<| | 2685 | | | | | 2686 | | |>F27 200 OK ->| | 2687 | | | |------ NOTIFY F28>| 2688 | | | | | 2689 | | | |F30 200 OK ->| | | | 2691 | |>F31 200 OK ------------------------------------>| 2692 | | | | | 2693 | | | |<----- NOTIFY F32<| 2694 | | | | | 2695 | | | |>F33 200 OK ----->| 2696 | | | | | 2697 | |<--------------------------------------- ACK F34<| 2698 |<---- ACK F35<| | | | 2699 | | | | | 2700 |<================= Both way RTP established ===================>| 2701 | | | | | 2702 | | |<- NOTIFY F36<| | 2703 | | | | | 2704 | | |>F37 200 OK ->| | 2705 | | | |------ NOTIFY F38>| 2706 | | | | | 2707 | | | || 2725 | | | | | 2726 | |<------------------------------(hold) INVITE F22<| 2727 |<- INVITE F23<| | | | 2728 | | | | | 2729 |>F24 200 OK ->| | | | 2730 | |>F25 200 OK ------------------------------------>| 2731 | | | | | 2732 | |<--------------------------------------- ACK F26<| 2733 |<---- ACK F27<| | | | 2734 | | | | | 2735 | |< - - - - - - - - - - - - - ->| | 2736 | | | | | 2737 | | |<- NOTIFY F28<| | 2738 | | | | | 2739 | | |>F29 200 OK ->| | 2740 | | | |>F30 NOTIFY ----->| 2741 | | | | | 2742 | | | |<----- 200 OK F31<| 2743 | | | | | 2744 | | Alice decides to pick up the call | 2745 | | | | | 2746 | | |>F32 PUBLISH->| | 2747 | | | | | 2748 | | |<- 200 OK F33<| | 2749 | | | | | 2750 | | |<- NOTIFY F34<| | 2751 | | | | | 2752 | | |>F35 200 OK ->| | 2753 | | | |>F36 NOTIFY ----->| 2754 | | | | | 2755 | | | |<----- 200 OK F37<| 2756 |>F38 BYE ---->| | | | 2757 | |>F39 BYE --------------------------------------->| 2758 | | | | | 2759 | |<------------------------------------ OK 200 F40<| 2760 |<- 200 OK F41<| | | | 2761 | |<-- INVITE F42<| | | 2762 |<- INVITE F43<|(w/ Replaces) | | | 2763 |( w/ Replaces)| | | | 2764 | | | | | 2765 |>F44 481 ---->| | | | 2766 | |>F45 481 ----->| | | 2767 |<---- ACK F46<| | | | 2768 | |<----- ACK F47<| | | 2769 | | |>F48 PUBLISH->| | 2770 | | | | | 2771 | | |<- 200 OK F49<| | 2772 | | | | | 2773 | | |<- NOTIFY F50<| | 2774 | | | | | 2775 | | |>F51 200 OK ->| | 2776 | | | |>F52 NOTIFY ----->| 2777 | | | | | 2778 | | | |<----- 200 OK F53<| 2780 Figure 14. 2782 F48 Alice ----> Appearance Agent 2784 PUBLISH sip:HelpDesk@example.com SIP/2.0 2785 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A 2786 From: ;tag=44150CC6-A7B7919D 2787 To: ;tag=428765950880801 2788 CSeq: 11 PUBLISH 2789 Call-ID: 87837Fkw87asfds 2790 Contact: 2791 Event: dialog;shared 2792 Max-Forwards: 70 2793 Content-Type: application/dialog-info+xml 2794 Content-Length: ... 2796 2797 2802 2805 1 2806 false 2807 2811 terminated 2812 2813 2814 2815 2816 2817 2818 2819 2820 2822 11.15. Appearance Seizure Incoming/Outgoing Contention Race Condition 2824 Alice tries to seize appearance 2 at the same time appearance 2 is 2825 allocated to an incoming call. The Appearance Agent resolves the 2826 conflict by sending a 409 Conflict to Alice. After the NOTIFY F6, 2827 Alice learns that the incoming call is using appearance 2. Alice 2828 republishes for appearance 3, which is accepted. Note that this 2829 example shows the INVITE being received before the NOTIFY from the 2830 Appearance Agent. 2832 Carol Proxy Alice Appearance Agent Bob 2833 | | | | | 2834 |>-- INVITE F1>| | | | 2835 | |< - - - - - - - - - - - - - ->| | 2836 | | | | | 2837 | | |>F2 PUBLISH ->| | 2838 | | | (appearance=2) | 2839 | | | | | 2840 | |>F3 INVITE (appearance=2) ---------------------->| 2841 | | | | | 2842 | |>F4 INVITE | | | 2843 | |(appearance=2)>| | | 2844 | | |<---- F5 409 <| | 2845 | | | | | 2846 | | |<-- NOTIFY F6<| | 2847 | | | | | 2848 | | |>F7 200 OK -->| | 2849 | | | |------- NOTIFY F8>| 2850 | | | | | 2851 | | | |F10 PUBLISH->| | 2854 | | | (appearance=3) | 2855 | | | | | 2856 | | |< F11 200 OK <| | 2857 | | | | | 2858 | | |<- NOTIFY F12<| | 2859 | | | | | 2860 | |>F13 200 OK ->| | 2861 Dave | | |------ NOTIFY F14>| 2862 | | | | | 2863 | | | |F17 100 ----->| | | 2867 |<- INVITE F18<| | | | 2869 Figure 15. 2871 12. Security Considerations 2873 Since multiple line appearance features are implemented using 2874 semantics provided by [RFC3261], Event Package for Dialog State as 2875 define in , and Event Notification [I-D.ietf-sipcore-rfc3265bis], 2876 [RFC3903], security considerations in these documents apply to this 2877 draft as well. 2879 NOTIFY or PUBLISH message bodies that provide the dialog state 2880 information and the dialog identifiers MAY be encrypted end-to-end 2881 using the standard mechanisms. All SUBSCRIBES between the UA's and 2882 the Appearance Agent MUST be authenticated. 2884 13. IANA Considerations 2886 This section registers the SIP event package parameter 'shared', the 2887 SIP Alert-Info header field parameter "appearance" and the XML 2888 namespace extensions to the SIP Dialog Package. 2890 13.1. SIP Event Package Parameter: shared 2892 This specification defines a new event parameter 'shared' for the 2893 Dialog Package. When used in a NOTIFY, it indicates that the 2894 notifier supports the shared appearance feature. When used in a 2895 PUBLISH, it indicates that the publisher has explicit appearance 2896 information contained in the message body. If not present in a 2897 PUBLISH, the Appearance Agent MAY assign an appearance number to any 2898 new dialogs in the message body. 2900 13.2. URN Sub-Namespace Registration: sa-dialog-info 2902 This section registers a new XML namespace per the procedures 2903 in [RFC3688]. 2905 URI: urn:ietf:params:xml:ns:sa-dialog-info. 2907 Registrant Contact: IETF BLISS working group, , 2908 Alan Johnston 2910 XML: 2912 BEGIN 2913 2914 2916 2917 2918 2920 Shared Appearance Dialog Information Namespace 2921 2922 2923

Namespace for Shared Appearance Dialog Information

2924

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

2925

See 2926 RFCXXXX.

2927 2928 2929 END 2931 13.3. XML Schema Registration 2933 This section registers an XML schema per the procedures in 2934 [RFC3688]. 2936 URI: urn:ietf:params:xml:schesa:sa-dialog-info. 2938 Registrant Contact: IETF BLISS working group, , 2939 Alan Johnston 2941 The XML for this schema can be found in Section 6. 2943 14. Acknowledgements 2945 The following individuals were part of the shared appearance Design 2946 team and have provided input and text to the document (in 2947 alphabetical order): 2949 Martin Dolly, Andrew Hutton, Raj Jain, Fernando Lombardo, Derek 2950 MacDonald, Bill Mitchell, Michael Procter, Theo Zowzouvillys. 2952 Thanks to Chris Boulton for helping with the XML schema. 2954 Much of the material has been drawn from previous work by Mohsen 2955 Soroushnejad, Venkatesh Venkataramanan, Paul Pepper and Anil Kumar, 2956 who in turn received assistance from: 2958 Kent Fritz, John Weald, and Sunil Veluvali of Sylantro Systems, Steve 2959 Towlson, and Michael Procter of Citel Technologies, Rob Harder and 2960 Hong Chen of Polycom Inc, John Elwell, J D Smith of Siemens 2961 Communications, Dale R. Worley of Pingtel, Graeme Dollar of Yahoo 2962 Inc. 2964 Also thanks to Geoff Devine, Paul Kyzivat, Jerry Yin, John Elwell, 2965 Dan York, Spenser Dawkins, Martin Dolly, and Brett Tate for their 2966 comments. 2968 Thanks to Carolyn Beeton, Francois Audet, Andy Hutton, Tim Ross, Raji 2969 Chinnappa, and Harsh Mendiratta for their detailed review of the 2970 document. 2972 15. References 2974 15.1. Normative References 2976 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2977 Requirement Levels", BCP 14, RFC 2119, March 1997. 2979 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2980 A., Peterson, J., Sparks, R., Handley, M., and E. 2981 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2982 June 2002. 2984 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 2985 Method", RFC 3515, April 2003. 2987 [I-D.ietf-sipcore-rfc3265bis] 2988 Roach, A., "SIP-Specific Event Notification", 2989 draft-ietf-sipcore-rfc3265bis-02 (work in progress), 2990 August 2010. 2992 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 2993 for Event State Publication", RFC 3903, October 2004. 2995 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 2996 Protocol (SIP) "Replaces" Header", RFC 3891, 2997 September 2004. 2999 [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- 3000 Initiated Dialog Event Package for the Session Initiation 3001 Protocol (SIP)", RFC 4235, November 2005. 3003 [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol 3004 (SIP) "Join" Header", RFC 3911, October 2004. 3006 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 3007 "Indicating User Agent Capabilities in the Session 3008 Initiation Protocol (SIP)", RFC 3840, August 2004. 3010 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3011 January 2004. 3013 [I-D.ietf-salud-alert-info-urns] 3014 Liess, L., Alexeitsev, D., Jesske, R., Johnston, A., and 3015 A. Siddiqui, "Alert-Info URNs for the Session Initiation 3016 Protocol (SIP)", draft-ietf-salud-alert-info-urns-00 (work 3017 in progress), December 2010. 3019 15.2. Informative References 3021 [RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and 3022 K. Summers, "Session Initiation Protocol Service 3023 Examples", BCP 144, RFC 5359, October 2008. 3025 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol 3026 (SIP) Call Control - Conferencing for User Agents", 3027 BCP 119, RFC 4579, August 2006. 3029 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 3030 Package for Registrations", RFC 3680, March 2004. 3032 [I-D.worley-service-example] 3033 Worley, D., "Session Initiation Protocol Service Example 3034 -- Music on Hold", draft-worley-service-example-06 (work 3035 in progress), December 2010. 3037 Authors' Addresses 3039 Alan Johnston (editor) 3040 Avaya 3041 St. Louis, MO 63124 3043 Email: alan.b.johnston@gmail.com 3045 Mohsen Soroushnejad 3046 Sylantro Systems Corp 3048 Email: mohsen.soroush@sylantro.com 3050 Venkatesh Venkataramanan 3051 Sylantro Systems Corp 3053 Email: vvenkatar@gmail.com