idnits 2.17.1 draft-ietf-sipping-dialog-package-02.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 8 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 (June 30, 2003) is 7605 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) ** 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) == Outdated reference: A later version (-04) exists of draft-ietf-sipping-mwi-02 Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING J. Rosenberg 3 Internet-Draft dynamicsoft 4 Expires: December 29, 2003 H. Schulzrinne 5 Columbia University 6 June 30, 2003 8 An INVITE Inititiated Dialog Event Package for the Session 9 Initiation Protocol (SIP) 10 draft-ietf-sipping-dialog-package-02 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 29, 2003. 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 This document defines a dialog event package for the SIP Events 41 architecture, along with a data format used in notifications for this 42 package. The dialog package allows users to subscribe to another 43 user, an receive notifications about the changes in state of INVITE 44 initiated dialogs that the user is involved in. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 50 3. Dialog Event Package . . . . . . . . . . . . . . . . . . . 6 51 3.1 Event Package Name . . . . . . . . . . . . . . . . . . . . 6 52 3.2 Event Package Parameters . . . . . . . . . . . . . . . . . 6 53 3.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 6 54 3.4 Subscription Duration . . . . . . . . . . . . . . . . . . 7 55 3.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 7 56 3.6 Notifier Processing of SUBSCRIBE Requests . . . . . . . . 8 57 3.7 Notifier Generation of NOTIFY Requests . . . . . . . . . . 8 58 3.7.1 The Dialog State Machine . . . . . . . . . . . . . . . . . 9 59 3.7.2 Applying the state machine . . . . . . . . . . . . . . . . 11 60 3.8 Subscriber Processing of NOTIFY Requests . . . . . . . . . 12 61 3.9 Handling of Forked Requests . . . . . . . . . . . . . . . 13 62 3.10 Rate of Notifications . . . . . . . . . . . . . . . . . . 13 63 3.11 State Agents . . . . . . . . . . . . . . . . . . . . . . . 13 64 4. Dialog Information Format . . . . . . . . . . . . . . . . 14 65 4.1 Structure of Dialog Information . . . . . . . . . . . . . 14 66 4.1.1 Dialog Element . . . . . . . . . . . . . . . . . . . . . . 14 67 4.1.2 State . . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 4.1.3 Local URI . . . . . . . . . . . . . . . . . . . . . . . . 15 69 4.1.4 Remote URI . . . . . . . . . . . . . . . . . . . . . . . . 16 70 4.1.5 Local Session Description . . . . . . . . . . . . . . . . 16 71 4.1.6 Remote Session Description . . . . . . . . . . . . . . . . 16 72 4.1.7 Remote Target . . . . . . . . . . . . . . . . . . . . . . 16 73 4.1.8 Local CSeq . . . . . . . . . . . . . . . . . . . . . . . . 16 74 4.1.9 Remote CSeq . . . . . . . . . . . . . . . . . . . . . . . 16 75 4.1.10 Duration . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 4.2 Constructing Coherent State . . . . . . . . . . . . . . . 17 77 4.3 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 17 78 4.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . 20 79 5. Security Considerations . . . . . . . . . . . . . . . . . 23 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 24 81 6.1 application/dialog-info+xml MIME Registration . . . . . . 24 82 6.2 URN Sub-Namespace Registration for 83 urn:ietf:params:xml:ns:dialog-info . . . . . . . . . . . . 25 84 6.3 Schema Registration . . . . . . . . . . . . . . . . . . . 25 85 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 26 86 Normative References . . . . . . . . . . . . . . . . . . . 27 87 Informative References . . . . . . . . . . . . . . . . . . 28 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 28 89 Intellectual Property and Copyright Statements . . . . . . 29 91 1. Introduction 93 The SIP Events framework [1] defines general mechanisms for 94 subscription to, and notification of, events within SIP networks. It 95 introduces the notion of a package, which is a specific 96 "instantiation" of the events mechanism for a well-defined set of 97 events. Packages have been defined for user presence [10], watcher 98 information [11], and message waiting indicators [12], amongst 99 others. Here, we define an event package for INVITE initiated 100 dialogs. Dialogs refer to the SIP relationship established between 101 two SIP peers [2]. Dialogs can be created by many methods, although 102 RFC 3261 defines only one - the INVITE method. RFC 3265 defines the 103 SUBSCRIBE and NOTIFY methods, which also create dialogs. However, the 104 usage of this package to model transitions in the state of those 105 dialogs is out of the scope of this specification. 107 There are a variety of applications enabled through the knowledge of 108 INVITE dialog state. Some examples include: 110 Automatic Callback: In this basic Public Switched Telephone Network 111 (PSTN) application, user A calls user B. User B is busy. User A 112 would like to get a callback when user B hangs up. When B hangs 113 up, user A's phone rings. When A picks it up, they here ringing, 114 and are being connected to B. To implement this with SIP, a 115 mechanism is required for B to receive a notification when the 116 dialogs at A are complete. 118 Presence-Enabled Conferencing: In this application, a user A wishes 119 to set up a conference call with users B and C. Rather than 120 scheduling it, it is to be created automatically when A, B and C 121 are all available. To do this, the server providing the 122 application would like to know whether A, B and C are "online", 123 not idle, and not in a phone call. Determining whether or not A, B 124 and C are in calls can be done in two ways. In the first, the 125 server acts as a call stateful proxy for users A, B and C, and 126 therefore knows their call state. This won't always be possible, 127 however, and it introduces scalability, reliability, and 128 operational complexities. Rather, the server would subscriber to 129 the dialog state of those users, and receive notifications as it 130 changes. This enables the application to be provided in a 131 distributed way; the server need not reside in the same domain as 132 the users. 134 IM Conference Alerts: In this application, a user can get an IM sent 135 to their phone whenever someone joins a conference that the phone 136 is involved in. The IM alerts are generated by an application 137 separate from the conference server. 139 In general, the dialog package allows for construction of distributed 140 applications, where the application requires information on dialog 141 state, but is not co-resident with the end user on which that state 142 resides. 144 2. Terminology 146 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 147 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 148 and "OPTIONAL" are to be interpreted as described in RFC 2119 [9] and 149 indicate requirement levels for compliant implementations. 151 3. Dialog Event Package 153 This section provides the details for defining a SIP Events package, 154 as specified by [1]. 156 3.1 Event Package Name 158 The name of this event package is "dialog". This package name is 159 carried in the Event and Allow-Events header, as defined in [1]. 161 3.2 Event Package Parameters 163 This package defines three Event Package parameters. They are 164 call-id, to-tag and from-tag. If a subscription to a specific dialog 165 is requested, all three of these parameters MUST be present. They 166 identify the dialog that is being subscribed to. The to-tag is 167 matched against the local tag, the from-tag is matched against the 168 remote tag, and the call-id is matched against the Call-ID. 170 It is also possible to subscribe to the set of dialogs created as a 171 result of a single INVITE sent by a UAC. In that case, the call-id 172 and to-tag MUST be present. The to-tag is matched against the local 173 tag, and the call-id is matched against the Call-ID. 175 The BNF for these parameters is: 177 call-id = "call-id" EQUAL SWS DQUOTE callid DQUOTE 178 ;;callid, EQUAL, SWS, DQUOTE from RFC3261 179 from-tag = "from-tag" EQUAL token 180 to-tag = "to-tag" EQUAL token 182 Note that the call-id parameter is a quoted string. This is because 183 the BNF for word (which is used by callid) allows for characters not 184 allowed within token. 186 3.3 SUBSCRIBE Bodies 188 A SUBSCRIBE for a dialog package MAY contain a body. This body 189 defines a filter to apply to the subscription. Filter documents are 190 not specified in this document, and at the time of writing, are 191 expected to be the subject of future standardization activity. 193 A SUBSCRIBE for a dialog package MAY be sent without a body. This 194 implies the default subscription filtering policy. The default policy 195 is: 197 o If the Event header field contained dialog identifiers, 198 notifications are generated every time there is a change in the 199 state of any matching dialogs for the user identified in the 200 request URI of the SUBSCRIBE. 202 o If there were no dialog identifiers in the Event header field, 203 notifications are generated every time there is any change in the 204 state of any dialogs for the user identified in the request URI of 205 the SUBSCRIBE. 207 o Notifications do not normally contain full state; rather, they 208 only indicate the state of the dialog whose state has changed. The 209 exception is a NOTIFY sent in response to a SUBSCRIBE. These 210 NOTIFYs contain the complete view of dialog state. 212 o The notifications contain the identities of the participants in 213 the dialog, and the dialog identifiers. Additional information, 214 such as the route set, remote target URI, CSeq numbers, SDP 215 information, and so on, are not included normally unless 216 explicitly requested and/or explicitly authorized. 218 3.4 Subscription Duration 220 Dialog state changes fairly quickly; once established, a typical 221 phone call lasts a few minutes (this is different for other session 222 types, of course). However, the interval between new calls is 223 typically infrequent. As such, we arbitrarily choose a default 224 duration of one hour. Clients SHOULD specify an explicit duration. 226 There are two distinct use cases for dialog state. The first is when 227 a subscriber is interested in the state of a specific dialog or 228 dialogs (and they are authorized to find out about just the state of 229 those dialogs). In that case, when the dialogs terminate, so too does 230 the subscription. In these cases, the value of the subscription 231 duration is largely irrelevant, and SHOULD be longer than the typical 232 duration of a dialog, about two hours would cover most dialogs. 234 In another case, a subscriber is interested in the state of all 235 dialogs for a specific user. In these cases, a shorter interval makes 236 more sense. The default is one hour for these subscriptions. 238 3.5 NOTIFY Bodies 240 As described in RFC 3265 [1], the NOTIFY message will contain bodies 241 that describe the state of the subscribed resource. This body is in a 242 format listed in the Accept header field of the SUBSCRIBE, or a 243 package-specific default if the Accept header field was omitted from 244 the SUBSCRIBE. 246 In this event package, the body of the notification contains a dialog 247 information document. This document describes the state of one or 248 more dialogs associated with the subscribed resource. All subscribers 249 and notifiers MUST support the "application/dialog-info+xml" data 250 format described in Section 4. The subscribe request MAY contain an 251 Accept header field. If no such header field is present, it has a 252 default value of "application/dialog-info+xml". If the header field 253 is present, it MUST include "application/dialog-info+xml", and MAY 254 include any other types capable of representing dialog state. 256 Of course, the notifications generated by the server MUST be in one 257 of the formats specified in the Accept header field in the SUBSCRIBE 258 request. 260 3.6 Notifier Processing of SUBSCRIBE Requests 262 The dialog information for a user contains sensitive information. 263 Therefore, all subscriptions SHOULD be authenticated and then 264 authorized before approval. All implementors of this package MUST 265 support the digest authentication mechanism as a baseline. 266 Authorization policy is at the discretion of the administrator, as 267 always. However, a few recommendations can be made. 269 It is RECOMMENDED that, if the policy of user B is that user A is 270 allowed to call them, dialog subscriptions from user A be allowed. 271 However, the information provided in the notifications does not 272 contain any dialog identification information; merely an indication 273 of whether the user is in one or more calls, or not. Specifically, 274 they should not be able to find out any more information than if they 275 sent an INVITE. 277 It is RECOMMENDED that if a user agent registers with the 278 address-of-record X, that this user agent authorize subscriptions 279 that come from any entity that can authenticate itself as X. Complete 280 information on the dialog state SHOULD be sent in this case. This 281 authorization behavior allows a group of devices representing a 282 single user to all become aware of each other's state. This is useful 283 for applications such as single-line-extension. 285 3.7 Notifier Generation of NOTIFY Requests 287 Notifications are generated for the dialog package when an INVITE 288 request is sent, when a new dialog comes into existence at a UA, or 289 when the state or characteristics of an existing dialog changes. 290 Therefore, a model of dialog state is needed in order to determine 291 precisely when to send notifications, and what their content should 292 be. The SIP specification has a reasonably well defined lifecycle for 293 dialogs. However, it is not explicitly modelled. This specification 294 provides an explicit model of dialog state through a finite state 295 machine. 297 It is RECOMMENDED that NOTIFY requests only contain information on 298 the dialogs whose state has changed. However, if a notifier receives 299 a SUBSCRIBE request, the triggered NOTIFY SHOULD contain the state of 300 all dialogs that the subscriber is authorized to see. 302 3.7.1 The Dialog State Machine 304 Modelling of dialog state is complicated by two factors. The first is 305 forking, which can cause a single INVITE to generate many dialogs at 306 a UAC. The second is the differing views of state at the UAC and UAS. 307 We have chosen to handle the first issue by extending the dialog FSM 308 to include the states between transmission of the INVITE and the 309 creation of actual dialogs through receipt of 1xx and 2xx responses. 310 As a result, this specification supports the notion of dialog state 311 for dialogs before they are fully instantiated. 313 We have also chosen to use a single FSM for both UAC and UAS. 315 +----------+ +----------+ 316 | | 1xx-notag | | 317 | |----------->| | 318 | Trying | |Proceeding|-----+ 319 | |---+ +-----| | | 320 | | | | | | | 321 +----------+ | | +----------+ | 322 | | | | | | 323 | | | | | | 324 +<--C-----C--+ |1xx-tag | 325 | | | | | 326 cancelled| | | V | 327 rejected| | |1xx-tag +----------+ | 328 | | +------->| | |2xx 329 | | | | | 330 +<--C--------------| Early |-----C----+1xx-tag 331 | | | | | | w. new tag 332 | | | |<----C----+ (new 333 | | +----------+ | FSM 334 | | 2xx | | instance 335 | +----------------+ | | created) 336 | | |2xx | 337 | | | | 338 V V V | 339 +----------+ +----------+ | 340 | | | | | 341 | | | | | 342 |Terminated|<-----------| Confirmed|<----+ 343 | | hungup | | 344 | | error | | 345 +----------+ timeout +----------+ 346 | ^ 347 | | 348 | | 349 +------+ 350 2xx w. new tag 351 (new FSM instance 352 created) 354 Figure 2 356 The FSM for dialog state is shown in Figure 2. The FSM is best 357 understood by considering the UAC and UAS cases separately. 359 The FSM is created in the "trying" state when the UAC sends an INVITE 360 request. Upon receipt of a 1xx without a tag (the "1xx-notag" event), 361 the FSM transitions to the "proceeding" state. Note that there is no 362 actual dialog yet, as defined by the SIP specification. However, 363 there is a "half-dialog", in the sense that two of the three 364 components of the dialog ID are known (the call identifier and local 365 tag). If a 1xx with a tag is received, the FSM transitions to the 366 early state. The full dialog identifier is now defined. Had a 2xx 367 been received, the FSM would have transitioned to the "confirmed" 368 state. 370 If, after transitioning to the "early" or ``confirmed'' states, the 371 UAC receives another 1xx or 2xx respectively with a different tag, 372 another instance of the FSM is created, initialized into the "early" 373 or "confirmed" state respectively. The benefit of this approach is 374 that there will be a single FSM representing the entire state of the 375 invitation and resulting dialog when dealing with the common case of 376 no forking. 378 If the UAC should send a CANCEL, and then subsequently receive a 487 379 to its INVITE transaction, all FSMs spawned from that INVITE 380 transition to the "terminated" state with the event ``cancelled''. If 381 the INVITE transaction terminates with a non-2xx response for any 382 other reason, all FSMs spawned from that INVITE transition to the 383 terminated state with the event "rejected". 385 Once in the confirmed state, the call is active. It can transition to 386 the terminated state if the UAC sends a BYE or receives a BYE 387 (corresponding to the "hungup" event), if a mid-dialog request 388 generates a 481 or 408 response (corresponding to the "error" event), 389 or a mid-dialog request generates no response (corresponding to the 390 "timeout" event). 392 From the perspective of the UAS, when an INVITE is received, the FSM 393 is created in the "trying" state. If it sends a 1xx without a tag, 394 the FSM transitions to the "proceeding" state. If a 1xx is sent with 395 a tag, the FSM transitions to the "early" state, and if a 2xx is 396 sent, it transitions to the "confirmed" state. If the UAS should 397 receive a CANCEL request and then generate a 487 response to the 398 INVITE (which can occur in the proceeding and early states), the FSM 399 transitions to the terminated state with the event "cancelled". If 400 the UAS should generate any other non-2xx final response to the 401 INVITE request, the FSM transitions to the terminated state with the 402 event "rejected". Once in the ``confirmed'' state, the transitions to 403 the "terminated" state occur for the same reasons they do in the case 404 of UAC. 406 There should never be a transition from the "trying" state to the 407 "terminated" state with the event ``cancelled'', since the SIP 408 specification prohibits transmission of CANCEL until a provisional 409 response is received. However, this transition is defined in the 410 FSM just to unify the transitions from trying, proceeding, and 411 early to the terminated state. 413 3.7.2 Applying the state machine 415 The notifier MAY generate a NOTIFY request on any event transition of 416 the FSM. Whether it does or not is policy dependent. However, some 417 general guidelines are provided. 419 When the subscriber is unauthenticated, or is authenticated, but 420 represents a third party with no specific authorization policies, it 421 is RECOMMENDED that subscriptions to an individual dialog, or to a 422 specific set of dialogs, is forbidden. Only subscriptions to all 423 dialogs (i.e., there are no dialog identifiers in the Event header 424 field) are permitted. In that case, actual dialog states across all 425 dialogs not be reported. Rather, a single "virtual" dialog FSM be 426 used, and event transitions on that FSM be reported. If there is any 427 dialog at the UA whose state is "confirmed", the virtual FSM is in 428 the "confirmed" state. If there are no dialogs at the UA in the 429 confirmed state, but there is at least one in the "early" state, the 430 virtual FSM is in the "early" or "confirmed" state. If there are no 431 dialogs in the confirmed or early states, but there is at least one 432 in the "proceeding" state, the virtual FSM is in the "proceeding", 433 "early" or "confirmed" state. If there are no dialogs in the 434 confirmed, early, or proceeding states, but there is at least one in 435 the "trying" state, the virtual FSM is in the "trying", "proceeding", 436 "early" or "confirmed" state. The choice about which state to use 437 depends on whether the UA wishes to let unknown users that their 438 phone is ringing, as opposed to in an active call. It is RECOMMENDED 439 that, in the absence of any preference, "confirmed" is used in all 440 cases. Furthermore, it is RECOMMENDED that the notifications of 441 changes in the virtual FSM machine not convey any information except 442 the state of the FSM and its event transitions - no dialog 443 identifiers (which are ill-defined in this model in any case). The 444 use of this virtual FSM allows for minimal information to be 445 conveyed. A subscriber cannot know how many calls are in progress, or 446 with whom, just that there exists a call. This is the same 447 information they would receive if they simply sent an INVITE to the 448 user instead; a 486 response would indicate that they are on a call. 450 When the subscriber is authenticated, and has authenticated itself 451 with the same address-of-record that the UA itself uses, if no 452 explicit authorization policy is defined, it is RECOMMENDED that all 453 state transitions on dialogs that have been subscribed to (which is 454 either all of them, if no dialog identifiers were present in the 455 Event header field, or a specific set of them identified by the Event 456 header field parameters) be reported, along with complete dialog IDs. 458 The notifier MAY generate a NOTIFY request on any change in the 459 characteristics associated with the dialog. Since these include CSeq 460 numbers and SDP, receipt of re-INVITEs and UPDATE requests [3] which 461 modify this information MAY trigger notifications. 463 3.8 Subscriber Processing of NOTIFY Requests 465 The SIP Events framework expects packages to specify how a subscriber 466 processes NOTIFY requests in any package specific ways, and in 467 particular, how it uses the NOTIFY requests to contruct a coherent 468 view of the state of the subscribed resource. 470 Typically, the NOTIFY for the dialog package will only contain 471 information about those dialogs whose state has changed. To construct 472 a coherent view of the total state of all dialogs, a subscriber to 473 the dialog package will need to combine NOTIFYs received over time. 475 Notifications within this package can convey partial information; 476 that is, they can indicate information about a subset of the state 477 associated with the subscription. This means that an explicit 478 algorithm needs to be defined in order to construct coherent and 479 consistent state. The details of this mechanism are specific to the 480 particular document type. See Section 4.2 for information on 481 constructing coherent information from an application/dialog-info+xml 482 document. 484 3.9 Handling of Forked Requests 486 Since dialog state is distributed across the UA for a particular 487 user, it is reasonable and useful for a SUBSCRIBE request for dialog 488 state to fork, and reach multiple UA. 490 As a result, a forked SUBSCRIBE request for dialog state can install 491 multiple subscriptions. Subscribers to this package MUST be prepared 492 to install subscription state for each NOTIFY generated as a result 493 of a single SUBSCRIBE. 495 3.10 Rate of Notifications 497 For reasons of congestion control, it is important that the rate of 498 notifications not become excessive. As a result, it is RECOMMENDED 499 that the server not generate notifications for a single subscriber at 500 a rate faster than once every 5 seconds. 502 3.11 State Agents 504 Dialog state is ideally maintained in the user agents in which the 505 dialog resides. Therefore, the elements that maintain the dialog are 506 the ones best suited to handle subscriptions to it. However, in some 507 cases, a network agent may also know the state of the dialogs held by 508 a user. As such, state agents MAY be used with this package. 510 4. Dialog Information Format 512 Dialog information is an XML document [4] that MUST be well-formed 513 and SHOULD be valid. Dialog information documents MUST be based on 514 XML 1.0 and MUST be encoded using UTF-8. This specification makes use 515 of XML namespaces for identifying dialog information documents and 516 document fragments. The namespace URI for elements defined by this 517 specification is a URN [5], using the namespace identifier 'ietf' 518 defined by [6] and extended by [7]. This URN is: 520 urn:ietf:params:xml:ns:dialog-info 522 A dialog information document begins with the root element tag 523 "dialog-info". 525 4.1 Structure of Dialog Information 527 A dialog information document starts with a dialog-info element. This 528 element has three mandatory attributes: 530 version: This attribute allows the recipient of dialog information 531 documents to properly order them. Versions start at 0, and 532 increment by one for each new document sent to a subscriber. 533 Versions are scoped within a subscription. Versions MUST be 534 representable using a 32 bit integer. 536 state: This attribute indicates whether the document contains the 537 full dialog information, or whether it contains only information 538 on those dialogs which have changed since the previous document 539 (partial). 541 entity: This attribute contains a URI that identifies the user whose 542 dialog information is reported in the remainder of the document. 543 This user is referred to as the "observed user". 545 The dialog-info element has a series of dialog sub-elements. Each of 546 those represents a specific dialog. 548 4.1.1 Dialog Element 550 The dialog element reports information on a specific dialog or 551 "half-dialog". It has a single mandatory attribute, id. The id 552 attribute provides a single string that can be used as an identifier 553 for this dialog or "half-dialog". This is a different identifier than 554 the dialog ID defined in RFC 3261 [2], but related to it. 556 For a caller, the id is created when an INVITE request is sent. When 557 a 1xx with a tag, or a 2xx is received, the dialog is formally 558 created. The id remains unchanged. However, if an additional 1xx or 559 2xx is received, resulting in the creation of another dialog (and 560 resulting FSM), that dialog is allocated a new id. 562 For a callee, the id is created when an INVITE outside of an existing 563 dialog is received. When a 2xx or a 1xx with a tag is sent, creating 564 the dialog, the id remains unchanged. 566 The id MUST be unique amongst all dialogs at a UA. 568 There are a number of optional attributes which provide 569 identification information about the dialog: 571 call-id: This attribute is a string which represents the call-id 572 component of the dialog identifier. 574 local-tag: This attribute is a string which represents the local-tag 575 component of the dialog identifier. 577 remote-tag: This attribute is a string which represents the 578 remote-tag component of the dialog identifier. The remote tag 579 attribute won't be present if there is only a "half-dialog", 580 resulting from the generation of an INVITE for which no final 581 responses or provisional responses with tags has been received. 583 direction: This attribute is either initiator or recipient, and 584 indicates whether the observed user was the initiator of the 585 dialog, or the recipient of the INVITE that created it. 587 The sub-elements of the dialog element provide additional information 588 about the dialog. The only mandatory one is state. 590 4.1.2 State 592 The state element indicates the state of the dialog. Its value is an 593 enumerated type describing one of the states in the FSM above. It has 594 an optional event attribute that can be used to indicate the event 595 which caused the transition into the current state, and an optional 596 code attribute that indicates the response code associated with the 597 transition, assuming the event was caused by a response. 599 4.1.3 Local URI 601 The local-uri element indicates the local URI, as defined in [2]. It 602 has an optional attribute, display-name, that contains the display 603 name from the local URI. 605 4.1.4 Remote URI 607 The remote-uri element indicates the remote URI, as defined in [2]. 608 It has an optional attribute, display-name, that contains the display 609 name from the remote URI. 611 4.1.5 Local Session Description 613 The local-session-description element contains the session 614 description used by the observed user for its end of the dialog. This 615 element should generally NOT be included in the notifications, unless 616 explicitly requested by the subscriber. It has a single attribute, 617 type, which indicates the MIME media type of the session description. 619 4.1.6 Remote Session Description 621 The remote-session-description element contains the session 622 description used by the peer of the observed user for its end of the 623 dialog. This element should generally NOT be included in the 624 notifications, unless explicitly requested by the subscriber. It has 625 a single attribute, type, which indicates the MIME media type of the 626 session description. 628 4.1.7 Remote Target 630 The remote-target contains the remote-target URI as constructed by 631 the user agent for this dialog, as defined in RFC 3261 [2]. This 632 element should generally not be included in notifications, unless 633 explicitly requested by the subscriber. 635 4.1.8 Local CSeq 637 The local-cseq element contains the most recent value of the CSeq 638 header used by the UA in an outgoing request on the dialog. This 639 element should generally NOT be included in the notifications, unless 640 explicitly requested by the subscriber. If no CSeq has yet been 641 defined, the value of the element is -1. 643 4.1.9 Remote CSeq 645 The remote-cseq element contains the most recent value of the CSeq 646 header seen by the UA in an incoming request on the dialog. This 647 element should generally NOT be included in the notifications, unless 648 explicitly requested by the subscriber. If no CSeq has yet been 649 defined, the value of the element is -1. 651 4.1.10 Duration 652 The duration element contains the amount of time, in seconds, since 653 the FSM was created. 655 4.2 Constructing Coherent State 657 The dialog information subscriber maintains a table for the list of 658 dialogs. The table contains a row for each dialog. Each row is 659 indexed by an ID, present in the "id" attribute of the "dialog" 660 element. The contents of each row contain the state of that dialog as 661 conveyed in the document. The table is also associated with a version 662 number. The version number MUST be initialized with the value of the 663 "version" attribute from the "dialog-info" element in the first 664 document received. Each time a new document is received, the value of 665 the local version number, and the "version" attribute in the new 666 document, are compared. If the value in the new document is one 667 higher than the local version number, the local version number is 668 increased by one, and the document is processed. If the value in the 669 document is more than one higher than the local version number, the 670 local version number is set to the value in the new document, and the 671 document is processed. If the document did not contain full state, 672 the subscriber SHOULD generate a refresh request to trigger a full 673 state notification. If the value in the document is less than the 674 local version, the document is discarded without processing. 676 The processing of the dialog information document depends on whether 677 it contains full or partial state. If it contains full state, 678 indicated by the value of the "state" attribute in the "dialog-info" 679 element, the contents of the table are flushed. They are repopulated 680 from the document. A new row in the table is created for each 681 "dialog" element. If the document contains partial state, as 682 indicated by the value of the "state" attribute in the "dialog-info" 683 element, the document is used to update the table. For each "dialog" 684 element in the document, the subscriber checks to see whether a row 685 exists for that dialog. This check is done by comparing the ID in the 686 "id" attribute of the "dialog" element with the ID associated with 687 the row. If the dialog doesn't exist in the table, a row is added, 688 and its state is set to the information from that "dialog" element. 689 If the dialog does exist, its state is updated to be the information 690 from that "dialog" element. If a row is updated or created, such that 691 its state is now terminated, that entry MAY be removed from the table 692 at any time. 694 4.3 Schema 696 The following is the schema for the application/dialog-info+xml type: 698 699 705 706 708 709 710 711 712 714 715 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 734 736 738 740 742 744 746 748 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 812 4.4 Example 814 For example, if a UAC sends an INVITE that looks like, in part: 816 INVITE sip:bob@example.com SIP/2.0 817 Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8 818 Max-Forwards: 70 819 To: Bob 820 From: Alice ;tag=1928301774 821 Call-ID: a84b4c76e66710 822 CSeq: 314159 INVITE 823 Contact: 824 Content-Type: application/sdp 825 Content-Length: 142 827 [SDP not shown] 829 The XML document in a notification from Alice might look like: 831 832 836 838 trying 839 841 843 If the following 180 response is received: 845 SIP/2.0 180 Ringing 846 Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8 847 To: Bob ;tag=456887766 848 From: Alice ;tag=1928301774 849 Call-ID: a84b4c76e66710 850 CSeq: 314159 INVITE 851 Contact: 853 The XML document in a notification might look like: 855 856 860 863 early 864 865 867 If it receives a second 180 with a different tag: 869 SIP/2.0 180 Ringing 870 Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8 871 To: Bob ;tag=hh76a 872 From: Alice ;tag=1928301774 873 Call-ID: a84b4c76e66710 874 CSeq: 314159 INVITE 875 Contact: 877 This results in the creation of a second dialog: 879 880 884 887 early 888 889 892 early 893 894 896 If a 200 OK is received on the second dialog, it moves to confirmed: 898 899 903 906 confirmed 907 908 910 32 seconds later, the other early dialog terminates because no 2xx is 911 received for it. This implies that it was successfully cancelled, and 912 therefore the following notification is sent: 914 915 919 922 terminated 923 924 926 5. Security Considerations 928 Subscriptions to dialog state can reveal sensitive information. For 929 this reason, Section 3.6 discusses authentication and authorization 930 of subscriptions, and provides guidelines on sensible authorization 931 policies. All implementations of this package MUST support the digest 932 authentication mechanism. 934 Since the data in notifications is sensitive as well, end-to-end SIP 935 encryption mechanisms using S/MIME MAY be used to protect it. 937 6. IANA Considerations 939 This document registers a new MIME type, application/dialog-info+xml 940 and registers a new XML namespace. 942 6.1 application/dialog-info+xml MIME Registration 944 MIME media type name: application 946 MIME subtype name: dialog-info+xml 948 Mandatory parameters: none 950 Optional parameters: Same as charset parameter application/xml as 951 specified in RFC 3023 [8]. 953 Encoding considerations: Same as encoding considerations of 954 application/xml as specified in RFC 3023 [8]. 956 Security considerations: See Section 10 of RFC 3023 [8] and Section 5 957 of this specification. 959 Interoperability considerations: none. 961 Published specification: This document. 963 Applications which use this media type: This document type has been 964 used to support SIP applications such as call return and 965 auto-conference. 967 Additional Information: 969 Magic Number: None 971 File Extension: .dif or .xml 973 Macintosh file type code: "TEXT" 975 Personal and email address for further information: Jonathan 976 Rosenberg, 978 Intended usage: COMMON 980 Author/Change controller: The IETF. 982 6.2 URN Sub-Namespace Registration for 983 urn:ietf:params:xml:ns:dialog-info 985 This section registers a new XML namespace, as per the guidelines in 986 [7]. 988 URI: The URI for this namespace is 989 urn:ietf:params:xml:ns:dialog-info. 991 Registrant Contact: IETF, SIPPING working group, , 992 Jonathan Rosenberg . 994 XML: 996 BEGIN 997 998 1000 1001 1002 1004 Dialog Information Namespace 1005 1007

Namespace for Dialog Information

1008

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

1009

See RFCXXXX.

1010 1011 1012 END 1014 6.3 Schema Registration 1016 This specification registers a schema, as per the guidelines in in 1017 [7]. 1019 URI: please assign. 1021 Registrant Contact: IETF, SIPPING Working Group 1022 (sipping@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net). 1024 XML: The XML can be found as the sole content of Section 4.3. 1026 7. Acknowledgements 1028 The author would like to thank Sean Olson for his comments. 1030 Normative References 1032 [1] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1033 Notification", RFC 3265, June 2002. 1035 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1036 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1037 Session Initiation Protocol", RFC 3261, June 2002. 1039 [3] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 1040 Method", RFC 3311, October 2002. 1042 [4] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 1043 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C REC 1044 REC-xml-20001006, October 2000. 1046 [5] Moats, R., "URN Syntax", RFC 2141, May 1997. 1048 [6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 1049 August 1999. 1051 [7] Mealling, M., "The IETF XML Registry", 1052 draft-mealling-iana-xmlns-registry-05 (work in progress), June 1053 2003. 1055 [8] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 1056 3023, January 2001. 1058 [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1059 Levels", BCP 14, RFC 2119, March 1997. 1061 Informative References 1063 [10] Rosenberg, J., "A Presence Event Package for the Session 1064 Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work 1065 in progress), January 2003. 1067 [11] Rosenberg, J., "A Watcher Information Event Template-Package 1068 for the Session Initiation Protocol (SIP)", 1069 draft-ietf-simple-winfo-package-05 (work in progress), January 1070 2003. 1072 [12] Mahy, R., "A Message Summary and Message Waiting Indication 1073 Event Package for the Session Initiation Protocol (SIP)", 1074 draft-ietf-sipping-mwi-02 (work in progress), March 2003. 1076 Authors' Addresses 1078 Jonathan Rosenberg 1079 dynamicsoft 1080 600 Lanidex Plaza 1081 Parsippany, NJ 07054 1082 US 1084 Phone: +1 973 952-5000 1085 EMail: jdrosen@dynamicsoft.com 1086 URI: http://www.jdrosen.net 1088 Henning Schulzrinne 1089 Columbia University 1090 M/S 0401 1091 1214 Amsterdam Ave. 1092 New York, NY 10027 1093 US 1095 EMail: schulzrinne@cs.columbia.edu 1096 URI: http://www.cs.columbia.edu/~hgs 1098 Intellectual Property Statement 1100 The IETF takes no position regarding the validity or scope of any 1101 intellectual property or other rights that might be claimed to 1102 pertain to the implementation or use of the technology described in 1103 this document or the extent to which any license under such rights 1104 might or might not be available; neither does it represent that it 1105 has made any effort to identify any such rights. Information on the 1106 IETF's procedures with respect to rights in standards-track and 1107 standards-related documentation can be found in BCP-11. Copies of 1108 claims of rights made available for publication and any assurances of 1109 licenses to be made available, or the result of an attempt made to 1110 obtain a general license or permission for the use of such 1111 proprietary rights by implementors or users of this specification can 1112 be obtained from the IETF Secretariat. 1114 The IETF invites any interested party to bring to its attention any 1115 copyrights, patents or patent applications, or other proprietary 1116 rights which may cover technology that may be required to practice 1117 this standard. Please address the information to the IETF Executive 1118 Director. 1120 Full Copyright Statement 1122 Copyright (C) The Internet Society (2003). All Rights Reserved. 1124 This document and translations of it may be copied and furnished to 1125 others, and derivative works that comment on or otherwise explain it 1126 or assist in its implementation may be prepared, copied, published 1127 and distributed, in whole or in part, without restriction of any 1128 kind, provided that the above copyright notice and this paragraph are 1129 included on all such copies and derivative works. However, this 1130 document itself may not be modified in any way, such as by removing 1131 the copyright notice or references to the Internet Society or other 1132 Internet organizations, except as needed for the purpose of 1133 developing Internet standards in which case the procedures for 1134 copyrights defined in the Internet Standards process must be 1135 followed, or as required to translate it into languages other than 1136 English. 1138 The limited permissions granted above are perpetual and will not be 1139 revoked by the Internet Society or its successors or assignees. 1141 This document and the information contained herein is provided on an 1142 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1143 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1144 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1145 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1146 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1148 Acknowledgement 1150 Funding for the RFC Editor function is currently provided by the 1151 Internet Society.