idnits 2.17.1 draft-ietf-sipping-dialog-package-05.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 1670. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1647. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1654. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1660. ** 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 (Nov 4, 2004) is 7112 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 1601, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 1605, 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-02 == 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: May 5, 2005 H. Schulzrinne 4 Columbia University 5 R. Mahy, Ed. 6 Airespace 7 Nov 4, 2004 9 An INVITE Inititiated Dialog Event Package for the Session 10 Initiation Protocol (SIP) 11 draft-ietf-sipping-dialog-package-05.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 May 5, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). 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, an receive notifications about the changes in state of INVITE 50 initiated dialogs 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 . . . . . . . . 7 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 116 dialogs. 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 dialogs. However, 120 the usage of this package to model transitions in the state of those 121 dialogs is out of the scope of this specification. 123 There are a variety of applications enabled through the knowledge of 124 INVITE dialog 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. 165 2. Terminology 167 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 168 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 169 and "OPTIONAL" are to be interpreted as described in RFC 2119 [9] and 170 indicate requirement levels for compliant implementations. 172 3. Dialog Event Package 174 This section provides the details for defining a SIP Events package, 175 as specified by [1]. 177 3.1 Event Package Name 179 The name of this event package is "dialog". This package name is 180 carried in the Event and Allow-Events header, as defined in [1]. 182 3.2 Event Package Parameters 184 This package defines four Event Package parameters. They are 185 call-id, to-tag, from-tag, and include-session-description. If a 186 subscription to a specific dialog is requested, all of the first 187 three of these parameters MUST be present. They identify the dialog 188 that is being subscribed to. The to-tag is matched against the local 189 tag, the from-tag is matched against the remote tag, and the call-id 190 is matched against the Call-ID. The include-session-description 191 parameter indicates if the subscriber would like to receive the 192 session descriptions associated with the subscribed dialog or 193 dialogs. 195 It is also possible to subscribe to the set of dialogs created as a 196 result of a single INVITE sent by a UAC. In that case, the call-id 197 and to-tag MUST be present. The to-tag is matched against the local 198 tag, and the call-id is matched against the Call-ID. 200 The ABNF for these parameters is shown below. It refers to many 201 constructions from the ABNF of RFC3261, such as EQUAL, DQUOTE, and 202 token. 204 call-id = "call-id" EQUAL ( token / DQUOTE callid DQUOTE ) 205 ;; NOTE: any DQUOTEs inside callid MUST be escaped! 206 from-tag = "from-tag" EQUAL token 207 to-tag = "to-tag" EQUAL token 208 with-sessd = "include-session-description" 210 Any callids which contain embedded double-quotes MUST escape those 211 double-quotes using the backslash-quoting mechanism. Note that the 212 call-id parameter may need to be expressed as a quoted string. This 213 is because the ABNF for callid and word (which is used by callid) 214 allow for some characters (such as "@", "[", and ":") which are not 215 allowed within a token. 217 3.3 SUBSCRIBE Bodies 219 A SUBSCRIBE for a dialog package MAY contain a body. This body 220 defines a filter to apply to the subscription. Filter documents are 221 not specified in this document, and at the time of writing, are 222 expected to be the subject of future standardization activity. 224 A SUBSCRIBE for a dialog package MAY be sent without a body. This 225 implies the default subscription filtering policy. The default 226 policy is: 227 o If the Event header field contained dialog identifiers, 228 notifications are generated every time there is a change in the 229 state of any matching dialogs for the user identified in the 230 request URI of the SUBSCRIBE. 231 o If there were no dialog identifiers in the Event header field, 232 notifications are generated every time there is any change in the 233 state of any dialogs for the user identified in the request URI of 234 the SUBSCRIBE with the following exceptions. If the target 235 (Contact) URI of a subscriber is equivalent to the remote target 236 URI of a specific dialog, then the dialog element for that dialog 237 is suppressed for that subscriber. (The subscriber is already a 238 party in the dialog directly, so these notifications are 239 superfluous.) If no dialogs remain after supressing dialogs, the 240 entire notification to that subscriber is supressed and the 241 version number in the dialog-info element is not incremented for 242 that subscriber. Implicit filtering for one subscriber does not 243 affect notifications to other subscribers. 244 o Notifications do not normally contain full state; rather, they 245 only indicate the state of the dialog whose state has changed. 246 The exceptions are a NOTIFY sent in response to a SUBSCRIBE, and a 247 NOTIFY that contains no dialog elements. These NOTIFYs contain 248 the complete view of dialog state. 249 o The notifications contain the identities of the participants in 250 the dialog, the target URIs, and the dialog identifiers. Session 251 descriptions are not included normally unless explicitly requested 252 and/or explicitly authorized. 254 3.4 Subscription Duration 256 Dialog state changes fairly quickly; once established, a typical 257 phone call lasts a few minutes (this is different for other session 258 types, of course). However, the interval between new calls is 259 typically infrequent. As such, we arbitrarily choose a default 260 duration of one hour. Clients SHOULD specify an explicit duration. 262 There are two distinct use cases for dialog state. The first is when 263 a subscriber is interested in the state of a specific dialog or 264 dialogs (and they are authorized to find out about just the state of 265 those dialogs). In that case, when the dialogs terminate, so too 266 does the subscription. In these cases, the value of the subscription 267 duration is largely irrelevant, and SHOULD be longer than the typical 268 duration of a dialog, about two hours would cover most dialogs. 270 In another case, a subscriber is interested in the state of all 271 dialogs for a specific user. In these cases, a shorter interval 272 makes more sense. The default is one hour for these subscriptions. 274 3.5 NOTIFY Bodies 276 As described in RFC 3265 [1], the NOTIFY message will contain bodies 277 that describe the state of the subscribed resource. This body is in 278 a format listed in the Accept header field of the SUBSCRIBE, or a 279 package-specific default if the Accept header field was omitted from 280 the SUBSCRIBE. 282 In this event package, the body of the notification contains a dialog 283 information document. This document describes the state of one or 284 more dialogs associated with the subscribed resource. All 285 subscribers and notifiers MUST support the 286 "application/dialog-info+xml" data format described in Section 4. 287 The subscribe request MAY contain an Accept header field. If no such 288 header field is present, it has a default value of 289 "application/dialog-info+xml". If the header field is present, it 290 MUST include "application/dialog-info+xml", and MAY include any other 291 types capable of representing dialog state. 293 Of course, the notifications generated by the server MUST be in one 294 of the formats specified in the Accept header field in the SUBSCRIBE 295 request. 297 3.6 Notifier Processing of SUBSCRIBE Requests 299 The dialog information for a user contains sensitive information. 301 Therefore, all subscriptions SHOULD be authenticated and then 302 authorized before approval. All implementors of this package MUST 303 support the digest authentication mechanism as a baseline. 304 Authorization policy is at the discretion of the administrator, as 305 always. However, a few recommendations can be made. 307 It is RECOMMENDED that, if the policy of user B is that user A is 308 allowed to call them, dialog subscriptions from user A be allowed. 309 However, the information provided in the notifications does not 310 contain any dialog identification information; merely an indication 311 of whether the user is in at least one call, or not. Specifically, 312 they should not be able to find out any more information than if they 313 sent an INVITE. (This concept of a "virtual" dialog is discussed 314 more in Section 3.7.2, and an example of such a notification body is 315 shown below.) 316 317 320 321 confirmed 322 323 325 It is RECOMMENDED that if a user agent registers with the 326 address-of-record X, that this user agent authorize subscriptions 327 that come from any entity that can authenticate itself as X. 328 Complete information on the dialog state SHOULD be sent in this case. 329 This authorization behavior allows a group of devices representing a 330 single user to all become aware of each other's state. This is 331 useful for applications such as single-line-extension. 332 Note that many implementations of "shared-lines" have a feature 333 which allows details of calls on a shared address-of-record to be 334 made private. This is a completely reasonable authorization 335 policy which could result in notifications which contain only the 336 id attribute of the dialog element and the state element when 337 shared-line privacy is requested, and notifications with more 338 complete information when shared-line privacy is not requested. 340 3.7 Notifier Generation of NOTIFY Requests 342 Notifications are generated for the dialog package when an INVITE 343 request is sent, when a new dialog comes into existence at a UA, or 344 when the state or characteristics of an existing dialog changes. 345 Therefore, a model of dialog state is needed in order to determine 346 precisely when to send notifications, and what their content should 347 be. The SIP specification has a reasonably well defined lifecycle 348 for dialogs. However, it is not explicitly modelled. This 349 specification provides an explicit model of dialog state through a 350 finite state machine. 352 It is RECOMMENDED that NOTIFY requests only contain information on 353 the dialogs whose state or participation information has changed. 354 However, if a notifier receives a SUBSCRIBE request, the triggered 355 NOTIFY SHOULD contain the state of all dialogs that the subscriber is 356 authorized to see. 358 3.7.1 The Dialog State Machine 360 Modelling of dialog state is complicated by two factors. The first 361 is forking, which can cause a single INVITE to generate many dialogs 362 at a UAC. The second is the differing views of state at the UAC and 363 UAS. We have chosen to handle the first issue by extending the 364 dialog FSM to include the states between transmission of the INVITE 365 and the creation of actual dialogs through receipt of 1xx and 2xx 366 responses. As a result, this specification supports the notion of 367 dialog state for dialogs before they are fully instantiated. 369 We have also chosen to use a single FSM for both UAC and UAS. 371 +----------+ +----------+ 372 | | 1xx-notag | | 373 | |----------->| | 374 | Trying | |Proceeding|-----+ 375 | |---+ +-----| | | 376 | | | | | | | 377 +----------+ | | +----------+ | 378 | | | | | | 379 | | | | | | 380 +<--C-----C--+ |1xx-tag | 381 | | | | | 382 cancelled| | | V | 383 rejected| | |1xx-tag +----------+ | 384 | | +------->| | |2xx 385 | | | | | 386 +<--C--------------| Early |-----C---+ 1xx-tag 387 | | replaced | | | | w/new tag 388 | | | |<----C---+ (new FSM 389 | | +----------+ | instance 390 | | 2xx | | created) 391 | +----------------+ | | 392 | | |2xx | 393 | | | | 394 V V V | 395 +----------+ +----------+ | 396 | | | | | 397 | | | | | 398 |Terminated|<-----------| Confirmed|<----+ 399 | | error | | 400 | | timeout | | 401 +----------+ replaced +----------+ 402 local-bye | ^ 403 remote-bye | | 404 | | 405 +------+ 406 2xx w. new tag 407 (new FSM instance 408 created) 410 Figure 3 412 The FSM for dialog state is shown in Figure 3. The FSM is best 413 understood by considering the UAC and UAS cases separately. 415 The FSM is created in the "trying" state when the UAC sends an INVITE 416 request. Upon receipt of a 1xx without a tag, the FSM transitions to 417 the "proceeding" state. Note that there is no actual dialog yet, as 418 defined by the SIP specification. However, there is a "half-dialog", 419 in the sense that two of the three components of the dialog ID are 420 known (the call identifier and local tag). If a 1xx with a tag is 421 received, the FSM transitions to the early state. The full dialog 422 identifier is now defined. Had a 2xx been received, the FSM would 423 have transitioned to the "confirmed" state. 425 If, after transitioning to the "early" or "confirmed" states, the UAC 426 receives another 1xx or 2xx respectively with a different tag, 427 another instance of the FSM is created, initialized into the "early" 428 or "confirmed" state respectively. The benefit of this approach is 429 that there will be a single FSM representing the entire state of the 430 invitation and resulting dialog when dealing with the common case of 431 no forking. 433 If the UAC should send a CANCEL, and then subsequently receive a 487 434 to its INVITE transaction, all FSMs spawned from that INVITE 435 transition to the "terminated" state with the event "cancelled". If 436 the UAC receives a new invitation (with a Replaces [13] header) which 437 replaces the current Early or Confirmed dialog, all INVITE 438 transactions spawned from the replaced invitation transition to the 439 "terminated" state with the event "replaced". If the INVITE 440 transaction terminates with a non-2xx response for any other reason, 441 all FSMs spawned from that INVITE transition to the terminated state 442 with the event "rejected". 444 Once in the confirmed state, the call is active. It can transition 445 to the terminated state if the UAC sends a BYE or receives a BYE 446 (corresponding to the "local-bye" and "remote-bye" events as 447 appropriate), if a mid-dialog request generates a 481 or 408 response 448 (corresponding to the "error" event), or a mid-dialog request 449 generates no response (corresponding to the "timeout" event). 451 From the perspective of the UAS, when an INVITE is received, the FSM 452 is created in the "trying" state. If it sends a 1xx without a tag, 453 the FSM transitions to the "proceeding" state. If a 1xx is sent with 454 a tag, the FSM transitions to the "early" state, and if a 2xx is 455 sent, it transitions to the "confirmed" state. If the UAS should 456 receive a CANCEL request and then generate a 487 response to the 457 INVITE (which can occur in the proceeding and early states), the FSM 458 transitions to the terminated state with the event "cancelled". If 459 the UAS should generate any other non-2xx final response to the 460 INVITE request, the FSM transitions to the terminated state with the 461 event "rejected". If the UAS receives a new invitation (with a 462 Replaces [13] header) which replaces the current Confirmed dialog, 463 the replaced invitation transition transitions to the "terminated" 464 state with the event "replaced". Once in the "confirmed" state, the 465 other transitions to the "terminated" state occur for the same 466 reasons they do in the case of UAC. 468 There should never be a transition from the "trying" state to the 469 "terminated" state with the event "cancelled", since the SIP 470 specification prohibits transmission of CANCEL until a provisional 471 response is received. However, this transition is defined in the 472 FSM just to unify the transitions from trying, proceeding, and 473 early to the terminated state. 475 3.7.2 Applying the state machine 477 The notifier MAY generate a NOTIFY request on any event transition of 478 the FSM. Whether it does or not is policy dependent. However, some 479 general guidelines are provided. 481 When the subscriber is unauthenticated, or is authenticated, but 482 represents a third party with no specific authorization policies, it 483 is RECOMMENDED that subscriptions to an individual dialog, or to a 484 specific set of dialogs, is forbidden. Only subscriptions to all 485 dialogs (i.e., there are no dialog identifiers in the Event header 486 field) are permitted. In that case, actual dialog states across all 487 dialogs will not be reported. Rather, a single "virtual" dialog FSM 488 be used, and event transitions on that FSM be reported. 490 If there is any dialog at the UA whose state is "confirmed", the 491 virtual FSM is in the "confirmed" state. If there are no dialogs at 492 the UA in the confirmed state, but there is at least one in the 493 "early" state, the virtual FSM is in the "early" or "confirmed" 494 state. If there are no dialogs in the confirmed or early states, but 495 there is at least one in the "proceeding" state, the virtual FSM is 496 in the "proceeding", "early" or "confirmed" state. If there are no 497 dialogs in the confirmed, early, or proceeding states, but there is 498 at least one in the "trying" state, the virtual FSM is in the 499 "trying", "proceeding", "early" or "confirmed" state. The choice 500 about which state to use depends on whether the UA wishes to let 501 unknown users know that their phone is ringing, as opposed to in an 502 active call. 504 It is RECOMMENDED that, in the absence of any preference, "confirmed" 505 is used in all cases (as shown in the example in Section 3.6. 506 Furthermore, it is RECOMMENDED that the notifications of changes in 507 the virtual FSM machine not convey any information except the state 508 of the FSM and its event transitions - no dialog identifiers (which 509 are ill-defined in this model in any case). The use of this virtual 510 FSM allows for minimal information to be conveyed. A subscriber 511 cannot know how many calls are in progress, or with whom, just that 512 there exists a call. This is the same information they would receive 513 if they simply sent an INVITE to the user instead; a 486 response 514 would indicate that they are on a call. 516 When the subscriber is authenticated, and has authenticated itself 517 with the same address-of-record that the UA itself uses, if no 518 explicit authorization policy is defined, it is RECOMMENDED that all 519 state transitions on dialogs that have been subscribed to (which is 520 either all of them, if no dialog identifiers were present in the 521 Event header field, or a specific set of them identified by the Event 522 header field parameters) be reported, along with complete dialog IDs. 524 The notifier SHOULD generate a NOTIFY request on any change in the 525 characteristics associated with the dialog. Since these include 526 Contact URIs, Contact parameters and session descriptions, receipt of 527 re-INVITEs and UPDATE requests [3] which modify this information MAY 528 trigger notifications. 530 3.8 Subscriber Processing of NOTIFY Requests 532 The SIP Events framework expects packages to specify how a subscriber 533 processes NOTIFY requests in any package specific ways, and in 534 particular, how it uses the NOTIFY requests to contruct a coherent 535 view of the state of the subscribed resource. 537 Typically, the NOTIFY for the dialog package will only contain 538 information about those dialogs whose state has changed. To 539 construct a coherent view of the total state of all dialogs, a 540 subscriber to the dialog package will need to combine NOTIFYs 541 received over time. 543 Notifications within this package can convey partial information; 544 that is, they can indicate information about a subset of the state 545 associated with the subscription. This means that an explicit 546 algorithm needs to be defined in order to construct coherent and 547 consistent state. The details of this mechanism are specific to the 548 particular document type. See Section 4.3 for information on 549 constructing coherent information from an application/dialog-info+xml 550 document. 552 3.9 Handling of Forked Requests 554 Since dialog state is distributed across the UA for a particular 555 user, it is reasonable and useful for a SUBSCRIBE request for dialog 556 state to fork, and reach multiple UA. 558 As a result, a forked SUBSCRIBE request for dialog state can install 559 multiple subscriptions. Subscribers to this package MUST be prepared 560 to install subscription state for each NOTIFY generated as a result 561 of a single SUBSCRIBE. 563 3.10 Rate of Notifications 565 For reasons of congestion control, it is important that the rate of 566 notifications not become excessive. As a result, it is RECOMMENDED 567 that the server not generate notifications for a single subscriber at 568 a rate faster than once every 1 second. 570 3.11 State Agents 572 Dialog state is ideally maintained in the user agents in which the 573 dialog resides. Therefore, the elements that maintain the dialog are 574 the ones best suited to handle subscriptions to it. However, in some 575 cases, a network agent may also know the state of the dialogs held by 576 a user. As such, state agents MAY be used with this package. 578 4. Dialog Information Format 580 Dialog information is an XML document [4] that MUST be well-formed 581 and SHOULD be valid. Dialog information documents MUST be based on 582 XML 1.0 and MUST be encoded using UTF-8. This specification makes 583 use of XML namespaces for identifying dialog information documents 584 and document fragments. The namespace URI for elements defined by 585 this specification is a URN [5], using the namespace identifier 586 'ietf' defined by [6] and extended by [7]. This URN is: 588 urn:ietf:params:xml:ns:dialog-info 590 A dialog information document begins with the root element tag 591 "dialog-info". 593 4.1 Structure of Dialog Information 595 A dialog information document starts with a dialog-info element. 596 This element has three mandatory attributes: 597 version: This attribute allows the recipient of dialog information 598 documents to properly order them. Versions start at 0, and 599 increment by one for each new document sent to a subscriber. 600 Versions are scoped within a subscription. Versions MUST be 601 representable using a 32 bit integer. 602 state: This attribute indicates whether the document contains the 603 full dialog information, or whether it contains only information 604 on those dialogs which have changed since the previous document 605 (partial). 606 entity: This attribute contains a URI that identifies the user whose 607 dialog information is reported in the remainder of the document. 608 This user is referred to as the "observed user". 610 The dialog-info element has a series of zero or more dialog 611 sub-elements. Each of those represents a specific dialog. 612 613 616 618 4.1.1 Dialog Element 620 The dialog element reports information on a specific dialog or 621 "half-dialog". It has single mandatory attribute: id. The id 622 attribute provides a single string that can be used as an identifier 623 for this dialog or "half-dialog". This is a different identifier 624 than the dialog ID defined in RFC 3261 [2], but related to it. 626 For a caller, the id is created when an INVITE request is sent. When 627 a 1xx with a tag, or a 2xx is received, the dialog is formally 628 created. The id remains unchanged. However, if an additional 1xx or 629 2xx is received, resulting in the creation of another dialog (and 630 resulting FSM), that dialog is allocated a new id. 632 For a callee, the id is created when an INVITE outside of an existing 633 dialog is received. When a 2xx or a 1xx with a tag is sent, creating 634 the dialog, the id remains unchanged. 636 The id MUST be unique amongst all dialogs at a UA. 638 There are a number of optional attributes which provide 639 identification information about the dialog: 640 call-id: This attribute is a string which represents the call-id 641 component of the dialog identifier. (Note that single and double 642 quotes inside a call-id must be escaped using "e; for " and 643 ' for ' .) 644 local-tag: This attribute is a string which represents the local-tag 645 component of the dialog identifier. 646 remote-tag: This attribute is a string which represents the 647 remote-tag component of the dialog identifier. The remote tag 648 attribute won't be present if there is only a "half-dialog", 649 resulting from the generation of an INVITE for which no final 650 responses or provisional responses with tags has been received. 651 direction: This attribute is either initiator or recipient, and 652 indicates whether the observed user was the initiator of the 653 dialog, or the recipient of the INVITE that created it. 655 656 659 661 ... 662 663 665 The sub-elements of the dialog element provide additional information 666 about the dialog. Some of these sub-elements provide more detail 667 about the dialog itself, while the local and remote sub-elements 668 describe characteristics of the participants involved in the dialog. 669 The only mandatory sub-element is the state element. 671 4.1.2 State 673 The state element indicates the state of the dialog. Its value is an 674 enumerated type describing one of the states in the FSM above. It 675 has an optional event attribute that can be used to indicate the 676 event which caused any transition into the terminated state, and an 677 optional code attribute that indicates the response code associated 678 with any transition caused by a response to the original INVITE. 680 terminated 682 4.1.3 Duration 684 The duration element contains the amount of time, in seconds, since 685 the FSM was created. 687 145 689 4.1.4 Replaces 691 The replaces element is used to correlate a new dialog with one it 692 replaced as a result of an invitation with a Replaces header. This 693 element is present in the replacement dialog only (the newer dialog) 694 and contains attributes with the call-id, local-tag, and remote-tag 695 of the replaced dialog. 697 700 4.1.5 Referred-By 702 The referred-by element is used to correlate a new dialog with a 703 REFER [12] request which triggered it. The element is present in a 704 dialog which was triggered by a REFER request which contained a 705 Referred-By [11] header and contains the (optional) display name 706 attribute and the Referred-By URI as its value. 708 sip:bob@example.com 710 4.1.6 Local and Remote elements 712 The local and remote elements are sub-elements of the dialog element 713 which contain information about the local and remote participants 714 respectively. They both have a number of optional sub-elements which 715 indicate the identity conveyed by the participant, the target URI, 716 the feature-tags of the target, and the session-description of the 717 participant. 719 4.1.6.1 Identity 721 The identity element indicates a local or remote URI, as defined in 722 [2] as appropriate. It has an optional attribute, display, that 723 contains the display name from the appropriate URI. 724 Note that multiple identities (for example a sip: URI and a tel: 725 URI) could be included if they all correspond to the participant. 726 To avoid repeating identity information in each request, the 727 subscriber can assume that the identity URIs are the same as in 728 previous notifications if no identity elements are present in the 729 corresponding local or remote element. If any identity elements 730 are present in the local or remote part of a notification, the new 731 list of identity tags completely supersedes the old list in the 732 corresponding part. 734 735 sip:anonymous@anonymous.invalid 737 4.1.6.2 Target 739 The target contains the local or remote target URI as constructed by 740 the user agent for this dialog, as defined in RFC 3261 [2] in a "uri" 741 attribute. 743 It can contain a list of Contact header parameters in param 744 sub-elements (such as those defined in [10]. The param element 745 contains two required attributes, pname and pval. (Boolean 746 parameters are represented by the explicit pval values "true" and 747 "false" [for example when a feature parameter is explicitly 748 negated]). The param element itself has no contents. To avoid 749 repeating Contact information in each request, the subscriber can 750 assume that the target URI and parameters are the same as in previous 751 notifications if no target element is present in the corresponding 752 local or remote element. If a target element is present in the local 753 or remote part of a notification, the new target tag and list of an 754 parameter tags completely supersedes the old target and parameter 755 list in the corresponding part. 757 758 759 760 762 4.1.6.3 Session Description 764 The session-description element contains the session description used 765 by the observed user for its end of the dialog. This element should 766 generally NOT be included in the notifications, unless explicitly 767 requested by the subscriber. It has a single attribute, type, which 768 indicates the MIME media type of the session description. To avoid 769 repeating session description information in each request, the 770 subscriber can assume that the session description is the same as in 771 previous notifications if no session description element is present 772 in the corresponding local or remote element. 774 4.2 Sample Notification Body 776 777 781 782 confirmed 783 274 784 785 sip:alice@example.com 786 787 788 789 790 791 792 sip:bob@example.org 793 794 795 796 798 4.3 Constructing Coherent State 800 The dialog information subscriber maintains a table for the list of 801 dialogs. The table contains a row for each dialog. Each row is 802 indexed by an ID, present in the "id" attribute of the "dialog" 803 element. The contents of each row contain the state of that dialog 804 as conveyed in the document. The table is also associated with a 805 version number. The version number MUST be initialized with the 806 value of the "version" attribute from the "dialog-info" element in 807 the first document received. Each time a new document is received, 808 the value of the local version number, and the "version" attribute in 809 the new document, are compared. If the value in the new document is 810 one higher than the local version number, the local version number is 811 increased by one, and the document is processed. If the value in the 812 document is more than one higher than the local version number, the 813 local version number is set to the value in the new document, and the 814 document is processed. If the document did not contain full state, 815 the subscriber SHOULD generate a refresh request to trigger a full 816 state notification. If the value in the document is less than the 817 local version, the document is discarded without processing. 819 The processing of the dialog information document depends on whether 820 it contains full or partial state. If it contains full state, 821 indicated by the value of the "state" attribute in the "dialog-info" 822 element, the contents of the table are flushed. They are repopulated 823 from the document. A new row in the table is created for each 824 "dialog" element. If the document contains partial state, as 825 indicated by the value of the "state" attribute in the "dialog-info" 826 element, the document is used to update the table. For each "dialog" 827 element in the document, the subscriber checks to see whether a row 828 exists for that dialog. This check is done by comparing the ID in 829 the "id" attribute of the "dialog" element with the ID associated 830 with the row. If the dialog doesn't exist in the table, a row is 831 added, and its state is set to the information from that "dialog" 832 element. If the dialog does exist, its state is updated to be the 833 information from that "dialog" element. If a row is updated or 834 created, such that its state is now terminated, that entry MAY be 835 removed from the table at any time. 837 4.4 Schema 839 The following is the schema for the application/dialog-info+xml type: 841 842 848 849 851 852 853 854 856 858 859 861 862 863 864 865 866 867 869 870 871 872 873 874 875 876 877 879 880 881 883 885 887 888 889 891 892 893 894 896 897 898 899 901 903 905 906 907 909 911 913 914 915 916 917 918 919 920 921 922 923 924 925 927 928 929 930 932 933 935 937 938 939 940 941 942 943 945 947 949 950 951 952 953 954 956 957 958 959 960 961 962 963 964 966 967 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 998 5. Definition of new media feature parameters 1000 5.1 The "sip.byeless" parameter 1002 The "sip.byeless" media feature parameter is a new boolean parameter, 1003 defined in this document, which provides a positive indication that 1004 the User Agent setting the parameter is unable to terminate sessions 1005 on its own (for example, by sending a BYE request). For example, 1006 continuous announcement services and certain recording services are 1007 unable to determine when it would be desirable to terminate a session 1008 and therefore do not have the ability to terminate sessions at all. 1009 Also, many human call centers are configured so that they never 1010 terminate sessions. (This is to prevent call center agents from 1011 accidentally disconnecting the caller.) 1012 Contact: 1013 ;automaton;+sip.byeless 1015 5.2 The "sip.rendering" parameter 1017 The "sip.rendering" media feature parameter is a new string 1018 parameter, defined in this document, which can provide a positive 1019 indication whether the User Agent setting the parameter is currently 1020 rendering any of the media it is receiving in the context of a 1021 specific session. It MUST only be used in a Contact header field in 1022 a dialog created using the INVITE request. (Note that per [10] this 1023 parameter name must be preceeded by a "+" character when used in a 1024 SIP Contact header field.) 1026 This parameter has three legal values: "yes", "no", and "unknown". 1027 The value "yes" indicates positive knowledge that the User Agent is 1028 rendering at least one of the streams of media that it is receiving. 1029 The value "no" indicates positive knowledge that the User Agent is 1030 rendering none of the media that it is receiving. The value 1031 "unknown" indicates that the User Agent does not know whether the 1032 media associated with the session is being rendered. (which may be 1033 the case if the User Agent is acting as a 3pcc (Third Party Call 1034 Control) [19] controller). 1036 The "sip.rendering" parameter is useful in applications such as 1037 shared appearances, conference status monitoring, or as an input to 1038 user presence. 1040 Contact: 1041 ;automaton;+sip.rendering="no" 1043 6. Examples 1045 6.1 Basic Example 1047 For example, if a UAC sends an INVITE that looks like, in part: 1049 INVITE sip:bob@example.com SIP/2.0 1050 Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8 1051 Max-Forwards: 70 1052 To: Bob 1053 From: Alice ;tag=1928301774 1054 Call-ID: a84b4c76e66710 1055 CSeq: 314159 INVITE 1056 Contact: 1057 Content-Type: application/sdp 1058 Content-Length: 142 1060 [SDP not shown] 1062 The XML document in a notification from Alice might look like: 1064 1065 1069 1071 trying 1072 1073 1075 If the following 180 response is received: 1077 SIP/2.0 180 Ringing 1078 Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8 1079 To: Bob ;tag=456887766 1080 From: Alice ;tag=1928301774 1081 Call-ID: a84b4c76e66710 1082 CSeq: 314159 INVITE 1083 Contact: 1085 The XML document in a notification might look like: 1087 1088 1092 1095 early 1096 1097 1099 If it receives a second 180 with a different tag: 1101 SIP/2.0 180 Ringing 1102 Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8 1103 To: Bob ;tag=hh76a 1104 From: Alice ;tag=1928301774 1105 Call-ID: a84b4c76e66710 1106 CSeq: 314159 INVITE 1107 Contact: 1109 This results in the creation of a second dialog: 1111 1112 1116 1119 early 1120 1121 1124 early 1125 1126 1128 If a 200 OK is received on the second dialog, it moves to confirmed: 1130 1131 1135 1138 confirmed 1139 1140 1142 32 seconds later, the other early dialog terminates because no 2xx is 1143 received for it. This implies that it was successfully cancelled, 1144 and therefore the following notification is sent: 1146 1147 1151 1154 terminated 1155 1156 1158 6.2 Emulating a Shared-Line phone system 1160 The following example shows how a SIP telephone user agent can 1161 provide detailed state information and also emulate a shared-line 1162 telephone system (the phone "lies" about having a dialog while it is 1163 merely offhook). 1165 Idle: 1167 1168 1171 1173 Seized: 1175 1176 1179 1180 trying 1181 1182 1184 Dialing: 1186 1187 1190 1192 trying 1193 1194 1195 sip:alice@example.com 1196 1197 1198 1199 1200 sip:bob@example.net 1201 1202 1203 1205 Ringing: 1207 1208 1211 1214 early 1215 1216 1217 1218 1219 1221 Answered (by voicemail): 1223 1224 1227 1230 terminated 1231 1232 1235 confirmed 1236 1237 1238 1239 1240 1241 1242 1243 1244 1246 Alice requests voicemail for Bob's attendant. 1247 (Alice presses "0" in North America / "9" in Europe) 1248 Voicemail completes a transfer with Cathy 1250 1251 1254 1257 terminated 1258 1259 1262 confirmed 1263 1266 1267 sip:bob-is-not-here@vm.example.net 1268 1269 1270 1271 1273 1274 1275 1276 sip:cjones@example.net 1277 1278 1279 1280 1281 1282 1283 1284 1286 Alice and Cathy talk, Cathy adds Alice to a local conference. 1288 1289 1292 1295 confirmed 1296 1297 1298 1299 1300 1301 1302 1304 Alice puts Cathy on hold 1306 1307 1310 1313 confirmed 1314 1315 1316 1317 1318 1319 1320 1321 Cathy hangs up 1323 1324 1327 1330 terminated 1331 1332 1333 trying 1334 1335 1337 Alice hangs up: 1339 1340 1343 1345 6.3 Minimal Dialog Information with Privacy 1347 The following example shows the same user agent providing minimal 1348 information to maintain privacy for services like automatic callback. 1350 Onhook: 1352 1353 1356 1358 Offhook: (implementation/policy choice for Alice to transition 1359 to this "state" when "seized", when Trying, when Proceeding, 1360 or when Confirmed.) 1362 1363 1366 1367 confirmed 1368 1369 1371 Onhook: (implementation/policy choice for Alice to transition to 1372 this "state" when terminated, or when no longer "seized") 1374 1375 1378 1380 7. Security Considerations 1382 Subscriptions to dialog state can reveal sensitive information. For 1383 this reason, Section 3.6 discusses authentication and authorization 1384 of subscriptions, and provides guidelines on sensible authorization 1385 policies. All implementations of this package MUST support the 1386 digest authentication mechanism. 1388 Since the data in notifications is sensitive as well, end-to-end SIP 1389 encryption mechanisms using S/MIME MAY be used to protect it. User 1390 Agents that implement the dialog package SHOULD also implement SIP 1391 over TLS [15] and the sips: scheme. 1393 8. IANA Considerations 1395 This document registers a new MIME type, application/dialog-info+xml; 1396 a new XML namespace; and two new media feature parameters in the SIP 1397 tree. 1399 8.1 application/dialog-info+xml MIME Registration 1400 MIME media type name: application 1401 MIME subtype name: dialog-info+xml 1402 Mandatory parameters: none 1403 Optional parameters: Same as charset parameter application/xml as 1404 specified in RFC 3023 [8]. 1405 Encoding considerations: Same as encoding considerations of 1406 application/xml as specified in RFC 3023 [8]. 1407 Security considerations: See Section 10 of RFC 3023 [8] and Section 7 1408 of this specification. 1409 Interoperability considerations: none. 1410 Published specification: This document. 1411 Applications which use this media type: This document type has been 1412 used to support SIP applications such as call return and 1413 auto-conference. 1414 Additional Information: 1415 Magic Number: None 1416 File Extension: .dif or .xml 1417 Macintosh file type code: "TEXT" 1418 Personal and email address for further information: Jonathan 1419 Rosenberg, 1420 Intended usage: COMMON 1421 Author/Change controller: The IETF. 1423 8.2 URN Sub-Namespace Registration for 1424 urn:ietf:params:xml:ns:dialog-info 1426 This section registers a new XML namespace, as per the guidelines in 1427 [7]. 1428 URI: The URI for this namespace is 1429 urn:ietf:params:xml:ns:dialog-info. 1430 Registrant Contact: IETF, SIPPING working group, , 1431 Jonathan Rosenberg . 1432 XML: 1434 BEGIN 1435 1436 1438 1439 1440 1442 Dialog Information Namespace 1443 1444 1445

Namespace for Dialog Information

1446

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

1447

See RFCXXXX.

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