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
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
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
889
894
896 If a 200 OK is received on the second dialog, it moves to confirmed:
898
899
903
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
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