idnits 2.17.1
draft-ietf-sipping-dialog-package-01.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 153: '...these parameters MUST be present. They...'
RFC 2119 keyword, line 160: '... and to-tag MUST be present. The to-...'
RFC 2119 keyword, line 176: '...a dialog package MAY contain a body. T...'
RFC 2119 keyword, line 181: '...a dialog package MAY be sent without a...'
RFC 2119 keyword, line 220: '... irrelevant, and SHOULD be longer than...'
(30 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 (March 1, 2003) is 7727 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')
-- Possible downref: Non-RFC (?) normative reference: ref. '7'
** Obsolete normative reference: RFC 3023 (ref. '8') (Obsoleted by RFC 7303)
Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 4 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-01.txt
8 March 1, 2003
9 Expires: September 1, 2003
11 An INVITE Inititiated Dialog Event Package
12 for the Session Initiation Protocol (SIP)
14 STATUS OF THIS MEMO
16 This document is an Internet-Draft and is in full conformance with
17 all provisions of Section 10 of RFC2026.
19 Internet-Drafts are working documents of the Internet Engineering
20 Task Force (IETF), its areas, and its working groups. Note that
21 other groups may also distribute working documents as Internet-
22 Drafts.
24 Internet-Drafts are draft documents valid for a maximum of six months
25 and may be updated, replaced, or obsoleted by other documents at any
26 time. It is inappropriate to use Internet-Drafts as reference
27 material or to cite them other than as "work in progress".
29 The list of current Internet-Drafts can be accessed at
30 http://www.ietf.org/ietf/1id-abstracts.txt
32 To view the list Internet-Draft Shadow Directories, see
33 http://www.ietf.org/shadow.html.
35 Abstract
37 This document defines a dialog event package for the SIP Events
38 architecture, along with a data format used in notifications for this
39 package. The dialog package allows users to subscribe to another
40 user, an receive notifications about the changes in state of INVITE
41 initiated dialogs that the user is involved in.
43 Table of Contents
45 1 Introduction ........................................ 3
46 2 Dialog Event Package ................................ 4
47 2.1 Event Package Name .................................. 4
48 2.2 Event Package Parameters ............................ 4
49 2.3 SUBSCRIBE Bodies .................................... 4
50 2.4 Subscription Duration ............................... 5
51 2.5 NOTIFY Bodies ....................................... 6
52 2.6 Notifier Processing of SUBSCRIBE Requests ........... 6
53 2.7 Notifier Generation of NOTIFY Requests .............. 6
54 2.7.1 The Dialog State Machine ............................ 7
55 2.7.2 Applying the state machine .......................... 8
56 2.8 Subscriber Processing of NOTIFY Requests ............ 10
57 2.9 Handling of Forked Requests ......................... 11
58 2.10 Rate of Notifications ............................... 11
59 2.11 State Agents ........................................ 11
60 3 Dialog Information Format ........................... 11
61 3.1 Structure of Dialog Information ..................... 12
62 3.1.1 Dialog Element ...................................... 12
63 3.1.2 State ............................................... 13
64 3.1.3 Local URI ........................................... 13
65 3.1.4 Remote URI .......................................... 13
66 3.1.5 Local Session Description ........................... 13
67 3.1.6 Remote Session Description .......................... 14
68 3.1.7 Remote Target ....................................... 14
69 3.1.8 Local CSeq .......................................... 14
70 3.1.9 Remote CSeq ......................................... 14
71 3.1.10 Duration ............................................ 14
72 3.2 Constructing Coherent State ......................... 14
73 3.3 Schema .............................................. 15
74 3.4 Example ............................................. 18
75 4 Security Considerations ............................. 21
76 5 IANA Considerations ................................. 21
77 5.1 application/dialog-info+xml MIME Registration ....... 21
78 5.2 URN Sub-Namespace Registration for
79 urn:ietf:params:xml:ns:dialog-info ............................. 22
80 6 Acknowledgements .................................... 23
81 7 Authors Addresses ................................... 23
82 8 Normative References ................................ 23
83 9 Informative References .............................. 24
85 1 Introduction
87 The SIP Events framework [1] defines general mechanisms for
88 subscription to, and notification of, events within SIP networks. It
89 introduces the notion of a package, which is a specific
90 "instantiation" of the events mechanism for a well-defined set of
91 events. Packages have been defined for user presence [9], watcher
92 information [10], and message waiting indicators [11], amongst
93 others. Here, we define an event package for INVITE initiated
94 dialogs. Dialogs refer to the SIP relationship established between
95 two SIP peers [2]. Dialogs can be created by many methods, although
96 RFC 3261 defines only one - the INVITE method. RFC 3265 defines the
97 SUBSCRIBE and NOTIFY methods, which also create dialogs. However, the
98 usage of this package to model transitions in the state of those
99 dialogs is out of the scope of this specification.
101 There are a variety of applications enabled through the knowledge of
102 INVITE dialog state. Some examples include:
104 Automatic Callback: In this basic Public Switched Telephone
105 Network (PSTN) application, user A calls user B. User B is
106 busy. User A would like to get a callback when user B hangs
107 up. When B hangs up, user A's phone rings. When A picks it
108 up, they here ringing, and are being connected to B. To
109 implement this with SIP, a mechanism is required for B to
110 receive a notification when the dialogs at A are complete.
112 Presence-Enabled Conferencing: In this application, a user A
113 wishes to set up a conference call with users B and C.
114 Rather than scheduling it, it is to be created
115 automatically when A, B and C are all available. To do
116 this, the server providing the application would like to
117 know whether A, B and C are "online", not idle, and not in
118 a phone call. Determining whether or not A, B and C are in
119 calls can be done in two ways. In the first, the server
120 acts as a call stateful proxy for users A, B and C, and
121 therefore knows their call state. This won't always be
122 possible, however, and it introduces scalability,
123 reliability, and operational complexities. Rather, the
124 server would subscriber to the dialog state of those users,
125 and receive notifications as it changes. This enables the
126 application to be provided in a distributed way; the server
127 need not reside in the same domain as the users.
129 IM Conference Alerts: In this application, a user can get an IM
130 sent to their phone whenever someone joins a conference
131 that the phone is involved in. The IM alerts are generated
132 by an application separate from the conference server.
134 In general, the dialog package allows for construction of distributed
135 applications, where the application requires information on dialog
136 state, but is not co-resident with the end user on which that state
137 resides.
139 2 Dialog Event Package
141 This section provides the details for defining a SIP Events package,
142 as specified by [1].
144 2.1 Event Package Name
146 The name of this event package is "dialog". This package name is
147 carried in the Event and Allow-Events header, as defined in [1].
149 2.2 Event Package Parameters
151 This package defines three Event Package parameters. They are call-
152 id, to-tag and from-tag. If a subscription to a specific dialog is
153 requested, all three of these parameters MUST be present. They
154 identify the dialog or that is being subscribed to. The to-tag is
155 matched against the local tag, the from-tag is matched against the
156 remote tag, and the call-id is matched against the Call-ID.
158 It is also possible to subscribe to the set of dialogs created as a
159 result of a single INVITE sent by a UAC. In that case, the call-id
160 and to-tag MUST be present. The to-tag is matched against the local
161 tag, and the call-id is matched against the Call-ID.
163 The BNF for these parameters is:
165 call-id = "call-id" EQUAL SWS DQUOTE callid DQUOTE
166 ;;callid, EQUAL, SWS, DQUOTE from rfc3261
167 from-tag = "from-tag" EQUAL token
168 to-tag = "to-tag" EQUAL token
170 Note that the call-id parameter is a quoted string. This is because
171 the BNF for word (which is used by callid) allows for characters not
172 allowed within token.
174 2.3 SUBSCRIBE Bodies
176 A SUBSCRIBE for a dialog package MAY contain a body. This body
177 defines a filter to apply to the subscription. Filter documents are
178 not specified in this document, and at the time of writing, are
179 expected to be the subject of future standardization activity.
181 A SUBSCRIBE for a dialog package MAY be sent without a body. This
182 implies the default subscription filtering policy. The default policy
183 is:
185 o If the Event header field contained dialog identifiers,
186 notifications are generated every time there is a change in
187 the state of any matching dialogs for the user identified in
188 the request URI of the SUBSCRIBE.
190 o If there were no dialog identifiers in the Event header field,
191 notifications are generated every time there is any change in
192 the state of any dialogs for the user identified in the
193 request URI of the SUBSCRIBE.
195 o Notifications do not normally contain full state; rather, they
196 only indicate the state of the dialog whose state has changed.
197 The exception is a NOTIFY sent in response to a SUBSCRIBE.
198 These NOTIFYs contain the complete view of dialog state.
200 o The notifications contain the identities of the participants
201 in the dialog, and the dialog identifiers. Additional
202 information, such as the route set, remote target URI, CSeq
203 numbers, SDP information, and so on, are not included normally
204 unless explicitly requested and/or explicitly authorized.
206 2.4 Subscription Duration
208 Dialog state changes fairly quickly; once established, a typical
209 phone call lasts a few minutes (this is different for other session
210 types, of course). However, the interval between new calls is
211 typically infrequent. As such, we arbitrarily choose a default
212 duration of one hour, and RECOMMEND that clients specify an explicit
213 duration.
215 There are two distinct use cases for dialog state. The first is when
216 a subscriber is interested in the state of a specific dialog or
217 dialogs (and they are authorized to find out about just the state of
218 those dialogs). In that case, when the dialogs terminate, so too does
219 the subscription. In these cases, the value of the subscription
220 duration is largely irrelevant, and SHOULD be longer than the typical
221 duration of a dialog, about two hours would cover most dialogs.
223 In another case, a subscriber is interested in the state of all
224 dialogs for a specific user. In these cases, a shorter interval makes
225 more sense. The default is one hour for these subscriptions.
227 2.5 NOTIFY Bodies
229 As described in RFC 3265 [1], the NOTIFY message will contain bodies
230 that describe the state of the subscribed resource. This body is in a
231 format listed in the Accept header field of the SUBSCRIBE, or a
232 package-specific default if the Accept header field was omitted from
233 the SUBSCRIBE.
235 In this event package, the body of the notification contains a dialog
236 information document. This document describes the state of one or
237 more dialogs associated with the subscribed resource. All subscribers
238 and notifiers MUST support the "application/dialog-info+xml" data
239 format described in 3. The subscribe request MAY contain an Accept
240 header field. If no such header field is present, it has a default
241 value of "application/dialog-info+xml". If the header field is
242 present, it MUST include "application/dialog-info+xml", and MAY
243 include any other types capable of representing dialog state.
245 Of course, the notifications generated by the server MUST be in one
246 of the formats specified in the Accept header field in the SUBSCRIBE
247 request.
249 2.6 Notifier Processing of SUBSCRIBE Requests
251 The dialog information for a user contains sensitive information.
252 Therefore, all subscriptions SHOULD be authenticated and then
253 authorized before approval. All implementors of this package MUST
254 support the digest authentication mechanism as a baseline.
255 Authorization policy is at the discretion of the administrator, as
256 always. However, a few recommendations can be made.
258 It is RECOMMENDED that, if the policy of user B is that user A is
259 allowed to call them, dialog subscriptions from user A be allowed.
260 However, the information provided in the notifications does not
261 contain any dialog identification information; merely an indication
262 of whether the user is in one or more calls, or not. Specifically,
263 they should not be able to find out any more information than if they
264 sent an INVITE.
266 It is RECOMMENDED that if a user agent registers with the address-
267 of-record X, that this user agent authorize subscriptions that come
268 from any entity that can authenticate itself as X. Complete
269 information on the dialog state SHOULD be sent in this case. This
270 authorization behavior allows a group of devices representing a
271 single user to all become aware of each other's state. This is useful
272 for applications such as single-line-extension.
274 2.7 Notifier Generation of NOTIFY Requests
275 Notifications are generated for the dialog package when an INVITE
276 request is sent, when a new dialog comes into existence at a UA, or
277 when the state or characteristics of an existing dialog changes.
278 Therefore, a model of dialog state is needed in order to determine
279 precisely when to send notifications, and what their content should
280 be. The SIP specification has a reasonably well defined lifecycle for
281 dialogs. However, it is not explicitly modelled. This specification
282 provides an explicit model of dialog state through a finite state
283 machine.
285 It is RECOMMENDED that NOTIFY requests only contain information on
286 the dialogs whose state has changed. However, if a notifier receives
287 a SUBSCRIBE request, the triggered NOTIFY SHOULD contain the state of
288 all dialogs that the subscriber is authorized to see.
290 2.7.1 The Dialog State Machine
292 Modelling of dialog state is complicated by two factors. The first is
293 forking, which can cause a single INVITE to generate many dialogs at
294 a UAC. The second is the differing views of state at the UAC and UAS.
295 We have chosen to handle the first issue by extending the dialog FSM
296 to include the states between transmission of the INVITE and the
297 creation of actual dialogs through receipt of 1xx and 2xx responses.
298 As a result, this specification supports the notion of dialog state
299 for dialogs before they are fully instantiated.
301 We have also chosen to use a single FSM for both UAC and UAS.
303 The FSM for dialog state is shown in Figure 1. The FSM is best
304 understood by considering the UAC and UAS cases separately.
306 The FSM is created in the "trying" state when the UAC sends an INVITE
307 request. Upon receipt of a 1xx without a tag (the "1xx-notag" event),
308 the FSM transitions to the "proceeding" state. Note that there is no
309 actual dialog yet, as defined by the SIP specification. However,
310 there is a "half-dialog", in the sense that two of the three
311 components of the dialog ID are known (the call identifier and local
312 tag). If a 1xx with a tag is received, the FSM transitions to the
313 early state. The full dialog identifier is now defined. Had a 2xx
314 been received, the FSM would have transitioned to the "confirmed"
315 state.
317 If, after transitioning to the "early" or "confirmed" states, the UAC
318 receives another 1xx or 2xx respectively with a different tag,
319 another instance of the FSM is created, initialized into the "early"
320 or "confirmed" state respectively. The benefit of this approach is
321 that there will be a single FSM representing the entire state of the
322 invitation and resulting dialog when dealing with the common case of
323 no forking.
325 If the UAC should send a CANCEL, and then subsequently receive a 487
326 to its INVITE transaction, all FSMs spawned from that INVITE
327 transition to the "terminated" state with the event "cancelled". If
328 the INVITE transaction terminates with a non-2xx response for any
329 other reason, all FSMs spawned from that INVITE transition to the
330 terminated state with the event "rejected".
332 Once in the confirmed state, the call is active. It can transition to
333 the terminated state if the UAC sends a BYE or receives a BYE
334 (corresponding to the "hungup" event), if a mid-dialog request
335 generates a 481 or 408 response (corresponding to the "error" event),
336 or a mid-dialog request generates no response (corresponding to the
337 "timeout" event).
339 From the perspective of the UAS, when an INVITE is received, the FSM
340 is created in the "trying" state. If it sends a 1xx without a tag,
341 the FSM transitions to the "proceeding" state. If a 1xx is sent with
342 a tag, the FSM transitions to the "early" state, and if a 2xx is
343 sent, it transitions to the "confirmed" state. If the UAS should
344 receive a CANCEL request and then generate a 487 response to the
345 INVITE (which can occur in the proceeding and early states), the FSM
346 transitions to the terminated state with the event "cancelled". If
347 the UAS should generate any other non-2xx final response to the
348 INVITE request, the FSM transitions to the terminated state with the
349 event "rejected". Once in the "confirmed" state, the transitions to
350 the "terminated" state occur for the same reasons they do in the case
351 of UAC.
353 There should never be a transition from the "trying" state
354 to the "terminated" state with the event "cancelled", since
355 the SIP specification prohibits transmission of CANCEL
356 until a provisional response is received. However, this
357 transition is defined in the FSM just to unify the
358 transitions from trying, proceeding, and early to the
359 terminated state.
361 2.7.2 Applying the state machine
363 The notifier MAY generate a NOTIFY request on any event transition of
364 the FSM. Whether it does or not is policy dependent. However, some
365 general guidelines are provided.
367 When the subscriber is unauthenticated, or is authenticated, but
368 represents a third party with no specific authorization policies, it
369 +----------+ +----------+
370 | | 1xx-notag | |
371 | |----------->| |
372 | Trying | |Proceeding|-----+
373 | |---+ +-----| | |
374 | | | | | | |
375 +----------+ | | +----------+ |
376 | | | | | |
377 | | | | | |
378 +<--C-----C--+ |1xx-tag |
379 | | | | |
380 cancelled| | | V |
381 rejected| | |1xx-tag +----------+ |
382 | | +------->| | |2xx
383 | | | | |
384 +<--C--------------| Early |-----C----+1xx-tag
385 | | | | | | w. new tag
386 | | | |<----C----+ (new
387 | | +----------+ | FSM
388 | | 2xx | | instance
389 | +----------------+ | | created)
390 | | |2xx |
391 | | | |
392 V V V |
393 +----------+ +----------+ |
394 | | | | |
395 | | | | |
396 |Terminated|<-----------| Confirmed|<----+
397 | | hungup | |
398 | | error | |
399 +----------+ timeout +----------+
400 | ^
401 | |
402 | |
403 +------+
404 2xx w. new tag
405 (new FSM instance
406 created)
408 Figure 1: Dialog finite state machine
409 dialogs (i.e., there are no dialog identifiers in the Event header
410 field) are permitted. In that case, actual dialog states across all
411 dialogs not be reported. Rather, a single "virtual" dialog FSM be
412 used, and event transitions on that FSM be reported. If there is any
413 dialog at the UA whose state is "confirmed", the virtual FSM is in
414 the "confirmed" state. If there are no dialogs at the UA in the
415 confirmed state, but there is at least one in the "early" state, the
416 virtual FSM is in the "early" or "confirmed" state. If there are no
417 dialogs in the confirmed or early states, but there is at least one
418 in the "proceeding" state, the virtual FSM is in the "proceeding",
419 "early" or "confirmed" state. If there are no dialogs in the
420 confirmed, early, or proceeding states, but there is at least one in
421 the "trying" state, the virtual FSM is in the "trying", "proceeding",
422 "early" or "confirmed" state. The choice about which state to use
423 depends on whether the UA wishes to let unknown users that their
424 phone is ringing, as opposed to in an active call. It is RECOMMENDED
425 that, in the absence of any preference, "confirmed" is used in all
426 cases. Furthermore, it is RECOMMENDED that the notifications of
427 changes in the virtual FSM machine not convey any information except
428 the state of the FSM and its event transitions - no dialog
429 identifiers (which are ill-defined in this model in any case). The
430 use of this virtual FSM allows for minimal information to be
431 conveyed. A subscriber cannot know how many calls are in progress, or
432 with whom, just that there exists a call. This is the same
433 information they would receive if they simply sent an INVITE to the
434 user instead; a 486 response would indicate that they are on a call.
436 When the subscriber is authenticated, and has authenticated itself
437 with the same address-of-record that the UA itself uses, if no
438 explicit authorization policy is defined, it is RECOMMENDED that all
439 state transitions on dialogs that have been subscribed to (which is
440 either all of them, if no dialog identifiers were present in the
441 Event header field, or a specific set of them identified by the Event
442 header field parameters) be reported, along with complete dialog IDs.
444 The notifier MAY generate a NOTIFY request on any change in the
445 characteristics associated with the dialog. Since these include CSeq
446 numbers and SDP, receipt of re-INVITEs and UPDATE requests [3] which
447 modify this information MAY trigger notifications.
449 2.8 Subscriber Processing of NOTIFY Requests
451 The SIP Events framework expects packages to specify how a subscriber
452 processes NOTIFY requests in any package specific ways, and in
453 particular, how it uses the NOTIFY requests to contruct a coherent
454 view of the state of the subscribed resource.
456 Typically, the NOTIFY for the dialog package will only contain
457 information about those dialogs whose state has changed. To construct
458 a coherent view of the total state of all dialogs, a subscriber to
459 the dialog package will need to combine NOTIFYs received over time.
461 Notifications within this package can convey partial information;
462 that is, they can indicate information about a subset of the state
463 associated with the subscription. This means that an explicit
464 algorithm needs to be defined in order to construct coherent and
465 consistent state. The details of this mechanism are specific to the
466 particular document type. See Section 3.2 for information on
467 constructing coherent information from an application/dialog-info+xml
468 document.
470 2.9 Handling of Forked Requests
472 Since dialog state is distributed across the UA for a particular
473 user, it is reasonable and useful for a SUBSCRIBE request for dialog
474 state to fork, and reach multiple UA.
476 As a result, a forked SUBSCRIBE request for dialog state can install
477 multiple subscriptions. Subscribers to this package MUST be prepared
478 to install subscription state for each NOTIFY generated as a result
479 of a single SUBSCRIBE.
481 2.10 Rate of Notifications
483 For reasons of congestion control, it is important that the rate of
484 notifications not become excessive. As a result, it is RECOMMENDED
485 that the server not generate notifications for a single subscriber at
486 a rate faster than once every 5 seconds.
488 2.11 State Agents
490 Dialog state is ideally maintained in the user agents in which the
491 dialog resides. Therefore, the elements that maintain the dialog are
492 the ones best suited to handle subscriptions to it. Therefore, the
493 usage of state agents is NOT RECOMMENDED for this package.
495 3 Dialog Information Format
497 Dialog information is an XML document [4] that MUST be well-formed
498 and SHOULD be valid. Dialog information documents MUST be based on
499 XML 1.0 and MUST be encoded using UTF-8. This specification makes use
500 of XML namespaces for identifying dialog information documents and
501 document fragments. The namespace URI for elements defined by this
502 specification is a URN [5], using the namespace identifier 'ietf'
503 defined by [6] and extended by [7]. This URN is:
505 urn:ietf:params:xml:ns:dialog-info
507 A dialog information document begins with the root element tag
508 "dialog-info".
510 3.1 Structure of Dialog Information
512 A dialog information document starts with a dialog-info element. This
513 element has three mandatory attributes:
515 version: This attribute allows the recipient of dialog
516 information documents to properly order them. Versions
517 start at 0, and increment by one for each new document sent
518 to a subscriber. Versions are scoped within a subscription.
519 Versions MUST be representable using a 32 bit integer.
521 state: This attribute indicates whether the document contains
522 the full dialog information, or whether it contains only
523 information on those dialogs which have changed since the
524 previous document (partial).
526 entity: This attribute contains a URI that identifies the user
527 whose dialog information is reported in the remainder of
528 the document.
530 The dialog-info element has a series of dialog sub-elements. Each of
531 those represents a specific dialog.
533 3.1.1 Dialog Element
535 The dialog element reports information on a specific dialog or
536 "half-dialog". It has a single mandatory attribute, id. The id
537 attribute provides a single string that can be used as an identifier
538 for this dialog or "half-dialog". This is a different identifier than
539 the dialog ID defined in RFC 3261 [2], but related to it.
541 For a caller, the id is created when an INVITE request is sent. When
542 a 1xx with a tag, or a 2xx is received, the dialog is formally
543 created. The id remains unchanged. However, if an additional 1xx or
544 2xx is received, resulting in the creation of another dialog (and
545 resulting FSM), that dialog is allocated a new id.
547 For a callee, the id is created when an INVITE outside of an existing
548 dialog is received. When a 2xx or a 1xx with a tag is sent, creating
549 the dialog, the id remains unchanged.
551 The id MUST be unique amongst all dialogs at a UA.
553 There are a number of optional attributes which provide
554 identification information about the dialog:
556 call-id: This attribute is a string which represents the call-id
557 component of the dialog identifier.
559 local-tag: This attribute is a string which represents the
560 local-tag component of the dialog identifier.
562 remote-tag: This attribute is a string which represents the
563 remote-tag component of the dialog identifier. The remote
564 tag attribute won't be present if there is only a "half-
565 dialog", resulting from the generation of an INVITE for
566 which no final responses or provisional responses with tags
567 has been received.
569 direction: This attribute is either initiator or recipient, and
570 indicates whether the notifier was the initiator of the
571 dialog, or the recipient of the INVITE that created it.
573 The sub-elements of the dialog element provide additional information
574 about the dialog. The only mandatory one is state.
576 3.1.2 State
578 The state element indicates the state of the dialog. Its value is an
579 enumerated type describing one of the states in the FSM above. It has
580 an optional event attribute that can be used to indicate the event
581 which caused the transition into the current state, and an optional
582 code attribute that indicates the response code associated with the
583 transition, assuming the event was 1xx-tag, 1xx-notag, or 2xx.
585 3.1.3 Local URI
587 The local-uri element indicates the local URI, as defined in [2]. It
588 has an optional attribute, display-name, that contains the display
589 name from the local URI.
591 3.1.4 Remote URI
593 The remote-uri element indicates the remote URI, as defined in [2].
594 It has an optional attribute, display-name, that contains the display
595 name from the remote URI.
597 3.1.5 Local Session Description
598 The local-session-description element contains the session
599 description used by the notifier for its end of the dialog. This
600 element should generally NOT be included in the notifications, unless
601 explicitly requested by the subscriber. It has a single attribute,
602 type, which indicates the MIME media type of the session description.
604 3.1.6 Remote Session Description
606 The remote-session-description element contains the session
607 description used by the peer of the notifier for its end of the
608 dialog. This element should generally NOT be included in the
609 notifications, unless explicitly requested by the subscriber. It has
610 a single attribute, type, which indicates the MIME media type of the
611 session description.
613 3.1.7 Remote Target
615 The remote-target contains the remote-target URI as constructed by
616 the user agent for this dialog, as defined in RFC 3261 [2]. This
617 element should generally not be included in notifications, unless
618 explicitly requested by the subscriber.
620 3.1.8 Local CSeq
622 The local-cseq element contains the most recent value of the CSeq
623 header used by the UA in an outgoing request on the dialog. This
624 element should generally NOT be included in the notifications, unless
625 explicitly requested by the subscriber. If no CSeq has yet been
626 defined, the value of the element is -1.
628 3.1.9 Remote CSeq
630 The remote-cseq element contains the most recent value of the CSeq
631 header seen by the UA in an incoming request on the dialog. This
632 element should generally NOT be included in the notifications, unless
633 explicitly requested by the subscriber. If no CSeq has yet been
634 defined, the value of the element is -1.
636 3.1.10 Duration
638 The duration element contains the amount of time, in seconds, since
639 the FSM was created.
641 3.2 Constructing Coherent State
643 The dialog information subscriber maintains a table for the list of
644 dialogs. The table contains a row for each dialog. Each row is
645 indexed by an ID, present in the "id" attribute of the "dialog"
646 element. The contents of each row contain the state of that dialog as
647 conveyed in the document. The table is also associated with a version
648 number. The version number MUST be initialized with the value of the
649 "version" attribute from the "dialog-info" element in the first
650 document received. Each time a new document is received, the value of
651 the local version number, and the "version" attribute in the new
652 document, are compared. If the value in the new document is one
653 higher than the local version number, the local version number is
654 increased by one, and the document is processed. If the value in the
655 document is more than one higher than the local version number, the
656 local version number is set to the value in the new document, and the
657 document is processed. If the document did not contain full state,
658 the subscriber SHOULD generate a refresh request to trigger a full
659 state notification. If the value in the document is less than the
660 local version, the document is discarded without processing.
662 The processing of the dialog information document depends on whether
663 it contains full or partial state. If it contains full state,
664 indicated by the value of the "state" attribute in the "dialog-info"
665 element, the contents of the table are flushed. They are repopulated
666 from the document. A new row in the table is created for each
667 "dialog" element. If the document contains partial state, as
668 indicated by the value of the "state" attribute in the "dialog-info"
669 element, the document is used to update the table. For each "dialog"
670 element in the document, the subscriber checks to see whether a row
671 exists for that dialog. This check is done by comparing the ID in the
672 "id" attribute of the "dialog" element with the ID associated with
673 the row. If the dialog doesn't exist in the table, a row is added,
674 and its state is set to the information from that "dialog" element.
675 If the dialog does exist, its state is updated to be the information
676 from that "dialog" element. If a row is updated or created, such that
677 its state is now terminated, that entry MAY be removed from the table
678 at any time.
680 3.3 Schema
682 The following is the schema for the application/dialog-info+xml type:
684
685
689
690
693
694
695
696
697
699
700
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
719
721
723
725
727
729
731
733
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
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
795
796
797
798
799
800
801
802
803
804
805
806
808 3.4 Example
810 For example, if a UAC sends an INVITE that looks like, in part:
812 INVITE sip:bob@example.com SIP/2.0
813 Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8
814 Max-Forwards: 70
815 To: Bob
816 From: Alice ;tag=1928301774
817 Call-ID: a84b4c76e66710
818 CSeq: 314159 INVITE
819 Contact:
820 Content-Type: application/sdp
821 Content-Length: 142
823 [SDP not shown]
825 The XML document in a notification from Alice might look like:
827
828
832
836
838 If the following 180 response is received:
840 SIP/2.0 180 Ringing
841 Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8
842 To: Bob ;tag=456887766
843 From: Alice ;tag=1928301774
844 Call-ID: a84b4c76e66710
845 CSeq: 314159 INVITE
846 Contact:
848 The XML document in a notification might look like:
850
851
855
860
862 If it receives a second 180 with a different tag:
864 SIP/2.0 180 Ringing
865 Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8
866 To: Bob ;tag=hh76a
867 From: Alice ;tag=1928301774
868 Call-ID: a84b4c76e66710
869 CSeq: 314159 INVITE
870 Contact:
872 This results in the creation of a second dialog:
874
875
879
884
889
891 If a 200 OK is received on the second dialog, it moves to confirmed:
893
894
898
903
904 32 seconds later, the other early dialog terminates because no 2xx is
905 received for it. This implies that it was successfully cancelled, and
906 therefore the following notification is sent:
908
909
913
918
920 4 Security Considerations
922 Subscriptions to dialog state can reveal sensitive information. For
923 this reason, Section 2.6 discusses authentication and authorization
924 of subscriptions, and provides guidelines on sensible authorization
925 policies. All implementations of this package MUST support the digest
926 authentication mechanism.
928 Since the data in notifications is sensitive as well, end-to-end SIP
929 encryption mechanisms using S/MIME MAY be used to protect it.
931 5 IANA Considerations
933 This document registers a new MIME type, application/dialog-info+xml
934 and registers a new XML namespace.
936 5.1 application/dialog-info+xml MIME Registration
938 MIME media type name: application
940 MIME subtype name: dialog-info+xml
942 Mandatory parameters: none
944 Optional parameters: Same as charset parameter application/xml
945 as specified in RFC 3023 [8].
947 Encoding considerations: Same as encoding considerations of
948 application/xml as specified in RFC 3023 [8].
950 Security considerations: See Section 10 of RFC 3023 [8] and
951 Section 4 of this specification.
953 Interoperability considerations: none.
955 Published specification: This document.
957 Applications which use this media type: This document type has
958 been used to support SIP applications such as call return
959 and auto-conference.
961 Additional Information:
963 Magic Number: None
965 File Extension: .dif or .xml
967 Macintosh file type code: "TEXT"
969 Personal and email address for further information: Jonathan
970 Rosenberg,
972 Intended usage: COMMON
974 Author/Change controller: The IETF.
976 5.2 URN Sub-Namespace Registration for urn:ietf:params:xml:ns:dialog-
977 info
979 This section registers a new XML namespace, as per the guidelines in
980 [7].
982 URI: The URI for this namespace is
983 urn:ietf:params:xml:ns:dialog-info.
985 Registrant Contact: IETF, SIMPLE working group,
986 , Jonathan Rosenberg
987 .
989 XML:
991 BEGIN
992
993
996
997
998
1000 Dialog Information Namespace
1001
1003 Namespace for Dialog Information
1004 application/dialog-info+xml
1005 See RFCXXXX.
1006
1007