idnits 2.17.1 draft-ietf-bliss-shared-appearances-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 (March 7, 2010) is 5161 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-01 Summary: 1 error (**), 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 Expires: September 8, 2010 M. Soroushnejad 5 V. Venkataramanan 6 Sylantro Systems Corp 7 March 7, 2010 9 Shared Appearances of a Session Initiation Protocol (SIP) Address of 10 Record (AOR) 11 draft-ietf-bliss-shared-appearances-05 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 to IETF 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), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 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 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt. 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 This Internet-Draft will expire on September 8, 2010. 52 Copyright Notice 54 Copyright (c) 2010 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the BSD License. 67 This document may contain material from IETF Documents or IETF 68 Contributions published or made publicly available before November 69 10, 2008. The person(s) controlling the copyright in some of this 70 material may not have granted the IETF Trust the right to allow 71 modifications of such material outside the IETF Standards Process. 72 Without obtaining an adequate license from the person(s) controlling 73 the copyright in such materials, this document may not be modified 74 outside the IETF Standards Process, and derivative works of it may 75 not be created outside the IETF Standards Process, except to format 76 it for publication as an RFC or to translate it into languages other 77 than English. 79 Table of Contents 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 82 2. Conventions used in this document . . . . . . . . . . . . . . 6 83 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 6 84 3.1. Executive/Assistant Arrangement . . . . . . . . . . . . . 6 85 3.2. Call Group . . . . . . . . . . . . . . . . . . . . . . . 7 86 3.3. Single Line Extension . . . . . . . . . . . . . . . . . . 7 87 4. Requirements and Implementation . . . . . . . . . . . . . . . 7 88 4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 7 89 4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 9 90 5. Normative Description . . . . . . . . . . . . . . . . . . . . 11 91 5.1. Elements . . . . . . . . . . . . . . . . . . . . . . . . 11 92 5.2. Shared Appearance Dialog Package Extensions . . . . . . . 11 93 5.2.1. The element . . . . . . . . . . . . . . . 12 94 5.2.2. The element . . . . . . . . . . . . . . . 12 95 5.2.3. The element . . . . . . . . . . . . . 12 96 5.2.4. The element . . . . . . . . . . . . 12 97 5.3. Shared Appearance User Agents . . . . . . . . . . . . . . 13 98 5.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . 15 99 6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 17 100 7. User Interface Considerations . . . . . . . . . . . . . . . . 19 101 7.1. Appearance Number Rendering . . . . . . . . . . . . . . . 19 102 7.1.1. Single Appearance UAs . . . . . . . . . . . . . . . . 19 103 7.1.2. Dual Appearance UAs . . . . . . . . . . . . . . . . . 19 104 7.1.3. Shared Appearance UAs with Fixed Appearance Number . . 19 105 7.1.4. Shared Appearance UAs with Variable Appearance 106 Number . . . . . . . . . . . . . . . . . . . . . . . . 20 107 7.2. Call State Rendering . . . . . . . . . . . . . . . . . . 20 108 8. Interop with non-Shared Appearance UAs . . . . . . . . . . . . 21 109 8.1. Appearance Assignment . . . . . . . . . . . . . . . . . . 21 110 8.2. Appearance Release . . . . . . . . . . . . . . . . . . . 21 111 8.3. UAs Supporting Dialog Events but Not Shared Appearance . 22 112 9. Provisioning Considerations . . . . . . . . . . . . . . . . . 22 113 10. Example Message Flows . . . . . . . . . . . . . . . . . . . . 22 114 10.1. Registration and Subscription . . . . . . . . . . . . . . 23 115 10.2. Appearance Selection for Incoming Call . . . . . . . . . 26 116 10.3. Outgoing Call without Appearance Seizure . . . . . . . . 30 117 10.4. Outgoing Call with Appearance Seizure . . . . . . . . . . 33 118 10.5. Outgoing Call without using an Appearance Number . . . . 37 119 10.6. Appearance Release . . . . . . . . . . . . . . . . . . . 39 120 10.7. Appearance Pickup . . . . . . . . . . . . . . . . . . . . 40 121 10.8. Calls between UAs within the Group . . . . . . . . . . . 44 122 10.9. Consultation Hold with Appearances . . . . . . . . . . . 47 123 10.10. Joining or Bridging an Appearance . . . . . . . . . . . . 49 124 10.11. Appearance Allocation - Loss of Appearance . . . . . . . 52 125 10.12. Appearance Seizure Contention Race Condition . . . . . . 53 126 10.13. Appearance Agent Subscription to UAs . . . . . . . . . . 54 127 10.14. Appearance Pickup Race Condition Failure . . . . . . . . 56 128 10.15. Appearance Seizure Incoming/Outgoing Contention Race 129 Condition . . . . . . . . . . . . . . . . . . . . . . . . 59 130 11. Incoming Appearance Assignment . . . . . . . . . . . . . . . . 60 131 12. Security Considerations . . . . . . . . . . . . . . . . . . . 60 132 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61 133 13.1. SIP Event Package Parameter: shared . . . . . . . . . . . 61 134 13.2. URN Sub-Namespace Registration: sa-dialog-info . . . . . 62 135 13.3. XML Schema Registration . . . . . . . . . . . . . . . . . 62 136 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 63 137 15. Informative References . . . . . . . . . . . . . . . . . . . . 63 138 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64 140 1. Introduction 142 The feature and functionality requirements for SIP user agents (UAs) 143 supporting business telephony applications differ greatly from basic 144 SIP user agents, both in terms of services and end user experience. 145 In addition to basic SIP support [RFC3261], many of the services in a 146 business environment require the support for SIP extensions such as 147 REFER [RFC3515], SUBSCRIBE/NOTIFY primitives 148 [I-D.ietf-sipcore-rfc3265bis] PUBLISH [RFC3903], the SIP Replaces 149 [RFC3891], and Join [RFC3911] header fields, etc. Many of the 150 popular business services have been documented in the SIP Service 151 Examples [RFC5359]. 153 This specification details a method for implementing a group 154 telephony feature known variously in telephony as Bridged Line 155 Appearance (BLA) or Multiple Line Appearances (MLA), one of the more 156 popular advanced features expected of SIP IP telephony devices in a 157 business environment. Other names for this feature include Shared 158 Call/Line Appearance (SCA), Shared Call Status and Multiple Call 159 Appearance (MCA). A variant of this feature is known as Single Line 160 Extension. 162 This document looks at how this feature can be implemented using 163 standard SIP [RFC3261] in conjunction with SIP events 164 [I-D.ietf-sipcore-rfc3265bis] and publication [RFC3903] for 165 exchanging status among user agents, and the SIP dialog state event 166 package [RFC4235] to exchange dialog state information to achieve the 167 same. Different approaches will be discussed including the use of 168 URI parameters, feature tags, and dialog package extensions along 169 with the strengths and weaknesses of the various approaches. 171 In traditional telephony, the line is physical. A common scenario in 172 telephony is for a number of business telephones to share a single or 173 a small number of lines. The sharing or appearance of these lines 174 between a number of phones is what gives this feature its name. A 175 common scenario in SIP is for a number of business telephones to 176 share a single or a small number of Address of Record (AOR) URIs. 178 In addition, an AOR can have multiple appearances on a single UA in 179 terms of the user interface. The appearance number relates to the 180 user interface for the telephone - typically each appearance of an 181 AOR has a visual display (lamp that can change color or blink or a 182 screen icon) and a button (used to select the appearance). The 183 telephony concept of line appearance is still relevant to SIP due to 184 the user interface considerations. It is important to keep the 185 appearance number construct because: 187 1. Human users are used to the concept and will expect it in 188 replacement systems (e.g. an overhead page announcement says "Joe 189 pickup line 3"). 190 2. It is a useful structure for user interface representation. 192 The purpose of the appearance number is to identify active calls to 193 facilitate sharing between users (e.g. passing a call from one user 194 to another). If a telephone has enough buttons/lamps, calls could be 195 presented on the nth button. If not, it may still be desirable to 196 present the call state, but the appearance number should be displayed 197 so that users know which call, for example, is on hold on which key. 199 In this document, except for the usage scenarios in the next section, 200 we will use the term "appearance" rather than "line appearance" since 201 SIP does not have the concept of lines. Note that this does not mean 202 that a conventional telephony user interface (lamps and buttons) must 203 be used - implementations may use another metaphor as long as the 204 appearance number is readily apparent to the user. Each AOR has a 205 separate appearance numbering space. As a result, a given UA user 206 interface may have multiple occurrences of the same appearance 207 number, but they will be for different AORs. 209 2. Conventions used in this document 211 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 212 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 213 document are to be interpreted as described in RFC-2119 [RFC2119] and 214 indicate requirement levels for compliant mechanisms. 216 3. Usage Scenarios 218 The following examples are common applications of the Shared 219 Appearances feature and are mentioned here as informative use cases. 220 All these example usages can be supported by the Shared Appearances 221 feature described in this document. The main differences relate to 222 the user interface considerations of the device. 224 3.1. Executive/Assistant Arrangement 226 The appearances on the executive's UA also appear on the assistant's 227 UA. The assistant may answer incoming calls to the executive and 228 then place the call on hold for the executive to pick up. The 229 assistant can always see the state of all calls on the executive's 230 UA. 232 3.2. Call Group 234 Users with similar business needs or tasks can be assigned to 235 specific groups and share an AOR. For example, an IT department 236 staff of five might answer a help line which has three appearances on 237 each phone in the IT work area. A call answered on one phone can be 238 put on hold and picked up on another phone. A shout or an IM to 239 another staff member can result in them taking over a call on a 240 particular appearance. Another phone can request to be added/joined/ 241 bridged to an existing appearance resulting in a conference call. 243 3.3. Single Line Extension 245 In this scenario, incoming calls are offered to a group of UAs. When 246 one answers, the other UAs are informed. If another UA in the group 247 seizes the line (i.e. goes off hook), it is immediately bridged or 248 joined in with the call. This mimics the way residential telephone 249 extensions usually operate. 251 4. Requirements and Implementation 253 The next section details the requirements and discusses the 254 implementation of the shared appearances of an AOR feature. 256 4.1. Requirements 258 The basic requirements of the shared appearance feature can be 259 summarized as follows: 261 REQ-1 Incoming calls to the AOR must be offered to a group of UAs and 262 can be answered by any of them. 264 REQ-2 Each UA in the group must be able to learn the call status of 265 the others in the group for the purpose of rendering this information 266 to the user. 268 REQ-3 A UA must be able to join (also called bridge or conference 269 together) or pick up (take) an active call of another UA in the group 270 in a secure way. 272 REQ-4 The mechanism should require the minimal amount of 273 configuration. UAs registering against the group AOR should be able 274 to participate in the appearance group without manual configuration 275 of group members. 277 REQ-5 The mechanism must scale for large numbers of appearances, n, 278 and large numbers of UAs, N, without introducing excessive messaging 279 traffic. 281 REQ-6 Each call or session (incoming or outgoing) must be assigned a 282 common "appearance" number from a managed pool administered for the 283 AOR group. Once the session has terminated, the appearance number is 284 released back into the pool and can be reused by another incoming or 285 outgoing session. 287 REQ-7 Each UA in the group must be able to learn the appearance 288 status of the group. 290 REQ-8 There must be mechanisms to resolve appearance contention among 291 the UAs in the group. 293 REQ-9 The mechanism must allow all UAs receiving an incoming session 294 request to utilize the same appearance number at the time of 295 alerting. 297 REQ-10 The mechanism must have a way of reconstructing appearance 298 state after an outage that does not result in excessive traffic and 299 processing. 301 REQ-11 The mechanism must have backwards compatibility such that a UA 302 which is unaware of the feature can still register against the group 303 AOR and make and receive calls. 305 REQ-12 The mechanism must not allow UAs outside the group to select, 306 seize or manipulate appearance numbers. 308 REQ-13 For privacy reasons, there must be a mechanism so that 309 appearance information is not leaked outside the group of UAs. (e.g. 310 "So who do you have on line 1?") 312 REQ-14 The mechanism must support a way for UAs to request 313 exclusivity on a line appearance. Exclusivity means that the UA 314 requesting it desires to have a private conversation with the 315 external party and other UAs must not be allowed to be joined or 316 taken. Exclusivity may be requested at the start of an incoming or 317 outgoing session or during the session. An exclusivity request may 318 be accepted or rejected by the entity providing the shared appearance 319 service. Therefore, the mechanism must provide a way of 320 communicating the result back to the requester UA. 322 REQ-15 The mechanism should support a way for a UA to seize a 323 particular appearance number for outgoing requests prior to sending 324 the actual request. This is often called seizure. 326 REQ-16 The mechanism should support a way for a UA to seize a 327 particular appearance number and also send the request at the same 328 time. This is needed when a ringdown feature is combined with shared 329 appearances - in this case, seizing the line is the same thing as 330 dialing. 332 4.2. Implementation 334 Many of the requirements for this service can be met using standard 335 SIP mechanisms such as: 337 - A SIP Forking Proxy and Registrar/Location Service meets REQ-1. 339 - The SIP Dialog Package meets REQ-2. 341 - The SIP Replaces and Join header fields meets REQ-3. 343 - The use of a State Agent for the Dialog Package meets REQ-4 and 344 REQ-5. 346 REQ-6 suggests the need for an entity which manages the appearance 347 resource. Just as conferencing systems commonly have a single point 348 of control, known as a focus, a Shared Appearance group has a single 349 point of control of the appearance shared resource. This is defined 350 as an Appearance Agent for a group. While an Appearance Agent can be 351 part of a centralized server, it could also be co-resident in a 352 member User Agent who has taken on this functionality for a group. 353 The Appearance Agent knows or is able to determine the dialog state 354 of all members of the group. 356 While the appearance resource could be managed co-operatively by a 357 group of UAs without any central control, this is outside the scope 358 of this draft. It is also possible that the Appearance Agent logic 359 could be distributed in all UAs in the group. For example, rules 360 that govern assigning appearance numbers for incoming requests (e.g. 361 lowest available appearance number) and rules for contention handling 362 (e.g. when two UAs request the use of the same appearance number, 363 hash dialog identifiers and compare with the lowest hash winning) 364 would need to be defined and implemented. 366 To best meet REQ-9, the appearance number for an incoming INVITE 367 needs to be contained in the INVITE, in addition to being delivered 368 in the dialog package NOTIFY. Otherwise, if the NOTIFY is delayed or 369 lost, a UA in the group might receive an incoming INVITE but might 370 not know which appearance number to render during alerting. 372 This specification defines an extension parameter for the Alert-Info 373 header field in RFC 3261 to carry the appearance number: 375 Alert-Info: ;appearance=0 377 The next section discusses the operations used to implement parts of 378 the shared appearance feature. An analysis of other mechanisms has 379 been performed, with the mechanism described here best meeting the 380 requirements of Section 4.1. 382 1. A UA is configured with the AOR of a shared appearance group. It 383 registers against the AOR, then attempts a dialog state 384 subscription to the AOR. If the subscription fails, loops back 385 to itself, or returns an error, it knows there is no State Agent, 386 and hence no Appearance Agent and this feature is not 387 implemented. 388 2. If the subscription receives a 200 OK, the UA knows there is a 389 State Agent and that the feature is implemented. The UA then 390 follows the steps in this list. 391 3. Information learned about the dialog state of other UAs in the 392 group is rendered to the user. 393 4. Incoming calls are forked to all UAs in the group, and any may 394 answer. UAs receive the appearance number to use in rendering 395 the incoming call in a NOTIFY from the Appearance Agent and in 396 the INVITE itself. The UA will also receive a notification if 397 the call is answered by another UA in the group so this 398 information can be rendered to the user. 399 5. For outgoing calls, the operation depends on the implementation. 400 If the user seizes a particular appearance number for the call, 401 the UA publishes this information and waits for a 200 OK before 402 sending the INVITE. 403 6. For outgoing calls, if the user does not seize a particular 404 appearance or does not care, the INVITE can be sent immediately, 405 and the appearance number learned as the call progresses from a 406 notification from the Appearance Agent. 407 7. For outgoing calls, if the user does not wish to seize an 408 appearance (such as during a consultation call), the UA also 409 publishes this prior to sending the INVITE. 410 8. Established calls within the group may be joined (bridged) or 411 taken (picked) by another UA. Information in the dialog package 412 notifications can be used to construct Join or Replaces header 413 fields. Since the same appearance number is used for these types 414 of operations, this information is published prior to sending the 415 INVITE Join or INVITE Replaces. 416 9. In some cases, the Appearance Agent may not have full access to 417 the complete dialog state of some or all of the UAs in the group. 418 If this is the case, the Appearance Agent will subscribe to the 419 dialog state of individual UAs in the group to obtain this 420 information. Normal notifications will be sent every time the 421 dialog state changes, including calls placed, answered, placed on 422 and off hold, and hangups. 424 5. Normative Description 426 This section normatively describes the shared appearance feature 427 extensions. The following definitions are used throughout this 428 document: 430 Seizing: An appearance can be reserved prior to a call being placed 431 by seizing the appearance. An appearance can be seized by 432 communicating an artificial state of "trying" prior to actually 433 initiating a dialog, in order to appear as it was already initiating 434 a dialog. The appearance number is confirmed prior to sending the 435 INVITE. 437 Selecting(or Not-Seizing): An appearance is merely selected (i.e., 438 not seized) if there is no such communication of artificial state of 439 "trying" prior to initiating a dialog: i.e., the state is 440 communicated when the dialog is actually initiated. The appearance 441 number is learned after the INVITE is sent. This is a user interface 442 only issue. 444 5.1. Elements 446 A complete system to implement this feature consists of: 448 1. User Agents that support publications, subscriptions, and 449 notifications for the SIP dialog event package, and the shared 450 appearance dialog package extensions and behavior. 451 2. An Appearance Agent consisting of a State Agent for the dialog 452 event package that implements an Event State Compositor (ESC) and 453 the shared appearance dialog package extensions and behavior. 454 The Appearance Agent also has logic for assigning and releasing 455 appearance numbers, and resolving appearance number contention. 456 3. A forking proxy server that can communicate with the State Agent 457 4. A registrar that supports the registration event package. 459 The behavior of these elements is described normatively in the 460 following sections after the definitions of the dialog package 461 extensions. 463 5.2. Shared Appearance Dialog Package Extensions 465 This specification defines four new elements as extensions to the SIP 466 Dialog Event package [I-D.ietf-sipcore-rfc3265bis]. The schema is 467 defined in Section 6. The elements are , , 468 , and which are sub-elements of the 469 element. 471 5.2.1. The element 473 The element is used to convey the appearance number. 474 The appearance number is a non-negative integer. When sent in a 475 publication in state Trying to the Appearance Agent, it is used to 476 request an appearance number. When sent by the Appearance Agent, it 477 indicates that the appearance number is associated with a dialog. 479 5.2.2. The element 481 The element is a boolean used to indicate whether the UA 482 will accept Join or Replaces INVITEs for this dialog. For example, 483 some shared appearance systems only allow call pickup when the call 484 is on hold. In this case, the element should be used to 485 explicitly indicate this, rather than implicitly by the hold state. 487 It is important to note that this element is a hint. Although a UA 488 may set exclusive to true, the UA must still be ready to reject an 489 INVITE Join relating to this dialog. Also, an INVITE Replaces might 490 be sent to the non-shared appearance UA to take the call. For this 491 reason, a UA MAY also not report full dialog identifier information 492 to the Appearance Agent for calls set to exclusive. If these dialog 493 identifiers have already been shared with the Appearance Agent, the 494 UA could send an INVITE Replaces to change them and then not report 495 the new ones to the Appearance Agent. 497 If the proxy knows which dialogs are marked exclusive, the proxy MAY 498 enforce this exclusivity by rejecting INVITE Join and INVITE Replaces 499 requests containing those dialog identifiers with a 403 Forbidden 500 response. 502 5.2.3. The element 504 The element is used to convey dialog identifiers of 505 any other dialogs which are joined (mixed or bridged) with the 506 dialog. Only the UA which is performing the actual media mixing 507 should include this element in publications to the Appearance Agent. 508 Note that this element should still be used even when the Join header 509 field was not used to join the dialogs. For example, two separate 510 dialogs on a UA could be joined without any SIP call control 511 operations. Joined dialogs will share the same appearance number. 513 5.2.4. The element 515 The element is used to convey dialog identifiers of 516 any other dialogs which will be or have been replaced with this 517 dialog. For example, a UA in the group picking up a call on another 518 UA by sending an INVITE with Replaces would include this element for 519 the replacing dialog. Replaced dialogs will share the same 520 appearance number. 522 5.3. Shared Appearance User Agents 524 User Agents that support the Shared Appearance feature MUST support 525 the dialog state package [RFC4235] with the shared appearance 526 extensions and the 'shared' dialog event package parameter defined in 527 Section 11. 529 User Agents MUST support the dialog package extensions in Section 5.2 530 along with SUBSCRIBE and NOTIFY [I-D.ietf-sipcore-rfc3265bis] and 531 PUBLISH [RFC3903]. SUBSCRIBE, NOTIFY, and PUBLISH requests for the 532 dialog event package SHOULD include the 'shared' Event header field 533 parameter. 535 The presence of the 'shared' Event package parameter tells the 536 Appearance Agent that this UA supports this specification. 538 Upon initialization, the UA SHOULD subscribe to the dialog event 539 package of the AOR and refresh the subscription per the SIP Events 540 Framework. If the SUBSCRIBE request fails, loops back to itself, 541 then no Appearance Agent is present and this feature is not active 542 for this AOR. The UA MAY periodically retry the subscription to see 543 if conditions have changed. 545 User Agents which implement call pickup, joining and bridging MUST 546 support sending an INVITE with Replaces [RFC3891] or Join [RFC3911]. 547 All User Agents supporting INVITE MUST support receiving an INVITE 548 with a Replaces [RFC3891] or a Join [RFC3911] header field. 550 When publishing or notifying dialog package information, a UA MUST 551 include all dialog identification available at the time of 552 publication, with the exception that a UA may omit information if it 553 wishes to prevent other UAs from joining or picking up a call. 554 Dialog identification includes local and remote target URIs, call-id, 555 to-tag, and from-tag. When calls are placed on hold, the 556 "+sip.rendering=no" feature tag MUST be included in dialog package 557 notifications. 559 The accurate rendering of the idle/active/alerting/hold state of 560 other UAs in the group is an important part of the shared 561 appearance feature. 563 A UA MUST send dialog package PUBLISH requests in the following 564 situations: 566 1. When the user seizes a particular appearance number for an 567 outgoing call (i.e. seizing the appearance and going "off-hook", 568 if the UA's user interface uses this metaphor). 569 2. When the user has requested that an appearance number not be used 570 for an outgoing call (i.e. during a consultation call or for a 571 call not considered part of the shared appearance group). 572 3. When the user has selected to join (or bridge) an existing call. 573 4. When the user has selected to replace (or take) an existing call. 575 In all these cases, the INVITE SHOULD NOT be sent until the 200 OK 576 response to the PUBLISH has been received, except for an emergency 577 call, when a UA MUST never wait for a confirmed seizure before 578 sending an INVITE. Instead, the emergency call MUST proceed 579 regardless of the status of PUBLISH transaction. 581 Note that when a UA seizes an appearance prior to establishment of a 582 dialog (#1 and #2 in above list), not all dialog information will be 583 available. In particular, when a UA publishes an attempt to seize an 584 appearance prior to knowing the destination URI, minimal or no dialog 585 information may be available. For example, in some cases, only the 586 local target URI for the call will be known and no dialog 587 information. If no dialog identification information is present in 588 the initial PUBLISH, the UA MUST PUBLISH again after receiving the 589 100 Trying response. 591 The first publication will cause the Appearance Agent to reserve 592 the appearance number for this UA. If the publication does not 593 have any dialog identifiers (e.g. Call-ID, or local tag) the 594 Appearance Agent cannot assign the appearance number to a 595 particular dialog of the UA until the second publication which 596 will contain some dialog identifiers. 598 This publication state SHOULD be refreshed during the early dialog 599 state or the Appearance Agent may reassign the appearance number. 600 Once the dialog has transitioned to the confirmed state, no 601 publication refreshes are necessary. 603 UAs SHOULD render information about other appearances to the user. 604 This includes the state (idle, active, busy, joined, etc.). UAs can 605 tell that a set of dialogs are joined (bridged or mixed) together by 606 the presence of one or more elements containing other 607 SIP dialog identifiers. A UA MUST render the appearance number to 608 the user or display appearance status information to the user in a 609 way that preserves the appearance order. Appearance numbers of 610 dialogs can be learned by dialog package notifications containing the 611 element from the Appearance Agent or from the 612 'appearance' Alert-Info parameter in an incoming INVITE. Should they 613 conflict, the dialog package notification takes precedence. 615 A UA that does not need to seize a particular appearance number (or 616 doesn't care) would just send an INVITE as normal to place an 617 outbound call. 619 A UA wanting to place a call but not have an appearance number 620 assigned publishes before sending the INVITE without an 'appearance' 621 element but with the 'shared' event package parameter present. If 622 the Appearance Agent policy does not allow calls without an assigned 623 appearance number, a 409 Conflict response will be received, and the 624 UA will republish either selecting/seizing an appearance number or 625 send the INVITE without publishing, in which case the Appearance 626 Agent will assign one. 628 When an INVITE is generated to attempt to bridge or take a call (i.e. 629 contains Join or Replaces with a dialog identifier of another dialog 630 in the shared appearance group), the appearance number of the joined 631 or replaced call SHOULD be published. The publication MUST contain 632 the appearance number of the dialog to be joined or replaced and the 633 dialog identifier in the 'joined-dialog' or 'replaced-dialog' 634 elements. 636 Note that this information is provided to the Appearance Agent so 637 that it can provide proper appearance assignment behavior. If the 638 INVITE Join or Replaces was sent without publishing first, the 639 Appearance Agent might assign a new appearance number to this 640 INVITE, which would be a mistake. With Join, the publication has 641 the 'joined-dialog' element to prevent the Appearance Agent from 642 generating a 409 Conflict response due to the reuse of an 643 appearance number. For Replaces, the purpose of the 'replaced- 644 dialog' is to prevent a race condition where the BYE could cause 645 the appearance number to be released when it should stay with the 646 replacing dialog. 648 A UA SHOULD register against the AOR only if it is likely the UA will 649 be answering incoming calls. If the UA is mainly going to be 650 monitoring the status of the shared appearance group calls and 651 picking or joining calls, the UA SHOULD only subscribe to the AOR and 652 not register against the AOR. 654 All subscribed UAs will received NOTIFYs of Trying state for 655 incoming INVITEs. 657 5.4. Appearance Agent 659 An Appearance Agent defined in this specification MUST implement a 660 dialog package state agent for the UAs registered against the AOR. 661 The Appearance Agent MUST support the appearance dialog package 662 extensions defined in Section 5.2. The Appearance Agent MUST support 663 publications and subscriptions for this event package. 665 The Appearance Agent MUST have a way of discovering the state of all 666 dialogs associated with the AOR. If this information is not 667 available from a call stateful proxy or B2BUA, the Appearance Agent 668 MAY use the registration event package [RFC3680] to learn of UAs 669 associated with the AOR and MAY subscribe to their dialog event 670 state. As a result, the registrar MUST support the registration 671 event package. The Appearance Agent SHOULD send dialog event state 672 notifications whenever the following events happen to UAs in the AOR 673 group: 675 1. A call is received, placed, answered, or terminated. 676 2. A call is placed on or off hold. 677 3. A call is joined or replaced. 678 4. An appearance number is reserved or released. 680 The Appearance Agent MUST allocate an appearance number for all 681 incoming calls and send immediate notifications to the UAs subscribed 682 to the shared group AOR. The Appearance Agent MUST be able to 683 communicate with the forking proxy to learn about incoming calls and 684 also to pass the appearance number to the proxy to insert in the 685 Alert-Info header field. 687 An Appearance Agent SHOULD assign an appearance number to an outgoing 688 dialog if a PUBLISH has not been received selecting/seizing a 689 particular appearance number. 691 Note that if the appearance group has appearance-unaware UAs 692 making calls, the Appearance Agent will still allocate appearance 693 numbers for INVITEs sent by those UAs. 695 An Appearance Agent receiving a PUBLISH with an appearance number 696 checks to make sure the publication is valid. An appearance number 697 can be assigned to only one dialog unless there is a 'joined-dialog' 698 or 'replaced-dialog' element indicating that the dialog will be/has 699 been replaced or joined. A 409 Conflict response is returned if the 700 chosen appearance number is invalid, and an immediate NOTIFY should 701 be sent to the UA containing full dialog event state. 703 An Appearance Agent receiving a PUBLISH without an appearance number 704 but with the 'shared' event package parameter present interprets this 705 as a request by the UA to not assign an appearance number. If the 706 Appearance Agent policy does not allow this, a 409 Conflict response 707 is returned. If policy does allow this, a 200 OK response is 708 returned and no appearance number is allocated. 710 The Appearance Agent allocates an appearance number to a dialog from 711 the time the appearance is requested via a PUBLISH or from the 712 receipt of an INVITE, to the time when the last dialog associated 713 with the appearance is terminted, including all dialogs which are 714 joined or replaced. During the early dialog state, the Appearance 715 Agent controls the rate of dialog state publication using the Expires 716 header field in 200 OK responses to PUBLISH requests. An interval of 717 3 minutes is RECOMMENDED. After the dialog associated with the 718 publication has been confirmed, the expiration of the publication 719 state has no effect on the appearance allocation. If the publication 720 contains no dialog state information, the Appearance Agent MUST 721 reserve the appearance number for the UA but can not assign the 722 appearance to any particular dialog of the UA. When the publication 723 state is updated with any dialog information, the appearance number 724 can then be assigned to the particular dialog. 726 During dynamic situations, such as during a call pickup or join 727 action, the Appearance Agent MAY choose to implement rate limiting to 728 reduce the amount of notification traffic. For example, an 729 Appearance Agent may choose not to generate immediate NOTIFYs upon 730 receipt of PUBLISHes. Instead, a single NOTIFY can convey the 731 effects of a number of PUBLISHes, thus reducing the NOTIFY traffic 732 within the group. 734 If an INVITE is sent by a member of the group using the shared AOR or 735 sent to the shared AOR and no appearance number is available, the 736 proxy MAY reject the INVITE with a 403 Forbidden response code. 738 6. XML Schema Definition 740 The 'appearance', 'joined-dialog', 'replaced-dialog', and 'exclusive' 741 elements are defined within a new XML namespace URI. This namespace 742 is "urn:ietf:params:xml:ns:sa-dialog-info". The schema for these 743 elements is: 745 746 752 754 755 757 759 761 762 764 766 767 769 771 773 774 776 777 778 779 781 782 783 784 785 787 7. User Interface Considerations 789 The "appearance number" allocated to a call is an important concept 790 that enables calls to be handled by multiple devices with 791 heterogeneous user interfaces in a manner that still allows users to 792 see a consistent model. Careful treatment of the appearance number 793 is essential to meet the expectations of the users. Also, rendering 794 the correct call/appearance state to users is also important. 796 7.1. Appearance Number Rendering 798 Since different UAs have different user interface capabilities, it is 799 usual to find that some UAs have restrictions that others do not. 800 Perfect interoperability across all UAs is clearly not possible, but 801 by careful design, interoperability up to the limits of each UA can 802 be achieved. 804 The following guidelines suggest how the appearance number should be 805 handled in three typical user interface implementations. 807 7.1.1. Single Appearance UAs 809 These devices are constrained by only having the capability of 810 displaying status indications for a single appearance. Despite this, 811 it is important that devices of this type do not ignore the 812 appearance number. The UA should still send messages annotated with 813 an appropriate appearance number (i.e. "0"). Any call indications 814 for appearances other than for number "0" should be rejected with a 815 486 or 480 response. 817 7.1.2. Dual Appearance UAs 819 These devices are essentially single appearance phones that implement 820 call waiting. They have a very simple user interface that allows 821 them to switch between two appearances (toggle or flash hook) and 822 perhaps audible tones to indicate the status of the other appearance. 824 7.1.3. Shared Appearance UAs with Fixed Appearance Number 826 This UA is the typical 'business-class' hard-phone. A number of 827 appearances are typically configured statically and labeled on 828 buttons, and calls may be managed using these configured appearances. 829 Any calls outside this range should be ignored, and not mapped to a 830 free button. Users of these devices often seize specific appearance 831 numbers for outgoing calls, and the UA will need to seize the 832 appearance number and wait for confirmation from the Appearance Agent 833 before proceeding with calls. 835 7.1.4. Shared Appearance UAs with Variable Appearance Number 837 This UA is typically a soft-phone or graphically rich user interface 838 hard-phone. In these cases, even the idea of an appearance index may 839 seem unnecessary. However, for these phones to be able to interwork 840 successfully with other phone types, it is important that they still 841 use the appearance index to govern the order of appearance of calls 842 in progress. No specific guidance on presentation is given except 843 that the order should be consistent. These devices can typically 844 make calls without waiting for confirmation from the Appearance Agent 845 on the appearance number. 847 The problems faced by each style of user interface are readily seen 848 in this example: 850 1. A call arrives at the shared appearance group, and is assigned an 851 appearance number of 0. All UAs should be able to render to the 852 user the arrival of this call. 853 2. Another call arrives at the shared appearance group, and is 854 assigned an appearance number of 1. The single appearance UA 855 should not present this call to the user. Other user agents 856 should have no problems presenting this call distinctly from the 857 first call. 858 3. The first call clears, releasing appearance number "0". The 859 single appearance UA should now be indicating no calls since it 860 is unable to manage calls other than on the first appearance. 861 Both shared appearance UAs should clearly show that appearance 862 number 0 is now free, but that there is still a call on 863 appearance number 1. 864 4. A third call arrives, and is assigned the appearance number of 0. 865 All UAs should be able to render the arrival of this new call to 866 the user. Multiple appearance UAs should continue to indicate 867 the presence of the second call, and should also ensure that the 868 presentation order is related to the appearance number and not 869 the order of call arrival. 871 7.2. Call State Rendering 873 UAs that implement the shared appearance feature typically have a 874 user interface that provides the state of other appearances in the 875 group. As dialog state NOTIFYs from the Appearance Agent are 876 processed, this information can be rendered. Even the simplest user 877 interface typically has three states: idle, active, and hold. The 878 idle state, usually indicated by lamp off, is indicated for an 879 appearance when the appearance number is not associated with any 880 dialogs, as reported by the Appearance Agent. The active state, 881 usually indicated by a lamp on, is indicated by an appearance number 882 being associated with at least one dialog, as reported by the 883 Appearance Agent. The hold state, often indicated by a blinking 884 lamp, means the call state from the perspective of the UA in the 885 shared appearance group is hold. This can be determined by the 886 presence of the "sip+rendering=no" feature tag [RFC3840] with the 887 local target URI. Note that the hold state of the remote target URI 888 is not relevant to this display. For joined dialogs, the state is 889 rendered as hold only if all local target URIs are indicated with the 890 "sip+rendering=no" feature tag. 892 8. Interop with non-Shared Appearance UAs 894 It is desirable to allow a basic UA that does not directly support 895 shared appearance to be part of a shared appearance group. To 896 support this the Proxy must collaborate with the Appearance Agent. 897 This is not required in the basic shared appearance architecture, 898 consequently shared appearance interop with non-shared appearance UAs 899 will not be available in all shared appearance deployments. 901 First, a UA which does not support dialog events or the shared 902 appearance feature will be discussed. Then, a UA which does support 903 dialog events but not the shared appearance feature will be 904 discussed. 906 8.1. Appearance Assignment 908 A UA that has no knowledge of appearances must will only have 909 appearance numbers for outgoing calls if assigned by the Appearance 910 Agent. If the non-shared appearance UA does not support Join or 911 Replaces, all dialogs could be marked "exclusive" to indicate that 912 these options are not available. 914 8.2. Appearance Release 916 In all cases the Appearance Agent must be aware of dialog lifetime to 917 release appearances back into the group. 919 It is also desirable that any dialog state changes (such as hold, 920 etc) be made available to other UAs in the group through the Dialog 921 Event Package. If the Appearance Agent includes a proxy which 922 Record-Routes for dialogs from the non-shared appearance aware UA, 923 the Appearance Agent will know about the state of dialogs including 924 hold, etc. This information could be determined from inspection of 925 INVITE and re-INVITE messages and added to the dialog information 926 conveyed to other UAs. 928 8.3. UAs Supporting Dialog Events but Not Shared Appearance 930 Interoperability with UAs which support dialog events but not the 931 shared appearance feature is more straightforward. As before, all 932 appearance number assignment must be done by the Appearance Agent. 933 The Appearance Agent can include appearance information in NOTIFYs - 934 this UA will simply ignore this extra information. This type of UA 935 will ignore appearance number limitations and may attempt to Join or 936 Replace dialogs marked exclusive. As a result, the Proxy or UAs may 937 need to reject such requests. 939 9. Provisioning Considerations 941 UAs can automatically discover if this feature is active for an AOR 942 by sending a SUBSCRIBE to the AOR, so no provisioning for this is 943 needed. 945 The registrar will need to be provisioned to accept either first or 946 third party registrations for the shared AOR. First party 947 registration means the To and From URIs in the REGISTER request are 948 the shared AOR URI. Third party registration means the To URI is the 949 shared AOR URI and the From URI is a different AOR, perhaps that of 950 the individual user. Either the credentials of the shared AOR or the 951 user MUST be accepted by the registrar and the Appearance Agent, 952 depending on the authorization policy in place for the domain. 954 If the Appearance Agent needs to subscribe to the dialog state of the 955 UAs, then the Appearance Agent and the UAs need to be provisioned 956 with credentials so the UAs can authenticate the Appearance Agent. 958 In some cases, UAs in the shared appearance group might have a UI 959 limitation on the number of appearances that can be rendered. 960 Typically this will be hard phones with buttons/lamps instead of more 961 flexible UIs. In this case, it can be useful for the Appearance 962 Agent to know this maximum number. This can allow the Appearance 963 Agent to apply policy when this limit is reached, e.g. deny a call. 964 However, this mechanism does not provide any way to discover this by 965 protocol means. 967 10. Example Message Flows 969 The next section shows call flow and message examples. The flows and 970 descriptions are non-normative. Note that in these examples, all 971 INVITEs sent by a UA in the group will be From the shared AOR 972 (sip:HelpDesk@example.com in this case), and all INVITES sent to the 973 group will have a Request-URI of the shared AOR. Any other requests 974 would not apply to this feature and would be handled using normal SIP 975 mechanisms. 977 Note that the first twelve examples assume the Appearance Agent is 978 aware of dialog state events. Example 10.13 shows the case where 979 this is not the case and as a result the Appearance Agent initiates a 980 subscription to users of the shared AOR. Any of the other call flow 981 examples could have shown this mode of operation as it is equally 982 valid. 984 10.1. Registration and Subscription 986 Bob and Alice are in an appearance group identified by the shared 987 appearance AOR sip:HelpDesk@example.com. Bob REGISTERs using contact 988 sip:bob@ua2.example.com. Alice REGISTERs with contact 989 sip:alice@ua1.example.com. 991 User Agents for Alice and Bob subscribe to the dialog package for the 992 appearance AOR and publish dialog state to the Appearance Agent. 993 Message exchanges between the Registrar, Appearance Agent, Alice, and 994 Bob are shown below. The call flow examples below do not show the 995 authentication of subscriptions, publications, and notifications. It 996 should be noted that for security purposes, all subscriptions must be 997 authorized before the same is accepted. 999 Also note that registrations and subscriptions must all be refreshed 1000 by Alice at intervals determined by the expiration intervals returned 1001 by the Registrar or Appearance Agent. 1003 Registrar Appearance Agent Alice Bob 1004 | | | | 1005 | | | | 1006 |<--------------------------- REGISTER F1<| | 1007 | | | | 1008 |>F2 200 OK ----------------------------->| | 1009 | | | | 1010 | |<----- SUBSCRIBE F3<| | 1011 | | | | 1012 | |>F4 200 OK -------->| | 1013 | | | | 1014 | |>F5 NOTIFY -------->| | 1015 | | | | 1016 | |<-------- 200 OK F6<| | 1017 | | | | 1018 |<-------------------------------------------- REGISTER F7<| 1019 | | | | 1020 |>F8 200 OK ---------------------------------------------->| 1021 | | | | 1022 | |<---------------------- SUBSCRIBE F9<| 1023 | | | | 1024 | |>F10 200 OK ------------------------>| 1025 | | | | 1026 | |>F11 NOTIFY ------------------------>| 1027 | | | | 1028 | |<------------------------ 200 OK F12<| 1029 | | | | 1031 Figure 1. 1033 F1-F2: Alice registers AOR with 1034 contact: 1036 F1 Alice ----> Registrar 1038 REGISTER sip:registrar.example.com SIP/2.0 1039 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09 1040 From: ;tag=CDF9A668-909E2BDD 1041 To: 1042 CSeq: 2 REGISTER 1043 Call-ID: d3281184-518783de-cc23d6bb 1044 Contact: 1045 Max-Forwards: 70 1046 Expires: 3600 1047 Content-Length: 0 1049 F2 Registrar ----> Alice 1051 SIP/2.0 200 OK 1052 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKfbf176ef7F1D5FA2 1053 CSeq: 2 REGISTER 1054 Call-ID: d3281184-518783de-cc23d6bb 1055 From: ;tag=CDF9A668-909E2BDD 1056 To: ;tag=1664573879820199 1057 Contact: 1058 Expires: 3600 1059 Content-Length: 0 1061 F3 to F6: Alice also subscribes to the events associated with the 1062 Appearance AOR. Appearance Agent notifies Alice of the status. 1064 F3 Alice ----> Appearance Agent 1066 SUBSCRIBE sip:HelpDesk@example.com SIP/2.0 1067 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A 1068 From: ;tag=925A3CAD-CEBB276E 1069 To: 1070 CSeq: 91 SUBSCRIBE 1071 Call-ID: ef4704d9-bb68aa0b-474c9d94 1072 Contact: 1073 Event: dialog;shared 1074 Accept: application/dialog-info+xml 1075 Max-Forwards: 70 1076 Expires: 3700 1077 Content-Length: 0 1079 F4 Appearance Agent ----> Alice 1081 SIP/2.0 200 OK 1082 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A 1083 CSeq: 91 SUBSCRIBE 1084 Call-ID: ef4704d9-bb68aa0b-474c9d94 1085 From: ;tag=925A3CAD-CEBB276E 1086 To: ;tag=1636248422222257 1087 Allow-Events: dialog 1088 Expires: 3700 1089 Contact: 1090 Content-Length: 0 1092 F5 Appearance Agent ----> Alice 1094 NOTIFY sip:alice@ua1.example.com SIP/2.0 1095 From: ;tag=1636248422222257 1096 To: ;tag=925A3CAD-CEBB276E 1097 Call-ID: ef4704d9-bb68aa0b-474c9d94 1098 CSeq: 232 NOTIFY 1099 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1846 1100 Max-Forwards: 70 1101 Content-Type: application/dialog-info+xml 1102 Event: dialog;shared 1103 Subscription-State: active 1104 Contact: 1105 Content-Length: ... 1107 1108 1112 1113 F6 Alice ----> Appearance Agent 1115 SIP/2.0 200 OK 1116 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1846 1117 From: ;tag=1636248422222257 1118 To: ;tag=925A3CAD-CEBB276E 1119 CSeq: 232 NOTIFY 1120 Call-ID: ef4704d9-bb68aa0b-474c9d94 1121 Contact: 1122 Event: dialog;shared 1123 Content-Length: 0 1125 F7 Bob ----> Registrar 1127 REGISTER sip:registrar.example.com SIP/2.0 1128 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4b53b54d87B 1129 From: ;tag=34831131 1130 To: 1131 CSeq: 72 REGISTER 1132 Call-ID: 139490230230249348 1133 Contact: 1134 Max-Forwards: 70 1135 Expires: 3600 1136 Content-Length: 0 1138 F8 Registrar ----> Bob 1140 SIP/2.0 200 OK 1141 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4b53b54d87B 1142 From: ;tag=34831131 1143 To: ;tag=fkwlwqi1 1144 CSeq: 72 REGISTER 1145 Call-ID: 139490230230249348 1146 Contact: ;expires=3200 1147 Contact: ;expires=3600 1148 Content-Length: 0 1150 10.2. Appearance Selection for Incoming Call 1152 In the call flow below Bob and Alice are in an appearance group. 1153 Carol places a call to the appearance group AOR. The Appearance 1154 Agent sends NOTIFYs to Alice and Bob telling them what appearance the 1155 call is using. Both Alice and Bob's devices are alerted of the 1156 incoming call. Bob answers the call. 1158 Note that it is possible that both Alice and Bob answer the call and 1159 send 200 OK responses to Carol. It is up to Carol to resolve this 1160 situation. Typically, Carol will send ACKs to both 200 OKs but send 1161 a BYE to terminate one of the dialogs. As a result, either Alice or 1162 Bob will receive the BYE and publish that their dialog is over. 1163 However, if Carol answers both Alice and Bob and keeps both dialogs 1164 active, then the Appearance Agent will need to resolve the situation 1165 by moving either Alice or Bob's dialog to a different appearance. 1167 All NOTIFY messages in the call flow below carry dialog events and 1168 only dialog states are mentioned for simplicity. For brevity, the 1169 details of some messages are not shown below. Note that the order of 1170 F2 - F5 and F7 - F8 could be reversed. 1172 Forking Appearance 1173 Carol Proxy Agent Alice Bob 1174 | | | | | 1175 |>F1 INVITE >| | | | 1176 | |< - - - - - >| | | 1177 | | |>F2 NOTIFY ----------->| 1178 | | | | | 1179 | | |F4 NOTIFY ->| | 1182 | | | | | 1183 | | |<-200 OK F5-<| | 1184 |<- 100 F6 -<| | | | 1185 | |>F7 INVITE (appearance=1) ---------->| 1186 | | | | | 1187 | |>F8 INVITE (appearance=1) >| | 1188 | | | | | 1189 | |<-------------------- Ringing 180 F9<| 1190 |< 180 F10 -<| | | | 1191 | |<--------- 180 Ringing F11<| | 1192 |< 180 F12 -<| | | | 1193 | | | | | 1194 | |<------------------------ 200 OK F13<| 1195 |< 200 F14 -<| | | | 1196 | | | | | 1197 | |>F15 CANCEL -------------->| | 1198 | | | | | 1199 | |<-------------- 200 OK F16<| | 1200 | | | | | 1201 | |F18 ACK ----------------->| | 1204 |>F19 ACK -->| | | | 1205 | |>F20 ACK --------------------------->| 1206 | | | | | 1207 |<=============Both way RTP established===========>| 1208 | | | | | 1209 | |< - - - - - >| | | 1210 | | | | | 1211 | | |>F21 NOTIFY >| | 1212 | | | | | 1213 | | |<- 200 F22 -<| | 1214 | | | | | 1215 | | |>F23 NOTIFY ---------->| 1216 | | | | | 1217 | | | Alice 1224 NOTIFY sip:alice@ua1.example.com SIP/2.0 1225 From: ;tag=151702541050937 1226 To: ;tag=18433323-C3D237CE 1227 Call-ID: 1e361d2f-a9f51109-bafe31d4 1228 CSeq: 12 NOTIFY 1229 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1403 1230 Max-Forwards: 70 1231 Content-Type: application/dialog-info+xml 1232 Event: dialog;shared 1233 Subscription-State: active 1234 Contact: 1235 Content-Length: ... 1237 1238 1243 1247 1 1248 trying 1249 1250 sip:carol@ua.example.com 1252 1253 1254 1256 F7 Proxy ----> Bob 1258 INVITE sip:bob@ua2.example.com SIP/2.0 1259 Via: SIP/2.0/UDP ua3.example.com;branch=z9hG4bK4324ea 1260 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK38432ji 1261 From: ;tag=44BAD75D-E3128D42 1262 To: 1263 CSeq: 106 INVITE 1264 Call-ID: 14-1541707345 1265 Contact: 1266 Max-Forwards: 69 1267 Alert-Info: ;appearance=1 1268 Content-Type: application/sdp 1269 Content-Length: ... 1271 v=0 1272 o=- 1102980499 1102980499 IN IP4 ua3.example.com 1273 s= 1274 c=IN IP4 ua3.example.com 1275 t=0 0 1276 m=audio 2238 RTP/AVP 0 8 101 1277 a=rtpmap:0 PCMU/8000 1278 a=rtpmap:8 PCMA/8000 1279 a=rtpmap:101 telephone-event/8000 1281 F21 Appearance Agent ----> Alice 1283 NOTIFY sip:alice@ua1.example.com SIP/2.0 1284 From: ;tag=151702541050937 1285 To: ;tag=18433323-C3D237CE 1286 Call-ID: 1e361d2f-a9f51109-bafe31d4 1287 CSeq: 12 NOTIFY 1288 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1403 1289 Max-Forwards: 70 1290 Content-Type: application/dialog-info+xml 1291 Event: dialog;shared 1292 Subscription-State: active 1293 Contact: 1294 Content-Length: ... 1296 1297 1302 1307 1 1308 confirmed 1309 1310 sip:bob@ua2.example.com 1311 1312 1313 sip:carol@ua.example.com 1314 1315 1316 1318 10.3. Outgoing Call without Appearance Seizure 1320 In this scenario, Bob's UA places a call without first selecting/ 1321 seizing an appearance number. After Bob sends the INVITE, the 1322 appearance assigns an appearance number for it and notifies both 1323 Alice and Bob. 1325 Carol Proxy Alice Appearance Agent Bob 1326 | | | | | 1327 | | | | | 1328 | |<------------------------------------- INVITE F1<| 1329 | | | | | 1330 | |>F2 100 Trying --------------------------------->| 1331 |<-- INVITE F3<| | | | 1332 | |< - - - - - - - - - - - - - ->| | 1333 | | | | | 1334 | | |<-- NOTIFY F4<| | 1335 | | | | | 1336 | | |>F5 200 OK -->| | 1337 | | | |------- NOTIFY F6>| 1338 | | | | | 1339 | | | |F8 180 ---->| | | | 1341 | |>F9 180 Ringing -------------------------------->| 1342 | | | | | 1343 | |< - - - - - - - - - - - - - ->| | 1344 | | | | | 1345 | | |<- NOTIFY F10<| | 1346 | | | | | 1347 | | |>F11 200 OK ->| | 1348 | | | |------ NOTIFY F12>| 1349 | | | | | 1350 | | | |F14 200 OK ->| | | | 1352 | |>F15 200 OK ------------------------------------>| 1353 | | | | | 1354 | |<--------------------------------------- ACK F16<| 1355 |<---- ACK F17<| | | | 1356 | | | | | 1357 |<================= Both way RTP established ===================>| 1358 | | | | | 1359 | |< - - - - - - - - - - - - - ->| | 1360 | | | | | 1361 | | |<- NOTIFY F18<| | 1362 | | | | | 1363 | | |>F19 200 OK ->| | 1364 | | | |------ NOTIFY F20>| 1365 | | | | | 1366 | | | | Proxy 1373 INVITE sip:carol@example.com SIP/2.0 1374 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK98c87c52123A08BF 1375 From: ;tag=15A3DE7C-9283203B 1376 To: 1377 CSeq: 1 INVITE 1378 Call-ID: f3b3cbd0-a2c5775e-5df9f8d5 1379 Contact: 1380 Max-Forwards: 70 1381 Content-Type: application/sdp 1382 Content-Length: 223 1384 v=0 1385 o=- 1102980499 1102980499 IN IP4 ua2.example.com 1386 s=IP SIP UA 1387 c=IN IP4 ua2.example.com 1388 t=0 0 1389 a=sendrecv 1390 m=audio 2236 RTP/AVP 0 8 101 1391 a=rtpmap:0 PCMU/8000 1392 a=rtpmap:8 PCMA/8000 1393 a=rtpmap:101 telephone-event/8000 1395 F4 Appearance Agent ----> Alice 1397 NOTIFY sip:alice@ua1.example.com SIP/2.0 1398 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK81d84f62 1399 From: ;tag=1636248422222257 1400 To: ;tag=925A3CAD-CEBB276E 1401 Call-ID: ef4704d9-bb68aa0b-474c9d94 1402 CSeq: 233 NOTIFY 1403 Max-Forwards: 70 1404 Content-Type: application/dialog-info+xml 1405 Event: dialog;shared 1406 Subscription-State: active 1407 Contact: 1408 Content-Length: ... 1410 1411 1416 1419 0 1420 false 1421 trying 1422 1423 1424 1425 1426 1427 1429 F6 Appearance Agent ----> Bob 1431 NOTIFY sip:bob@ua1.example.com SIP/2.0 1432 From: ;tag=497585728578386 1433 To: ;tag=633618CF-B9C2EDA4 1434 Call-ID: a7d559db-d6d7dcad-311c9e3a 1435 CSeq: 7 NOTIFY 1436 Via: SIP/2.0/UDP appearanceagent.example.com 1437 ;branch=z9hG4bK1711759878512309 1438 Max-Forwards: 70 1439 Content-Type: application/dialog-info+xml 1440 Event: dialog;shared 1441 Subscription-State: active 1442 Contact: 1443 Content-Length: ... 1445 1446 1451 1454 0 1455 false 1456 trying 1457 1458 1459 1460 1461 1462 1464 10.4. Outgoing Call with Appearance Seizure 1466 In this scenario, Bob's UA sends out a dialog event PUBLISH with 1467 state (trying) selecting/seizing an appearance number before sending 1468 the INVITE. After receiving the 200 OK from the Appearance Agent 1469 confirming the appearance number, Bob's UA sends the INVITE to Carol 1470 and establishes a session. For brevity, details of some of the 1471 messages are not included in the message flows. 1473 Carol Proxy Alice Appearance Agent Bob 1474 | | | | | 1475 | | | |<----- PUBLISH F1<| 1476 | | | | | 1477 | | | |>F2 200 OK ------>| 1478 | | | | | 1479 | | |<-- NOTIFY F3<| | 1480 | | | | | 1481 | | |>F4 200 OK -->| | 1482 | | | |------- NOTIFY F5>| 1483 | | | | | 1484 | | | |F8 100 Trying --------------------------------->| 1489 |<-- INVITE F9<| | | | 1490 | | | |<---- PUBLISH F10<| 1491 | | | | | 1492 | | | |>F11 200 OK ----->| 1493 | | | | | 1494 |>F12 180 --->| | | | 1495 | |>F13 180 Ringing ------------------------------->| 1496 | | | | | 1497 | |< - - - - - - - - - - - - - ->| | 1498 | | | | | 1499 | | |<- NOTIFY F14<| | 1500 | | | | | 1501 | | |>F15 200 OK ->| | 1502 | | | |------ NOTIFY F16>| 1503 | | | | | 1504 | | | |F18 200 OK ->| | | | 1506 | |>F19 200 OK ------------------------------------>| 1507 | | | | | 1508 | |<--------------------------------------- ACK F20<| 1509 |<---- ACK F21<| | | | 1510 | | | | | 1511 |<================= Both way RTP established ===================>| 1512 | | | | | 1513 | |< - - - - - - - - - - - - - ->| | 1514 | | | | | 1515 | | |<- NOTIFY F22<| | 1516 | | | | | 1517 | | |>F23 200 OK ->| | 1518 | | | |------ NOTIFY F24>| 1519 | | | | | 1520 | | | | Appearance Agent 1536 PUBLISH sip:HelpDesk@example.com SIP/2.0 1537 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 1538 From: ;tag=44150CC6-A7B7919D 1539 To: 1540 CSeq: 7 PUBLISH 1541 Call-ID: 44fwF144-F12893K38424 1542 Contact: 1543 Event: dialog;shared 1544 Max-Forwards: 70 1545 Content-Type: application/dialog-info+xml 1546 Content-Length: ... 1548 1549 1554 1555 0 1556 false 1557 trying 1558 1559 1560 1561 1562 1563 1565 F2 Appearance Agent ----> Bob 1567 SIP/2.0 200 OK 1568 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 1569 From: ;tag=44150CC6-A7B7919D 1570 To: 1571 CSeq: 7 PUBLISH 1572 Call-ID: 44fwF144-F12893K38424 1573 Contact: 1574 Event: dialog;shared 1575 SIP-Etag: 482943245 1576 Allow-Events: dialog 1577 Expires: 60 1578 Content-Length: 0 1579 F7 Bob ---> Proxy 1581 INVITE sip:carol@example.com SIP/2.0 1582 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK342122 1583 Max-Forwards: 70 1584 From: ;tag=15A3DE7C-9283203B 1585 To: 1586 Call-ID: f3b3cbd0-a2c5775e-5df9f8d5 1587 CSeq: 31 INVITE 1588 Contact: 1589 Content-Type: application/sdp 1590 Content-Length: ... 1592 (SDP Not Shown) 1594 F10 Bob ----> Appearance Agent 1596 PUBLISH sip:HelpDesk@example.com SIP/2.0 1597 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK6d644638E7 1598 From: ;tag=0CCf6-A7FdsB79D 1599 To: 1600 CSeq: 437 PUBLISH 1601 Call-ID: fwF14d4-F1FFF2F2893K38424 1602 Contact: 1603 Event: dialog;shared 1604 Max-Forwards: 70 1605 Content-Type: application/dialog-info+xml 1606 Content-Length: ... 1608 1609 1614 1618 0 1619 false 1620 trying 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1632 10.5. Outgoing Call without using an Appearance Number 1634 In this scenario, Bob's UA sends out a dialog event PUBLISH with 1635 state (trying) indicating that he does not want to utilize an 1636 appearance number for this dialog. The PUBLISH does not have an 1637 appearance element but does have the 'shared' dialog event parameter. 1638 As a result, the Appearance Agent knows the UA does not wish to use 1639 an appearance number for this call. If the Appearance Agent does not 1640 wish to allow this, it would reject the PUBLISH with a 409 Conflict 1641 response and the UA would know to re-PUBLISH selecting/seizing an 1642 appearance number. 1644 Carol Proxy Alice Appearance Agent Bob 1645 | | | | | 1646 | | | |<----- PUBLISH F1<| 1647 | | | | | 1648 | | | |>F2 200 OK ------>| 1649 | | | | | 1650 | | |<-- NOTIFY F3<| | 1651 | | | | | 1652 | | |>F4 200 OK -->| | 1653 | | | |------- NOTIFY F5>| 1654 | | | | | 1655 | | | |F8 100 Trying --------------------------------->| 1660 |<-- INVITE F9<| | | | 1661 | | | |<---- PUBLISH F10<| 1662 | | | | | 1663 | | | |>F11 200 OK ----->| 1664 | | | | | 1665 |>F12 180 --->| | | | 1666 | |>F13 180 Ringing ------------------------------->| 1667 | | | | | 1668 | |< - - - - - - - - - - - - - ->| | 1669 | | | | | 1670 | | |<- NOTIFY F14<| | 1671 | | | | | 1672 | | |>F15 200 OK ->| | 1673 | | | |------ NOTIFY F16>| 1674 | | | | | 1675 | | | |F18 200 OK ->| | | | 1677 | |>F19 200 OK ------------------------------------>| 1678 | | | | | 1679 | |<--------------------------------------- ACK F20<| 1680 |<---- ACK F21<| | | | 1681 | | | | | 1682 |<================= Both way RTP established ===================>| 1683 | | | | | 1684 | |< - - - - - - - - - - - - - ->| | 1685 | | | | | 1686 | | |<- NOTIFY F22<| | 1687 | | | | | 1688 | | |>F23 200 OK ->| | 1689 | | | |------ NOTIFY F24>| 1690 | | | | | 1691 | | | | Appearance Agent 1698 PUBLISH sip:appearanceagent.example.com SIP/2.0 1699 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 1700 From: ;tag=4415df82k39sf 1701 To: 1702 CSeq: 7 PUBLISH 1703 Call-ID: 44fwF144-F12893K38424 1704 Contact: 1705 Event: dialog;shared 1706 Max-Forwards: 70 1707 Content-Type: application/dialog-info+xml 1708 Content-Length: ... 1710 1711 1716 1717 false 1718 trying 1719 1720 1721 1722 1723 1724 1726 Note that F7 would be the same as the previous example. 1728 10.6. Appearance Release 1730 Bob and Carol are in a dialog, created, for example as in Section 1731 10.3. Carol sends a BYE to Bob to terminate the dialog and the 1732 Appearance Agent de-allocates the appearance number used, sending 1733 notifications out to the UAs in the shared group. 1735 Carol Proxy Alice Appearance Agent Bob 1736 | | | | | 1737 | | | | | 1738 |<================= Both way RTP established ===================>| 1739 | | | | | 1740 |>F22 BYE ---->| | | | 1741 | |>F23 BYE --------------------------------------->| 1742 | | | | | 1743 | |<------------------------------------ 200 OK F24<| 1744 |<--200 OK F25<| | | | 1745 | |< - - - - - - - - - - - - - ->| | 1746 | | | | | 1747 | | |<- NOTIFY F26<| | 1748 | | | | | 1749 | | |>F27 200 OK ->| | 1750 | | | |------ NOTIFY F28>| 1751 | | | | | 1752 | | | | Bob 1758 NOTIFY sip:bob@ua1.example.com SIP/2.0 1759 From: ;tag=497585728578386 1760 To: 1761 Call-ID: a7d559db-d6d7dcad-311c9e3a 1762 CSeq: 7 NOTIFY 1763 Via: SIP/2.0/UDP appearanceagent.example.com 1764 ;branch=z9hG4bK759878512309 1765 Max-Forwards: 70 1766 Content-Type: application/dialog-info+xml 1767 Event: dialog;shared 1768 Subscription-State: active 1769 Contact: 1770 Content-Length: ... 1772 1773 1778 1783 0 1784 false 1785 terminated 1786 1787 1788 1789 1790 1791 1793 10.7. Appearance Pickup 1795 In this scenario, Bob has an established dialog with Carol created 1796 using the call flows of Figure 1 or Figure 2. Bob then places Carol 1797 on hold. Alice receives a notification of this and renders this on 1798 Alice's UI. Alice subsequently picks up the held call and has a 1799 established session with Carol. Finally, Carol hangs up. Alice must 1800 PUBLISH F32 to indicate that the INVITE F38 will be an attempt to 1801 pickup the dialog between Carol and Bob, and hence may use the same 1802 appearance number. 1804 Carol Proxy Alice Appearance Agent Bob 1805 | | | | | 1806 |<================= Both way RTP established ===================>| 1807 | | | | | 1808 | |<------------------------------(hold) INVITE F22<| 1809 |<- INVITE F23<| | | | 1810 | | | | | 1811 |>F24 200 OK ->| | | | 1812 | |>F25 200 OK ------------------------------------>| 1813 | | | | | 1814 | |<--------------------------------------- ACK F26<| 1815 |<---- ACK F27<| | | | 1816 | |< - - - - - - - - - - - - - ->| | 1817 | | | | | 1818 | | |<- NOTIFY F28<| | 1819 | | | | | 1820 | | |>F29 200 OK ->| | 1821 | | | |>F30 NOTIFY ----->| 1822 | | | | | 1823 | | | |<----- 200 OK F31<| 1824 | | | | | 1825 | | Alice decides to pick up the call | 1826 | | | | | 1827 | | |>F32 PUBLISH->| | 1828 | | | | | 1829 | | |<- 200 OK F33<| | 1830 | | | | | 1831 | | |<- NOTIFY F34<| | 1832 | | | | | 1833 | | |>F35 200 OK ->| | 1834 | | | |>F36 NOTIFY ----->| 1835 | | | | | 1836 | | | |<----- 200 OK F37<| 1837 | |<-- INVITE F38<| | | 1838 |<- INVITE F39<|(w/ Replaces) | | | 1839 |( w/ Replaces)| | | | 1840 |>F40 200 OK ->| | | | 1841 | |>F41 200 OK -->| | | 1842 | | | | | 1843 | |< - - - - - - - - - - - - - ->| | 1844 | | | | | 1845 | | | |>F42 NOTIFY ----->| 1846 | | | | | 1847 | | | |<----- 200 OK F43<| 1848 | | |<- NOTIFY F44<| | 1849 | | | | | 1850 | | |>F45 200 OK ->| | 1851 | | | | | 1852 | |<----- ACK F46<| | | 1853 |<---- ACK F47<| | | | 1854 | | | | | 1855 |<= Both way RTP established =>| | | 1856 | | | | | 1857 |>F48 BYE ---->| | | | 1858 | |>F49 BYE --------------------------------------->| 1859 | | | | | 1860 | |<------------------------------------ OK 200 F50<| 1861 |<- 200 OK F51<| | | | 1862 | | | | | 1863 | |< - - - - - - - - - - - - - ->| | 1864 | | | | | 1865 | | |<- NOTIFY F52<| | 1866 | | | | | 1867 | | |>F53 200 OK ->| | 1868 | | | | | 1869 | | | |>F54 NOTIFY ----->| 1870 | | | | | 1871 | | | |<----- 200 OK F55<| 1873 Figure 7. 1875 F28 Appearance ----> Alice 1877 NOTIFY sip:alice@ua1.example.com SIP/2.0 1878 From: ;tag=151702541050937 1879 To: ;tag=18433323-C3D237CE 1880 Call-ID: 1e361d2f-a9f51109-bafe31d4 1881 CSeq: 12 NOTIFY 1882 Via: SIP/2.0/UDP appearanceagent.example.com 1883 ;branch=z9hG4bK1403 1884 Max-Forwards: 70 1885 Content-Type: application/dialog-info+xml 1886 Event: dialog;shared 1887 Subscription-State: active 1888 Contact: 1889 Content-Length: ... 1891 1892 1897 1902 0 1903 false 1904 active 1905 1906 1907 1908 1909 1910 1911 sip:carol@example.com 1912 1913 1914 1915 1917 F32 Alice ----> Appearance Agent 1919 PUBLISH sip:HelpDesk@example.com SIP/2.0 1920 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A 1921 From: ;tag=44150CC6-A7B7919D 1922 To: ;tag=428765950880801 1923 CSeq: 11 PUBLISH 1924 Call-ID: 87837Fkw87asfds 1925 Contact: 1926 Event: dialog;shared 1927 Max-Forwards: 70 1928 Content-Type: application/dialog-info+xml 1929 Content-Length: ... 1931 1932 1937 1940 0 1941 false 1942 1946 trying 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 F38 Alice ----> Proxy 1959 INVITE sip:carol@example.com SIP/2.0 1960 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK4ea695b5B376A60C 1961 From: ;tag=8C4183CB-BCEAB710 1962 To: 1963 CSeq: 1 INVITE 1964 Call-ID: 3d57cd17-47deb849-dca8b6c6 1965 Contact: 1966 1967 Replaces: f3b3cbd0-a2c5775e-5df9f8d5;to-tag=65a98f7c 1968 -1dd2-11b2-88c6-b03162323164+65a98f7c;from-tag=15A3DE7C-9283203B 1969 1970 Max-Forwards: 70 1971 Content-Type: application/sdp 1972 Content-Length: 223 1974 v=0 1975 o=- 1102980497 1102980497 IN IP4 ua1.example.com 1976 s=IP SIP UA 1977 c=IN IP4 ua1.example.com 1978 t=0 0 1979 a=sendrecv 1980 m=audio 2238 RTP/AVP 0 8 101 1981 a=rtpmap:0 PCMU/8000 1982 a=rtpmap:8 PCMA/8000 1983 a=rtpmap:101 telephone-event/8000 1985 10.8. Calls between UAs within the Group 1987 In this scenario, Bob calls Alice who is also in the Appearance 1988 group. 1990 Carol Proxy Alice Appearance Agent Bob 1991 | | | | | 1992 | |<-------------------- INVITE (to Alice's UA) F1<| 1993 | | | | | 1994 | |< - - - - - - - - - - - - - ->| | 1995 | | | | | 1996 | | | | | 1997 | | |<-- NOTIFY F2<| | 1998 | | | | | 1999 | | |>F3 200 OK -->| | 2000 | | | |>F4 NOTIFY ------>| 2001 | | | | | 2002 | | | |<------ 200 OK F5<| 2003 | |>F6 INVITE --->| | | 2004 | | (appearance=1)| | | 2005 | | | | | 2006 | |<------ 180 F7<| | | 2007 | | | | | 2008 | |>F8 180 --------------------------------------->| 2009 | | | | | 2010 | |< - - - - - - - - - - - - - ->| | 2011 | | | | | 2012 | | |<-- NOTIFY F9<| | 2013 | | | | | 2014 | | |>F10 200 OK ->| | 2015 | | | |>F11 NOTIFY ----->| 2016 | | | | | 2017 | | | |<----- 200 OK F12<| 2018 | |<-- 200 OK F13<| | | 2019 | | | | | 2020 | |>F14 200 OK ------------------------------------>| 2021 | | | | | 2022 | |<--------------------------------------- ACK F15<| 2023 | | | | | 2024 | |>F16 ACK ----->| | | 2025 | | | | | 2026 | | |<======= RTP established =======>| 2027 | | | | | 2028 | |< - - - - - - - - - - - - - ->| | 2029 | | | | | 2030 | | |<- NOTIFY F17<| | 2031 | | | | | 2032 | | |>F18 200 OK ->| | 2033 | | | |>F19 NOTIFY ----->| 2034 | | | | | 2035 | | | |<----- 200 OK F24<| 2036 | | | | | 2038 Figure 8. 2040 F19 Appearance Agent ----> Bob 2042 NOTIFY sip:bob@ua1.example.com SIP/2.0 2043 From: ;tag=497585728578386 2044 To: ;tag=633618CF-B9C2EDA4 2045 Call-ID: a7d559db-d6d7dcad-311c9e3a 2046 CSeq: 7 NOTIFY 2047 Via: SIP/2.0/UDP appearanceagent.example.com 2048 ;branch=z9hG4bK1711759878512309 2049 Max-Forwards: 70 2050 Content-Type: application/dialog-info+xml 2051 Event: dialog;shared 2052 Subscription-State: active 2053 Contact: 2054 Content-Length: ... 2056 2057 2062 2067 true 2068 1 2069 confirmed 2070 2071 2072 2073 2074 2075 sip:HelpDesk@example.com 2076 2077 2078 2080 2085 true 2086 1 2087 confirmed 2088 2089 2090 2091 2092 sip:HelpDesk@example.com 2093 2094 2095 2097 2099 10.9. Consultation Hold with Appearances 2101 In this scenario, Bob has a call with Carol. Bob makes a 2102 consultation call to Alice by putting Carol on hold and calling 2103 Alice. Bob chooses not to have an appearance number for the call to 2104 Alice since he is treating it as part of the call to Carol. He 2105 indicates this in his PUBLISH F32 which contains the 'shared' Event 2106 parameter but no element. The PUBLISH is sent before 2107 the INVITE to Alice to ensure no appearance number is assigned by the 2108 Appearance Agent. Finally, Bob hangs up with Alice and resumes the 2109 call with Carol. Note that the Appearance Agent does not generate 2110 notifications on the dialog state of the consultation call. 2112 Note that if Carol hangs up while Bob is consulting with Alice, Bob 2113 can decide if he wants to reuse the appearance number used with Carol 2114 for the call with Alice. If not, Bob publishes the termination of 2115 the dialog with Carol and the Appearance Agent will re-allocate the 2116 appearance. If he wants to keep the appearance, Bob will publish the 2117 termination of the dialog with Carol and also publish the appearance 2118 with the dialog with Alice. This will result in Bob keeping the 2119 appearance number until he reports the dialog with Alice terminated. 2121 Carol Proxy Alice Appearance Agent Bob 2122 | | | | | 2123 |<================= Both way RTP established ===================>| 2124 | | | | | 2125 | |<------------------------------(hold) INVITE F22<| 2126 |<- INVITE F23<| | | | 2127 | | | | | 2128 |>F24 200 OK ->| | | | 2129 | |>F25 200 OK ------------------------------------>| 2130 | | | | | 2131 | |<--------------------------------------- ACK F26<| 2132 |<---- ACK F27<| | | | 2133 | |< - - - - - - - - - - - - - ->| | 2134 | | | | | 2135 | | |<- NOTIFY F28<| | 2136 | | | | | 2137 | | |>F29 200 OK ->| | 2138 | | | |>F30 NOTIFY ----->| 2139 | | | | | 2140 | | | |<----- 200 OK F31<| 2141 | | | | | 2142 | | Bob makes a consultation call to Alice | 2143 | | | | | 2144 | | | |<---- PUBLISH F32<| 2145 | | | | | 2146 | | | |>F33 200 OK ----->| 2147 | | | | | 2148 | |<------------------------------------ INVITE F34<| 2149 | | | | | 2150 | |>F35 INVITE -->| | | 2151 | | | | | 2152 | |<-- 200 OK F36<| | | 2153 | | | | | 2154 | |>F37 200 OK ------------------------------------>| 2155 | | | | | 2156 | |<--------------------------------------- ACK F38<| 2157 | | | | | 2158 | |>F39 ACK ----->| | | 2159 | | | | | 2160 | | |<======= RTP established =======>| 2161 | | | | | 2162 | | Bob hangs up with Alice | 2163 | | | | | 2164 | |<--------------------------------------- BYE F40<| 2165 | | | | | 2166 | |>F41 BYE ----->| | | 2167 | | | | | 2168 | |<-- 200 OK F42<| | | 2169 | | | | | 2170 | |>F43 200 OK ------------------------------------>| 2171 | | | | | 2172 | |<----------------------------(unhold) INVITE F44<| 2173 |<- INVITE F45<| | | | 2174 | | | | | 2175 |>F46 200 OK ->| | | | 2176 | |>F47 200 OK ------------------------------------>| 2177 | | | | | 2178 | |<--------------------------------------- ACK F48<| 2179 |<---- ACK F49<| | | | 2180 | |< - - - - - - - - - - - - - ->| | 2181 | | | | | 2182 | | |<- NOTIFY F50<| | 2183 | | | | | 2184 | | |>F51 200 OK ->| | 2185 | | | |>F52 NOTIFY ----->| 2186 | | | | | 2187 | | | |<----- 200 OK F53<| 2188 | | | | | 2189 |<================= Both way RTP established ===================>| 2190 | | | | | 2192 Figure 9. 2194 F32 Bob ----> Appearance Agent 2195 PUBLISH sip:HelpDesk@example.com SIP/2.0 2196 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A 2197 From: ;tag=44150CC6-A7B7919D 2198 To: ;tag=428765950880801 2199 CSeq: 11 PUBLISH 2200 Call-ID: 44fwF144-F12893K38424 2201 Contact: 2202 Event: dialog;shared 2203 Max-Forwards: 70 2204 Content-Type: application/dialog-info+xml 2205 Content-Length: ... 2207 2208 2213 2217 true 2218 trying 2219 2220 2221 2222 2223 2224 sip:HelpDesk@example.com 2225 2226 2227 2228 2230 10.10. Joining or Bridging an Appearance 2232 In this call flow, a call answered by Bob is joined by Alice or 2233 "bridged". The Join header field is used by Alice to request this 2234 bridging. If Bob did not support media mixing, Bob could obtain 2235 conferencing resources as described in [RFC4579]. 2237 Carol Forking Proxy Appearance Agent Alice Bob 2238 | | | | | 2239 |<=============Both way RTP established===========>| 2240 | | | | | 2241 | | |< PUBLISH F22| | 2242 | | | | | 2243 | | |>F23 200 OK >| | 2244 | | | | | 2245 | |<---- INVITE (w/ Join) F24<| | 2246 | | | | | 2247 | |>F25 INVITE (w/Join)---------------->| 2248 | | | | | 2249 | |<---- OK 200 Contact:Bob;isfocus F26<| 2250 | | | | | 2251 | |< - - - - - >| | | 2252 | | | | | 2253 | | |>F27 NOTIFY >| | 2254 | | | | | 2255 | | |< 200 OK F28<| | 2256 | | | | | 2257 | | |>F29 NOTIFY ---------->| 2258 | | | | | 2259 | | |F31 200 OK Contact:B----->| | 2262 | | | | | 2263 | |<----------------- ACK F32<| | 2264 | | | | | 2265 | |>ACK F33---------------------------->| 2266 | | | | | 2267 | |<-----INVITE Contact:Bob;isfocus F34<| 2268 |<-INVITE F35| | | | 2269 | | | | | 2270 |>F26 200 -->| | | | 2271 | |>F37 200 OK ------------------------>| 2272 | | | | | 2273 | |<--------------------------- ACK F38<| 2274 |<--- ACK F39| | | | 2275 | | | |<==RTP==>| 2276 |<=============Both way RTP established===========>| 2277 | | | | | 2278 | |< - - - - - >| | | 2279 | | | | | 2280 | | |>F40 NOTIFY >| | 2281 | | | | | 2282 | | |< 200 OK F41<| | 2283 | | | | | 2284 | | |>F42 NOTIFY ---------->| 2285 | | | | | 2286 | | | Appearance Agent 2293 PUBLISH sip:HelpDesk@example.com SIP/2.0 2294 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A 2295 From: ;tag=44150CC6-A7B7919D 2296 To: ;tag=428765950880801 2297 CSeq: 11 PUBLISH 2298 Call-ID: 87837Fkw87asfds 2299 Contact: 2300 Event: dialog;shared 2301 Max-Forwards: 70 2302 Content-Type: application/dialog-info+xml 2303 Content-Length: ... 2305 2306 2311 2314 0 2315 false 2316 2320 trying 2321 2322 2323 2324 2325 2326 2327 2328 2329 2331 F24 Alice ----> Proxy 2333 INVITE sip:bob@ua.example.com SIP/2.0 2334 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKcc9d727c2C29BE31 2335 From: ;tag=605AD957-1F6305C2 2336 To: 2337 CSeq: 2 INVITE 2338 Call-ID: dc95da63-60db1abd-d5a74b48 2339 Contact: 2340 2341 Join: 14-1541707345;to-tag=d3b06488-1dd1-11b2-88c5 2342 -b03162323164+d3e48f4c;from-tag=44BAD75D-E3128D42 2343 2344 Max-Forwards: 70 2345 Content-Type: application/sdp 2346 Content-Length: 223 2348 v=0 2349 o=- 1103061265 1103061265 IN IP4 ua1.example.com 2350 s=IP SIP UA 2351 c=IN IP4 ua1.example.com 2352 t=0 0 2353 a=sendrecv 2354 m=audio 2236 RTP/AVP 0 8 101 2355 a=rtpmap:0 PCMU/8000 2356 a=rtpmap:8 PCMA/8000 2357 a=rtpmap:101 telephone-event/8000 2359 10.11. Appearance Allocation - Loss of Appearance 2361 Bob reserves an appearance with a PUBLISH, sends an INVITE to Carol, 2362 then becomes unreachable. When he fails to refresh his publication 2363 to the appearance agent, the Appearance Agent declares the dialog 2364 terminated and frees up the appearance using NOTIFYs F14 and F16. 2365 After retransmitting the NOTIFY to Bob (in not shown messages F17, 2366 F18, etc.), the subscription is terminated. 2368 Carol Proxy Alice Appearance Agent Bob 2369 | | | | | 2370 | | | |<----- PUBLISH F1<| 2371 | | | | | 2372 | | | |>F2 200 OK ------>| 2373 | | | | | 2374 | | |<-- NOTIFY F3<| | 2375 | | | | | 2376 | | |>F4 200 OK -->| | 2377 | | | |------- NOTIFY F5>| 2378 | | | | | 2379 | | | |F8 100 Trying --------------------------------->| 2384 |<-- INVITE F9<| | | | 2385 | | | |<---- PUBLISH F10<| 2386 | | | | | 2387 | | | |>F11 200 OK ----->| 2388 | | | | | 2389 |>F12 180 --->| | | | 2390 | |>F13 180 Ringing ------------------------------->| 2391 | | | | | 2392 | | | | Bob goes offline | 2393 | | | | | 2394 | | | Appearance selection times out | 2395 | | | | | 2396 | | |<- NOTIFY F14<| | 2397 | | | | | 2398 | | |>F15 200 OK ->| | 2399 | | | |------ NOTIFY F16>| 2400 | | | | | 2401 | | | NOTIFY is retransmitted | 2403 Figure 11. 2405 10.12. Appearance Seizure Contention Race Condition 2407 Bob and Alice both try to reserve appearance 2 by publishing at the 2408 same time. The Appearance Agent allocates the appearance to Bob by 2409 sending a 200 OK and denies it to Alice by sending a 409 Conflict. 2410 After the NOTIFY F5, Alice learns that Bob is using appearance 2. 2411 Alice republishes for appearance 3 which is accepted. 2413 Carol Proxy Alice Appearance Agent Bob 2414 | | | | | 2415 | | | |<----- PUBLISH F1<| 2416 | | | | (appearance=2) 2417 | | |>F2 PUBLISH ->| | 2418 | | | (appearance=2) | 2419 | | | | | 2420 | | | |>F3 200 OK ------>| 2421 | | |<---- F4 409 <| | 2422 | | | | | 2423 | | |<-- NOTIFY F5<| | 2424 | | | | | 2425 | | |>F6 200 OK -->| | 2426 | | | |------- NOTIFY F7>| 2427 | | | | | 2428 | | | |F10 100 Trying -------------------------------->| 2433 |<- INVITE F11<| | | | 2434 | | | |<---- PUBLISH F12<| 2435 | | | | (appearance=2) 2436 | | | |>F13 200 OK ----->| 2437 | | |>F14 PUBLISH->| | 2438 | | | (appearance=3) | 2439 | | | | | 2440 | | |<--- F15 200 <| | 2441 | | | | | 2442 | | |<- NOTIFY F16<| | 2443 | | | | | 2444 | |>F17 200 OK ->| | 2445 Dave | | |------ NOTIFY F18>| 2446 | | | | | 2447 | | | |F21 100 ----->| | | 2451 |<- INVITE F22<| | | | 2453 Figure 12. 2455 10.13. Appearance Agent Subscription to UAs 2457 In this scenario, the Appearance Agent does not have any way of 2458 knowing Bob's dialog state information, except through Bob. This 2459 could be because the Appearance Agent is not part of a B2BUA, or 2460 perhaps Bob is remotely registering. When Bob registers, the 2461 Appearance Agent receives a registration event package notification 2462 from the registrar. The Appearance Agent then SUBSCRIBEs to Bob's 2463 dialog event state using Event:dialog in the SUBSCRIBE. Whenever 2464 Bob's dialog state changes, a NOTIFY is sent to the Appearance Agent 2465 who then notifies the other other UAs in the group. 2467 Carol Proxy Alice Appearance Agent Bob 2468 | | | | | 2469 | |<----------------------------------- REGISTER F1<| 2470 | | | | | 2471 | |>F2 200 OK ------------------------------------->| 2472 | | | | | 2473 | |>F3 NOTIFY ------------------>| | 2474 | | | | | 2475 | |<------------------ 200 OK F4<| | 2476 | | | |---- SUBSCRIBE F5>| 2477 | | | | | 2478 | | | |F8 200 OK ------>| 2483 | | | | | 2484 | | | |<--- SUBSCRIBE F9<| 2485 | | | | | 2486 | | | |>F10 200 OK ----->| 2487 | | | | | 2488 | | | |------ NOTIFY F11>| 2489 | | | | | 2490 | | | |F14 100 Trying -------------------------------->| 2495 |<- INVITE F15<| | | | 2496 | | | |<----- NOTIFY F16<| 2497 | | | | | 2498 | | | |>F17 200 OK ----->| 2499 | | |<- NOTIFY F18<| | 2500 | | | | | 2501 | | |>F19 200 OK ->| | 2502 | | | |------ NOTIFY F20>| 2503 | | | | | 2504 | | | |F22 180 --->| | | | 2506 | |>F23 180 Ringing ------------------------------->| 2507 | | | | | 2508 | | | |<----- NOTIFY F24<| 2509 | | | | | 2510 | | | |>F25 200 OK ----->| 2511 | | |<- NOTIFY F26<| | 2512 | | | | | 2513 | | |>F27 200 OK ->| | 2514 | | | |------ NOTIFY F28>| 2515 | | | | | 2516 | | | |F30 200 OK ->| | | | 2518 | |>F31 200 OK ------------------------------------>| 2519 | | | | | 2520 | | | |<----- NOTIFY F32<| 2521 | | | | | 2522 | | | |>F33 200 OK ----->| 2523 | | | | | 2524 | |<--------------------------------------- ACK F34<| 2525 |<---- ACK F35<| | | | 2526 | | | | | 2527 |<================= Both way RTP established ===================>| 2528 | | | | | 2529 | | |<- NOTIFY F36<| | 2530 | | | | | 2531 | | |>F37 200 OK ->| | 2532 | | | |------ NOTIFY F38>| 2533 | | | | | 2534 | | | || 2552 | | | | | 2553 | |<------------------------------(hold) INVITE F22<| 2554 |<- INVITE F23<| | | | 2555 | | | | | 2556 |>F24 200 OK ->| | | | 2557 | |>F25 200 OK ------------------------------------>| 2558 | | | | | 2559 | |<--------------------------------------- ACK F26<| 2560 |<---- ACK F27<| | | | 2561 | | | | | 2562 | |< - - - - - - - - - - - - - ->| | 2563 | | | | | 2564 | | |<- NOTIFY F28<| | 2565 | | | | | 2566 | | |>F29 200 OK ->| | 2567 | | | |>F30 NOTIFY ----->| 2568 | | | | | 2569 | | | |<----- 200 OK F31<| 2570 | | | | | 2571 | | Alice decides to pick up the call | 2572 | | | | | 2573 | | |>F32 PUBLISH->| | 2574 | | | | | 2575 | | |<- 200 OK F33<| | 2576 | | | | | 2577 | | |<- NOTIFY F34<| | 2578 | | | | | 2579 | | |>F35 200 OK ->| | 2580 | | | |>F36 NOTIFY ----->| 2581 | | | | | 2582 | | | |<----- 200 OK F37<| 2583 |>F38 BYE ---->| | | | 2584 | |>F39 BYE --------------------------------------->| 2585 | | | | | 2586 | |<------------------------------------ OK 200 F40<| 2587 |<- 200 OK F41<| | | | 2588 | |<-- INVITE F42<| | | 2589 |<- INVITE F43<|(w/ Replaces) | | | 2590 |( w/ Replaces)| | | | 2591 | | | | | 2592 |>F44 481 ---->| | | | 2593 | |>F45 481 ----->| | | 2594 |<---- ACK F46<| | | | 2595 | |<----- ACK F47<| | | 2596 | | |>F48 PUBLISH->| | 2597 | | | | | 2598 | | |<- 200 OK F49<| | 2599 | | | | | 2600 | | |<- NOTIFY F50<| | 2601 | | | | | 2602 | | |>F51 200 OK ->| | 2603 | | | |>F52 NOTIFY ----->| 2604 | | | | | 2605 | | | |<----- 200 OK F53<| 2607 Figure 14. 2609 F48 Alice ----> Appearance Agent 2611 PUBLISH sip:HelpDesk@example.com SIP/2.0 2612 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A 2613 From: ;tag=44150CC6-A7B7919D 2614 To: ;tag=428765950880801 2615 CSeq: 11 PUBLISH 2616 Call-ID: 87837Fkw87asfds 2617 Contact: 2618 Event: dialog;shared 2619 Max-Forwards: 70 2620 Content-Type: application/dialog-info+xml 2621 Content-Length: ... 2623 2624 2629 2632 0 2633 false 2634 2638 terminated 2639 2640 2641 2642 2643 2644 2645 2646 2647 2649 10.15. Appearance Seizure Incoming/Outgoing Contention Race Condition 2651 Alice tries to seize appearance 2 at the same time appearance 2 is 2652 allocated to an incoming call. The Appearance Agent resolves the 2653 conflict by sending a 409 Conflict to Alice. After the NOTIFY F6, 2654 Alice learns that the incoming call is using appearance 2. Alice 2655 republishes for appearance 3, which is accepted. Note that this 2656 example shows the INVITE being received before the NOTIFY from the 2657 Appearance Agent. 2659 Carol Proxy Alice Appearance Agent Bob 2660 | | | | | 2661 |>-- INVITE F1>| | | | 2662 | |< - - - - - - - - - - - - - ->| | 2663 | | | | | 2664 | | |>F2 PUBLISH ->| | 2665 | | | (appearance=2) | 2666 | | | | | 2667 | |>F3 INVITE (appearance=2) ---------------------->| 2668 | | | | | 2669 | |>F4 INVITE | | | 2670 | |(appearance=2)>| | | 2671 | | |<---- F5 409 <| | 2672 | | | | | 2673 | | |<-- NOTIFY F6<| | 2674 | | | | | 2675 | | |>F7 200 OK -->| | 2676 | | | |------- NOTIFY F8>| 2677 | | | | | 2678 | | | |F10 PUBLISH->| | 2681 | | | (appearance=3) | 2682 | | | | | 2683 | | |< F11 200 OK <| | 2684 | | | | | 2685 | | |<- NOTIFY F12<| | 2686 | | | | | 2687 | |>F13 200 OK ->| | 2688 Dave | | |------ NOTIFY F14>| 2689 | | | | | 2690 | | | |F17 100 ----->| | | 2694 |<- INVITE F18<| | | | 2696 Figure 15. 2698 11. Incoming Appearance Assignment 2700 A proxy inserting an 'appearance' Alert-Info parameter follows normal 2701 policies Alert-Info policies. If an Alert-Info is already present, 2702 the proxy either removes the Alert-Info if it is not trusted, or adds 2703 the 'appearance' parameter to the Alert-Info header field. If no 2704 special ringtone is desired, a normal ringtone should be indicated 2705 using the urn:alert:tone:normal in the Alert-Info, as per 2706 [I-D.liess-dispatch-alert-info-urns]. 2708 The determination as to what value to use in the appearance parameter 2709 can be done at the proxy that forks the incoming request to all the 2710 registered UAs. 2712 There are a variety of ways the proxy can use to determine what 2713 value it should use to populate this parameter. For example, the 2714 proxy could fetch this information by initiating a SUBSCRIBE 2715 request with Expires: 0 to the Appearance Agent for the AOR to 2716 fetch the list of lines that are in use. Alternatively, it could 2717 act like a UA that is a part of the appearance group and SUBSCRIBE 2718 to the State-Agent like any other UA. This would ensure that the 2719 active dialog information is available without having to poll on a 2720 need basis. It could keep track of the list of active calls for 2721 the appearance AOR based on how many unique INVITE requests it has 2722 forked to or received from the appearance AOR. Another approach 2723 would be for the Proxy to first send the incoming INVITE to the 2724 Appearance Agent which would redirect to the appearance group URI 2725 and escape the proper Alert-Info header field for the Proxy to 2726 recurse and distribute to the other UAs in the group. 2727 The Appearance Agent needs to know about all incoming requests to 2728 the AOR in order to seize the appearance number. One way in which 2729 this could be done is for the Appearance Agent to register against 2730 the AOR with a higher q value. This will result in the INVITE 2731 being sent to the Appearance Agent first, then being offered to 2732 the UAs in the group. 2734 The changes to RFC 3261 ABNF are: 2736 alert-param = LAQUOT absoluteURI RAQUOT *( SEMI (generic-param / 2737 appearance-param) ) 2739 appearance-param = "appearance" EQUAL *DIGIT 2741 12. Security Considerations 2743 Since multiple line appearance features are implemented using 2744 semantics provided by [RFC3261], Event Package for Dialog State as 2745 define in , and Event Notification [I-D.ietf-sipcore-rfc3265bis], 2746 [RFC3903], security considerations in these documents apply to this 2747 draft as well. 2749 Specifically, since dialog state information and the dialog 2750 identifiers are supplied by UA's in an appearance group to other 2751 members, the same is prone to "call hijacks". For example, a rogue 2752 UA could snoop for these identifiers and send an INVITE with Replaces 2753 header containing these call details to take over the call. As such 2754 INVITES with Replaces header MUST be authenticated using the standard 2755 mechanism (like Digest or S/MIME) described in [RFC3261]. before it 2756 is accepted. NOTIFY or PUBLISH message bodies that provide the 2757 dialog state information and the dialog identifiers MAY be encrypted 2758 end-to-end using the standard mechanics. All SUBSCRIBES between the 2759 UA's and the Appearance Agent MUST be authenticated. 2761 13. IANA Considerations 2763 This section registers the SIP event package parameter 'shared', the 2764 SIP Alert-Info header field parameter "appearance" and the XML 2765 namespace extensions to the SIP Dialog Package. 2767 13.1. SIP Event Package Parameter: shared 2769 This specification defines a new event parameter 'shared' for the 2770 Dialog Package. When used in a NOTIFY, it indicates that the 2771 notifier supports the shared appearance feature. When used in a 2772 PUBLISH, it indicates that the publisher has explicit appearance 2773 information contained in the message body. If not present in a 2774 PUBLISH, the Appearance Agent MAY assign an appearance number to any 2775 new dialogs in the message body. 2777 13.2. URN Sub-Namespace Registration: sa-dialog-info 2779 This section registers a new XML namespace per the procedures 2780 in [RFC3688]. 2782 URI: urn:ietf:params:xml:ns:sa-dialog-info. 2784 Registrant Contact: IETF BLISS working group, , 2785 Alan Johnston 2787 XML: 2789 BEGIN 2790 2791 2793 2794 2795 2797 Shared Appearance Dialog Information Namespace 2798 2799 2800

Namespace for Shared Appearance Dialog Information

2801

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

2802

See 2803 RFCXXXX.

2804 2805 2806 END 2808 13.3. XML Schema Registration 2810 This section registers an XML schema per the procedures in 2811 [RFC3688]. 2813 URI: urn:ietf:params:xml:schesa:sa-dialog-info. 2815 Registrant Contact: IETF BLISS working group, , 2816 Alan Johnston 2818 The XML for this schema can be found in Section 6. 2820 14. Acknowledgements 2822 The following individuals were part of the shared appearance Design 2823 team and have provided input and text to the document (in 2824 alphabetical order): 2826 Martin Dolly, Andrew Hutton, Raj Jain, Fernando Lombardo, Derek 2827 MacDonald, Bill Mitchell, Michael Procter, Theo Zowzouvillys. 2829 Thanks to Chris Boulton for helping with the XML schema. 2831 Much of the material has been drawn from previous work by Mohsen 2832 Soroushnejad, Venkatesh Venkataramanan, Paul Pepper and Anil Kumar, 2833 who in turn received assistance from: 2835 Kent Fritz, John Weald, and Sunil Veluvali of Sylantro Systems, Steve 2836 Towlson, and Michael Procter of Citel Technologies, Rob Harder and 2837 Hong Chen of Polycom Inc, John Elwell, J D Smith of Siemens 2838 Communications, Dale R. Worley of Pingtel, Graeme Dollar of Yahoo 2839 Inc. 2841 Also thanks to Geoff Devine, Paul Kyzivat, Jerry Yin, John Elwell, 2842 Dan York, Spenser Dawkins, Martin Dolly, and Brett Tate for their 2843 comments. 2845 Thanks to Carolyn Beeton, Francois Audet, Andy Hutton, Tim Ross, Raji 2846 Chinnappa, and Harsh Mendiratta for their detailed review of the 2847 document. 2849 15. Informative References 2851 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2852 Requirement Levels", BCP 14, RFC 2119, March 1997. 2854 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2855 A., Peterson, J., Sparks, R., Handley, M., and E. 2856 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2857 June 2002. 2859 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 2860 Method", RFC 3515, April 2003. 2862 [I-D.ietf-sipcore-rfc3265bis] 2863 Roach, A., "SIP-Specific Event Notification", 2864 draft-ietf-sipcore-rfc3265bis-01 (work in progress), 2865 February 2010. 2867 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 2868 for Event State Publication", RFC 3903, October 2004. 2870 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 2871 Protocol (SIP) "Replaces" Header", RFC 3891, 2872 September 2004. 2874 [RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and 2875 K. Summers, "Session Initiation Protocol Service 2876 Examples", BCP 144, RFC 5359, October 2008. 2878 [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- 2879 Initiated Dialog Event Package for the Session Initiation 2880 Protocol (SIP)", RFC 4235, November 2005. 2882 [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol 2883 (SIP) "Join" Header", RFC 3911, October 2004. 2885 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol 2886 (SIP) Call Control - Conferencing for User Agents", 2887 BCP 119, RFC 4579, August 2006. 2889 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 2890 "Indicating User Agent Capabilities in the Session 2891 Initiation Protocol (SIP)", RFC 3840, August 2004. 2893 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2894 January 2004. 2896 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 2897 Package for Registrations", RFC 3680, March 2004. 2899 [I-D.liess-dispatch-alert-info-urns] 2900 Alexeitsev, D., Liess, L., Jesske, R., Johnston, A., and 2901 A. Siddiqui, "Alert-Info URNs for the Session Initiation 2902 Protocol (SIP)", draft-liess-dispatch-alert-info-urns-01 2903 (work in progress), February 2010. 2905 Authors' Addresses 2907 Alan Johnston (editor) 2908 Avaya 2909 St. Louis, MO 63124 2911 Email: alan.b.johnston@gmail.com 2912 Mohsen Soroushnejad 2913 Sylantro Systems Corp 2915 Email: mohsen.soroush@sylantro.com 2917 Venkatesh Venkataramanan 2918 Sylantro Systems Corp 2920 Email: vvenkatar@gmail.com