idnits 2.17.1 draft-ietf-bliss-shared-appearances-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 12, 2010) is 5008 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-01 == Outdated reference: A later version (-03) exists of draft-liess-dispatch-alert-info-urns-02 == Outdated reference: A later version (-15) exists of draft-worley-service-example-05 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BLISS A. Johnston, Ed. 3 Internet-Draft Avaya 4 Intended status: Standards Track M. Soroushnejad 5 Expires: January 13, 2011 V. Venkataramanan 6 Sylantro Systems Corp 7 July 12, 2010 9 Shared Appearances of a Session Initiation Protocol (SIP) Address of 10 Record (AOR) 11 draft-ietf-bliss-shared-appearances-06 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 January 13, 2011. 46 Copyright Notice 48 Copyright (c) 2010 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.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . 16 94 6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 18 95 7. User Interface Considerations . . . . . . . . . . . . . . . . 20 96 7.1. Appearance Number Rendering . . . . . . . . . . . . . . . 20 97 7.1.1. Single Appearance UAs . . . . . . . . . . . . . . . . 20 98 7.1.2. Dual Appearance UAs . . . . . . . . . . . . . . . . . 20 99 7.1.3. Shared Appearance UAs with Fixed Appearance Number . . 20 100 7.1.4. Shared Appearance UAs with Variable Appearance 101 Number . . . . . . . . . . . . . . . . . . . . . . . . 21 102 7.2. Call State Rendering . . . . . . . . . . . . . . . . . . 21 103 8. Interop with non-Shared Appearance UAs . . . . . . . . . . . . 22 104 8.1. Appearance Assignment . . . . . . . . . . . . . . . . . . 22 105 8.2. Appearance Release . . . . . . . . . . . . . . . . . . . 22 106 8.3. UAs Supporting Dialog Events but Not Shared Appearance . 23 107 9. Provisioning Considerations . . . . . . . . . . . . . . . . . 23 108 10. Example Message Flows . . . . . . . . . . . . . . . . . . . . 23 109 10.1. Registration and Subscription . . . . . . . . . . . . . . 24 110 10.2. Appearance Selection for Incoming Call . . . . . . . . . 27 111 10.3. Outgoing Call without Appearance Seizure . . . . . . . . 31 112 10.4. Outgoing Call with Appearance Seizure . . . . . . . . . . 34 113 10.5. Outgoing Call without using an Appearance Number . . . . 38 114 10.6. Appearance Release . . . . . . . . . . . . . . . . . . . 40 115 10.7. Appearance Pickup . . . . . . . . . . . . . . . . . . . . 41 116 10.8. Calls between UAs within the Group . . . . . . . . . . . 45 117 10.9. Consultation Hold with Appearances . . . . . . . . . . . 48 118 10.10. Joining or Bridging an Appearance . . . . . . . . . . . . 50 119 10.11. Appearance Allocation - Loss of Appearance . . . . . . . 53 120 10.12. Appearance Seizure Contention Race Condition . . . . . . 54 121 10.13. Appearance Agent Subscription to UAs . . . . . . . . . . 55 122 10.14. Appearance Pickup Race Condition Failure . . . . . . . . 57 123 10.15. Appearance Seizure Incoming/Outgoing Contention Race 124 Condition . . . . . . . . . . . . . . . . . . . . . . . . 60 125 11. Incoming Appearance Assignment . . . . . . . . . . . . . . . . 61 126 12. Security Considerations . . . . . . . . . . . . . . . . . . . 62 127 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62 128 13.1. SIP Event Package Parameter: shared . . . . . . . . . . . 62 129 13.2. URN Sub-Namespace Registration: sa-dialog-info . . . . . 63 130 13.3. XML Schema Registration . . . . . . . . . . . . . . . . . 63 131 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 64 132 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64 133 15.1. Normative References . . . . . . . . . . . . . . . . . . 64 134 15.2. Informative References . . . . . . . . . . . . . . . . . 65 135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66 137 1. Introduction 139 The feature and functionality requirements for SIP user agents (UAs) 140 supporting business telephony applications differ greatly from basic 141 SIP user agents, both in terms of services and end user experience. 142 In addition to basic SIP support [RFC3261], many of the services in a 143 business environment require the support for SIP extensions such as 144 REFER [RFC3515], SUBSCRIBE/NOTIFY primitives 145 [I-D.ietf-sipcore-rfc3265bis] PUBLISH [RFC3903], the SIP Replaces 146 [RFC3891], and Join [RFC3911] header fields, etc. Many of the 147 popular business services have been documented in the SIP Service 148 Examples [RFC5359]. 150 This specification details a method for implementing a group 151 telephony feature known variously in telephony as Bridged Line 152 Appearance (BLA) or Multiple Line Appearances (MLA), one of the more 153 popular advanced features expected of SIP IP telephony devices in a 154 business environment. Other names for this feature include Shared 155 Call/Line Appearance (SCA), Shared Call Status and Multiple Call 156 Appearance (MCA). A variant of this feature is known as Single Line 157 Extension. 159 This document looks at how this feature can be implemented using 160 standard SIP [RFC3261] in conjunction with SIP events 161 [I-D.ietf-sipcore-rfc3265bis] and publication [RFC3903] for 162 exchanging status among user agents, and the SIP dialog state event 163 package [RFC4235] to exchange dialog state information to achieve the 164 same. Different approaches will be discussed including the use of 165 URI parameters, feature tags, and dialog package extensions along 166 with the strengths and weaknesses of the various approaches. 168 In traditional telephony, the line is physical. A common scenario in 169 telephony is for a number of business telephones to share a single or 170 a small number of lines. The sharing or appearance of these lines 171 between a number of phones is what gives this feature its name. A 172 common scenario in SIP is for a number of business telephones to 173 share a single or a small number of Address of Record (AOR) URIs. 175 In addition, an AOR can have multiple appearances on a single UA in 176 terms of the user interface. The appearance number relates to the 177 user interface for the telephone - typically each appearance of an 178 AOR has a visual display (lamp that can change color or blink or a 179 screen icon) and a button (used to select the appearance). The 180 telephony concept of line appearance is still relevant to SIP due to 181 the user interface considerations. It is important to keep the 182 appearance number construct because: 184 1. Human users are used to the concept and will expect it in 185 replacement systems (e.g. an overhead page announcement says "Joe 186 pickup line 3"). 187 2. It is a useful structure for user interface representation. 189 The purpose of the appearance number is to identify active calls to 190 facilitate sharing between users (e.g. passing a call from one user 191 to another). If a telephone has enough buttons/lamps, calls could be 192 presented on the nth button. If not, it may still be desirable to 193 present the call state, but the appearance number should be displayed 194 so that users know which call, for example, is on hold on which key. 196 In this document, except for the usage scenarios in the next section, 197 we will use the term "appearance" rather than "line appearance" since 198 SIP does not have the concept of lines. Note that this does not mean 199 that a conventional telephony user interface (lamps and buttons) must 200 be used - implementations may use another metaphor as long as the 201 appearance number is readily apparent to the user. Each AOR has a 202 separate appearance numbering space. As a result, a given UA user 203 interface may have multiple occurrences of the same appearance 204 number, but they will be for different AORs. 206 2. Conventions used in this document 208 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 209 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 210 document are to be interpreted as described in RFC-2119 [RFC2119] and 211 indicate requirement levels for compliant mechanisms. 213 3. Usage Scenarios 215 The following examples are common applications of the Shared 216 Appearances feature and are mentioned here as informative use cases. 217 All these example usages can be supported by the Shared Appearances 218 feature described in this document. The main differences relate to 219 the user interface considerations of the device. 221 3.1. Executive/Assistant Arrangement 223 The appearances on the executive's UA also appear on the assistant's 224 UA. The assistant may answer incoming calls to the executive and 225 then place the call on hold for the executive to pick up. The 226 assistant can always see the state of all calls on the executive's 227 UA. 229 3.2. Call Group 231 Users with similar business needs or tasks can be assigned to 232 specific groups and share an AOR. For example, an IT department 233 staff of five might answer a help line which has three appearances on 234 each phone in the IT work area. A call answered on one phone can be 235 put on hold and picked up on another phone. A shout or an IM to 236 another staff member can result in them taking over a call on a 237 particular appearance. Another phone can request to be added/joined/ 238 bridged to an existing appearance resulting in a conference call. 240 3.3. Single Line Extension 242 In this scenario, incoming calls are offered to a group of UAs. When 243 one answers, the other UAs are informed. If another UA in the group 244 seizes the line (i.e. goes off hook), it is immediately bridged or 245 joined in with the call. This mimics the way residential telephone 246 extensions usually operate. 248 3.4. Changing UAs 250 A user is on a call on one UA and wishes to change devices and 251 continue the call on another UA. They place the call on hold, note 252 the appearance number of the call, then walk to another UA. They are 253 able to identify the same appearance number on the other UA, pickup 254 the call, and continue the conversation. 256 4. Requirements and Implementation 258 The next section details the requirements and discusses the 259 implementation of the shared appearances of an AOR feature. 261 4.1. Requirements 263 The basic requirements of the shared appearance feature can be 264 summarized as follows: 266 REQ-1 Incoming calls to the AOR must be offered to a group of UAs and 267 can be answered by any of them. 269 REQ-2 Each UA in the group must be able to learn the call status of 270 the others in the group for the purpose of rendering this information 271 to the user. 273 REQ-3 A UA must be able to join (also called bridge or conference 274 together) or pick up (take) an active call of another UA in the group 275 in a secure way. 277 REQ-4 The mechanism should require the minimal amount of 278 configuration. UAs registering against the group AOR should be able 279 to participate in the appearance group without manual configuration 280 of group members. 282 REQ-5 The mechanism must scale for large numbers of appearances, n, 283 and large numbers of UAs, N, without introducing excessive messaging 284 traffic. 286 REQ-6 Each call or session (incoming or outgoing) must be assigned a 287 common "appearance" number from a managed pool administered for the 288 AOR group. Once the session has terminated, the appearance number is 289 released back into the pool and can be reused by another incoming or 290 outgoing session. 292 REQ-7 Each UA in the group must be able to learn the status of all 293 appearances of the group. 295 REQ-8 There must be mechanisms to resolve appearance contention among 296 the UAs in the group. 298 REQ-9 The mechanism must allow all UAs receiving an incoming session 299 request to utilize the same appearance number at the time of 300 alerting. 302 REQ-10 The mechanism must have a way of reconstructing appearance 303 state after an outage that does not result in excessive traffic and 304 processing. 306 REQ-11 The mechanism must have backwards compatibility such that a UA 307 which is unaware of the feature can still register against the group 308 AOR and make and receive calls. 310 REQ-12 The mechanism must not allow UAs outside the group to select, 311 seize or manipulate appearance numbers. 313 REQ-13 For privacy reasons, there must be a mechanism so that 314 appearance information is not leaked outside the group of UAs. (e.g. 315 "So who do you have on line 1?") 317 REQ-14 The mechanism must support a way for UAs to request 318 exclusivity on a line appearance. Exclusivity means that the UA 319 requesting it desires to have a private conversation with the 320 external party and other UAs must not be allowed to be joined or 321 taken. Exclusivity may be requested at the start of an incoming or 322 outgoing session or during the session. An exclusivity request may 323 be accepted or rejected by the entity providing the shared appearance 324 service. Therefore, the mechanism must provide a way of 325 communicating the result back to the requester UA. 327 REQ-15 The mechanism should support a way for a UA to seize a 328 particular appearance number for outgoing requests prior to sending 329 the actual request. This is often called seizure. 331 REQ-16 The mechanism should support a way for a UA to seize a 332 particular appearance number and also send the request at the same 333 time. This is needed when an automatic ringdown feature (a telephone 334 configured to immediately dial a phone number when it goes off hook) 335 is combined with shared appearances - in this case, seizing the line 336 is the same thing as dialing. 338 4.2. Implementation 340 Many of the requirements for this service can be met using standard 341 SIP mechanisms such as: 343 - A SIP Forking Proxy and Registrar/Location Service meets REQ-1. 345 - The SIP Dialog Package meets REQ-2. 347 - The SIP Replaces and Join header fields meets REQ-3. 349 - The use of a State Agent for the Dialog Package meets REQ-4 and 350 REQ-5. 352 REQ-6 suggests the need for an entity which manages the appearance 353 resource. Just as conferencing systems commonly have a single point 354 of control, known as a focus, a Shared Appearance group has a single 355 point of control of the appearance shared resource. This is defined 356 as an Appearance Agent for a group. While an Appearance Agent can be 357 part of a centralized server, it could also be co-resident in a 358 member User Agent who has taken on this functionality for a group. 359 The Appearance Agent knows or is able to determine the dialog state 360 of all members of the group. 362 While the appearance resource could be managed co-operatively by a 363 group of UAs without any central control, this is outside the scope 364 of this draft. It is also possible that the Appearance Agent logic 365 could be distributed in all UAs in the group. For example, rules 366 that govern assigning appearance numbers for incoming requests (e.g. 367 lowest available appearance number) and rules for contention handling 368 (e.g. when two UAs request the use of the same appearance number, 369 hash dialog identifiers and compare with the lowest hash winning) 370 would need to be defined and implemented. 372 To best meet REQ-9, the appearance number for an incoming INVITE 373 needs to be contained in the INVITE, in addition to being delivered 374 in the dialog package NOTIFY. Otherwise, if the NOTIFY is delayed or 375 lost, a UA in the group might receive an incoming INVITE but might 376 not know which appearance number to render during alerting. 378 This specification defines an extension parameter for the Alert-Info 379 header field in RFC 3261 to carry the appearance number: 381 Alert-Info: ;appearance=1 383 The next section discusses the operations used to implement parts of 384 the shared appearance feature. An analysis of other mechanisms has 385 been performed, with the mechanism described here best meeting the 386 requirements of Section 4.1. 388 1. A UA is configured with the AOR of a shared appearance group. It 389 registers against the AOR, then attempts a dialog state 390 subscription to the AOR. If the subscription fails, loops back 391 to itself, or returns an error, it knows there is no State Agent, 392 and hence no Appearance Agent and this feature is not 393 implemented. 394 2. If the subscription receives a 200 OK, the UA knows there is a 395 State Agent and that the feature is implemented. The UA then 396 follows the steps in this list. 397 3. Information learned about the dialog state of other UAs in the 398 group is rendered to the user. 399 4. Incoming calls are forked to all UAs in the group, and any may 400 answer. UAs receive the appearance number to use in rendering 401 the incoming call in a NOTIFY from the Appearance Agent and in 402 the INVITE itself. The UA will also receive a notification if 403 the call is answered by another UA in the group so this 404 information can be rendered to the user. 405 5. For outgoing calls, the operation depends on the implementation. 406 If the user seizes a particular appearance number for the call, 407 the UA publishes this information and waits for a 200 OK before 408 sending the INVITE. 409 6. For outgoing calls, if the user does not seize a particular 410 appearance or does not care, the INVITE can be sent immediately, 411 and the appearance number learned as the call progresses from a 412 notification from the Appearance Agent. 413 7. For outgoing calls, if the user does not wish to seize an 414 appearance (such as during a consultation call or if a UA is 415 fetching 'service media' such as music on hold 416 [I-D.worley-service-example]), the UA also publishes this prior 417 to sending the INVITE. 418 8. Established calls within the group may be joined (bridged) or 419 taken (picked) by another UA. Information in the dialog package 420 notifications can be used to construct Join or Replaces header 421 fields. Since the same appearance number is used for these types 422 of operations, this information is published prior to sending the 423 INVITE Join or INVITE Replaces. 424 9. In some cases, the Appearance Agent may not have full access to 425 the complete dialog state of some or all of the UAs in the group. 426 If this is the case, the Appearance Agent will subscribe to the 427 dialog state of individual UAs in the group to obtain this 428 information. Normal notifications will be sent every time the 429 dialog state changes, including calls placed, answered, placed on 430 and off hold, and hangups. 432 5. Normative Description 434 This section normatively describes the shared appearance feature 435 extensions. The following definitions are used throughout this 436 document: 438 Seizing: An appearance can be reserved prior to a call being placed 439 by seizing the appearance. An appearance can be seized by 440 communicating an artificial state of "trying" prior to actually 441 initiating a dialog, in order to appear as it was already initiating 442 a dialog. The appearance number is confirmed prior to sending the 443 INVITE. 445 Selecting(or Not-Seizing): An appearance is merely selected (i.e., 446 not seized) if there is no such communication of artificial state of 447 "trying" prior to initiating a dialog: i.e., the state is 448 communicated when the dialog is actually initiated. The appearance 449 number is learned after the INVITE is sent. This is a user interface 450 only issue. 452 5.1. Elements 454 A complete system to implement this feature consists of: 456 1. User Agents that support publications, subscriptions, and 457 notifications for the SIP dialog event package, and the shared 458 appearance dialog package extensions and behavior. 459 2. An Appearance Agent consisting of a State Agent for the dialog 460 event package that implements an Event State Compositor (ESC) and 461 the shared appearance dialog package extensions and behavior. 462 The Appearance Agent also has logic for assigning and releasing 463 appearance numbers, and resolving appearance number contention. 464 3. A forking proxy server that can communicate with the State Agent 465 4. A registrar that supports the registration event package. 467 The behavior of these elements is described normatively in the 468 following sections after the definitions of the dialog package 469 extensions. 471 5.2. Shared Appearance Dialog Package Extensions 473 This specification defines four new elements as extensions to the SIP 474 Dialog Event package [I-D.ietf-sipcore-rfc3265bis]. The schema is 475 defined in Section 6. The elements are , , 476 , and which are sub-elements of the 477 element. 479 5.2.1. The element 481 The element is used to convey the appearance number. 482 The appearance number is a positive integer. When sent in a 483 publication in state Trying to the Appearance Agent, it is used to 484 request an appearance number. When sent by the Appearance Agent, it 485 indicates that the appearance number is associated with a dialog. 487 5.2.2. The element 489 The element is a boolean used to indicate whether the UA 490 will accept Join or Replaces INVITEs for this dialog. For example, 491 some shared appearance systems only allow call pickup when the call 492 is on hold. In this case, the element should be used to 493 explicitly indicate this, rather than implicitly by the hold state. 495 It is important to note that this element is a hint. Although a UA 496 may set exclusive to true, the UA must still be ready to reject an 497 INVITE Join relating to this dialog. Also, an INVITE Replaces might 498 be sent to the non-shared appearance UA to take the call. For this 499 reason, a UA MAY also not report full dialog identifier information 500 to the Appearance Agent for calls set to exclusive. If these dialog 501 identifiers have already been shared with the Appearance Agent, the 502 UA could send an INVITE Replaces to change them and then not report 503 the new ones to the Appearance Agent. 505 If the proxy knows which dialogs are marked exclusive, the proxy MAY 506 enforce this exclusivity by rejecting INVITE Join and INVITE Replaces 507 requests containing those dialog identifiers with a 403 Forbidden 508 response. 510 Note that exclusivity has nothing to do with appearance number 511 selection or seizing - instead, it is about call control 512 operations that can be performed on a dialog. 514 5.2.3. The element 516 The element is used to convey dialog identifiers of 517 any other dialogs which are joined (mixed or bridged) with the 518 dialog. Only the UA which is performing the actual media mixing 519 should include this element in publications to the Appearance Agent. 520 Note that this element should still be used even when the Join header 521 field was not used to join the dialogs. For example, two separate 522 dialogs on a UA could be joined without any SIP call control 523 operations. Joined dialogs will share the same appearance number. 525 5.2.4. The element 527 The element is used to convey dialog identifiers of 528 any other dialogs which will be or have been replaced with this 529 dialog. For example, a UA in the group picking up a call on another 530 UA by sending an INVITE with Replaces would include this element for 531 the replacing dialog. Replaced dialogs will share the same 532 appearance number. 534 5.3. Shared Appearance User Agents 536 User Agents that support the Shared Appearance feature MUST support 537 the dialog state package [RFC4235] with the shared appearance 538 extensions and the 'shared' dialog event package parameter defined in 539 Section 11. 541 User Agents MUST support the dialog package extensions in Section 5.2 542 along with SUBSCRIBE and NOTIFY [I-D.ietf-sipcore-rfc3265bis] and 543 PUBLISH [RFC3903]. SUBSCRIBE, NOTIFY, and PUBLISH requests for the 544 dialog event package SHOULD include the 'shared' Event header field 545 parameter. 547 The presence of the 'shared' Event package parameter tells the 548 Appearance Agent that this UA supports this specification. 550 Upon initialization, the UA SHOULD subscribe to the dialog event 551 package of the AOR and refresh the subscription per the SIP Events 552 Framework. If the SUBSCRIBE request fails, loops back to itself, 553 then no Appearance Agent is present and this feature is not active 554 for this AOR. The UA MAY periodically retry the subscription to see 555 if conditions have changed. 557 User Agents which implement call pickup, joining and bridging MUST 558 support sending an INVITE with Replaces [RFC3891] or Join [RFC3911]. 559 All User Agents supporting INVITE MUST support receiving an INVITE 560 with a Replaces [RFC3891] or a Join [RFC3911] header field. 562 When publishing or notifying dialog package information, a UA MUST 563 include all dialog identification available at the time of 564 publication, with the exception that a UA may omit information if it 565 wishes to prevent other UAs from joining or picking up a call. 566 Dialog identification includes local and remote target URIs, call-id, 567 to-tag, and from-tag. When calls are placed on hold, the 568 "+sip.rendering=no" feature tag MUST be included in dialog package 569 notifications. 571 The accurate rendering of the idle/active/alerting/hold state of 572 other UAs in the group is an important part of the shared 573 appearance feature. 575 A UA MUST send dialog package PUBLISH requests in the following 576 situations: 578 1. When the user seizes a particular appearance number for an 579 outgoing call (i.e. seizing the appearance and going "off-hook", 580 if the UA's user interface uses this metaphor). 581 2. When the user has requested that an appearance number not be used 582 for an outgoing call (i.e. during a consultation call, a 'service 583 media' call such as for music on hold 584 [I-D.worley-service-example] or for a call not considered part of 585 the shared appearance group). 586 3. When the user has selected to join (or bridge) an existing call. 587 4. When the user has selected to replace (or take) an existing call. 589 In all these cases, the INVITE SHOULD NOT be sent until the 200 OK 590 response to the PUBLISH has been received, except for an emergency 591 call, when a UA MUST never wait for a confirmed seizure before 592 sending an INVITE. Instead, the emergency call MUST proceed 593 regardless of the status of PUBLISH transaction. 595 Note that when a UA seizes an appearance prior to establishment of a 596 dialog (#1 and #2 in above list), not all dialog information will be 597 available. In particular, when a UA publishes an attempt to seize an 598 appearance prior to knowing the destination URI, minimal or no dialog 599 information may be available. For example, in some cases, only the 600 local target URI for the call will be known and no dialog 601 information. If no dialog identification information is present in 602 the initial PUBLISH, the UA MUST PUBLISH again after receiving the 603 100 Trying response. 605 The first publication will cause the Appearance Agent to reserve 606 the appearance number for this UA. If the publication does not 607 have any dialog identifiers (e.g. Call-ID, or local tag) the 608 Appearance Agent cannot assign the appearance number to a 609 particular dialog of the UA until the second publication which 610 will contain some dialog identifiers. 612 This publication state SHOULD be refreshed during the early dialog 613 state or the Appearance Agent may reassign the appearance number. 614 Once the dialog has transitioned to the confirmed state, no 615 publication refreshes are necessary. 617 Appearance numbers are a shorthand label for active and pending 618 dialogs related to an AOR. Many of the features and services built 619 using this extension rely on the correct rendering of this 620 information to the human user. In addition, the group nature of the 621 feature means that the rendering must be similar between different 622 vendors and different models. Failure to do so will greatly reduce 623 the value and usefulness of these protocol extensions. The 624 appearances number for each active and pending dialog SHOULD be 625 explicitly or implicitly rendered to the user. The far end identity 626 of each dialog (e.g. the remote party identity) MUST NOT be rendered 627 in place of the appearance number. The state of each appearance 628 SHOULD also be rendered (idle, active, busy, joined, etc.). UAs can 629 tell that a set of dialogs are joined (bridged or mixed) together by 630 the presence of one or more elements containing other 631 SIP dialog identifiers. Appearance numbers of dialogs can be learned 632 by dialog package notifications containing the element 633 from the Appearance Agent or from the 'appearance' Alert-Info 634 parameter in an incoming INVITE. Should they conflict, the dialog 635 package notification takes precedence. 637 A UA that does not need to seize a particular appearance number (or 638 doesn't care) would just send an INVITE as normal to place an 639 outbound call. 641 A user may select an appearance number but then abandon placing a 642 call (go back on hook). In this case, the UA SHOULD free up the 643 appearance number by removing the event state with a PUBLISH as 644 described in [RFC3903]. 646 A UA wanting to place a call but not have an appearance number 647 assigned publishes before sending the INVITE without an 'appearance' 648 element but with the 'shared' event package parameter present. If 649 the Appearance Agent policy does not allow calls without an assigned 650 appearance number, a 409 Conflict response will be received, and the 651 UA will republish either selecting/seizing an appearance number or 652 send the INVITE without publishing, in which case the Appearance 653 Agent will assign one. 655 Note that if an Appearance Agent rejects calls without an 656 appearance number, certain operations such as consultation calls 657 and music on hold may be impacted. 659 When an INVITE is generated to attempt to bridge or take a call (i.e. 660 contains Join or Replaces with a dialog identifier of another dialog 661 in the shared appearance group), the appearance number of the joined 662 or replaced call SHOULD be published. The publication MUST contain 663 the appearance number of the dialog to be joined or replaced and the 664 dialog identifier in the 'joined-dialog' or 'replaced-dialog' 665 elements. 667 Note that this information is provided to the Appearance Agent so 668 that it can provide proper appearance assignment behavior. If the 669 INVITE Join or Replaces was sent without publishing first, the 670 Appearance Agent might assign a new appearance number to this 671 INVITE, which would be a mistake. With Join, the publication has 672 the 'joined-dialog' element to prevent the Appearance Agent from 673 generating a 409 Conflict response due to the reuse of an 674 appearance number. For Replaces, the purpose of the 'replaced- 675 dialog' is to prevent a race condition where the BYE could cause 676 the appearance number to be released when it should stay with the 677 replacing dialog. 679 A UA SHOULD register against the AOR only if it is likely the UA will 680 be answering incoming calls. If the UA is mainly going to be 681 monitoring the status of the shared appearance group calls and 682 picking or joining calls, the UA SHOULD only subscribe to the AOR and 683 not register against the AOR. 685 All subscribed UAs will received NOTIFYs of Trying state for 686 incoming INVITEs. 688 5.4. Appearance Agent 690 An Appearance Agent defined in this specification MUST implement a 691 dialog package state agent for the UAs registered against the AOR. 692 The Appearance Agent MUST support the appearance dialog package 693 extensions defined in Section 5.2. The Appearance Agent MUST support 694 publications and subscriptions for this event package. 696 The Appearance Agent MUST have a way of discovering the state of all 697 dialogs associated with the AOR. If this information is not 698 available from a call stateful proxy or B2BUA, the Appearance Agent 699 MAY use the registration event package [RFC3680] to learn of UAs 700 associated with the AOR and MAY subscribe to their dialog event 701 state. Also, an Appearance Agent MAY subscribe to a UAs dialog event 702 state in order to reconstruct state. As a result, the registrar MUST 703 support the registration event package. The Appearance Agent SHOULD 704 send dialog event state notifications whenever the following events 705 happen to UAs in the AOR group: 707 1. A call is received, placed, answered, or terminated. 708 2. A call is placed on or off hold. 709 3. A call is joined or replaced. 710 4. An appearance number is reserved or released. 712 The Appearance Agent MUST allocate an appearance number for all 713 incoming calls and send immediate notifications to the UAs subscribed 714 to the shared group AOR. The Appearance Agent MUST be able to 715 communicate with the forking proxy to learn about incoming calls and 716 also to pass the appearance number to the proxy to insert in the 717 Alert-Info header field. 719 Note that UAs need to be able to handle incoming INVITEs without 720 an appearance number assigned. This could be caused by a failure 721 of the Appearance Agent or other error condition. Although the 722 proper rendering of the INVITE may not be possible, this is better 723 than ignoring or failing the INVITE. 725 An Appearance Agent SHOULD assign an appearance number to an outgoing 726 dialog if a PUBLISH has not been received selecting/seizing a 727 particular appearance number. 729 Note that if the appearance group has appearance-unaware UAs 730 making calls, the Appearance Agent will still allocate appearance 731 numbers for INVITEs sent by those UAs. 733 An Appearance Agent receiving a PUBLISH with an appearance number 734 checks to make sure the publication is valid. An appearance number 735 can be assigned to only one dialog unless there is a 'joined-dialog' 736 or 'replaced-dialog' element indicating that the dialog will be/has 737 been replaced or joined. A 409 Conflict response is returned if the 738 chosen appearance number is invalid, and an immediate NOTIFY should 739 be sent to the UA containing full dialog event state. 741 An Appearance Agent receiving a PUBLISH without an appearance number 742 but with the 'shared' event package parameter present interprets this 743 as a request by the UA to not assign an appearance number. If the 744 Appearance Agent policy does not allow this, a 409 Conflict response 745 is returned. If policy does allow this, a 200 OK response is 746 returned and no appearance number is allocated. An Appearance Agent 747 does not have to share this dialog information with other UAs in the 748 group as the information will not be rendered by the other UAs. 750 The Appearance Agent allocates an appearance number to a dialog from 751 the time the appearance is requested via a PUBLISH or from the 752 receipt of an INVITE, to the time when the last dialog associated 753 with the appearance is terminated, including all dialogs which are 754 joined or replaced. During the early dialog state, the Appearance 755 Agent controls the rate of dialog state publication using the Expires 756 header field in 200 OK responses to PUBLISH requests. An interval of 757 3 minutes is RECOMMENDED. After the dialog associated with the 758 publication has been confirmed, the expiration of the publication 759 state has no effect on the appearance allocation. If the publication 760 contains no dialog state information, the Appearance Agent MUST 761 reserve the appearance number for the UA but can not assign the 762 appearance to any particular dialog of the UA. When the publication 763 state is updated with any dialog information, the appearance number 764 can then be assigned to the particular dialog. A UA which has been 765 allocated an appearance number using a PUBLISH MAY free up the 766 appearance number by removing the event state with a PUBLISH as 767 described in [RFC3903]. 769 During dynamic situations, such as during a call pickup or join 770 action, the Appearance Agent MAY choose to implement rate limiting to 771 reduce the amount of notification traffic. For example, an 772 Appearance Agent may choose not to generate immediate NOTIFYs upon 773 receipt of PUBLISHes. Instead, a single NOTIFY can convey the 774 effects of a number of PUBLISHes, thus reducing the NOTIFY traffic 775 within the group. 777 If an INVITE is sent by a member of the group using the shared AOR or 778 sent to the shared AOR and no appearance number is available, the 779 proxy MAY reject the INVITE with a 403 Forbidden response code. 781 Appearance numbers are only used for dialogs in which one UA 782 associated with the group AOR is a participant. If an incoming 783 INVITE to the group AOR is forwarded to another AOR, the appearance 784 number is immediately freed up and can be assigned to another dialog. 786 6. XML Schema Definition 788 The 'appearance', 'joined-dialog', 'replaced-dialog', and 'exclusive' 789 elements are defined within a new XML namespace URI. This namespace 790 is "urn:ietf:params:xml:ns:sa-dialog-info". The schema for these 791 elements is: 793 794 800 802 803 805 807 809 810 812 814 815 817 819 821 822 824 825 826 827 829 830 831 832 833 835 7. User Interface Considerations 837 The "appearance number" allocated to a call is an important concept 838 that enables calls to be handled by multiple devices with 839 heterogeneous user interfaces in a manner that still allows users to 840 see a consistent model. Careful treatment of the appearance number 841 is essential to meet the expectations of the users. Also, rendering 842 the correct call/appearance state to users is also important. 844 7.1. Appearance Number Rendering 846 Since different UAs have different user interface capabilities, it is 847 usual to find that some UAs have restrictions that others do not. 848 Perfect interoperability across all UAs is clearly not possible, but 849 by careful design, interoperability up to the limits of each UA can 850 be achieved. 852 The following guidelines suggest how the appearance number should be 853 handled in three typical user interface implementations. 855 7.1.1. Single Appearance UAs 857 These devices are constrained by only having the capability of 858 displaying status indications for a single appearance. Despite this, 859 it is important that devices of this type do not ignore the 860 appearance number. The UA should still send messages annotated with 861 an appropriate appearance number (i.e. "0"). Any call indications 862 for appearances other than for number "0" should be rejected with a 863 486 or 480 response. 865 7.1.2. Dual Appearance UAs 867 These devices are essentially single appearance phones that implement 868 call waiting. They have a very simple user interface that allows 869 them to switch between two appearances (toggle or flash hook) and 870 perhaps audible tones to indicate the status of the other appearance. 872 7.1.3. Shared Appearance UAs with Fixed Appearance Number 874 This UA is the typical 'business-class' hard-phone. A number of 875 appearances are typically configured statically and labeled on 876 buttons, and calls may be managed using these configured appearances. 877 Any calls outside this range should be ignored, and not mapped to a 878 free button. Users of these devices often seize specific appearance 879 numbers for outgoing calls, and the UA will need to seize the 880 appearance number and wait for confirmation from the Appearance Agent 881 before proceeding with calls. 883 7.1.4. Shared Appearance UAs with Variable Appearance Number 885 This UA is typically a soft-phone or graphically rich user interface 886 hard-phone. In these cases, even the idea of an appearance index may 887 seem unnecessary. However, for these phones to be able to interwork 888 successfully with other phone types, it is important that they still 889 use the appearance index to govern the order of appearance of calls 890 in progress. No specific guidance on presentation is given except 891 that the order should be consistent. These devices can typically 892 make calls without waiting for confirmation from the Appearance Agent 893 on the appearance number. 895 The problems faced by each style of user interface are readily seen 896 in this example: 898 1. A call arrives at the shared appearance group, and is assigned an 899 appearance number of 0. All UAs should be able to render to the 900 user the arrival of this call. 901 2. Another call arrives at the shared appearance group, and is 902 assigned an appearance number of 1. The single appearance UA 903 should not present this call to the user. Other user agents 904 should have no problems presenting this call distinctly from the 905 first call. 906 3. The first call clears, releasing appearance number "0". The 907 single appearance UA should now be indicating no calls since it 908 is unable to manage calls other than on the first appearance. 909 Both shared appearance UAs should clearly show that appearance 910 number 0 is now free, but that there is still a call on 911 appearance number 1. 912 4. A third call arrives, and is assigned the appearance number of 0. 913 All UAs should be able to render the arrival of this new call to 914 the user. Multiple appearance UAs should continue to indicate 915 the presence of the second call, and should also ensure that the 916 presentation order is related to the appearance number and not 917 the order of call arrival. 919 7.2. Call State Rendering 921 UAs that implement the shared appearance feature typically have a 922 user interface that provides the state of other appearances in the 923 group. As dialog state NOTIFYs from the Appearance Agent are 924 processed, this information can be rendered. Even the simplest user 925 interface typically has three states: idle, active, and hold. The 926 idle state, usually indicated by lamp off, is indicated for an 927 appearance when the appearance number is not associated with any 928 dialogs, as reported by the Appearance Agent. The active state, 929 usually indicated by a lamp on, is indicated by an appearance number 930 being associated with at least one dialog, as reported by the 931 Appearance Agent. The hold state, often indicated by a blinking 932 lamp, means the call state from the perspective of the UA in the 933 shared appearance group is hold. This can be determined by the 934 presence of the "sip+rendering=no" feature tag [RFC3840] with the 935 local target URI. Note that the hold state of the remote target URI 936 is not relevant to this display. For joined dialogs, the state is 937 rendered as hold only if all local target URIs are indicated with the 938 "sip+rendering=no" feature tag. 940 8. Interop with non-Shared Appearance UAs 942 It is desirable to allow a basic UA that does not directly support 943 shared appearance to be part of a shared appearance group. To 944 support this the Proxy must collaborate with the Appearance Agent. 945 This is not required in the basic shared appearance architecture, 946 consequently shared appearance interop with non-shared appearance UAs 947 will not be available in all shared appearance deployments. 949 First, a UA which does not support dialog events or the shared 950 appearance feature will be discussed. Then, a UA which does support 951 dialog events but not the shared appearance feature will be 952 discussed. 954 8.1. Appearance Assignment 956 A UA that has no knowledge of appearances must will only have 957 appearance numbers for outgoing calls if assigned by the Appearance 958 Agent. If the non-shared appearance UA does not support Join or 959 Replaces, all dialogs could be marked "exclusive" to indicate that 960 these options are not available. 962 8.2. Appearance Release 964 In all cases the Appearance Agent must be aware of dialog lifetime to 965 release appearances back into the group. 967 It is also desirable that any dialog state changes (such as hold, 968 etc) be made available to other UAs in the group through the Dialog 969 Event Package. If the Appearance Agent includes a proxy which 970 Record-Routes for dialogs from the non-shared appearance aware UA, 971 the Appearance Agent will know about the state of dialogs including 972 hold, etc. This information could be determined from inspection of 973 INVITE and re-INVITE messages and added to the dialog information 974 conveyed to other UAs. 976 8.3. UAs Supporting Dialog Events but Not Shared Appearance 978 Interoperability with UAs which support dialog events but not the 979 shared appearance feature is more straightforward. As before, all 980 appearance number assignment must be done by the Appearance Agent. 981 The Appearance Agent can include appearance information in NOTIFYs - 982 this UA will simply ignore this extra information. This type of UA 983 will ignore appearance number limitations and may attempt to Join or 984 Replace dialogs marked exclusive. As a result, the Proxy or UAs may 985 need to reject such requests. 987 9. Provisioning Considerations 989 UAs can automatically discover if this feature is active for an AOR 990 by sending a SUBSCRIBE to the AOR, so no provisioning for this is 991 needed. 993 The registrar will need to be provisioned to accept either first or 994 third party registrations for the shared AOR. First party 995 registration means the To and From URIs in the REGISTER request are 996 the shared AOR URI. Third party registration means the To URI is the 997 shared AOR URI and the From URI is a different AOR, perhaps that of 998 the individual user. Either the credentials of the shared AOR or the 999 user MUST be accepted by the registrar and the Appearance Agent, 1000 depending on the authorization policy in place for the domain. 1002 If the Appearance Agent needs to subscribe to the dialog state of the 1003 UAs, then the Appearance Agent and the UAs need to be provisioned 1004 with credentials so the UAs can authenticate the Appearance Agent. 1006 In some cases, UAs in the shared appearance group might have a UI 1007 limitation on the number of appearances that can be rendered. 1008 Typically this will be hard phones with buttons/lamps instead of more 1009 flexible UIs. In this case, it can be useful for the Appearance 1010 Agent to know this maximum number. This can allow the Appearance 1011 Agent to apply policy when this limit is reached, e.g. deny a call. 1012 However, this mechanism does not provide any way to discover this by 1013 protocol means. 1015 10. Example Message Flows 1017 The next section shows call flow and message examples. The flows and 1018 descriptions are non-normative. Note that in these examples, all 1019 INVITEs sent by a UA in the group will be From the shared AOR 1020 (sip:HelpDesk@example.com in this case), and all INVITES sent to the 1021 group will have a Request-URI of the shared AOR. Any other requests 1022 would not apply to this feature and would be handled using normal SIP 1023 mechanisms. 1025 Note that the first twelve examples assume the Appearance Agent is 1026 aware of dialog state events. Example 10.13 shows the case where 1027 this is not the case and as a result the Appearance Agent initiates a 1028 subscription to users of the shared AOR. Any of the other call flow 1029 examples could have shown this mode of operation as it is equally 1030 valid. 1032 10.1. Registration and Subscription 1034 Bob and Alice are in an appearance group identified by the shared 1035 appearance AOR sip:HelpDesk@example.com. Bob REGISTERs using contact 1036 sip:bob@ua2.example.com. Alice REGISTERs with contact 1037 sip:alice@ua1.example.com. 1039 User Agents for Alice and Bob subscribe to the dialog package for the 1040 appearance AOR and publish dialog state to the Appearance Agent. 1041 Message exchanges between the Registrar, Appearance Agent, Alice, and 1042 Bob are shown below. The call flow examples below do not show the 1043 authentication of subscriptions, publications, and notifications. It 1044 should be noted that for security purposes, all subscriptions must be 1045 authorized before the same is accepted. 1047 Also note that registrations and subscriptions must all be refreshed 1048 by Alice at intervals determined by the expiration intervals returned 1049 by the Registrar or Appearance Agent. 1051 Registrar Appearance Agent Alice Bob 1052 | | | | 1053 | | | | 1054 |<--------------------------- REGISTER F1<| | 1055 | | | | 1056 |>F2 200 OK ----------------------------->| | 1057 | | | | 1058 | |<----- SUBSCRIBE F3<| | 1059 | | | | 1060 | |>F4 200 OK -------->| | 1061 | | | | 1062 | |>F5 NOTIFY -------->| | 1063 | | | | 1064 | |<-------- 200 OK F6<| | 1065 | | | | 1066 |<-------------------------------------------- REGISTER F7<| 1067 | | | | 1068 |>F8 200 OK ---------------------------------------------->| 1069 | | | | 1070 | |<---------------------- SUBSCRIBE F9<| 1071 | | | | 1072 | |>F10 200 OK ------------------------>| 1073 | | | | 1074 | |>F11 NOTIFY ------------------------>| 1075 | | | | 1076 | |<------------------------ 200 OK F12<| 1077 | | | | 1079 Figure 1. 1081 F1-F2: Alice registers AOR with 1082 contact: 1084 F1 Alice ----> Registrar 1086 REGISTER sip:registrar.example.com SIP/2.0 1087 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09 1088 From: ;tag=CDF9A668-909E2BDD 1089 To: 1090 CSeq: 2 REGISTER 1091 Call-ID: d3281184-518783de-cc23d6bb 1092 Contact: 1093 Max-Forwards: 70 1094 Expires: 3600 1095 Content-Length: 0 1097 F2 Registrar ----> Alice 1099 SIP/2.0 200 OK 1100 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKfbf176ef7F1D5FA2 1101 CSeq: 2 REGISTER 1102 Call-ID: d3281184-518783de-cc23d6bb 1103 From: ;tag=CDF9A668-909E2BDD 1104 To: ;tag=1664573879820199 1105 Contact: 1106 Expires: 3600 1107 Content-Length: 0 1109 F3 to F6: Alice also subscribes to the events associated with the 1110 Appearance AOR. Appearance Agent notifies Alice of the status. 1112 F3 Alice ----> Appearance Agent 1114 SUBSCRIBE sip:HelpDesk@example.com SIP/2.0 1115 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A 1116 From: ;tag=925A3CAD-CEBB276E 1117 To: 1118 CSeq: 91 SUBSCRIBE 1119 Call-ID: ef4704d9-bb68aa0b-474c9d94 1120 Contact: 1121 Event: dialog;shared 1122 Accept: application/dialog-info+xml 1123 Max-Forwards: 70 1124 Expires: 3700 1125 Content-Length: 0 1127 F4 Appearance Agent ----> Alice 1129 SIP/2.0 200 OK 1130 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A 1131 CSeq: 91 SUBSCRIBE 1132 Call-ID: ef4704d9-bb68aa0b-474c9d94 1133 From: ;tag=925A3CAD-CEBB276E 1134 To: ;tag=1636248422222257 1135 Allow-Events: dialog 1136 Expires: 3700 1137 Contact: 1138 Content-Length: 0 1140 F5 Appearance Agent ----> Alice 1142 NOTIFY sip:alice@ua1.example.com SIP/2.0 1143 From: ;tag=1636248422222257 1144 To: ;tag=925A3CAD-CEBB276E 1145 Call-ID: ef4704d9-bb68aa0b-474c9d94 1146 CSeq: 232 NOTIFY 1147 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1846 1148 Max-Forwards: 70 1149 Content-Type: application/dialog-info+xml 1150 Event: dialog;shared 1151 Subscription-State: active 1152 Contact: 1153 Content-Length: ... 1155 1156 1160 1161 F6 Alice ----> Appearance Agent 1163 SIP/2.0 200 OK 1164 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1846 1165 From: ;tag=1636248422222257 1166 To: ;tag=925A3CAD-CEBB276E 1167 CSeq: 232 NOTIFY 1168 Call-ID: ef4704d9-bb68aa0b-474c9d94 1169 Contact: 1170 Event: dialog;shared 1171 Content-Length: 0 1173 F7 Bob ----> Registrar 1175 REGISTER sip:registrar.example.com SIP/2.0 1176 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4b53b54d87B 1177 From: ;tag=34831131 1178 To: 1179 CSeq: 72 REGISTER 1180 Call-ID: 139490230230249348 1181 Contact: 1182 Max-Forwards: 70 1183 Expires: 3600 1184 Content-Length: 0 1186 F8 Registrar ----> Bob 1188 SIP/2.0 200 OK 1189 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4b53b54d87B 1190 From: ;tag=34831131 1191 To: ;tag=fkwlwqi1 1192 CSeq: 72 REGISTER 1193 Call-ID: 139490230230249348 1194 Contact: ;expires=3200 1195 Contact: ;expires=3600 1196 Content-Length: 0 1198 10.2. Appearance Selection for Incoming Call 1200 In the call flow below Bob and Alice are in an appearance group. 1201 Carol places a call to the appearance group AOR. The Appearance 1202 Agent sends NOTIFYs to Alice and Bob telling them what appearance the 1203 call is using. Both Alice and Bob's devices are alerted of the 1204 incoming call. Bob answers the call. 1206 Note that it is possible that both Alice and Bob answer the call and 1207 send 200 OK responses to Carol. It is up to Carol to resolve this 1208 situation. Typically, Carol will send ACKs to both 200 OKs but send 1209 a BYE to terminate one of the dialogs. As a result, either Alice or 1210 Bob will receive the BYE and publish that their dialog is over. 1211 However, if Carol answers both Alice and Bob and keeps both dialogs 1212 active, then the Appearance Agent will need to resolve the situation 1213 by moving either Alice or Bob's dialog to a different appearance. 1215 All NOTIFY messages in the call flow below carry dialog events and 1216 only dialog states are mentioned for simplicity. For brevity, the 1217 details of some messages are not shown below. Note that the order of 1218 F2 - F5 and F7 - F8 could be reversed. 1220 Forking Appearance 1221 Carol Proxy Agent Alice Bob 1222 | | | | | 1223 |>F1 INVITE >| | | | 1224 | |< - - - - - >| | | 1225 | | |>F2 NOTIFY ----------->| 1226 | | | | | 1227 | | |F4 NOTIFY ->| | 1230 | | | | | 1231 | | |<-200 OK F5-<| | 1232 |<- 100 F6 -<| | | | 1233 | |>F7 INVITE (appearance=1) ---------->| 1234 | | | | | 1235 | |>F8 INVITE (appearance=1) >| | 1236 | | | | | 1237 | |<-------------------- Ringing 180 F9<| 1238 |< 180 F10 -<| | | | 1239 | |<--------- 180 Ringing F11<| | 1240 |< 180 F12 -<| | | | 1241 | | | | | 1242 | |<------------------------ 200 OK F13<| 1243 |< 200 F14 -<| | | | 1244 | | | | | 1245 | |>F15 CANCEL -------------->| | 1246 | | | | | 1247 | |<-------------- 200 OK F16<| | 1248 | | | | | 1249 | |F18 ACK ----------------->| | 1252 |>F19 ACK -->| | | | 1253 | |>F20 ACK --------------------------->| 1254 | | | | | 1255 |<=============Both way RTP established===========>| 1256 | | | | | 1257 | |< - - - - - >| | | 1258 | | | | | 1259 | | |>F21 NOTIFY >| | 1260 | | | | | 1261 | | |<- 200 F22 -<| | 1262 | | | | | 1263 | | |>F23 NOTIFY ---------->| 1264 | | | | | 1265 | | | Alice 1272 NOTIFY sip:alice@ua1.example.com SIP/2.0 1273 From: ;tag=151702541050937 1274 To: ;tag=18433323-C3D237CE 1275 Call-ID: 1e361d2f-a9f51109-bafe31d4 1276 CSeq: 12 NOTIFY 1277 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1403 1278 Max-Forwards: 70 1279 Content-Type: application/dialog-info+xml 1280 Event: dialog;shared 1281 Subscription-State: active 1282 Contact: 1283 Content-Length: ... 1285 1286 1291 1295 1 1296 trying 1297 1298 sip:carol@ua.example.com 1300 1301 1302 1304 F7 Proxy ----> Bob 1306 INVITE sip:bob@ua2.example.com SIP/2.0 1307 Via: SIP/2.0/UDP ua3.example.com;branch=z9hG4bK4324ea 1308 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK38432ji 1309 From: ;tag=44BAD75D-E3128D42 1310 To: 1311 CSeq: 106 INVITE 1312 Call-ID: 14-1541707345 1313 Contact: 1314 Max-Forwards: 69 1315 Alert-Info: ;appearance=1 1316 Content-Type: application/sdp 1317 Content-Length: ... 1319 v=0 1320 o=- 1102980499 1102980499 IN IP4 ua3.example.com 1321 s= 1322 c=IN IP4 ua3.example.com 1323 t=0 0 1324 m=audio 2238 RTP/AVP 0 8 101 1325 a=rtpmap:0 PCMU/8000 1326 a=rtpmap:8 PCMA/8000 1327 a=rtpmap:101 telephone-event/8000 1329 F21 Appearance Agent ----> Alice 1331 NOTIFY sip:alice@ua1.example.com SIP/2.0 1332 From: ;tag=151702541050937 1333 To: ;tag=18433323-C3D237CE 1334 Call-ID: 1e361d2f-a9f51109-bafe31d4 1335 CSeq: 12 NOTIFY 1336 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1403 1337 Max-Forwards: 70 1338 Content-Type: application/dialog-info+xml 1339 Event: dialog;shared 1340 Subscription-State: active 1341 Contact: 1342 Content-Length: ... 1344 1345 1350 1355 1 1356 confirmed 1357 1358 sip:bob@ua2.example.com 1359 1360 1361 sip:carol@ua.example.com 1362 1363 1364 1366 10.3. Outgoing Call without Appearance Seizure 1368 In this scenario, Bob's UA places a call without first selecting/ 1369 seizing an appearance number. After Bob sends the INVITE, the 1370 appearance assigns an appearance number for it and notifies both 1371 Alice and Bob. 1373 Carol Proxy Alice Appearance Agent Bob 1374 | | | | | 1375 | | | | | 1376 | |<------------------------------------- INVITE F1<| 1377 | | | | | 1378 | |>F2 100 Trying --------------------------------->| 1379 |<-- INVITE F3<| | | | 1380 | |< - - - - - - - - - - - - - ->| | 1381 | | | | | 1382 | | |<-- NOTIFY F4<| | 1383 | | | | | 1384 | | |>F5 200 OK -->| | 1385 | | | |------- NOTIFY F6>| 1386 | | | | | 1387 | | | |F8 180 ---->| | | | 1389 | |>F9 180 Ringing -------------------------------->| 1390 | | | | | 1391 | |< - - - - - - - - - - - - - ->| | 1392 | | | | | 1393 | | |<- NOTIFY F10<| | 1394 | | | | | 1395 | | |>F11 200 OK ->| | 1396 | | | |------ NOTIFY F12>| 1397 | | | | | 1398 | | | |F14 200 OK ->| | | | 1400 | |>F15 200 OK ------------------------------------>| 1401 | | | | | 1402 | |<--------------------------------------- ACK F16<| 1403 |<---- ACK F17<| | | | 1404 | | | | | 1405 |<================= Both way RTP established ===================>| 1406 | | | | | 1407 | |< - - - - - - - - - - - - - ->| | 1408 | | | | | 1409 | | |<- NOTIFY F18<| | 1410 | | | | | 1411 | | |>F19 200 OK ->| | 1412 | | | |------ NOTIFY F20>| 1413 | | | | | 1414 | | | | Proxy 1421 INVITE sip:carol@example.com SIP/2.0 1422 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK98c87c52123A08BF 1423 From: ;tag=15A3DE7C-9283203B 1424 To: 1425 CSeq: 1 INVITE 1426 Call-ID: f3b3cbd0-a2c5775e-5df9f8d5 1427 Contact: 1428 Max-Forwards: 70 1429 Content-Type: application/sdp 1430 Content-Length: 223 1432 v=0 1433 o=- 1102980499 1102980499 IN IP4 ua2.example.com 1434 s=IP SIP UA 1435 c=IN IP4 ua2.example.com 1436 t=0 0 1437 a=sendrecv 1438 m=audio 2236 RTP/AVP 0 8 101 1439 a=rtpmap:0 PCMU/8000 1440 a=rtpmap:8 PCMA/8000 1441 a=rtpmap:101 telephone-event/8000 1443 F4 Appearance Agent ----> Alice 1445 NOTIFY sip:alice@ua1.example.com SIP/2.0 1446 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK81d84f62 1447 From: ;tag=1636248422222257 1448 To: ;tag=925A3CAD-CEBB276E 1449 Call-ID: ef4704d9-bb68aa0b-474c9d94 1450 CSeq: 233 NOTIFY 1451 Max-Forwards: 70 1452 Content-Type: application/dialog-info+xml 1453 Event: dialog;shared 1454 Subscription-State: active 1455 Contact: 1456 Content-Length: ... 1458 1459 1464 1467 1 1468 false 1469 trying 1470 1471 1472 1473 1474 1475 1477 F6 Appearance Agent ----> Bob 1479 NOTIFY sip:bob@ua1.example.com SIP/2.0 1480 From: ;tag=497585728578386 1481 To: ;tag=633618CF-B9C2EDA4 1482 Call-ID: a7d559db-d6d7dcad-311c9e3a 1483 CSeq: 7 NOTIFY 1484 Via: SIP/2.0/UDP appearanceagent.example.com 1485 ;branch=z9hG4bK1711759878512309 1486 Max-Forwards: 70 1487 Content-Type: application/dialog-info+xml 1488 Event: dialog;shared 1489 Subscription-State: active 1490 Contact: 1491 Content-Length: ... 1493 1494 1499 1502 1 1503 false 1504 trying 1505 1506 1507 1508 1509 1510 1512 10.4. Outgoing Call with Appearance Seizure 1514 In this scenario, Bob's UA sends out a dialog event PUBLISH with 1515 state (trying) selecting/seizing an appearance number before sending 1516 the INVITE. After receiving the 200 OK from the Appearance Agent 1517 confirming the appearance number, Bob's UA sends the INVITE to Carol 1518 and establishes a session. For brevity, details of some of the 1519 messages are not included in the message flows. 1521 Carol Proxy Alice Appearance Agent Bob 1522 | | | | | 1523 | | | |<----- PUBLISH F1<| 1524 | | | | | 1525 | | | |>F2 200 OK ------>| 1526 | | | | | 1527 | | |<-- NOTIFY F3<| | 1528 | | | | | 1529 | | |>F4 200 OK -->| | 1530 | | | |------- NOTIFY F5>| 1531 | | | | | 1532 | | | |F8 100 Trying --------------------------------->| 1537 |<-- INVITE F9<| | | | 1538 | | | |<---- PUBLISH F10<| 1539 | | | | | 1540 | | | |>F11 200 OK ----->| 1541 | | | | | 1542 |>F12 180 --->| | | | 1543 | |>F13 180 Ringing ------------------------------->| 1544 | | | | | 1545 | |< - - - - - - - - - - - - - ->| | 1546 | | | | | 1547 | | |<- NOTIFY F14<| | 1548 | | | | | 1549 | | |>F15 200 OK ->| | 1550 | | | |------ NOTIFY F16>| 1551 | | | | | 1552 | | | |F18 200 OK ->| | | | 1554 | |>F19 200 OK ------------------------------------>| 1555 | | | | | 1556 | |<--------------------------------------- ACK F20<| 1557 |<---- ACK F21<| | | | 1558 | | | | | 1559 |<================= Both way RTP established ===================>| 1560 | | | | | 1561 | |< - - - - - - - - - - - - - ->| | 1562 | | | | | 1563 | | |<- NOTIFY F22<| | 1564 | | | | | 1565 | | |>F23 200 OK ->| | 1566 | | | |------ NOTIFY F24>| 1567 | | | | | 1568 | | | | Appearance Agent 1580 PUBLISH sip:HelpDesk@example.com SIP/2.0 1581 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 1582 From: ;tag=44150CC6-A7B7919D 1583 To: 1584 CSeq: 7 PUBLISH 1585 Call-ID: 44fwF144-F12893K38424 1586 Contact: 1587 Event: dialog;shared 1588 Max-Forwards: 70 1589 Content-Type: application/dialog-info+xml 1590 Content-Length: ... 1592 1593 1598 1599 1 1600 false 1601 trying 1602 1603 1604 1605 1606 1607 1609 F2 Appearance Agent ----> Bob 1611 SIP/2.0 200 OK 1612 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 1613 From: ;tag=44150CC6-A7B7919D 1614 To: 1615 CSeq: 7 PUBLISH 1616 Call-ID: 44fwF144-F12893K38424 1617 Contact: 1618 Event: dialog;shared 1619 SIP-Etag: 482943245 1620 Allow-Events: dialog 1621 Expires: 60 1622 Content-Length: 0 1624 F7 Bob ---> Proxy 1625 INVITE sip:carol@example.com SIP/2.0 1626 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK342122 1627 Max-Forwards: 70 1628 From: ;tag=15A3DE7C-9283203B 1629 To: 1630 Call-ID: f3b3cbd0-a2c5775e-5df9f8d5 1631 CSeq: 31 INVITE 1632 Contact: 1633 Content-Type: application/sdp 1634 Content-Length: ... 1636 (SDP Not Shown) 1638 F10 Bob ----> Appearance Agent 1640 PUBLISH sip:HelpDesk@example.com SIP/2.0 1641 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK6d644638E7 1642 From: ;tag=0CCf6-A7FdsB79D 1643 To: 1644 CSeq: 437 PUBLISH 1645 Call-ID: fwF14d4-F1FFF2F2893K38424 1646 Contact: 1647 Event: dialog;shared 1648 Max-Forwards: 70 1649 Content-Type: application/dialog-info+xml 1650 Content-Length: ... 1652 1653 1658 1662 1 1663 false 1664 trying 1665 1666 1667 1668 1669 1670 1671 1673 1674 1675 1677 10.5. Outgoing Call without using an Appearance Number 1679 In this scenario, Bob's UA sends out a dialog event PUBLISH with 1680 state (trying) indicating that he does not want to utilize an 1681 appearance number for this dialog. The PUBLISH does not have an 1682 appearance element but does have the 'shared' dialog event parameter. 1683 As a result, the Appearance Agent knows the UA does not wish to use 1684 an appearance number for this call. If the Appearance Agent does not 1685 wish to allow this, it would reject the PUBLISH with a 409 Conflict 1686 response and the UA would know to re-PUBLISH selecting/seizing an 1687 appearance number. 1689 Carol Proxy Alice Appearance Agent Bob 1690 | | | | | 1691 | | | |<----- PUBLISH F1<| 1692 | | | | | 1693 | | | |>F2 200 OK ------>| 1694 | | | | | 1695 | | |<-- NOTIFY F3<| | 1696 | | | | | 1697 | | |>F4 200 OK -->| | 1698 | | | |------- NOTIFY F5>| 1699 | | | | | 1700 | | | |F8 100 Trying --------------------------------->| 1705 |<-- INVITE F9<| | | | 1706 | | | |<---- PUBLISH F10<| 1707 | | | | | 1708 | | | |>F11 200 OK ----->| 1709 | | | | | 1710 |>F12 180 --->| | | | 1711 | |>F13 180 Ringing ------------------------------->| 1712 | | | | | 1713 | |< - - - - - - - - - - - - - ->| | 1714 | | | | | 1715 | | |<- NOTIFY F14<| | 1716 | | | | | 1717 | | |>F15 200 OK ->| | 1718 | | | |------ NOTIFY F16>| 1719 | | | | | 1720 | | | |F18 200 OK ->| | | | 1722 | |>F19 200 OK ------------------------------------>| 1723 | | | | | 1724 | |<--------------------------------------- ACK F20<| 1725 |<---- ACK F21<| | | | 1726 | | | | | 1727 |<================= Both way RTP established ===================>| 1728 | | | | | 1729 | |< - - - - - - - - - - - - - ->| | 1730 | | | | | 1731 | | |<- NOTIFY F22<| | 1732 | | | | | 1733 | | |>F23 200 OK ->| | 1734 | | | |------ NOTIFY F24>| 1735 | | | | | 1736 | | | | Appearance Agent 1743 PUBLISH sip:appearanceagent.example.com SIP/2.0 1744 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 1745 From: ;tag=4415df82k39sf 1746 To: 1747 CSeq: 7 PUBLISH 1748 Call-ID: 44fwF144-F12893K38424 1749 Contact: 1750 Event: dialog;shared 1751 Max-Forwards: 70 1752 Content-Type: application/dialog-info+xml 1753 Content-Length: ... 1755 1756 1761 1762 false 1763 trying 1764 1765 1766 1767 1769 1770 1772 Note that F7 would be the same as the previous example. 1774 10.6. Appearance Release 1776 Bob and Carol are in a dialog, created, for example as in Section 1777 10.3. Carol sends a BYE to Bob to terminate the dialog and the 1778 Appearance Agent de-allocates the appearance number used, sending 1779 notifications out to the UAs in the shared group. 1781 Carol Proxy Alice Appearance Agent Bob 1782 | | | | | 1783 | | | | | 1784 |<================= Both way RTP established ===================>| 1785 | | | | | 1786 |>F22 BYE ---->| | | | 1787 | |>F23 BYE --------------------------------------->| 1788 | | | | | 1789 | |<------------------------------------ 200 OK F24<| 1790 |<--200 OK F25<| | | | 1791 | |< - - - - - - - - - - - - - ->| | 1792 | | | | | 1793 | | |<- NOTIFY F26<| | 1794 | | | | | 1795 | | |>F27 200 OK ->| | 1796 | | | |------ NOTIFY F28>| 1797 | | | | | 1798 | | | | Bob 1804 NOTIFY sip:bob@ua1.example.com SIP/2.0 1805 From: ;tag=497585728578386 1806 To: 1807 Call-ID: a7d559db-d6d7dcad-311c9e3a 1808 CSeq: 7 NOTIFY 1809 Via: SIP/2.0/UDP appearanceagent.example.com 1810 ;branch=z9hG4bK759878512309 1811 Max-Forwards: 70 1812 Content-Type: application/dialog-info+xml 1813 Event: dialog;shared 1814 Subscription-State: active 1815 Contact: 1816 Content-Length: ... 1818 1819 1824 1829 1 1830 false 1831 terminated 1832 1833 1834 1835 1836 1837 1839 10.7. Appearance Pickup 1841 In this scenario, Bob has an established dialog with Carol created 1842 using the call flows of Figure 1 or Figure 2. Bob then places Carol 1843 on hold. Alice receives a notification of this and renders this on 1844 Alice's UI. Alice subsequently picks up the held call and has a 1845 established session with Carol. Finally, Carol hangs up. Alice must 1846 PUBLISH F32 to indicate that the INVITE F38 will be an attempt to 1847 pickup the dialog between Carol and Bob, and hence may use the same 1848 appearance number. 1850 Carol Proxy Alice Appearance Agent Bob 1851 | | | | | 1852 |<================= Both way RTP established ===================>| 1853 | | | | | 1854 | |<------------------------------(hold) INVITE F22<| 1855 |<- INVITE F23<| | | | 1856 | | | | | 1857 |>F24 200 OK ->| | | | 1858 | |>F25 200 OK ------------------------------------>| 1859 | | | | | 1860 | |<--------------------------------------- ACK F26<| 1861 |<---- ACK F27<| | | | 1862 | |< - - - - - - - - - - - - - ->| | 1863 | | | | | 1864 | | |<- NOTIFY F28<| | 1865 | | | | | 1866 | | |>F29 200 OK ->| | 1867 | | | |>F30 NOTIFY ----->| 1868 | | | | | 1869 | | | |<----- 200 OK F31<| 1870 | | | | | 1871 | | Alice decides to pick up the call | 1872 | | | | | 1873 | | |>F32 PUBLISH->| | 1874 | | | | | 1875 | | |<- 200 OK F33<| | 1876 | | | | | 1877 | | |<- NOTIFY F34<| | 1878 | | | | | 1879 | | |>F35 200 OK ->| | 1880 | | | |>F36 NOTIFY ----->| 1881 | | | | | 1882 | | | |<----- 200 OK F37<| 1883 | |<-- INVITE F38<| | | 1884 |<- INVITE F39<|(w/ Replaces) | | | 1885 |( w/ Replaces)| | | | 1886 |>F40 200 OK ->| | | | 1887 | |>F41 200 OK -->| | | 1888 | | | | | 1889 | |< - - - - - - - - - - - - - ->| | 1890 | | | | | 1891 | | | |>F42 NOTIFY ----->| 1892 | | | | | 1893 | | | |<----- 200 OK F43<| 1894 | | |<- NOTIFY F44<| | 1895 | | | | | 1896 | | |>F45 200 OK ->| | 1897 | | | | | 1898 | |<----- ACK F46<| | | 1899 |<---- ACK F47<| | | | 1900 | | | | | 1901 |<= Both way RTP established =>| | | 1902 | | | | | 1903 |>F48 BYE ---->| | | | 1904 | |>F49 BYE --------------------------------------->| 1905 | | | | | 1906 | |<------------------------------------ OK 200 F50<| 1907 |<- 200 OK F51<| | | | 1908 | | | | | 1909 | |< - - - - - - - - - - - - - ->| | 1910 | | | | | 1911 | | |<- NOTIFY F52<| | 1912 | | | | | 1913 | | |>F53 200 OK ->| | 1914 | | | | | 1915 | | | |>F54 NOTIFY ----->| 1916 | | | | | 1917 | | | |<----- 200 OK F55<| 1919 Figure 7. 1921 F28 Appearance ----> Alice 1923 NOTIFY sip:alice@ua1.example.com SIP/2.0 1924 From: ;tag=151702541050937 1925 To: ;tag=18433323-C3D237CE 1926 Call-ID: 1e361d2f-a9f51109-bafe31d4 1927 CSeq: 12 NOTIFY 1928 Via: SIP/2.0/UDP appearanceagent.example.com 1929 ;branch=z9hG4bK1403 1930 Max-Forwards: 70 1931 Content-Type: application/dialog-info+xml 1932 Event: dialog;shared 1933 Subscription-State: active 1934 Contact: 1935 Content-Length: ... 1937 1938 1943 1948 1 1949 false 1950 active 1951 1952 1953 1954 1955 1956 1957 sip:carol@example.com 1958 1959 1961 1962 1964 F32 Alice ----> Appearance Agent 1966 PUBLISH sip:HelpDesk@example.com SIP/2.0 1967 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A 1968 From: ;tag=44150CC6-A7B7919D 1969 To: ;tag=428765950880801 1970 CSeq: 11 PUBLISH 1971 Call-ID: 87837Fkw87asfds 1972 Contact: 1973 Event: dialog;shared 1974 Max-Forwards: 70 1975 Content-Type: application/dialog-info+xml 1976 Content-Length: ... 1978 1979 1984 1987 1 1988 false 1989 1993 trying 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2005 F38 Alice ----> Proxy 2006 INVITE sip:carol@example.com SIP/2.0 2007 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK4ea695b5B376A60C 2008 From: ;tag=8C4183CB-BCEAB710 2009 To: 2010 CSeq: 1 INVITE 2011 Call-ID: 3d57cd17-47deb849-dca8b6c6 2012 Contact: 2013 2014 Replaces: f3b3cbd0-a2c5775e-5df9f8d5;to-tag=65a98f7c 2015 -1dd2-11b2-88c6-b03162323164+65a98f7c;from-tag=15A3DE7C-9283203B 2016 2017 Max-Forwards: 70 2018 Content-Type: application/sdp 2019 Content-Length: 223 2021 v=0 2022 o=- 1102980497 1102980497 IN IP4 ua1.example.com 2023 s=IP SIP UA 2024 c=IN IP4 ua1.example.com 2025 t=0 0 2026 a=sendrecv 2027 m=audio 2238 RTP/AVP 0 8 101 2028 a=rtpmap:0 PCMU/8000 2029 a=rtpmap:8 PCMA/8000 2030 a=rtpmap:101 telephone-event/8000 2032 10.8. Calls between UAs within the Group 2034 In this scenario, Bob calls Alice who is also in the Appearance 2035 group. Only one appearance number is used for this dialog. This 2036 example also shows the use of the 'exclusive' tag to indicate that 2037 other UAs in the group can not join or take this dialog. 2039 Carol Proxy Alice Appearance Agent Bob 2040 | | | | | 2041 | |<-------------------- INVITE (to Alice's UA) F1<| 2042 | | | | | 2043 | |< - - - - - - - - - - - - - ->| | 2044 | | | | | 2045 | | | | | 2046 | | |<-- NOTIFY F2<| | 2047 | | | | | 2048 | | |>F3 200 OK -->| | 2049 | | | |>F4 NOTIFY ------>| 2050 | | | | | 2051 | | | |<------ 200 OK F5<| 2052 | |>F6 INVITE --->| | | 2053 | | (appearance=1)| | | 2054 | | | | | 2055 | |<------ 180 F7<| | | 2056 | | | | | 2057 | |>F8 180 --------------------------------------->| 2058 | | | | | 2059 | |< - - - - - - - - - - - - - ->| | 2060 | | | | | 2061 | | |<-- NOTIFY F9<| | 2062 | | | | | 2063 | | |>F10 200 OK ->| | 2064 | | | |>F11 NOTIFY ----->| 2065 | | | | | 2066 | | | |<----- 200 OK F12<| 2067 | |<-- 200 OK F13<| | | 2068 | | | | | 2069 | |>F14 200 OK ------------------------------------>| 2070 | | | | | 2071 | |<--------------------------------------- ACK F15<| 2072 | | | | | 2073 | |>F16 ACK ----->| | | 2074 | | | | | 2075 | | |<======= RTP established =======>| 2076 | | | | | 2077 | |< - - - - - - - - - - - - - ->| | 2078 | | | | | 2079 | | |<- NOTIFY F17<| | 2080 | | | | | 2081 | | |>F18 200 OK ->| | 2082 | | | |>F19 NOTIFY ----->| 2083 | | | | | 2084 | | | |<----- 200 OK F24<| 2085 | | | | | 2087 Figure 8. 2089 F19 Appearance Agent ----> Bob 2091 NOTIFY sip:bob@ua1.example.com SIP/2.0 2092 From: ;tag=497585728578386 2093 To: ;tag=633618CF-B9C2EDA4 2094 Call-ID: a7d559db-d6d7dcad-311c9e3a 2095 CSeq: 7 NOTIFY 2096 Via: SIP/2.0/UDP appearanceagent.example.com 2097 ;branch=z9hG4bK1711759878512309 2098 Max-Forwards: 70 2099 Content-Type: application/dialog-info+xml 2100 Event: dialog;shared 2101 Subscription-State: active 2102 Contact: 2103 Content-Length: ... 2105 2106 2111 2116 true 2117 1 2118 confirmed 2119 2120 2121 2122 2123 2124 sip:HelpDesk@example.com 2125 2126 2127 2129 2134 true 2135 1 2136 confirmed 2137 2138 2139 2140 2141 sip:HelpDesk@example.com 2142 2143 2144 2146 2148 10.9. Consultation Hold with Appearances 2150 In this scenario, Bob has a call with Carol. Bob makes a 2151 consultation call to Alice by putting Carol on hold and calling 2152 Alice. Bob chooses not to have an appearance number for the call to 2153 Alice since he is treating it as part of the call to Carol. He 2154 indicates this in his PUBLISH F32 which contains the 'shared' Event 2155 parameter but no element. The PUBLISH is sent before 2156 the INVITE to Alice to ensure no appearance number is assigned by the 2157 Appearance Agent. Finally, Bob hangs up with Alice and resumes the 2158 call with Carol. Note that the Appearance Agent does not generate 2159 notifications on the dialog state of the consultation call. 2161 Note that if Carol hangs up while Bob is consulting with Alice, Bob 2162 can decide if he wants to reuse the appearance number used with Carol 2163 for the call with Alice. If not, Bob publishes the termination of 2164 the dialog with Carol and the Appearance Agent will re-allocate the 2165 appearance. If he wants to keep the appearance, Bob will publish the 2166 termination of the dialog with Carol and also publish the appearance 2167 with the dialog with Alice. This will result in Bob keeping the 2168 appearance number until he reports the dialog with Alice terminated. 2170 Note that the call flow would be similar if Bob called a music on 2171 hold server instead of Alice to implement a music on hold service as 2172 described in [I-D.worley-service-example]. 2174 Carol Proxy Alice Appearance Agent Bob 2175 | | | | | 2176 |<================= Both way RTP established ===================>| 2177 | | | | | 2178 | |<------------------------------(hold) INVITE F22<| 2179 |<- INVITE F23<| | | | 2180 | | | | | 2181 |>F24 200 OK ->| | | | 2182 | |>F25 200 OK ------------------------------------>| 2183 | | | | | 2184 | |<--------------------------------------- ACK F26<| 2185 |<---- ACK F27<| | | | 2186 | |< - - - - - - - - - - - - - ->| | 2187 | | | | | 2188 | | |<- NOTIFY F28<| | 2189 | | | | | 2190 | | |>F29 200 OK ->| | 2191 | | | |>F30 NOTIFY ----->| 2192 | | | | | 2193 | | | |<----- 200 OK F31<| 2194 | | | | | 2195 | | Bob makes a consultation call to Alice | 2196 | | | | | 2197 | | | |<---- PUBLISH F32<| 2198 | | | | | 2199 | | | |>F33 200 OK ----->| 2200 | | | | | 2201 | |<------------------------------------ INVITE F34<| 2202 | | | | | 2203 | |>F35 INVITE -->| | | 2204 | | | | | 2205 | |<-- 200 OK F36<| | | 2206 | | | | | 2207 | |>F37 200 OK ------------------------------------>| 2208 | | | | | 2209 | |<--------------------------------------- ACK F38<| 2210 | | | | | 2211 | |>F39 ACK ----->| | | 2212 | | | | | 2213 | | |<======= RTP established =======>| 2214 | | | | | 2215 | | Bob hangs up with Alice | 2216 | | | | | 2217 | |<--------------------------------------- BYE F40<| 2218 | | | | | 2219 | |>F41 BYE ----->| | | 2220 | | | | | 2221 | |<-- 200 OK F42<| | | 2222 | | | | | 2223 | |>F43 200 OK ------------------------------------>| 2224 | | | | | 2225 | |<----------------------------(unhold) INVITE F44<| 2226 |<- INVITE F45<| | | | 2227 | | | | | 2228 |>F46 200 OK ->| | | | 2229 | |>F47 200 OK ------------------------------------>| 2230 | | | | | 2231 | |<--------------------------------------- ACK F48<| 2232 |<---- ACK F49<| | | | 2233 | |< - - - - - - - - - - - - - ->| | 2234 | | | | | 2235 | | |<- NOTIFY F50<| | 2236 | | | | | 2237 | | |>F51 200 OK ->| | 2238 | | | |>F52 NOTIFY ----->| 2239 | | | | | 2240 | | | |<----- 200 OK F53<| 2241 | | | | | 2242 |<================= Both way RTP established ===================>| 2243 | | | | | 2244 Figure 9. 2246 F32 Bob ----> Appearance Agent 2248 PUBLISH sip:HelpDesk@example.com SIP/2.0 2249 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A 2250 From: ;tag=44150CC6-A7B7919D 2251 To: ;tag=428765950880801 2252 CSeq: 11 PUBLISH 2253 Call-ID: 44fwF144-F12893K38424 2254 Contact: 2255 Event: dialog;shared 2256 Max-Forwards: 70 2257 Content-Type: application/dialog-info+xml 2258 Content-Length: ... 2260 2261 2266 2270 true 2271 trying 2272 2273 2274 2275 2276 2277 sip:HelpDesk@example.com 2278 2279 2280 2281 2283 10.10. Joining or Bridging an Appearance 2285 In this call flow, a call answered by Bob is joined by Alice or 2286 "bridged". The Join header field is used by Alice to request this 2287 bridging. If Bob did not support media mixing, Bob could obtain 2288 conferencing resources as described in [RFC4579]. 2290 Carol Forking Proxy Appearance Agent Alice Bob 2291 | | | | | 2292 |<=============Both way RTP established===========>| 2293 | | | | | 2294 | | |< PUBLISH F22| | 2295 | | | | | 2296 | | |>F23 200 OK >| | 2297 | | | | | 2298 | |<---- INVITE (w/ Join) F24<| | 2299 | | | | | 2300 | |>F25 INVITE (w/Join)---------------->| 2301 | | | | | 2302 | |<---- OK 200 Contact:Bob;isfocus F26<| 2303 | | | | | 2304 | |< - - - - - >| | | 2305 | | | | | 2306 | | |>F27 NOTIFY >| | 2307 | | | | | 2308 | | |< 200 OK F28<| | 2309 | | | | | 2310 | | |>F29 NOTIFY ---------->| 2311 | | | | | 2312 | | |F31 200 OK Contact:B----->| | 2315 | | | | | 2316 | |<----------------- ACK F32<| | 2317 | | | | | 2318 | |>ACK F33---------------------------->| 2319 | | | | | 2320 | |<-----INVITE Contact:Bob;isfocus F34<| 2321 |<-INVITE F35| | | | 2322 | | | | | 2323 |>F26 200 -->| | | | 2324 | |>F37 200 OK ------------------------>| 2325 | | | | | 2326 | |<--------------------------- ACK F38<| 2327 |<--- ACK F39| | | | 2328 | | | |<==RTP==>| 2329 |<=============Both way RTP established===========>| 2330 | | | | | 2331 | |< - - - - - >| | | 2332 | | | | | 2333 | | |>F40 NOTIFY >| | 2334 | | | | | 2335 | | |< 200 OK F41<| | 2336 | | | | | 2337 | | |>F42 NOTIFY ---------->| 2338 | | | | | 2339 | | | Appearance Agent 2346 PUBLISH sip:HelpDesk@example.com SIP/2.0 2347 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A 2348 From: ;tag=44150CC6-A7B7919D 2349 To: ;tag=428765950880801 2350 CSeq: 11 PUBLISH 2351 Call-ID: 87837Fkw87asfds 2352 Contact: 2353 Event: dialog;shared 2354 Max-Forwards: 70 2355 Content-Type: application/dialog-info+xml 2356 Content-Length: ... 2358 2359 2364 2367 1 2368 false 2369 2373 trying 2374 2375 2376 2377 2378 2379 2380 2381 2382 2384 F24 Alice ----> Proxy 2386 INVITE sip:bob@ua.example.com SIP/2.0 2387 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKcc9d727c2C29BE31 2388 From: ;tag=605AD957-1F6305C2 2389 To: 2390 CSeq: 2 INVITE 2391 Call-ID: dc95da63-60db1abd-d5a74b48 2392 Contact: 2393 2394 Join: 14-1541707345;to-tag=d3b06488-1dd1-11b2-88c5 2395 -b03162323164+d3e48f4c;from-tag=44BAD75D-E3128D42 2396 2397 Max-Forwards: 70 2398 Content-Type: application/sdp 2399 Content-Length: 223 2401 v=0 2402 o=- 1103061265 1103061265 IN IP4 ua1.example.com 2403 s=IP SIP UA 2404 c=IN IP4 ua1.example.com 2405 t=0 0 2406 a=sendrecv 2407 m=audio 2236 RTP/AVP 0 8 101 2408 a=rtpmap:0 PCMU/8000 2409 a=rtpmap:8 PCMA/8000 2410 a=rtpmap:101 telephone-event/8000 2412 10.11. Appearance Allocation - Loss of Appearance 2414 Bob reserves an appearance with a PUBLISH, sends an INVITE to Carol, 2415 then becomes unreachable. When he fails to refresh his publication 2416 to the appearance agent, the Appearance Agent declares the dialog 2417 terminated and frees up the appearance using NOTIFYs F14 and F16. 2418 After retransmitting the NOTIFY to Bob (in not shown messages F17, 2419 F18, etc.), the subscription is terminated. 2421 Carol Proxy Alice Appearance Agent Bob 2422 | | | | | 2423 | | | |<----- PUBLISH F1<| 2424 | | | | | 2425 | | | |>F2 200 OK ------>| 2426 | | | | | 2427 | | |<-- NOTIFY F3<| | 2428 | | | | | 2429 | | |>F4 200 OK -->| | 2430 | | | |------- NOTIFY F5>| 2431 | | | | | 2432 | | | |F8 100 Trying --------------------------------->| 2437 |<-- INVITE F9<| | | | 2438 | | | |<---- PUBLISH F10<| 2439 | | | | | 2440 | | | |>F11 200 OK ----->| 2441 | | | | | 2442 |>F12 180 --->| | | | 2443 | |>F13 180 Ringing ------------------------------->| 2444 | | | | | 2445 | | | | Bob goes offline | 2446 | | | | | 2447 | | | Appearance selection times out | 2448 | | | | | 2449 | | |<- NOTIFY F14<| | 2450 | | | | | 2451 | | |>F15 200 OK ->| | 2452 | | | |------ NOTIFY F16>| 2453 | | | | | 2454 | | | NOTIFY is retransmitted | 2456 Figure 11. 2458 10.12. Appearance Seizure Contention Race Condition 2460 Bob and Alice both try to reserve appearance 2 by publishing at the 2461 same time. The Appearance Agent allocates the appearance to Bob by 2462 sending a 200 OK and denies it to Alice by sending a 409 Conflict. 2463 After the NOTIFY F5, Alice learns that Bob is using appearance 2. 2464 Alice then attempts to reserve appearance 3 by publishing, which is 2465 then accepted. 2467 Carol Proxy Alice Appearance Agent Bob 2468 | | | | | 2469 | | | |<----- PUBLISH F1<| 2470 | | | | (appearance=2) 2471 | | |>F2 PUBLISH ->| | 2472 | | | (appearance=2) | 2473 | | | | | 2474 | | | |>F3 200 OK ------>| 2475 | | |<---- F4 409 <| | 2476 | | | | | 2477 | | |<-- NOTIFY F5<| | 2478 | | | | | 2479 | | |>F6 200 OK -->| | 2480 | | | |------- NOTIFY F7>| 2481 | | | | | 2482 | | | |F10 100 Trying -------------------------------->| 2487 |<- INVITE F11<| | | | 2488 | | | |<---- PUBLISH F12<| 2489 | | | | (appearance=2) 2490 | | | |>F13 200 OK ----->| 2491 | | |>F14 PUBLISH->| | 2492 | | | (appearance=3) | 2493 | | | | | 2494 | | |<--- F15 200 <| | 2495 | | | | | 2496 | | |<- NOTIFY F16<| | 2497 | | | | | 2498 | |>F17 200 OK ->| | 2499 Dave | | |------ NOTIFY F18>| 2500 | | | | | 2501 | | | |F21 100 ----->| | | 2505 |<- INVITE F22<| | | | 2507 Figure 12. 2509 10.13. Appearance Agent Subscription to UAs 2511 In this scenario, the Appearance Agent does not have any way of 2512 knowing Bob's dialog state information, except through Bob. This 2513 could be because the Appearance Agent is not part of a B2BUA, or 2514 perhaps Bob is remotely registering. When Bob registers, the 2515 Appearance Agent receives a registration event package notification 2516 from the registrar. The Appearance Agent then SUBSCRIBEs to Bob's 2517 dialog event state using Event:dialog in the SUBSCRIBE. Whenever 2518 Bob's dialog state changes, a NOTIFY is sent to the Appearance Agent 2519 who then notifies the other other UAs in the group. 2521 Carol Proxy Alice Appearance Agent Bob 2522 | | | | | 2523 | |<----------------------------------- REGISTER F1<| 2524 | | | | | 2525 | |>F2 200 OK ------------------------------------->| 2526 | | | | | 2527 | |>F3 NOTIFY ------------------>| | 2528 | | | | | 2529 | |<------------------ 200 OK F4<| | 2530 | | | |---- SUBSCRIBE F5>| 2531 | | | | | 2532 | | | |F8 200 OK ------>| 2537 | | | | | 2538 | | | |<--- SUBSCRIBE F9<| 2539 | | | | | 2540 | | | |>F10 200 OK ----->| 2541 | | | | | 2542 | | | |------ NOTIFY F11>| 2543 | | | | | 2544 | | | |F14 100 Trying -------------------------------->| 2549 |<- INVITE F15<| | | | 2550 | | | |<----- NOTIFY F16<| 2551 | | | | | 2552 | | | |>F17 200 OK ----->| 2553 | | |<- NOTIFY F18<| | 2554 | | | | | 2555 | | |>F19 200 OK ->| | 2556 | | | |------ NOTIFY F20>| 2557 | | | | | 2558 | | | |F22 180 --->| | | | 2560 | |>F23 180 Ringing ------------------------------->| 2561 | | | | | 2562 | | | |<----- NOTIFY F24<| 2563 | | | | | 2564 | | | |>F25 200 OK ----->| 2565 | | |<- NOTIFY F26<| | 2566 | | | | | 2567 | | |>F27 200 OK ->| | 2568 | | | |------ NOTIFY F28>| 2569 | | | | | 2570 | | | |F30 200 OK ->| | | | 2572 | |>F31 200 OK ------------------------------------>| 2573 | | | | | 2574 | | | |<----- NOTIFY F32<| 2575 | | | | | 2576 | | | |>F33 200 OK ----->| 2577 | | | | | 2578 | |<--------------------------------------- ACK F34<| 2579 |<---- ACK F35<| | | | 2580 | | | | | 2581 |<================= Both way RTP established ===================>| 2582 | | | | | 2583 | | |<- NOTIFY F36<| | 2584 | | | | | 2585 | | |>F37 200 OK ->| | 2586 | | | |------ NOTIFY F38>| 2587 | | | | | 2588 | | | || 2606 | | | | | 2607 | |<------------------------------(hold) INVITE F22<| 2608 |<- INVITE F23<| | | | 2609 | | | | | 2610 |>F24 200 OK ->| | | | 2611 | |>F25 200 OK ------------------------------------>| 2612 | | | | | 2613 | |<--------------------------------------- ACK F26<| 2614 |<---- ACK F27<| | | | 2615 | | | | | 2616 | |< - - - - - - - - - - - - - ->| | 2617 | | | | | 2618 | | |<- NOTIFY F28<| | 2619 | | | | | 2620 | | |>F29 200 OK ->| | 2621 | | | |>F30 NOTIFY ----->| 2622 | | | | | 2623 | | | |<----- 200 OK F31<| 2624 | | | | | 2625 | | Alice decides to pick up the call | 2626 | | | | | 2627 | | |>F32 PUBLISH->| | 2628 | | | | | 2629 | | |<- 200 OK F33<| | 2630 | | | | | 2631 | | |<- NOTIFY F34<| | 2632 | | | | | 2633 | | |>F35 200 OK ->| | 2634 | | | |>F36 NOTIFY ----->| 2635 | | | | | 2636 | | | |<----- 200 OK F37<| 2637 |>F38 BYE ---->| | | | 2638 | |>F39 BYE --------------------------------------->| 2639 | | | | | 2640 | |<------------------------------------ OK 200 F40<| 2641 |<- 200 OK F41<| | | | 2642 | |<-- INVITE F42<| | | 2643 |<- INVITE F43<|(w/ Replaces) | | | 2644 |( w/ Replaces)| | | | 2645 | | | | | 2646 |>F44 481 ---->| | | | 2647 | |>F45 481 ----->| | | 2648 |<---- ACK F46<| | | | 2649 | |<----- ACK F47<| | | 2650 | | |>F48 PUBLISH->| | 2651 | | | | | 2652 | | |<- 200 OK F49<| | 2653 | | | | | 2654 | | |<- NOTIFY F50<| | 2655 | | | | | 2656 | | |>F51 200 OK ->| | 2657 | | | |>F52 NOTIFY ----->| 2658 | | | | | 2659 | | | |<----- 200 OK F53<| 2661 Figure 14. 2663 F48 Alice ----> Appearance Agent 2665 PUBLISH sip:HelpDesk@example.com SIP/2.0 2666 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A 2667 From: ;tag=44150CC6-A7B7919D 2668 To: ;tag=428765950880801 2669 CSeq: 11 PUBLISH 2670 Call-ID: 87837Fkw87asfds 2671 Contact: 2672 Event: dialog;shared 2673 Max-Forwards: 70 2674 Content-Type: application/dialog-info+xml 2675 Content-Length: ... 2677 2678 2683 2686 1 2687 false 2688 2692 terminated 2693 2694 2695 2696 2697 2698 2699 2700 2701 2703 10.15. Appearance Seizure Incoming/Outgoing Contention Race Condition 2705 Alice tries to seize appearance 2 at the same time appearance 2 is 2706 allocated to an incoming call. The Appearance Agent resolves the 2707 conflict by sending a 409 Conflict to Alice. After the NOTIFY F6, 2708 Alice learns that the incoming call is using appearance 2. Alice 2709 republishes for appearance 3, which is accepted. Note that this 2710 example shows the INVITE being received before the NOTIFY from the 2711 Appearance Agent. 2713 Carol Proxy Alice Appearance Agent Bob 2714 | | | | | 2715 |>-- INVITE F1>| | | | 2716 | |< - - - - - - - - - - - - - ->| | 2717 | | | | | 2718 | | |>F2 PUBLISH ->| | 2719 | | | (appearance=2) | 2720 | | | | | 2721 | |>F3 INVITE (appearance=2) ---------------------->| 2722 | | | | | 2723 | |>F4 INVITE | | | 2724 | |(appearance=2)>| | | 2725 | | |<---- F5 409 <| | 2726 | | | | | 2727 | | |<-- NOTIFY F6<| | 2728 | | | | | 2729 | | |>F7 200 OK -->| | 2730 | | | |------- NOTIFY F8>| 2731 | | | | | 2732 | | | |F10 PUBLISH->| | 2735 | | | (appearance=3) | 2736 | | | | | 2737 | | |< F11 200 OK <| | 2738 | | | | | 2739 | | |<- NOTIFY F12<| | 2740 | | | | | 2741 | |>F13 200 OK ->| | 2742 Dave | | |------ NOTIFY F14>| 2743 | | | | | 2744 | | | |F17 100 ----->| | | 2748 |<- INVITE F18<| | | | 2750 Figure 15. 2752 11. Incoming Appearance Assignment 2754 A proxy inserting an 'appearance' Alert-Info parameter follows normal 2755 policies Alert-Info policies. If an Alert-Info is already present, 2756 the proxy either removes the Alert-Info if it is not trusted, or adds 2757 the 'appearance' parameter to the Alert-Info header field. If an 2758 appearance number parameter is already present (associated with 2759 another AOR or by mistake), the value is rewritten adding the new 2760 appearance number. There MUST NOT be more than one appearance 2761 parameter in an Alert-Info header field. 2763 If no special ringtone is desired, a normal ringtone should be 2764 indicated using the urn:alert:service:normal in the Alert-Info, as 2765 per [I-D.liess-dispatch-alert-info-urns]. The appearance number 2766 present in an Alert-Info header field SHOULD be rendered by the UA to 2767 the user, following the guidelines in Section 5.3. If the INVITE is 2768 forwarded to another AOR, the appearance parameter in the Alert-Info 2769 SHOULD be removed before forwarding outside the group. 2771 The determination as to what value to use in the appearance parameter 2772 can be done at the proxy that forks the incoming request to all the 2773 registered UAs. 2775 There are a variety of ways the proxy can use to determine what 2776 value it should use to populate this parameter. For example, the 2777 proxy could fetch this information by initiating a SUBSCRIBE 2778 request with Expires: 0 to the Appearance Agent for the AOR to 2779 fetch the list of lines that are in use. Alternatively, it could 2780 act like a UA that is a part of the appearance group and SUBSCRIBE 2781 to the State-Agent like any other UA. This would ensure that the 2782 active dialog information is available without having to poll on a 2783 need basis. It could keep track of the list of active calls for 2784 the appearance AOR based on how many unique INVITE requests it has 2785 forked to or received from the appearance AOR. Another approach 2786 would be for the Proxy to first send the incoming INVITE to the 2787 Appearance Agent which would redirect to the appearance group URI 2788 and escape the proper Alert-Info header field for the Proxy to 2789 recurse and distribute to the other UAs in the group. 2790 The Appearance Agent needs to know about all incoming requests to 2791 the AOR in order to seize the appearance number. One way in which 2792 this could be done is for the Appearance Agent to register against 2793 the AOR with a higher q value. This will result in the INVITE 2794 being sent to the Appearance Agent first, then being offered to 2795 the UAs in the group. 2797 The changes to RFC 3261 ABNF are: 2799 alert-param = LAQUOT absoluteURI RAQUOT *( SEMI (generic-param / 2800 appearance-param) ) 2802 appearance-param = "appearance" EQUAL *DIGIT 2804 12. Security Considerations 2806 Since multiple line appearance features are implemented using 2807 semantics provided by [RFC3261], Event Package for Dialog State as 2808 define in , and Event Notification [I-D.ietf-sipcore-rfc3265bis], 2809 [RFC3903], security considerations in these documents apply to this 2810 draft as well. 2812 Specifically, since dialog state information and the dialog 2813 identifiers are supplied by UA's in an appearance group to other 2814 members, the same is prone to "call hijacks". For example, a rogue 2815 UA could snoop for these identifiers and send an INVITE with Replaces 2816 header containing these call details to take over the call. As such 2817 INVITES with Replaces header MUST be authenticated using the standard 2818 mechanism (like Digest or S/MIME) described in [RFC3261]. before it 2819 is accepted. NOTIFY or PUBLISH message bodies that provide the 2820 dialog state information and the dialog identifiers MAY be encrypted 2821 end-to-end using the standard mechanics. All SUBSCRIBES between the 2822 UA's and the Appearance Agent MUST be authenticated. 2824 13. IANA Considerations 2826 This section registers the SIP event package parameter 'shared', the 2827 SIP Alert-Info header field parameter "appearance" and the XML 2828 namespace extensions to the SIP Dialog Package. 2830 13.1. SIP Event Package Parameter: shared 2832 This specification defines a new event parameter 'shared' for the 2833 Dialog Package. When used in a NOTIFY, it indicates that the 2834 notifier supports the shared appearance feature. When used in a 2835 PUBLISH, it indicates that the publisher has explicit appearance 2836 information contained in the message body. If not present in a 2837 PUBLISH, the Appearance Agent MAY assign an appearance number to any 2838 new dialogs in the message body. 2840 13.2. URN Sub-Namespace Registration: sa-dialog-info 2842 This section registers a new XML namespace per the procedures 2843 in [RFC3688]. 2845 URI: urn:ietf:params:xml:ns:sa-dialog-info. 2847 Registrant Contact: IETF BLISS working group, , 2848 Alan Johnston 2850 XML: 2852 BEGIN 2853 2854 2856 2857 2858 2860 Shared Appearance Dialog Information Namespace 2861 2862 2863

Namespace for Shared Appearance Dialog Information

2864

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

2865

See 2866 RFCXXXX.

2867 2868 2869 END 2871 13.3. XML Schema Registration 2873 This section registers an XML schema per the procedures in 2874 [RFC3688]. 2876 URI: urn:ietf:params:xml:schesa:sa-dialog-info. 2878 Registrant Contact: IETF BLISS working group, , 2879 Alan Johnston 2881 The XML for this schema can be found in Section 6. 2883 14. Acknowledgements 2885 The following individuals were part of the shared appearance Design 2886 team and have provided input and text to the document (in 2887 alphabetical order): 2889 Martin Dolly, Andrew Hutton, Raj Jain, Fernando Lombardo, Derek 2890 MacDonald, Bill Mitchell, Michael Procter, Theo Zowzouvillys. 2892 Thanks to Chris Boulton for helping with the XML schema. 2894 Much of the material has been drawn from previous work by Mohsen 2895 Soroushnejad, Venkatesh Venkataramanan, Paul Pepper and Anil Kumar, 2896 who in turn received assistance from: 2898 Kent Fritz, John Weald, and Sunil Veluvali of Sylantro Systems, Steve 2899 Towlson, and Michael Procter of Citel Technologies, Rob Harder and 2900 Hong Chen of Polycom Inc, John Elwell, J D Smith of Siemens 2901 Communications, Dale R. Worley of Pingtel, Graeme Dollar of Yahoo 2902 Inc. 2904 Also thanks to Geoff Devine, Paul Kyzivat, Jerry Yin, John Elwell, 2905 Dan York, Spenser Dawkins, Martin Dolly, and Brett Tate for their 2906 comments. 2908 Thanks to Carolyn Beeton, Francois Audet, Andy Hutton, Tim Ross, Raji 2909 Chinnappa, and Harsh Mendiratta for their detailed review of the 2910 document. 2912 15. References 2914 15.1. Normative References 2916 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2917 Requirement Levels", BCP 14, RFC 2119, March 1997. 2919 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2920 A., Peterson, J., Sparks, R., Handley, M., and E. 2921 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2922 June 2002. 2924 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 2925 Method", RFC 3515, April 2003. 2927 [I-D.ietf-sipcore-rfc3265bis] 2928 Roach, A., "SIP-Specific Event Notification", 2929 draft-ietf-sipcore-rfc3265bis-01 (work in progress), 2930 February 2010. 2932 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 2933 for Event State Publication", RFC 3903, October 2004. 2935 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 2936 Protocol (SIP) "Replaces" Header", RFC 3891, 2937 September 2004. 2939 [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- 2940 Initiated Dialog Event Package for the Session Initiation 2941 Protocol (SIP)", RFC 4235, November 2005. 2943 [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol 2944 (SIP) "Join" Header", RFC 3911, October 2004. 2946 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 2947 "Indicating User Agent Capabilities in the Session 2948 Initiation Protocol (SIP)", RFC 3840, August 2004. 2950 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2951 January 2004. 2953 [I-D.liess-dispatch-alert-info-urns] 2954 Liess, L., Alexeitsev, D., Jesske, R., Johnston, A., and 2955 A. Siddiqui, "Alert-Info URNs for the Session Initiation 2956 Protocol (SIP)", draft-liess-dispatch-alert-info-urns-02 2957 (work in progress), July 2010. 2959 15.2. Informative References 2961 [RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and 2962 K. Summers, "Session Initiation Protocol Service 2963 Examples", BCP 144, RFC 5359, October 2008. 2965 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol 2966 (SIP) Call Control - Conferencing for User Agents", 2967 BCP 119, RFC 4579, August 2006. 2969 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 2970 Package for Registrations", RFC 3680, March 2004. 2972 [I-D.worley-service-example] 2973 Worley, D., "Session Initiation Protocol Service Example 2974 -- Music on Hold", draft-worley-service-example-05 (work 2975 in progress), July 2010. 2977 Authors' Addresses 2979 Alan Johnston (editor) 2980 Avaya 2981 St. Louis, MO 63124 2983 Email: alan.b.johnston@gmail.com 2985 Mohsen Soroushnejad 2986 Sylantro Systems Corp 2988 Email: mohsen.soroush@sylantro.com 2990 Venkatesh Venkataramanan 2991 Sylantro Systems Corp 2993 Email: vvenkatar@gmail.com