idnits 2.17.1 draft-ietf-bliss-shared-appearances-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2565. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2576. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2583. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2589. 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 : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 416 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 24, 2008) is 5690 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3688' is mentioned on line 2004, but not defined == Unused Reference: 'RFC3325' is defined on line 2510, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3265 (Obsoleted by RFC 6665) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 8 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: March 28, 2009 M. Soroushnejad 5 V. Venkataramanan 6 Sylantro Systems Corp 7 P. Pepper 8 Citel Technologies 9 A. Kumar 10 Yahoo Inc. 11 September 24, 2008 13 Shared Appearances of a Session Initiation Protocol (SIP) Address of 14 Record (AOR) 15 draft-ietf-bliss-shared-appearances-00 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on March 28, 2009. 42 Abstract 44 This document describes the requirements and implementation of a 45 group telephony feature commonly known as Bridged Line Appearance 46 (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line 47 Appearance (SCA). When implemented using the Session Initiation 48 Protocol (SIP), it is referred to as Shared Appearances (SA) of an 49 Address of Record (AOR) since SIP does not have the concept of lines. 50 This feature is commonly offered in the IP Centrex services and IP- 51 PBX offerings and is likely to be implemented on SIP IP telephones 52 and SIP feature servers used in a business environment. This 53 document lists requirements and compares implementation options for 54 this feature. Extensions to the SIP dialog event package are 55 proposed. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Conventions used in this document . . . . . . . . . . . . . . 5 61 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.1. Executive/Assistant Arrangement . . . . . . . . . . . . . 5 63 3.2. BLA Call Group . . . . . . . . . . . . . . . . . . . . . . 5 64 3.3. Single Line Extension . . . . . . . . . . . . . . . . . . 6 65 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5. Normative Description . . . . . . . . . . . . . . . . . . . . 7 67 5.1. Implementation . . . . . . . . . . . . . . . . . . . . . . 7 68 5.2. SA Dialog Package Extensions . . . . . . . . . . . . . . . 10 69 5.2.1. The element . . . . . . . . . . . . . . . 11 70 5.2.2. The element . . . . . . . . . . . . . . . 11 71 5.2.3. The element . . . . . . . . . . . . . 11 72 5.3. Shared Appearance User Agents . . . . . . . . . . . . . . 11 73 5.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . . 13 74 6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 14 75 7. User Interface Considerations . . . . . . . . . . . . . . . . 15 76 7.1. Appearance Number Rendering . . . . . . . . . . . . . . . 15 77 7.1.1. Single Appearance UAs . . . . . . . . . . . . . . . . 16 78 7.1.2. Dual Appearance UAs . . . . . . . . . . . . . . . . . 16 79 7.1.3. Shared Appearance UAs with Fixed Appearance Number . . 16 80 7.1.4. Shared Appearance UAs with Variable Appearance 81 Number . . . . . . . . . . . . . . . . . . . . . . . . 16 82 7.2. Call State Rendering . . . . . . . . . . . . . . . . . . . 17 83 8. Interop with non-SA UAs . . . . . . . . . . . . . . . . . . . 17 84 8.1. Appearance Assignment . . . . . . . . . . . . . . . . . . 18 85 8.2. Appearance Release . . . . . . . . . . . . . . . . . . . . 18 86 8.3. UAs Supporting Dialog Events but Not SA . . . . . . . . . 18 87 9. Provisioning Considerations . . . . . . . . . . . . . . . . . 19 88 10. Example Message Flows . . . . . . . . . . . . . . . . . . . . 19 89 10.1. Registration and Subscription . . . . . . . . . . . . . . 19 90 10.2. Appearance Selection for Outgoing Call . . . . . . . . . . 22 91 10.3. Taking an Appearance . . . . . . . . . . . . . . . . . . . 26 92 10.4. Appearance Selection for Incoming Call . . . . . . . . . . 33 93 10.5. Appearance Publication . . . . . . . . . . . . . . . . . . 37 94 10.6. Joining an Appearance . . . . . . . . . . . . . . . . . . 39 95 10.7. Appearance Allocation - Loss of Subscription with UA . . . 42 96 10.8. Appearance Selection Contention Race Condition . . . . . . 43 97 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 98 11.1. SIP Event Package Parameter: sa . . . . . . . . . . . . . 44 99 11.2. URN Sub-Namespace Registration: sa-dialog-info . . . . . . 44 100 11.3. XML Schema Registration . . . . . . . . . . . . . . . . . 45 101 12. Appendix A - Incoming Appearance Assignment . . . . . . . . . 45 102 13. Appendix B - Implementation Options Discussion . . . . . . . . 46 103 13.1. Appearance Implementation Options . . . . . . . . . . . . 46 104 13.1.1. URI parameter Approach . . . . . . . . . . . . . . . . 46 105 13.1.2. Dialog Package Parameter . . . . . . . . . . . . . . . 47 106 13.1.3. Appearance Selections Mechanisms . . . . . . . . . . . 50 107 13.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 52 108 13.2.1. Comparison of Appearance Selection Methods . . . . . . 53 109 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 54 110 15. Security Considerations . . . . . . . . . . . . . . . . . . . 54 111 16. Informative References . . . . . . . . . . . . . . . . . . . . 55 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 113 Intellectual Property and Copyright Statements . . . . . . . . . . 57 115 1. Introduction 117 The feature and functionality requirements for SIP user agents (UAs) 118 supporting business telephony applications differ greatly from basic 119 SIP user agents, both in terms of services and end user experience. 120 In addition to basic SIP support [RFC3261], many of the services in a 121 business environment require the support for SIP extensions such as 122 REFER [RFC3515], SUBSCRIBE/NOTIFY primitives [RFC3265], PUBLISH 123 [RFC3903], the SIP Replaces [RFC3891], and Join [RFC3911], header 124 fields, etc. Many of the popular business services have been 125 documented in the SIP Service Examples 126 [I-D.ietf-sipping-service-examples]. 128 This specification details a method for implementing a group 129 telephony feature known in telephony as Bridged Line Appearance (BLA) 130 or Multiple Line Appearances (MLA), one of the more popular advanced 131 features expected of SIP IP telephony devices in a business 132 environment. Other names for this feature include Shared Call/Line 133 Appearance (SCA), Shared Call Status and Multiple Call Appearance 134 (MCA). A variant of this feature is known as Single Line Extension. 136 This document looks at how this feature can be implemented using 137 standard SIP [RFC3261] in conjunction with [RFC3265] and [RFC3903] 138 for exchanging status among user agents, and the SIP dialog state 139 event package [RFC4235] to exchange dialog state information to 140 achieve the same. Different approaches will be discussed including 141 the use of URI parameters, feature tags, and dialog package 142 extensions along with the strengths and weaknesses of the various 143 approaches. 145 A call flow for Single Line Extension was formerly included in the 146 SIP Service Examples [I-D.ietf-sipping-service-examples]. However, 147 the attempt to implement using standard SIP primitives ultimately 148 failed, leading to its removal from that document. This document 149 defines SIP extensions to implement this service. 151 In traditional telephony, the line is physical. A common scenario is 152 for a number of business telephones to share a single or a small 153 number of Address of Record (AOR) URIs. The sharing of this AOR 154 between multiple UAs is what gives this feature its name. In 155 addition, an AOR can have multiple appearances on a single UA in 156 terms of the user interface. The appearance number relates to the 157 user interface for the telephone - typically each appearance or an 158 AOR has a visual display (lamp that can change color or blink) and a 159 button (used to select the appearance). The telephony concept of 160 line aappearance is still relevant to SIP due to the user interface 161 considerations. It is important to keep the appearance number 162 construct because: 164 1. Human users are used to the concept and will expect it in 165 replacement systems (e.g. an overhead page announcement says "Joe 166 pickup line 3"). 167 2. It is a useful structure for user interface representation. 169 In this document, we will use the term "appearance" rather than "line 170 appearance" since SIP does not have the concept of lines. Note that 171 this does not mean that a conventional telephony user interface 172 (lamps and buttons) must be used - implementations may use another 173 metaphor as long as the appearance number is readily apparent to the 174 user. Each AOR has a separate appearance numbering space. As a 175 result, a given UA user interface may have multiple occurrences of 176 the same appearance number, but they will be for different AORs. 178 2. Conventions used in this document 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in RFC-2119 [RFC2119] and 183 indicate requirement levels for compliant mechanisms. 185 3. Usage Scenarios 187 The following examples are common applications of the Shared 188 Appearances feature and are mentioned here as informative use cases. 189 All these example usages can be supported by the Shared Appearances 190 feature described in this document. The differences relate to the 191 user interface considerations of the device. 193 3.1. Executive/Assistant Arrangement 195 The appearances on the executive's UA may also appear on the 196 assistant's UA. The assistant may answer incoming calls to the 197 executive and then place the call on hold for the executive to pick 198 up. The assistant can always see the state of all calls on the 199 executive's UA. 201 3.2. BLA Call Group 203 Users with similar business needs or tasks can be assigned to 204 specific groups and share the line appearances of each other on each 205 others SIP telephony devices. For example, an IT department staff of 206 five might answer a help line which has three appearances on each 207 phone in the IT work area. A call answered on one phone can be put 208 on hold and picked up on another phone. A shout or an IM to another 209 staff member can result in them taking over a call on a particular 210 appearance. Another phone can request to be added to an appearance 211 resulting in a conference call. 213 3.3. Single Line Extension 215 In this scenario, incoming calls are offered to a group of UAs. When 216 one answers, the other UAs are informed. If another UA in the group 217 selects the line (i.e. goes off hook), it is immediately bridged or 218 joined in with the call. This mimics the way residential telephone 219 extensions usually operate. 221 4. Requirements 223 The basic requirements of the shared appearance feature can be 224 summarized as follows: 226 REQ-1 Incoming calls to the AOR must be offered to a group of UAs and 227 can be answered by any of them. 229 REQ-2 Each UA in the group must be able to learn the call status of 230 the others in the group for the purpose of rendering this information 231 to the user. 233 REQ-3 Calls can be joined (also called bridged or conferenced 234 together) or can be picked up (taken) by another UA in the group in a 235 secure way. 237 REQ-4 The mechanism should require the minimal amount of 238 configuration. UAs registering against the group AOR should be able 239 to learn about each other and join the appearance group. 241 REQ-5 The mechanism must scale for large numbers of appearances, n, 242 and large numbers of UAs, N, without introducing excessive messaging 243 traffic. 245 REQ-6 Each call or session (incoming or outgoing) must be assigned a 246 common "appearance" number from a managed pool administered for the 247 AOR group. Once the session has terminated, the appearance number is 248 released back into the pool and can be reused by another incoming or 249 outgoing session. 251 REQ-7 Each UA in the group must be able to learn the appearance 252 status of the the group. 254 REQ-8 There must be mechanisms to resolve appearance contention among 255 the UAs in the group. 257 REQ-9 The mechanism must allow all UAs receiving an incoming session 258 request to select the same appearance number at the time of alerting. 260 REQ-10 The mechanism must have a way of reconstructing appearance 261 state after an outage that does not result in excessive traffic and 262 processing. 264 REQ-11 The mechanism must have backwards compatibility such that a UA 265 which is unaware of the feature can still register against the group 266 AOR and make and receive calls. 268 REQ-12 The mechanism must not allow UAs outside the group to select 269 or manipulate appearance numbers. 271 REQ-13 For privacy reasons, there must be a mechanism so that 272 appearance information is not leaked outside the group of UAs. (e.g. 273 "So who do you have on line 1?") 275 REQ-14 The mechanism must support a way for UAs to request 276 exclusivity on a line appearance. Exclusivity means that the UA 277 requesting it desires to have a private conversation with the 278 external party and other UAs must not be allowed to barge-in. 279 Exclusivity may be requested at the start of an incoming or outgoing 280 session or during the session. An exclusivity request may be 281 accepted or rejected by the entity providing the SA service. 282 Therefore, the mechanism must provide a way of communicating the 283 result back to the requester UA. 285 REQ-15 The mechanism should support a way for a UA to select a 286 particular appearance number for outgoing requests prior to sending 287 the actual request. This is often called seizure. 289 REQ-16 The mechanism should support a way for a UA to select a 290 particular appearance number and also send the request at the same 291 time. This is needed when a ringdown feature is combined with shared 292 appearances - in this case, seizing the line is the same thing as 293 dialing. 295 5. Normative Description 297 This section normatively describes the SA feature extensions. 299 5.1. Implementation 301 Many of the requirements for this service can be met using standard 302 SIP mechanisms such as: 304 - A SIP Forking Proxy and Registrar/Location Service meets REQ-1. 306 - The SIP Dialog Package meets REQ-2. 308 - The SIP Replaces and Join header fields meets REQ-3. 310 - The SIP Registration Package meets REQ-4. 312 - The use of a State Agent for the Dialog Package meets REQ-5. 314 REQ-6 suggests the need for an entity which manages the appearance 315 resource. Just as conferencing systems commonly have a single point 316 of control, known as a focus, a Shared Appearance group has a single 317 point of control of the appearance shared resource. This is defined 318 as an Appearance Agent for a group. While an Appearance Agent can be 319 part of a centralized server, it could also be co-resident in a 320 member User Agent who has taken on this functionality for a group. 321 The Appearance Agent learns the group state either by subscribing to 322 the dialog state of each member UA individually or by dialog state 323 publications from members. 325 While the appearance resource could be managed co-operatively by a 326 group of UAs without any central control, this is not discussed in 327 this draft, but instead is left as a research project for future 328 standardization. It is also possible that the Appearance Agent logic 329 could be distributed in all UAs in the group. For example, rules 330 that govern assigning appearance numbers for incoming requests (e.g. 331 lowest available appearance number) and rules for contention handling 332 (e.g. when two UAs request the use of the same appearance number, 333 hash dialog identifiers and compare with the lowest hash winning) 334 would need to be defined and implemented. 336 REQs 6-13 can be implemented using a number of approaches, as 337 discussed in the following sections. 339 Figure 1 illustrates the SIP components involved in supporting these 340 common requirements of the Shared Appearance using standard SIP 341 messages including REGISTER, INVITE, SUBSCRIBE, NOTIFY, and PUBLISH. 343 +----------------------------+ +----+ 344 | | | | 345 | Appearance Agent | | UA | 346 | | | | 347 +----------------------------+ +----+ 348 ^ ^ |1)SUBSCRIBE ^ ^ 4)NOTIFY INVITE | 349 | | |(Event:reg) | | registration sip:alice@example.com| 350 | | V | | events V 351 | | +--------------------+ +----------+7)Query+--------+ 352 | | | (example.com) | | |<===== | | 353 | | | |3) Store| Location | | Proxy | 354 | | | Registrar |=======>| Service | | | 355 | | | | | |=====> | | 356 | | +--------------------+ +----------+8)Resp +--------+ 357 | | ^ ^ | | 358 | | | | 2) REGISTER (alice) | | 359 | | | | | | 360 | | +----+ +----+ | | 361 | | | | | | | | 362 | | |UA1 | |UA2 | | | 363 | | | | | | | | 364 | | +----+ +----+ | | 365 | | ^ ^ ^ ^ | | 366 | | | | | | | | 367 | +----+ | | | | | 368 | | | +--------------------------------------+ | 369 | +----+-------------------------------------------+ 370 | | 8) INVITE 371 +--------------+ sip:alice@example.com 372 5-7) SUBSCRIBE and/or PUBLISH 373 (Event:dialog) 375 Figure 1. 377 The next section discusses normal SIP operations used to implement 378 parts of the shared appearance feature. 380 1. The Appearance Agent SUBSCRIBES to the registration event package 381 as outlined in [RFC3680] for contacts registered to the group 382 AOR. Thus, it has knowledge of all User Agents registered 383 against the AOR at any point of time. 384 2. UAs (UA1 and UA2 in Figure 1) belong to the appearance group and, 385 after authentication, register against the same AOR (e.g., 386 sip:alice@example.com). 387 3. Each registration is stored in the Location Service. 388 4. The registrar notifies the Appearance Agent of successful 389 registration at each UA. 391 5. UAs PUBLISH their dialog state to the State Agent in the 392 Appearance Agent. 393 6. The UAs SUBSCRIBE to the Appearance Agent for the state of all 394 dialogs as defined in [RFC3265] . The Request-URI of the 395 SUBSCRIBE could be either the AOR of the group, the Contact URI 396 information it received in the incoming subscription from the 397 Appearance Agent, or a provisioned URI. 398 7. The UAs PUBLISH their dialog information to the Appearance Agent 399 every time their dialog state changes (i.e. receive an INVITE, 400 enter alerting state, answer a call, terminate a call, generate 401 an INVITE, etc.) 402 8. Forking Proxy forks an incoming INVITE for the AOR address to the 403 registered user agents. 405 The User Agents in the group could SUBSCRIBE to each other and NOTIFY 406 dialog state events, but in a large group the User Agents have to 407 manage a larger number of SUBSCRIPTIONS and NOTIFICATIONS. The State 408 Agent in the Appearance Agent helps in managing large groups better. 409 Further, the State Agent can filter dialog state events and NOTIFY 410 User Agents of the dialog state events which are required for the 411 application or feature. The State Agent can also SUBSCRIBE to dialog 412 state events with filters to reduce the number of NOTIFY messages 413 exchanged between the State Agent and the user agents in the group. 414 This allows a group of N UAs to each only establish a pair of dialog 415 state subscriptions (one in each direction) to learn the dialog state 416 of all other group members. This results in 2N total subscriptions 417 for the entire group. A full mesh of subscriptions without a state 418 agent would result in N(N-1) total subscriptions. 420 The Appearance Agent can select the appearance number for an incoming 421 call 423 OPEN ISSUE: Do we want to define another mode of operation in which 424 UAs only PUBLISH to seize a line appearance? This assumes the 425 Appearance Agent already knows about all dialogs related to the AOR 426 and could publish that information to the UAs in the SA group. This 427 approach would simply UA operation and cleanly resolve some race 428 conditions. Should we define this mode in a separate draft? 430 5.2. SA Dialog Package Extensions 432 This specification defines three new elements as extensions to the 433 SIP Dialog Event package [RFC3265] . The schema is defined in 434 Section 7. The elements are , ;, and . All three elements are sub-elements of the 436 element. 438 5.2.1. The element 440 The element is used convey the appearance number. The 441 appearance number is a non-negative integer. When sent in a 442 notification in state Trying to the Appearance Agent, it is used to 443 request an appearance number. When sent by the Appearance Agent, it 444 indicates that the appearance number is associated with a dialog. 446 5.2.2. The element 448 The element is a boolean used indicate whether the UA 449 will accept Join or Replaces INVITEs for this dialog. For example, 450 some SA systems only allow call pickup when the call is on hold. In 451 this case, the element should be used to explicitly 452 indicate this, rather than implicitly by the hold state. 454 It is important to note that this element is a hint. Although a UA 455 may set exclusive to true, the UA must still be ready to reject an 456 INVITE Join relating to this dialog. Also, an INVITE Replaces might 457 be sent to the non-SA UA to take the call. For this reason, a UA MAY 458 also not report full dialog identifier information to the Appearance 459 Agent for calls set to exclusive. If these dialog identifiers have 460 already been shared with the Appearance Agent, the UA could send an 461 INVITE Replaces to change them and then not report the new ones to 462 the Appearance Agent. 464 If the proxy knows which dialogs are marked exclusive, the proxy MAY 465 enforce this exclusivity by rejecting INVITE Join and INVITE Replace 466 requests containing those dialog identifiers with a 403 Forbidden 467 response. 469 5.2.3. The element 471 The element is used convey dialog identifiers of any 472 other dialogs which are joined (mixed or bridged) with the dialog. 473 Only the UA which is performing the actual media mixing should 474 include this element in notifications to the Appearance Agent. Note 475 that this element should still be used even when the Join header 476 field was not used to join the dialogs. For example, two separate 477 dialogs on a UA could be joined without any SIP call control 478 operations. The UA would report this using this header field. 480 5.3. Shared Appearance User Agents 482 User Agents that support the Shared Appearance feature MUST support 483 the dialog state package [RFC4235] with the SA extensions and the 484 "sa" dialog event package parameter defined in this draft. 486 User Agents MUST use the extended package in conjunction with PUBLISH 487 [RFC3903] to send local status to the Appearance Agent, and in 488 conjunction with SUBSCRIBE and NOTIFY [RFC3265] to learn the status 489 or other User Agents. The publication URI is either a provisioned 490 value or the username 'appearance-agent'. For example, a UA in the 491 domain of example.com would publish dialog state to 492 sip:appearance-agent@example.com 494 OPEN ISSUE: Do we need to specify a publish URI or should it be only 495 by provisioning? Should a UA be able to publish to its own URI for 496 this? 498 User Agents SHOULD support sending and receiving an INVITE with a 499 Replaces [RFC3891] header to allow the Call Pickup operation. User 500 Agents MUST support sending an INVITE a Join [RFC3911] header to 501 initiate bridging. User Agents MUST support receiving an INVITE with 502 a Join header, though they are not obligated to support bridging of 503 calls, either through policy, preference, or implementation 504 limitations such as bandwidth or hardware constraints. 506 When publishing dialog package information, a UA MUST include all 507 dialog identification available at the time of publication, with the 508 exception that a UA may omit information if it wishes to prevent 509 other UAs from joining or picking up a call. Dialog identification 510 includes local and remote target URIs, call-id, to-tag, and from-tag. 511 When calls are placed on hold, the "+sip.rendering=no" feature tag 512 MUST be included in dialog package notifications. 514 There are two exceptions to the requirement for seizing an appearance 515 before sending an INVITE. One is an emergency call, which should 516 proceed regardless of the status of PUBLISH transaction. This 517 requirement applies to both clients and servers implementing this 518 feature. The other is when the INVITE is an attempt to bridge or 519 take a call (i.e. contains Join or Replaces with a dialog identifier 520 of another member of the SA group). In this case, the INVITE Join or 521 Replaces should be sent without selecting an appearance. After the 522 INVITE succeeds, the PUBLISH MUST be sent, reusing the appearance 523 number of the dialog that has been bridged or taken. 525 UAs can tell that a set of dialogs are joined (bridged or mixed) 526 together by the presence of one or more elements 527 containing other SIP dialog identifiers. 529 Prior to placing an outbound call, UAs may select or "seize" an 530 appearance number by sending a PUBLISH to the Appearance Agent with 531 an identifying the appearance number selected. In 532 traditional telephony terms, this corresponds to "going off hook" 533 with an analog telephone. Note that when a UA selects an appearance 534 prior to establishment of a dialog, not all dialog information will 535 be available. In particular, when a UA publishes an attempt to 536 select an appearance prior to knowing the destination very minimal 537 dialog information may be available. 539 A UA that does not need to select a particular appearance number (or 540 doesn't care) would just send an INVITE as normal to place an 541 outbound call. The Appearance Agent would select an available 542 appearance and notify all subscribed UAs of the selection. The UA 543 placing the call then publishes the use of this appearance number. 545 If an INVITE is sent and no appearance number is available, the proxy 546 would reject the INVITE with a suitable response code and perhaps a 547 header field indication. 549 For inbound calls which contain a reference to an appearance number 550 in the INVITE, a UA MUST PUBLISH the use of an appearance number 551 after it responds with a 2xx to establish a dialog. A UA SHOULD NOT 552 PUBLISH the use of an appearance number for incoming requests which 553 are in the early state or which are rejected with 4xx, 5xx or 6xx 554 responses, as this would create excessive traffic when a large number 555 of UAs are sharing an appearance. 557 The dialog state package defined in [RFC4235] defines the set of 558 messages that MAY be provided by a UA to publish state information of 559 dialogs. 561 A UA should only register against the AOR if it is likely the UA will 562 be answering incoming calls. If the UA is mainly going to be 563 monitoring the status of the SA group calls and picking or joining 564 calls, the UA SHOULD only subscribe to the Appearance Agent and not 565 register against the AOR. 567 5.4. Appearance Agent 569 An Appearance Agent defined in this specification MUST implement a 570 dialog package state agent for the UAs registered against the AOR. 572 The dialog package XML element dialog id (NOT the SIP dialog 573 identifier consisting of the Call-ID, To tag, and From tag) is used 574 for partial update processing. RFC 4235 only requires the dialog id 575 be unique for the UA, not unique across all UAs associated with the 576 same AOR. As a result, is possible that two UAs in a SA group might 577 choose the same XML element dialog id for different dialogs. If this 578 is the case, the Appearance Agent, acting as the dialog package event 579 state compositor may need to produce different notification documents 580 for the UAs that have conflicting dialog package XML element dialog 581 ids. 583 The Appearance Agent MUST support the appearance dialog package 584 extensions defined in this specification. 586 Even in trivial deployments of two shared appearance enabled user 587 agents, race conditions can exist when both user agents attempt to 588 utilize an appearance simultaneously (i.e. when the NOTIFY messages, 589 that each user agent sends to the other, are active within the 590 network during an overlapping time period). The Appearance Agent can 591 use any policy deemed necessary to resolve races and ensure no two 592 user agents are not allocated the same appearance number at the same 593 time. 595 Appearance Agents are responsible for resolving conflicts in the 596 appearance resource. If a UA requests the use of an appearance 597 number that is in use by another UA, the Appearance Agent will 598 respond based on the presence of the selection attribute in the 599 element as described in the previous section. 601 In the case where a UA is bridging two calls, the Appearance Agent 602 may receive dialog package PUBLISHes that contain multiple dialogs 603 with the same appearance number. This is valid and does not 604 represent appearance number contention. 606 A critical aspect for reliable operation of this feature is the 607 ability for all user agents in the BLA group to recover from network 608 failures caused at a single UA. For example, one of the user agents 609 in the BLA group may have answered an incoming call, notified the 610 dialog state to other members and then experienced a network outage. 611 The calling UA could have detected the same (using RTP or some other 612 means) and could have hung up. However, none of the other user 613 agents in the BLA group would get notification of this change in 614 dialog state and their BLA appearances could stay out of sync for a 615 long time; depending on when the network is restored, or when the 616 Appearance Agent attempts to refresh its dialog-state subscription 617 with the failed UA. To recover from such a failure, UAs MUST PUBLISH 618 with a shorter expiration (expiration interval not smaller than 300 619 seconds is RECOMMENDED) following the notification of a "confirmed" 620 dialog or when a Appearance Agent honors a "trying" for call 621 origination, with the user agents that notified it of this 622 information. 624 6. XML Schema Definition 626 The 'appearance' and 'exclusive' elements are defined within a new 627 XML namespace URI. This namespace is 628 "urn:ietf:params:xml:ns:sa-dialog-info". The schema for these 629 elements is: 631 632 638 639 640 642 644 646 647 649 650 651 652 654 655 656 657 658 660 7. User Interface Considerations 662 The "appearance number" allocated to a call is an important concept 663 that enables calls to be handled by multiple devices with 664 heterogeneous user interfaces in a manner that still allows users to 665 see a consistent model. Careful treatment of the appearance number 666 is essential to meet the expectations of the users. Also, rendering 667 the correct call/appearance state to users is also important. 669 7.1. Appearance Number Rendering 671 Since different UAs have different user interface capabilities, it is 672 usual to find that some UAs have restrictions that others do not. 673 Perfect interoperability across all UAs is clearly not possible, but 674 by careful design, interoperability up to the limits of each UA can 675 be achieved. 677 The following guidelines suggest how the appearance number should be 678 handled in three typical user interface implementations. 680 7.1.1. Single Appearance UAs 682 These devices are constrained by only having the capability of 683 displaying status indications for a single appearance. Despite this, 684 it is important that devices of this type do not ignore the 685 appearance number. The UA should still send messages annotated with 686 an appropriate appearance number (i.e. "0"). Any call indications 687 for appearances other than for number "0" should be rejected with a 688 486 or 480 response. 690 7.1.2. Dual Appearance UAs 692 These devices are essentially single appearance phones that implement 693 call waiting. They have a very simple user interface that allows 694 them to switch between two appearances (toggle or flash hook) and 695 perhaps audible tones to indicate the status of the other appearance. 697 7.1.3. Shared Appearance UAs with Fixed Appearance Number 699 This UA is the typical 'business-class' hard-phone. A number of 700 appearances are typically configured statically and labeled on 701 buttons, and calls may be managed using these configured appearances. 702 Any calls outside this range should be ignored, and not mapped to a 703 free button. Users of these devices often select specific appearance 704 numbers for outgoing calls, and the UA will need to select the 705 appearance number and wait for confirmation from the Appearance Agent 706 before proceeding with calls. 708 7.1.4. Shared Appearance UAs with Variable Appearance Number 710 This UA is typically a soft-phone or graphically rich user interface 711 hard-phone. In these cases, even the idea of an appearance index may 712 seem unnecessary. However, for these phones to be able to interwork 713 successfully with other phone types, it is important that they still 714 use the appearance index to govern the order of appearance of calls 715 in progress. No specific guidance on presentation is given except 716 that the order should be consistent. Thought should also be given to 717 how an appearance number that has no call associated with it should 718 be rendered to the user. These devices can typically make calls 719 without waiting for confirmation from the Appearance Agent on the 720 appearance number. 722 The problems faced by each style of user interface are readily seen 723 in this example: 725 1. A call arrives at the SA group, and is assigned an appearance 726 number of 0. All UAs should be able to render to the user the 727 arrival of this call. 728 2. Another call arrives at the SA group, and is assigned an 729 appearance number of 1. The single appearance UA should not 730 present this call to the user. Other user agents should have no 731 problems presenting this call distinctly from the first call. 732 3. The first call clears, releasing appearance number "0". The 733 single appearance UA should now be indicating no calls since it 734 is unable to manage calls other than on the first appearance. 735 Both shared appearance UAs should clearly show that appearance 736 number 0 is now free, but that there is still a call on 737 appearance number 1. 738 4. A third call arrives, and is assigned the appearance number of 0. 739 All UAs should be able to render the arrival of this new call to 740 the user. Multiple appearnce UAs should continue to indicate the 741 presence of the second call, and should also ensure that the 742 presentation order is related to the appearance number and not 743 the order of call arrival. 745 7.2. Call State Rendering 747 UAs that implement the SA feature typically have a user interface 748 that provides the state of other appearances in the group. As dialog 749 state NOTIFYs from the Appearance Agent are processed, this 750 information can be rendered. Even the simplest user interface 751 typically has three states: idle, active, and hold. The idle state, 752 usually indicated by lamp off, is indicated for an appearance when 753 the appearance number is not associated with any dialogs, as reported 754 by the Appearance Agent. The active state, usually indicated by a 755 lamp on, is indicated by an appearance number being associated with 756 at least one dialog, as reported by the Appearance Agent. The hold 757 state, often indicated by a blinking lamp, means the call state from 758 the perspective of the UA in the SA group is hold. This can be 759 determined by the presence of the "sip+rendering=no" feature tag 760 [RFC3840] with the local target URI. Note that the hold state of the 761 remote target URI is not relevant to this display. For joined 762 dialogs, the state is rendered as hold only if all local target URIs 763 are indicated with the "sip+rendering=no" feature tag. 765 8. Interop with non-SA UAs 767 It is desirable to allow a basic UA that does not directly support SA 768 to be part of a SA group. To support this the Proxy must collaborate 769 with the Appearance Agent. This is not required in the basic SA 770 architecture, consequently SA interop with non-SA UAs will not be 771 available in all SA deployments. 773 First, a UA which does not support dialog events or the SA feature 774 will be discussed. Then, a UA which does support dialog events but 775 not the SA feature will be discussed. 777 8.1. Appearance Assignment 779 A UA that has no knowledge of appearances must have appearance 780 numbers assigned by the Appearance Agent for both incoming and 781 outgoing calls. If the non-SA UA does not support Join or Replaces, 782 all dialogs could be marked "exclusive" to indicate that these 783 options are not available. 785 OPEN ISSUE: How can an Appearance Agent know that a given UA does not 786 support the feature? Do we need a SIP option tag for this purpose? 787 Do we need to be able to correlate a registration with a 788 subscription? 790 8.2. Appearance Release 792 In all cases the Appearance Agent must be aware of dialog lifetime to 793 release appearances back into the group. 795 It is also desirable that any dialog state changes (such as hold, 796 etc) be made available to other UAs in the group through the Dialog 797 Event Package. If the Appearance Agent includes a proxy which 798 Record-Routes for dialogs from the non-SA aware UA, the Appearance 799 Agent will know about the state of dialogs including hold, etc. This 800 information could be determined from inspection of INVITE and re- 801 INVITE messages and added to the dialog information conveyed to other 802 UAs. 804 8.3. UAs Supporting Dialog Events but Not SA 806 Interoperability with UAs which support dialog events but not the SA 807 feature is more straightforward. As before, all appearance number 808 assignment must be done by the Appearance Agent. This type of UA 809 will be detected by the Appearance Agent by the absence of the ma 810 event parameter in SUBSCRIBE or PUBLISH messages. The Appearance 811 Agent can include appearance information in NOTIFYs - this UA will 812 simply ignore this extra information. This type of UA will ignore 813 appearance number limitations and may attempt to Join or Replace 814 dialogs marked exclusive. As a result, the Proxy or UAs may need to 815 reject such requests. 817 The need for close cooperation between the Proxy and the Appearance 818 Agent is not needed as the Appearance Agent will learn about all 819 dialogs from the UA itself. 821 9. Provisioning Considerations 823 TBD. 825 10. Example Message Flows 827 The next section shows call flow and message examples. The flows and 828 descriptions are non-normative. 830 EDITOR'S NOTE: These flows need to be gone over closely to make sure 831 they reflect the latest protocol design. 833 10.1. Registration and Subscription 835 Bob and Alice are in an appearance group identified by Alice's AOR. 836 Bob REGISTERs using contact sip:bob@ua2.example.com. Furthermore, 837 Bob REGISTERs his primary address with contact sip: 838 bob@ua2.example.com. Alice REGISTERs with contact 839 sip:alice@ua1.example.com. 841 The Appearance Agent subscribes to dialog states of the SA AOR (i.e., 842 sip:alice@example.com) at the User Agents for Alice and Bob. Message 843 exchange between the Registrar, Appearance Agent, Alice, and Bob are 844 shown below. The call flow examples below do not show challenging of 845 subscriptions or notifications. It should be noted that for security 846 purposes, all subscriptions must be authorized before the same is 847 accepted. 849 Registrar Appearance Agent Alice 850 | | | 851 | | | 852 |<--------------------------- REGISTER F1<| 853 | | | 854 |>F2 200 OK ----------------------------->| 855 | | | 856 | |<----- SUBSCRIBE F3<| 857 | | | 858 | |>F4 202 Accepted -->| 859 | | | 860 | |>F5 NOTIFY -------->| 861 | | | 862 | |<-------- OK 200 F6<| 863 | | | 865 Figure 2. 867 F1-F2: Alice registers AOR with contact: 869 F1 Alice ----> Registrar 871 REGISTER sip:registrar.example.com SIP/2.0 872 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09 873 From: ;tag=CDF9A668-909E2BDD 874 To: 875 CSeq: 2 REGISTER 876 Call-ID: d3281184-518783de-cc23d6bb@ua1.example.com 877 Contact: 878 User-Agent: ABC-UA/1.2.3 879 Max-Forwards: 70 880 Expires: 3600 881 Content-Length: 0 883 F2 Registrar ----> Alice 885 SIP/2.0 200 OK 886 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKfbf176ef7F1D5FA2 887 CSeq: 2 REGISTER 888 Call-ID: d3281184-518783de-cc23d6bb@ua1.example.com 889 From: ;tag=CDF9A668-909E2BDD 890 To: ;tag=1664573879820199 891 Contact: 892 Expires: 3600 893 Content-Length: 0 895 F3 to F6: Alice also subscribes to the events associated with the 896 Appearance AOR. Appearance Agent also notifies Alice of the status. 898 F3 Alice ----> Appearance Agent 900 SUBSCRIBE sip:sa@stateagent.example.com SIP/2.0 901 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A 902 From: ;tag=925A3CAD-CEBB276E 903 To: 904 CSeq: 1 SUBSCRIBE 905 Call-ID: ef4704d9-bb68aa0b-474c9d94@ua1.example.com 906 Contact: 907 Event: dialog 908 User-Agent: ABC-UA/1.2.3 909 Accept: application/dialog-info+xml 910 Max-Forwards: 70 911 Expires: 3700 912 Content-Length: 0 914 F4 Appearance Agent ----> Alice 916 SIP/2.0 202 Accepted 917 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A 918 CSeq: 1 SUBSCRIBE 919 Call-ID: ef4704d9-bb68aa0b-474c9d94@ua1.example.com 920 From: ;tag=925A3CAD-CEBB276E 921 To: ;tag=1636248422222257 922 Allow-Events: dialog 923 Expires: 3700 924 Contact: 925 Content-Length: 0 927 F5 Appearance Agent ----> Alice 929 NOTIFY sip:alice@ua1.example.com SIP/2.0 930 From: ;tag=1636248422222257 931 To: ;tag=925A3CAD-CEBB276E 932 Call-ID: ef4704d9-bb68aa0b-474c9d94@ua1.example.com 933 CSeq: 2 NOTIFY 934 Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1846984327225734 935 Max-Forwards: 70 936 Content-Type: application/dialog-info+xml 937 Event: dialog 938 Subscription-State: active 939 Contact: 940 Content-Length: ... 942 943 947 949 F6 Alice ----> Appearance Agent 951 SIP/2.0 200 OK 952 Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1846984327225734 953 From: ;tag=1636248422222257 954 To: ;tag=925A3CAD-CEBB276E 955 CSeq: 2 NOTIFY 956 Call-ID: ef4704d9-bb68aa0b-474c9d94@ua1.example.com 957 Contact: 958 Event: dialog 959 User-Agent: ABC-UA/1.2.3 960 Content-Length: 0 962 10.2. Appearance Selection for Outgoing Call 964 In this scenario, Bob's UA sends out a dialog event NOTIFY with state 965 (trying) selecting an appearance number. After receiving the NOTIFY 966 from the Appearance Agent confirming the appearance number, Bob's UA 967 sends the INVITE to Carol and establishes a session. For brevity, 968 details of some of the messages are not included in the message 969 flows. 971 Carol Proxy Alice Appearance Agent Bob 972 | | | | | 973 | | | |<----- PUBLISH F1<| 974 | | | | | 975 | | | |>F2 200 OK ------>| 976 | | | | | 977 | | |<-- NOTIFY F3<| | 978 | | | | | 979 | | |>F4 200 OK -->| | 980 | | | |------- NOTIFY F5>| 981 | | | | | 982 | | | |F13 180 --->| | | | 990 | |>F14 180 Ringing ------------------------------->| 991 |>F15 200 OK ->| | | | 992 | |>F16 200 OK ------------------------------------>| 993 | | | | | 994 |<------------------------------------------------------ ACK F17<| 995 | | | | | 996 |<================= Both way RTP established ===================>| 997 | | | | | 998 | | | |<---- PUBLISH F18<| 999 | | | | | 1000 | | | |>F19 200 OK ----->| 1001 | | |<- NOTIFY F20<| | 1002 | | | | | 1003 | | |>F21 200 OK ->| | 1004 | | | |------ NOTIFY F22>| 1005 | | | | | 1006 | | | | 1013
Appearance Agent 1017 PUBLISH sip:appearance-agent@example.com SIP/2.0 1018 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 1019 From: ;tag=44150CC6-A7B7919D 1020 To: ;tag=428765950880801 1021 CSeq: 7 PUBLISH 1022 Call-ID: 144-1289338424@example.com 1023 Contact: 1024 Event: dialog 1025 User-Agent: XYZ-UA/4.5.6 1026 Max-Forwards: 70 1027 Content-Type: application/dialog-info+xml 1028 Content-Length: ... 1030 1031 1036 1037 0 1038 false 1039 trying 1040 1041 1042 1043 1044 1045 1047 F2 Appearance Agent ----> Bob 1048 SIP/2.0 200 OK 1049 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 1050 CSeq: 7 PUBLISH 1051 Call-ID: 144-1289338424@example.com 1052 From: ;tag=44150CC6-A7B7919D 1053 To: ;tag=428765950880801 1054 Allow-Events: dialog 1055 Contact: 1056 Content-Length: 0 1058 F3 Appearance Agent ----> Alice 1060 NOTIFY sip:alice@ua1.example.com SIP/2.0 1061 From: ;tag=497585728578386 1062 To: ;tag=633618CF-B9C2EDA4 1063 Call-ID: a7d559db-d6d7dcad-311c9e3a@ua1.example.com 1064 CSeq: 7 NOTIFY 1065 Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1711759878512309 1066 Max-Forwards: 70 1067 Content-Type: application/dialog-info+xml 1068 Event: dialog 1069 Subscription-State: active 1070 Contact: 1071 Content-Length: ... 1073 1074 1079 1080 0 1081 false 1082 trying 1083 1084 1085 1086 1087 1088 1090 F4 Alice ----> Appearance Agent 1092 SIP/2.0 200 OK 1093 Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1711759878512309 1094 From: ;tag=497585728578386 1095 To: ;tag=633618CF-B9C2EDA4 1096 CSeq: 7 NOTIFY 1097 Call-ID: a7d559db-d6d7dcad-311c9e3a@ua1.example.com 1098 Contact: 1099 Event: dialog 1100 User-Agent: ABC-UA/1.2.3 1101 Content-Length: 0 1103 F5 and F6: The Appearance Agent sends a NOTIFY to Bob confirming appearance number. 1105 F11 to F17: Bob places a call to Carol by sending the INVITE request 1106 towards the Proxy. The INVITE (see F5 message below) includes a 1107 P-Preferred-Identity header to designate the identity to be 1108 used as the calling party for this call (i.e., Alice instead of Bob). 1110 F11 Bob ----> Proxy 1112 INVITE sip:carol@example.com SIP/2.0 1113 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK98c87c52123A08BF 1114 From: ;tag=15A3DE7C-9283203B 1115 To: 1116 CSeq: 1 INVITE 1117 Call-ID: f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com 1118 Contact: 1119 User-Agent: XYZ-UA/4.5.6 1120 P-Preferred-Identity: 1121 Max-Forwards: 70 1122 Content-Type: application/sdp 1123 Content-Length: 223 1125 v=0 1126 o=- 1102980499 1102980499 IN IP4 ua2.example.com 1127 s=IP SIP UA 1128 c=IN IP4 ua2.example.com 1129 t=0 0 1130 a=sendrecv 1131 m=audio 2236 RTP/AVP 0 8 101 1132 a=rtpmap:0 PCMU/8000 1133 a=rtpmap:8 PCMA/8000 1134 a=rtpmap:101 telephone-event/8000 1136 F18 to F21: Bob notifies the Appearance Agent of the status of the 1137 dialog (i.e., confirmed). Appearance Agent notifies Alice of the 1138 same. 1140 F18 Bob ----> Appearance Agent 1142 NOTIFY sip:sa@stateagent.example.com SIP/2.0 1143 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa39d3f69D4E20602 1144 From: ;tag=44150CC6-A7B7919D 1145 To: ;tag=428765950880801 1146 CSeq: 9 NOTIFY 1147 Call-ID: 144-1289338424@example.com 1148 Contact: 1149 Event: dialog 1150 User-Agent: XYZ-UA/4.5.6 1151 Subscription-State: active;expires=3342 1152 Max-Forwards: 70 1153 Content-Type: application/dialog-info+xml 1154 Content-Length: ... 1156 1157 1162 1167 confirmed 1168 0 1169 false 1170 1171 1172 1173 1174 1175 1176 sip:carol@example.com 1177 1178 1179 1180 1182 10.3. Taking an Appearance 1184 In this scenario, Bob has an established dialog with Carol. Bob then 1185 places Carol on hold. Alice subsequently picks up the held call and 1186 has a established session with Carol. Finally, Carol hangs up. The 1187 details of the notifications amongst the user agents and the 1188 Appearance Agent in updating the status of the BLA group members are 1189 shown below. For brevity, details of some of the messages are not 1190 included in the message flows. 1192 Carol Proxy Alice Appearance Agent Bob 1193 | | | | | 1194 | | | | | 1195 |<================= Both way RTP established ===================>| 1196 | | | | | 1197 | | | | | 1198 | |<------------------------------(hold) INVITE F16<| 1199 |<- INVITE F17<| | | | 1200 | | | | | 1201 |>F18 200 OK ->| | | | 1202 | |>F19 200 OK ------------------------------------>| 1203 | | | | | 1204 |<------------------------------------------------------ ACK F20<| 1205 | | | | | 1206 | | | |<----- NOTIFY F21<| 1207 | | | | | 1208 | | | |>F22 200 OK ----->| 1209 | | |<- NOTIFY F23<| | 1210 | | | | | 1211 | | |>F24 200 OK ->| | 1212 | |<-- INVITE F25<| | | 1213 |<- INVITE F26<|(w/ Replaces) | | | 1214 |( w/ Replaces)| | | | 1215 |>F27 200 OK ->| | | | 1216 | |>F28 200 OK -->| | | 1217 | | | | | 1218 |<-------------------- ACK F29<| | | 1219 | | | | | 1220 |<= Both way RTP established =>| | | 1221 | | | | | 1222 |>F30 BYE ---->| | | | 1223 | |>F31 BYE --------------------------------------->| 1224 | | | | | 1225 | |<------------------------------------ OK 200 F32<| 1226 |<- 200 OK F33<| | | | 1227 | | | | | 1228 | | | |<----- NOTIFY F34<| 1229 | | | | | 1230 | | | |>F35 200 OK ----->| 1231 | | |<- NOTIFY F36<| | 1232 | | | | | 1233 | | |>F37 200 OK ->| | 1234 | | | | | 1235 | | |>F38 NOTIFY ->| | 1236 | | | | | 1237 | | |<- 200 OK F39<| | 1238 | | | |>F40 NOTIFY ----->| 1239 | | | | | 1240 | | | |<----- 200 OK F41<| 1241 |>F42 BYE ---->| | | | 1242 | |>F43 BYE ----->| | | 1243 | | | | | 1244 | |<-- 200 OK F44<| | | 1245 |<--200 OK F45<| | | | 1246 | | |>F46 NOTIFY ->| | 1247 | | | | | 1248 | | |<- 200 OK F47<| | 1249 | | | |>F48 NOTIFY ----->| 1250 | | | | | 1251 | | | |<----- OK 200 F49<| 1253 Figure 4. 1255 F16 to F20: Bob places Carol on hold. 1257 F22 to F24: Bob notifies Appearance Agent of the status of the dialog to 1258 indicate the held state. It indicates this by setting the sip.rendering 1259 parameter in the NOTIFY payload to (no). Appearance Agent notifies 1260 Alice of the same. 1262 F22 Bob ----> Appearance Agent 1264 NOTIFY sip:sa@stateagent.example.com SIP/2.0 1265 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK6c78a6c5CA00520E 1266 From: ;tag=44150CC6-A7B7919D 1267 To: ;tag=428765950880801 1268 CSeq: 10 NOTIFY 1269 Call-ID: 144-1289338424@example.com 1270 Contact: 1271 Event: dialog 1272 User-Agent: XYZ-UA/4.5.6 1273 Subscription-State: active;expires=3338 1274 Max-Forwards: 70 1275 Content-Type: application/dialog-info+xml 1276 Content-Length: ... 1278 1279 1284 1289 confirmed 1290 0 1291 false 1292 1293 1294 1295 1296 1297 1298 sip:carol@example.com 1299 1300 1301 1302 1304 F26 to F34 : Alice picks up the held call by sending an INVITE with 1305 Replaces: header (F26). Session is established between Alice and 1306 Carol. The dialog between Carol and Bob is terminated. 1308 F26 Alice ----> Proxy 1310 INVITE sip:carol@example.com SIP/2.0 1311 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK4ea695b5B376A60C 1312 From: ;tag=8C4183CB-BCEAB710 1313 To: 1314 CSeq: 1 INVITE 1315 Call-ID: 3d57cd17-47deb849-dca8b6c6@ua1.example.com 1316 Contact: 1317 User-Agent: ABC-UA/1.2.3 1318 P-Preferred-Identity: 1319 1320 Replaces: f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com;to-tag=65a98f7c 1321 -1dd2-11b2-88c6-b03162323164+65a98f7c;from-tag=15A3DE7C-9283203B 1322 1323 Max-Forwards: 70 1324 Content-Type: application/sdp 1325 Content-Length: 223 1327 v=0 1328 o=- 1102980497 1102980497 IN IP4 ua1.example.com 1329 s=IP SIP UA 1330 c=IN IP4 ua1.example.com 1331 t=0 0 1332 a=sendrecv 1333 m=audio 2238 RTP/AVP 0 8 101 1334 a=rtpmap:0 PCMU/8000 1335 a=rtpmap:8 PCMA/8000 1336 a=rtpmap:101 telephone-event/8000 1338 F34 to F41: Bob notifies the Appearance Agent of the termination of 1339 dialog at his UA. Alice notifies the Appearance Agent of the 1340 confirmed state of the dialog at her UA. 1342 F34 Bob ----> Appearance Agent 1344 NOTIFY sip:sa@stateagent.example.com SIP/2.0 1345 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A 1346 From: ;tag=44150CC6-A7B7919D 1347 To: "State_Agent" ;tag=428765950880801 1348 CSeq: 11 NOTIFY 1349 Call-ID: 144-1289338424@example.com 1350 Contact: 1351 Event: dialog 1352 User-Agent: XYZ-UA/4.5.6 1353 Subscription-State: active;expires=3334 1354 Max-Forwards: 70 1355 Content-Type: application/dialog-info+xml 1356 Content-Length: ... 1358 1359 1364 1369 0 1370 false 1371 terminated 1372 1373 1374 1376 1377 1378 sip:carol@example.com 1379 1380 1381 1382 1384 F38 Alice ----> Appearance Agent 1386 NOTIFY sip:sa@stateagent.example.com SIP/2.0 1387 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK93f44af3518A1572 1388 From: ;tag=5861255C-14C04045 1389 To: "State_Agent" ;tag=920163082722420 1390 CSeq: 10 NOTIFY 1391 Call-ID: 143-1840952798@example.com 1392 Contact: 1393 Event: dialog 1394 User-Agent: ABC-UA/1.2.3 1395 Subscription-State: active;expires=3315 1396 Max-Forwards: 70 1397 Content-Type: application/dialog-info+xml 1398 Content-Length: ... 1400 1401 1406 1411 confirmed 1412 0 1413 false 1414 1415 1416 1417 1418 1419 1420 sip:carol@example.com 1421 1423 1424 1425 1427 F42 to F59: Carol terminates the dialog with Alice. Alice notifies the 1428 Appearance Agent of the dialog state (terminated). The Appearance Agent 1429 notifies Bob of the same. 1431 F46 Alice ----> Appearance Agent 1433 NOTIFY sip:sa@stateagent.example.com SIP/2.0 1434 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKa46c2f85F29F839C 1435 From: ;tag=5861255C-14C04045 1436 To: "State_Agent" ;tag=920163082722420 1437 CSeq: 11 NOTIFY 1438 Call-ID: 143-1840952798@example.com 1439 Contact: 1440 Event: dialog 1441 User-Agent: ABC-UA/1.2.3 1442 Subscription-State: active;expires=3311 1443 Max-Forwards: 70 1444 Content-Type: application/dialog-info+xml 1445 Content-Length: ... 1447 1448 1453 1458 terminated 1459 0 1460 false 1461 1462 1463 1464 1465 1466 sip:carol@example.com 1467 1468 1469 1471 1473 10.4. Appearance Selection for Incoming Call 1475 In the call flow below Bob and Alice are in an appearance group 1476 identified by Alice's AOR. Carol places a call to Alice. Both Alice 1477 and Bob's devices are alerted of the incoming call. Bob answers the 1478 call. He then places Carol on hold. Alice picks up the held call 1479 and has a established session with Carol. Finally, Carol terminates 1480 the session. All NOTIFY messages in the call flow below carry dialog 1481 events and only dialog states are mentioned for simplicity. For 1482 brevity, the details of some messages are not shown below. 1484 Forking Appearance 1485 Carol Proxy Agent Alice Bob 1486 | | | | | 1487 |>F1 INVITE >| | | | 1488 | |< - - - - - >| | | 1489 | | |>F2 NOTIFY ----------->| 1490 | | | | | 1491 | | |F4 NOTIFY ->| | 1494 | | | | | 1495 | | |<-200 OK F5-<| | 1496 | | | | | 1497 | |>F6 INVITE ------------------------->| 1498 | | | | | 1499 | |>F7 INVITE --------------->| | 1500 | | | | | 1501 |<- 100 F8 -<| | | | 1502 | | | | | 1503 | |<-------------------- Ringing 180 F9<| 1504 |< 180 F10 -<| | | | 1505 | |<--------- 180 Ringing F11<| | 1506 |< 180 F12 -<| | | | 1507 | |<------------------------ 200 OK F13<| 1508 |< 200 F14 -<| | | | 1509 | | | | | 1510 | |>F14 CANCEL -------------->| | 1511 | | | | | 1512 | |<-------------- 200 OK F15<| | 1513 | | | | | 1514 | |F17 ACK ----------------->| | 1517 |>F18 ACK -->| | | | 1518 | |>F19 ACK --------------------------->| 1519 | | | | | 1520 |<=============Both way RTP established===========>| 1521 | | | | | 1522 | | |<---------- NOTIFY F20<| 1523 | | | | | 1524 | | |>F21 200 OK ---------->| 1525 | | | | | 1526 | | |>F22 NOTIFY >| | 1527 | | | | | 1528 | | |<- 200 F22 -<| | 1529 | | | | | 1530 | | |-------- SUBSCRIBE F23>| 1531 | | | | 1532 | | |F26 200 OK ---------->| 1537 | | | | 1539 Figure 5. 1541 F1 to F16: An incoming call from Carol to Alice is forked to 1542 Bob and Alice. Both Alice and Bob indicate an incoming call 1543 (e.g., ringing) from Carol. Bob answers the call and two-way 1544 media is established between Carol and Bob. 1546 F2 Proxy ----> Bob 1548 INVITE sip:alice@ua3.example.com SIP/2.0 1549 Via: SIP/2.0/UDP ua3.example.com;branch=z9hG4bK4324ea695b5B376A 1550 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK38432ji 1551 From: ;tag=94183CB-BCEAB7 1552 To: 1553 CSeq: 106 INVITE 1554 Call-ID: 47deb849-dca8b6c6-3d342 1555 Contact: 1556 Max-Forwards: 69 1557 Alert-Info: ;alert=normal;appearance=0 1558 Content-Type: application/sdp 1559 Content-Length: 223 1561 v=0 1562 o=- 1102980499 1102980499 IN IP4 ua3.example.com 1563 s= 1564 c=IN IP4 ua3.example.com 1565 t=0 0 1566 a=sendrecv 1567 m=audio 2238 RTP/AVP 0 8 101 1568 a=rtpmap:0 PCMU/8000 1569 a=rtpmap:8 PCMA/8000 1570 a=rtpmap:101 telephone-event/8000 1572 F3 Proxy ----> Alice 1574 INVITE sip:alice@ua1.example.com SIP/2.0 1575 Via: SIP/2.0/UDP ua3.example.com;branch=z9hG4bK4324ea695b5B376A 1576 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK348281 1577 From: ;tag=94183CB-BCEAB7 1578 To: 1579 CSeq: 106 INVITE 1580 Call-ID: 47deb849-dca8b6c6-3d342 1581 Contact: 1582 Max-Forwards: 69 1583 Alert-Info: ;alert=normal;appearance=0 1584 Content-Type: application/sdp 1585 Content-Length: 223 1587 v=0 1588 o=- 1102980499 1102980499 IN IP4 ua3.example.com 1589 s= 1590 c=IN IP4 ua3.example.com 1591 t=0 0 1592 a=sendrecv 1593 m=audio 2238 RTP/AVP 0 8 101 1594 a=rtpmap:0 PCMU/8000 1595 a=rtpmap:8 PCMA/8000 1596 a=rtpmap:101 telephone-event/8000 1598 F17 - F20: Bob notifies the Appearance Agent with dialog state 1599 payload indicating the dialog in confirmed state. Appearance 1600 Agent notifies Alice of the status of the dialog at Bob. 1602 F17 Bob ----> Appearance Agent 1604 NOTIFY sip:sa@stateagent.example.com SIP/2.0 1605 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK58a0dd68C2D63263 1606 From: ;tag=558C18F7-DB9DF7BC 1607 To: ;tag=1894685100249086 1608 CSeq: 14 NOTIFY 1609 Call-ID: 77-505889516@example.com 1610 Contact: 1611 Event: dialog 1612 User-Agent: XYZ-UA/4.5.6 1613 Subscription-State: active;expires=3427 1614 Max-Forwards: 70 1615 Content-Type: application/dialog-info+xml 1616 Content-Length: ... 1618 1619 1624 1630 0 1631 false 1632 confirmed 1633 1634 1635 1636 1637 1638 1639 sip:carol@ua.example.com 1640 1641 1642 1644 F19 Appearance Agent ----> Alice 1646 NOTIFY sip:alice@ua1.example.com SIP/2.0 1647 From: ;tag=151702541050937 1648 To: ;tag=18433323-C3D237CE 1649 Call-ID: 1e361d2f-a9f51109-bafe31d4@ua1.example.com 1650 CSeq: 12 NOTIFY 1651 Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK14031499568413 1652 Max-Forwards: 70 1653 Content-Type: application/dialog-info+xml 1654 Event: dialog 1655 Subscription-State: active 1656 Contact: 1657 Content-Length: ... 1659 1660 1665 1670 0 1671 false 1672 confirmed 1673 1674 1675 1676 1677 1678 1679 sip:carol@ua.example.com 1680 1681 1682 1684 10.5. Appearance Publication 1686 This call flow shows the use of PUBLISH between the members of the 1687 appearance group and the Appearance Agent. 1689 Carol Proxy Alice Appearance Agent Bob 1690 | | | | | 1691 | | | |<----- PUBLISH F1<| 1692 | | | | | 1693 | | | |>F2 200 OK ------>| 1694 | | | | | 1695 | | |<-- NOTIFY F3<| | 1696 | | | | | 1697 | | |>F4 200 OK -->| | 1698 | | | | | 1699 | |<------------------------------------- INVITE F5<| 1700 | | | | | 1701 |<-- INVITE F6<| | | | 1702 | | | | | 1703 |>F7 180 Ring >| | | | 1704 | |>F8 180 Ringing -------------------------------->| 1705 |>F9 200 OK -->| | | | 1706 | |>F10 200 OK ------------------------------------>| 1707 | | | | | 1708 |<------------------------------------------------------ ACK F11<| 1709 | | | | | 1710 |<================= Both way RTP established ===================>| 1711 | | | | | 1712 | | | |<---- PUBLISH F12<| 1713 | | | | | 1714 | | | |>F13 200 OK ----->| 1715 | | |<- NOTIFY F14<| | 1716 | | | | | 1717 | | |>F15 200 OK ->| | 1718 | | | | | 1719 | |<------------------------------(hold) INVITE F16<| 1720 |<- INVITE F17<| | | | 1721 | | | | | 1722 |>F18 200 OK ->| | | | 1723 | |>F19 200 OK ------------------------------------>| 1724 | | | | | 1725 |<------------------------------------------------------ ACK F20<| 1726 | | | | | 1727 | | | |<---- PUBLISH F21<| 1728 | | | | | 1729 | | | |>F22 200 OK ----->| 1730 | | |<- NOTIFY F23<| | 1731 | | | | | 1732 | | |>F24 200 OK ->| | 1733 | |<-- INVITE F25<| | | 1734 |<- INVITE F26<|(w/ Replaces) | | | 1735 |( w/ Replaces)| | | | 1736 |>F27 200 OK ->| | | | 1737 | |>F28 200 OK -->| | | 1738 | | | | | 1739 |<-------------------- ACK F29<| | | 1740 | | | | | 1741 |<= Both way RTP established =>| | | 1742 | | | | | 1743 |>F30 BYE ---->| | | | 1744 | |>F31 BYE --------------------------------------->| 1745 | | | | | 1746 | |<------------------------------------ OK 200 F32<| 1747 |<- 200 OK F33<| | | | 1748 | | | | | 1749 | | | |<---- PUBLISH F34<| 1750 | | | | | 1751 | | | |>F35 200 OK ----->| 1752 | | |<- NOTIFY F36<| | 1753 | | | | | 1754 | | |>F37 200 OK ->| | 1755 | | | | | 1756 | | |>F38 PUBLISH >| | 1757 | | | | | 1758 | | |<- 200 OK F39<| | 1759 | | | |>F40 NOTIFY ----->| 1760 | | | | | 1761 | | | |<----- 200 OK F41<| 1762 |>F42 BYE ---->| | | | 1763 | |>F43 BYE ----->| | | 1764 | | | | | 1765 | |<-- 200 OK F44<| | | 1766 |<--200 OK F45<| | | | 1767 | | |>F46 PUBLISH >| | 1768 | | | | | 1769 | | |<- 200 OK F47<| | 1770 | | | |>F48 NOTIFY ----->| 1771 | | | | | 1772 | | | |<----- OK 200 F49<| 1774 Figure 6. 1776 10.6. Joining an Appearance 1778 In this call flow, a call answered by Bob is joined by Alice or 1779 "bridged". The Join header field is used by Alice to request this 1780 bridging. If Bob did not support media mixing, Bob could obtain 1781 conferencing resources as described in [RFC4579]. 1783 Carol Forking Proxy Appearance Agent Alice Bob 1784 | | | | | 1785 |>F1 INVITE >| | | | 1786 | |>F2 INVITE ------------------------->| 1787 | | | | | 1788 | |>F3 INVITE --------------->| | 1789 | | | | | 1790 |<-100Try F4<| | | | 1791 | | | | | 1792 | |<-------------------- Ringing 180 F5<| 1793 |<180Ring F6<| | | | 1794 | |<---------- Ringing 180 F7<| | 1795 |<180Ring F8<| | | | 1796 | |<------------------------- 200 OK F9<| 1797 |<-200OK F10<| | | | 1798 | | | | | 1799 | |>F11 CANCEL -------------->| | 1800 | | | | | 1801 | |<-------------- 200 OK F12<| | 1802 | | | | | 1803 | |F14 ACK ----------------->| | 1806 |>F15 ACK -->| | | | 1807 | |>F16 ACK --------------------------->| 1808 | | | | | 1809 |<=============Both way RTP established===========>| 1810 | | | | | 1811 | | |<---------- NOTIFY F17<| 1812 | | | | | 1813 | | |>F18 200 OK ---------->| 1814 | | | | | 1815 | | |>F19 NOTIFY >| | 1816 | | | | | 1817 | | |<- 200OK F20<| | 1818 | | | | | 1819 | |<---- INVITE (w/ Join) F21<| | 1820 | | | | | 1821 | |>F22 INVITE (w/Join)---------------->| 1822 | | | | | 1823 | |<---- OK 200 Contact:Bob;isfocus F23<| 1824 | | | | | 1825 | |>F24 200 OK Contact:Bob;isfocus----->| 1826 | | | | | 1827 | |<----------------- ACK F25<| | 1828 | | | | | 1829 | |>ACK F26---------------------------->| 1830 | | | | | 1831 | |<-----INVITE Contact:Bob;isfocus F27<| 1832 |<-INVITE F28| | | | 1833 |>F29 200 -->| | | | 1834 | |>F30 200 OK ------------------------>| 1835 | | | | | 1836 | |<--------------------------- ACK F31<| 1837 |<--- ACK F32| | | | 1838 | | | |<==RTP==>| 1839 |<=============Both way RTP established===========>| 1841 Figure 7. 1843 F21 Alice ----> Proxy 1845 INVITE sip:bob@ua.example.com SIP/2.0 1846 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKcc9d727c2C29BE31 1847 From: ;tag=605AD957-1F6305C2 1848 To: 1849 CSeq: 2 INVITE 1850 Call-ID: dc95da63-60db1abd-d5a74b48@ua1.example.com 1851 Contact: 1852 User-Agent: ABC-UA/1.2.3 1853 P-Preferred-Identity: 1854 1855 Join: 14-1541707345@example.com;to-tag=d3b06488-1dd1-11b2-88c5 1856 -b03162323164+d3e48f4c;from-tag=44BAD75D-E3128D42 1857 1858 Max-Forwards: 70 1859 Content-Type: application/sdp 1860 Content-Length: 223 1862 v=0 1863 o=- 1103061265 1103061265 IN IP4 ua1.example.com 1864 s=IP SIP UA 1865 c=IN IP4 ua1.example.com 1866 t=0 0 1867 a=sendrecv 1868 m=audio 2236 RTP/AVP 0 8 101 1869 a=rtpmap:0 PCMU/8000 1870 a=rtpmap:8 PCMA/8000 1871 a=rtpmap:101 telephone-event/8000 1873 10.7. Appearance Allocation - Loss of Subscription with UA 1875 UA Appearance Agent UA1 UA2 1876 | | | | 1877 | | F1: NOTIFY (trying) | 1878 | |<---------------| | 1879 | | F2: 200 OK | | 1880 | |--------------->| | 1881 | | F3: NOTIFY (trying) | 1882 | |----------------+--------------->| 1883 | | F4: 200 OK | | 1884 | |<---------------+----------------| 1885 | F5: INVITE | | | 1886 |<--------------------------------| | 1887 | F6: 180 Ringing| | | 1888 |-------------------------------->| | 1889 | | | | 1890 | | End | 1891 | | | 1892 | | | 1893 | | F7: SUBSCRIBE x 6 retries | 1894 | |---------------> | 1895 | | | 1896 | | F8: NOTIFY (terminated) | 1897 | |-------------------------------->| 1898 | | F9: 200 OK | 1899 | |<--------------------------------| 1900 | | | 1902 Figure 8. 1904 The flow shown in this figure illustrates the failure of a user agent 1905 after it has obtained an appearance number (F1-F2). Messages used to 1906 refresh the subscription from Appearance Agent to UA1 are shown at 1907 F7. When the Appearance Agent attempts to refresh its subscription 1908 but receives no response. In this case, the Appearance Agent may 1909 apply policy and free up the appearance number as it wishes. In this 1910 case, after a delay, the Appearance Agent frees up the appearance 1911 number and sends NOTIFY messages (F8) indicating the termination of 1912 the dialog associated with the shared line. 1914 10.8. Appearance Selection Contention Race Condition 1916 UA Appearance Agent UA1 UA2 1917 | | | | 1918 | | F1 NOTIFY (trying appearance=1) | 1919 | |<---------------| | 1920 | | F2 NOTIFY (trying appearance=1) | 1921 | |<---------------+----------------| 1922 | | F3 200 OK | | 1923 | |--------------->| | 1924 | | F4 200 OK | | 1925 | |----------------+--------------->| 1926 | | F5 NOTIFY (trying appearance=1)| 1927 | |--------------->| | 1928 | | F6 200 OK | | 1929 | |<---------------| | 1930 | | F7 NOTIFY (trying) | 1931 | |----------------+--------------->| 1932 | | F8 200 OK | | 1933 | |<---------------+----------------| 1934 | F9 INVITE | | | 1935 |<--------------------------------| | 1936 | | F10 NOTIFY (trying appearance=2)| 1937 | |<---------------+----------------| 1938 | | F11 200 OK | | 1939 | |----------------+--------------->| 1940 | | F12 NOTIFY (trying appearance=2)| 1941 | |----------------+--------------->| 1942 | | F13 200 OK | | 1943 | |<---------------+----------------| 1944 | F14 INVITE | | | 1945 |<-------------------------------------------------| 1946 | | | | 1948 Figure 9. 1950 This figure illustrates two user agents, UA1 and UA2, attempting to 1951 select the same appearance number (i.e. seize the same line number) 1952 simultaneously. This type of race condition is often referred to in 1953 telephony as a glare condition. Appearance Agent may use any desired 1954 policy to decide which UA receives the appearance and which does not. 1955 In this case UA1 obtains the appearance number, as indicated by the 1956 NOTIFY from the Appearance Agent with the appearance number. UA2 1957 learns that it did not obtain the appearance number since its NOTIFY 1958 does not contain the appearance number from its NOTIFY. 1960 11. IANA Considerations 1962 This section registers the SIP Alert-Info header field parameter 1963 "appearance" and the XML namespace extensions to the SIP Dialog 1964 Package. 1966 11.1. SIP Event Package Parameter: sa 1968 This specification also defines a new event parameter "sa" for the 1969 Dialog Package. 1971 11.2. URN Sub-Namespace Registration: sa-dialog-info 1973 This section registers a new XML namespace per the procedures in 1974 [RFC3688]. 1976 URI: urn:ietf:params:xml:ns:sa-dialog-info. 1978 Registrant Contact: IETF BLISS working group, , 1979 Alan Johnston 1981 XML: 1983 BEGIN 1984 1985 1987 1988 1989 1991 Shared Appearance Dialog Information Namespace 1992 1993 1994

Namespace for Shared Appearance Dialog Information

1995

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

1996

See 1997 RFCXXXX.

1998 1999 2000 END 2002 11.3. XML Schema Registration 2004 This section registers an XML schema per the procedures in [RFC3688]. 2006 URI: urn:ietf:params:xml:schesa:sa-dialog-info. 2008 Registrant Contact: IETF BLISS working group, , 2009 Alan Johnston 2011 The XML for this schema can be found in Section 7. 2013 12. Appendix A - Incoming Appearance Assignment 2015 To best meet REQ-9, the appearance number for an incoming INVITE 2016 should be contained in the INVITE itself. 2018 For the dialog package parameter approach, REQ-9 could be met in two 2019 ways. When an incoming request is received, the Appearance Agent 2020 could send out a NOTIFY with state trying and include the appearance 2021 number to be used for this request. Upon receipt of this NOTIFY, the 2022 UAs could begin alerting using the appearance number selected. This 2023 approach is sub-optimal since the UAs could receive the INVITE but be 2024 unable to begin alerting if the NOTIFY from the Appearance Agent is 2025 delayed or lost 2027 An alternative approach is to define an extension parameter for the 2028 Alert-Info header field in RFC 3261 such as: 2030 Alert-Info: ;alert=normal;appearance=0 2032 This Alert-Info header would indicate to place the call on the first 2033 line appearance instance. 2035 The determination as to what value to use in the appearance parameter 2036 can be done at the proxy that forks the incoming request to all the 2037 registered UAs. There are a variety of ways the proxy can use to 2038 determine what value it should use to populate this parameter. For 2039 example, the proxy could fetch this information by initiating a 2040 SUBSCRIBE request with Expires: 0 to the Appearance Agent for the AOR 2041 to fetch the list of lines that are in use. Alternatively, it could 2042 act like a UA that is a part of the appearance group and SUBSCRIBE to 2043 the State-Agent like any other UA. This would ensure that the active 2044 dialog information is available without having to poll on a need 2045 basis. It could keep track of the list of active calls for the 2046 appearance AOR based on how many unique INVITE requests it has forked 2047 to or received from the appearance AOR. Another approach would be 2048 for the Proxy to first send the incoming INVITE to the Appearance 2049 Agent which would redirect to the appearance group URI and escape the 2050 proper Alert-Info header field for the Proxy to recurse and 2051 distribute to the other UAs in the group. 2053 The Appearance Agent needs to know about all incoming requests to the 2054 AOR in order to select the appearance number. One way in which this 2055 could be done is for the Appearance Agent to register against the AOR 2056 with a higher q value. This will result in the INVITE being sent to 2057 the Appearance Agent first, then being offered to the UAs in the 2058 group. 2060 The changes to RFC 3261 ABNF would be: 2062 alert-param = LAQUOT absoluteURI RAQUOT *( SEMI (generic-param / 2063 appearance-param) ) 2065 appearance-param = "appearance" EQUAL *DIGIT 2067 13. Appendix B - Implementation Options Discussion 2069 This section discusses some options on how to implement the Shared 2070 Appearances feature in SIP. This section is non-normative. 2072 13.1. Appearance Implementation Options 2074 This section discusses and compares two methods of implementing, 2075 conveying, and selecting appearances in SIP while meeting the 2076 requirements of Section 4. One approach involves a URI parameter and 2077 is discussed in section 5.1.1. The other approach uses a SIP dialog 2078 package extension parameter and is discussed in section 5.1.2. Both 2079 approaches assume the common elements and operations of Figure 1. In 2080 addition, this section discusses approaches for incoming appearance 2081 indication, REQ-9, and appearance contention, REQ-8. These 2082 approaches will be discussed for an example appearance group of N 2083 phones each with n line appearances. The usage of the word phone 2084 does not imply that this feature is limited to telephony devices. 2086 13.1.1. URI parameter Approach 2088 Some implementations of this feature utilize a URI parameter such as 2089 "line=3" on the Contact URI. Each appearance is effectively a 2090 logical UA, so each line appearance requires a separate registration. 2091 The number of line appearances needs to be provisioned on each phone. 2092 Each appearance also requires a separate dialog package subscription. 2093 Even using a State Agent for the dialog package, each phone must 2094 maintain n subscriptions to the dialog package. 2096 This results in 2nN total subscriptions and nN registrations for this 2097 implementation. 2099 Since Contact URI parameters will be conveyed by the dialog package, 2100 REQ-7 is met. 2102 REQ-10 can be met by having the Appearance Agent send a SUBSCRIBE to 2103 each UA and line number to obtain the current dialog state - this 2104 will result in nN SUBSCRIBEs and NOTIFYs. 2106 It is not obvious how to meet REQ-11 with this approach. A UA 2107 registering against the AOR but does not implement the appearance URI 2108 parameter will not include a line appearance number in Contact URIs 2109 and dialog package NOTIFYs. The Appearance Agent will have no way of 2110 indicating to the other UAs the appearance number being used by this 2111 UA, as adding a parameter to the Contact URI would cause call control 2112 operations such as Replaces and Join to fail. 2114 REQs 12 and 13 are difficult to meet with this approach as the line 2115 appearance number will be present in the Request-URI of incoming 2116 requests and the Contact URI in INVITE and 200 OK messages. This 2117 approach will require integrity protection of all dialog creating 2118 requests and responses, and privacy mechanisms to hide the Contact 2119 URI from other UAs. 2121 Also, this approach will require mechanisms to protect against 2122 another UA sending an INVITE directly to a group member with the line 2123 appearance number already set. 2125 13.1.2. Dialog Package Parameter 2127 Instead of the URI parameter approach, consider an extension 2128 parameter "appearance" to the SIP dialog package. The e.g.: 2130 2131 2136 2138 2 2139 false 2140 2141 2142 connected 2143 2144 2145 2146 2147 2148 ... 2150 In this approach, the appearance number is never carried in a 2151 Request-URI or Contact URI. Instead, it is only present in dialog 2152 package NOTIFY and PUBLISH messages. As a result, only a single 2153 registration per AOR is required. Also, only a single dialog package 2154 subscription in each direction per AOR. 2156 This results in 2N total subscriptions and N registrations for this 2157 approach. 2159 If the dialog package is extended to carry the appearance number, 2160 then REQ-7 is met. 2162 REQ-10 can be met by having the Appearance Agent send a SUBSCRIBE to 2163 each UA and line number to obtain the current dialog state - this 2164 will result in N SUBSCRIBEs and NOTIFYs. 2166 REQ-11 can be met by this approach. Even though a UA does not 2167 provide an appearance number in dialog package NOTIFYs, the 2168 Appearance Agent can assign one and include it in NOTIFYs to the 2169 other UAs. This parameter would simply be ignored by the UAs that 2170 did not understand the parameter, and have no impact on call control 2171 operations. 2173 REQs 12 and 13 are met because the appearance number is only conveyed 2174 in dialog package NOTIFYs. Integrity and privacy of NOTIFY bodies 2175 can be achieved using normal SIP mechanisms independent of the 2176 security mechanisms used for other requests. 2178 The dialog-package [RFC3265] describes a mechanism whereby shared- 2179 line privacy REQ-14 can be accomplished by suppressing certain dialog 2180 information from being presented to the UAs. The reasoning behind 2181 that is if the UAs were unaware of a dialog's call-id, local-tag and 2182 remote-tag then they will be unable to create requests such as INVITE 2183 with Replaces [RFC3891] and Join [RFC3911] header fields to barge-in 2184 or pickup the line appearance. Below is a quote from section 3.6 of 2185 dialog-package[RFC3265] that describes this approach: 2187 Note that many implementations of "shared-lines" have a feature that 2188 allows details of calls on a shared address-of-record to be made 2189 private. This is a completely reasonable authorization policy that 2190 could result in notifications that contain only the id attribute of 2191 the dialog element and the state element when shared-line privacy is 2192 requested, and notifications with more complete information when 2193 shared-line privacy is not requested. 2195 There are certain fundamental drawbacks in the privacy-by-obscurity 2196 approach described in [RFC3265] . It models exclusivity as a static 2197 property of the appearance AOR. There are situations where 2198 exclusivity needs to be a dynamic property (e.g. boss does not want 2199 secretary to listen-in on a particular part of the conversation). In 2200 addition, [RFC3265] does not address how a UA can request exclusivity 2201 at the start of a session or mid-session and how that request will be 2202 granted or rejected. 2204 Exclusivity being a dynamic property means that a UA can request it 2205 to be turned on or off in the middle of a session. When exclusivity 2206 is turned off all the UAs that share the line AOR will need to see 2207 the complete dialog information. Once they have that information it 2208 can not be taken back from them. This will not allow exclusivity to 2209 be turned on later on in the dialog lifetime. Therefore, there needs 2210 to be a centralized entity that will actually enforce exclusivity. 2212 The approach proposed for meeting REQ-14 is to include an exclusivity 2213 parameter to the dialog package. This allows a UA to request 2214 exclusivity, by setting the exclusive parameter in notifications. 2215 This could be done prior to a call being made or answered, or during 2216 a call at any time. A UA can remove exclusivity by sending a 2217 notification at any time during a call and setting "exclusive=no". 2218 It also allows a UA to learn that a particular dialog is exclusive by 2219 the presence of this parameter in a NOTIFY. In addition, a UA can 2220 still apply policy to any INVITE Join or Replaces requests it 2221 receives, as per normal SIP call control mechanisms. 2223 With this approach, the number of appearances is centrally managed 2224 and controlled by the Appearance Agent. For UAs with soft keys or 2225 buttons, this gives a great deal of flexibility in system management. 2227 13.1.3. Appearance Selections Mechanisms 2229 Regardless of how the appearance number is conveyed by UAs, there is 2230 still the issue of how appearance numbers are selected. For example, 2231 some UAs might have actual buttons and lamps, and pressing a 2232 particular button requires the UA to reserve a particular appearance 2233 number. For devices with this type of user interface, the selection 2234 must be done before the user continues with the call and dials digits 2235 or a URI. Other UAs with different user interfaces can be flexible 2236 at the time of dialing, updating the display with the appearance 2237 number at a later date. For devices which require advance appearance 2238 selection, there are three options discussed in the following 2239 sections for meeting REQ-15. 2241 13.1.3.1. Floor Control Appearance Selection Mechanism 2243 This approach models each appearance number as a floor (shared 2244 resource) and uses a floor control server to arbitrate exclusive 2245 access (seizure of a particular appearance number). This approach 2246 uses a standard SIP Event State Compositor (ESC), a standard Floor 2247 Control Server that uses the Appearance Agent as Moderator. The 2248 Binary Floor Control Protocol (BFCP) is used between the UAs and the 2249 Floor Control Server. A Registrar/Forking Proxy Server talks to 2250 Appearance Agent about incoming calls. The Appearance Agent acts as 2251 a Moderator for the floor control server and tells forking proxy to 2252 insert the appearance number in incoming and outgoing requests. 2254 Appearance numbers are allocated/selected/reserved in two ways: 2256 For incoming calls, the Forking Proxy interacts with the Appearance 2257 Agent. The Appearance Agent selects an appearance by taking a 2258 particular floor and marking it "moderator controlled". This 2259 appearance number is then included by the Forking Proxy in INVITEs 2260 using the Alert-Info parameter. When a UA answers the call, it takes 2261 the appearance number from the Alert-Info and includes it in the 2262 dialog state publication. It then requests the floor associated with 2263 the appearance number from the floor control server, which forwards 2264 the request to the Appearance Agent (moderator). The Appearance 2265 Agent correlates the floor control request with the dialog state 2266 notification with the dialog ID from the INVITE with the Alert-Info. 2267 If they match, the floor is granted. If they do not match, it means 2268 the floor request is not an answer of the call but is a random 2269 appearance selection by the UA and will be rejected. 2271 For outgoing calls, the UA sends an INVITE and requests a particular 2272 floor from the floor control server. Depending on the User Interface 2273 requirements, the floor request can be done before or after sending 2274 the INVITE. The floor grant policy for most appearances is set to 2275 "first come first serve". Once the floor has been granted and the 2276 call answered, the dialog state publication by the UA will include 2277 the appearance number. 2279 When a call has ended, the UA releases the floor to the floor control 2280 server and this appearance is now available for incoming and outgoing 2281 calls. 2283 When a UA in the group which does not support BFCP is in a call, the 2284 Appearance Agent will grant the floor associated with that appearance 2285 to that UA. When that call is over, the Appearance Agent will 2286 release the floor. Since the UA will not publish the appearance 2287 number to the ESC, the Appearance Agent will need to do that on their 2288 behalf. If the UA does publish dialog state but without the 2289 appearance number, the Appearance Agent will still need to re-publish 2290 the dialog state including the appearance number. UAs in the group 2291 will be able to recognize these two dialogs as one since they will 2292 have the same SIP dialog ID. 2294 13.1.3.2. INVITE Appearance Selection Mechanism 2296 This is an alternative approach that utilizes sending an INVITE to 2297 select/reserve/seize an appearance number. 2299 A UA that does not need to select a particular appearance number (or 2300 doesn't care) would just send an INVITE as normal. The Appearance 2301 Agent would tell the proxy which appearance number was being used by 2302 inserting this information in a header field in the first non-100 2303 provisional response sent back to the calling UA. The UA would then 2304 PUBLISH this appearance number to the Dialog Event State Compositor 2305 for the AOR which would distribute details of the dialog and the 2306 appearance number to the other UAs in the group. 2308 If an INVITE is sent and no appearance number is available, the proxy 2309 would reject the INVITE with a suitable response code and perhaps a 2310 header field indication. 2312 A UA that does need to select a particular appearance number would 2313 use an approach similar to overlap dialing (multi-stage dialing). An 2314 INVITE would be sent when the appearance number is requested (i.e. 2315 when the button is pressed, before dialing begins). The appearance 2316 number selected would be carried in the INVITE, in a header field or 2317 in the Request-URI, for example. The proxy would reject the INVITE 2318 with a 484 Address Incomplete response (see RFC 3578) if the 2319 appearance number is Available and start a timer. The UA could then 2320 resend the INVITE after the URI has been dialed and then PUBLISH this 2321 appearance number to the ESC. If the appearance number is not 2322 available, another response code such as 403 would be sent. The user 2323 could then select a different appearance number and resend the 2324 INVITE. If no INVITE with a matching Call-ID is received before the 2325 timer expires, the appearance seizure is cancelled and is made 2326 available for other calls. 2328 Note that this approach does not actually require a B2BUA, but it 2329 does require a proxy that can act as a UAS and communicate with an 2330 Appearance Agent which keeps track of appearance number allocations. 2332 13.1.3.3. PUBLISH Appearance Selection Mechanism 2334 The approach used in previous versions of this draft is to use the 2335 PUBLISH to the event state compositor to select an appearance number. 2336 This approach requires a special event state compositor and special 2337 behavior on the part of the UA. 2339 In the selection of an appearance for requests initiated by UAs in 2340 the group, there is the possibility of contention where more than one 2341 UA select the same appearance number. 2343 One way to solve this and meet REQ-8 is to require UAs to send a 2344 notification (trying) to the Appearance Agent indicating the 2345 appearance number to be used for the session. The Appearance Agent 2346 would confirm the allocation of the appearance number in a NOTIFY 2347 sent to the group UAs. Should the appearance number be unavailable 2348 or otherwise not allowed, there are two options: 2350 - The notification could be rejected with a 500 response and a Retry- 2351 After header field. The Appearance Agent would send an immediate 2352 NOTIFY indicating that the appearance is unavailable. If the NOTIFY 2353 is received before the expiration of the Retry-After time, the 2354 notification state information would become out of date and would be 2355 discarded without resending. The UA would select another appearance 2356 number and send another notification. 2358 - The notification could be accepted but an immediate NOTIFY 2359 generated by the Appearance Agent indicating that the appearance is 2360 unavailable. The UA would then select another appearance number and 2361 PUBLISH again. 2363 UAs would wait for a notification from the Appearance Agent before 2364 sending the INVITE. 2366 13.2. Comparison 2368 In comparing the URI parameter and the dialog package parameter, 2369 there are clear differences in the number of registrations and 2370 subscriptions, with the dialog package approach requiring n times 2371 fewer in both cases. 2373 The security model for the dialog package parameter approach is much 2374 cleaner, since only NOTIFY and PUBLISH requests need integrity and 2375 privacy. The security model for the URI parameter approach would 2376 likely require a B2BUA which introduces many undesirable properties. 2378 The dialog package parameter approach has better backwards 2379 compatibility than the URI parameter approach. 2381 In summary, the dialog package parameter approach better meets REQs 2382 5, 10, 11, 12, and 13 while the URI parameter approach better meets 2383 REQ-9. However, the combined dialog package parameter approach and 2384 the Alert-Info parameter approach meets REQ-9. 2386 13.2.1. Comparison of Appearance Selection Methods 2388 All three approaches meet REQ-15 and REQ-16. 2390 Previous versions of this draft proposed the publish/notify method of 2391 appearance selection. The advantage of this approach is that the 2392 appearance number is only carried in one place (dialog package XML 2393 documents) and the same protocol/mechanism is used to select and 2394 learn appearance numbers. The disadvantage of this approach is that 2395 a specialized event state compositor must be used, since it is aware 2396 of appearance numbers. Also, concerns have been raised about whether 2397 this approach defines new semantics for publish/notify beyond that in 2398 RFC 3265. 2400 The floor control approach makes good reuse of existing protocols 2401 such as Binary Floor Control Protocol (BFCP) and cleanly models the 2402 state. However, while BFCP can be used in conferencing applications, 2403 it is unlikely most UAs implementing shared appearances would utilize 2404 the protocol. Also, having appearance state in two places (dialog 2405 package XML documents and floor control messages) complicates the 2406 application. Also, BFCP only runs over TCP and requires a separate 2407 offer/answer exchange to establish the connection, making operation 2408 through NATs and firewalls more difficult. The BFCP approach is also 2409 radically different from all current implementations of this feature. 2410 As a result, standardizing this approach would likely result in an 2411 increase in feature interoperability rather than a decrease. 2413 The INVITE selection mechanism is based on overlap dialing. Overlap 2414 dialing is supported in very few SIP UAs and is regarded as a 2415 somewhat archaic leftover from the PSTN. As such, it is not regarded 2416 as a good starting point for a common feature such as shared 2417 appearances. 2419 The PUBLISH selection mechanism reuses the SIP events extensions 2420 which already must be implemented by UAs supporting this feature. In 2421 fact, it results in no additional messages or round trips. It is 2422 also very similar to many current feature implementations today. 2423 Standardizing this approach is likely to increase overall 2424 interoperability of this feature. 2426 The rest of this document will only discuss the PUBLISH appearance 2427 selection mechanism. 2429 14. Acknowledgements 2431 The following individuals were part of the SA Design team and have 2432 provided input and text to the document (in alphabetical order): 2434 Martin Dolly, Andrew Hutton, Raj Jain, Fernando Lombardo, Derek 2435 MacDonald, Bill Mitchell, Michael Procter, Theo Zowzouvillys. 2437 Thanks to Chris Boulton for helping with the XML schema. 2439 Much of the material has been drawn from previous work by Mohsen 2440 Soroushnejad, Venkatesh Venkataramanan, Paul Pepper and Anil Kumar, 2441 who in turn received assistance from: 2443 Kent Fritz, John Weald, and Sunil Veluvali of Sylantro Systems, Steve 2444 Towlson, and Michael Procter of Citel Technologies, Rob Harder and 2445 Hong Chen of Polycom Inc, John Elwell, J D Smith of Siemens 2446 Communications, Dale R. Worley of Pingtel, Graeme Dollar of Yahoo 2447 Inc. 2449 Also thanks to Geoff Devine, Paul Kyzivat, Jerry Yin, John Elwell, 2450 Dan York, Spenser Dawkins, and Martin Dolly for their comments. 2452 15. Security Considerations 2454 Since multiple line appearance features are implemented using 2455 semantics provided by [RFC3261], Event Package for Dialog State as 2456 define in , and Event Notification [RFC3265], [RFC3903], security 2457 considerations in these documents apply to this draft as well. 2459 Specifically, since dialog state information and the dialog 2460 identifiers are supplied by UA's in an appearance group to other 2461 members, the same is prone to "call hijacks". For example, a rogue 2462 UA could snoop for these identifiers and send an INVITE with Replaces 2463 header containing these call details to take over the call. As such 2464 INVITES with Replaces header MUST be authenticated using the standard 2465 mechanism (like Digest or S/MIME) described in [RFC3261]. before it 2466 is accepted. NOTIFY message bodies that provide the dialog state 2467 information and the dialog identifiers MAY be encrypted end-to-end 2468 using the standard mechanics. All SUBSCRIBES between the UA's and 2469 the Appearance Agent MUST be authenticated. 2471 16. Informative References 2473 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2474 Requirement Levels", BCP 14, RFC 2119, March 1997. 2476 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2477 A., Peterson, J., Sparks, R., Handley, M., and E. 2478 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2479 June 2002. 2481 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 2482 Method", RFC 3515, April 2003. 2484 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 2485 Event Notification", RFC 3265, June 2002. 2487 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 2488 for Event State Publication", RFC 3903, October 2004. 2490 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 2491 Protocol (SIP) "Replaces" Header", RFC 3891, 2492 September 2004. 2494 [I-D.ietf-sipping-service-examples] 2495 Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and 2496 K. Summers, "Session Initiation Protocol Service 2497 Examples", draft-ietf-sipping-service-examples-15 (work in 2498 progress), July 2008. 2500 [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- 2501 Initiated Dialog Event Package for the Session Initiation 2502 Protocol (SIP)", RFC 4235, November 2005. 2504 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 2505 Package for Registrations", RFC 3680, March 2004. 2507 [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol 2508 (SIP) "Join" Header", RFC 3911, October 2004. 2510 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 2511 Extensions to the Session Initiation Protocol (SIP) for 2512 Asserted Identity within Trusted Networks", RFC 3325, 2513 November 2002. 2515 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol 2516 (SIP) Call Control - Conferencing for User Agents", 2517 BCP 119, RFC 4579, August 2006. 2519 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 2520 "Indicating User Agent Capabilities in the Session 2521 Initiation Protocol (SIP)", RFC 3840, August 2004. 2523 Authors' Addresses 2525 Alan Johnston (editor) 2526 Avaya 2527 St. Louis, MO 63124 2529 Email: alan@sipstation.com 2531 Mohsen Soroushnejad 2532 Sylantro Systems Corp 2534 Email: mohsen.soroush@sylantro.com 2536 Venkatesh Venkataramanan 2537 Sylantro Systems Corp 2539 Email: vvenkatar@gmail.com 2541 Paul Pepper 2542 Citel Technologies 2544 Email: paul.pepper@citel.com 2546 Anil Kumar 2547 Yahoo Inc. 2549 Email: anil@yahoo-inc.com 2551 Full Copyright Statement 2553 Copyright (C) The IETF Trust (2008). 2555 This document is subject to the rights, licenses and restrictions 2556 contained in BCP 78, and except as set forth therein, the authors 2557 retain all their rights. 2559 This document and the information contained herein are provided on an 2560 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2561 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2562 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2563 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2564 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2565 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2567 Intellectual Property 2569 The IETF takes no position regarding the validity or scope of any 2570 Intellectual Property Rights or other rights that might be claimed to 2571 pertain to the implementation or use of the technology described in 2572 this document or the extent to which any license under such rights 2573 might or might not be available; nor does it represent that it has 2574 made any independent effort to identify any such rights. Information 2575 on the procedures with respect to rights in RFC documents can be 2576 found in BCP 78 and BCP 79. 2578 Copies of IPR disclosures made to the IETF Secretariat and any 2579 assurances of licenses to be made available, or the result of an 2580 attempt made to obtain a general license or permission for the use of 2581 such proprietary rights by implementers or users of this 2582 specification can be obtained from the IETF on-line IPR repository at 2583 http://www.ietf.org/ipr. 2585 The IETF invites any interested party to bring to its attention any 2586 copyrights, patents or patent applications, or other proprietary 2587 rights that may cover technology that may be required to implement 2588 this standard. Please address the information to the IETF at 2589 ietf-ipr@ietf.org.