idnits 2.17.1 draft-ietf-bliss-shared-appearances-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 9, 2009) is 5528 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) -- Obsolete informational reference (is this intentional?): RFC 3265 (Obsoleted by RFC 6665) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 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 10, 2009 M. Soroushnejad 5 V. Venkataramanan 6 Sylantro Systems Corp 7 March 9, 2009 9 Shared Appearances of a Session Initiation Protocol (SIP) Address of 10 Record (AOR) 11 draft-ietf-bliss-shared-appearances-02 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may contain material 17 from IETF Documents or IETF Contributions published or made publicly 18 available before November 10, 2008. The person(s) controlling the 19 copyright in some of this material may not have granted the IETF 20 Trust the right to allow modifications of such material outside the 21 IETF Standards Process. Without obtaining an adequate license from 22 the person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, and 24 derivative works of it may not be created outside the IETF Standards 25 Process, except to format it for publication as an RFC or to 26 translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on September 10, 2009. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 This document describes the requirements and implementation of a 60 group telephony feature commonly known as Bridged Line Appearance 61 (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line 62 Appearance (SCA). When implemented using the Session Initiation 63 Protocol (SIP), it is referred to as shared appearances of an Address 64 of Record (AOR) since SIP does not have the concept of lines. This 65 feature is commonly offered in IP Centrex services and IP-PBX 66 offerings and is likely to be implemented on SIP IP telephones and 67 SIP feature servers used in a business environment. This document 68 lists requirements and compares implementation options for this 69 feature. Extensions to the SIP dialog event package are proposed. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 2. Conventions used in this document . . . . . . . . . . . . . . 6 75 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 6 76 3.1. Executive/Assistant Arrangement . . . . . . . . . . . . . 6 77 3.2. Call Group . . . . . . . . . . . . . . . . . . . . . . . 6 78 3.3. Single Line Extension . . . . . . . . . . . . . . . . . . 7 79 4. Requirements and Implementation . . . . . . . . . . . . . . . 7 80 4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 7 81 4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 8 82 5. Normative Description . . . . . . . . . . . . . . . . . . . . 10 83 5.1. Elements . . . . . . . . . . . . . . . . . . . . . . . . 10 84 5.2. Shared Appearance Dialog Package Extensions . . . . . . . 11 85 5.2.1. The element . . . . . . . . . . . . . . . 11 86 5.2.2. The element . . . . . . . . . . . . . . . 11 87 5.2.3. The element . . . . . . . . . . . . . 11 88 5.2.4. The element . . . . . . . . . . . . 12 89 5.3. Shared Appearance User Agents . . . . . . . . . . . . . . 12 90 5.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . 15 91 6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 16 92 7. User Interface Considerations . . . . . . . . . . . . . . . . 18 93 7.1. Appearance Number Rendering . . . . . . . . . . . . . . . 18 94 7.1.1. Single Appearance UAs . . . . . . . . . . . . . . . . 18 95 7.1.2. Dual Appearance UAs . . . . . . . . . . . . . . . . . 18 96 7.1.3. Shared Appearance UAs with Fixed Appearance Number . . 18 97 7.1.4. Shared Appearance UAs with Variable Appearance 98 Number . . . . . . . . . . . . . . . . . . . . . . . . 19 99 7.2. Call State Rendering . . . . . . . . . . . . . . . . . . 19 100 8. Interop with non-Shared Appearance UAs . . . . . . . . . . . . 20 101 8.1. Appearance Assignment . . . . . . . . . . . . . . . . . . 20 102 8.2. Appearance Release . . . . . . . . . . . . . . . . . . . 20 103 8.3. UAs Supporting Dialog Events but Not Shared Appearance . 21 104 9. Provisioning Considerations . . . . . . . . . . . . . . . . . 21 105 10. Example Message Flows . . . . . . . . . . . . . . . . . . . . 21 106 10.1. Registration and Subscription . . . . . . . . . . . . . . 21 107 10.2. Appearance Selection for Incoming Call . . . . . . . . . 24 108 10.3. Outgoing Call without Appearance Pre-Selection . . . . . 28 109 10.4. Outgoing Call with Appearance Pre-Selection . . . . . . . 30 110 10.5. Outgoing Call without using an Appearance Number . . . . 33 111 10.6. Appearance Release . . . . . . . . . . . . . . . . . . . 35 112 10.7. Appearance Pickup . . . . . . . . . . . . . . . . . . . . 36 113 10.8. Calls between UAs within the Group . . . . . . . . . . . 40 114 10.9. Consultation Hold with Appearances . . . . . . . . . . . 43 115 10.10. Joining or Bridging an Appearance . . . . . . . . . . . . 45 116 10.11. Appearance Allocation - Loss of Appearance . . . . . . . 48 117 10.12. Appearance Selection Contention Race Condition . . . . . 49 118 10.13. Appearance Agent Subscription to UAs . . . . . . . . . . 50 120 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 121 11.1. SIP Event Package Parameter: shared . . . . . . . . . . . 52 122 11.2. URN Sub-Namespace Registration: sa-dialog-info . . . . . 53 123 11.3. XML Schema Registration . . . . . . . . . . . . . . . . . 53 124 12. Appendix A - Incoming Appearance Assignment . . . . . . . . . 54 125 13. Appendix B - Implementation Options Discussion . . . . . . . . 55 126 13.1. Appearance Implementation Options . . . . . . . . . . . . 55 127 13.1.1. URI parameter Approach . . . . . . . . . . . . . . . . 55 128 13.1.2. Dialog Package Parameter . . . . . . . . . . . . . . . 56 129 13.1.3. Appearance Selections Mechanisms . . . . . . . . . . . 58 130 13.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . 61 131 13.2.1. Comparison of Appearance Selection Methods . . . . . . 62 132 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 63 133 15. Security Considerations . . . . . . . . . . . . . . . . . . . 63 134 16. Informative References . . . . . . . . . . . . . . . . . . . . 64 135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 65 137 1. Introduction 139 The feature and functionality requirements for SIP user agents (UAs) 140 supporting business telephony applications differ greatly from basic 141 SIP user agents, both in terms of services and end user experience. 142 In addition to basic SIP support [RFC3261], many of the services in a 143 business environment require the support for SIP extensions such as 144 REFER [RFC3515], SUBSCRIBE/NOTIFY primitives [RFC3265], PUBLISH 145 [RFC3903], the SIP Replaces [RFC3891], and Join [RFC3911] header 146 fields, etc. Many of the popular business services have been 147 documented in the SIP Service Examples [RFC5359]. 149 This specification details a method for implementing a group 150 telephony feature known variously in telephony as Bridged Line 151 Appearance (BLA) or Multiple Line Appearances (MLA), one of the more 152 popular advanced features expected of SIP IP telephony devices in a 153 business environment. Other names for this feature include Shared 154 Call/Line Appearance (SCA), Shared Call Status and Multiple Call 155 Appearance (MCA). A variant of this feature is known as Single Line 156 Extension. 158 This document looks at how this feature can be implemented using 159 standard SIP [RFC3261] in conjunction with SIP events [RFC3265] and 160 publication [RFC3903] for exchanging status among user agents, and 161 the SIP dialog state event package [RFC4235] to exchange dialog state 162 information to achieve the same. Different approaches will be 163 discussed including the use of URI parameters, feature tags, and 164 dialog package extensions along with the strengths and weaknesses of 165 the various approaches. 167 In traditional telephony, the line is physical. A common scenario in 168 telephony is for a number of business telephones to share a single or 169 a small number of lines. The sharing or appearance of these lines 170 between a number of phones is what gives this feature its. A common 171 scenario in SIP is for a number of business telephones to share a 172 single or a small number of Address of Record (AOR) URIs. In 173 addition, an AOR can have multiple appearances on a single UA in 174 terms of the user interface. The appearance number relates to the 175 user interface for the telephone - typically each appearance or an 176 AOR has a visual display (lamp that can change color or blink) and a 177 button (used to select the appearance). The telephony concept of 178 line appearance is still relevant to SIP due to the user interface 179 considerations. It is important to keep the appearance number 180 construct because: 182 1. Human users are used to the concept and will expect it in 183 replacement systems (e.g. an overhead page announcement says "Joe 184 pickup line 3"). 186 2. It is a useful structure for user interface representation. 188 In this document, we will use the term "appearance" rather than "line 189 appearance" since SIP does not have the concept of lines. Note that 190 this does not mean that a conventional telephony user interface 191 (lamps and buttons) must be used - implementations may use another 192 metaphor as long as the appearance number is readily apparent to the 193 user. Each AOR has a separate appearance numbering space. As a 194 result, a given UA user interface may have multiple occurrences of 195 the same appearance number, but they will be for different AORs. 197 2. Conventions used in this document 199 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 200 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 201 document are to be interpreted as described in RFC-2119 [RFC2119] and 202 indicate requirement levels for compliant mechanisms. 204 3. Usage Scenarios 206 The following examples are common applications of the Shared 207 Appearances feature and are mentioned here as informative use cases. 208 All these example usages can be supported by the Shared Appearances 209 feature described in this document. The differences relate to the 210 user interface considerations of the device. 212 3.1. Executive/Assistant Arrangement 214 The appearances on the executive's UA also appear on the assistant's 215 UA. The assistant may answer incoming calls to the executive and 216 then place the call on hold for the executive to pick up. The 217 assistant can always see the state of all calls on the executive's 218 UA. An assistant can make outgoing calls using the identity of 219 either the executive or their own. 221 3.2. Call Group 223 Users with similar business needs or tasks can be assigned to 224 specific groups and share the line appearances of each other on each 225 others SIP telephony devices. For example, an IT department staff of 226 five might answer a help line which has three appearances on each 227 phone in the IT work area. A call answered on one phone can be put 228 on hold and picked up on another phone. A shout or an IM to another 229 staff member can result in them taking over a call on a particular 230 appearance. Another phone can request to be added to an appearance 231 resulting in a conference call. 233 3.3. Single Line Extension 235 In this scenario, incoming calls are offered to a group of UAs. When 236 one answers, the other UAs are informed. If another UA in the group 237 selects the line (i.e. goes off hook), it is immediately bridged or 238 joined in with the call. This mimics the way residential telephone 239 extensions usually operate. 241 4. Requirements and Implementation 243 The next section details the requirements and discusses the 244 implementation of the shared appearances of an AOR feature. 246 4.1. Requirements 248 The basic requirements of the shared appearance feature can be 249 summarized as follows: 251 REQ-1 Incoming calls to the AOR must be offered to a group of UAs and 252 can be answered by any of them. 254 REQ-2 Each UA in the group must be able to learn the call status of 255 the others in the group for the purpose of rendering this information 256 to the user. 258 REQ-3 Calls can be joined (also called bridged or conferenced 259 together) or can be picked up (taken) by another UA in the group in a 260 secure way. 262 REQ-4 The mechanism should require the minimal amount of 263 configuration. UAs registering against the group AOR should be able 264 to learn about each other and join the appearance group. 266 REQ-5 The mechanism must scale for large numbers of appearances, n, 267 and large numbers of UAs, N, without introducing excessive messaging 268 traffic. 270 REQ-6 Each call or session (incoming or outgoing) must be assigned a 271 common "appearance" number from a managed pool administered for the 272 AOR group. Once the session has terminated, the appearance number is 273 released back into the pool and can be reused by another incoming or 274 outgoing session. 276 REQ-7 Each UA in the group must be able to learn the appearance 277 status of the the group. 279 REQ-8 There must be mechanisms to resolve appearance contention among 280 the UAs in the group. 282 REQ-9 The mechanism must allow all UAs receiving an incoming session 283 request to select the same appearance number at the time of alerting. 285 REQ-10 The mechanism must have a way of reconstructing appearance 286 state after an outage that does not result in excessive traffic and 287 processing. 289 REQ-11 The mechanism must have backwards compatibility such that a UA 290 which is unaware of the feature can still register against the group 291 AOR and make and receive calls. 293 REQ-12 The mechanism must not allow UAs outside the group to select 294 or manipulate appearance numbers. 296 REQ-13 For privacy reasons, there must be a mechanism so that 297 appearance information is not leaked outside the group of UAs. (e.g. 298 "So who do you have on line 1?") 300 REQ-14 The mechanism must support a way for UAs to request 301 exclusivity on a line appearance. Exclusivity means that the UA 302 requesting it desires to have a private conversation with the 303 external party and other UAs must not be allowed to be joined or 304 taken. Exclusivity may be requested at the start of an incoming or 305 outgoing session or during the session. An exclusivity request may 306 be accepted or rejected by the entity providing the shared appearance 307 service. Therefore, the mechanism must provide a way of 308 communicating the result back to the requester UA. 310 REQ-15 The mechanism should support a way for a UA to select a 311 particular appearance number for outgoing requests prior to sending 312 the actual request. This is often called seizure. 314 REQ-16 The mechanism should support a way for a UA to select a 315 particular appearance number and also send the request at the same 316 time. This is needed when a ringdown feature is combined with shared 317 appearances - in this case, seizing the line is the same thing as 318 dialing. 320 4.2. Implementation 322 Many of the requirements for this service can be met using standard 323 SIP mechanisms such as: 325 - A SIP Forking Proxy and Registrar/Location Service meets REQ-1. 327 - The SIP Dialog Package meets REQ-2. 329 - The SIP Replaces and Join header fields meets REQ-3. 331 - The use of a State Agent for the Dialog Package meets REQ-4 and 332 REQ-5. 334 REQ-6 suggests the need for an entity which manages the appearance 335 resource. Just as conferencing systems commonly have a single point 336 of control, known as a focus, a Shared Appearance group has a single 337 point of control of the appearance shared resource. This is defined 338 as an Appearance Agent for a group. While an Appearance Agent can be 339 part of a centralized server, it could also be co-resident in a 340 member User Agent who has taken on this functionality for a group. 341 The Appearance Agent learns the group state either dialog state 342 publications from members. 344 While the appearance resource could be managed co-operatively by a 345 group of UAs without any central control, this is not discussed in 346 this draft, but instead is left as a research project for future 347 standardization. It is also possible that the Appearance Agent logic 348 could be distributed in all UAs in the group. For example, rules 349 that govern assigning appearance numbers for incoming requests (e.g. 350 lowest available appearance number) and rules for contention handling 351 (e.g. when two UAs request the use of the same appearance number, 352 hash dialog identifiers and compare with the lowest hash winning) 353 would need to be defined and implemented. 355 The next section discusses normal SIP operations used to implement 356 parts of the shared appearance feature. 358 1. A UA is configured with the AOR of a shared appearance group. It 359 registers against the AOR, then attempts a dialog state 360 subscription to the AOR. If the subscription fails, loops back 361 to itself, or returns a 482 Loop Detected, it knows there is no 362 State Agent, and hence no Appearance Agent and this feature is 363 not implemented. 364 2. If the subscription receives a 200 OK, the UA knows there is a 365 State Agent and that the feature is implemented. The UA then 366 follows the steps in this list. 367 3. Information learned about the dialog state of other UAs in the 368 group is rendered to the user. 369 4. Incoming calls are forked to all UAs in the group, and any may 370 answer. UAs receive a notification from the Appearance Agent 371 indicating the appearance number to use in rendering the incoming 372 call. The UA will also receive a notification if the call is 373 answered by another UA in the group so this information can be 374 rendered to the user. 376 5. For outgoing calls, the operation depends on the user input. If 377 the user selects a particular appearance number for the call, the 378 UA publishes this information and waits for a 200 OK before 379 sending the INVITE. 380 6. For outgoing calls, if the user does not select a particular 381 appearance or does not care, the INVITE can be sent immediately, 382 and the appearance number learned as the call progresses from a 383 notification from the Appearance Agent. 384 7. For outgoing calls, if the user does not wish to select an 385 appearance (such as during a consultation call), the UA also 386 publishes this prior to sending the INVITE. 387 8. Established calls within the group may be joined (bridged) or 388 taken (picked) by another UA. Information in the dialog package 389 notifications can be used to construct Join or Replaces header 390 fields. Since the same appearance number is used for these types 391 of operations, this information is published prior to sending the 392 INVITE Join or INVITE Replaces. 393 9. In some cases, the Appearance Agent may not have full access to 394 the complete dialog state of some or all of the UAs in the group. 395 If this is the case, the Appearance Agent will subscribe to the 396 dialog state of individual UAs in the group to obtain this 397 information. Normal notifications will be sent every time the 398 dialog state changes, including calls placed, answered, placed on 399 and off hold, and hangups. 401 5. Normative Description 403 This section normatively describes the shared appearance feature 404 extensions. For a discussion of various approaches to implement this 405 feature, see Appendix B. 407 5.1. Elements 409 A complete system to implement this feature consists of: 411 1. User Agents that support publications, subscriptions, and 412 notifications for the SIP dialog event package, and the shared 413 appearance dialog package extensions and behavior. 414 2. An Appearance Agent consisting of a State Agent for the dialog 415 event package that implements an Event State Compositor (ESC) and 416 the shared appearance dialog package extensions and behavior. 417 The Appearance Agent also has logic for assigning and releasing 418 appearance numbers, and resolving appearance number contention. 419 3. A forking proxy server that can communicate with the State Agent 420 4. A registrar that supports the registration event package. 422 The behavior of these elements is described normatively in the 423 following sections after the definitions of the dialog package 424 extensions. 426 5.2. Shared Appearance Dialog Package Extensions 428 This specification defines four new elements as extensions to the SIP 429 Dialog Event package [RFC3265]. The schema is defined in Section 6. 430 The elements are , , , and 431 which are sub-elements of the element. 433 5.2.1. The element 435 The element is used convey the appearance number. The 436 appearance number is a non-negative integer. When sent in a 437 notification in state Trying to the Appearance Agent, it is used to 438 request an appearance number. When sent by the Appearance Agent, it 439 indicates that the appearance number is associated with a dialog. 441 5.2.2. The element 443 The element is a boolean used to indicate whether the UA 444 will accept Join or Replaces INVITEs for this dialog. For example, 445 some shared appearance systems only allow call pickup when the call 446 is on hold. In this case, the element should be used to 447 explicitly indicate this, rather than implicitly by the hold state. 449 It is important to note that this element is a hint. Although a UA 450 may set exclusive to true, the UA must still be ready to reject an 451 INVITE Join relating to this dialog. Also, an INVITE Replaces might 452 be sent to the non-shared appearance UA to take the call. For this 453 reason, a UA MAY also not report full dialog identifier information 454 to the Appearance Agent for calls set to exclusive. If these dialog 455 identifiers have already been shared with the Appearance Agent, the 456 UA could send an INVITE Replaces to change them and then not report 457 the new ones to the Appearance Agent. 459 If the proxy knows which dialogs are marked exclusive, the proxy MAY 460 enforce this exclusivity by rejecting INVITE Join and INVITE Replaces 461 requests containing those dialog identifiers with a 403 Forbidden 462 response. 464 5.2.3. The element 466 The element is used convey dialog identifiers of any 467 other dialogs which are joined (mixed or bridged) with the dialog. 468 Only the UA which is performing the actual media mixing should 469 include this element in notifications to the Appearance Agent. Note 470 that this element should still be used even when the Join header 471 field was not used to join the dialogs. For example, two separate 472 dialogs on a UA could be joined without any SIP call control 473 operations. Joined dialogs will share the same appearance number. 475 5.2.4. The element 477 The element is used convey dialog identifiers of 478 any other dialogs which will be or have been replaced with this 479 dialog. For example, a UA in the group picking up a call on another 480 UA by sending an INVITE with Replaces would include this element for 481 the replacing dialog. Replaced dialogs will share the same 482 appearance number. 484 5.3. Shared Appearance User Agents 486 User Agents that support the Shared Appearance feature MUST support 487 the dialog state package [RFC4235] with the shared appearance 488 extensions and the 'shared' dialog event package parameter defined in 489 this draft. 491 User Agents MUST support the dialog package extensions in Section 5.2 492 along with SUBSCRIBE and NOTIFY [RFC3265] and PUBLISH [RFC3903]. 493 SUBSCRIBE, NOTIFY, and PUBLISH requests for the dialog event package 494 SHOULD include the 'shared' Event header field parameter. 496 The presence of the 'shared' Event package parameter tells the 497 Appearance Agent that this UA supports this specification. 499 Upon initialization and at regular intervals, the UA SHOULD subscribe 500 to the dialog event package of the AOR. If the SUBSCRIBE request 501 fails, loops back to itself, or returns a 482 Loop Detected, then no 502 Appearance Agent is present and this feature is not active for this 503 AOR. The UA MAY periodically retry the subscription to see if 504 conditions have changed. 506 User Agents SHOULD support sending and receiving an INVITE with a 507 Replaces [RFC3891] header to allow the Call Pickup operation. User 508 Agents MUST support sending an INVITE with a Join [RFC3911] header 509 field to initiate bridging. 511 Note that the Join operation can be implemented outside the UA, 512 for example, in a B2BUA. This is why UAs must support sending 513 Join header fields even if they do not necessarily support 514 receiving them. 516 When publishing or notifying dialog package information, a UA MUST 517 include all dialog identification available at the time of 518 publication, with the exception that a UA may omit information if it 519 wishes to prevent other UAs from joining or picking up a call. 520 Dialog identification includes local and remote target URIs, call-id, 521 to-tag, and from-tag. When calls are placed on hold, the 522 "+sip.rendering=no" feature tag MUST be included in dialog package 523 notifications. 525 The accurate rendering of the idle/active/alerting/hold state of 526 other UAs in the group is an important part of the shared 527 appearance feature. 529 A UA MUST send dialog package PUBLISH requests in the following 530 situations: 532 1. When the user selects a particular appearance number for an 533 outgoing call (i.e. seizing an appearance or going "off-hook" 534 with an appearance, if the UA's user interface uses this 535 metaphor). 536 2. When the user has requested that an appearance number not be used 537 for an outgoing call (i.e. during a consultation call or for a 538 call not considered part of the shared appearance group). 539 3. When the user has selected to join (or bridge) an existing call. 540 4. When the user has selected to replace (or take) an existing call. 542 In all these cases, the INVITE SHOULD NOT be sent until the 200 OK 543 response to the PUBLISH has been received, except for an emergency 544 call, when a UA MUST never wait for a confirmed seizure before 545 sending an INVITE. Instead, the emergency call MUST proceed 546 regardless of the status of PUBLISH transaction. 548 Note that when a UA selects an appearance prior to establishment of a 549 dialog (#1 and #2 in above list), not all dialog information will be 550 available. In particular, when a UA publishes an attempt to select 551 an appearance prior to knowing the destination URI, minimal or no 552 dialog information may be available. For example, in some cases, 553 only the local target URI for the call will be known and no dialog 554 information. If no dialog identification information is present in 555 the initial PUBLISH, the UA MUST PUBLISH again after receiving the 556 100 Trying response. 558 The first publication will cause the Appearance Agent to reserve 559 the appearance number for this UA. If the publication does not 560 have any dialog identifiers (e.g. Call-ID, or local tag) the 561 Appearance Agent cannot assign the appearance number to a 562 particular dialog of the UA until the second publication which 563 will contain some dialog identifiers. 565 This publication state SHOULD be refreshed during the early dialog 566 state or the Appearance Agent may reassign the appearance number. 568 Once the dialog has transitioned to the confirmed state, no 569 publication refreshes are necessary. 571 UAs SHOULD render information about other appearances to the user. 572 This includes the state (idle, active, busy, joined, etc.). UAs can 573 tell that a set of dialogs are joined (bridged or mixed) together by 574 the presence of one or more elements containing other 575 SIP dialog identifiers. A UA SHOULD render the appearance number to 576 the user or display appearance status information to the user in a 577 way that preserves the appearance order. 579 A UA that does not need to select a particular appearance number (or 580 doesn't care) would just send an INVITE as normal to place an 581 outbound call. 583 A UA wanting to place a call but not have an appearance number 584 assigned publishes before sending the INVITE without an 'appearance' 585 element but with the 'shared' event package parameter present. If 586 the Appearance Agent policy does not allow calls without an assigned 587 appearance number, a 409 Conflict response will be received, and the 588 UA will republish either selecting an appearance number or without 589 one, in which case the Appearance Agent will assign one. 591 When an INVITE is generated to attempt to bridge or take a call (i.e. 592 contains Join or Replaces with a dialog identifier of another dialog 593 in the shared appearance group), the appearance number of the joined 594 or replaced call SHOULD be used. The publication MUST contain the 595 appearance number of the dialog to be joined or replaced and the 596 dialog identifier in the 'joined-dialog' or 'replaced-dialog' 597 elements. 599 Note that this information is provided to the Appearance Agent so 600 that it can provide proper appearance assignment behavior. With 601 Join, the goal is to prevent the Appearance Agent from generating 602 a 409 Conflict response due to the reuse of an appearance number. 603 For Replaces, the goal is to prevent a race condition where the 604 BYE could cause the appearance number to be released when it 605 should stay with the replacing dialog. 607 A UA SHOULD register against the AOR only if it is likely the UA will 608 be answering incoming calls. If the UA is mainly going to be 609 monitoring the status of the shared appearance group calls and 610 picking or joining calls, the UA SHOULD only subscribe to the AOR and 611 not register against the AOR. 613 All subscribed UAs will received NOTIFYs of Trying state for 614 incoming INVITEs. 616 5.4. Appearance Agent 618 An Appearance Agent defined in this specification MUST implement a 619 dialog package state agent for the UAs registered against the AOR. 620 The Appearance Agent MUST support the appearance dialog package 621 extensions defined in Section 5.2. The Appearance Agent MUST support 622 publications and subscriptions for this event package. 624 The Appearance Agent MUST have a way of discovering the state of all 625 dialogs associated with the AOR. If this information is not 626 available from a call stateful proxy or B2BUA, the Appearance Agent 627 MAY use the registration event package [RFC3680] to learn of UAs 628 associated with the AOR and MAY subscribe to their dialog event 629 state. As a result, the registrar MUST support the registration 630 event package. The Appearance Agent SHOULD send dialog event state 631 notifications whenever the following events happen to UAs in the AOR 632 group: 634 1. A call is received, placed, answered, or terminated. 635 2. A call is placed on or off hold. 636 3. A call is joined or replaced. 637 4. An appearance number is reserved or released. 639 The Appearance Agent MUST allocate an appearance number for all 640 incoming calls and send immediate notifications to the UAs subscribed 641 to the shared group AOR. The Appearance Agent MUST be able to 642 communicate with the forking proxy to learn about incoming calls and 643 also to pass the appearance number to the proxy to insert in the 644 Alert-Info header field. 646 An Appearance Agent SHOULD assign an appearance number to an outgoing 647 INVITE if a PUBLISH has not been received selecting a particular 648 appearance number. 650 Note that if the appearance group has non-shared appearance UAs, 651 the Appearance Agent will still allocate appearance numbers for 652 INVITEs sent by those UAs. 654 An Appearance Agent receiving a PUBLISH with an appearance number 655 checks to make sure the publication is valid. An appearance number 656 can be assigned to only one dialog unless there is a 'joined-dialog' 657 or 'replaced-dialog' element indicating that the dialog will be/has 658 been replaced or joined. A 409 Conflict response is returned if the 659 chosen appearance number is invalid, and an immediate NOTIFY should 660 be sent to the UA containing full dialog event state. 662 An Appearance Agent receiving a PUBLISH without an appearance number 663 but with the 'shared' event package parameter present interprets this 664 as a request by the UA to not assign an appearance number. If the 665 Appearance Agent policy does not allow this, a 409 Conflict response 666 is returned. If policy does allow this, a 200 OK response is 667 returned and no appearance number is allocated. In general, the 668 dialog state will not be shared with the other UAs in the group. 670 The Appearance Agent allocates an appearance number to a dialog from 671 the time the appearance is requested via a PUBLISH or from the 672 receipt of an INVITE, to the time when the last dialog associated 673 with the appearance is terminted, including all dialogs which are 674 joined or replaced. During the early dialog state, the Appearance 675 Agent controls the rate of dialog state publication using the Expires 676 header field in 200 OK responses to PUBLISH requests. An interval of 677 3 minutes is RECOMMENDED. After the dialog associated with the 678 publication has been confirmed, the expiration of the publication 679 state has no effect on the appearance allocation. If the publication 680 contains no dialog state information, the Appearance Agent MUST 681 reserve the appearance number for the UA but can not assign the 682 appearance to any particular dialog of the UA. When the publication 683 state is updated with any dialog information, the appearance number 684 can then be assigned to the particular dialog. 686 During dynamic situations, such as during a call pickup or join 687 action, the Appearance Agent MAY choose to implement rate limiting to 688 reduce the amount of notification traffic. For example, an 689 Appearance Agent may choose not to generate immediate NOTIFYs upon 690 receipt of PUBLISHes. Instead, a single NOTIFY can convey the 691 effects of a number of PUBLISHes, thus reducing the NOTIFY traffic 692 within the group. 694 If an INVITE is sent and no appearance number is available, the proxy 695 MAY reject the INVITE with a 403 Forbidden response code. 697 6. XML Schema Definition 699 The 'appearance', 'joined-dialog', 'replaced-dialog', and 'exclusive' 700 elements are defined within a new XML namespace URI. This namespace 701 is "urn:ietf:params:xml:ns:sa-dialog-info". The schema for these 702 elements is: 704 705 711 713 714 716 718 720 721 723 725 726 728 730 732 733 735 736 737 738 740 741 742 743 744 746 7. User Interface Considerations 748 The "appearance number" allocated to a call is an important concept 749 that enables calls to be handled by multiple devices with 750 heterogeneous user interfaces in a manner that still allows users to 751 see a consistent model. Careful treatment of the appearance number 752 is essential to meet the expectations of the users. Also, rendering 753 the correct call/appearance state to users is also important. 755 7.1. Appearance Number Rendering 757 Since different UAs have different user interface capabilities, it is 758 usual to find that some UAs have restrictions that others do not. 759 Perfect interoperability across all UAs is clearly not possible, but 760 by careful design, interoperability up to the limits of each UA can 761 be achieved. 763 The following guidelines suggest how the appearance number should be 764 handled in three typical user interface implementations. 766 7.1.1. Single Appearance UAs 768 These devices are constrained by only having the capability of 769 displaying status indications for a single appearance. Despite this, 770 it is important that devices of this type do not ignore the 771 appearance number. The UA should still send messages annotated with 772 an appropriate appearance number (i.e. "0"). Any call indications 773 for appearances other than for number "0" should be rejected with a 774 486 or 480 response. 776 7.1.2. Dual Appearance UAs 778 These devices are essentially single appearance phones that implement 779 call waiting. They have a very simple user interface that allows 780 them to switch between two appearances (toggle or flash hook) and 781 perhaps audible tones to indicate the status of the other appearance. 783 7.1.3. Shared Appearance UAs with Fixed Appearance Number 785 This UA is the typical 'business-class' hard-phone. A number of 786 appearances are typically configured statically and labeled on 787 buttons, and calls may be managed using these configured appearances. 788 Any calls outside this range should be ignored, and not mapped to a 789 free button. Users of these devices often select specific appearance 790 numbers for outgoing calls, and the UA will need to select the 791 appearance number and wait for confirmation from the Appearance Agent 792 before proceeding with calls. 794 7.1.4. Shared Appearance UAs with Variable Appearance Number 796 This UA is typically a soft-phone or graphically rich user interface 797 hard-phone. In these cases, even the idea of an appearance index may 798 seem unnecessary. However, for these phones to be able to interwork 799 successfully with other phone types, it is important that they still 800 use the appearance index to govern the order of appearance of calls 801 in progress. No specific guidance on presentation is given except 802 that the order should be consistent. Thought should also be given to 803 how an appearance number that has no call associated with it should 804 be rendered to the user. These devices can typically make calls 805 without waiting for confirmation from the Appearance Agent on the 806 appearance number. 808 The problems faced by each style of user interface are readily seen 809 in this example: 811 1. A call arrives at the shared appearance group, and is assigned an 812 appearance number of 0. All UAs should be able to render to the 813 user the arrival of this call. 814 2. Another call arrives at the shared appearance group, and is 815 assigned an appearance number of 1. The single appearance UA 816 should not present this call to the user. Other user agents 817 should have no problems presenting this call distinctly from the 818 first call. 819 3. The first call clears, releasing appearance number "0". The 820 single appearance UA should now be indicating no calls since it 821 is unable to manage calls other than on the first appearance. 822 Both shared appearance UAs should clearly show that appearance 823 number 0 is now free, but that there is still a call on 824 appearance number 1. 825 4. A third call arrives, and is assigned the appearance number of 0. 826 All UAs should be able to render the arrival of this new call to 827 the user. Multiple appearnce UAs should continue to indicate the 828 presence of the second call, and should also ensure that the 829 presentation order is related to the appearance number and not 830 the order of call arrival. 832 7.2. Call State Rendering 834 UAs that implement the shared appearance feature typically have a 835 user interface that provides the state of other appearances in the 836 group. As dialog state NOTIFYs from the Appearance Agent are 837 processed, this information can be rendered. Even the simplest user 838 interface typically has three states: idle, active, and hold. The 839 idle state, usually indicated by lamp off, is indicated for an 840 appearance when the appearance number is not associated with any 841 dialogs, as reported by the Appearance Agent. The active state, 842 usually indicated by a lamp on, is indicated by an appearance number 843 being associated with at least one dialog, as reported by the 844 Appearance Agent. The hold state, often indicated by a blinking 845 lamp, means the call state from the perspective of the UA in the 846 shared appearance group is hold. This can be determined by the 847 presence of the "sip+rendering=no" feature tag [RFC3840] with the 848 local target URI. Note that the hold state of the remote target URI 849 is not relevant to this display. For joined dialogs, the state is 850 rendered as hold only if all local target URIs are indicated with the 851 "sip+rendering=no" feature tag. 853 8. Interop with non-Shared Appearance UAs 855 EDITOR'S NOTE: This section needs to be reviewed in light of recent 856 changes in the specification. 858 It is desirable to allow a basic UA that does not directly support 859 shared appearance to be part of a shared appearance group. To 860 support this the Proxy must collaborate with the Appearance Agent. 861 This is not required in the basic shared appearance architecture, 862 consequently shared appearance interop with non-shared appearance UAs 863 will not be available in all shared appearance deployments. 865 First, a UA which does not support dialog events or the shared 866 appearance feature will be discussed. Then, a UA which does support 867 dialog events but not the shared appearance feature will be 868 discussed. 870 8.1. Appearance Assignment 872 A UA that has no knowledge of appearances must have appearance 873 numbers assigned by the Appearance Agent for both incoming and 874 outgoing calls. If the non-shared appearance UA does not support 875 Join or Replaces, all dialogs could be marked "exclusive" to indicate 876 that these options are not available. 878 8.2. Appearance Release 880 In all cases the Appearance Agent must be aware of dialog lifetime to 881 release appearances back into the group. 883 It is also desirable that any dialog state changes (such as hold, 884 etc) be made available to other UAs in the group through the Dialog 885 Event Package. If the Appearance Agent includes a proxy which 886 Record-Routes for dialogs from the non-shared appearance aware UA, 887 the Appearance Agent will know about the state of dialogs including 888 hold, etc. This information could be determined from inspection of 889 INVITE and re-INVITE messages and added to the dialog information 890 conveyed to other UAs. 892 8.3. UAs Supporting Dialog Events but Not Shared Appearance 894 Interoperability with UAs which support dialog events but not the 895 shared appearance feature is more straightforward. As before, all 896 appearance number assignment must be done by the Appearance Agent. 897 This type of UA will be detected by the Appearance Agent by the 898 absence of the ma event parameter in SUBSCRIBE or PUBLISH messages. 899 The Appearance Agent can include appearance information in NOTIFYs - 900 this UA will simply ignore this extra information. This type of UA 901 will ignore appearance number limitations and may attempt to Join or 902 Replace dialogs marked exclusive. As a result, the Proxy or UAs may 903 need to reject such requests. 905 The need for close cooperation between the Proxy and the Appearance 906 Agent is not needed as the Appearance Agent will learn about all 907 dialogs from the UA itself. 909 9. Provisioning Considerations 911 Previous versions of this draft required the URI of the Appearance 912 Agent be provisioned in each UA in the group. Since publication is 913 now done to the group URI, this provisioning is no longer necessary. 915 UAs can automatically discover if this feature is active for an AOR 916 by sending a SUBSCRIBE to the AOR, so no provisioning for this is 917 needed. 919 If the Appearance Agent needs to subscribe to the dialog state of the 920 UAs, then the Appearance Agent and the UAs need to be provisioned 921 with credentials so the UAs can authenticate the Appearance Agent. 923 10. Example Message Flows 925 The next section shows call flow and message examples. The flows and 926 descriptions are non-normative. 928 10.1. Registration and Subscription 930 Bob and Alice are in an appearance group identified by Alice's AOR. 931 Bob REGISTERs using contact sip:bob@ua2.example.com. Alice REGISTERs 932 with contact sip:alice@ua1.example.com. 934 User Agents for Alice and Bob subscribe to the dialog package for the 935 appearance AOR and publish dialog state to the Appearance Agent. 936 Message exchanges between the Registrar, Appearance Agent, Alice, and 937 Bob are shown below. The call flow examples below do not show the 938 authentication of subscriptions, publications, and notifications. It 939 should be noted that for security purposes, all subscriptions must be 940 authorized before the same is accepted. 942 Also note that registrations and subscriptions must all be refreshed 943 by Alice at intervals determined by the expiration intervals returned 944 by the Registrar or Appearance Agent. 946 Registrar Appearance Agent Alice 947 | | | 948 | | | 949 |<--------------------------- REGISTER F1<| 950 | | | 951 |>F2 200 OK ----------------------------->| 952 | | | 953 | |<----- SUBSCRIBE F3<| 954 | | | 955 | |>F4 202 Accepted -->| 956 | | | 957 | |>F5 NOTIFY -------->| 958 | | | 959 | |<-------- 200 OK F6<| 960 | | | 962 Figure 1. 964 F1-F2: Alice registers AOR with 965 contact: 967 F1 Alice ----> Registrar 969 REGISTER sip:registrar.example.com SIP/2.0 970 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09 971 From: ;tag=CDF9A668-909E2BDD 972 To: 973 CSeq: 2 REGISTER 974 Call-ID: d3281184-518783de-cc23d6bb 975 Contact: 976 Max-Forwards: 70 977 Expires: 3600 978 Content-Length: 0 980 F2 Registrar ----> Alice 981 SIP/2.0 200 OK 982 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKfbf176ef7F1D5FA2 983 CSeq: 2 REGISTER 984 Call-ID: d3281184-518783de-cc23d6bb 985 From: ;tag=CDF9A668-909E2BDD 986 To: ;tag=1664573879820199 987 Contact: 988 Expires: 3600 989 Content-Length: 0 991 F3 to F6: Alice also subscribes to the events associated with the 992 Appearance AOR. Appearance Agent also notifies Alice of the status. 994 F3 Alice ----> Appearance Agent 996 SUBSCRIBE sip:alice@example.com SIP/2.0 997 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A 998 From: ;tag=925A3CAD-CEBB276E 999 To: 1000 CSeq: 91 SUBSCRIBE 1001 Call-ID: ef4704d9-bb68aa0b-474c9d94 1002 Contact: 1003 Event: dialog;shared 1004 Accept: application/dialog-info+xml 1005 Max-Forwards: 70 1006 Expires: 3700 1007 Content-Length: 0 1009 F4 Appearance Agent ----> Alice 1011 SIP/2.0 202 Accepted 1012 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A 1013 CSeq: 91 SUBSCRIBE 1014 Call-ID: ef4704d9-bb68aa0b-474c9d94 1015 From: ;tag=925A3CAD-CEBB276E 1016 To: ;tag=1636248422222257 1017 Allow-Events: dialog 1018 Expires: 3700 1019 Contact: 1020 Content-Length: 0 1022 F5 Appearance Agent ----> Alice 1024 NOTIFY sip:alice@ua1.example.com SIP/2.0 1025 From: ;tag=1636248422222257 1026 To: ;tag=925A3CAD-CEBB276E 1027 Call-ID: ef4704d9-bb68aa0b-474c9d94 1028 CSeq: 232 NOTIFY 1029 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1846 1030 Max-Forwards: 70 1031 Content-Type: application/dialog-info+xml 1032 Event: dialog;shared 1033 Subscription-State: active 1034 Contact: 1035 Content-Length: ... 1037 1038 1042 1044 F6 Alice ----> Appearance Agent 1046 SIP/2.0 200 OK 1047 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1846 1048 From: ;tag=1636248422222257 1049 To: ;tag=925A3CAD-CEBB276E 1050 CSeq: 232 NOTIFY 1051 Call-ID: ef4704d9-bb68aa0b-474c9d94 1052 Contact: 1053 Event: dialog;shared 1054 Content-Length: 0 1056 10.2. Appearance Selection for Incoming Call 1058 In the call flow below Bob and Alice are in an appearance group. 1059 Carol places a call to the appearance group AOR. The Appearance 1060 Agent sends NOTIFYs to Alice and Bob telling them what appearance the 1061 call is using. Both Alice and Bob's devices are alerted of the 1062 incoming call. Bob answers the call. 1064 Note that it is possible that both Alice and Bob answer the call and 1065 send 200 OK responses to Carol. It is up to Carol to resolve this 1066 situation. Typically, Carol will send ACKs to both 200 OKs but send 1067 a BYE to terminate one of the dialogs. As a result, either Alice or 1068 Bob will receive the BYE and publish that their dialog is over. 1069 However, if Carol answers both Alice and Bob and keeps both dialogs 1070 active, then the Appearance Agent will need to resolve the situation 1071 by moving either Alice or Bob's dialog to a different appearance. 1073 All NOTIFY messages in the call flow below carry dialog events and 1074 only dialog states are mentioned for simplicity. For brevity, the 1075 details of some messages are not shown below. 1077 Forking Appearance 1078 Carol Proxy Agent Alice Bob 1079 | | | | | 1080 |>F1 INVITE >| | | | 1081 | |< - - - - - >| | | 1082 | | |>F2 NOTIFY ----------->| 1083 | | | | | 1084 | | |F4 NOTIFY ->| | 1087 | | | | | 1088 | | |<-200 OK F5-<| | 1089 |<- 100 F6 -<| | | | 1090 | |>F7 INVITE (appearance=1) ---------->| 1091 | | | | | 1092 | |>F8 INVITE (appearance=1) >| | 1093 | | | | | 1094 | |<-------------------- Ringing 180 F9<| 1095 |< 180 F10 -<| | | | 1096 | |<--------- 180 Ringing F11<| | 1097 |< 180 F12 -<| | | | 1098 | | | | | 1099 | |<------------------------ 200 OK F13<| 1100 |< 200 F14 -<| | | | 1101 | | | | | 1102 | |>F15 CANCEL -------------->| | 1103 | | | | | 1104 | |<-------------- 200 OK F16<| | 1105 | | | | | 1106 | |F18 ACK ----------------->| | 1109 |>F19 ACK -->| | | | 1110 | |>F20 ACK --------------------------->| 1111 | | | | | 1112 |<=============Both way RTP established===========>| 1113 | | | | | 1114 | | |>F21 NOTIFY >| | 1115 | | | | | 1116 | | |<- 200 F22 -<| | 1117 | | | | | 1118 | | |>F23 NOTIFY ---------->| 1119 | | | | | 1120 | | | Alice 1127 NOTIFY sip:alice@ua1.example.com SIP/2.0 1128 From: ;tag=151702541050937 1129 To: ;tag=18433323-C3D237CE 1130 Call-ID: 1e361d2f-a9f51109-bafe31d4 1131 CSeq: 12 NOTIFY 1132 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1403 1133 Max-Forwards: 70 1134 Content-Type: application/dialog-info+xml 1135 Event: dialog;shared 1136 Subscription-State: active 1137 Contact: 1138 Content-Length: ... 1140 1141 1146 1150 1 1151 trying 1152 1153 sip:carol@ua.example.com 1154 1155 1156 1158 F7 Proxy ----> Bob 1160 INVITE sip:alice@ua3.example.com SIP/2.0 1161 Via: SIP/2.0/UDP ua3.example.com;branch=z9hG4bK4324ea 1162 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK38432ji 1163 From: ;tag=44BAD75D-E3128D42 1164 To: 1165 CSeq: 106 INVITE 1166 Call-ID: 14-1541707345 1167 Contact: 1168 Max-Forwards: 69 1169 Alert-Info: ;alert=normal;appearance=1 1170 Content-Type: application/sdp 1171 Content-Length: 223 1173 v=0 1174 o=- 1102980499 1102980499 IN IP4 ua3.example.com 1175 s= 1176 c=IN IP4 ua3.example.com 1177 t=0 0 1178 a=sendrecv 1179 m=audio 2238 RTP/AVP 0 8 101 1180 a=rtpmap:0 PCMU/8000 1181 a=rtpmap:8 PCMA/8000 1182 a=rtpmap:101 telephone-event/8000 1184 F21 Appearance Agent ----> Alice 1186 NOTIFY sip:alice@ua1.example.com SIP/2.0 1187 From: ;tag=151702541050937 1188 To: ;tag=18433323-C3D237CE 1189 Call-ID: 1e361d2f-a9f51109-bafe31d4 1190 CSeq: 12 NOTIFY 1191 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1403 1192 Max-Forwards: 70 1193 Content-Type: application/dialog-info+xml 1194 Event: dialog;shared 1195 Subscription-State: active 1196 Contact: 1197 Content-Length: ... 1199 1200 1205 1210 1 1211 confirmed 1212 1213 sip:carol@ua.example.com 1215 1216 1217 1219 10.3. Outgoing Call without Appearance Pre-Selection 1221 In this scenario, Bob's UA places a call without first selecting an 1222 appearance number. After Bob sends the INVITE, the appearance 1223 assigns an appearance number for it and notifies both Alice and Bob. 1225 Carol Proxy Alice Appearance Agent Bob 1226 | | | | | 1227 | | | | | 1228 | |<------------------------------------- INVITE F1<| 1229 | | | | | 1230 | |>F2 100 Trying --------------------------------->| 1231 |<-- INVITE F3<| | | | 1232 | | |<-- NOTIFY F4<| | 1233 | | | | | 1234 | | |>F5 200 OK -->| | 1235 | | | |------- NOTIFY F6>| 1236 | | | | | 1237 | | | |F8 180 ---->| | | | 1239 | |>F9 180 Ringing -------------------------------->| 1240 | | | | | 1241 | | |<- NOTIFY F10<| | 1242 | | | | | 1243 | | |>F11 200 OK ->| | 1244 | | | |------ NOTIFY F12>| 1245 | | | | | 1246 | | | |F14 200 OK ->| | | | 1248 | |>F15 200 OK ------------------------------------>| 1249 | | | | | 1250 | |<--------------------------------------- ACK F16<| 1251 |<---- ACK F17<| | | | 1252 | | | | | 1253 |<================= Both way RTP established ===================>| 1254 | | | | | 1255 | | |<- NOTIFY F18<| | 1256 | | | | | 1257 | | |>F19 200 OK ->| | 1258 | | | |------ NOTIFY F20>| 1259 | | | | | 1260 | | | | Proxy 1266 INVITE sip:carol@example.com SIP/2.0 1267 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK98c87c52123A08BF 1268 From: ;tag=15A3DE7C-9283203B 1269 To: 1270 CSeq: 1 INVITE 1271 Call-ID: f3b3cbd0-a2c5775e-5df9f8d5 1272 Contact: 1273 Max-Forwards: 70 1274 Content-Type: application/sdp 1275 Content-Length: 223 1277 v=0 1278 o=- 1102980499 1102980499 IN IP4 ua2.example.com 1279 s=IP SIP UA 1280 c=IN IP4 ua2.example.com 1281 t=0 0 1282 a=sendrecv 1283 m=audio 2236 RTP/AVP 0 8 101 1284 a=rtpmap:0 PCMU/8000 1285 a=rtpmap:8 PCMA/8000 1286 a=rtpmap:101 telephone-event/8000 1288 F6 Appearance Agent ----> Bob 1290 NOTIFY sip:bob@ua1.example.com SIP/2.0 1291 From: ;tag=497585728578386 1292 To: ;tag=633618CF-B9C2EDA4 1293 Call-ID: a7d559db-d6d7dcad-311c9e3a 1294 CSeq: 7 NOTIFY 1295 Via: SIP/2.0/UDP appearanceagent.example.com 1296 ;branch=z9hG4bK1711759878512309 1297 Max-Forwards: 70 1298 Content-Type: application/dialog-info+xml 1299 Event: dialog;shared 1300 Subscription-State: active 1301 Contact: 1302 Content-Length: ... 1304 1305 1310 1313 0 1314 false 1315 trying 1316 1317 1318 1319 1320 1321 1323 10.4. Outgoing Call with Appearance Pre-Selection 1325 In this scenario, Bob's UA sends out a dialog event PUBLISH with 1326 state (trying) selecting an appearance number before sending the 1327 INVITE. After receiving the 200 OK from the Appearance Agent 1328 confirming the appearance number, Bob's UA sends the INVITE to Carol 1329 and establishes a session. For brevity, details of some of the 1330 messages are not included in the message flows. 1332 Carol Proxy Alice Appearance Agent Bob 1333 | | | | | 1334 | | | |<----- PUBLISH F1<| 1335 | | | | | 1336 | | | |>F2 200 OK ------>| 1337 | | | | | 1338 | | |<-- NOTIFY F3<| | 1339 | | | | | 1340 | | |>F4 200 OK -->| | 1341 | | | |------- NOTIFY F5>| 1342 | | | | | 1343 | | | |F8 100 Trying --------------------------------->| 1348 |<-- INVITE F9<| | | | 1349 | | | |<---- PUBLISH F10<| 1350 | | | | | 1351 | | | |>F11 200 OK ----->| 1352 | | | | | 1353 |>F12 180 --->| | | | 1354 | |>F13 180 Ringing ------------------------------->| 1355 | | | | | 1356 | | |<- NOTIFY F14<| | 1357 | | | | | 1358 | | |>F15 200 OK ->| | 1359 | | | |------ NOTIFY F16>| 1360 | | | | | 1361 | | | |F18 200 OK ->| | | | 1363 | |>F19 200 OK ------------------------------------>| 1364 | | | | | 1365 | |<--------------------------------------- ACK F20<| 1366 |<---- ACK F21<| | | | 1367 | | | | | 1368 |<================= Both way RTP established ===================>| 1369 | | | | | 1370 | | |<- NOTIFY F22<| | 1371 | | | | | 1372 | | |>F23 200 OK ->| | 1373 | | | |------ NOTIFY F24>| 1374 | | | | | 1375 | | | | Appearance Agent 1394 PUBLISH sip:alice@example.com SIP/2.0 1395 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 1396 From: ;tag=44150CC6-A7B7919D 1397 To: 1398 CSeq: 7 PUBLISH 1399 Call-ID: 44fwF144-F12893K38424 1400 Contact: 1401 Event: dialog;shared 1402 Max-Forwards: 70 1403 Content-Type: application/dialog-info+xml 1404 Content-Length: ... 1406 1407 1412 1413 0 1414 false 1415 trying 1416 1417 1418 1419 1420 1421 1423 F10 Bob ----> Appearance Agent 1425 PUBLISH sip:alice@example.com SIP/2.0 1426 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK6d644638E7 1427 From: ;tag=0CCf6-A7FdsB79D 1428 To: 1429 CSeq: 437 PUBLISH 1430 Call-ID: fwF14d4-F1FFF2F2893K38424 1431 Contact: 1432 Event: dialog;shared 1433 Max-Forwards: 70 1434 Content-Type: application/dialog-info+xml 1435 Content-Length: ... 1437 1438 1443 1447 0 1448 false 1449 trying 1450 1451 1452 1453 1454 1455 1457 10.5. Outgoing Call without using an Appearance Number 1459 In this scenario, Bob's UA sends out a dialog event PUBLISH with 1460 state (trying) indicating that he does not want to utilize an 1461 appearance number for this dialog. The PUBLISH does not have an 1462 appearance element but does have the 'shared' dialog event parameter. 1463 As a result, the Appearance Agent knows the UA does not wish to use 1464 an appearance number for this call. If the Appearance Agent does not 1465 wish to allow this, it would reject the PUBLISH with a 409 Conflict 1466 response and the UA would know to re-PUBLISH selecting an appearance 1467 number. 1469 Carol Proxy Alice Appearance Agent Bob 1470 | | | | | 1471 | | | |<----- PUBLISH F1<| 1472 | | | | | 1473 | | | |>F2 200 OK ------>| 1474 | | | | | 1475 | | |<-- NOTIFY F3<| | 1476 | | | | | 1477 | | |>F4 200 OK -->| | 1478 | | | |------- NOTIFY F5>| 1479 | | | | | 1480 | | | |F8 100 Trying --------------------------------->| 1485 |<-- INVITE F9<| | | | 1486 | | | |<---- PUBLISH F10<| 1487 | | | | | 1488 | | | |>F11 200 OK ----->| 1489 | | | | | 1490 |>F12 180 --->| | | | 1491 | |>F13 180 Ringing ------------------------------->| 1492 | | | | | 1493 | | |<- NOTIFY F14<| | 1494 | | | | | 1495 | | |>F15 200 OK ->| | 1496 | | | |------ NOTIFY F16>| 1497 | | | | | 1498 | | | |F18 200 OK ->| | | | 1500 | |>F19 200 OK ------------------------------------>| 1501 | | | | | 1502 | |<--------------------------------------- ACK F20<| 1503 |<---- ACK F21<| | | | 1504 | | | | | 1505 |<================= Both way RTP established ===================>| 1506 | | | | | 1507 | | |<- NOTIFY F22<| | 1508 | | | | | 1509 | | |>F23 200 OK ->| | 1510 | | | |------ NOTIFY F24>| 1511 | | | | | 1512 | | | | Appearance Agent 1519 PUBLISH sip:appearanceagent.example.com SIP/2.0 1520 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 1521 From: ;tag=4415df82k39sf 1522 To: 1523 CSeq: 7 PUBLISH 1524 Call-ID: 44fwF144-F12893K38424 1525 Contact: 1526 Event: dialog;shared 1527 Max-Forwards: 70 1528 Content-Type: application/dialog-info+xml 1529 Content-Length: ... 1531 1532 1537 1538 false 1539 trying 1540 1541 1542 1543 1544 1545 1547 10.6. Appearance Release 1549 Bob and Carol are in a dialog, created in one of the previous two 1550 call flows. Carol sends a BYE to Bob to terminate the dialog. Bob 1551 publishes the termination of the dialog and the Appearance Agent de- 1552 allocates the appearance number used. 1554 Carol Proxy Alice Appearance Agent Bob 1555 | | | | | 1556 | | | | | 1557 |<================= Both way RTP established ===================>| 1558 | | | | | 1559 |>F22 BYE ---->| | | | 1560 | |>F23 BYE --------------------------------------->| 1561 | | | | | 1562 | |<------------------------------------ 200 OK F24<| 1563 |<--200 OK F25<| | | | 1564 | | |<- NOTIFY F26<| | 1565 | | | | | 1566 | | |>F27 200 OK ->| | 1567 | | | |------ NOTIFY F28>| 1568 | | | | | 1569 | | | | Bob 1575 NOTIFY sip:bob@ua1.example.com SIP/2.0 1576 From: ;tag=497585728578386 1577 To: 1578 Call-ID: a7d559db-d6d7dcad-311c9e3a 1579 CSeq: 7 NOTIFY 1580 Via: SIP/2.0/UDP appearanceagent.example.com 1581 ;branch=z9hG4bK759878512309 1582 Max-Forwards: 70 1583 Content-Type: application/dialog-info+xml 1584 Event: dialog;shared 1585 Subscription-State: active 1586 Contact: 1587 Content-Length: ... 1589 1590 1595 1600 0 1601 false 1602 terminated 1603 1604 1605 1606 1607 1608 1610 10.7. Appearance Pickup 1612 In this scenario, Bob has an established dialog with Carol created 1613 using the call flows of Figure 1 or Figure 2. Bob then places Carol 1614 on hold. Alice receives a notification of this and renders this on 1615 Alice's UI. Alice subsequently picks up the held call and has a 1616 established session with Carol. Finally, Carol hangs up. 1618 Carol Proxy Alice Appearance Agent Bob 1619 | | | | | 1620 |<================= Both way RTP established ===================>| 1621 | | | | | 1622 | |<------------------------------(hold) INVITE F22<| 1623 |<- INVITE F23<| | | | 1624 | | | | | 1625 |>F24 200 OK ->| | | | 1626 | |>F25 200 OK ------------------------------------>| 1627 | | | | | 1628 | |<--------------------------------------- ACK F26<| 1629 |<---- ACK F27<| | | | 1630 | | |<- NOTIFY F28<| | 1631 | | | | | 1632 | | |>F29 200 OK ->| | 1633 | | | |>F30 NOTIFY ----->| 1634 | | | | | 1635 | | | |<----- 200 OK F31<| 1636 | | | | | 1637 | | Alice decides to pick up the call | 1638 | | | | | 1639 | | |>F32 PUBLISH->| | 1640 | | | | | 1641 | | |<- 200 OK F33<| | 1642 | | | | | 1643 | | |<- NOTIFY F34<| | 1644 | | | | | 1645 | | |>F35 200 OK ->| | 1646 | | | |>F36 NOTIFY ----->| 1647 | | | | | 1648 | | | |<----- 200 OK F37<| 1649 | |<-- INVITE F38<| | | 1650 |<- INVITE F39<|(w/ Replaces) | | | 1651 |( w/ Replaces)| | | | 1652 |>F40 200 OK ->| | | | 1653 | |>F41 200 OK -->| | | 1654 | | | |>F42 NOTIFY ----->| 1655 | | | | | 1656 | | | |<----- 200 OK F43<| 1657 | | |<- NOTIFY F44<| | 1658 | | | | | 1659 | | |>F45 200 OK ->| | 1660 | | | | | 1661 | |<----- ACK F46<| | | 1662 |<---- ACK F47<| | | | 1663 | | | | | 1664 |<= Both way RTP established =>| | | 1665 | | | | | 1666 |>F48 BYE ---->| | | | 1667 | |>F49 BYE --------------------------------------->| 1668 | | | | | 1669 | |<------------------------------------ OK 200 F50<| 1670 |<- 200 OK F51<| | | | 1671 | | | | | 1672 | | |<- NOTIFY F52<| | 1673 | | | | | 1674 | | |>F53 200 OK ->| | 1675 | | | | | 1676 | | | |>F54 NOTIFY ----->| 1677 | | | | | 1678 | | | |<----- 200 OK F55<| 1680 Figure 7. 1682 F28 Appearance ----> Alice 1684 NOTIFY sip:alice@ua1.example.com SIP/2.0 1685 From: ;tag=151702541050937 1686 To: ;tag=18433323-C3D237CE 1687 Call-ID: 1e361d2f-a9f51109-bafe31d4 1688 CSeq: 12 NOTIFY 1689 Via: SIP/2.0/UDP appearanceagent.example.com 1690 ;branch=z9hG4bK1403 1691 Max-Forwards: 70 1692 Content-Type: application/dialog-info+xml 1693 Event: dialog;shared 1694 Subscription-State: active 1695 Contact: 1696 Content-Length: ... 1698 1699 1704 1709 0 1710 false 1711 active 1712 1713 1714 1715 1716 1717 1718 sip:carol@example.com 1719 1720 1721 1722 1724 F32 Alice ----> Appearance Agent 1726 PUBLISH sip:alice@example.com SIP/2.0 1727 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A 1728 From: ;tag=44150CC6-A7B7919D 1729 To: ;tag=428765950880801 1730 CSeq: 11 PUBLISH 1731 Call-ID: 87837Fkw87asfds 1732 Contact: 1733 Event: dialog;shared 1734 Max-Forwards: 70 1735 Content-Type: application/dialog-info+xml 1736 Content-Length: ... 1738 1739 1744 1747 0 1748 false 1749 1753 trying 1754 1755 1756 1757 1759 1760 1761 1762 1763 1764 1766 F38 Alice ----> Proxy 1768 INVITE sip:carol@example.com SIP/2.0 1769 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK4ea695b5B376A60C 1770 From: ;tag=8C4183CB-BCEAB710 1771 To: 1772 CSeq: 1 INVITE 1773 Call-ID: 3d57cd17-47deb849-dca8b6c6 1774 Contact: 1775 1776 Replaces: f3b3cbd0-a2c5775e-5df9f8d5;to-tag=65a98f7c 1777 -1dd2-11b2-88c6-b03162323164+65a98f7c;from-tag=15A3DE7C-9283203B 1778 1779 Max-Forwards: 70 1780 Content-Type: application/sdp 1781 Content-Length: 223 1783 v=0 1784 o=- 1102980497 1102980497 IN IP4 ua1.example.com 1785 s=IP SIP UA 1786 c=IN IP4 ua1.example.com 1787 t=0 0 1788 a=sendrecv 1789 m=audio 2238 RTP/AVP 0 8 101 1790 a=rtpmap:0 PCMU/8000 1791 a=rtpmap:8 PCMA/8000 1792 a=rtpmap:101 telephone-event/8000 1794 10.8. Calls between UAs within the Group 1796 In this scenario, Bob calls Alice who is also in the Appearance 1797 group. 1799 Carol Proxy Alice Appearance Agent Bob 1800 | | | | | 1801 | |<-------------------- INVITE (to Alice's UA) F1<| 1802 | | | | | 1803 | |<- - - - - - ->| | | 1804 | | | | | 1805 | | |<-- NOTIFY F2<| | 1806 | | | | | 1807 | | |>F3 200 OK -->| | 1808 | | | |>F4 NOTIFY ------>| 1809 | | | | | 1810 | | | |<------ 200 OK F5<| 1811 | |>F6 INVITE --->| | | 1812 | | (appearance=1)| | | 1813 | | | | | 1814 | |<------ 180 F7<| | | 1815 | | | | | 1816 | |>F8 180 --------------------------------------->| 1817 | | | | | 1818 | | |<-- NOTIFY F9<| | 1819 | | | | | 1820 | | |>F10 200 OK ->| | 1821 | | | |>F11 NOTIFY ----->| 1822 | | | | | 1823 | | | |<----- 200 OK F12<| 1824 | |<-- 200 OK F13<| | | 1825 | | |<- NOTIFY F14<| | 1826 | | | | | 1827 | | |>F15 200 OK ->| | 1828 | | | |>F16 NOTIFY ----->| 1829 | | | | | 1830 | | | |<----- 200 OK F17<| 1831 | | | | | 1832 | |>F18 200 OK ------------------------------------>| 1833 | | | | | 1834 | |<--------------------------------------- ACK F19<| 1835 | | | | | 1836 | |>F20 ACK ----->| | | 1837 | | | | | 1838 | | |<======= RTP established =======>| 1839 | | | | | 1840 | | |<- NOTIFY F21<| | 1841 | | | | | 1842 | | |>F22 200 OK ->| | 1843 | | | |>F23 NOTIFY ----->| 1844 | | | | | 1845 | | | |<----- 200 OK F24<| 1846 | | | | | 1848 Figure 8. 1850 F16 Appearance Agent ----> Bob 1851 NOTIFY sip:bob@ua1.example.com SIP/2.0 1852 From: ;tag=497585728578386 1853 To: ;tag=633618CF-B9C2EDA4 1854 Call-ID: a7d559db-d6d7dcad-311c9e3a 1855 CSeq: 7 NOTIFY 1856 Via: SIP/2.0/UDP appearanceagent.example.com 1857 ;branch=z9hG4bK1711759878512309 1858 Max-Forwards: 70 1859 Content-Type: application/dialog-info+xml 1860 Event: dialog;shared 1861 Subscription-State: active 1862 Contact: 1863 Content-Length: ... 1865 1866 1871 1876 true 1877 1 1878 connected 1879 1880 1881 1882 1883 1884 sip:alice@example.com 1885 1886 1887 1889 1894 true 1895 1 1896 connected 1897 1898 1900 1901 1902 sip:alice@example.com 1903 1904 1905 1907 1909 10.9. Consultation Hold with Appearances 1911 In this scenario, Bob has a call with Carol. Bob makes a 1912 consultation call to Alice by putting Carol on hold and calling 1913 Alice. Bob chooses not to have an appearance number for the call to 1914 Alice since he is treating it as part of the call to Carol. He 1915 indicates this in his PUBLISH F32 which is sent before the INVITE to 1916 Alice to ensure no appearance number is assigned by the Appearance 1917 Agent. Finally, Bob hangs up with Alice and resumes the call with 1918 Carol. Note that the Appearance Agent does not generate 1919 notifications on the dialog state of the consultation call. 1921 Note that if Carol hangs up while Bob is consulting with Alice, Bob 1922 can decide if he wants to reuse the appearance number used with Carol 1923 for the call with Alice. If not, Bob publishes the termination of 1924 the dialog with Carol and the Appearance Agent will re-allocate the 1925 appearance. If he wants to keep the appearance, Bob will publish the 1926 termination of the dialog with Carol and also publish the appearance 1927 with the dialog with Alice. This will result in Bob keeping the 1928 appearance number until he reports the dialog with Alice terminated. 1930 Carol Proxy Alice Appearance Agent Bob 1931 | | | | | 1932 |<================= Both way RTP established ===================>| 1933 | | | | | 1934 | |<------------------------------(hold) INVITE F22<| 1935 |<- INVITE F23<| | | | 1936 | | | | | 1937 |>F24 200 OK ->| | | | 1938 | |>F25 200 OK ------------------------------------>| 1939 | | | | | 1940 | |<--------------------------------------- ACK F26<| 1941 |<---- ACK F27<| | | | 1942 | | |<- NOTIFY F28<| | 1943 | | | | | 1944 | | |>F29 200 OK ->| | 1945 | | | |>F30 NOTIFY ----->| 1946 | | | | | 1947 | | | |<----- 200 OK F31<| 1948 | | | | | 1949 | | Bob makes a consultation call to Alice | 1950 | | | | | 1951 | | | |<---- PUBLISH F32<| 1952 | | | | | 1953 | | | |>F33 200 OK ----->| 1954 | | | | | 1955 | |<------------------------------------ INVITE F34<| 1956 | | | | | 1957 | |>F35 INVITE -->| | | 1958 | | | | | 1959 | |<-- 200 OK F36<| | | 1960 | | | | | 1961 | |>F37 200 OK ------------------------------------>| 1962 | | | | | 1963 | |<--------------------------------------- ACK F38<| 1964 | | | | | 1965 | |>F39 ACK ----->| | | 1966 | | | | | 1967 | | |<======= RTP established =======>| 1968 | | | | | 1969 | | Bob hangs up with Alice | 1970 | | | | | 1971 | |<--------------------------------------- BYE F40<| 1972 | | | | | 1973 | |>F41 BYE ----->| | | 1974 | | | | | 1975 | |<-- 200 OK F42<| | | 1976 | | | | | 1977 | |>F43 200 OK ------------------------------------>| 1978 | | | | | 1979 | |<----------------------------(unhold) INVITE F44<| 1980 |<- INVITE F45<| | | | 1981 | | | | | 1982 |>F46 200 OK ->| | | | 1983 | |>F47 200 OK ------------------------------------>| 1984 | | | | | 1985 | |<--------------------------------------- ACK F48<| 1986 |<---- ACK F49<| | | | 1987 | | |<- NOTIFY F50<| | 1988 | | | | | 1989 | | |>F51 200 OK ->| | 1990 | | | |>F52 NOTIFY ----->| 1991 | | | | | 1992 | | | |<----- 200 OK F53<| 1993 | | | | | 1994 |<================= Both way RTP established ===================>| 1995 | | | | | 1997 Figure 9. 1999 F32 Bob ----> Appearance Agent 2001 PUBLISH sip:alice@example.com SIP/2.0 2002 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A 2003 From: ;tag=44150CC6-A7B7919D 2004 To: ;tag=428765950880801 2005 CSeq: 11 PUBLISH 2006 Call-ID: 44fwF144-F12893K38424 2007 Contact: 2008 Event: dialog;shared 2009 Max-Forwards: 70 2010 Content-Type: application/dialog-info+xml 2011 Content-Length: ... 2013 2014 2019 2023 true 2024 trying 2025 2026 2027 2028 2029 2030 sip:alice@example.com 2031 2032 2033 2034 2036 10.10. Joining or Bridging an Appearance 2038 In this call flow, a call answered by Bob is joined by Alice or 2039 "bridged". The Join header field is used by Alice to request this 2040 bridging. If Bob did not support media mixing, Bob could obtain 2041 conferencing resources as described in [RFC4579]. 2043 Carol Forking Proxy Appearance Agent Alice Bob 2044 | | | | | 2045 |<=============Both way RTP established===========>| 2046 | | | | | 2047 | | |< PUBLISH F22| | 2048 | | | | | 2049 | | |>F23 200 OK >| | 2050 | | | | | 2051 | |<---- INVITE (w/ Join) F24<| | 2052 | | | | | 2053 | |>F25 INVITE (w/Join)---------------->| 2054 | | | | | 2055 | |<---- OK 200 Contact:Bob;isfocus F26<| 2056 | | | | | 2057 | | |>F27 NOTIFY >| | 2058 | | | | | 2059 | | |< 200 OK F28<| | 2060 | | | | | 2061 | | |>F29 NOTIFY ---------->| 2062 | | | | | 2063 | | |F31 200 OK Contact:B----->| | 2066 | | | | | 2067 | |<----------------- ACK F32<| | 2068 | | | | | 2069 | |>ACK F33---------------------------->| 2070 | | | | | 2071 | |<-----INVITE Contact:Bob;isfocus F34<| 2072 |<-INVITE F35| | | | 2073 | | | | | 2074 |>F26 200 -->| | | | 2075 | |>F37 200 OK ------------------------>| 2076 | | | | | 2077 | |<--------------------------- ACK F38<| 2078 |<--- ACK F39| | | | 2079 | | | |<==RTP==>| 2080 |<=============Both way RTP established===========>| 2081 | | | | | 2082 | | |>F40 NOTIFY >| | 2083 | | | | | 2084 | | |< 200 OK F41<| | 2085 | | | | | 2086 | | |>F42 NOTIFY ---------->| 2087 | | | | | 2088 | | | Appearance Agent 2095 PUBLISH sip:alice@example.com SIP/2.0 2096 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A 2097 From: ;tag=44150CC6-A7B7919D 2098 To: ;tag=428765950880801 2099 CSeq: 11 PUBLISH 2100 Call-ID: 87837Fkw87asfds 2101 Contact: 2102 Event: dialog;shared 2103 Max-Forwards: 70 2104 Content-Type: application/dialog-info+xml 2105 Content-Length: ... 2107 2108 2113 2116 0 2117 false 2118 2122 trying 2123 2124 2125 2126 2127 2128 2129 2130 2131 2133 F24 Alice ----> Proxy 2135 INVITE sip:bob@ua.example.com SIP/2.0 2136 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKcc9d727c2C29BE31 2137 From: ;tag=605AD957-1F6305C2 2138 To: 2139 CSeq: 2 INVITE 2140 Call-ID: dc95da63-60db1abd-d5a74b48 2141 Contact: 2142 2143 Join: 14-1541707345;to-tag=d3b06488-1dd1-11b2-88c5 2144 -b03162323164+d3e48f4c;from-tag=44BAD75D-E3128D42 2145 2146 Max-Forwards: 70 2147 Content-Type: application/sdp 2148 Content-Length: 223 2150 v=0 2151 o=- 1103061265 1103061265 IN IP4 ua1.example.com 2152 s=IP SIP UA 2153 c=IN IP4 ua1.example.com 2154 t=0 0 2155 a=sendrecv 2156 m=audio 2236 RTP/AVP 0 8 101 2157 a=rtpmap:0 PCMU/8000 2158 a=rtpmap:8 PCMA/8000 2159 a=rtpmap:101 telephone-event/8000 2161 10.11. Appearance Allocation - Loss of Appearance 2163 Bob reserves an appearance with a PUBLISH, sends an INVITE to Carol, 2164 then becomes unreachable. When he fails to refresh his publication 2165 to the appearance agent, the Appearance Agent declares the dialog 2166 terminated and frees up the appearance using NOTIFYs R24 and F26. 2167 After retransmitting the NOTIFY F26 to Bob, the subscription is 2168 terminated. 2170 Carol Proxy Alice Appearance Agent Bob 2171 | | | | | 2172 | | | |<----- PUBLISH F1<| 2173 | | | | | 2174 | | | |>F2 200 OK ------>| 2175 | | | | | 2176 | | |<-- NOTIFY F3<| | 2177 | | | | | 2178 | | |>F4 200 OK -->| | 2179 | | | |------- NOTIFY F5>| 2180 | | | | | 2181 | | | |F8 100 Trying --------------------------------->| 2186 |<-- INVITE F9<| | | | 2187 | | | |<---- PUBLISH F10<| 2188 | | | | | 2189 | | | |>F11 200 OK ----->| 2190 | | | | | 2191 |>F12 180 --->| | | | 2192 | |>F13 180 Ringing ------------------------------->| 2193 | | | | | 2194 | | | | Bob goes offline 2195 | | | | 2196 | | | Appearance selection times out 2197 | | | | 2198 | | | | 2199 | | |<- NOTIFY F14<| 2200 | | | | 2201 | | |>F15 200 OK ->| 2202 | | | |------ NOTIFY F16> 2203 | | | | 2204 | | | NOTIFY is retransmitted 2206 Figure 11. 2208 10.12. Appearance Selection Contention Race Condition 2210 Bob and Alice both try to reserve appearance 2 by publishing at the 2211 same time. The Appearance Agent allocates the appearance to Bob by 2212 sending a 200 OK and denies it to Alice by sending a 409 Conflict. 2213 After the NOTIFY F24, Alice learns that Bob is using appearance 2. 2214 Alice republishes for appearance 3 which is accepted. 2216 Carol Proxy Alice Appearance Agent Bob 2217 | | | | | 2218 | | | |<----- PUBLISH F1<| 2219 | | | | (appearance=2) 2220 | | |>F2 PUBLISH ->| | 2221 | | | (appearance=2) | 2222 | | | | | 2223 | | | |>F3 200 OK ------>| 2224 | | |<---- F4 409 <| | 2225 | | | | | 2226 | | |<-- NOTIFY F5<| | 2227 | | | | | 2228 | | |>F6 200 OK -->| | 2229 | | | |------- NOTIFY F7>| 2230 | | | | | 2231 | | | |F10 100 Trying -------------------------------->| 2236 |<- INVITE F11<| | | | 2237 | | | |<---- PUBLISH F12<| 2238 | | | | (appearance=2) 2239 | | | |>F13 200 OK ----->| 2240 | | |>F14 PUBLISH->| | 2241 | | | (appearance=3) | 2242 | | | | | 2243 | | |<--- F15 200 <| | 2244 | | | | | 2245 | | |<- NOTIFY F16<| | 2246 | | | | | 2247 | |>F17 200 OK ->| | 2248 Dave | | |------ NOTIFY F18>| 2249 | | | | | 2250 | | | |F21 100 ----->| | | 2254 |<- INVITE F22<| | | | 2256 Figure 12. 2258 10.13. Appearance Agent Subscription to UAs 2260 In this scenario, the Appearance Agent does not have any way of 2261 knowing Bob's dialog state information, except through Bob. This 2262 could be because the Appearance Agent is not part of a B2BUA, or 2263 perhaps Bob is remotely registering. When Bob registers, the 2264 Appearance Agent receives a registration event package notification 2265 from the registrar. The Appearance Agent then SUBSCRIBEs to Bob's 2266 dialog event state. Whenever Bob's dialog state changes, a NOTIFY is 2267 sent to the Appearance Agent who then notifies the other other UAs in 2268 the group. 2270 Carol Proxy Alice Appearance Agent Bob 2271 | | | | | 2272 | |<----------------------------------- REGISTER F1<| 2273 | | | | | 2274 | |>F2 200 OK ------------------------------------->| 2275 | | | | | 2276 | |>F3 NOTIFY ------------------>| | 2277 | | | | | 2278 | |<------------------ 200 OK F4<| | 2279 | | | |---- SUBSCRIBE F5>| 2280 | | | | | 2281 | | | |F8 200 OK ------>| 2286 | | | | | 2287 | | | |<--- SUBSCRIBE F9<| 2288 | | | | | 2289 | | | |>F10 200 OK ----->| 2290 | | | | | 2291 | | | |------ NOTIFY F11>| 2292 | | | | | 2293 | | | |F14 100 Trying -------------------------------->| 2298 |<- INVITE F15<| | | | 2299 | | | |<----- NOTIFY F16<| 2300 | | | | | 2301 | | | |>F17 200 OK ----->| 2302 | | |<- NOTIFY F18<| | 2303 | | | | | 2304 | | |>F19 200 OK ->| | 2305 | | | |------ NOTIFY F20>| 2306 | | | | | 2307 | | | |F22 180 --->| | | | 2309 | |>F23 180 Ringing ------------------------------->| 2310 | | | | | 2311 | | | |<----- NOTIFY F24<| 2312 | | | | | 2313 | | | |>F25 200 OK ----->| 2314 | | |<- NOTIFY F26<| | 2315 | | | | | 2316 | | |>F27 200 OK ->| | 2317 | | | |------ NOTIFY F28>| 2318 | | | | | 2319 | | | |F30 200 OK ->| | | | 2321 | |>F31 200 OK ------------------------------------>| 2322 | | | | | 2323 | | | |<----- NOTIFY F32<| 2324 | | | | | 2325 | | | |>F33 200 OK ----->| 2326 | | | | | 2327 | |<--------------------------------------- ACK F34<| 2328 |<---- ACK F35<| | | | 2329 | | | | | 2330 |<================= Both way RTP established ===================>| 2331 | | | | | 2332 | | |<- NOTIFY F36<| | 2333 | | | | | 2334 | | |>F37 200 OK ->| | 2335 | | | |------ NOTIFY F38>| 2336 | | | | | 2337 | | | |, 2366 Alan Johnston 2368 XML: 2370 BEGIN 2371 2372 2374 2375 2376 2378 Shared Appearance Dialog Information Namespace 2379 2380 2381

Namespace for Shared Appearance Dialog Information

2382

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

2383

See 2384 RFCXXXX.

2385 2386 2387 END 2389 11.3. XML Schema Registration 2391 This section registers an XML schema per the procedures in 2392 [RFC3688]. 2394 URI: urn:ietf:params:xml:schesa:sa-dialog-info. 2396 Registrant Contact: IETF BLISS working group, , 2397 Alan Johnston 2399 The XML for this schema can be found in Section 6. 2401 12. Appendix A - Incoming Appearance Assignment 2403 To best meet REQ-9, the appearance number for an incoming INVITE 2404 should be contained in the INVITE itself. 2406 For the dialog package parameter approach, REQ-9 could be met in two 2407 ways. When an incoming request is received, the Appearance Agent 2408 could send out a NOTIFY with state trying and include the appearance 2409 number to be used for this request. Upon receipt of this NOTIFY, the 2410 UAs could begin alerting using the appearance number selected. This 2411 approach is sub-optimal since the UAs could receive the INVITE but be 2412 unable to begin alerting if the NOTIFY from the Appearance Agent is 2413 delayed or lost 2415 An alternative approach is to define an extension parameter for the 2416 Alert-Info header field in RFC 3261 such as: 2418 Alert-Info: ;alert=normal;appearance=0 2420 This Alert-Info header would indicate to place the call on the first 2421 line appearance instance. 2423 OPEN ISSUE: What URI do we use if no special ring is requested? 2425 The determination as to what value to use in the appearance parameter 2426 can be done at the proxy that forks the incoming request to all the 2427 registered UAs. There are a variety of ways the proxy can use to 2428 determine what value it should use to populate this parameter. For 2429 example, the proxy could fetch this information by initiating a 2430 SUBSCRIBE request with Expires: 0 to the Appearance Agent for the AOR 2431 to fetch the list of lines that are in use. Alternatively, it could 2432 act like a UA that is a part of the appearance group and SUBSCRIBE to 2433 the State-Agent like any other UA. This would ensure that the active 2434 dialog information is available without having to poll on a need 2435 basis. It could keep track of the list of active calls for the 2436 appearance AOR based on how many unique INVITE requests it has forked 2437 to or received from the appearance AOR. Another approach would be 2438 for the Proxy to first send the incoming INVITE to the Appearance 2439 Agent which would redirect to the appearance group URI and escape the 2440 proper Alert-Info header field for the Proxy to recurse and 2441 distribute to the other UAs in the group. 2443 The Appearance Agent needs to know about all incoming requests to the 2444 AOR in order to select the appearance number. One way in which this 2445 could be done is for the Appearance Agent to register against the AOR 2446 with a higher q value. This will result in the INVITE being sent to 2447 the Appearance Agent first, then being offered to the UAs in the 2448 group. 2450 The changes to RFC 3261 ABNF would be: 2452 alert-param = LAQUOT absoluteURI RAQUOT *( SEMI (generic-param / 2453 appearance-param) ) 2455 appearance-param = "appearance" EQUAL *DIGIT 2457 13. Appendix B - Implementation Options Discussion 2459 This section discusses some options on how to implement the Shared 2460 Appearances feature in SIP. This section is non-normative. 2462 13.1. Appearance Implementation Options 2464 This section discusses and compares two methods of implementing, 2465 conveying, and selecting appearances in SIP while meeting the 2466 requirements of Section 4. One approach involves a URI parameter and 2467 is discussed in section 5.1.1. The other approach uses a SIP dialog 2468 package extension parameter and is discussed in section 5.1.2. Both 2469 approaches assume an Appearance Agent. In addition, this section 2470 discusses approaches for incoming appearance indication, REQ-9, and 2471 appearance contention, REQ-8. These approaches will be discussed for 2472 an example appearance group of N phones each with n line appearances. 2473 The usage of the word phone does not imply that this feature is 2474 limited to telephony devices. 2476 13.1.1. URI parameter Approach 2478 Some implementations of this feature utilize a URI parameter such as 2479 "line=3" on the Contact URI. Each appearance is effectively a 2480 logical UA, so each line appearance requires a separate registration. 2481 The number of line appearances needs to be provisioned on each phone. 2482 Each appearance also requires a separate dialog package subscription. 2483 Even using a State Agent for the dialog package, each phone must 2484 maintain n subscriptions to the dialog package. 2486 This results in 2nN total subscriptions and nN registrations for this 2487 implementation. 2489 Since Contact URI parameters will be conveyed by the dialog package, 2490 REQ-7 is met. 2492 REQ-10 can be met by having the Appearance Agent send a SUBSCRIBE to 2493 each UA and line number to obtain the current dialog state - this 2494 will result in nN SUBSCRIBEs and NOTIFYs. 2496 It is not obvious how to meet REQ-11 with this approach. A UA 2497 registering against the AOR but does not implement the appearance URI 2498 parameter will not include a line appearance number in Contact URIs 2499 and dialog package NOTIFYs. The Appearance Agent will have no way of 2500 indicating to the other UAs the appearance number being used by this 2501 UA, as adding a parameter to the Contact URI would cause call control 2502 operations such as Replaces and Join to fail. 2504 REQs 12 and 13 are difficult to meet with this approach as the line 2505 appearance number will be present in the Request-URI of incoming 2506 requests and the Contact URI in INVITE and 200 OK messages. This 2507 approach will require integrity protection of all dialog creating 2508 requests and responses, and privacy mechanisms to hide the Contact 2509 URI from other UAs. 2511 Also, this approach will require mechanisms to protect against 2512 another UA sending an INVITE directly to a group member with the line 2513 appearance number already set. 2515 13.1.2. Dialog Package Parameter 2517 Instead of the URI parameter approach, consider an extension 2518 parameter "appearance" to the SIP dialog package. The e.g.: 2520 2521 2526 2528 2 2529 false 2530 2532 2534 connected 2535 2536 2537 2538 2539 2540 ... 2542 In this approach, the appearance number is never carried in a 2543 Request-URI or Contact URI. Instead, it is only present in dialog 2544 package NOTIFY and PUBLISH messages. As a result, only a single 2545 registration per AOR is required. Also, only a single dialog package 2546 subscription in each direction per AOR. 2548 This results in 2N total subscriptions and N registrations for this 2549 approach. 2551 If the dialog package is extended to carry the appearance number, 2552 then REQ-7 is met. 2554 REQ-10 can be met by having the Appearance Agent send a SUBSCRIBE to 2555 each UA and line number to obtain the current dialog state - this 2556 will result in N SUBSCRIBEs and NOTIFYs. 2558 REQ-11 can be met by this approach. Even though a UA does not 2559 provide an appearance number in dialog package NOTIFYs, the 2560 Appearance Agent can assign one and include it in NOTIFYs to the 2561 other UAs. This parameter would simply be ignored by the UAs that 2562 did not understand the parameter, and have no impact on call control 2563 operations. 2565 REQs 12 and 13 are met because the appearance number is only conveyed 2566 in dialog package NOTIFYs. Integrity and privacy of NOTIFY bodies 2567 can be achieved using normal SIP mechanisms independent of the 2568 security mechanisms used for other requests. 2570 The dialog-package [RFC3265] describes a mechanism whereby shared- 2571 line privacy REQ-14 can be accomplished by suppressing certain dialog 2572 information from being presented to the UAs. The reasoning behind 2573 that is if the UAs were unaware of a dialog's call-id, local-tag and 2574 remote-tag then they will be unable to create requests such as INVITE 2575 with Replaces [RFC3891] and Join [RFC3911] header fields to barge-in 2576 or pickup the line appearance. Below is a quote from section 3.6 of 2577 dialog-package[RFC3265] that describes this approach: 2579 Note that many implementations of "shared-lines" have a feature that 2580 allows details of calls on a shared address-of-record to be made 2581 private. This is a completely reasonable authorization policy that 2582 could result in notifications that contain only the id attribute of 2583 the dialog element and the state element when shared-line privacy is 2584 requested, and notifications with more complete information when 2585 shared-line privacy is not requested. 2587 There are certain fundamental drawbacks in the privacy-by-obscurity 2588 approach described in [RFC3265] . It models exclusivity as a static 2589 property of the appearance AOR. There are situations where 2590 exclusivity needs to be a dynamic property (e.g. boss does not want 2591 secretary to listen-in on a particular part of the conversation). In 2592 addition, [RFC3265] does not address how a UA can request exclusivity 2593 at the start of a session or mid-session and how that request will be 2594 granted or rejected. 2596 Exclusivity being a dynamic property means that a UA can request it 2597 to be turned on or off in the middle of a session. When exclusivity 2598 is turned off all the UAs that share the line AOR will need to see 2599 the complete dialog information. Once they have that information it 2600 can not be taken back from them. This will not allow exclusivity to 2601 be turned on later on in the dialog lifetime. Therefore, there needs 2602 to be a centralized entity that will actually enforce exclusivity. 2604 The approach proposed for meeting REQ-14 is to include an exclusivity 2605 parameter to the dialog package. This allows a UA to request 2606 exclusivity, by setting the exclusive parameter in notifications. 2607 This could be done prior to a call being made or answered, or during 2608 a call at any time. A UA can remove exclusivity by sending a 2609 notification at any time during a call and setting "exclusive=no". 2610 It also allows a UA to learn that a particular dialog is exclusive by 2611 the presence of this parameter in a NOTIFY. In addition, a UA can 2612 still apply policy to any INVITE Join or Replaces requests it 2613 receives, as per normal SIP call control mechanisms. 2615 With this approach, the number of appearances is centrally managed 2616 and controlled by the Appearance Agent. For UAs with soft keys or 2617 buttons, this gives a great deal of flexibility in system management. 2619 The User Agents in the group could SUBSCRIBE to each other and NOTIFY 2620 dialog state events, but in a large group the User Agents have to 2621 manage a larger number of SUBSCRIPTIONS and NOTIFICATIONS. The State 2622 Agent in the Appearance Agent helps in managing large groups better. 2623 Further, the State Agent can filter dialog state events and NOTIFY 2624 User Agents of the dialog state events which are required for the 2625 application or feature. The State Agent can also SUBSCRIBE to dialog 2626 state events with filters to reduce the number of NOTIFY messages 2627 exchanged between the State Agent and the user agents in the group. 2628 This allows a group of N UAs to each only establish a pair of dialog 2629 state subscriptions (one in each direction) to learn the dialog state 2630 of all other group members. This results in 2N total subscriptions 2631 for the entire group. A full mesh of subscriptions without a state 2632 agent would result in N(N-1) total subscriptions. 2634 13.1.3. Appearance Selections Mechanisms 2636 Regardless of how the appearance number is conveyed by UAs, there is 2637 still the issue of how appearance numbers are selected. For example, 2638 some UAs might have actual buttons and lamps, and pressing a 2639 particular button requires the UA to reserve a particular appearance 2640 number. For devices with this type of user interface, the selection 2641 must be done before the user continues with the call and dials digits 2642 or a URI. Other UAs with different user interfaces can be flexible 2643 at the time of dialing, updating the display with the appearance 2644 number at a later date. For devices which require advance appearance 2645 selection, there are three options discussed in the following 2646 sections for meeting REQ-15. 2648 13.1.3.1. Floor Control Appearance Selection Mechanism 2650 This approach models each appearance number as a floor (shared 2651 resource) and uses a floor control server to arbitrate exclusive 2652 access (seizure of a particular appearance number). This approach 2653 uses a standard SIP Event State Compositor (ESC), a standard Floor 2654 Control Server that uses the Appearance Agent as Moderator. The 2655 Binary Floor Control Protocol (BFCP) is used between the UAs and the 2656 Floor Control Server. A Registrar/Forking Proxy Server talks to 2657 Appearance Agent about incoming calls. The Appearance Agent acts as 2658 a Moderator for the floor control server and tells forking proxy to 2659 insert the appearance number in incoming and outgoing requests. 2661 Appearance numbers are allocated/selected/reserved in two ways: 2663 For incoming calls, the Forking Proxy interacts with the Appearance 2664 Agent. The Appearance Agent selects an appearance by taking a 2665 particular floor and marking it "moderator controlled". This 2666 appearance number is then included by the Forking Proxy in INVITEs 2667 using the Alert-Info parameter. When a UA answers the call, it takes 2668 the appearance number from the Alert-Info and includes it in the 2669 dialog state publication. It then requests the floor associated with 2670 the appearance number from the floor control server, which forwards 2671 the request to the Appearance Agent (moderator). The Appearance 2672 Agent correlates the floor control request with the dialog state 2673 notification with the dialog ID from the INVITE with the Alert-Info. 2674 If they match, the floor is granted. If they do not match, it means 2675 the floor request is not an answer of the call but is a random 2676 appearance selection by the UA and will be rejected. 2678 For outgoing calls, the UA sends an INVITE and requests a particular 2679 floor from the floor control server. Depending on the User Interface 2680 requirements, the floor request can be done before or after sending 2681 the INVITE. The floor grant policy for most appearances is set to 2682 "first come first serve". Once the floor has been granted and the 2683 call answered, the dialog state publication by the UA will include 2684 the appearance number. 2686 When a call has ended, the UA releases the floor to the floor control 2687 server and this appearance is now available for incoming and outgoing 2688 calls. 2690 When a UA in the group which does not support BFCP is in a call, the 2691 Appearance Agent will grant the floor associated with that appearance 2692 to that UA. When that call is over, the Appearance Agent will 2693 release the floor. Since the UA will not publish the appearance 2694 number to the ESC, the Appearance Agent will need to do that on their 2695 behalf. If the UA does publish dialog state but without the 2696 appearance number, the Appearance Agent will still need to re-publish 2697 the dialog state including the appearance number. UAs in the group 2698 will be able to recognize these two dialogs as one since they will 2699 have the same SIP dialog ID. 2701 13.1.3.2. INVITE Appearance Selection Mechanism 2703 This is an alternative approach that utilizes sending an INVITE to 2704 select/reserve/seize an appearance number. 2706 A UA that does not need to select a particular appearance number (or 2707 doesn't care) would just send an INVITE as normal. The Appearance 2708 Agent would tell the proxy which appearance number was being used by 2709 inserting this information in a header field in the first non-100 2710 provisional response sent back to the calling UA. The UA would then 2711 PUBLISH this appearance number to the Dialog Event State Compositor 2712 for the AOR which would distribute details of the dialog and the 2713 appearance number to the other UAs in the group. 2715 If an INVITE is sent and no appearance number is available, the proxy 2716 would reject the INVITE with a suitable response code and perhaps a 2717 header field indication. 2719 A UA that does need to select a particular appearance number would 2720 use an approach similar to overlap dialing (multi-stage dialing). An 2721 INVITE would be sent when the appearance number is requested (i.e. 2722 when the button is pressed, before dialing begins). The appearance 2723 number selected would be carried in the INVITE, in a header field or 2724 in the Request-URI, for example. The proxy would reject the INVITE 2725 with a 484 Address Incomplete response (see RFC 3578) if the 2726 appearance number is Available and start a timer. The UA could then 2727 resend the INVITE after the URI has been dialed and then PUBLISH this 2728 appearance number to the ESC. If the appearance number is not 2729 available, another response code such as 403 would be sent. The user 2730 could then select a different appearance number and resend the 2731 INVITE. If no INVITE with a matching Call-ID is received before the 2732 timer expires, the appearance seizure is cancelled and is made 2733 available for other calls. 2735 Note that this approach does not actually require a B2BUA, but it 2736 does require a proxy that can act as a UAS and communicate with an 2737 Appearance Agent which keeps track of appearance number allocations. 2739 13.1.3.3. PUBLISH Appearance Selection Mechanism 2741 The approach used in previous versions of this draft is to use the 2742 PUBLISH to the event state compositor to select an appearance number. 2743 This approach requires a special event state compositor and special 2744 behavior on the part of the UA. 2746 In the selection of an appearance for requests initiated by UAs in 2747 the group, there is the possibility of contention where more than one 2748 UA select the same appearance number. 2750 One way to solve this and meet REQ-8 is to require UAs to send a 2751 notification (trying) to the Appearance Agent indicating the 2752 appearance number to be used for the session. The Appearance Agent 2753 would confirm the allocation of the appearance number in a NOTIFY 2754 sent to the group UAs. Should the appearance number be unavailable 2755 or otherwise not allowed, there are two options: 2757 - The notification could be rejected with a 500 response and a Retry- 2758 After header field. The Appearance Agent would send an immediate 2759 NOTIFY indicating that the appearance is unavailable. If the NOTIFY 2760 is received before the expiration of the Retry-After time, the 2761 notification state information would become out of date and would be 2762 discarded without resending. The UA would select another appearance 2763 number and send another notification. 2765 - The notification could be accepted but an immediate NOTIFY 2766 generated by the Appearance Agent indicating that the appearance is 2767 unavailable. The UA would then select another appearance number and 2768 PUBLISH again. 2770 UAs would wait for a notification from the Appearance Agent before 2771 sending the INVITE. 2773 13.2. Comparison 2775 In comparing the URI parameter and the dialog package parameter, 2776 there are clear differences in the number of registrations and 2777 subscriptions, with the dialog package approach requiring n times 2778 fewer in both cases. 2780 The security model for the dialog package parameter approach is much 2781 cleaner, since only NOTIFY and PUBLISH requests need integrity and 2782 privacy. The security model for the URI parameter approach would 2783 likely require a B2BUA which introduces many undesirable properties. 2785 The dialog package parameter approach has better backwards 2786 compatibility than the URI parameter approach. 2788 In summary, the dialog package parameter approach better meets REQs 2789 5, 10, 11, 12, and 13 while the URI parameter approach better meets 2790 REQ-9. However, the combined dialog package parameter approach and 2791 the Alert-Info parameter approach meets REQ-9. 2793 13.2.1. Comparison of Appearance Selection Methods 2795 All three approaches meet REQ-15 and REQ-16. 2797 Previous versions of this draft proposed the publish/notify method of 2798 appearance selection. The advantage of this approach is that the 2799 appearance number is only carried in one place (dialog package XML 2800 documents) and the same protocol/mechanism is used to select and 2801 learn appearance numbers. The disadvantage of this approach is that 2802 a specialized event state compositor must be used, since it is aware 2803 of appearance numbers. Also, concerns have been raised about whether 2804 this approach defines new semantics for publish/notify beyond that in 2805 RFC 3265. 2807 The floor control approach makes good reuse of existing protocols 2808 such as Binary Floor Control Protocol (BFCP) and cleanly models the 2809 state. However, while BFCP can be used in conferencing applications, 2810 it is unlikely most UAs implementing shared appearances would utilize 2811 the protocol. Also, having appearance state in two places (dialog 2812 package XML documents and floor control messages) complicates the 2813 application. Also, BFCP only runs over TCP and requires a separate 2814 offer/answer exchange to establish the connection, making operation 2815 through NATs and firewalls more difficult. The BFCP approach is also 2816 radically different from all current implementations of this feature. 2817 As a result, standardizing this approach would likely result in an 2818 increase in feature interoperability rather than a decrease. 2820 The INVITE selection mechanism is based on overlap dialing. Overlap 2821 dialing is supported in very few SIP UAs and is regarded as a 2822 somewhat archaic leftover from the PSTN. As such, it is not regarded 2823 as a good starting point for a common feature such as shared 2824 appearances. 2826 The PUBLISH selection mechanism reuses the SIP events extensions 2827 which already must be implemented by UAs supporting this feature. In 2828 fact, it results in no additional messages or round trips. It is 2829 also very similar to many current feature implementations today. 2830 Standardizing this approach is likely to increase overall 2831 interoperability of this feature. 2833 The rest of this document will only discuss the PUBLISH appearance 2834 selection mechanism. 2836 14. Acknowledgements 2838 The following individuals were part of the shared appearance Design 2839 team and have provided input and text to the document (in 2840 alphabetical order): 2842 Martin Dolly, Andrew Hutton, Raj Jain, Fernando Lombardo, Derek 2843 MacDonald, Bill Mitchell, Michael Procter, Theo Zowzouvillys. 2845 Thanks to Chris Boulton for helping with the XML schema. 2847 Much of the material has been drawn from previous work by Mohsen 2848 Soroushnejad, Venkatesh Venkataramanan, Paul Pepper and Anil Kumar, 2849 who in turn received assistance from: 2851 Kent Fritz, John Weald, and Sunil Veluvali of Sylantro Systems, Steve 2852 Towlson, and Michael Procter of Citel Technologies, Rob Harder and 2853 Hong Chen of Polycom Inc, John Elwell, J D Smith of Siemens 2854 Communications, Dale R. Worley of Pingtel, Graeme Dollar of Yahoo 2855 Inc. 2857 Also thanks to Geoff Devine, Paul Kyzivat, Jerry Yin, John Elwell, 2858 Dan York, Spenser Dawkins, Martin Dolly, and Brett Tate for their 2859 comments. 2861 15. Security Considerations 2863 Since multiple line appearance features are implemented using 2864 semantics provided by [RFC3261], Event Package for Dialog State as 2865 define in , and Event Notification [RFC3265], [RFC3903], security 2866 considerations in these documents apply to this draft as well. 2868 Specifically, since dialog state information and the dialog 2869 identifiers are supplied by UA's in an appearance group to other 2870 members, the same is prone to "call hijacks". For example, a rogue 2871 UA could snoop for these identifiers and send an INVITE with Replaces 2872 header containing these call details to take over the call. As such 2873 INVITES with Replaces header MUST be authenticated using the standard 2874 mechanism (like Digest or S/MIME) described in [RFC3261]. before it 2875 is accepted. NOTIFY or PUBLISH message bodies that provide the 2876 dialog state information and the dialog identifiers MAY be encrypted 2877 end-to-end using the standard mechanics. All SUBSCRIBES between the 2878 UA's and the Appearance Agent MUST be authenticated. 2880 16. Informative References 2882 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2883 Requirement Levels", BCP 14, RFC 2119, March 1997. 2885 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2886 A., Peterson, J., Sparks, R., Handley, M., and E. 2887 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2888 June 2002. 2890 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 2891 Method", RFC 3515, April 2003. 2893 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 2894 Event Notification", RFC 3265, June 2002. 2896 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 2897 for Event State Publication", RFC 3903, October 2004. 2899 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 2900 Protocol (SIP) "Replaces" Header", RFC 3891, 2901 September 2004. 2903 [RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and 2904 K. Summers, "Session Initiation Protocol Service 2905 Examples", BCP 144, RFC 5359, October 2008. 2907 [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- 2908 Initiated Dialog Event Package for the Session Initiation 2909 Protocol (SIP)", RFC 4235, November 2005. 2911 [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol 2912 (SIP) "Join" Header", RFC 3911, October 2004. 2914 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol 2915 (SIP) Call Control - Conferencing for User Agents", 2916 BCP 119, RFC 4579, August 2006. 2918 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 2919 "Indicating User Agent Capabilities in the Session 2920 Initiation Protocol (SIP)", RFC 3840, August 2004. 2922 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2923 January 2004. 2925 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 2926 Package for Registrations", RFC 3680, March 2004. 2928 Authors' Addresses 2930 Alan Johnston (editor) 2931 Avaya 2932 St. Louis, MO 63124 2934 Email: alan@sipstation.com 2936 Mohsen Soroushnejad 2937 Sylantro Systems Corp 2939 Email: mohsen.soroush@sylantro.com 2941 Venkatesh Venkataramanan 2942 Sylantro Systems Corp 2944 Email: vvenkatar@gmail.com