idnits 2.17.1 draft-ietf-sipping-dialog-package-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 149: '...a dialog package MAY contain a body. T...' RFC 2119 keyword, line 152: '...a dialog package MAY be sent without a...' RFC 2119 keyword, line 189: '... irrelevant, and SHOULD be longer than...' RFC 2119 keyword, line 200: '...ml". All subscribers MUST support this...' RFC 2119 keyword, line 201: '... format, and MUST list its type in a...' (26 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 (June 24, 2002) is 7948 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 2141 (ref. '4') (Obsoleted by RFC 8141) ** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 3023 (ref. '7') (Obsoleted by RFC 7303) Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force SIPPING WG 3 Internet Draft J. Rosenberg 4 dynamicsoft 5 H. Schulzrinne 6 Columbia U. 7 draft-ietf-sipping-dialog-package-00.txt 8 June 24, 2002 9 Expires: December 2002 11 A Session Initiation Protocol (SIP) Event Package for Dialog State 13 STATUS OF THIS MEMO 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 To view the list Internet-Draft Shadow Directories, see 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document defines a dialog event package for the SIP Events 37 architecture, along with a data format used in notifications for this 38 package. The dialog package allows users to subscribe to another 39 user, an receive notifications about the changes in state of INVITE 40 initiated dialogs that the user is involved in. 42 Table of Contents 44 1 Introduction ........................................ 4 45 2 Dialog Event Package ................................ 5 46 2.1 Event Package Name .................................. 5 47 2.2 Event Package Parameters ............................ 5 48 2.3 SUBSCRIBE Bodies .................................... 5 49 2.4 Subscription Duration ............................... 5 50 2.5 NOTIFY Bodies ....................................... 6 51 2.6 Notifier Processing of SUBSCRIBE Requests ........... 6 52 2.7 Notifier Generation of NOTIFY Requests .............. 7 53 2.7.1 The Dialog State Machine ............................ 7 54 2.7.2 Applying the state machine .......................... 9 55 2.8 Subscriber Processing of NOTIFY Requests ............ 10 56 2.9 Handling of Forked Requests ......................... 11 57 2.10 Rate of Notifications ............................... 11 58 2.11 State Agents ........................................ 11 59 3 Dialog Information Format ........................... 11 60 3.1 Structure of Dialog Information ..................... 12 61 3.1.1 Dialog Element ...................................... 12 62 3.1.2 State ............................................... 13 63 3.1.3 Local URI ........................................... 13 64 3.1.4 Remote URI .......................................... 13 65 3.1.5 Local Session Description ........................... 13 66 3.1.6 Remote Session Description .......................... 13 67 3.1.7 Remote Target ....................................... 13 68 3.1.8 Local CSeq .......................................... 14 69 3.1.9 Remote CSeq ......................................... 14 70 3.1.10 Duration ............................................ 14 71 3.2 Constructing Coherent State ......................... 14 72 3.3 Schema .............................................. 15 73 3.4 Example ............................................. 18 74 4 Security Considerations ............................. 20 75 5 IANA Considerations ................................. 20 76 5.1 application/dialog-info+xml MIME Registration ....... 20 77 5.2 URN Sub-Namespace Registration for 78 urn:ietf:params:xml:ns:dialog-info ............................. 21 79 6 Acknowledgements .................................... 22 80 7 Authors Addresses ................................... 22 81 8 Normative References ................................ 22 82 9 Informative References .............................. 23 84 1 Introduction 86 The SIP Events framework [1] defines general mechanisms for 87 subscription to, and notification of, events within SIP networks. It 88 introduces the notion of a package, which is a specific 89 "instantiation" of the events mechanism for a well-defined set of 90 events. Packages have been defined for user presence [8], watcher 91 information [9], and message waiting indicators [10], amongst others. 92 Here, we define an event package for INVITE initiated dialogs. 93 Dialogs refer to the SIP relationship established between two SIP 94 peers [2]. 96 There are a variety of applications enabled through the knowledge of 97 dialog state. Some examples include: 99 Automatic Callback: In this basic PSTN application, user A calls 100 user B. User B is busy. User A would like to get a callback 101 when user B hangs up. When B hangs up, user A's phone 102 rings. When A picks it up, they here ringing, and are being 103 connected to B. In VoIP, this requires A to receive a 104 notification when the dialogs at A are complete. 106 Presence-Enabled Conferencing: In this application, a user A 107 wishes to set up a conference call with users B and C. 108 Rather than scheduling it, it is to be created 109 automatically when A, B and C are all available. To do 110 this, the server providing the application would like to 111 know whether A, B and C are "online", not idle, and not in 112 a phone call. Determining whether or not A, B and C are in 113 calls can be done in two ways. In the first, the server 114 acts as a call stateful proxy for users A, B and C, and 115 therefore knows their call state. This won't always be 116 possible, however, and it introduces scalability, 117 reliability, and operational complexities. Rather, the 118 server would subscriber to the dialog state of those users, 119 and receive notifications as it changes. This enables the 120 application to be provided in a distributed way; the server 121 need not reside in the same domain as the users. 123 IM Conference Alerts: In this application, a user can get an IM 124 sent to their phone whenever someone joins a conference 125 that the phone is involved in. The IM alerts are generated 126 by an application separate from the conference server. 128 In general, the dialog package allows for construction of distributed 129 applications, where the application requires information on dialog 130 state, but is not co-resident with the end user on which that state 131 resides. 133 2 Dialog Event Package 135 This section provides the details for defining a SIP Events package, 136 as specified by [1]. 138 2.1 Event Package Name 140 The name of this event package is "dialog". This package name is 141 carried in the Event and Allow-Events header, as defined in [1]. 143 2.2 Event Package Parameters 145 This package does not define any event package parameters. 147 2.3 SUBSCRIBE Bodies 149 A SUBSCRIBE for a dialog package MAY contain a body. This body 150 defines a filter to apply to the subscription. 152 A SUBSCRIBE for a dialog package MAY be sent without a body. This 153 implies the default subscription filtering policy. The default policy 154 is: 156 o Notifications are generated every time there is any change in 157 the state of any dialogs for the user identified in the 158 request URI of the SUBSCRIBE. 160 o Notifications do not normally contain full state; rather, they 161 only indicate the state of the dialog whose state has changed. 162 The exception is a NOTIFY sent in response to a SUBSCRIBE. 163 These NOTIFYs contain the complete view of dialog state. 165 o The notifications contain the identities of the participants 166 in the dialog, and the dialog identifiers. Additional 167 information, such as the route set, remote target URI, CSeq 168 numbers, SDP information, and so on, are not included normally 169 unless explicitly requested and/or explicitly authorized. 171 OPEN ISSUE: It might be useful to define a filter within 172 this document that would allow a subscriber to ask about a 173 specific dialog. 175 2.4 Subscription Duration 177 Dialog state changes fairly quickly; once established, a typical 178 phone call lasts a few minutes (this is different for other session 179 types, of course). However, the interval between new calls is 180 typically infrequent. As such, we arbitrarily choose a default 181 duration of one hour, and RECOMMEND that clients specify an explicit 182 duration. 184 There are two distinct use cases for dialog state. The first is when 185 a subscriber is interested in the state of a specific dialog (and 186 they are authorized to find out about just the state of that dialog). 187 In that case, when the dialog terminates, so too does the 188 subscription. In these cases, the value of the subscription duration 189 is largely irrelevant, and SHOULD be longer than the typical duration 190 of a dialog, about two hours would cover most dialogs. 192 In another case, a subscriber is interested in the state of all call 193 legs for a specific user. In these cases, a shorter interval makes 194 more sense. The default is one hour for these subscriptions. 196 2.5 NOTIFY Bodies 198 The body of the notification contains a dialog information document. 199 The format of this document is described in Section 3. Its MIME type 200 is "application/dialog-info+xml". All subscribers MUST support this 201 format, and MUST list its type in any Accept header in the SUBSCRIBE. 202 When no Accept header is present in the SUBSCRIBE, its default value 203 is "application/dialog-info+xml". 205 Other dialog information formats might be defined in the future. In 206 that case, the subscriptions MAY indicate support for other formats. 207 However, they MUST always support and list "application/dialog- 208 info+xml" as an allowed format. 210 Of course, the notifications generated by the server MUST be in one 211 of the formats specified in the Accept header in the SUBSCRIBE 212 request. 214 2.6 Notifier Processing of SUBSCRIBE Requests 216 The dialog information for a user contains very sensitive 217 information. Therefore, all subscriptions SHOULD be authenticated and 218 then authorized before approval. Authorization policy is at the 219 discretion of the administrator, as always. However, a few 220 recommendations can be made. 222 It is RECOMMENDED that if the policy of a user is that A is allowed 223 to call them, dialog subscriptions from user A be allowed. However, 224 the information provided in the notifications does not contain any 225 dialog identification information; merely an indication of whether 226 the user is in one or more calls, or not. Specifically, they should 227 not be able to find out any more information than if they sent an 228 INVITE. 230 It is RECOMMENDED that if a user agent registers with the address- 231 of-record X, that this user agent authorize subscriptions that come 232 from any entity that can authenticate itself as X. Complete 233 information on the dialog state SHOULD be sent in this case. This 234 authorization behavior allows a group of devices representing a 235 single user to all become aware of each other's state. This is useful 236 for applications such as single-line-extension. 238 2.7 Notifier Generation of NOTIFY Requests 240 Notifications are generated for the dialog package when a new dialog 241 comes into existence at a UA, or when the state or characteristics of 242 an existing dialog changes. Therefore, a model of dialog state is 243 needed in order to determine precisely when to send notifications, 244 and what their content should be. The SIP specification has a 245 reasonably well defined lifecycle for dialogs. However, it is not 246 explicitly modelled. This specification provides an explicit model of 247 dialog state through a finite state machine. 249 It is RECOMMENDED that NOTIFY requests only contain information on 250 the dialogs whose state has changed. However, if a notifier receives 251 a SUBSCRIBE request, the triggered NOTIFY SHOULD contain the state of 252 all dialogs that the subscriber is authorized to see. 254 2.7.1 The Dialog State Machine 256 Modelling of dialog state is complicated by two factors. The first is 257 forking, which can cause a single INVITE to generate many dialogs at 258 a UAC. The second is the differing views of state at the UAC and UAS. 259 We have chosen to handle the first issue by extending the dialog FSM 260 to include the states between transmission of the INVITE and the 261 creation of actual dialogs through receipt of 1xx and 2xx responses. 262 We have also chosen to use a single FSM for both UAC and UAS. 264 The FSM for dialog state is shown in Figure 1. The FSM is best 265 understood by considering the UAC and UAS cases separately. 267 The FSM is created in the "trying" state when the UAC sends an INVITE 268 request. Upon receipt of a 1xx without a tag (the "1xx-notag" event), 269 the FSM transitions to the "proceeding" state. Note that there is no 270 actual dialog yet, as defined by the SIP specification. However, 271 there is a "half-dialog", in the sense that two of the three 272 components of the dialog ID are known (the call identifier and local 273 tag). If a 1xx with a tag is received, the FSM transitions to the 274 early state. The full dialog identifier is now defined. Had a 2xx 275 +----------+ +----------+ 276 | | 1xx-notag | | 277 | |----------->| | 278 | Trying | |Proceeding|-----+ 279 | |---+ +-----| | | 280 | | | | | | | 281 +----------+ | | +----------+ | 282 | | | | | | 283 | | | | | | 284 +<--C-----C--+ |1xx-tag | 285 | | | | | 286 cancelled| | | V | 287 rejected| | |1xx-tag +----------+ | 288 | | +------->| | |2xx 289 | | | | | 290 +<--C--------------| Early | | 291 | | | | | 292 | | | | | 293 | | +----------+ | 294 | | 2xx | | 295 | +----------------+ | | 296 | | |2xx | 297 | | | | 298 V V V | 299 +----------+ +----------+ | 300 | | | | | 301 | | | | | 302 |Terminated|<-----------| Confirmed|<----+ 303 | | hungup | | 304 | | error | | 305 +----------+ timeout +----------+ 307 Figure 1: Dialog finite state machine 309 been received, the FSM would have transitioned to the "confirmed" 310 state. 312 If, after transitioning to the "early" or "confirmed" states, the UAC 313 receives another 1xx or 2xx with a different tag, another instance of 314 the FSM is created, initialized into the "early" or "confirmed" state 315 depending on the response code. The benefit of this approach is that 316 there will be a single FSM representing the entire state of the 317 invitation and resulting dialog when dealing with the common case of 318 no forking. 320 If the UAC should send a CANCEL, and then subsequently receive a 487 321 to its INVITE transaction, all FSMs spawned from that INVITE 322 transition to the "terminated" state with the event "canceled". If 323 the INVITE transaction terminates with a non-2xx response for any 324 other reason, all FSMs spawned from that INVITE transition to the 325 terminated state with the event "rejected". 327 Once in the confirmed state, the call is active. It can transition to 328 the terminated state if the UAC sends a BYE or receives a BYE 329 (corresponding to the "hungup" event), if a mid-dialog request 330 generates a 481 or 408 response (corresponding to the "error" event), 331 or a mid-dialog request generates no response (corresponding to the 332 "timeout" event). 334 From the perspective of the UAS, when an INVITE is received, the FSM 335 is created in the "trying" state. If it sends a 1xx without a tag, 336 the FSM transitions to the "proceeding" state. If a 1xx is sent with 337 a tag, the FSM transitions to the "early" state, and if a 2xx is 338 sent, it transitions to the "confirmed" state. If the UAS should 339 receive a CANCEL request and then generate a 487 response to the 340 INVITE (which can occur in the proceeding and early states), the FSM 341 transitions to the terminated state with the event "cancelled". If 342 the UAS should generate any other non-2xx final response to the 343 INVITE request, the FSM transitions to the terminated state with the 344 event "rejected". Once in the "confirmed" state, the transitions to 345 the "terminated" state occur for the same reasons they do in the case 346 of UAC. 348 There should never be a transition from the "trying" state 349 to the "terminated" state with the event "cancelled", since 350 the SIP specification prohibits transmission of CANCEL 351 until a provisional response is received. However, this 352 transition is defined in the FSM just to unify the 353 transitions from trying, proceeding, and early to the 354 terminated state. 356 2.7.2 Applying the state machine 358 The notifier MAY generate a NOTIFY request on any event transition of 359 the FSM. Whether it does or not is policy dependent. However, some 360 general guidelines are provided. 362 When the subscriber is unauthenticated, or is authenticated, but 363 represents a third party with no specific authorization policies, it 364 is RECOMMENDED that actual dialog states across all dialogs not be 365 reported. Rather, a single "virtual" dialog FSM be used, and event 366 transitions on that FSM be reported. If there is any dialog at the UA 367 whose state is "confirmed", the virtual FSM is in the "confirmed" 368 state. If there are no dialogs at the UA in the confirmed state, but 369 there is at least one in the "early" state, the virtual FSM is in the 370 "early" state. If there are no dialogs in the confirmed or early 371 states, but there is at least one in the "proceeding" state, the 372 virtual FSM is in the "proceeding" state. If there are no dialogs in 373 the confirmed, early, or proceeding states, but there is at least one 374 in the "trying" state, the virtual FSM is in the "trying" state. 375 Furthermore, it is RECOMMENDED that the notifications of changes in 376 the virtual FSM machine not convey any information except the state 377 of the FSM and its event transitions - no dialog identifiers (which 378 are ill-defined in this model in any case). The use of this virtual 379 FSM allows for minimal information to be conveyed. A subscriber 380 cannot know how many calls are in progress, or with whom, just that 381 there exists a call. 383 When the subscriber is authenticated, and has authenticated itself 384 with the same address-of-record that the UA itself uses, if no 385 explicit authorization policy is defined, it is RECOMMENDED that all 386 state transitions on all dialogs be reported, along with complete 387 dialog IDs. 389 The notifier MAY generate a NOTIFY request on any change in the 390 characteristics associated with the dialog. Since these include CSeq 391 numbers and SDP, receipt of re-INVITEs and UPDATE requests [11] which 392 modify this information MAY trigger notifications. 394 2.8 Subscriber Processing of NOTIFY Requests 396 The SIP Events framework expects packages to specify how a subscriber 397 processes NOTIFY requests in any package specific ways, and in 398 particular, how it uses the NOTIFY requests to contruct a coherent 399 view of the state of the subscribed resource. 401 Typically, the NOTIFY for the dialog package will only contain 402 information about those dialogs whose state has changed. To construct 403 a coherent view of the total state of all dialogs, a subscriber to 404 the dialog package will need to combine NOTIFYs received over time. 406 Notifications within this package can convey partial information; 407 that is, they can indicate information about a subset of the state 408 associated with the subscription. This means that an explicit 409 algorithm needs to be defined in order to construct coherent and 410 consistent state. The details of this mechanism are specific to the 411 particular document type. See Section 3.2 for information on 412 constructing coherent information from an application/dialog-info+xml 413 document. 415 2.9 Handling of Forked Requests 417 Since dialog state is distributed across the UA for a particular 418 user, it is reasonable and useful for a SUBSCRIBE request for dialog 419 state to fork, and reach multiple UA. 421 As a result, a forked SUBSCRIBE request for dialog state can install 422 multiple subscriptions. Subscribers to this package MUST be prepared 423 to install subscription state for each NOTIFY generated as a result 424 of a single SUBSCRIBE. 426 2.10 Rate of Notifications 428 For reasons of congestion control, it is important that the rate of 429 notifications not become excessive. As a result, it is RECOMMENDED 430 that the server not generate notifications for a single subscriber at 431 a rate faster than once every 5 seconds. 433 2.11 State Agents 435 Dialog state is ideally maintained in the user agents in which the 436 dialog resides. Therefore, the elements that maintain the dialog are 437 the ones best suited to handle subscriptions to it. Therefore, the 438 usage of state agents is NOT RECOMMENDED for this package. 440 3 Dialog Information Format 442 Dialog information is an XML document [3] that MUST be well-formed 443 and SHOULD be valid. Dialog information documents MUST be based on 444 XML 1.0 and MUST be encoded using UTF-8. This specification makes use 445 of XML namespaces for identifying dialog information documents and 446 document fragments. The namespace URI for elements defined by this 447 specification is a URN [4], using the namespace identifier 'ietf' 448 defined by [5] and extended by [6]. This URN is: 450 urn:ietf:params:xml:ns:dialog-info 451 A dialog information document begins with the root element tag 452 "dialog-info". 454 3.1 Structure of Dialog Information 456 A dialog information document starts with a dialog-info element. This 457 element has three mandatory attributes: 459 version: This attribute allows the recipient of dialog 460 information documents to properly order them. Versions 461 start at 0, and increment by one for each new document sent 462 to a subscriber. Versions are scoped within a subscription. 463 Versions MUST be representable using a 32 bit integer. 465 state: This attribute indicates whether the document contains 466 the full dialog information, or whether it contains only 467 information on those dialogs which have changed since the 468 previous document (partial). 470 entity: This attribute contains a URI that identifies the user 471 whose dialog information is reported in the remainder of 472 the document. 474 The dialog-info element has a series of dialog sub-elements. Each of 475 those represents a specific dialog. 477 3.1.1 Dialog Element 479 The dialog element reports information on a specific dialog. It has a 480 single mandatory attribute, id. The id attribute provides a single 481 string that can be used as an identifier for this dialog. This is a 482 different identifier than the formal dialog ID defined in SIP [2]. 483 This identifier exists before the dialog exists, and remains 484 unchanged when the actual dialog is established. 486 There are a number of optional attributes which provide 487 identification information about the dialog: 489 call-id: This attribute is a string which represents the call-id 490 component of the dialog identifier. 492 local-tag: This attribute is a string which represents the 493 local-tag component of the dialog identifier. 495 remote-tag: This attribute is a string which represents the 496 remote-tag component of the dialog identifier. The remote 497 tag attribute won't be present if there is only a "half- 498 dialog", resulting from generation of a request that can 499 create a dialog. 501 direction: This attribute is either initiator or recipient, and 502 indicates whether the notifier was the initiator of the 503 dialog, or the recipient of the INVITE that created it. 505 The sub-elements of the dialog element provide additional information 506 about the dialog. The only mandatory one is status. 508 3.1.2 State 510 The state element indicates the state of the dialog. Its value is an 511 enumerated type describing one of the states in the FSM above. It has 512 an optional event attribute that can be used to indicate the event 513 which caused the transition into the current state, and an optional 514 code attribute that indicates the response code associated with the 515 transition, assuming the event was 1xx-tag, 1xx-notag, or 2xx. 517 3.1.3 Local URI 519 The local-uri element indicates the local URI, as defined in [2]. It 520 has an optional attribute, display-name, that contains the display 521 name from the local URI. 523 3.1.4 Remote URI 525 The remote-uri element indicates the remote URI, as defined in [2]. 526 It has an optional attribute, display-name, that contains the display 527 name from the remote URI. 529 3.1.5 Local Session Description 531 The local-session-description element contains the session 532 description used by the notifier for its end of the dialog. This 533 element should generally NOT be included in the notifications, unless 534 explicitly requested by the subscriber. It has a single attribute, 535 type, which indicates the MIME media type of the session description. 537 3.1.6 Remote Session Description 539 The remote-session-description element contains the session 540 description used by the peer of the notifier for its end of the 541 dialog. This element should generally NOT be included in the 542 notifications, unless explicitly requested by the subscriber. It has 543 a single attribute, type, which indicates the MIME media type of the 544 session description. 546 3.1.7 Remote Target 547 The remote-target contains the remote-target URI as constructed by 548 the user agent for this dialog, as defined in RFC BBBB [2]. This 549 element should generally not be included in notifications, unless 550 explicitly requested by the subscriber. 552 3.1.8 Local CSeq 554 The local-cseq element contains the most recent value of the CSeq 555 header used by the UA in an outgoing request on the dialog. This 556 element should generally NOT be included in the notifications, unless 557 explicitly requested by the subscriber. If no CSeq has yet been 558 defined, the value of the element is -1. 560 3.1.9 Remote CSeq 562 The remote-cseq element contains the most recent value of the CSeq 563 header seen by the UA in an incoming request on the dialog. This 564 element should generally NOT be included in the notifications, unless 565 explicitly requested by the subscriber. If no CSeq has yet been 566 defined, the value of the element is -1. 568 3.1.10 Duration 570 The duration element contains the amount of time, in seconds, since 571 the FSM was created. 573 3.2 Constructing Coherent State 575 The dialog information subscriber maintains a table for the list of 576 dialogs. The table contains a row for each dialog. Each row is 577 indexed by an ID, present in the "id" attribute of the "dialog" 578 element. The contents of each row contain the state of that dialog as 579 conveyed in the document. The table is also associated with a version 580 number. The version number MUST be initialized with the value of the 581 "version" attribute from the "dialog-info" element in the first 582 document received. Each time a new document is received, the value of 583 the local version number, and the "version" attribute in the new 584 document, are compared. If the value in the new document is one 585 higher than the local version number, the local version number is 586 increased by one, and the document is processed. If the value in the 587 document is more than one higher than the local version number, the 588 local version number is set to the value in the new document, the 589 document is processed, and the subscriber SHOULD generate a refresh 590 request to trigger a full state notification. If the value in the 591 document is less than the local version, the document is discarded 592 without processing. 594 The processing of the dialog information document depends on whether 595 it contains full or partial state. If it contains full state, 596 indicated by the value of the "state" attribute in the "dialog-info" 597 element, the contents of the table are flushed. They are repopulated 598 from the document. A new row in the table is created for each 599 "dialog" element. If the document contains partial state, as 600 indicated by the value of the "state" attribute in the "dialog-info" 601 element, the document is used to update the table. For each "dialog" 602 element in the document, the subscriber checks to see whether a row 603 exists for that dialog. This check is done by comparing the ID in the 604 "id" attribute of the "dialog" element with the ID associated with 605 the row. If the dialog doesn't exist in the table, a row is added, 606 and its state is set to the information from that "dialog" element. 607 If the dialog does exist, its state is updated to be the information 608 from that "dialog" element. If a row is updated or created, such that 609 its state is now terminated, that entry MAY be removed from the table 610 at any time. 612 3.3 Schema 614 The following is the schema for the application/dialog-info+xml type: 616 617 621 622 624 625 626 627 628 630 631 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 650 652 654 656 658 660 662 664 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 738 740 3.4 Example 742 For example, if a UAC sends an INVITE that looks like, in part: 744 INVITE sip:callee@foo.com SIP/2.0 745 From: sip:caller@bar.com;tag=123 746 To: sip:callee@foo.com 747 Call-ID: 987@1.2.3.4 749 The XML document in a notification might look like: 751 752 756 758 trying 759 760 762 If a 1xx with a tag is received, the XML document in a notification 763 might look like: 765 766 770 772 early 774 775 777 If it receives a second 1xx, with a different tag, this results in 778 the creation of a second dialog: 780 781 785 787 early 788 789 791 early 792 793 795 If a 200 OK is received on the second dialog, it moves to confirmed: 797 798 802 804 confirmed 805 806 808 32 seconds later, the other early dialog terminates because no 2xx is 809 received for it. This implies that it was successfully cancelled, and 810 therefore the following notification is sent: 812 813 817 819 terminated 820 821 823 4 Security Considerations 825 Subscriptions to dialog state can reveal very sensitive information. 826 For this reason, this specification recommends authentication and 827 authorization of subscriptions, and provides guidelines on sensible 828 authorization policies. 830 Since the data in notifications is sensitive as well, end-to-end SIP 831 encryption mechanisms using S/MIME MAY be used to protect it. 833 5 IANA Considerations 835 This document registers a new MIME type, application/dialog-info+xml 836 and registers a new XML namespace. 838 5.1 application/dialog-info+xml MIME Registration 840 MIME media type name: application 842 MIME subtype name: dialog-info+xml 844 Mandatory parameters: none 846 Optional parameters: Same as charset parameter application/xml 847 as specified in RFC 3023 [7]. 849 Encoding considerations: Same as encoding considerations of 850 application/xml as specified in RFC 3023 [7]. 852 Security considerations: See Section 10 of RFC 3023 [7] and 853 Section 4 of this specification. 855 Interoperability considerations: none. 857 Published specification: This document. 859 Applications which use this media type: This document type has 860 been used to support SIP applications such as call return 861 and auto-conference. 863 Additional Information: 865 Magic Number: None 867 File Extension: .dif or .xml 869 Macintosh file type code: "TEXT" 871 Personal and email address for further information: Jonathan 872 Rosenberg, 874 Intended usage: COMMON 876 Author/Change controller: The IETF. 878 5.2 URN Sub-Namespace Registration for urn:ietf:params:xml:ns:dialog- 879 info 881 This section registers a new XML namespace, as per the guidelines in 882 [6]. 884 URI: The URI for this namespace is 885 urn:ietf:params:xml:ns:dialog-info. 887 Registrant Contact: IETF, SIMPLE working group, 888 , Jonathan Rosenberg 889 . 891 XML: 893 BEGIN 894 895 897 898 899 901 Dialog Information Namespace 902 904

Namespace for Dialog Information

905

application/dialog-info+xml

906

See RFCXXXX.

907 908 909 END 911 6 Acknowledgements 913 The author would like to thank Sean Olson for his comments. 915 7 Authors Addresses 917 Jonathan Rosenberg 918 dynamicsoft 919 72 Eagle Rock Avenue 920 First Floor 921 East Hanover, NJ 07936 922 email: jdrosen@dynamicsoft.com 924 Henning Schulzrinne 925 Columbia University 926 M/S 0401 927 1214 Amsterdam Ave. 928 New York, NY 10027-7003 929 email: schulzrinne@cs.columbia.edu 931 8 Normative References 933 [1] A. Roach, "SIP-specific event notification," Internet Draft, 934 Internet Engineering Task Force, Mar. 2002. Work in progress. 936 [2] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation 937 protocol," Internet Draft, Internet Engineering Task Force, Feb. 938 2002. Work in progress. 940 [3] W. W. W. C. (W3C), "Extensible markup language (xml) 1.0." The 941 XML 1.0 spec can be found at http://www.w3.org/TR/1998/REC-xml- 942 19980210. 944 [4] R. Moats, "URN syntax," RFC 2141, Internet Engineering Task 945 Force, May 1997. 947 [5] R. Moats, "A URN namespace for IETF documents," RFC 2648, 948 Internet Engineering Task Force, Aug. 1999. 950 [6] M. Mealling, "The IANA XML registry," Internet Draft, Internet 951 Engineering Task Force, Nov. 2001. Work in progress. 953 [7] M. Murata, S. S. Laurent, and D. Kohn, "XML media types," RFC 954 3023, Internet Engineering Task Force, Jan. 2001. 956 9 Informative References 958 [8] J. Rosenberg, "Session initiation protocol (SIP) extensions for 959 presence," Internet Draft, Internet Engineering Task Force, May 2002. 960 Work in progress. 962 [9] J. Rosenberg, "A session initiation protocol (SIP)event 963 template-package for watcher information," Internet Draft, Internet 964 Engineering Task Force, May 2002. Work in progress. 966 [10] R. Mahy, "A message summary and message waiting indication event 967 package for the session initiation protocol (SIP)," Internet Draft, 968 Internet Engineering Task Force, June 2002. Work in progress. 970 [11] J. Rosenberg, "The session initiation protocol UPDATE method," 971 Internet Draft, Internet Engineering Task Force, May 2002. Work in 972 progress. 974 Full Copyright Statement 976 Copyright (c) The Internet Society (2002). All Rights Reserved. 978 This document and translations of it may be copied and furnished to 979 others, and derivative works that comment on or otherwise explain it 980 or assist in its implementation may be prepared, copied, published 981 and distributed, in whole or in part, without restriction of any 982 kind, provided that the above copyright notice and this paragraph are 983 included on all such copies and derivative works. However, this 984 document itself may not be modified in any way, such as by removing 985 the copyright notice or references to the Internet Society or other 986 Internet organizations, except as needed for the purpose of 987 developing Internet standards in which case the procedures for 988 copyrights defined in the Internet Standards process must be 989 followed, or as required to translate it into languages other than 990 English. 992 The limited permissions granted above are perpetual and will not be 993 revoked by the Internet Society or its successors or assigns. 995 This document and the information contained herein is provided on an 996 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 997 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 998 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 999 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1000 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.