idnits 2.17.1
draft-ietf-sipping-dialog-package-06.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1.a on line 20.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 1676.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1653.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1660.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1666.
** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
Acknowledgement.
** This document has an original RFC 3978 Section 5.4 Copyright Line,
instead of the newer IETF Trust Copyright according to RFC 4748.
** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
of the newer disclaimer which includes the IETF Trust according to RFC
4748.
** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate
instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission
of drafts without verbatim RFC 3978 boilerplate is not accepted.
The following non-3978 patterns matched text found in the document.
That text should be removed or replaced:
This document is an Internet-Draft and is subject to all provisions of
Section 3 of RFC 3667.
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== Line 9 has weird spacing: '...Package for t...'
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords.
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (Apr 12, 2005) is 6954 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Unused Reference: '20' is defined on line 1609, but no explicit
reference was found in the text
== Unused Reference: '21' is defined on line 1614, but no explicit
reference was found in the text
** Obsolete normative reference: RFC 3265 (ref. '1') (Obsoleted by RFC 6665)
-- Possible downref: Non-RFC (?) normative reference: ref. '4'
** Obsolete normative reference: RFC 2141 (ref. '5') (Obsoleted by RFC 8141)
** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '6')
** Obsolete normative reference: RFC 3023 (ref. '8') (Obsoleted by RFC 7303)
** Obsolete normative reference: RFC 2246 (ref. '15') (Obsoleted by RFC
4346)
== Outdated reference: A later version (-15) exists of
draft-ietf-sip-gruu-03
== Outdated reference: A later version (-12) exists of
draft-ietf-sipping-cc-transfer-03
Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 SIPPING J. Rosenberg
2 Internet-Draft Cisco Systems
3 Expires: October 11, 2005 H. Schulzrinne
4 Columbia University
5 R. Mahy, Ed.
6 SIP Edge LLC
7 Apr 12, 2005
9 An INVITE Inititiated Dialog Event Package for the Session
10 Initiation Protocol (SIP)
11 draft-ietf-sipping-dialog-package-06.txt
13 Status of this Memo
15 This document is an Internet-Draft and is subject to all provisions
16 of section 3 of RFC 3667. By submitting this Internet-Draft, each
17 author represents that any applicable patent or other IPR claims of
18 which he or she is aware have been or will be disclosed, and any of
19 which he or she become aware will be disclosed, in accordance with
20 RFC 3668.
22 Internet-Drafts are working documents of the Internet Engineering
23 Task Force (IETF), its areas, and its working groups. Note that
24 other groups may also distribute working documents as
25 Internet-Drafts.
27 Internet-Drafts are draft documents valid for a maximum of six months
28 and may be updated, replaced, or obsoleted by other documents at any
29 time. It is inappropriate to use Internet-Drafts as reference
30 material or to cite them other than as "work in progress."
32 The list of current Internet-Drafts can be accessed at
33 http://www.ietf.org/ietf/1id-abstracts.txt.
35 The list of Internet-Draft Shadow Directories can be accessed at
36 http://www.ietf.org/shadow.html.
38 This Internet-Draft will expire on October 11, 2005.
40 Copyright Notice
42 Copyright (C) The Internet Society (2005).
44 Abstract
46 This document defines a dialog event package for the SIP Events
47 architecture, along with a data format used in notifications for this
48 package. The dialog package allows users to subscribe to another
49 user, and receive notifications about the changes in state of INVITE
50 initiated dialog usages that the user is involved in.
52 Table of Contents
54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
56 3. Dialog Event Package . . . . . . . . . . . . . . . . . . . . . 5
57 3.1 Event Package Name . . . . . . . . . . . . . . . . . . . . 5
58 3.2 Event Package Parameters . . . . . . . . . . . . . . . . . 5
59 3.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 6
60 3.4 Subscription Duration . . . . . . . . . . . . . . . . . . 7
61 3.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 7
62 3.6 Notifier Processing of SUBSCRIBE Requests . . . . . . . . 8
63 3.7 Notifier Generation of NOTIFY Requests . . . . . . . . . . 8
64 3.7.1 The Dialog State Machine . . . . . . . . . . . . . . . 9
65 3.7.2 Applying the state machine . . . . . . . . . . . . . . 12
66 3.8 Subscriber Processing of NOTIFY Requests . . . . . . . . . 13
67 3.9 Handling of Forked Requests . . . . . . . . . . . . . . . 13
68 3.10 Rate of Notifications . . . . . . . . . . . . . . . . . . 14
69 3.11 State Agents . . . . . . . . . . . . . . . . . . . . . . . 14
70 4. Dialog Information Format . . . . . . . . . . . . . . . . . . 14
71 4.1 Structure of Dialog Information . . . . . . . . . . . . . 14
72 4.1.1 Dialog Element . . . . . . . . . . . . . . . . . . . . 15
73 4.1.2 State . . . . . . . . . . . . . . . . . . . . . . . . 16
74 4.1.3 Duration . . . . . . . . . . . . . . . . . . . . . . . 16
75 4.1.4 Replaces . . . . . . . . . . . . . . . . . . . . . . . 16
76 4.1.5 Referred-By . . . . . . . . . . . . . . . . . . . . . 17
77 4.1.6 Local and Remote elements . . . . . . . . . . . . . . 17
78 4.1.6.1 Identity . . . . . . . . . . . . . . . . . . . . . 17
79 4.1.6.2 Target . . . . . . . . . . . . . . . . . . . . . . 17
80 4.1.6.3 Session Description . . . . . . . . . . . . . . . 18
81 4.2 Sample Notification Body . . . . . . . . . . . . . . . . . 19
82 4.3 Constructing Coherent State . . . . . . . . . . . . . . . 19
83 4.4 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 20
84 5. Definition of new media feature parameters . . . . . . . . . . 23
85 5.1 The "sip.byeless" parameter . . . . . . . . . . . . . . . 23
86 5.2 The "sip.rendering" parameter . . . . . . . . . . . . . . 24
87 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
88 6.1 Basic Example . . . . . . . . . . . . . . . . . . . . . . 24
89 6.2 Emulating a Shared-Line phone system . . . . . . . . . . . 27
90 6.3 Minimal Dialog Information with Privacy . . . . . . . . . 31
91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32
92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
93 8.1 application/dialog-info+xml MIME Registration . . . . . . 33
94 8.2 URN Sub-Namespace Registration for
95 urn:ietf:params:xml:ns:dialog-info . . . . . . . . . . . . 33
96 8.3 Schema Registration . . . . . . . . . . . . . . . . . . . 34
97 8.4 Media Feature Parameter Registration . . . . . . . . . . . 34
98 8.4.1 sip.byeless . . . . . . . . . . . . . . . . . . . . . 34
99 8.4.2 sip.rendering . . . . . . . . . . . . . . . . . . . . 35
100 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36
101 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
102 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 36
103 10.2 Informative References . . . . . . . . . . . . . . . . . . . 37
104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37
105 Intellectual Property and Copyright Statements . . . . . . . . 39
107 1. Introduction
109 The SIP Events framework [1] defines general mechanisms for
110 subscription to, and notification of, events within SIP networks. It
111 introduces the notion of a package, which is a specific
112 "instantiation" of the events mechanism for a well-defined set of
113 events. Packages have been defined for user presence [16], watcher
114 information [17], and message waiting indicators [18], amongst
115 others. Here, we define an event package for INVITE initiated dialog
116 usages. Dialogs refer to the SIP relationship established between
117 two SIP peers [2]. Dialogs can be created by many methods, although
118 RFC 3261 defines only one - the INVITE method. RFC 3265 defines the
119 SUBSCRIBE and NOTIFY methods, which also create new dialog usages.
120 However, the usage of this package to model transitions in the state
121 of those dialog usages are out of the scope of this specification.
123 There are a variety of applications enabled through the knowledge of
124 INVITE dialog usage state. Some examples include:
125 Automatic Callback: In this basic Public Switched Telephone Network
126 (PSTN) application, user A calls user B. User B is busy. User A
127 would like to get a callback when user B hangs up. When B hangs
128 up, user A's phone rings. When A picks it up, they here ringing,
129 and are being connected to B. To implement this with SIP, a
130 mechanism is required for B to receive a notification when the
131 dialogs at A are complete.
132 Presence-Enabled Conferencing: In this application, a user A wishes
133 to set up a conference call with users B and C. Rather than
134 scheduling it, it is to be created automatically when A, B and C
135 are all available. To do this, the server providing the
136 application would like to know whether A, B and C are "online",
137 not idle, and not in a phone call. Determining whether or not A,
138 B and C are in calls can be done in two ways. In the first, the
139 server acts as a call stateful proxy for users A, B and C, and
140 therefore knows their call state. This won't always be possible,
141 however, and it introduces scalability, reliability, and
142 operational complexities. Rather, the server would subscribe to
143 the dialog state of those users, and receive notifications as it
144 changes. This enables the application to be provided in a
145 distributed way; the server need not reside in the same domain as
146 the users.
147 IM Conference Alerts: In this application, a user can get an Instant
148 Message (IM) sent to their phone whenever someone joins a
149 conference that the phone is involved in. The IM alerts are
150 generated by an application separate from the conference server.
152 In general, the dialog package allows for construction of distributed
153 applications, where the application requires information on dialog
154 state, but is not co-resident with the end user on which that state
155 resides.
157 In addition, this document also defines two new callee capabilities
158 [10] feature parameters: "sip.byeless", which indicates that a SIP
159 User Agent (UA) is not capable of terminating a session itself (for
160 example as with some announcement or recording services, and in some
161 call centers)in which the UA is no longer interested in
162 participating; and "sip.rendering", which positively describes if the
163 User Agent is rendering any of the media it is receiving. These
164 feature parameters are useful in many of the same applications which
165 motivated the dialog package, such as conferencing, presence, and the
166 shared-line example described in Section 6.2.
168 2. Terminology
170 In this document, the key words "MUST", "MUST NOT", "REQUIRED",
171 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
172 and "OPTIONAL" are to be interpreted as described in RFC 2119 [9] and
173 indicate requirement levels for compliant implementations.
175 3. Dialog Event Package
177 This section provides the details for defining a SIP Events package,
178 as specified by [1].
180 3.1 Event Package Name
182 The name of this event package is "dialog". This package name is
183 carried in the Event and Allow-Events header, as defined in [1].
185 3.2 Event Package Parameters
187 This package defines four Event Package parameters. They are
188 call-id, to-tag, from-tag, and include-session-description. If a
189 subscription to a specific dialog is requested, all of the first
190 three of these parameters MUST be present. They identify the dialog
191 that is being subscribed to. The to-tag is matched against the local
192 tag, the from-tag is matched against the remote tag, and the call-id
193 is matched against the Call-ID. The include-session-description
194 parameter indicates if the subscriber would like to receive the
195 session descriptions associated with the subscribed dialog usage or
196 usages.
198 It is also possible to subscribe to the set of dialogs created as a
199 result of a single INVITE sent by a UAC. In that case, the call-id
200 and to-tag MUST be present. The to-tag is matched against the local
201 tag, and the call-id is matched against the Call-ID.
203 The ABNF for these parameters is shown below. It refers to many
204 constructions from the ABNF of RFC3261, such as EQUAL, DQUOTE, and
205 token.
207 call-id = "call-id" EQUAL ( token / DQUOTE callid DQUOTE )
208 ;; NOTE: any DQUOTEs inside callid MUST be escaped!
209 from-tag = "from-tag" EQUAL token
210 to-tag = "to-tag" EQUAL token
211 with-sessd = "include-session-description"
213 Any callids which contain embedded double-quotes MUST escape those
214 double-quotes using the backslash-quoting mechanism. Note that the
215 call-id parameter may need to be expressed as a quoted string. This
216 is because the ABNF for callid and word (which is used by callid)
217 allow for some characters (such as "@", "[", and ":") which are not
218 allowed within a token.
220 3.3 SUBSCRIBE Bodies
222 A SUBSCRIBE for a dialog package MAY contain a body. This body
223 defines a filter to apply to the subscription. Filter documents are
224 not specified in this document, and at the time of writing, are
225 expected to be the subject of future standardization activity.
227 A SUBSCRIBE for a dialog package MAY be sent without a body. This
228 implies the default subscription filtering policy. The default
229 policy is:
230 o If the Event header field contained dialog identifiers,
231 notifications are generated every time there is a change in the
232 state of any matching dialogs for the user identified in the
233 request URI of the SUBSCRIBE.
234 o If there were no dialog identifiers in the Event header field,
235 notifications are generated every time there is any change in the
236 state of any dialogs for the user identified in the request URI of
237 the SUBSCRIBE with the following exceptions. If the target
238 (Contact) URI of a subscriber is equivalent to the remote target
239 URI of a specific dialog, then the dialog element for that dialog
240 is suppressed for that subscriber. (The subscriber is already a
241 party in the dialog directly, so these notifications are
242 superfluous.) If no dialogs remain after supressing dialogs, the
243 entire notification to that subscriber is supressed and the
244 version number in the dialog-info element is not incremented for
245 that subscriber. Implicit filtering for one subscriber does not
246 affect notifications to other subscribers.
247 o Notifications do not normally contain full state; rather, they
248 only indicate the state of the dialog whose state has changed.
249 The exceptions are a NOTIFY sent in response to a SUBSCRIBE, and a
250 NOTIFY that contains no dialog elements. These NOTIFYs contain
251 the complete view of dialog state.
252 o The notifications contain the identities of the participants in
253 the dialog, the target URIs, and the dialog identifiers. Session
254 descriptions are not included normally unless explicitly requested
255 and/or explicitly authorized.
257 3.4 Subscription Duration
259 Dialog state changes fairly quickly; once established, a typical
260 phone call lasts a few minutes (this is different for other session
261 types, of course). However, the interval between new calls is
262 typically infrequent. As such, we arbitrarily choose a default
263 duration of one hour. Clients SHOULD specify an explicit duration.
265 There are two distinct use cases for dialog state. The first is when
266 a subscriber is interested in the state of a specific dialog or
267 dialogs (and they are authorized to find out about just the state of
268 those dialogs). In that case, when the dialogs terminate, so too
269 does the subscription. In these cases, the value of the subscription
270 duration is largely irrelevant, and SHOULD be longer than the typical
271 duration of a dialog, about two hours would cover most dialogs.
273 In another case, a subscriber is interested in the state of all
274 dialogs for a specific user. In these cases, a shorter interval
275 makes more sense. The default is one hour for these subscriptions.
277 3.5 NOTIFY Bodies
279 As described in RFC 3265 [1], the NOTIFY message will contain bodies
280 that describe the state of the subscribed resource. This body is in
281 a format listed in the Accept header field of the SUBSCRIBE, or a
282 package-specific default if the Accept header field was omitted from
283 the SUBSCRIBE.
285 In this event package, the body of the notification contains a dialog
286 information document. This document describes the state of one or
287 more dialogs associated with the subscribed resource. All
288 subscribers and notifiers MUST support the
289 "application/dialog-info+xml" data format described in Section 4.
290 The subscribe request MAY contain an Accept header field. If no such
291 header field is present, it has a default value of
292 "application/dialog-info+xml". If the header field is present, it
293 MUST include "application/dialog-info+xml", and MAY include any other
294 types capable of representing dialog state.
296 Of course, the notifications generated by the server MUST be in one
297 of the formats specified in the Accept header field in the SUBSCRIBE
298 request.
300 3.6 Notifier Processing of SUBSCRIBE Requests
302 The dialog information for a user contains sensitive information.
303 Therefore, all subscriptions SHOULD be authenticated and then
304 authorized before approval. All implementors of this package MUST
305 support the digest authentication mechanism as a baseline.
306 Authorization policy is at the discretion of the administrator, as
307 always. However, a few recommendations can be made.
309 It is RECOMMENDED that, if the policy of user B is that user A is
310 allowed to call them, dialog subscriptions from user A be allowed.
311 However, the information provided in the notifications does not
312 contain any dialog identification information; merely an indication
313 of whether the user is in at least one call, or not. Specifically,
314 they should not be able to find out any more information than if they
315 sent an INVITE. (This concept of a "virtual" dialog is discussed
316 more in Section 3.7.2, and an example of such a notification body is
317 shown below.)
318
319
322
325
327 It is RECOMMENDED that if a user agent registers with the
328 address-of-record X, that this user agent authorize subscriptions
329 that come from any entity that can authenticate itself as X.
330 Complete information on the dialog state SHOULD be sent in this case.
331 This authorization behavior allows a group of devices representing a
332 single user to all become aware of each other's state. This is
333 useful for applications such as single-line-extension.
334 Note that many implementations of "shared-lines" have a feature
335 which allows details of calls on a shared address-of-record to be
336 made private. This is a completely reasonable authorization
337 policy which could result in notifications which contain only the
338 id attribute of the dialog element and the state element when
339 shared-line privacy is requested, and notifications with more
340 complete information when shared-line privacy is not requested.
342 3.7 Notifier Generation of NOTIFY Requests
344 Notifications are generated for the dialog package when an INVITE
345 request is sent, when a new dialog comes into existence at a UA, or
346 when the state or characteristics of an existing dialog changes.
347 Therefore, a model of dialog state is needed in order to determine
348 precisely when to send notifications, and what their content should
349 be. The SIP specification has a reasonably well defined lifecycle
350 for dialogs. However, it is not explicitly modelled. This
351 specification provides an explicit model of dialog state through a
352 finite state machine.
354 It is RECOMMENDED that NOTIFY requests only contain information on
355 the dialogs whose state or participation information has changed.
356 However, if a notifier receives a SUBSCRIBE request, the triggered
357 NOTIFY SHOULD contain the state of all dialogs that the subscriber is
358 authorized to see.
360 3.7.1 The Dialog State Machine
362 Modelling of dialog state is complicated by two factors. The first
363 is forking, which can cause a single INVITE to generate many dialogs
364 at a UAC. The second is the differing views of state at the UAC and
365 UAS. We have chosen to handle the first issue by extending the
366 dialog FSM to include the states between transmission of the INVITE
367 and the creation of actual dialogs through receipt of 1xx and 2xx
368 responses. As a result, this specification supports the notion of
369 dialog state for dialogs before they are fully instantiated.
371 We have also chosen to use a single FSM for both UAC and UAS.
373 +----------+ +----------+
374 | | 1xx-notag | |
375 | |----------->| |
376 | Trying | |Proceeding|-----+
377 | |---+ +-----| | |
378 | | | | | | |
379 +----------+ | | +----------+ |
380 | | | | | |
381 | | | | | |
382 +<--C-----C--+ |1xx-tag |
383 | | | | |
384 cancelled| | | V |
385 rejected| | |1xx-tag +----------+ |
386 | | +------->| | |2xx
387 | | | | |
388 +<--C--------------| Early |-----C---+ 1xx-tag
389 | | replaced | | | | w/new tag
390 | | | |<----C---+ (new FSM
391 | | +----------+ | instance
392 | | 2xx | | created)
393 | +----------------+ | |
394 | | |2xx |
395 | | | |
396 V V V |
397 +----------+ +----------+ |
398 | | | | |
399 | | | | |
400 |Terminated|<-----------| Confirmed|<----+
401 | | error | |
402 | | timeout | |
403 +----------+ replaced +----------+
404 local-bye | ^
405 remote-bye | |
406 | |
407 +------+
408 2xx w. new tag
409 (new FSM instance
410 created)
412 Figure 3
414 The FSM for dialog state is shown in Figure 3. The FSM is best
415 understood by considering the UAC and UAS cases separately.
417 The FSM is created in the "trying" state when the UAC sends an INVITE
418 request. Upon receipt of a 1xx without a tag, the FSM transitions to
419 the "proceeding" state. Note that there is no actual dialog yet, as
420 defined by the SIP specification. However, there is a "half-dialog",
421 in the sense that two of the three components of the dialog ID are
422 known (the call identifier and local tag). If a 1xx with a tag is
423 received, the FSM transitions to the early state. The full dialog
424 identifier is now defined. Had a 2xx been received, the FSM would
425 have transitioned to the "confirmed" state.
427 If, after transitioning to the "early" or "confirmed" states, the UAC
428 receives another 1xx or 2xx respectively with a different tag,
429 another instance of the FSM is created, initialized into the "early"
430 or "confirmed" state respectively. The benefit of this approach is
431 that there will be a single FSM representing the entire state of the
432 invitation and resulting dialog when dealing with the common case of
433 no forking.
435 If the UAC should send a CANCEL, and then subsequently receive a 487
436 to its INVITE transaction, all FSMs spawned from that INVITE
437 transition to the "terminated" state with the event "cancelled". If
438 the UAC receives a new invitation (with a Replaces [13] header) which
439 replaces the current Early or Confirmed dialog, all INVITE
440 transactions spawned from the replaced invitation transition to the
441 "terminated" state with the event "replaced". If the INVITE
442 transaction terminates with a non-2xx response for any other reason,
443 all FSMs spawned from that INVITE transition to the terminated state
444 with the event "rejected".
446 Once in the confirmed state, the call is active. It can transition
447 to the terminated state if the UAC sends a BYE or receives a BYE
448 (corresponding to the "local-bye" and "remote-bye" events as
449 appropriate), if a mid-dialog request generates a 481 or 408 response
450 (corresponding to the "error" event), or a mid-dialog request
451 generates no response (corresponding to the "timeout" event).
453 From the perspective of the UAS, when an INVITE is received, the FSM
454 is created in the "trying" state. If it sends a 1xx without a tag,
455 the FSM transitions to the "proceeding" state. If a 1xx is sent with
456 a tag, the FSM transitions to the "early" state, and if a 2xx is
457 sent, it transitions to the "confirmed" state. If the UAS should
458 receive a CANCEL request and then generate a 487 response to the
459 INVITE (which can occur in the proceeding and early states), the FSM
460 transitions to the terminated state with the event "cancelled". If
461 the UAS should generate any other non-2xx final response to the
462 INVITE request, the FSM transitions to the terminated state with the
463 event "rejected". If the UAS receives a new invitation (with a
464 Replaces [13] header) which replaces the current Confirmed dialog,
465 the replaced invitation transitions to the "terminated" state with
466 the event "replaced". Once in the "confirmed" state, the other
467 transitions to the "terminated" state occur for the same reasons they
468 do in the case of UAC.
470 There should never be a transition from the "trying" state to the
471 "terminated" state with the event "cancelled", since the SIP
472 specification prohibits transmission of CANCEL until a provisional
473 response is received. However, this transition is defined in the
474 FSM just to unify the transitions from trying, proceeding, and
475 early to the terminated state.
477 3.7.2 Applying the state machine
479 The notifier MAY generate a NOTIFY request on any event transition of
480 the FSM. Whether it does or not is policy dependent. However, some
481 general guidelines are provided.
483 When the subscriber is unauthenticated, or is authenticated, but
484 represents a third party with no specific authorization policies, it
485 is RECOMMENDED that subscriptions to an individual dialog, or to a
486 specific set of dialogs, is forbidden. Only subscriptions to all
487 dialogs (i.e., there are no dialog identifiers in the Event header
488 field) are permitted. In that case, actual dialog states across all
489 dialogs will not be reported. Rather, a single "virtual" dialog FSM
490 be used, and event transitions on that FSM be reported.
492 If there is any dialog at the UA whose state is "confirmed", the
493 virtual FSM is in the "confirmed" state. If there are no dialogs at
494 the UA in the confirmed state, but there is at least one in the
495 "early" state, the virtual FSM is in the "early" or "confirmed"
496 state. If there are no dialogs in the confirmed or early states, but
497 there is at least one in the "proceeding" state, the virtual FSM is
498 in the "proceeding", "early" or "confirmed" state. If there are no
499 dialogs in the confirmed, early, or proceeding states, but there is
500 at least one in the "trying" state, the virtual FSM is in the
501 "trying", "proceeding", "early" or "confirmed" state. The choice
502 about which state to use depends on whether the UA wishes to let
503 unknown users know that their phone is ringing, as opposed to in an
504 active call.
506 It is RECOMMENDED that, in the absence of any preference, "confirmed"
507 is used in all cases (as shown in the example in Section 3.6.
508 Furthermore, it is RECOMMENDED that the notifications of changes in
509 the virtual FSM machine not convey any information except the state
510 of the FSM and its event transitions - no dialog identifiers (which
511 are ill-defined in this model in any case). The use of this virtual
512 FSM allows for minimal information to be conveyed. A subscriber
513 cannot know how many calls are in progress, or with whom, just that
514 there exists a call. This is the same information they would receive
515 if they simply sent an INVITE to the user instead; a 486 response
516 would indicate that they are on a call.
518 When the subscriber is authenticated, and has authenticated itself
519 with the same address-of-record that the UA itself uses, if no
520 explicit authorization policy is defined, it is RECOMMENDED that all
521 state transitions on dialogs that have been subscribed to (which is
522 either all of them, if no dialog identifiers were present in the
523 Event header field, or a specific set of them identified by the Event
524 header field parameters) be reported, along with complete dialog IDs.
526 The notifier SHOULD generate a NOTIFY request on any change in the
527 characteristics associated with the dialog. Since these include
528 Contact URIs, Contact parameters and session descriptions, receipt of
529 re-INVITEs and UPDATE requests [3] which modify this information MAY
530 trigger notifications.
532 3.8 Subscriber Processing of NOTIFY Requests
534 The SIP Events framework expects packages to specify how a subscriber
535 processes NOTIFY requests in any package specific ways, and in
536 particular, how it uses the NOTIFY requests to contruct a coherent
537 view of the state of the subscribed resource.
539 Typically, the NOTIFY for the dialog package will only contain
540 information about those dialogs whose state has changed. To
541 construct a coherent view of the total state of all dialogs, a
542 subscriber to the dialog package will need to combine NOTIFYs
543 received over time.
545 Notifications within this package can convey partial information;
546 that is, they can indicate information about a subset of the state
547 associated with the subscription. This means that an explicit
548 algorithm needs to be defined in order to construct coherent and
549 consistent state. The details of this mechanism are specific to the
550 particular document type. See Section 4.3 for information on
551 constructing coherent information from an application/dialog-info+xml
552 document.
554 3.9 Handling of Forked Requests
556 Since dialog state is distributed across the UA for a particular
557 user, it is reasonable and useful for a SUBSCRIBE request for dialog
558 state to fork, and reach multiple UA.
560 As a result, a forked SUBSCRIBE request for dialog state can install
561 multiple subscriptions. Subscribers to this package MUST be prepared
562 to install subscription state for each NOTIFY generated as a result
563 of a single SUBSCRIBE.
565 3.10 Rate of Notifications
567 For reasons of congestion control, it is important that the rate of
568 notifications not become excessive. As a result, it is RECOMMENDED
569 that the server not generate notifications for a single subscriber at
570 a rate faster than once every 1 second.
572 3.11 State Agents
574 Dialog state is ideally maintained in the user agents in which the
575 dialog resides. Therefore, the elements that maintain the dialog are
576 the ones best suited to handle subscriptions to it. However, in some
577 cases, a network agent may also know the state of the dialogs held by
578 a user. As such, state agents MAY be used with this package.
580 4. Dialog Information Format
582 Dialog information is an XML document [4] that MUST be well-formed
583 and SHOULD be valid. Dialog information documents MUST be based on
584 XML 1.0 and MUST be encoded using UTF-8. This specification makes
585 use of XML namespaces for identifying dialog information documents
586 and document fragments. The namespace URI for elements defined by
587 this specification is a URN [5], using the namespace identifier
588 'ietf' defined by [6] and extended by [7]. This URN is:
590 urn:ietf:params:xml:ns:dialog-info
592 A dialog information document begins with the root element tag
593 "dialog-info".
595 4.1 Structure of Dialog Information
597 A dialog information document starts with a dialog-info element.
598 This element has three mandatory attributes:
599 version: This attribute allows the recipient of dialog information
600 documents to properly order them. Versions start at 0, and
601 increment by one for each new document sent to a subscriber.
602 Versions are scoped within a subscription. Versions MUST be
603 representable using a 32 bit integer.
604 state: This attribute indicates whether the document contains the
605 full dialog information, or whether it contains only information
606 on those dialogs which have changed since the previous document
607 (partial).
608 entity: This attribute contains a URI that identifies the user whose
609 dialog information is reported in the remainder of the document.
610 This user is referred to as the "observed user".
612 The dialog-info element has a series of zero or more dialog
613 sub-elements. Each of those represents a specific dialog.
614
615
618
620 4.1.1 Dialog Element
622 The dialog element reports information on a specific dialog or
623 "half-dialog". It has single mandatory attribute: id. The id
624 attribute provides a single string that can be used as an identifier
625 for this dialog or "half-dialog". This is a different identifier
626 than the dialog ID defined in RFC 3261 [2], but related to it.
628 For a caller, the id is created when an INVITE request is sent. When
629 a 1xx with a tag, or a 2xx is received, the dialog is formally
630 created. The id remains unchanged. However, if an additional 1xx or
631 2xx is received, resulting in the creation of another dialog (and
632 resulting FSM), that dialog is allocated a new id.
634 For a callee, the id is created when an INVITE outside of an existing
635 dialog is received. When a 2xx or a 1xx with a tag is sent, creating
636 the dialog, the id remains unchanged.
638 The id MUST be unique amongst all dialogs at a UA.
640 There are a number of optional attributes which provide
641 identification information about the dialog:
642 call-id: This attribute is a string which represents the call-id
643 component of the dialog identifier. (Note that single and double
644 quotes inside a call-id must be escaped using "e; for " and
645 ' for ' .)
646 local-tag: This attribute is a string which represents the local-tag
647 component of the dialog identifier.
648 remote-tag: This attribute is a string which represents the
649 remote-tag component of the dialog identifier. The remote tag
650 attribute won't be present if there is only a "half-dialog",
651 resulting from the generation of an INVITE for which no final
652 responses or provisional responses with tags has been received.
653 direction: This attribute is either initiator or recipient, and
654 indicates whether the observed user was the initiator of the
655 dialog, or the recipient of the INVITE that created it.
657
658
661
665
667 The sub-elements of the dialog element provide additional information
668 about the dialog. Some of these sub-elements provide more detail
669 about the dialog itself, while the local and remote sub-elements
670 describe characteristics of the participants involved in the dialog.
671 The only mandatory sub-element is the state element.
673 4.1.2 State
675 The state element indicates the state of the dialog. Its value is an
676 enumerated type describing one of the states in the FSM above. It
677 has an optional event attribute that can be used to indicate the
678 event which caused any transition into the terminated state, and an
679 optional code attribute that indicates the response code associated
680 with any transition caused by a response to the original INVITE.
682 terminated
684 4.1.3 Duration
686 The duration element contains the amount of time, in seconds, since
687 the FSM was created.
689 145
691 4.1.4 Replaces
693 The replaces element is used to correlate a new dialog with one it
694 replaced as a result of an invitation with a Replaces header. This
695 element is present in the replacement dialog only (the newer dialog)
696 and contains attributes with the call-id, local-tag, and remote-tag
697 of the replaced dialog.
699
702 4.1.5 Referred-By
704 The referred-by element is used to correlate a new dialog with a
705 REFER [12] request which triggered it. The element is present in a
706 dialog which was triggered by a REFER request which contained a
707 Referred-By [11] header and contains the (optional) display name
708 attribute and the Referred-By URI as its value.
710 sip:bob@example.com
712 4.1.6 Local and Remote elements
714 The local and remote elements are sub-elements of the dialog element
715 which contain information about the local and remote participants
716 respectively. They both have a number of optional sub-elements which
717 indicate the identity conveyed by the participant, the target URI,
718 the feature-tags of the target, and the session-description of the
719 participant.
721 4.1.6.1 Identity
723 The identity element indicates a local or remote URI, as defined in
724 [2] as appropriate. It has an optional attribute, display, that
725 contains the display name from the appropriate URI.
726 Note that multiple identities (for example a sip: URI and a tel:
727 URI) could be included if they all correspond to the participant.
728 To avoid repeating identity information in each request, the
729 subscriber can assume that the identity URIs are the same as in
730 previous notifications if no identity elements are present in the
731 corresponding local or remote element. If any identity elements
732 are present in the local or remote part of a notification, the new
733 list of identity tags completely supersedes the old list in the
734 corresponding part.
736
737 sip:anonymous@anonymous.invalid
739 4.1.6.2 Target
741 The target contains the local or remote target URI as constructed by
742 the user agent for this dialog, as defined in RFC 3261 [2] in a "uri"
743 attribute.
745 It can contain a list of Contact header parameters in param
746 sub-elements (such as those defined in [10]). The param element
747 contains two required attributes, pname and pval. Boolean parameters
748 are represented by the explicit pval values "true" and "false" (for
749 example when a feature parameter is explicitly negated). The param
750 element itself has no contents. To avoid repeating Contact
751 information in each request, the subscriber can assume that the
752 target URI and parameters are the same as in previous notifications
753 if no target element is present in the corresponding local or remote
754 element. If a target element is present in the local or remote part
755 of a notification, the new target tag and list of an parameter tags
756 completely supersedes the old target and parameter list in the
757 corresponding part.
759
760
761
762
764 4.1.6.3 Session Description
766 The session-description element contains the session description used
767 by the observed user for its end of the dialog. This element should
768 generally NOT be included in the notifications, unless explicitly
769 requested by the subscriber. It has a single attribute, type, which
770 indicates the MIME media type of the session description. To avoid
771 repeating session description information in each request, the
772 subscriber can assume that the session description is the same as in
773 previous notifications if no session description element is present
774 in the corresponding local or remote element.
776 4.2 Sample Notification Body
778
779
783
798
800 4.3 Constructing Coherent State
802 The dialog information subscriber maintains a table for the list of
803 dialogs. The table contains a row for each dialog. Each row is
804 indexed by an ID, present in the "id" attribute of the "dialog"
805 element. The contents of each row contain the state of that dialog
806 as conveyed in the document. The table is also associated with a
807 version number. The version number MUST be initialized with the
808 value of the "version" attribute from the "dialog-info" element in
809 the first document received. Each time a new document is received,
810 the value of the local version number, and the "version" attribute in
811 the new document, are compared. If the value in the new document is
812 one higher than the local version number, the local version number is
813 increased by one, and the document is processed. If the value in the
814 document is more than one higher than the local version number, the
815 local version number is set to the value in the new document, and the
816 document is processed. If the document did not contain full state,
817 the subscriber SHOULD generate a refresh request to trigger a full
818 state notification. If the value in the document is less than the
819 local version, the document is discarded without processing.
821 The processing of the dialog information document depends on whether
822 it contains full or partial state. If it contains full state,
823 indicated by the value of the "state" attribute in the "dialog-info"
824 element, the contents of the table are flushed. They are repopulated
825 from the document. A new row in the table is created for each
826 "dialog" element. If the document contains partial state, as
827 indicated by the value of the "state" attribute in the "dialog-info"
828 element, the document is used to update the table. For each "dialog"
829 element in the document, the subscriber checks to see whether a row
830 exists for that dialog. This check is done by comparing the ID in
831 the "id" attribute of the "dialog" element with the ID associated
832 with the row. If the dialog doesn't exist in the table, a row is
833 added, and its state is set to the information from that "dialog"
834 element. If the dialog does exist, its state is updated to be the
835 information from that "dialog" element. If a row is updated or
836 created, such that its state is now terminated, that entry MAY be
837 removed from the table at any time.
839 4.4 Schema
841 The following is the schema for the application/dialog-info+xml type:
843
844
850
851
853
854
855
856
858
860
861
863
864
865
866
867
868
869
871
872
873
874
875
876
877
878
879
881
882
883
885
887
889
890
891
893
894
895
896
898
899
900
901
903
905
907
908
909
911
913
915
916
917
918
919
920
921
922
923
924
925
926
927
929
930
931
932
934
935
937
939
940
941
942
943
944
945
947
949
951
952
953
954
955
956
958
959
960
961
962
963
964
965
966
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
1000 5. Definition of new media feature parameters
1002 This section defines two new media feature parameters which are
1003 useful as input to user presence, in conferencing applications, and
1004 in applications like the shared-line example described in Section
1005 6.2. These feature parameters are especially useful when used in
1006 combination with the dialog package, as they allow an authorized
1007 third party to become aware of these characteristics.
1009 5.1 The "sip.byeless" parameter
1011 The "sip.byeless" media feature parameter is a new boolean parameter,
1012 defined in this document, which provides a positive indication that
1013 the User Agent setting the parameter is unable to terminate sessions
1014 on its own (for example, by sending a BYE request). For example,
1015 continuous announcement services and certain recording services are
1016 unable to determine when it would be desirable to terminate a session
1017 and therefore do not have the ability to terminate sessions at all.
1018 Also, many human call centers are configured so that they never
1019 terminate sessions. (This is to prevent call center agents from
1020 accidentally disconnecting the caller.)
1022 Contact:
1023 ;automaton;+sip.byeless
1025 5.2 The "sip.rendering" parameter
1027 The "sip.rendering" media feature parameter is a new string
1028 parameter, defined in this document, which can provide a positive
1029 indication whether the User Agent setting the parameter is currently
1030 rendering any of the media it is receiving in the context of a
1031 specific session. It MUST only be used in a Contact header field in
1032 a dialog created using the INVITE request. (Note that per [10] this
1033 parameter name must be preceeded by a "+" character when used in a
1034 SIP Contact header field.)
1036 This parameter has three legal values: "yes", "no", and "unknown".
1037 The value "yes" indicates positive knowledge that the User Agent is
1038 rendering at least one of the streams of media that it is receiving.
1039 The value "no" indicates positive knowledge that the User Agent is
1040 rendering none of the media that it is receiving. The value
1041 "unknown" indicates that the User Agent does not know whether the
1042 media associated with the session is being rendered. (which may be
1043 the case if the User Agent is acting as a 3pcc (Third Party Call
1044 Control) [19] controller).
1046 The "sip.rendering" parameter is useful in applications such as
1047 shared appearances, conference status monitoring, or as an input to
1048 user presence.
1050 Contact:
1051 ;automaton;+sip.rendering="no"
1053 6. Examples
1055 6.1 Basic Example
1057 For example, if a UAC sends an INVITE that looks like, in part:
1059 INVITE sip:bob@example.com SIP/2.0
1060 Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8
1061 Max-Forwards: 70
1062 To: Bob
1063 From: Alice ;tag=1928301774
1064 Call-ID: a84b4c76e66710
1065 CSeq: 314159 INVITE
1066 Contact:
1067 Content-Type: application/sdp
1068 Content-Length: 142
1070 [SDP not shown]
1072 The XML document in a notification from Alice might look like:
1074
1075
1079
1083
1085 If the following 180 response is received:
1087 SIP/2.0 180 Ringing
1088 Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8
1089 To: Bob ;tag=456887766
1090 From: Alice ;tag=1928301774
1091 Call-ID: a84b4c76e66710
1092 CSeq: 314159 INVITE
1093 Contact:
1095 The XML document in a notification might look like:
1097
1098
1102
1107
1109 If it receives a second 180 with a different tag:
1111 SIP/2.0 180 Ringing
1112 Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8
1113 To: Bob ;tag=hh76a
1114 From: Alice ;tag=1928301774
1115 Call-ID: a84b4c76e66710
1116 CSeq: 314159 INVITE
1117 Contact:
1119 This results in the creation of a second dialog:
1121
1122
1126
1131
1136
1138 If a 200 OK is received on the second dialog, it moves to confirmed:
1140
1141
1145
1150
1152 32 seconds later, the other early dialog terminates because no 2xx is
1153 received for it. This implies that it was successfully cancelled,
1154 and therefore the following notification is sent:
1156
1157
1161
1166
1168 6.2 Emulating a Shared-Line phone system
1170 The following example shows how a SIP telephone user agent can
1171 provide detailed state information and also emulate a shared-line
1172 telephone system (the phone "lies" about having a dialog while it is
1173 merely offhook).
1175 Idle:
1177
1178
1181
1183 Seized:
1185
1186
1189
1192
1194 Dialing:
1196
1197
1200
1213
1215 Ringing:
1217
1218
1221
1229
1231 Answered (by voicemail):
1233
1234
1237
1242
1254
1256 Alice requests voicemail for Bob's attendant.
1257 (Alice presses "0" in North America / "9" in Europe)
1258 Voicemail completes a transfer with Cathy
1260
1261
1264
1269
1294
1296 Alice and Cathy talk, Cathy adds Alice to a local conference.
1298
1299
1302
1312
1314 Alice puts Cathy on hold
1316
1317
1320
1330
1331 Cathy hangs up
1333
1334
1337
1342
1345
1347 Alice hangs up:
1349
1350
1353
1355 6.3 Minimal Dialog Information with Privacy
1357 The following example shows the same user agent providing minimal
1358 information to maintain privacy for services like automatic callback.
1360 Onhook:
1362
1363
1366
1368 Offhook: (implementation/policy choice for Alice to transition
1369 to this "state" when "seized", when Trying, when Proceeding,
1370 or when Confirmed.)
1372
1373
1376
1379
1381 Onhook: (implementation/policy choice for Alice to transition to
1382 this "state" when terminated, or when no longer "seized")
1384
1385
1388
1390 7. Security Considerations
1392 Subscriptions to dialog state can reveal sensitive information. For
1393 this reason, Section 3.6 discusses authentication and authorization
1394 of subscriptions, and provides guidelines on sensible authorization
1395 policies. All implementations of this package MUST support the
1396 digest authentication mechanism.
1398 Since the data in notifications is sensitive as well, end-to-end SIP
1399 encryption mechanisms using S/MIME MAY be used to protect it. User
1400 Agents that implement the dialog package SHOULD also implement SIP
1401 over TLS [15] and the sips: scheme.
1403 8. IANA Considerations
1405 This document registers a new MIME type, application/dialog-info+xml;
1406 a new XML namespace; and two new media feature parameters in the SIP
1407 tree.
1409 8.1 application/dialog-info+xml MIME Registration
1410 MIME media type name: application
1411 MIME subtype name: dialog-info+xml
1412 Mandatory parameters: none
1413 Optional parameters: Same as charset parameter application/xml as
1414 specified in RFC 3023 [8].
1415 Encoding considerations: Same as encoding considerations of
1416 application/xml as specified in RFC 3023 [8].
1417 Security considerations: See Section 10 of RFC 3023 [8] and Section 7
1418 of this specification.
1419 Interoperability considerations: none.
1420 Published specification: This document.
1421 Applications which use this media type: This document type has been
1422 used to support SIP applications such as call return and
1423 auto-conference.
1424 Additional Information:
1425 Magic Number: None
1426 File Extension: .xml
1427 Macintosh file type code: "TEXT"
1428 Personal and email address for further information: Jonathan
1429 Rosenberg,
1430 Intended usage: COMMON
1431 Author/Change controller: The IETF.
1433 8.2 URN Sub-Namespace Registration for
1434 urn:ietf:params:xml:ns:dialog-info
1436 This section registers a new XML namespace, as per the guidelines in
1437 [7].
1438 URI: The URI for this namespace is
1439 urn:ietf:params:xml:ns:dialog-info.
1440 Registrant Contact: The IESG,
1441 XML:
1443 BEGIN
1444
1445
1447
1448
1449
1451 Dialog Information Namespace
1452
1453
1454 Namespace for Dialog Information
1455 urn:ietf:params:xml:ns:dialog-info
1456 See RFCXXXX.
1457
1458
1459 END
1461 8.3 Schema Registration
1463 This specification registers a schema, as per the guidelines in in
1464 [7].
1465 URI: please assign.
1466 Registrant Contact: The IESG,
1467 XML: The XML can be found as the sole content of Section 4.4.
1469 8.4 Media Feature Parameter Registration
1471 This section registers two new media feature tags, per the procedures
1472 defined in RFC 2506 [14]. The tags are placed into the sip tree,
1473 which is defined in [10].
1475 8.4.1 sip.byeless
1476 Media feature tag name sip.byeless
1477 ASN.1 Identifier New assignment by IANA.
1478 Summary of the media feature indicated by this tag This feature tag
1479 is a boolean flag. When set it indicates that the device is
1480 incapable of terminating a session autonomously.
1481 Values appropriate for use with this feature tag Boolean.
1482 The feature tag is intended primarily for use in the following
1483 applications, protocols, services, or negotiation mechanisms This
1484 feature tag is most useful in a communications application for
1485 describing the capabilities of an application, such as an
1486 announcement service, recording service, conference, or call
1487 center.
1489 Examples of typical use Call centers and media services.
1490 Related standards or documents RFC XXXX [[Note to IANA: Please
1491 replace XXXX with the RFC number of this specification.]]
1492 Security Considerations This media feature tag can be used in ways
1493 which affect application behaviors or may reveal private
1494 information. For example, a conferencing or other application may
1495 decide to terminate a call prematurely if this media feature tag
1496 is set. Therefore, if an attacker can modify the values of this
1497 tag, they may be able to affect the behavior of applications. As
1498 a result of this, applications which utilize this media feature
1499 tag SHOULD provide a means for ensuring its integrity. Similarly,
1500 this feature tag should only be trusted as valid when it comes
1501 from the user or user agent described by the tag. As a result,
1502 protocols for conveying this feature tag SHOULD provide a
1503 mechanism for guaranteeing authenticity.
1505 8.4.2 sip.rendering
1506 Media feature tag name sip.rendering
1507 ASN.1 Identifier New assignment by IANA.
1508 Summary of the media feature indicated by this tag This feature tag
1509 contains one of three string values indicating if the device is
1510 rendering any media from the current session ("yes"), none of the
1511 media from the current session ("no"), or if this status is not
1512 known to the device ("unknown").
1513 Values appropriate for use with this feature tag String.
1514 The feature tag is intended primarily for use in the following
1515 applications, protocols, services, or negotiation mechanisms This
1516 feature tag is most useful in a communications application, for
1517 describing the state of a device (such as a phone or PDA) during a
1518 multimedia session.
1519 Examples of typical use Conferencing, telephone shared-line
1520 emulation, and presence applications.
1521 Related standards or documents RFC XXXX [[Note to IANA: Please
1522 replace XXXX with the RFC number of this specification.]]
1523 Security Considerations This media feature tag can be used in ways
1524 which affect application behaviors or may reveal private
1525 information. For exmaple, a conferencing or other application may
1526 decide to terminate a call prematurely if this media feature tag
1527 is set to "no". Therefore, if an attacker can modify the values
1528 of this tag, they may be able to affect the behavior of
1529 applications. As a result of this, applications which utilize
1530 this media feature tag SHOULD provide a means for ensuring its
1531 integrity. Similarly, this feature tag should only be trusted as
1532 valid when it comes from the user or user agent described by the
1533 tag. As a result, protocols for conveying this feature tag SHOULD
1534 provide a mechanism for guaranteeing authenticity.
1536 9. Acknowledgements
1538 The authors would like to thank Sean Olson for his comments.
1540 10. References
1542 10.1 Normative References
1544 [1] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
1545 Notification", RFC 3265, June 2002.
1547 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
1548 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
1549 Session Initiation Protocol", RFC 3261, June 2002.
1551 [3] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
1552 Method", RFC 3311, October 2002.
1554 [4] Paoli, J., Sperberg-McQueen, C., Bray, T. and E. Maler,
1555 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
1556 FirstEdition REC-xml-20001006, October 2000.
1558 [5] Moats, R., "URN Syntax", RFC 2141, May 1997.
1560 [6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
1561 August 1999.
1563 [7] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1564 January 2004.
1566 [8] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC
1567 3023, January 2001.
1569 [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
1570 Levels", BCP 14, RFC 2119, March 1997.
1572 [10] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Indicating User
1573 Agent Capabilities in the Session Initiation Protocol (SIP)",
1574 RFC 3840, August 2004.
1576 [11] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By
1577 Mechanism", RFC 3892, September 2004.
1579 [12] Sparks, R., "The Session Initiation Protocol (SIP) Refer
1580 Method", RFC 3515, April 2003.
1582 [13] Mahy, R., Biggs, B. and R. Dean, "The Session Initiation
1583 Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
1585 [14] Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag
1586 Registration Procedure", BCP 31, RFC 2506, March 1999.
1588 [15] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
1589 2246, January 1999.
1591 10.2 Informative References
1593 [16] Rosenberg, J., "A Presence Event Package for the Session
1594 Initiation Protocol (SIP)", RFC 3856, August 2004.
1596 [17] Rosenberg, J., "A Watcher Information Event Template-Package
1597 for the Session Initiation Protocol (SIP)", RFC 3857, August
1598 2004.
1600 [18] Mahy, R., "A Message Summary and Message Waiting Indication
1601 Event Package for the Session Initiation Protocol (SIP)", RFC
1602 3842, August 2004.
1604 [19] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo,
1605 "Best Current Practices for Third Party Call Control (3pcc) in
1606 the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April
1607 2004.
1609 [20] Rosenberg, J., "Obtaining and Using Globally Routable User
1610 Agent (UA) URIs (GRUU) in the Session Initiation Protocol
1611 (SIP)", draft-ietf-sip-gruu-03 (work in progress), February
1612 2005.
1614 [21] Sparks, R. and A. Johnston, "Session Initiation Protocol Call
1615 Control - Transfer", draft-ietf-sipping-cc-transfer-03 (work in
1616 progress), October 2004.
1618 Authors' Addresses
1620 Jonathan Rosenberg
1621 Cisco Systems
1622 600 Lanidex Plaza
1623 Parsippany, NJ 07054
1624 US
1626 Phone: +1 973 952-5000
1627 EMail: jdrosen@cisco.com
1628 URI: http://www.jdrosen.net
1629 Henning Schulzrinne
1630 Columbia University
1631 M/S 0401
1632 1214 Amsterdam Ave.
1633 New York, NY 10027
1634 US
1636 EMail: schulzrinne@cs.columbia.edu
1637 URI: http://www.cs.columbia.edu/~hgs
1639 Rohan Mahy (editor)
1640 SIP Edge LLC
1642 EMail: rohan@ekabal.com
1644 Intellectual Property Statement
1646 The IETF takes no position regarding the validity or scope of any
1647 Intellectual Property Rights or other rights that might be claimed to
1648 pertain to the implementation or use of the technology described in
1649 this document or the extent to which any license under such rights
1650 might or might not be available; nor does it represent that it has
1651 made any independent effort to identify any such rights. Information
1652 on the procedures with respect to rights in RFC documents can be
1653 found in BCP 78 and BCP 79.
1655 Copies of IPR disclosures made to the IETF Secretariat and any
1656 assurances of licenses to be made available, or the result of an
1657 attempt made to obtain a general license or permission for the use of
1658 such proprietary rights by implementers or users of this
1659 specification can be obtained from the IETF on-line IPR repository at
1660 http://www.ietf.org/ipr.
1662 The IETF invites any interested party to bring to its attention any
1663 copyrights, patents or patent applications, or other proprietary
1664 rights that may cover technology that may be required to implement
1665 this standard. Please address the information to the IETF at
1666 ietf-ipr@ietf.org.
1668 Disclaimer of Validity
1670 This document and the information contained herein are provided on an
1671 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1672 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1673 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1674 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1675 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1676 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1678 Copyright Statement
1680 Copyright (C) The Internet Society (2005). This document is subject
1681 to the rights, licenses and restrictions contained in BCP 78, and
1682 except as set forth therein, the authors retain all their rights.
1684 Acknowledgment
1686 Funding for the RFC Editor function is currently provided by the
1687 Internet Society.