idnits 2.17.1 draft-ietf-sipping-dialog-package-06.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.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1676. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1653. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1660. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1666. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 9 has weird spacing: '...Package for t...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (Apr 12, 2005) is 6954 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) == Unused Reference: '20' is defined on line 1609, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 1614, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3265 (ref. '1') (Obsoleted by RFC 6665) -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2141 (ref. '5') (Obsoleted by RFC 8141) ** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '6') ** Obsolete normative reference: RFC 3023 (ref. '8') (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 2246 (ref. '15') (Obsoleted by RFC 4346) == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-03 == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-transfer-03 Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIPPING J. Rosenberg 2 Internet-Draft Cisco Systems 3 Expires: October 11, 2005 H. Schulzrinne 4 Columbia University 5 R. Mahy, Ed. 6 SIP Edge LLC 7 Apr 12, 2005 9 An INVITE Inititiated Dialog Event Package for the Session 10 Initiation Protocol (SIP) 11 draft-ietf-sipping-dialog-package-06.txt 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on October 11, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 44 Abstract 46 This document defines a dialog event package for the SIP Events 47 architecture, along with a data format used in notifications for this 48 package. The dialog package allows users to subscribe to another 49 user, and receive notifications about the changes in state of INVITE 50 initiated dialog usages that the user is involved in. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. Dialog Event Package . . . . . . . . . . . . . . . . . . . . . 5 57 3.1 Event Package Name . . . . . . . . . . . . . . . . . . . . 5 58 3.2 Event Package Parameters . . . . . . . . . . . . . . . . . 5 59 3.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 6 60 3.4 Subscription Duration . . . . . . . . . . . . . . . . . . 7 61 3.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 7 62 3.6 Notifier Processing of SUBSCRIBE Requests . . . . . . . . 8 63 3.7 Notifier Generation of NOTIFY Requests . . . . . . . . . . 8 64 3.7.1 The Dialog State Machine . . . . . . . . . . . . . . . 9 65 3.7.2 Applying the state machine . . . . . . . . . . . . . . 12 66 3.8 Subscriber Processing of NOTIFY Requests . . . . . . . . . 13 67 3.9 Handling of Forked Requests . . . . . . . . . . . . . . . 13 68 3.10 Rate of Notifications . . . . . . . . . . . . . . . . . . 14 69 3.11 State Agents . . . . . . . . . . . . . . . . . . . . . . . 14 70 4. Dialog Information Format . . . . . . . . . . . . . . . . . . 14 71 4.1 Structure of Dialog Information . . . . . . . . . . . . . 14 72 4.1.1 Dialog Element . . . . . . . . . . . . . . . . . . . . 15 73 4.1.2 State . . . . . . . . . . . . . . . . . . . . . . . . 16 74 4.1.3 Duration . . . . . . . . . . . . . . . . . . . . . . . 16 75 4.1.4 Replaces . . . . . . . . . . . . . . . . . . . . . . . 16 76 4.1.5 Referred-By . . . . . . . . . . . . . . . . . . . . . 17 77 4.1.6 Local and Remote elements . . . . . . . . . . . . . . 17 78 4.1.6.1 Identity . . . . . . . . . . . . . . . . . . . . . 17 79 4.1.6.2 Target . . . . . . . . . . . . . . . . . . . . . . 17 80 4.1.6.3 Session Description . . . . . . . . . . . . . . . 18 81 4.2 Sample Notification Body . . . . . . . . . . . . . . . . . 19 82 4.3 Constructing Coherent State . . . . . . . . . . . . . . . 19 83 4.4 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 20 84 5. Definition of new media feature parameters . . . . . . . . . . 23 85 5.1 The "sip.byeless" parameter . . . . . . . . . . . . . . . 23 86 5.2 The "sip.rendering" parameter . . . . . . . . . . . . . . 24 87 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 88 6.1 Basic Example . . . . . . . . . . . . . . . . . . . . . . 24 89 6.2 Emulating a Shared-Line phone system . . . . . . . . . . . 27 90 6.3 Minimal Dialog Information with Privacy . . . . . . . . . 31 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 93 8.1 application/dialog-info+xml MIME Registration . . . . . . 33 94 8.2 URN Sub-Namespace Registration for 95 urn:ietf:params:xml:ns:dialog-info . . . . . . . . . . . . 33 96 8.3 Schema Registration . . . . . . . . . . . . . . . . . . . 34 97 8.4 Media Feature Parameter Registration . . . . . . . . . . . 34 98 8.4.1 sip.byeless . . . . . . . . . . . . . . . . . . . . . 34 99 8.4.2 sip.rendering . . . . . . . . . . . . . . . . . . . . 35 100 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 101 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 102 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 36 103 10.2 Informative References . . . . . . . . . . . . . . . . . . . 37 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37 105 Intellectual Property and Copyright Statements . . . . . . . . 39 107 1. Introduction 109 The SIP Events framework [1] defines general mechanisms for 110 subscription to, and notification of, events within SIP networks. It 111 introduces the notion of a package, which is a specific 112 "instantiation" of the events mechanism for a well-defined set of 113 events. Packages have been defined for user presence [16], watcher 114 information [17], and message waiting indicators [18], amongst 115 others. Here, we define an event package for INVITE initiated dialog 116 usages. Dialogs refer to the SIP relationship established between 117 two SIP peers [2]. Dialogs can be created by many methods, although 118 RFC 3261 defines only one - the INVITE method. RFC 3265 defines the 119 SUBSCRIBE and NOTIFY methods, which also create new dialog usages. 120 However, the usage of this package to model transitions in the state 121 of those dialog usages are out of the scope of this specification. 123 There are a variety of applications enabled through the knowledge of 124 INVITE dialog usage state. Some examples include: 125 Automatic Callback: In this basic Public Switched Telephone Network 126 (PSTN) application, user A calls user B. User B is busy. User A 127 would like to get a callback when user B hangs up. When B hangs 128 up, user A's phone rings. When A picks it up, they here ringing, 129 and are being connected to B. To implement this with SIP, a 130 mechanism is required for B to receive a notification when the 131 dialogs at A are complete. 132 Presence-Enabled Conferencing: In this application, a user A wishes 133 to set up a conference call with users B and C. Rather than 134 scheduling it, it is to be created automatically when A, B and C 135 are all available. To do this, the server providing the 136 application would like to know whether A, B and C are "online", 137 not idle, and not in a phone call. Determining whether or not A, 138 B and C are in calls can be done in two ways. In the first, the 139 server acts as a call stateful proxy for users A, B and C, and 140 therefore knows their call state. This won't always be possible, 141 however, and it introduces scalability, reliability, and 142 operational complexities. Rather, the server would subscribe to 143 the dialog state of those users, and receive notifications as it 144 changes. This enables the application to be provided in a 145 distributed way; the server need not reside in the same domain as 146 the users. 147 IM Conference Alerts: In this application, a user can get an Instant 148 Message (IM) sent to their phone whenever someone joins a 149 conference that the phone is involved in. The IM alerts are 150 generated by an application separate from the conference server. 152 In general, the dialog package allows for construction of distributed 153 applications, where the application requires information on dialog 154 state, but is not co-resident with the end user on which that state 155 resides. 157 In addition, this document also defines two new callee capabilities 158 [10] feature parameters: "sip.byeless", which indicates that a SIP 159 User Agent (UA) is not capable of terminating a session itself (for 160 example as with some announcement or recording services, and in some 161 call centers)in which the UA is no longer interested in 162 participating; and "sip.rendering", which positively describes if the 163 User Agent is rendering any of the media it is receiving. These 164 feature parameters are useful in many of the same applications which 165 motivated the dialog package, such as conferencing, presence, and the 166 shared-line example described in Section 6.2. 168 2. Terminology 170 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 171 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 172 and "OPTIONAL" are to be interpreted as described in RFC 2119 [9] and 173 indicate requirement levels for compliant implementations. 175 3. Dialog Event Package 177 This section provides the details for defining a SIP Events package, 178 as specified by [1]. 180 3.1 Event Package Name 182 The name of this event package is "dialog". This package name is 183 carried in the Event and Allow-Events header, as defined in [1]. 185 3.2 Event Package Parameters 187 This package defines four Event Package parameters. They are 188 call-id, to-tag, from-tag, and include-session-description. If a 189 subscription to a specific dialog is requested, all of the first 190 three of these parameters MUST be present. They identify the dialog 191 that is being subscribed to. The to-tag is matched against the local 192 tag, the from-tag is matched against the remote tag, and the call-id 193 is matched against the Call-ID. The include-session-description 194 parameter indicates if the subscriber would like to receive the 195 session descriptions associated with the subscribed dialog usage or 196 usages. 198 It is also possible to subscribe to the set of dialogs created as a 199 result of a single INVITE sent by a UAC. In that case, the call-id 200 and to-tag MUST be present. The to-tag is matched against the local 201 tag, and the call-id is matched against the Call-ID. 203 The ABNF for these parameters is shown below. It refers to many 204 constructions from the ABNF of RFC3261, such as EQUAL, DQUOTE, and 205 token. 207 call-id = "call-id" EQUAL ( token / DQUOTE callid DQUOTE ) 208 ;; NOTE: any DQUOTEs inside callid MUST be escaped! 209 from-tag = "from-tag" EQUAL token 210 to-tag = "to-tag" EQUAL token 211 with-sessd = "include-session-description" 213 Any callids which contain embedded double-quotes MUST escape those 214 double-quotes using the backslash-quoting mechanism. Note that the 215 call-id parameter may need to be expressed as a quoted string. This 216 is because the ABNF for callid and word (which is used by callid) 217 allow for some characters (such as "@", "[", and ":") which are not 218 allowed within a token. 220 3.3 SUBSCRIBE Bodies 222 A SUBSCRIBE for a dialog package MAY contain a body. This body 223 defines a filter to apply to the subscription. Filter documents are 224 not specified in this document, and at the time of writing, are 225 expected to be the subject of future standardization activity. 227 A SUBSCRIBE for a dialog package MAY be sent without a body. This 228 implies the default subscription filtering policy. The default 229 policy is: 230 o If the Event header field contained dialog identifiers, 231 notifications are generated every time there is a change in the 232 state of any matching dialogs for the user identified in the 233 request URI of the SUBSCRIBE. 234 o If there were no dialog identifiers in the Event header field, 235 notifications are generated every time there is any change in the 236 state of any dialogs for the user identified in the request URI of 237 the SUBSCRIBE with the following exceptions. If the target 238 (Contact) URI of a subscriber is equivalent to the remote target 239 URI of a specific dialog, then the dialog element for that dialog 240 is suppressed for that subscriber. (The subscriber is already a 241 party in the dialog directly, so these notifications are 242 superfluous.) If no dialogs remain after supressing dialogs, the 243 entire notification to that subscriber is supressed and the 244 version number in the dialog-info element is not incremented for 245 that subscriber. Implicit filtering for one subscriber does not 246 affect notifications to other subscribers. 247 o Notifications do not normally contain full state; rather, they 248 only indicate the state of the dialog whose state has changed. 249 The exceptions are a NOTIFY sent in response to a SUBSCRIBE, and a 250 NOTIFY that contains no dialog elements. These NOTIFYs contain 251 the complete view of dialog state. 252 o The notifications contain the identities of the participants in 253 the dialog, the target URIs, and the dialog identifiers. Session 254 descriptions are not included normally unless explicitly requested 255 and/or explicitly authorized. 257 3.4 Subscription Duration 259 Dialog state changes fairly quickly; once established, a typical 260 phone call lasts a few minutes (this is different for other session 261 types, of course). However, the interval between new calls is 262 typically infrequent. As such, we arbitrarily choose a default 263 duration of one hour. Clients SHOULD specify an explicit duration. 265 There are two distinct use cases for dialog state. The first is when 266 a subscriber is interested in the state of a specific dialog or 267 dialogs (and they are authorized to find out about just the state of 268 those dialogs). In that case, when the dialogs terminate, so too 269 does the subscription. In these cases, the value of the subscription 270 duration is largely irrelevant, and SHOULD be longer than the typical 271 duration of a dialog, about two hours would cover most dialogs. 273 In another case, a subscriber is interested in the state of all 274 dialogs for a specific user. In these cases, a shorter interval 275 makes more sense. The default is one hour for these subscriptions. 277 3.5 NOTIFY Bodies 279 As described in RFC 3265 [1], the NOTIFY message will contain bodies 280 that describe the state of the subscribed resource. This body is in 281 a format listed in the Accept header field of the SUBSCRIBE, or a 282 package-specific default if the Accept header field was omitted from 283 the SUBSCRIBE. 285 In this event package, the body of the notification contains a dialog 286 information document. This document describes the state of one or 287 more dialogs associated with the subscribed resource. All 288 subscribers and notifiers MUST support the 289 "application/dialog-info+xml" data format described in Section 4. 290 The subscribe request MAY contain an Accept header field. If no such 291 header field is present, it has a default value of 292 "application/dialog-info+xml". If the header field is present, it 293 MUST include "application/dialog-info+xml", and MAY include any other 294 types capable of representing dialog state. 296 Of course, the notifications generated by the server MUST be in one 297 of the formats specified in the Accept header field in the SUBSCRIBE 298 request. 300 3.6 Notifier Processing of SUBSCRIBE Requests 302 The dialog information for a user contains sensitive information. 303 Therefore, all subscriptions SHOULD be authenticated and then 304 authorized before approval. All implementors of this package MUST 305 support the digest authentication mechanism as a baseline. 306 Authorization policy is at the discretion of the administrator, as 307 always. However, a few recommendations can be made. 309 It is RECOMMENDED that, if the policy of user B is that user A is 310 allowed to call them, dialog subscriptions from user A be allowed. 311 However, the information provided in the notifications does not 312 contain any dialog identification information; merely an indication 313 of whether the user is in at least one call, or not. Specifically, 314 they should not be able to find out any more information than if they 315 sent an INVITE. (This concept of a "virtual" dialog is discussed 316 more in Section 3.7.2, and an example of such a notification body is 317 shown below.) 318 319 322 323 confirmed 324 325 327 It is RECOMMENDED that if a user agent registers with the 328 address-of-record X, that this user agent authorize subscriptions 329 that come from any entity that can authenticate itself as X. 330 Complete information on the dialog state SHOULD be sent in this case. 331 This authorization behavior allows a group of devices representing a 332 single user to all become aware of each other's state. This is 333 useful for applications such as single-line-extension. 334 Note that many implementations of "shared-lines" have a feature 335 which allows details of calls on a shared address-of-record to be 336 made private. This is a completely reasonable authorization 337 policy which could result in notifications which contain only the 338 id attribute of the dialog element and the state element when 339 shared-line privacy is requested, and notifications with more 340 complete information when shared-line privacy is not requested. 342 3.7 Notifier Generation of NOTIFY Requests 344 Notifications are generated for the dialog package when an INVITE 345 request is sent, when a new dialog comes into existence at a UA, or 346 when the state or characteristics of an existing dialog changes. 347 Therefore, a model of dialog state is needed in order to determine 348 precisely when to send notifications, and what their content should 349 be. The SIP specification has a reasonably well defined lifecycle 350 for dialogs. However, it is not explicitly modelled. This 351 specification provides an explicit model of dialog state through a 352 finite state machine. 354 It is RECOMMENDED that NOTIFY requests only contain information on 355 the dialogs whose state or participation information has changed. 356 However, if a notifier receives a SUBSCRIBE request, the triggered 357 NOTIFY SHOULD contain the state of all dialogs that the subscriber is 358 authorized to see. 360 3.7.1 The Dialog State Machine 362 Modelling of dialog state is complicated by two factors. The first 363 is forking, which can cause a single INVITE to generate many dialogs 364 at a UAC. The second is the differing views of state at the UAC and 365 UAS. We have chosen to handle the first issue by extending the 366 dialog FSM to include the states between transmission of the INVITE 367 and the creation of actual dialogs through receipt of 1xx and 2xx 368 responses. As a result, this specification supports the notion of 369 dialog state for dialogs before they are fully instantiated. 371 We have also chosen to use a single FSM for both UAC and UAS. 373 +----------+ +----------+ 374 | | 1xx-notag | | 375 | |----------->| | 376 | Trying | |Proceeding|-----+ 377 | |---+ +-----| | | 378 | | | | | | | 379 +----------+ | | +----------+ | 380 | | | | | | 381 | | | | | | 382 +<--C-----C--+ |1xx-tag | 383 | | | | | 384 cancelled| | | V | 385 rejected| | |1xx-tag +----------+ | 386 | | +------->| | |2xx 387 | | | | | 388 +<--C--------------| Early |-----C---+ 1xx-tag 389 | | replaced | | | | w/new tag 390 | | | |<----C---+ (new FSM 391 | | +----------+ | instance 392 | | 2xx | | created) 393 | +----------------+ | | 394 | | |2xx | 395 | | | | 396 V V V | 397 +----------+ +----------+ | 398 | | | | | 399 | | | | | 400 |Terminated|<-----------| Confirmed|<----+ 401 | | error | | 402 | | timeout | | 403 +----------+ replaced +----------+ 404 local-bye | ^ 405 remote-bye | | 406 | | 407 +------+ 408 2xx w. new tag 409 (new FSM instance 410 created) 412 Figure 3 414 The FSM for dialog state is shown in Figure 3. The FSM is best 415 understood by considering the UAC and UAS cases separately. 417 The FSM is created in the "trying" state when the UAC sends an INVITE 418 request. Upon receipt of a 1xx without a tag, the FSM transitions to 419 the "proceeding" state. Note that there is no actual dialog yet, as 420 defined by the SIP specification. However, there is a "half-dialog", 421 in the sense that two of the three components of the dialog ID are 422 known (the call identifier and local tag). If a 1xx with a tag is 423 received, the FSM transitions to the early state. The full dialog 424 identifier is now defined. Had a 2xx been received, the FSM would 425 have transitioned to the "confirmed" state. 427 If, after transitioning to the "early" or "confirmed" states, the UAC 428 receives another 1xx or 2xx respectively with a different tag, 429 another instance of the FSM is created, initialized into the "early" 430 or "confirmed" state respectively. The benefit of this approach is 431 that there will be a single FSM representing the entire state of the 432 invitation and resulting dialog when dealing with the common case of 433 no forking. 435 If the UAC should send a CANCEL, and then subsequently receive a 487 436 to its INVITE transaction, all FSMs spawned from that INVITE 437 transition to the "terminated" state with the event "cancelled". If 438 the UAC receives a new invitation (with a Replaces [13] header) which 439 replaces the current Early or Confirmed dialog, all INVITE 440 transactions spawned from the replaced invitation transition to the 441 "terminated" state with the event "replaced". If the INVITE 442 transaction terminates with a non-2xx response for any other reason, 443 all FSMs spawned from that INVITE transition to the terminated state 444 with the event "rejected". 446 Once in the confirmed state, the call is active. It can transition 447 to the terminated state if the UAC sends a BYE or receives a BYE 448 (corresponding to the "local-bye" and "remote-bye" events as 449 appropriate), if a mid-dialog request generates a 481 or 408 response 450 (corresponding to the "error" event), or a mid-dialog request 451 generates no response (corresponding to the "timeout" event). 453 From the perspective of the UAS, when an INVITE is received, the FSM 454 is created in the "trying" state. If it sends a 1xx without a tag, 455 the FSM transitions to the "proceeding" state. If a 1xx is sent with 456 a tag, the FSM transitions to the "early" state, and if a 2xx is 457 sent, it transitions to the "confirmed" state. If the UAS should 458 receive a CANCEL request and then generate a 487 response to the 459 INVITE (which can occur in the proceeding and early states), the FSM 460 transitions to the terminated state with the event "cancelled". If 461 the UAS should generate any other non-2xx final response to the 462 INVITE request, the FSM transitions to the terminated state with the 463 event "rejected". If the UAS receives a new invitation (with a 464 Replaces [13] header) which replaces the current Confirmed dialog, 465 the replaced invitation transitions to the "terminated" state with 466 the event "replaced". Once in the "confirmed" state, the other 467 transitions to the "terminated" state occur for the same reasons they 468 do in the case of UAC. 470 There should never be a transition from the "trying" state to the 471 "terminated" state with the event "cancelled", since the SIP 472 specification prohibits transmission of CANCEL until a provisional 473 response is received. However, this transition is defined in the 474 FSM just to unify the transitions from trying, proceeding, and 475 early to the terminated state. 477 3.7.2 Applying the state machine 479 The notifier MAY generate a NOTIFY request on any event transition of 480 the FSM. Whether it does or not is policy dependent. However, some 481 general guidelines are provided. 483 When the subscriber is unauthenticated, or is authenticated, but 484 represents a third party with no specific authorization policies, it 485 is RECOMMENDED that subscriptions to an individual dialog, or to a 486 specific set of dialogs, is forbidden. Only subscriptions to all 487 dialogs (i.e., there are no dialog identifiers in the Event header 488 field) are permitted. In that case, actual dialog states across all 489 dialogs will not be reported. Rather, a single "virtual" dialog FSM 490 be used, and event transitions on that FSM be reported. 492 If there is any dialog at the UA whose state is "confirmed", the 493 virtual FSM is in the "confirmed" state. If there are no dialogs at 494 the UA in the confirmed state, but there is at least one in the 495 "early" state, the virtual FSM is in the "early" or "confirmed" 496 state. If there are no dialogs in the confirmed or early states, but 497 there is at least one in the "proceeding" state, the virtual FSM is 498 in the "proceeding", "early" or "confirmed" state. If there are no 499 dialogs in the confirmed, early, or proceeding states, but there is 500 at least one in the "trying" state, the virtual FSM is in the 501 "trying", "proceeding", "early" or "confirmed" state. The choice 502 about which state to use depends on whether the UA wishes to let 503 unknown users know that their phone is ringing, as opposed to in an 504 active call. 506 It is RECOMMENDED that, in the absence of any preference, "confirmed" 507 is used in all cases (as shown in the example in Section 3.6. 508 Furthermore, it is RECOMMENDED that the notifications of changes in 509 the virtual FSM machine not convey any information except the state 510 of the FSM and its event transitions - no dialog identifiers (which 511 are ill-defined in this model in any case). The use of this virtual 512 FSM allows for minimal information to be conveyed. A subscriber 513 cannot know how many calls are in progress, or with whom, just that 514 there exists a call. This is the same information they would receive 515 if they simply sent an INVITE to the user instead; a 486 response 516 would indicate that they are on a call. 518 When the subscriber is authenticated, and has authenticated itself 519 with the same address-of-record that the UA itself uses, if no 520 explicit authorization policy is defined, it is RECOMMENDED that all 521 state transitions on dialogs that have been subscribed to (which is 522 either all of them, if no dialog identifiers were present in the 523 Event header field, or a specific set of them identified by the Event 524 header field parameters) be reported, along with complete dialog IDs. 526 The notifier SHOULD generate a NOTIFY request on any change in the 527 characteristics associated with the dialog. Since these include 528 Contact URIs, Contact parameters and session descriptions, receipt of 529 re-INVITEs and UPDATE requests [3] which modify this information MAY 530 trigger notifications. 532 3.8 Subscriber Processing of NOTIFY Requests 534 The SIP Events framework expects packages to specify how a subscriber 535 processes NOTIFY requests in any package specific ways, and in 536 particular, how it uses the NOTIFY requests to contruct a coherent 537 view of the state of the subscribed resource. 539 Typically, the NOTIFY for the dialog package will only contain 540 information about those dialogs whose state has changed. To 541 construct a coherent view of the total state of all dialogs, a 542 subscriber to the dialog package will need to combine NOTIFYs 543 received over time. 545 Notifications within this package can convey partial information; 546 that is, they can indicate information about a subset of the state 547 associated with the subscription. This means that an explicit 548 algorithm needs to be defined in order to construct coherent and 549 consistent state. The details of this mechanism are specific to the 550 particular document type. See Section 4.3 for information on 551 constructing coherent information from an application/dialog-info+xml 552 document. 554 3.9 Handling of Forked Requests 556 Since dialog state is distributed across the UA for a particular 557 user, it is reasonable and useful for a SUBSCRIBE request for dialog 558 state to fork, and reach multiple UA. 560 As a result, a forked SUBSCRIBE request for dialog state can install 561 multiple subscriptions. Subscribers to this package MUST be prepared 562 to install subscription state for each NOTIFY generated as a result 563 of a single SUBSCRIBE. 565 3.10 Rate of Notifications 567 For reasons of congestion control, it is important that the rate of 568 notifications not become excessive. As a result, it is RECOMMENDED 569 that the server not generate notifications for a single subscriber at 570 a rate faster than once every 1 second. 572 3.11 State Agents 574 Dialog state is ideally maintained in the user agents in which the 575 dialog resides. Therefore, the elements that maintain the dialog are 576 the ones best suited to handle subscriptions to it. However, in some 577 cases, a network agent may also know the state of the dialogs held by 578 a user. As such, state agents MAY be used with this package. 580 4. Dialog Information Format 582 Dialog information is an XML document [4] that MUST be well-formed 583 and SHOULD be valid. Dialog information documents MUST be based on 584 XML 1.0 and MUST be encoded using UTF-8. This specification makes 585 use of XML namespaces for identifying dialog information documents 586 and document fragments. The namespace URI for elements defined by 587 this specification is a URN [5], using the namespace identifier 588 'ietf' defined by [6] and extended by [7]. This URN is: 590 urn:ietf:params:xml:ns:dialog-info 592 A dialog information document begins with the root element tag 593 "dialog-info". 595 4.1 Structure of Dialog Information 597 A dialog information document starts with a dialog-info element. 598 This element has three mandatory attributes: 599 version: This attribute allows the recipient of dialog information 600 documents to properly order them. Versions start at 0, and 601 increment by one for each new document sent to a subscriber. 602 Versions are scoped within a subscription. Versions MUST be 603 representable using a 32 bit integer. 604 state: This attribute indicates whether the document contains the 605 full dialog information, or whether it contains only information 606 on those dialogs which have changed since the previous document 607 (partial). 608 entity: This attribute contains a URI that identifies the user whose 609 dialog information is reported in the remainder of the document. 610 This user is referred to as the "observed user". 612 The dialog-info element has a series of zero or more dialog 613 sub-elements. Each of those represents a specific dialog. 614 615 618 620 4.1.1 Dialog Element 622 The dialog element reports information on a specific dialog or 623 "half-dialog". It has single mandatory attribute: id. The id 624 attribute provides a single string that can be used as an identifier 625 for this dialog or "half-dialog". This is a different identifier 626 than the dialog ID defined in RFC 3261 [2], but related to it. 628 For a caller, the id is created when an INVITE request is sent. When 629 a 1xx with a tag, or a 2xx is received, the dialog is formally 630 created. The id remains unchanged. However, if an additional 1xx or 631 2xx is received, resulting in the creation of another dialog (and 632 resulting FSM), that dialog is allocated a new id. 634 For a callee, the id is created when an INVITE outside of an existing 635 dialog is received. When a 2xx or a 1xx with a tag is sent, creating 636 the dialog, the id remains unchanged. 638 The id MUST be unique amongst all dialogs at a UA. 640 There are a number of optional attributes which provide 641 identification information about the dialog: 642 call-id: This attribute is a string which represents the call-id 643 component of the dialog identifier. (Note that single and double 644 quotes inside a call-id must be escaped using "e; for " and 645 ' for ' .) 646 local-tag: This attribute is a string which represents the local-tag 647 component of the dialog identifier. 648 remote-tag: This attribute is a string which represents the 649 remote-tag component of the dialog identifier. The remote tag 650 attribute won't be present if there is only a "half-dialog", 651 resulting from the generation of an INVITE for which no final 652 responses or provisional responses with tags has been received. 653 direction: This attribute is either initiator or recipient, and 654 indicates whether the observed user was the initiator of the 655 dialog, or the recipient of the INVITE that created it. 657 658 661 663 ... 664 665 667 The sub-elements of the dialog element provide additional information 668 about the dialog. Some of these sub-elements provide more detail 669 about the dialog itself, while the local and remote sub-elements 670 describe characteristics of the participants involved in the dialog. 671 The only mandatory sub-element is the state element. 673 4.1.2 State 675 The state element indicates the state of the dialog. Its value is an 676 enumerated type describing one of the states in the FSM above. It 677 has an optional event attribute that can be used to indicate the 678 event which caused any transition into the terminated state, and an 679 optional code attribute that indicates the response code associated 680 with any transition caused by a response to the original INVITE. 682 terminated 684 4.1.3 Duration 686 The duration element contains the amount of time, in seconds, since 687 the FSM was created. 689 145 691 4.1.4 Replaces 693 The replaces element is used to correlate a new dialog with one it 694 replaced as a result of an invitation with a Replaces header. This 695 element is present in the replacement dialog only (the newer dialog) 696 and contains attributes with the call-id, local-tag, and remote-tag 697 of the replaced dialog. 699 702 4.1.5 Referred-By 704 The referred-by element is used to correlate a new dialog with a 705 REFER [12] request which triggered it. The element is present in a 706 dialog which was triggered by a REFER request which contained a 707 Referred-By [11] header and contains the (optional) display name 708 attribute and the Referred-By URI as its value. 710 sip:bob@example.com 712 4.1.6 Local and Remote elements 714 The local and remote elements are sub-elements of the dialog element 715 which contain information about the local and remote participants 716 respectively. They both have a number of optional sub-elements which 717 indicate the identity conveyed by the participant, the target URI, 718 the feature-tags of the target, and the session-description of the 719 participant. 721 4.1.6.1 Identity 723 The identity element indicates a local or remote URI, as defined in 724 [2] as appropriate. It has an optional attribute, display, that 725 contains the display name from the appropriate URI. 726 Note that multiple identities (for example a sip: URI and a tel: 727 URI) could be included if they all correspond to the participant. 728 To avoid repeating identity information in each request, the 729 subscriber can assume that the identity URIs are the same as in 730 previous notifications if no identity elements are present in the 731 corresponding local or remote element. If any identity elements 732 are present in the local or remote part of a notification, the new 733 list of identity tags completely supersedes the old list in the 734 corresponding part. 736 737 sip:anonymous@anonymous.invalid 739 4.1.6.2 Target 741 The target contains the local or remote target URI as constructed by 742 the user agent for this dialog, as defined in RFC 3261 [2] in a "uri" 743 attribute. 745 It can contain a list of Contact header parameters in param 746 sub-elements (such as those defined in [10]). The param element 747 contains two required attributes, pname and pval. Boolean parameters 748 are represented by the explicit pval values "true" and "false" (for 749 example when a feature parameter is explicitly negated). The param 750 element itself has no contents. To avoid repeating Contact 751 information in each request, the subscriber can assume that the 752 target URI and parameters are the same as in previous notifications 753 if no target element is present in the corresponding local or remote 754 element. If a target element is present in the local or remote part 755 of a notification, the new target tag and list of an parameter tags 756 completely supersedes the old target and parameter list in the 757 corresponding part. 759 760 761 762 764 4.1.6.3 Session Description 766 The session-description element contains the session description used 767 by the observed user for its end of the dialog. This element should 768 generally NOT be included in the notifications, unless explicitly 769 requested by the subscriber. It has a single attribute, type, which 770 indicates the MIME media type of the session description. To avoid 771 repeating session description information in each request, the 772 subscriber can assume that the session description is the same as in 773 previous notifications if no session description element is present 774 in the corresponding local or remote element. 776 4.2 Sample Notification Body 778 779 783 784 confirmed 785 274 786 787 sip:alice@example.com 788 789 790 791 792 793 794 sip:bob@example.org 795 796 797 798 800 4.3 Constructing Coherent State 802 The dialog information subscriber maintains a table for the list of 803 dialogs. The table contains a row for each dialog. Each row is 804 indexed by an ID, present in the "id" attribute of the "dialog" 805 element. The contents of each row contain the state of that dialog 806 as conveyed in the document. The table is also associated with a 807 version number. The version number MUST be initialized with the 808 value of the "version" attribute from the "dialog-info" element in 809 the first document received. Each time a new document is received, 810 the value of the local version number, and the "version" attribute in 811 the new document, are compared. If the value in the new document is 812 one higher than the local version number, the local version number is 813 increased by one, and the document is processed. If the value in the 814 document is more than one higher than the local version number, the 815 local version number is set to the value in the new document, and the 816 document is processed. If the document did not contain full state, 817 the subscriber SHOULD generate a refresh request to trigger a full 818 state notification. If the value in the document is less than the 819 local version, the document is discarded without processing. 821 The processing of the dialog information document depends on whether 822 it contains full or partial state. If it contains full state, 823 indicated by the value of the "state" attribute in the "dialog-info" 824 element, the contents of the table are flushed. They are repopulated 825 from the document. A new row in the table is created for each 826 "dialog" element. If the document contains partial state, as 827 indicated by the value of the "state" attribute in the "dialog-info" 828 element, the document is used to update the table. For each "dialog" 829 element in the document, the subscriber checks to see whether a row 830 exists for that dialog. This check is done by comparing the ID in 831 the "id" attribute of the "dialog" element with the ID associated 832 with the row. If the dialog doesn't exist in the table, a row is 833 added, and its state is set to the information from that "dialog" 834 element. If the dialog does exist, its state is updated to be the 835 information from that "dialog" element. If a row is updated or 836 created, such that its state is now terminated, that entry MAY be 837 removed from the table at any time. 839 4.4 Schema 841 The following is the schema for the application/dialog-info+xml type: 843 844 850 851 853 854 855 856 858 860 861 863 864 865 866 867 868 869 871 872 873 874 875 876 877 878 879 881 882 883 885 887 889 890 891 893 894 895 896 898 899 900 901 903 905 907 908 909 911 913 915 916 917 918 919 920 921 922 923 924 925 926 927 929 930 931 932 934 935 937 939 940 941 942 943 944 945 947 949 951 952 953 954 955 956 958 959 960 961 962 963 964 965 966 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 1000 5. Definition of new media feature parameters 1002 This section defines two new media feature parameters which are 1003 useful as input to user presence, in conferencing applications, and 1004 in applications like the shared-line example described in Section 1005 6.2. These feature parameters are especially useful when used in 1006 combination with the dialog package, as they allow an authorized 1007 third party to become aware of these characteristics. 1009 5.1 The "sip.byeless" parameter 1011 The "sip.byeless" media feature parameter is a new boolean parameter, 1012 defined in this document, which provides a positive indication that 1013 the User Agent setting the parameter is unable to terminate sessions 1014 on its own (for example, by sending a BYE request). For example, 1015 continuous announcement services and certain recording services are 1016 unable to determine when it would be desirable to terminate a session 1017 and therefore do not have the ability to terminate sessions at all. 1018 Also, many human call centers are configured so that they never 1019 terminate sessions. (This is to prevent call center agents from 1020 accidentally disconnecting the caller.) 1022 Contact: 1023 ;automaton;+sip.byeless 1025 5.2 The "sip.rendering" parameter 1027 The "sip.rendering" media feature parameter is a new string 1028 parameter, defined in this document, which can provide a positive 1029 indication whether the User Agent setting the parameter is currently 1030 rendering any of the media it is receiving in the context of a 1031 specific session. It MUST only be used in a Contact header field in 1032 a dialog created using the INVITE request. (Note that per [10] this 1033 parameter name must be preceeded by a "+" character when used in a 1034 SIP Contact header field.) 1036 This parameter has three legal values: "yes", "no", and "unknown". 1037 The value "yes" indicates positive knowledge that the User Agent is 1038 rendering at least one of the streams of media that it is receiving. 1039 The value "no" indicates positive knowledge that the User Agent is 1040 rendering none of the media that it is receiving. The value 1041 "unknown" indicates that the User Agent does not know whether the 1042 media associated with the session is being rendered. (which may be 1043 the case if the User Agent is acting as a 3pcc (Third Party Call 1044 Control) [19] controller). 1046 The "sip.rendering" parameter is useful in applications such as 1047 shared appearances, conference status monitoring, or as an input to 1048 user presence. 1050 Contact: 1051 ;automaton;+sip.rendering="no" 1053 6. Examples 1055 6.1 Basic Example 1057 For example, if a UAC sends an INVITE that looks like, in part: 1059 INVITE sip:bob@example.com SIP/2.0 1060 Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8 1061 Max-Forwards: 70 1062 To: Bob 1063 From: Alice ;tag=1928301774 1064 Call-ID: a84b4c76e66710 1065 CSeq: 314159 INVITE 1066 Contact: 1067 Content-Type: application/sdp 1068 Content-Length: 142 1070 [SDP not shown] 1072 The XML document in a notification from Alice might look like: 1074 1075 1079 1081 trying 1082 1083 1085 If the following 180 response is received: 1087 SIP/2.0 180 Ringing 1088 Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8 1089 To: Bob ;tag=456887766 1090 From: Alice ;tag=1928301774 1091 Call-ID: a84b4c76e66710 1092 CSeq: 314159 INVITE 1093 Contact: 1095 The XML document in a notification might look like: 1097 1098 1102 1105 early 1106 1107 1109 If it receives a second 180 with a different tag: 1111 SIP/2.0 180 Ringing 1112 Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8 1113 To: Bob ;tag=hh76a 1114 From: Alice ;tag=1928301774 1115 Call-ID: a84b4c76e66710 1116 CSeq: 314159 INVITE 1117 Contact: 1119 This results in the creation of a second dialog: 1121 1122 1126 1129 early 1130 1131 1134 early 1135 1136 1138 If a 200 OK is received on the second dialog, it moves to confirmed: 1140 1141 1145 1148 confirmed 1149 1150 1152 32 seconds later, the other early dialog terminates because no 2xx is 1153 received for it. This implies that it was successfully cancelled, 1154 and therefore the following notification is sent: 1156 1157 1161 1164 terminated 1165 1166 1168 6.2 Emulating a Shared-Line phone system 1170 The following example shows how a SIP telephone user agent can 1171 provide detailed state information and also emulate a shared-line 1172 telephone system (the phone "lies" about having a dialog while it is 1173 merely offhook). 1175 Idle: 1177 1178 1181 1183 Seized: 1185 1186 1189 1190 trying 1191 1192 1194 Dialing: 1196 1197 1200 1202 trying 1203 1204 1205 sip:alice@example.com 1206 1207 1208 1209 1210 sip:bob@example.net 1211 1212 1213 1215 Ringing: 1217 1218 1221 1224 early 1225 1226 1227 1228 1229 1231 Answered (by voicemail): 1233 1234 1237 1240 terminated 1241 1242 1245 confirmed 1246 1247 1248 1249 1250 1251 1252 1253 1254 1256 Alice requests voicemail for Bob's attendant. 1257 (Alice presses "0" in North America / "9" in Europe) 1258 Voicemail completes a transfer with Cathy 1260 1261 1264 1267 terminated 1268 1269 1272 confirmed 1273 1276 1277 sip:bob-is-not-here@vm.example.net 1278 1279 1280 1281 1283 1284 1285 1286 sip:cjones@example.net 1287 1288 1289 1290 1291 1292 1293 1294 1296 Alice and Cathy talk, Cathy adds Alice to a local conference. 1298 1299 1302 1305 confirmed 1306 1307 1308 1309 1310 1311 1312 1314 Alice puts Cathy on hold 1316 1317 1320 1323 confirmed 1324 1325 1326 1327 1328 1329 1330 1331 Cathy hangs up 1333 1334 1337 1340 terminated 1341 1342 1343 trying 1344 1345 1347 Alice hangs up: 1349 1350 1353 1355 6.3 Minimal Dialog Information with Privacy 1357 The following example shows the same user agent providing minimal 1358 information to maintain privacy for services like automatic callback. 1360 Onhook: 1362 1363 1366 1368 Offhook: (implementation/policy choice for Alice to transition 1369 to this "state" when "seized", when Trying, when Proceeding, 1370 or when Confirmed.) 1372 1373 1376 1377 confirmed 1378 1379 1381 Onhook: (implementation/policy choice for Alice to transition to 1382 this "state" when terminated, or when no longer "seized") 1384 1385 1388 1390 7. Security Considerations 1392 Subscriptions to dialog state can reveal sensitive information. For 1393 this reason, Section 3.6 discusses authentication and authorization 1394 of subscriptions, and provides guidelines on sensible authorization 1395 policies. All implementations of this package MUST support the 1396 digest authentication mechanism. 1398 Since the data in notifications is sensitive as well, end-to-end SIP 1399 encryption mechanisms using S/MIME MAY be used to protect it. User 1400 Agents that implement the dialog package SHOULD also implement SIP 1401 over TLS [15] and the sips: scheme. 1403 8. IANA Considerations 1405 This document registers a new MIME type, application/dialog-info+xml; 1406 a new XML namespace; and two new media feature parameters in the SIP 1407 tree. 1409 8.1 application/dialog-info+xml MIME Registration 1410 MIME media type name: application 1411 MIME subtype name: dialog-info+xml 1412 Mandatory parameters: none 1413 Optional parameters: Same as charset parameter application/xml as 1414 specified in RFC 3023 [8]. 1415 Encoding considerations: Same as encoding considerations of 1416 application/xml as specified in RFC 3023 [8]. 1417 Security considerations: See Section 10 of RFC 3023 [8] and Section 7 1418 of this specification. 1419 Interoperability considerations: none. 1420 Published specification: This document. 1421 Applications which use this media type: This document type has been 1422 used to support SIP applications such as call return and 1423 auto-conference. 1424 Additional Information: 1425 Magic Number: None 1426 File Extension: .xml 1427 Macintosh file type code: "TEXT" 1428 Personal and email address for further information: Jonathan 1429 Rosenberg, 1430 Intended usage: COMMON 1431 Author/Change controller: The IETF. 1433 8.2 URN Sub-Namespace Registration for 1434 urn:ietf:params:xml:ns:dialog-info 1436 This section registers a new XML namespace, as per the guidelines in 1437 [7]. 1438 URI: The URI for this namespace is 1439 urn:ietf:params:xml:ns:dialog-info. 1440 Registrant Contact: The IESG, 1441 XML: 1443 BEGIN 1444 1445 1447 1448 1449 1451 Dialog Information Namespace 1452 1453 1454

Namespace for Dialog Information

1455

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

1456

See RFCXXXX.

1457 1458 1459 END 1461 8.3 Schema Registration 1463 This specification registers a schema, as per the guidelines in in 1464 [7]. 1465 URI: please assign. 1466 Registrant Contact: The IESG, 1467 XML: The XML can be found as the sole content of Section 4.4. 1469 8.4 Media Feature Parameter Registration 1471 This section registers two new media feature tags, per the procedures 1472 defined in RFC 2506 [14]. The tags are placed into the sip tree, 1473 which is defined in [10]. 1475 8.4.1 sip.byeless 1476 Media feature tag name sip.byeless 1477 ASN.1 Identifier New assignment by IANA. 1478 Summary of the media feature indicated by this tag This feature tag 1479 is a boolean flag. When set it indicates that the device is 1480 incapable of terminating a session autonomously. 1481 Values appropriate for use with this feature tag Boolean. 1482 The feature tag is intended primarily for use in the following 1483 applications, protocols, services, or negotiation mechanisms This 1484 feature tag is most useful in a communications application for 1485 describing the capabilities of an application, such as an 1486 announcement service, recording service, conference, or call 1487 center. 1489 Examples of typical use Call centers and media services. 1490 Related standards or documents RFC XXXX [[Note to IANA: Please 1491 replace XXXX with the RFC number of this specification.]] 1492 Security Considerations This media feature tag can be used in ways 1493 which affect application behaviors or may reveal private 1494 information. For example, a conferencing or other application may 1495 decide to terminate a call prematurely if this media feature tag 1496 is set. Therefore, if an attacker can modify the values of this 1497 tag, they may be able to affect the behavior of applications. As 1498 a result of this, applications which utilize this media feature 1499 tag SHOULD provide a means for ensuring its integrity. Similarly, 1500 this feature tag should only be trusted as valid when it comes 1501 from the user or user agent described by the tag. As a result, 1502 protocols for conveying this feature tag SHOULD provide a 1503 mechanism for guaranteeing authenticity. 1505 8.4.2 sip.rendering 1506 Media feature tag name sip.rendering 1507 ASN.1 Identifier New assignment by IANA. 1508 Summary of the media feature indicated by this tag This feature tag 1509 contains one of three string values indicating if the device is 1510 rendering any media from the current session ("yes"), none of the 1511 media from the current session ("no"), or if this status is not 1512 known to the device ("unknown"). 1513 Values appropriate for use with this feature tag String. 1514 The feature tag is intended primarily for use in the following 1515 applications, protocols, services, or negotiation mechanisms This 1516 feature tag is most useful in a communications application, for 1517 describing the state of a device (such as a phone or PDA) during a 1518 multimedia session. 1519 Examples of typical use Conferencing, telephone shared-line 1520 emulation, and presence applications. 1521 Related standards or documents RFC XXXX [[Note to IANA: Please 1522 replace XXXX with the RFC number of this specification.]] 1523 Security Considerations This media feature tag can be used in ways 1524 which affect application behaviors or may reveal private 1525 information. For exmaple, a conferencing or other application may 1526 decide to terminate a call prematurely if this media feature tag 1527 is set to "no". Therefore, if an attacker can modify the values 1528 of this tag, they may be able to affect the behavior of 1529 applications. As a result of this, applications which utilize 1530 this media feature tag SHOULD provide a means for ensuring its 1531 integrity. Similarly, this feature tag should only be trusted as 1532 valid when it comes from the user or user agent described by the 1533 tag. As a result, protocols for conveying this feature tag SHOULD 1534 provide a mechanism for guaranteeing authenticity. 1536 9. Acknowledgements 1538 The authors would like to thank Sean Olson for his comments. 1540 10. References 1542 10.1 Normative References 1544 [1] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1545 Notification", RFC 3265, June 2002. 1547 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1548 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1549 Session Initiation Protocol", RFC 3261, June 2002. 1551 [3] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 1552 Method", RFC 3311, October 2002. 1554 [4] Paoli, J., Sperberg-McQueen, C., Bray, T. and E. Maler, 1555 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C 1556 FirstEdition REC-xml-20001006, October 2000. 1558 [5] Moats, R., "URN Syntax", RFC 2141, May 1997. 1560 [6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 1561 August 1999. 1563 [7] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1564 January 2004. 1566 [8] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 1567 3023, January 2001. 1569 [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1570 Levels", BCP 14, RFC 2119, March 1997. 1572 [10] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Indicating User 1573 Agent Capabilities in the Session Initiation Protocol (SIP)", 1574 RFC 3840, August 2004. 1576 [11] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By 1577 Mechanism", RFC 3892, September 2004. 1579 [12] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1580 Method", RFC 3515, April 2003. 1582 [13] Mahy, R., Biggs, B. and R. Dean, "The Session Initiation 1583 Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. 1585 [14] Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag 1586 Registration Procedure", BCP 31, RFC 2506, March 1999. 1588 [15] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 1589 2246, January 1999. 1591 10.2 Informative References 1593 [16] Rosenberg, J., "A Presence Event Package for the Session 1594 Initiation Protocol (SIP)", RFC 3856, August 2004. 1596 [17] Rosenberg, J., "A Watcher Information Event Template-Package 1597 for the Session Initiation Protocol (SIP)", RFC 3857, August 1598 2004. 1600 [18] Mahy, R., "A Message Summary and Message Waiting Indication 1601 Event Package for the Session Initiation Protocol (SIP)", RFC 1602 3842, August 2004. 1604 [19] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo, 1605 "Best Current Practices for Third Party Call Control (3pcc) in 1606 the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 1607 2004. 1609 [20] Rosenberg, J., "Obtaining and Using Globally Routable User 1610 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 1611 (SIP)", draft-ietf-sip-gruu-03 (work in progress), February 1612 2005. 1614 [21] Sparks, R. and A. Johnston, "Session Initiation Protocol Call 1615 Control - Transfer", draft-ietf-sipping-cc-transfer-03 (work in 1616 progress), October 2004. 1618 Authors' Addresses 1620 Jonathan Rosenberg 1621 Cisco Systems 1622 600 Lanidex Plaza 1623 Parsippany, NJ 07054 1624 US 1626 Phone: +1 973 952-5000 1627 EMail: jdrosen@cisco.com 1628 URI: http://www.jdrosen.net 1629 Henning Schulzrinne 1630 Columbia University 1631 M/S 0401 1632 1214 Amsterdam Ave. 1633 New York, NY 10027 1634 US 1636 EMail: schulzrinne@cs.columbia.edu 1637 URI: http://www.cs.columbia.edu/~hgs 1639 Rohan Mahy (editor) 1640 SIP Edge LLC 1642 EMail: rohan@ekabal.com 1644 Intellectual Property Statement 1646 The IETF takes no position regarding the validity or scope of any 1647 Intellectual Property Rights or other rights that might be claimed to 1648 pertain to the implementation or use of the technology described in 1649 this document or the extent to which any license under such rights 1650 might or might not be available; nor does it represent that it has 1651 made any independent effort to identify any such rights. Information 1652 on the procedures with respect to rights in RFC documents can be 1653 found in BCP 78 and BCP 79. 1655 Copies of IPR disclosures made to the IETF Secretariat and any 1656 assurances of licenses to be made available, or the result of an 1657 attempt made to obtain a general license or permission for the use of 1658 such proprietary rights by implementers or users of this 1659 specification can be obtained from the IETF on-line IPR repository at 1660 http://www.ietf.org/ipr. 1662 The IETF invites any interested party to bring to its attention any 1663 copyrights, patents or patent applications, or other proprietary 1664 rights that may cover technology that may be required to implement 1665 this standard. Please address the information to the IETF at 1666 ietf-ipr@ietf.org. 1668 Disclaimer of Validity 1670 This document and the information contained herein are provided on an 1671 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1672 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1673 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1674 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1675 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1676 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1678 Copyright Statement 1680 Copyright (C) The Internet Society (2005). This document is subject 1681 to the rights, licenses and restrictions contained in BCP 78, and 1682 except as set forth therein, the authors retain all their rights. 1684 Acknowledgment 1686 Funding for the RFC Editor function is currently provided by the 1687 Internet Society.