idnits 2.17.1 draft-anil-sipping-bla-04.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 2068. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2079. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2086. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2092. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 243 has weird spacing: '...tration alice...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: In case a UA receives a 500 final response for the NOTIFY, it MUST inspect the Retry-After interval. If one is present, the UA must wait for this interval before it retries sending the NOTIFY. Further it should continue to delay sending out the INVITE. Should the UA receive a NOTIFY of (trying) from the Appearance Agent before the expiry of this interval, it MUST honor the same by providing appropriate end user indication; cancel any timers it has started for retrying the NOTIFY request; and abandon reinitiating of the NOTIFY request. The UA MUST then abandon sending out INVITE to the address in such a scenario. It should be noted that this 500 response does not amount to a NOTIFY failure. Specifically, this response MUST not result in the UA terminating Subscriptions of the Appearance Agent. -- 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 (March 4, 2007) is 6256 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC 3840' on line 466 -- Looks like a reference, but probably isn't: 'RFC 4211' on line 1940 == Unused Reference: '1' is defined on line 1978, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3265 (ref. '4') (Obsoleted by RFC 6665) == Outdated reference: A later version (-15) exists of draft-ietf-sipping-service-examples-12 == Outdated reference: A later version (-02) exists of draft-johnston-bliss-mla-req-00 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BLISS M. Soroushnejad, Ed. 3 Internet-Draft V. Venkataramanan 4 Intended status: Informational Sylantro Systems Corp 5 Expires: September 5, 2007 P. Pepper 6 Citel Technologies 7 A. Kumar 8 Yahoo Inc. 9 A. Johnston, Ed. 10 Avaya 11 March 4, 2007 13 Implementing Multiple Line Appearances using the Session Initiation 14 Protocol (SIP) 15 draft-anil-sipping-bla-04 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 September 5, 2007. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). 46 Abstract 48 This document describes the implementation of a group telephony 49 feature commonly known as Bridged Line Appearance (BLA), Multiple 50 Line Appearance (MLA), or Shared Call/Line Appearance (SCA). When 51 implemented using the Session Initiation Protocol (SIP), it is 52 referred to as Multiple Appearances. This feature is commonly 53 offered in the IP Centrex services and IP-PBX offerings and is likely 54 to be implemented on SIP IP telephones and SIP feature servers used 55 in a business environment. This specification defines a new SIP 56 dialog event package tag "appearance" and a method for a group of SIP 57 user agents to coordinate the identification of appearances between 58 them using SIP dialog package subscriptions. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Conventions used in this document . . . . . . . . . . . . . . 3 64 3. Feature Description . . . . . . . . . . . . . . . . . . . . . 3 65 3.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 5 66 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 67 4.1. Appearance Implementation . . . . . . . . . . . . . . . . 8 68 5. Normative Description . . . . . . . . . . . . . . . . . . . . 10 69 5.1. Multiple Appearance User Agents . . . . . . . . . . . . . 10 70 5.2. Appearance Agent . . . . . . . . . . . . . . . . . . . . . 12 71 6. Example Message Flows . . . . . . . . . . . . . . . . . . . . 13 72 6.1. Registration and Subscription Flows . . . . . . . . . . . 13 73 6.1.1. Alice Registration and Subscription Flow . . . . . . . 13 74 6.1.2. Registration and Subscription Flow . . . . . . . . . . 17 75 6.2. Call Originated within the Appearance Group . . . . . . . 19 76 6.3. Call Offered to an Appearance Group . . . . . . . . . . . 30 77 6.4. Use of PUBLISH . . . . . . . . . . . . . . . . . . . . . . 36 78 6.5. Bridging on an Appearance . . . . . . . . . . . . . . . . 38 79 6.6. State and Error Recovery Examples . . . . . . . . . . . . 40 80 6.6.1. Line Seize (Refresh Subscription) . . . . . . . . . . 40 81 6.6.2. Line Seize (Notifier Failure) . . . . . . . . . . . . 41 82 6.6.3. Line Seize (Race Condition) . . . . . . . . . . . . . 42 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 43 85 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 86 10. Normative References . . . . . . . . . . . . . . . . . . . . . 43 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 88 Intellectual Property and Copyright Statements . . . . . . . . . . 46 90 1. Introduction 92 The feature and functionality requirements for SIP user agents 93 supporting business telephony applications differ vastly from basic 94 SIP user agents, both in terms of services and end user experience. 95 In addition to basic SIP support, many of the services in a business 96 environment require the support for SIP extensions such as REFER [3], 97 SUBSCRIBE/NOTIFY primitives [4], the SIP Replaces header field [5], 98 etc. Many of the popular business services have been documented in 99 the SIPPING service-examples draft [6]. 101 This specification details a method for implementing a group 102 telephony feature known in telephony as Bridged Line Appearance (BLA) 103 or Multiple Line Appearance (MLA), one of the more popular advanced 104 features expected of SIP IP telephony devices in a business 105 environment. Another common name for the this feature is Shared 106 Call/Line Appearance (SCA). 108 This specification uses standard SIP RFC 3261 [2] in conjunction with 109 RFC 3265 [4] for exchanging status among user agents, and the SIP 110 dialog state event package [7] to exchange dialog state information 111 to achieve the same. This specification also extends RFC 4235 to add 112 a new dialog package parameter "appearance" which is used to 113 coordinate the appearance number of a given Address of Record (AOR). 114 A parameter for the Alert-Info header field is also defined. 116 2. Conventions used in this document 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC-2119 [ ] and 121 indicate requirement levels for compliant mechanisms. 123 3. Feature Description 125 The basic functionality of the multiple appearance feature can be 126 summarized as follows: 128 1. Incoming calls to the AOR are offered to a group of UAs and can 129 be answered by any of them. The group is referred to as BLA or MA 130 group. The method by which the group is defined (i.e., created, 131 members added/deleted, etc.) is out of the scope of this document. 133 2. Each UA in the group knows the call status of the others in the 134 group and typically renders this information to the user. 136 3. Each call or session (incoming or outgoing) is assigned a unique 137 "appearance" number from a managed pool administered for the AOR 138 group. This number is used by the user interface for display of call 139 information (e.g. the order of the lamp/button on the device) and 140 out-of-band indications (e.g. "Sales pickup line 2, please"). Once 141 the dialog has terminated, the appearance number is released back 142 into the pool and can be reassigned to another incoming or outgoing 143 session. 145 4. Calls can be joined (also called bridged or conferenced together) 146 or can be placed on hold and picked up (taken) by another UA in the 147 group. 149 #1 is commonly done today in SIP by having each UA register against 150 the group AOR. Incoming requests are forked by the proxy server to 151 all UAs. 153 #2 can be done using the SIP dialog package. To avoid a full mesh of 154 dialog package subscriptions, this specification uses a State Agent. 156 #3 requires an extension to SIP, defined in this specification. 158 #4 can be done using the Replaces and Join header fields constructed 159 using information obtained from the dialog package. 161 In traditional telephony, the line is physical. A common scenario is 162 for a number of business telephones to share a single or a small 163 number of lines. The appearance number relates to the user interface 164 for the telephone - typically each appearance has a visual display 165 (lamp that can change color or blink) and a button (used to select 166 the appearance). In SIP terms, the line is virtual. However, the 167 concept of appearance is still relevant to SIP due to the user 168 interface considerations. It is important to keep the appearance 169 number construct because: 171 1. Human users are used to the concept and will expect it in 172 replacement systems (e.g. an overhead page announcement says "Joe 173 pickup line 3") 175 2. It is a useful structure for user interface representation 177 3. There are cases where for bandwidth or gateway limitations, it is 178 useful to limit the number of concurrent sessions. 180 In this document, we will use the term "appearance" as a stand-in for 181 "line appearance". Note that this does not mean that a conventional 182 telephony user interface (lamps and buttons) must be used - 183 implementations may use another metaphor as long as the appearance 184 number is readily apparent to the user. 186 3.1. Usage Scenarios 188 The following examples are common applications of the Multiple 189 Appearances feature and are mentioned here as informative use cases: 191 1. Executive/Assistant arrangement: The executive may appear as an 192 appearance on the assistant SIP telephony device. Assistant may 193 answer incoming calls to executive and then place the call on hold 194 for the executive to pick it up. The assistant can always see the 195 call state of the executive. 197 2. BLA Call Group: Users with similar business needs or tasks can be 198 assigned to specific groups and share the line appearances of each 199 other on each others SIP telephony devices. For example, an IT 200 department staff of five might answer a help line which has three 201 appearances on each phone in the IT work area. A call answered on 202 one phone can be put on hold and picked up on another phone. A shout 203 or an IM to another staff member can result in them taking over a 204 call on a particular appearance. 206 3. Virtual BLA: Allows a AOR, not assigned as a primary appearance 207 to any user, to be set up as a BLA on a given set of user devices. 209 All the example usages above can be supported by the Multiple 210 Appearances feature described in this document, however the details 211 of setup and usage of the above examples are not relevant to 212 understanding of the BLA mechanism itself. 214 4. Overview of Operation 216 This section provides an overview of the components and operation of 217 the service. It is non-normative in nature. The requirements for 218 the Multiple Appearances feature are documented in [13]. 220 The Multiple Line Appearance service uses the following components to 221 enable this feature: 223 - SIP Registrar/Location Service 225 - SIP Forking Proxy 227 - Appearance Agent defined in this specification 229 - SIP User Agents that support this feature 230 The Appearance Agent implements a State Agent (SA) for the dialog 231 state for the AOR of the group and manages the appearance number 232 shared resource. 234 Figure 1 illustrates the SIP components involved in supporting the 235 Multiple Appearance feature as described in this document. 237 +----------------------------+ +----+ 238 | | | | 239 | Appearance Agent | | UA | 240 | | | | 241 +----------------------------+ +----+ 242 ^ ^ |1)SUBSCRIBE ^ ^ 4)NOTIFY INVITE | 243 | | |(Event:reg) | | registration alice@example.com | 244 | | V | | events V 245 | | +--------------------+ +----------+7)Query+--------+ 246 | | | (example.com) | | |<===== | | 247 | | | |3) Store| Location | | Proxy | 248 | | | Registrar |=======>| Service | | | 249 | | | | | |=====> | | 250 | | +--------------------+ +----------+8)Resp +--------+ 251 | | ^ ^ | | 252 | | | | 2) REGISTER (alice) | | 253 | | | | | | 254 | | +----+ +----+ | | 255 | | | | | | | | 256 | | |UA1 | |UA2 | | | 257 | | | | | | | | 258 | | +----+ +----+ | | 259 | | ^ ^ ^ ^ | | 260 | | | | | | | | 261 | +----+ | | | | | 262 | | | +--------------------------------------+ | 263 | +----+-------------------------------------------+ 264 | | 8) INVITE 265 +--------------+ alice@example.com 266 5-7) SUBSCRIBE and/or PUBLISH 267 (Event:dialog) 269 Figure 1. 271 1. The Appearance Agent SUBSCRIBES to the registration event package 272 as outlined in [8] for contacts registered to the group AoR. Thus, 273 it has knowledge of all User Agents registered against the AOR at any 274 point of time. 276 2. User Agents (UA1 and UA2 in Figure 1) belong to the appearance 277 group and REGISTER against the same AOR (e.g., alice@example.com). 278 The SIP third-party registration mechanism (i.e., when From: is not 279 equal to To: in the REGISTER message)can be used to allow the members 280 of the group to have different authentication credentials. 282 3. Each registration is stored in the Location Service. 284 4. The registrar notifies the Appearance Agent of successful 285 registration at each UA. 287 5. The Appearance Agent SUBSCRIBEs to User Agents for the state of 288 all dialogs associated with the UA1 and UA2, as defined in [7]. 289 Alternatively, if configured with the URI of the Appearance Agent, 290 UA1 and UA2 can PUBLISH [14] their dialog state directly. 292 6. The User Agents SUBSCRIBE to the Appearance Agent for the state 293 of all dialogs as defined in [7]. The Request-URI of the SUBSCRIBE 294 could be either the AOR of the group or the Contact URI information 295 it received in the incoming subscription from the Appearance Agent. 297 7. The User Agents act as the notifier for the dialog state events 298 as defined in [7]. They send a NOTIFY every time their dialog state 299 changes (i.e. receive an INVITE, enter alerting state, answer a call, 300 terminate a call, generate an INVITE, etc.) 302 8. Forking Proxy forks an incoming INVITE for the AOR address to the 303 registered user agents. 305 The User Agents in the group could SUBSCRIBE to each other and NOTIFY 306 dialog state events, but in a large group the User Agents have to 307 manage a larger number of SUBSCRIPTIONS and NOTIFICATIONS. The State 308 Agent in the Appearance Agent helps in managing large groups better. 309 Further, the State Agent can filter dialog state events and NOTIFY 310 User Agents of the dialog state events which are required for the 311 application or feature. The State Agent can also SUBSCRIBE to dialog 312 state events with filters to reduce the number of NOTIFY messages 313 exchanged between the State Agent and the user agents in the group. 314 This allows a group of N UAs to each only establish a single dialog 315 state subscription to learn the dialog state of all other group 316 members. This results in 2N total subscriptions for the entire 317 group. A full mesh of subscriptions without a state agent would 318 result in N(N-1) total subscriptions. 320 Just as conferencing systems commonly have a single point of control, 321 known as a focus, a Multiple Appearance group has a single point of 322 control of the appearance shared resource. This is known as the 323 Appearance Agent for a group. While an Appearance Agent can be part 324 of a centralized server, it could also be co-resident in a member 325 User Agent who has taken on this functionality for a group. The 326 Appearance Agent learns the group state either by subscribing to the 327 dialog state of each member UA individually or by dialog state 328 publications from members. 330 The Appearance Agent can select the appearance number for an incoming 331 call. The appearance number is a non-negative integer: 0,1,2, etc. 332 An Appearance agent can use the registration event package to learn 333 how many UAs are part of the group. The Appearance Agent sends a 334 NOTIFY of dialog state events to all the User Agents. 336 4.1. Appearance Implementation 338 This section discusses and compares two methods of implementing the 339 appearance function. One uses a URI parameter while the other uses a 340 SIP dialog package extension parameter. 342 Some implementations of this feature utilize a URI parameter such as 343 "line=3" on the Contact URI. While this does work, it is sub-optimal 344 for the following reasons: 346 1. Each "line" on a UA needs to REGISTER individually against the 347 AOR. For a system of many multi-line phones, this greatly multiplies 348 the number of registrations and refreshes. For N phones each with n 349 appearances, this means nN registrations. 351 2. Since each "line" has a unique Contact, a separate dialog package 352 subscription would be needed for each "line". This would result in 353 2nN subscriptions. 355 3. The number of appearances is controlled by the UA. Using other 356 approaches, it is possible to have the Appearance Agent dynamically 357 manage the number of appearances. 359 4. The "line" number conveyed in the Contact URI would be always 360 shared with the other UA in the dialog, possibly leaking private 361 information ("So who do you have on line 1?"). 363 5. Incoming INVITEs constructed using Contact URIs could be rejected 364 due to having incorrect "line" number settings. 366 Instead of the URI parameter approach, this specification defines an 367 extension parameter "appearance" to the SIP dialog package. The 368 value of this parameter is a non-negative integer: 0,1,2, etc. 369 Compared to the URI parameter approach: 371 1. Only one registration per UA per AOR is required, as per normal 372 SIP. 374 2. Only a single dialog package subscription per AOR per UA is 375 needed, resulting in 2N total subscriptions. 377 3. The number of appearances is centrally managed and controlled by 378 the Appearance Agent. 380 4. The appearance number is never leaked to the other UA in a 381 dialog. 383 5. Only the Appearance Agent can select an appearance number for 384 incoming requests, avoiding call failures. 386 When a UA indicates, via a dialog-info NOTIFY command, a state change 387 on a dialog, the appearance parameter is placed in the parameters of 388 the local target of the dialog-info. For example: 390 391 395 396 trying 397 398 399 400 401 402 403 404 ... 406 Before the user can be alerted on an incoming request, a UA needs to 407 know the appearance number for an incoming request. For this reason, 408 an extension parameter is defined for the Alert-Info header field. 410 For example: 412 Alert-Info: ;alert=normal;appearance=0 414 This Alert-Info header would indicate to place the call on the first 415 line appearance instance. 417 The determination as to what value to use in the appearance parameter 418 can be done at the proxy that forks the incoming request to all the 419 registered UA's. There are a variety of ways the proxy can use to 420 determine what value it should use to populate this parameter. For 421 example, the proxy could fetch this information by initiating a 422 SUBSCRIBE request with Expires: 0 for the AOR to fetch the list of 423 lines that are in use. Alternatively, it could act like a UA that is 424 a part of the APPEARANCE group and SUBSCRIBE to the State-Agent like 425 any other UA. This would ensure that the active dialog information 426 is available without having to poll on a need basis. It could keep 427 track of the list of active calls for the APPEARANCE AOR based on how 428 many unique INVITE requests it has forked to or received from the 429 APPEARANCE AOR. The actual mechanism is left to the implementation. 431 The Appearance Agent needs to know about all incoming requests to the 432 AOR in order to select the appearance number. One way in which this 433 could be done is for the Appearance Agent to register against the AOR 434 with a higher q value. This will result in the INVITE being sent to 435 the Appearance Agent first, then being offered to the UAs in the 436 group. The actual mechanism used is left to the implementation. 438 It should be noted that the appearance parameter is relative to the 439 AOR. Thus a UA can support multiple AOR's with each AOR capable of 440 supporting appearance's sequentially numbered from 0 through n-1 441 where n is the number of lines the UA supports for each of the AOR's. 443 5. Normative Description 445 This section normatively describes the service. 447 5.1. Multiple Appearance User Agents 449 User Agents that support the Multiple Appearance feature MUST support 450 the dialog state package as outlined in [7] to NOTIFY other User 451 Agents of the dialog-state. 453 User Agents MUST support Replaces [5] and MAY support Join [11]. 455 They MUST support the "appearance" extensions to the dialog package 456 defined in this specification. They SHOULD understand and support 457 the (ma) event parameter outlined in this draft. Section 7 of this 458 draft outlines how this parameter is to be interpreted by the UA. 460 When generating dialog package notifications, UAs MUST include dialog 461 identification information including call-id, to-tag and from-tag. 462 When calls are placed on hold, the UAs MAY include local session 463 description in the dialog package notification. The element should 464 indicate that the call that is the subject of the dialog is being 465 held (use of a=inactive or a=sendonly is RECOMMENDED [9]). When 466 calls are placed on hold, the "+sip.rendering=no" [RFC 3840] feature 467 tag MUST be used. 469 The UA MUST send dialog-info in state "trying" with the appropriate 470 appearance parameter present in the local target when it is 471 attempting to 'seize' a line appearance. It MUST NOT send the INVITE 472 until a 200 OK response to the NOTIFY is received from the Appearance 473 Agent. 475 Note: Sending NOTIFY dialog state of (trying) before an INVITE is a 476 departure from [7], but this MUST be implemented to resolve glare 477 issues. 479 In case a UA receives a 500 final response for the NOTIFY, it MUST 480 inspect the Retry-After interval. If one is present, the UA must 481 wait for this interval before it retries sending the NOTIFY. Further 482 it should continue to delay sending out the INVITE. Should the UA 483 receive a NOTIFY of (trying) from the Appearance Agent before the 484 expiry of this interval, it MUST honor the same by providing 485 appropriate end user indication; cancel any timers it has started for 486 retrying the NOTIFY request; and abandon reinitiating of the NOTIFY 487 request. The UA MUST then abandon sending out INVITE to the address 488 in such a scenario. It should be noted that this 500 response does 489 not amount to a NOTIFY failure. Specifically, this response MUST not 490 result in the UA terminating Subscriptions of the Appearance Agent. 492 This is needed to resolve conflicts in the use of a particular 493 appearance. 495 Further, the dialog state definition [7] has no restrictions on the 496 number of dialogs that MAY be conveyed in a single SIP NOTIFY 497 message. However, since the NOTIFY for going off-hook can be 498 rejected by the Appearance Agent, such a NOTIFY MUST be presented to 499 the Appearance Agent as a single dialog payload in the NOTIFY. 501 The dialog state package defined in [7] defines the set of messages 502 that MAY be provided by a UA to publish state information of dialogs. 503 For satisfactory operation of this feature, the flows require that 504 the UA SUBSCRIBE to the dialog-event package on receipt of a SUBSRIBE 505 request. It MUST use the contact in this SUBSCRIBE for making 'line 506 reservations' when placing calls from the AOR. Also, as seen in the 507 above example message flows, not all of these messages need to be 508 published by a UA to effectively participate in a BLA group. In 509 order to indicate this preference, this draft proposes a new Event 510 parameter for the dialog package called (ma). User Agents that 511 understand this parameter will provide dialog state information as 512 detailed in this draft. 514 A critical aspect for reliable operation of this feature is the 515 ability for all user agents in the BLA group to recover from network 516 failures caused at a single UA. For example, one of the user agents 517 in the BLA group may have answered an incoming call, notified the 518 dialog state to other members and then experienced a network outage. 519 The calling UA could have detected the same (using RTP or some other 520 means) and could have hung up. However, none of the other user 521 agents in the BLA group would get notification of this change in 522 dialog state and their BLA appearances could stay out of sync for a 523 long time; depending on when the network is restored, or when the 524 Appearance Agent attempts to refresh its dialog-state subscription 525 with the failed UA. To recover from such a failure, the Appearance 526 Agent MUST SUBSCRIBE with a shorter expiration (expiration interval 527 not smaller than 300 seconds is RECOMMENDED) following the 528 notification of a "confirmed" dialog or when a Event Agent honors a 529 "trying" for call origination, with the user agents that notified it 530 of this information. 532 Alternatively, while a user agent is acquiring, or holds a line 533 seize, the dialog subscriptions to it act as BLA status indicators to 534 the subscriber. If subscription refresh requests to the user agent 535 are not honored, then it must be determined that the user agent's 536 capacity to maintain line seize has been lost. For this reason, 537 during the period a user agent is acquiring or holds a line seize, 538 the remaining expiry period of subscriptions to it MAY be reduced by 539 the user agent to minimize the outage problem (expiration interval 540 not smaller than 300 seconds is RECOMMENDED). This can be 541 accomplished by setting the Expires parameter in the Subscription- 542 State header in the NOTIFY message sent out by the UA. 544 5.2. Appearance Agent 546 An Appearance Agent defined in this specification MUST implement a 547 dialog package state agent for the UAs registered against the AOR. 549 The Appearance Agent MUST support the appearance dialog package 550 extensions defined in this specification. 552 Even in trivial deployments of two multiple appearance enabled user 553 agents, race conditions can exist when both user agents attempt to 554 utilize an appearance simultaneously (i.e. when the NOTIFY messages, 555 that each user agent sends to the other, are active within the 556 network during an overlapping time period). The SIP-specific event 557 notification framework, described in [4], defines the use of state 558 agents. State agents act on behalf of resources to publish state. 559 The Appearance Agent can use any policy deemed necessary to resolve 560 races and ensure no two user agents obtain the same line seize during 561 overlapping periods. 563 Appearance Agents are responsible for resolving conflicts in the 564 appearance resource. If a UA requests the use of an appearance 565 number that is in use by another UA, the Appearance Agent will send a 566 500 response and resend a dialog state notification to the UA to 567 allow them to synchronize with the proper state. An example is shown 568 in Section 7.3. 570 6. Example Message Flows 572 The next section shows call flows. The flows and descriptions are 573 non-normative. 575 6.1. Registration and Subscription Flows 577 Bob has bridged line appearance for Alice. Bob REGISTERs for Alice's 578 AOR using contact sip:alice@ua2.example.com. Furthermore, Bob 579 REGISTERs his primary address with contact sip: bob@ua2.example.com. 580 Alice REGISTERs with contact sip:alice@ua1.example.com. 582 The Appearance Agent subscribes to dialog states of the BLA AOR 583 (i.e., sip:alice@example.com) at the User Agents for Alice and Bob. 584 Message exchange between the Registrar, Appearance Agent, Alice, and 585 Bob are shown below. The call flow examples below do not show 586 challenging of subscriptions or notifications. It should be noted 587 that for security purposes, all subscriptions MUST be authorized 588 before the same is accepted. 590 6.1.1. Alice Registration and Subscription Flow 592 Registrar Appearance Agent Alice 593 | | | 594 | | | 595 |<--------------------------- REGISTER F1<| 596 | | | 597 |>F2 200 OK ----------------------------->| 598 | | | 599 | |>F3 SUBSCRIBE ----->| 600 | | | 601 | |<-------- 200 OK F4<| 602 | | | 603 | |<-------- NOTIFY F5<| 604 | | | 605 | |>F6 200 OK -------->| 606 | | | 607 | |<----- SUBSCRIBE F7<| 608 | | | 609 | |>F8 202 Accepted -->| 610 | | | 611 | |>F9 NOTIFY -------->| 612 | | | 613 | |<------- OK 200 F10<| 614 | | | 616 F1-F2: Alice registers AOR with contact: 618 F1 Alice ----> Registrar 620 REGISTER sip:registrar.example.com SIP/2.0 621 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09 622 From: ;tag=CDF9A668-909E2BDD 623 To: 624 CSeq: 2 REGISTER 625 Call-ID: d3281184-518783de-cc23d6bb@ua1.example.com 626 Contact: 627 User-Agent: ABC-UA/1.2.3 628 Max-Forwards: 70 629 Expires: 3600 630 Content-Length: 0 632 F2 Registrar ----> Alice 634 SIP/2.0 200 OK 635 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKfbf176ef7F1D5FA2 636 CSeq: 2 REGISTER 637 Call-ID: d3281184-518783de-cc23d6bb@ua1.example.com 638 From: ;tag=CDF9A668-909E2BDD 639 To: ;tag=1664573879820199 640 Contact: 641 Expires: 3600 642 Content-Length: 0 644 F3 to F6: Once Alice registers, Appearance Agent subscribes 645 to the events at the contact registered for Alice and Alice 646 notifies the Appearance Agent of its status. 648 F3 Appearance Agent ----> Alice 650 SUBSCRIBE sip:alice@ua1.example.com SIP/2.0 651 From: ;tag=110286377866002 652 To: 653 Call-ID: 284-425690188@example.com 654 CSeq: 2 SUBSCRIBE 655 Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1979345546866532 656 Event: dialog;ma 657 Expires: 3700 658 Contact: 659 Content-Length: 0 661 F4 Alice ----> Appearance Agent 663 SIP/2.0 200 OK 664 Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1979345546866532 665 From: ;tag=110286377866002 666 To: ;tag=717A8C26-BA734CE3 667 CSeq: 2 SUBSCRIBE 668 Call-ID: 284-425690188@example.com 669 Contact: 670 Event: dialog;ma 671 User-Agent: ABC-UA/1.2.3 672 Expires: 3700 673 Content-Length: 0 675 F5 Alice ----> Appearance Agent 677 NOTIFY sip:sa@stateagent.example.com SIP/2.0 678 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKa2269cc565A30870 679 From: ;tag=717A8C26-BA734CE3 680 To: ;tag=110286377866002 681 CSeq: 1 NOTIFY 682 Call-ID: 284-425690188@example.com 683 Contact: 684 Event: dialog;ma 685 User-Agent: ABC-UA/1.2.3 686 Subscription-State: active;expires=3698 687 Max-Forwards: 70 688 Content-Type: application/dialog-info+xml 689 Content-Length: 164 691 692 696 698 F6 Appearance Agent ----> Alice 699 SIP/2.0 200 OK 700 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKa2269cc565A30870 701 CSeq: 1 NOTIFY 702 Call-ID: 284-425690188@example.com 703 From: ;tag=717A8C26-BA734CE3 704 To: ;tag=110286377866002 705 Allow-Events: dialog;ma 706 Contact: 707 Content-Length: 0 709 F7 to F10: Alice also subscribes to the events associated with the 710 Appearance AOR. Appearance Agent also notifies Alice of the status. 712 F7 Alice ----> Appearance Agent 714 SUBSCRIBE sip:sa@stateagent.example.com SIP/2.0 715 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A 716 From: ;tag=925A3CAD-CEBB276E 717 To: 718 CSeq: 1 SUBSCRIBE 719 Call-ID: ef4704d9-bb68aa0b-474c9d94@ua1.example.com 720 Contact: 721 Event: dialog;ma 722 User-Agent: ABC-UA/1.2.3 723 Accept: application/dialog-info+xml 724 Max-Forwards: 70 725 Expires: 3700 726 Content-Length: 0 728 F8 Appearance Agent ----> Alice 730 SIP/2.0 202 Accepted 731 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A 732 CSeq: 1 SUBSCRIBE 733 Call-ID: ef4704d9-bb68aa0b-474c9d94@ua1.example.com 734 From: ;tag=925A3CAD-CEBB276E 735 To: ;tag=1636248422222257 736 Allow-Events: dialog;ma 737 Expires: 3700 738 Contact: 739 Content-Length: 0 741 F9 Appearance Agent ----> Alice 743 NOTIFY sip:alice@ua1.example.com SIP/2.0 744 From: ;tag=1636248422222257 745 To: ;tag=925A3CAD-CEBB276E 746 Call-ID: ef4704d9-bb68aa0b-474c9d94@ua1.example.com 747 CSeq: 2 NOTIFY 748 Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1846984327225734 749 Max-Forwards: 70 750 Content-Type: application/dialog-info+xml 751 Event: dialog;ma 752 Subscription-State: active 753 Contact: 754 Content-Length: 162 756 757 761 763 F10 Alice ----> Appearance Agent 765 SIP/2.0 200 OK 766 Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1846984327225734 767 From: ;tag=1636248422222257 768 To: ;tag=925A3CAD-CEBB276E 769 CSeq: 2 NOTIFY 770 Call-ID: ef4704d9-bb68aa0b-474c9d94@ua1.example.com 771 Contact: 772 Event: dialog;ma 773 User-Agent: ABC-UA/1.2.3 774 Content-Length: 0 776 6.1.2. Registration and Subscription Flow 778 Registrar Appearance Agent Bob 779 | | | 780 | | | 781 |<--------------------------- REGISTER F1<| 782 | | | 783 |>F2 200 OK ----------------------------->| 784 | | | 785 |<--------------------------- REGISTER F3<| 786 | | | 787 |>F4 200 OK ----------------------------->| 788 | | | 789 | |>F5 SUBSCRIBE ----->| 790 | | | 791 | |<-------- 200 OK F6<| 792 | | | 793 | |<-------- NOTIFY F7<| 794 | | | 795 | |>F8 200 OK -------->| 796 | | | 797 | |<----- SUBSCRIBE F9<| 798 | | | 799 | |>F10 202 Accepted ->| 800 | | | 801 | |>F11 NOTIFY ------->| 802 | | | 803 | |<------- 200 OK F12<| 804 | | | 806 F1 to F2: Bob registers his (private) AOR with contact 807 sip:bob@ua2.example.com (i.e., first-party registration). 809 F1 Bob ----> Registrar 811 REGISTER sip:registrar.example.com SIP/2.0 812 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK41599ad63A2E521F 813 From: ;tag=9F80647C-94355FE3 814 To: 815 CSeq: 2 REGISTER 816 Call-ID: e4a1e078-75ccf65a-1a4c1ee1@ua2.example.com 817 Contact: 818 User-Agent: XYZ-UA/4.5.6 819 Max-Forwards: 70 820 Expires: 3600 821 Content-Length: 0 823 F2 Registrar ----> Bob 825 SIP/2.0 200 OK 826 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK1b1c1d25FB82B2DE 827 CSeq: 2 REGISTER 828 Call-ID: e4a1e078-75ccf65a-1a4c1ee1@ua2.example.com 829 From: ;tag=9F80647C-94355FE3 830 To: ;tag=468305689550907 831 Contact: 832 Expires: 3600 833 Content-Length: 0 834 F3 to F4: Bob registers Alice AOR with his client using SIP third-party 835 registration. Note that this is considered third-party since From is 836 different from To in the REGISTER. 838 F3 Bob ----> Registrar 840 REGISTER sip:registrar.example.com SIP/2.0 841 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK5f3f2c694DF31062 842 From: ;tag=81B52F2F-7EA64EE6 843 To: 844 CSeq: 1 REGISTER 845 Call-ID: 55d48e6b-a0598cad-9ab32f84@ua2.example.com 846 Contact: 847 User-Agent: XYZ-UA/4.5.6 848 Max-Forwards: 70 849 Expires: 3600 850 Content-Length: 0 852 F4 Registrar ----> Bob 854 SIP/2.0 200 OK 855 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKdf17f688391F7DF1 856 CSeq: 2 REGISTER 857 Call-ID: 55d48e6b-a0598cad-9ab32f84@ua2.example.com 858 From: ;tag=81B52F2F-7EA64EE6 859 To: ;tag=773736136499990 860 Contact: 861 Expires: 3600 862 Content-Length: 0 864 F5 to F10: Once Bob registers with Alice AOR, Appearance Agent 865 subscribes to the events at the contact registered for Alice 866 and Bob notifies the Appearance Agent of its status. These 867 messages are not shown as they are essentially identical to 868 the previous call flow. 870 6.2. Call Originated within the Appearance Group 872 In this scenario, the UA just before allowing the user to place a 873 call, sends out a dialog event NOTIFY with state (trying). Only 874 after receiving the 200 OK does the UA procede with the call and send 875 the INVITE. 877 In the following call flow, Bob, as a member of the Alice BLA group, 878 places an outgoing call to Carol using Alice line appearance. Bob 879 then places Carol on hold. Alice subsequently picks up the held call 880 and has a established session with Carol. Finally, Carol hangs up. 881 The details of the notifications amongst the user agents and the 882 Appearance Agent in updating the status of the BLA group members are 883 shown below. For brevity, details of some of the messages are not 884 included in the message flows. 886 Carol Proxy Alice Appearance Agent Bob 887 | | | | | 888 | | | |<------ NOTIFY F1<| 889 | | | | | 890 | | | |>F2 200 OK ------>| 891 | | | | | 892 | | |<-- NOTIFY F3<| | 893 | | | | | 894 | | |>F4 200 OK -->| | 895 | | | | | 896 | |<------------------------------------- INVITE F5<| 897 | | | | | 898 |<-- INVITE F6<| | | | 899 | | | | | 900 |>F7 180 Ring >| | | | 901 | |>F8 180 Ringing -------------------------------->| 902 |>F9 200 OK -->| | | | 903 | |>F10 200 OK ------------------------------------>| 904 | | | | | 905 |<------------------------------------------------------ ACK F11<| 906 | | | | | 907 |<================= Both way RTP established ===================>| 908 | | | | | 909 | | | |<----- NOTIFY F12<| 910 | | | | | 911 | | | |>F13 200 OK ----->| 912 | | |<- NOTIFY F14<| | 913 | | | | | 914 | | |>F15 200 OK ->| | 915 | | | | | 916 | |<------------------------------(hold) INVITE F16<| 917 |<- INVITE F17<| | | | 918 | | | | | 919 |>F18 200 OK ->| | | | 920 | |>F19 200 OK ------------------------------------>| 921 | | | | | 922 |<------------------------------------------------------ ACK F20<| 923 | | | | | 924 | | | |<----- NOTIFY F21<| 925 | | | | | 926 | | | |>F22 200 OK ----->| 927 | | |<- NOTIFY F23<| | 928 | | | | | 929 | | |>F24 200 OK ->| | 930 | |<-- INVITE F25<| | | 931 |<- INVITE F26<|(w/ Replaces) | | | 932 |( w/ Replaces)| | | | 933 |>F27 200 OK ->| | | | 934 | |>F28 200 OK -->| | | 935 | | | | | 936 |<-------------------- ACK F29<| | | 937 | | | | | 938 |<= Both way RTP established =>| | | 939 | | | | | 940 |>F30 BYE ---->| | | | 941 | |>F31 BYE --------------------------------------->| 942 | | | | | 943 | |<------------------------------------ OK 200 F32<| 944 |<- 200 OK F33<| | | | 945 | | | | | 946 | | | |<----- NOTIFY F34<| 947 | | | | | 948 | | | |>F35 200 OK ----->| 949 | | |<- NOTIFY F36<| | 950 | | | | | 951 | | |>F37 200 OK ->| | 952 | | | | | 953 | | |>F38 NOTIFY ->| | 954 | | | | | 955 | | |<- 200 OK F39<| | 956 | | | |>F40 NOTIFY ----->| 957 | | | | | 958 | | | |<----- 200 OK F41<| 959 |>F42 BYE ---->| | | | 960 | |>F43 BYE ----->| | | 961 | | | | | 962 | |<-- 200 OK F44<| | | 963 |<--200 OK F45<| | | | 964 | | |>F46 NOTIFY ->| | 965 | | | | | 966 | | |<- 200 OK F47<| | 967 | | | |>F48 NOTIFY ----->| 968 | | | | | 969 | | | |<----- OK 200 F49<| 971 F1 to F4: Bob uses the BLA appearance of Alice on his UA to place an 972 outgoing call (e.g., he goes off-hook). Before sending the outgoing 973 INVITE request, Bob notifies the sate agent that Alice line 974 appearance is in (trying) state. Appearance Agent notifies Alice of 975 the same event by forwarding the NOTIFY payload provided by Bob after 976 appropriately changing the dialog id field in the XML payload to a 977 unique value towards each of the entities it is forwarding to (Alice 978 in this example). 980 F1 Bob ----> Appearance Agent 982 NOTIFY sip:sa@stateagent.example.com SIP/2.0 983 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 984 From: ;tag=44150CC6-A7B7919D 985 To: ;tag=428765950880801 986 CSeq: 7 NOTIFY 987 Call-ID: 144-1289338424@example.com 988 Contact: 989 Event: dialog;ma 990 User-Agent: XYZ-UA/4.5.6 991 Subscription-State: active;expires=3347 992 Max-Forwards: 70 993 Content-Type: application/dialog-info+xml 994 Content-Length: 365 996 997 1001 1002 trying 1003 1004 1005 1006 1007 1008 1009 1011 F2 Appearance Agent ----> Bob 1013 SIP/2.0 200 OK 1014 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 1015 CSeq: 7 NOTIFY 1016 Call-ID: 144-1289338424@example.com 1017 From: ;tag=44150CC6-A7B7919D 1018 To: ;tag=428765950880801 1019 Allow-Events: dialog;ma 1020 Contact: 1021 Content-Length: 0 1023 F3 Appearance Agent ----> Alice 1025 NOTIFY sip:alice@ua1.example.com SIP/2.0 1026 From: ;tag=497585728578386 1027 To: ;tag=633618CF-B9C2EDA4 1028 Call-ID: a7d559db-d6d7dcad-311c9e3a@ua1.example.com 1029 CSeq: 7 NOTIFY 1030 Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1711759878512309 1031 Max-Forwards: 70 1032 Content-Type: application/dialog-info+xml 1033 Event: dialog;ma 1034 Subscription-State: active 1035 Contact: 1036 Content-Length: 402 1038 1039 1043 1045 trying 1046 1047 1048 1049 1050 1051 1052 1054 F4 Alice ----> Appearance Agent 1056 SIP/2.0 200 OK 1057 Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1711759878512309 1058 From: ;tag=497585728578386 1059 To: ;tag=633618CF-B9C2EDA4 1060 CSeq: 7 NOTIFY 1061 Call-ID: a7d559db-d6d7dcad-311c9e3a@ua1.example.com 1062 Contact: 1063 Event: dialog;ma 1064 User-Agent: ABC-UA/1.2.3 1065 Content-Length: 0 1066 F5 to F11: Bob places a call to Carol by sending the INVITE request 1067 towards the Proxy. The INVITE (see F5 message below) includes a 1068 P-Preferred-Identity header [10] to designate the identity to be 1069 used as the calling party for this call (i.e., Alice instead of Bob). 1071 F5 Bob ----> Proxy 1073 INVITE sip:carol@example.com SIP/2.0 1074 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK98c87c52123A08BF 1075 From: ;tag=15A3DE7C-9283203B 1076 To: 1077 CSeq: 1 INVITE 1078 Call-ID: f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com 1079 Contact: 1080 User-Agent: XYZ-UA/4.5.6 1081 P-Preferred-Identity: 1082 Max-Forwards: 70 1083 Content-Type: application/sdp 1084 Content-Length: 223 1086 v=0 1087 o=- 1102980499 1102980499 IN IP4 ua2.example.com 1088 s=IP SIP UA 1089 c=IN IP4 ua2.example.com 1090 t=0 0 1091 a=sendrecv 1092 m=audio 2236 RTP/AVP 0 8 101 1093 a=rtpmap:0 PCMU/8000 1094 a=rtpmap:8 PCMA/8000 1095 a=rtpmap:101 telephone-event/8000 1097 F12 to F15: Bob notifies the Appearance Agent of the status of the 1098 dialog (i.e., confirmed). Appearance Agent notifies Alice of the 1099 same. 1101 F12 Bob ----> Appearance Agent 1103 NOTIFY sip:sa@stateagent.example.com SIP/2.0 1104 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa39d3f69D4E20602 1105 From: ;tag=44150CC6-A7B7919D 1106 To: ;tag=428765950880801 1107 CSeq: 9 NOTIFY 1108 Call-ID: 144-1289338424@example.com 1109 Contact: 1110 Event: dialog;ma 1111 User-Agent: XYZ-UA/4.5.6 1112 Subscription-State: active;expires=3342 1113 Max-Forwards: 70 1114 Content-Type: application/dialog-info+xml 1115 Content-Length: 675 1117 1118 1122 1127 confirmed 1128 1129 1130 1131 1132 1133 1134 1135 sip:carol@example.com 1136 1137 1138 1139 1141 F16 to F20: Bob places Carol on hold. 1143 F22 to F24: Bob notifies Appearance Agent of the status of the dialog to 1144 indicate the held state. It indicates this by setting the sip.rendering 1145 parameter in the NOTIFY payload to (no). Appearance Agent notifies 1146 Alice of the same. 1148 F22 Bob ----> Appearance Agent 1150 NOTIFY sip:sa@stateagent.example.com SIP/2.0 1151 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK6c78a6c5CA00520E 1152 From: ;tag=44150CC6-A7B7919D 1153 To: ;tag=428765950880801 1154 CSeq: 10 NOTIFY 1155 Call-ID: 144-1289338424@example.com 1156 Contact: 1157 Event: dialog;ma 1158 User-Agent: XYZ-UA/4.5.6 1159 Subscription-State: active;expires=3338 1160 Max-Forwards: 70 1161 Content-Type: application/dialog-info+xml 1162 Content-Length: 942 1164 1165 1169 1174 confirmed 1175 1176 1177 1178 1179 1180 1181 1182 sip:carol@example.com 1183 1184 1185 1186 1188 F26 to F34 : Alice picks up the held call by sending an INVITE with 1189 Replaces: header (F26). Session is established between Alice and 1190 Carol. The dialog between Carol and Bob is terminated. 1192 F26 Alice ----> Proxy 1194 INVITE sip:carol@example.com SIP/2.0 1195 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK4ea695b5B376A60C 1196 From: ;tag=8C4183CB-BCEAB710 1197 To: 1198 CSeq: 1 INVITE 1199 Call-ID: 3d57cd17-47deb849-dca8b6c6@ua1.example.com 1200 Contact: 1201 User-Agent: ABC-UA/1.2.3 1202 P-Preferred-Identity: 1203 1204 Replaces: f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com;to-tag=65a98f7c 1205 -1dd2-11b2-88c6-b03162323164+65a98f7c;from-tag=15A3DE7C-9283203B 1206 1207 Max-Forwards: 70 1208 Content-Type: application/sdp 1209 Content-Length: 223 1211 v=0 1212 o=- 1102980497 1102980497 IN IP4 ua1.example.com 1213 s=IP SIP UA 1214 c=IN IP4 ua1.example.com 1215 t=0 0 1216 a=sendrecv 1217 m=audio 2238 RTP/AVP 0 8 101 1218 a=rtpmap:0 PCMU/8000 1219 a=rtpmap:8 PCMA/8000 1220 a=rtpmap:101 telephone-event/8000 1222 F34 to F41: Bob notifies the Appearance Agent of the termination of 1223 dialog at his UA. Alice notifies the Appearance Agent of the 1224 confirmed state of the dialog at her UA. 1226 F34 Bob ----> Appearance Agent 1228 NOTIFY sip:sa@stateagent.example.com SIP/2.0 1229 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A 1230 From: ;tag=44150CC6-A7B7919D 1231 To: "State_Agent" ;tag=428765950880801 1232 CSeq: 11 NOTIFY 1233 Call-ID: 144-1289338424@example.com 1234 Contact: 1235 Event: dialog;ma 1236 User-Agent: XYZ-UA/4.5.6 1237 Subscription-State: active;expires=3334 1238 Max-Forwards: 70 1239 Content-Type: application/dialog-info+xml 1240 Content-Length: 677 1242 1243 1247 1252 terminated 1253 1254 1255 1256 1257 1258 1259 sip:carol@example.com 1260 1261 1262 1263 1265 F38 Alice ----> Appearance Agent 1267 NOTIFY sip:sa@stateagent.example.com SIP/2.0 1268 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK93f44af3518A1572 1269 From: ;tag=5861255C-14C04045 1270 To: "State_Agent" ;tag=920163082722420 1271 CSeq: 10 NOTIFY 1272 Call-ID: 143-1840952798@example.com 1273 Contact: 1274 Event: dialog;ma 1275 User-Agent: ABC-UA/1.2.3 1276 Subscription-State: active;expires=3315 1277 Max-Forwards: 70 1278 Content-Type: application/dialog-info+xml 1279 Content-Length: 640 1281 1282 1286 1291 confirmed 1292 1293 1294 1295 1296 1298 1299 1300 sip:carol@example.com 1301 1302 1303 1304 1306 F42 to F59: Carol terminates the dialog with Alice. Alice notifies the 1307 Appearance Agent of the dialog state (terminated). The Appearance Agent 1308 notifies Bob of the same. 1310 F46 Alice ----> Appearance Agent 1312 NOTIFY sip:sa@stateagent.example.com SIP/2.0 1313 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKa46c2f85F29F839C 1314 From: ;tag=5861255C-14C04045 1315 To: "State_Agent" ;tag=920163082722420 1316 CSeq: 11 NOTIFY 1317 Call-ID: 143-1840952798@example.com 1318 Contact: 1319 Event: dialog;ma 1320 User-Agent: ABC-UA/1.2.3 1321 Subscription-State: active;expires=3311 1322 Max-Forwards: 70 1323 Content-Type: application/dialog-info+xml 1324 Content-Length: 642 1326 1327 1331 1336 terminated 1337 1338 1339 1340 1341 1342 1343 sip:carol@example.com 1344 1346 1347 1348 1350 6.3. Call Offered to an Appearance Group 1352 In the call flow below Bob has bridged appearance of Alice. Carol 1353 places a call to Alice. Both Alice and Bob's devices are alerted of 1354 the incoming call. Bob answers the call. He then places Carol on 1355 hold. Alice picks up the held call and has a established session 1356 with Carol. Finally, Carol terminates the session. All NOTIFY 1357 messages in the call flow below carry dialog events and only dialog 1358 states are mentioned for simplicity. For brevity, the details of 1359 some messages are not shown below. 1361 Carol Forking Proxy Appearance Agent Alice Bob 1362 | | | | | 1363 |>F1 INVITE >| | | | 1364 | |>F2 INVITE ------------------------->| 1365 | | | | | 1366 | |>F3 INVITE --------------->| | 1367 | | | | | 1368 |<-100Try F4<| | | | 1369 | | | | | 1370 | |<-------------------- Ringing 180 F5<| 1371 |<180Ring F6<| | | | 1372 | |<---------- Ringing 180 F7<| | 1373 |<180Ring F8<| | | | 1374 | |<------------------------- 200 OK F9<| 1375 |<-200OK F10<| | | | 1376 | | | | | 1377 | |>F11 CANCEL -------------->| | 1378 | | | | | 1379 | |<-------------- 200 OK F12<| | 1380 | | | | | 1381 | |F14 ACK ----------------->| | 1384 |>F15 ACK -->| | | | 1385 | |>F16 ACK --------------------------->| 1386 | | | | | 1387 |<=============Both way RTP established===========>| 1388 | | | | | 1389 | | |<---------- NOTIFY F17<| 1390 | | | | | 1391 | | |>F18 200 OK ---------->| 1392 | | | | | 1393 | | |>F19 NOTIFY >| | 1394 | | | | | 1395 | | |<- 200OK F20<| | 1396 | | | | | 1397 | |<----------------("Hold") INVITE F21<| 1398 |F23 200OK->| | | | 1401 | |>F24 200 OK ------------------------>| 1402 | | | | | 1403 | |<--------------------------- ACK F25<| 1404 |<-- ACK F26<| | | | 1405 | | |<---------- NOTIFY F27<| 1406 | | | | | 1407 | | |>F28 200 OK ---------->| 1408 | | | | | 1409 | | |>F29 NOTIFY >| | 1410 | | | | | 1411 | | |<- 200OK F30<| | 1412 | | | | | 1413 | |< INVITE (w/ Replaces) F31<| | 1414 |F33 200 OK>| | | | 1417 | |>F34 200 OK -------------->| | 1418 | | | | | 1419 | |<----------------- ACK F35<| | 1420 |<-- ACK F36<| | | | 1421 | | | | | 1422 |<=======Both way RTP established=======>| | 1423 | | | | | 1424 |>F37 BYE -->| | | | 1425 | |>F38 BYE --------------------------->| 1426 | | | | | 1427 | |<------------------------ OK 200 F39<| 1428 |<-200OK F40<| | | | 1429 | | |<---------- NOTIFY F41<| 1430 | | | | | 1431 | | |>F42 200 OK ---------->| 1432 | | | | | 1433 | | |>F43 NOTIFY >| | 1434 | | | | | 1435 | | |<-200 OK F44<| | 1436 | | | | | 1437 | | |<-NOTIFY F45<| | 1438 | | | | | 1439 | | |>F46 200 OK->| | 1440 | | | | | 1441 | | |>F47 NOTIFY ---------->| 1442 | | | | | 1443 | | |<---------- 200 OK F48<| 1444 |>49 BYE --->| | | | 1445 | |>F50 BYE ----------------->| | 1446 | | | | | 1447 | |<-------------- OK 200 F51<| | 1448 |<-200OK F52<| | | | 1449 | | |< NOTIFY F53<| | 1450 | | | | | 1451 | | |>F54 200 OK >| | 1452 | | | | | 1453 | | |>F55 NOTIFY ---------->| 1454 | | | | | 1455 | | |<---------- 200 OK F56<| 1456 | | | | | 1458 F1 to F16: An incoming call from Carol to Alice is forked to 1459 Bob and Alice. Both Alice and Bob indicate an incoming call 1460 (e.g., ringing) from Carol. Bob answers the call and two-way 1461 media is established between Carol and Bob. 1463 F2 Proxy ----> Bob 1465 INVITE sip:alice@ua3.example.com SIP/2.0 1466 Via: SIP/2.0/UDP ua3.example.com;branch=z9hG4bK4324ea695b5B376A 1467 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK38432ji 1468 From: ;tag=94183CB-BCEAB7 1469 To: 1470 CSeq: 106 INVITE 1471 Call-ID: 47deb849-dca8b6c6-3d342 1472 Contact: 1473 Max-Forwards: 69 1474 Alert-Info: ;alert=normal;appearance=0 1475 Content-Type: application/sdp 1476 Content-Length: 223 1478 v=0 1479 o=- 1102980499 1102980499 IN IP4 ua3.example.com 1480 s= 1481 c=IN IP4 ua3.example.com 1482 t=0 0 1483 a=sendrecv 1484 m=audio 2238 RTP/AVP 0 8 101 1485 a=rtpmap:0 PCMU/8000 1486 a=rtpmap:8 PCMA/8000 1487 a=rtpmap:101 telephone-event/8000 1489 F3 Proxy ----> Alice 1491 INVITE sip:alice@ua1.example.com SIP/2.0 1492 Via: SIP/2.0/UDP ua3.example.com;branch=z9hG4bK4324ea695b5B376A 1493 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK348281 1494 From: ;tag=94183CB-BCEAB7 1495 To: 1496 CSeq: 106 INVITE 1497 Call-ID: 47deb849-dca8b6c6-3d342 1498 Contact: 1499 Max-Forwards: 69 1500 Alert-Info: ;alert=normal;appearance=0 1501 Content-Type: application/sdp 1502 Content-Length: 223 1504 v=0 1505 o=- 1102980499 1102980499 IN IP4 ua3.example.com 1506 s= 1507 c=IN IP4 ua3.example.com 1508 t=0 0 1509 a=sendrecv 1510 m=audio 2238 RTP/AVP 0 8 101 1511 a=rtpmap:0 PCMU/8000 1512 a=rtpmap:8 PCMA/8000 1513 a=rtpmap:101 telephone-event/8000 1515 F17 - F20: Bob notifies the Appearance Agent with dialog state 1516 payload indicating the dialog in confirmed state. Appearance 1517 Agent notifies Alice of the status of the dialog at Bob. 1519 F17 Bob ----> Appearance Agent 1521 NOTIFY sip:sa@stateagent.example.com SIP/2.0 1522 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK58a0dd68C2D63263 1523 From: ;tag=558C18F7-DB9DF7BC 1524 To: ;tag=1894685100249086 1525 CSeq: 14 NOTIFY 1526 Call-ID: 77-505889516@example.com 1527 Contact: 1528 Event: dialog;ma 1529 User-Agent: XYZ-UA/4.5.6 1530 Subscription-State: active;expires=3427 1531 Max-Forwards: 70 1532 Content-Type: application/dialog-info+xml 1533 Content-Length: 575 1535 1536 1540 1545 confirmed 1546 1547 1548 1549 1550 1551 1552 1553 sip:carol@ua.example.com 1554 1555 1556 1558 F19 Appearance Agent ----> Alice 1560 NOTIFY sip:alice@ua1.example.com SIP/2.0 1561 From: ;tag=151702541050937 1562 To: ;tag=18433323-C3D237CE 1563 Call-ID: 1e361d2f-a9f51109-bafe31d4@ua1.example.com 1564 CSeq: 12 NOTIFY 1565 Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK14031499568413 1566 Max-Forwards: 70 1567 Content-Type: application/dialog-info+xml 1568 Event: dialog;ma 1569 Subscription-State: active 1570 Contact: 1571 Content-Length: 618 1573 1574 1578 1583 confirmed 1584 1585 1586 1587 1588 1589 1590 1591 sip:carol@ua.example.com 1592 1593 1594 1596 F21 to F26: Bob places Carol on hold. 1598 F27 to F30: Bob notifies the Appearance Agent of the status 1599 of the dialog on hold with inclusion of the session description 1600 in the NOTIFY payload. Subsequently, Appearance Agent notifies 1601 Alice of the status of dialog. 1603 F31 to F40: Alice picks up the held call by sending an INVITE 1604 with Replaces: header populated with the dialog data received 1605 in the NOTIFY from the Appearance Agent. Carol establishes a 1606 session with Alice and terminates the dialog with Bob. 1608 F31 Alice ----> Proxy 1610 INVITE sip:carol@ua.example.com SIP/2.0 1611 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKcc9d727c2C29BE31 1612 From: ;tag=605AD957-1F6305C2 1613 To: 1614 CSeq: 2 INVITE 1615 Call-ID: dc95da63-60db1abd-d5a74b48@ua1.example.com 1616 Contact: 1617 User-Agent: ABC-UA/1.2.3 1618 P-Preferred-Identity: 1619 1620 Replaces: 14-1541707345@example.com;to-tag=d3b06488-1dd1-11b2 1621 -88c5-b03162323164+d3e48f4c;from-tag=44BAD75D-E3128D42 1622 1623 Max-Forwards: 70 1624 Content-Type: application/sdp 1625 Content-Length: 223 1626 v=0 1627 o=- 1103061265 1103061265 IN IP4 ua1.example.com 1628 s=IP SIP UA 1629 c=IN IP4 ua1.example.com 1630 t=0 0 1631 a=sendrecv 1632 m=audio 2236 RTP/AVP 0 8 101 1633 a=rtpmap:0 PCMU/8000 1634 a=rtpmap:8 PCMA/8000 1635 a=rtpmap:101 telephone-event/8000 1637 F41 to F48: Bob notifies the Appearance Agent of the termination 1638 of the dialog and Appearance Agent notifies the same to Alice. 1639 Alice notifies the Appearance Agent of the confirmed state of 1640 dialog at Alice and Appearance Agent informs Bob of the same. 1642 F49 to F52: Carol terminates dialog with Alice. 1644 F53 to F56: Alice notifies the Appearance Agent of the termination 1645 of the dialog and Appearance Agent notifies Bob of the same. 1647 6.4. Use of PUBLISH 1649 This call flow shows the use of PUBLISH instead of SUBSCRIBE/NOTIFY 1650 between the members of the appearance group and the Appearance Agent. 1652 Carol Proxy Alice Appearance Agent Bob 1653 | | | | | 1654 | | | |<----- PUBLISH F1<| 1655 | | | | | 1656 | | | |>F2 200 OK ------>| 1657 | | | | | 1658 | | |<-- NOTIFY F3<| | 1659 | | | | | 1660 | | |>F4 200 OK -->| | 1661 | | | | | 1662 | |<------------------------------------- INVITE F5<| 1663 | | | | | 1664 |<-- INVITE F6<| | | | 1665 | | | | | 1666 |>F7 180 Ring >| | | | 1667 | |>F8 180 Ringing -------------------------------->| 1668 |>F9 200 OK -->| | | | 1669 | |>F10 200 OK ------------------------------------>| 1670 | | | | | 1671 |<------------------------------------------------------ ACK F11<| 1672 | | | | | 1673 |<================= Both way RTP established ===================>| 1674 | | | | | 1675 | | | |<---- PUBLISH F12<| 1676 | | | | | 1677 | | | |>F13 200 OK ----->| 1678 | | |<- NOTIFY F14<| | 1679 | | | | | 1680 | | |>F15 200 OK ->| | 1681 | | | | | 1682 | |<------------------------------(hold) INVITE F16<| 1683 |<- INVITE F17<| | | | 1684 | | | | | 1685 |>F18 200 OK ->| | | | 1686 | |>F19 200 OK ------------------------------------>| 1687 | | | | | 1688 |<------------------------------------------------------ ACK F20<| 1689 | | | | | 1690 | | | |<---- PUBLISH F21<| 1691 | | | | | 1692 | | | |>F22 200 OK ----->| 1693 | | |<- NOTIFY F23<| | 1694 | | | | | 1695 | | |>F24 200 OK ->| | 1696 | |<-- INVITE F25<| | | 1697 |<- INVITE F26<|(w/ Replaces) | | | 1698 |( w/ Replaces)| | | | 1699 |>F27 200 OK ->| | | | 1700 | |>F28 200 OK -->| | | 1701 | | | | | 1702 |<-------------------- ACK F29<| | | 1703 | | | | | 1704 |<= Both way RTP established =>| | | 1705 | | | | | 1706 |>F30 BYE ---->| | | | 1707 | |>F31 BYE --------------------------------------->| 1708 | | | | | 1709 | |<------------------------------------ OK 200 F32<| 1710 |<- 200 OK F33<| | | | 1711 | | | | | 1712 | | | |<---- PUBLISH F34<| 1713 | | | | | 1714 | | | |>F35 200 OK ----->| 1715 | | |<- NOTIFY F36<| | 1716 | | | | | 1717 | | |>F37 200 OK ->| | 1718 | | | | | 1719 | | |>F38 PUBLISH >| | 1720 | | | | | 1721 | | |<- 200 OK F39<| | 1722 | | | |>F40 NOTIFY ----->| 1723 | | | | | 1724 | | | |<----- 200 OK F41<| 1725 |>F42 BYE ---->| | | | 1726 | |>F43 BYE ----->| | | 1727 | | | | | 1728 | |<-- 200 OK F44<| | | 1729 |<--200 OK F45<| | | | 1730 | | |>F46 PUBLISH >| | 1731 | | | | | 1732 | | |<- 200 OK F47<| | 1733 | | | |>F48 NOTIFY ----->| 1734 | | | | | 1735 | | | |<----- OK 200 F49<| 1737 6.5. Bridging on an Appearance 1739 In this call flow, a call answered by Bob is joined by Alice or 1740 "bridged". The Join header field is used by Alice to request this 1741 bridging. If Bob did not support media mixing, Bob could obtain 1742 conferencing resources as described in [12]. 1744 Carol Forking Proxy Appearance Agent Alice Bob 1745 | | | | | 1746 |>F1 INVITE >| | | | 1747 | |>F2 INVITE ------------------------->| 1748 | | | | | 1749 | |>F3 INVITE --------------->| | 1750 | | | | | 1751 |<-100Try F4<| | | | 1752 | | | | | 1753 | |<-------------------- Ringing 180 F5<| 1754 |<180Ring F6<| | | | 1755 | |<---------- Ringing 180 F7<| | 1756 |<180Ring F8<| | | | 1757 | |<------------------------- 200 OK F9<| 1758 |<-200OK F10<| | | | 1759 | | | | | 1760 | |>F11 CANCEL -------------->| | 1761 | | | | | 1762 | |<-------------- 200 OK F12<| | 1763 | | | | | 1764 | |F14 ACK ----------------->| | 1767 |>F15 ACK -->| | | | 1768 | |>F16 ACK --------------------------->| 1769 | | | | | 1770 |<=============Both way RTP established===========>| 1771 | | | | | 1772 | | |<---------- NOTIFY F17<| 1773 | | | | | 1774 | | |>F18 200 OK ---------->| 1775 | | | | | 1776 | | |>F19 NOTIFY >| | 1777 | | | | | 1778 | | |<- 200OK F20<| | 1779 | | | | | 1780 | |<---- INVITE (w/ Join) F21<| | 1781 | | | | | 1782 | |>F22 INVITE (w/Join)---------------->| 1783 | | | | | 1784 | |<---- OK 200 Contact:Bob;isfocus F23<| 1785 | | | | | 1786 | |>F24 200 OK Contact:Bob;isfocus----->| 1787 | | | | | 1788 | |<----------------- ACK F25<| | 1789 | | | | | 1790 | |>ACK F26---------------------------->| 1791 | | | | | 1792 | |<-----INVITE Contact:Bob;isfocus F27<| 1793 |<-INVITE F28| | | | 1794 |>F29 200 -->| | | | 1795 | |>F30 200 OK ------------------------>| 1796 | | | | | 1797 | |<--------------------------- ACK F31<| 1798 |<--- ACK F32| | | | 1799 | | | |<==RTP==>| 1800 |<=============Both way RTP established===========>| 1802 F21 Alice ----> Proxy 1804 INVITE sip:bob@ua.example.com SIP/2.0 1805 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKcc9d727c2C29BE31 1806 From: ;tag=605AD957-1F6305C2 1807 To: 1808 CSeq: 2 INVITE 1809 Call-ID: dc95da63-60db1abd-d5a74b48@ua1.example.com 1810 Contact: 1811 User-Agent: ABC-UA/1.2.3 1812 P-Preferred-Identity: 1813 1814 Join: 14-1541707345@example.com;to-tag=d3b06488-1dd1-11b2-88c5 1815 -b03162323164+d3e48f4c;from-tag=44BAD75D-E3128D42 1816 1817 Max-Forwards: 70 1818 Content-Type: application/sdp 1819 Content-Length: 223 1821 v=0 1822 o=- 1103061265 1103061265 IN IP4 ua1.example.com 1823 s=IP SIP UA 1824 c=IN IP4 ua1.example.com 1825 t=0 0 1826 a=sendrecv 1827 m=audio 2236 RTP/AVP 0 8 101 1828 a=rtpmap:0 PCMU/8000 1829 a=rtpmap:8 PCMA/8000 1830 a=rtpmap:101 telephone-event/8000 1832 6.6. State and Error Recovery Examples 1834 6.6.1. Line Seize (Refresh Subscription) 1836 UA - Called Appearance Agent UA - Calling 1837 | | | 1838 | | F1: NOTIFY (trying)| 1839 | |<-------------------| 1840 | | F2: 200 OK | 1841 | |------------------->| 1842 | F3: INVITE/180 Ring/200 OK/ACK | 1843 |<-------------------+--------------------| 1844 | | F4: SUBSCRIBE | 1845 | |------------------->| 1846 | | F5: 200 OK | 1847 | |<-------------------| 1848 | | F6: NOTIFY(confirm)| 1849 | |<-------------------| 1850 | | F7: 200 OK | 1851 | |------------------->| 1852 | | | 1854 This figure shows UA seizing a bridged line (F1 and F2) from the 1855 Appearance Agent. Appearance Agent refreshes its subscription to UA 1856 (F4-F7) ensuring continuity of service (whilst also verifying User 1857 agents shared line service). UA should maintain a policy of 1858 shortened expires periods so long as it holds a line seize 1859 (throughout the period of a call). Subscription refreshes will 1860 therefore continue to use a shortened expires period. Although UA 1861 will determine the expiration period of subscriptions to it, the 1862 Appearance Agent may choose to refresh subscriptions on a more 1863 regular basis as an extra means of ensuring continuity of shared line 1864 service. 1866 6.6.2. Line Seize (Notifier Failure) 1868 UA Appearance Agent UA1 UA2 1869 | | | | 1870 | | F1: NOTIFY (trying) | 1871 | |<---------------| | 1872 | | F2: 200 OK | | 1873 | |--------------->| | 1874 | | F3: NOTIFY (trying) | 1875 | |----------------+--------------->| 1876 | | F4: 200 OK | | 1877 | |<---------------+----------------| 1878 | F5: INVITE | | | 1879 |<--------------------------------| | 1880 | F6: 180 Ringing| | | 1881 |-------------------------------->| | 1882 | | | | 1883 | | End | 1884 | | | 1885 | | | 1886 | | F7: SUBSCRIBE x 6 retries | 1887 | |---------------> | 1888 | | | 1889 | | F8: NOTIFY (terminated) | 1890 | |-------------------------------->| 1891 | | F9: 200 OK | 1892 | |<--------------------------------| 1893 | | | 1895 The flow shown in this figure illustrates the failure of a user agent 1896 after it has obtained a line seize (F1-F2). Messages used to refresh 1897 the subscription from Appearance Agent to UA1 are shown at F7. The 1898 discontinuation of the bridged line service within user agent UA1 is 1899 shown by the abrupt termination of the UA1 vertical time line. When 1900 the Appearance Agent attempts to refresh its subscription and no 1901 response is received, indicating the shared line service maintained 1902 by UA1 has failed. Appearance Agent should at this point free the 1903 seize lock held by UA1 and issue NOTIFY messages (F8) indicating the 1904 termination of the dialog associated with the shared line. 1906 6.6.3. Line Seize (Race Condition) 1908 UA Appearance Agent UA1 UA2 1909 | | | | 1910 | | F1: NOTIFY (trying) | 1911 | |<---------------| | 1912 | | F2: NOTIFY (trying) | 1913 | |<---------------+----------------| 1914 | | F03: 200 OK | | 1915 | |--------------->| | 1916 | | F4: 500 | | 1917 | |----------------+--------------->| 1918 | | F5 : NOTIFY (trying) | 1919 | |----------------+--------------->| 1920 | | F6: 200 OK | | 1921 | |<---------------+----------------| 1922 | F09: INVITE | | | 1923 |<---------------+----------------| | 1924 | | | | 1926 This figure illustrates two user agents, UA1 and UA2, attempting to 1927 seize the same bridged line simultaneously. This type of race 1928 condition is often referred as a glare condition. Appearance Agent 1929 provides only one of UA1 and UA2 with the initiator's line seize (UA1 1930 in this case) and may choose any policy deemed appropriate to resolve 1931 the race. 1933 7. IANA Considerations 1935 This section registers the SIP Alert-Info header field parameter 1936 "appearance" and the XML namespace extensions to the SIP Dialog 1937 Package. 1939 The namespace URIs for the elements defined by this specification are 1940 URNs [RFC 4211], using the namespace identifier 'ietf' defined by [4] 1941 and extended by [6]: 1943 urn:ietf:params:xml:ns:dialog-info:ma 1945 This specification also defines a new event parameter "ma" for the 1946 Dialog Package. 1948 8. Security Considerations 1950 Since many of these features are implemented using semantics provided 1951 by RFC 3261 [2], Event Package for Dialog State as define in [7], and 1952 Event Notification [4], security considerations in these documents 1953 apply to this draft as well. 1955 Specifically, since dialog state information and the dialog 1956 identifiers are supplied by UA's in an appearance group to other 1957 members, the same is prone to "call hijacks". For example, a rogue 1958 UA could snoop for these identifiers and send an INVITE with Replaces 1959 header containing these call details to take over the call. As such 1960 INVITES with Replaces header MUST be authenticated using the standard 1961 mechanism (like Digest or S/MIME) described in RFC 3261 [2] before it 1962 is accepted. NOTIFY message bodies that provide the dialog state 1963 information and the dialog identifiers MAY be encrypted end-to-end 1964 using the standard mechanics. All SUBSCRIBES between the UA's and 1965 the Event Agent MUST be authenticated. 1967 9. Acknowledgements 1969 The authors would like to thank Kent Fritz, John Weald, and Sunil 1970 Veluvali of Sylantro Systems, Steve Towlson, and Michael Procter of 1971 Citel Technologies, Rob Harder and Hong Chen of Polycom Inc, John 1972 Elwell, J D Smith of Siemens Communications, Dale R. Worley of 1973 Pingtel, and Graeme Dollar of Yahoo Inc, for their numerous 1974 corrections, comments and suggestions during authoring of this draft. 1976 10. Normative References 1978 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1979 Levels", BCP 14, RFC 2119, March 1997. 1981 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1982 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1983 Session Initiation Protocol", RFC 3261, June 2002. 1985 [3] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1986 Method", RFC 3515, April 2003. 1988 [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1989 Notification", RFC 3265, June 2002. 1991 [5] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 1992 Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. 1994 [6] Johnston, A., "Session Initiation Protocol Service Examples", 1995 draft-ietf-sipping-service-examples-12 (work in progress), 1996 January 2007. 1998 [7] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- 1999 Initiated Dialog Event Package for the Session Initiation 2000 Protocol (SIP)", RFC 4235, November 2005. 2002 [8] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 2003 Package for Registrations", RFC 3680, March 2004. 2005 [9] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 2006 Session Description Protocol (SDP)", RFC 3264, June 2002. 2008 [10] Jennings, C., Peterson, J., and M. Watson, "Private Extensions 2009 to the Session Initiation Protocol (SIP) for Asserted Identity 2010 within Trusted Networks", RFC 3325, November 2002. 2012 [11] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) 2013 "Join" Header", RFC 3911, October 2004. 2015 [12] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) 2016 Call Control - Conferencing for User Agents", BCP 119, 2017 RFC 4579, August 2006. 2019 [13] Johnston, A., "Requirements and Implementation Options for the 2020 Multiple Line Appearance Feature using the Session Initiation 2021 Protocol (SIP)", draft-johnston-bliss-mla-req-00 (work in 2022 progress), February 2007. 2024 [14] Niemi, A., "Session Initiation Protocol (SIP) Extension for 2025 Event State Publication", RFC 3903, October 2004. 2027 Authors' Addresses 2029 Mohsen Soroushnejad (editor) 2030 Sylantro Systems Corp 2032 Email: mohsen.soroush@sylantro.com 2034 Venkatesh Venkataramanan 2035 Sylantro Systems Corp 2037 Email: venkatar@sylantro.com 2038 Paul Pepper 2039 Citel Technologies 2041 Email: paul.pepper@citel.com 2043 Anil Kumar 2044 Yahoo Inc. 2046 Email: anil@yahoo-inc.com 2048 Alan Johnston (editor) 2049 Avaya 2050 St. Louis, MO 63124 2052 Email: alan@sipstation.com 2054 Full Copyright Statement 2056 Copyright (C) The IETF Trust (2007). 2058 This document is subject to the rights, licenses and restrictions 2059 contained in BCP 78, and except as set forth therein, the authors 2060 retain all their rights. 2062 This document and the information contained herein are provided on an 2063 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2064 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2065 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2066 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2067 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2068 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2070 Intellectual Property 2072 The IETF takes no position regarding the validity or scope of any 2073 Intellectual Property Rights or other rights that might be claimed to 2074 pertain to the implementation or use of the technology described in 2075 this document or the extent to which any license under such rights 2076 might or might not be available; nor does it represent that it has 2077 made any independent effort to identify any such rights. Information 2078 on the procedures with respect to rights in RFC documents can be 2079 found in BCP 78 and BCP 79. 2081 Copies of IPR disclosures made to the IETF Secretariat and any 2082 assurances of licenses to be made available, or the result of an 2083 attempt made to obtain a general license or permission for the use of 2084 such proprietary rights by implementers or users of this 2085 specification can be obtained from the IETF on-line IPR repository at 2086 http://www.ietf.org/ipr. 2088 The IETF invites any interested party to bring to its attention any 2089 copyrights, patents or patent applications, or other proprietary 2090 rights that may cover technology that may be required to implement 2091 this standard. Please address the information to the IETF at 2092 ietf-ipr@ietf.org. 2094 Acknowledgment 2096 Funding for the RFC Editor function is provided by the IETF 2097 Administrative Support Activity (IASA).