idnits 2.17.1
draft-ietf-sipping-profile-datasets-03.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** The document seems to lack a License Notice according IETF Trust
Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009
Section 6.b -- however, there's a paragraph with a matching beginning.
Boilerplate error?
(You're using the IETF Trust Provisions' Section 6.b License Notice from
12 Feb 2009 rather than one of the newer Notices. See
https://trustee.ietf.org/license-info/.)
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (March 8, 2009) is 5528 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)
== Outdated reference: A later version (-10) exists of
draft-ietf-sip-session-policy-framework-05
== Outdated reference: A later version (-18) exists of
draft-ietf-sipping-config-framework-15
** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615,
RFC 7616, RFC 7617)
** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303)
== Outdated reference: A later version (-16) exists of
draft-ietf-sipping-media-policy-dataset-07
-- Obsolete informational reference (is this intentional?): RFC 2141
(Obsoleted by RFC 8141)
Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 SIPPING M. Dolly
3 Internet-Draft AT&T
4 Intended status: Standards Track D. Petrie
5 Expires: September 9, 2009 SIPez LLC
6 D. Worley (Editor)
7 Nortel Networks
8 March 8, 2009
10 A Schema and Guidelines for Defining Session Initiation Protocol User
11 Agent Profile Datasets
12 draft-ietf-sipping-profile-datasets-03.txt
14 Status of this Memo
16 This Internet-Draft is submitted to IETF in full conformance with the
17 provisions of BCP 78 and BCP 79.
19 Internet-Drafts are working documents of the Internet Engineering
20 Task Force (IETF), its areas, and its working groups. Note that
21 other groups may also distribute working documents as Internet-
22 Drafts.
24 Internet-Drafts are draft documents valid for a maximum of six months
25 and may be updated, replaced, or obsoleted by other documents at any
26 time. It is inappropriate to use Internet-Drafts as reference
27 material or to cite them other than as "work in progress."
29 The list of current Internet-Drafts can be accessed at
30 http://www.ietf.org/ietf/1id-abstracts.txt.
32 The list of Internet-Draft Shadow Directories can be accessed at
33 http://www.ietf.org/shadow.html.
35 This Internet-Draft will expire on September 9, 2009.
37 Copyright Notice
39 Copyright (c) 2009 IETF Trust and the persons identified as the
40 document authors. All rights reserved.
42 This document is subject to BCP 78 and the IETF Trust's Legal
43 Provisions Relating to IETF Documents in effect on the date of
44 publication of this document (http://trustee.ietf.org/license-info).
45 Please review these documents carefully, as they describe your rights
46 and restrictions with respect to this document.
48 Abstract
50 This document defines the requirements and a format for SIP user
51 agent profile data. An overall schema is specified for the
52 definition of profile datasets. The schema also provides for
53 expressing constraints for how multiple sources of profile data are
54 to be combined. This document provides a guide to considerations,
55 policies and syntax for defining datasets to be included in profile
56 data.
58 Table of Contents
60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
62 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
63 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 6
64 4.1. Requirement Descriptions . . . . . . . . . . . . . . . . . 6
65 4.1.1. Implementer Extensibility . . . . . . . . . . . . . . 6
66 4.1.2. Flexible Capabilities . . . . . . . . . . . . . . . . 7
67 4.1.3. Access Control . . . . . . . . . . . . . . . . . . . . 7
68 4.1.4. Data Constraints and Range Definition . . . . . . . . 7
69 4.1.5. Support of User, Device, Local Network Sources . . . . 7
70 4.1.6. The Ability to Specify Policy . . . . . . . . . . . . 8
71 4.1.7. XML . . . . . . . . . . . . . . . . . . . . . . . . . 8
72 5. Overall Dataset Schema . . . . . . . . . . . . . . . . . . . . 8
73 5.1. Data Primitives . . . . . . . . . . . . . . . . . . . . . 9
74 5.2. Use of Namespaces . . . . . . . . . . . . . . . . . . . . 9
75 5.3. The 'propertySet' Element . . . . . . . . . . . . . . . . 10
76 5.4. The Abstract 'setting_container' Element . . . . . . . . . 10
77 5.5. The Abstract 'setting' Element . . . . . . . . . . . . . . 10
78 5.5.1. The 'visibility' Attribute . . . . . . . . . . . . . . 11
79 5.5.2. The 'policy' Attributes . . . . . . . . . . . . . . . 11
80 5.5.3. The 'excludedPolicy' Attributes . . . . . . . . . . . 11
81 5.5.4. The 'direction' Attribute . . . . . . . . . . . . . . 12
82 5.5.5. The 'q' Attribute . . . . . . . . . . . . . . . . . . 12
83 5.6. The 'profileUri' Element . . . . . . . . . . . . . . . . . 13
84 5.7. The 'profileCredential' Element . . . . . . . . . . . . . 13
85 5.7.1. realm Element . . . . . . . . . . . . . . . . . . . . 13
86 5.7.2. authUser Element . . . . . . . . . . . . . . . . . . . 14
87 5.7.3. a1Digest Element . . . . . . . . . . . . . . . . . . . 14
88 5.7.4. password Element . . . . . . . . . . . . . . . . . . . 14
89 5.8. The 'profileContactUri' Element . . . . . . . . . . . . . 14
90 5.9. The 'profileInfo' Element . . . . . . . . . . . . . . . . 15
91 5.10. Example Profile Dataset . . . . . . . . . . . . . . . . . 15
92 5.11. Merging Property Sets . . . . . . . . . . . . . . . . . . 16
93 5.11.1. Single Numeric Value Merging Algorithm . . . . . . . . 17
94 5.11.2. Multiple Enumerated Value Merging Algorithm . . . . . 17
95 5.11.3. Closest Value First Merging Algorithm . . . . . . . . 18
96 5.12. Common Types . . . . . . . . . . . . . . . . . . . . . . . 19
97 6. Defining Data Sets . . . . . . . . . . . . . . . . . . . . . . 19
98 6.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 19
99 6.2. Property Definitions . . . . . . . . . . . . . . . . . . . 19
100 6.3. Merging Data Sets . . . . . . . . . . . . . . . . . . . . 20
101 7. Candidate Data Sets . . . . . . . . . . . . . . . . . . . . . 20
102 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
103 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
104 9.1. Content-type registration for
105 'application/uaprofile+xml' . . . . . . . . . . . . . . . 21
106 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22
107 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
108 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
109 12.1. Normative References . . . . . . . . . . . . . . . . . . . 23
110 12.2. Informative References . . . . . . . . . . . . . . . . . . 24
111 Appendix A. Relax NG SIP UA Profile Schema . . . . . . . . . . . 25
112 Appendix B. Use Cases . . . . . . . . . . . . . . . . . . . . . . 30
113 B.1. Outbound Proxy Setting . . . . . . . . . . . . . . . . . . 30
114 B.2. Codec Settings . . . . . . . . . . . . . . . . . . . . . . 31
115 B.2.1. Codec Setting Not Set . . . . . . . . . . . . . . . . 31
116 B.2.2. Codec Set in Device Profile . . . . . . . . . . . . . 31
117 B.2.3. Set in Device and User Profiles . . . . . . . . . . . 31
118 B.2.4. Set in Device and Local Profiles . . . . . . . . . . . 32
119 B.2.5. Set in Device, User and Local Profiles . . . . . . . . 32
120 B.2.6. Example Derived Requirements . . . . . . . . . . . . . 33
121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
123 1. Introduction
125 The SIP User Agent Profile Delivery Framework
126 [I-D.ietf-sipping-config-framework] and the Framework for SIP Session
127 Policies [I-D.ietf-sip-session-policy-framework] specify how SIP user
128 agents locate and retrieve profile data specific to the user, the
129 device, and the local network. It is important for SIP User Agents
130 to be able to obtain and use these multiple sources of profile data
131 in order to support a wide range of applications without undue
132 complexity.
134 While these frameworks define the mechanisms for transmitting profile
135 data, they do not define a format for the actual profile data. This
136 document defines the requirements, the default/mandatory to support
137 content type for [I-D.ietf-sipping-config-framework] , a high level
138 schema for, and guide to how these datasets can be defined. The goal
139 is to enable any SIP user agent to obtain profile data and be
140 functional in a new environment independent of the implementation or
141 model of user agent. The nature of having profile data from three
142 potential sources requires the definition of policies on how to apply
143 the data in an interoperable way across implementations which may
144 have widely varying capabilities.
146 The ultimate objective of the framework described here, together with
147 the SIP User Agent Profile delivery framework, is to a start up
148 experience requiring minimal user intervention. One should be able
149 to take a new SIP user agent out of the box, plug it in or install
150 the software and have it get its profiles without human intervention
151 other than security measures. This is necessary for cost effective
152 deployment of large numbers of user agents.
154 2. Terminology
156 "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
158 document are to be interpreted as described in RFC 2119." [RFC2119].
160 This document uses the terms "profile" and "device" as defined in
161 [I-D.ietf-sipping-config-framework]:
163 profile - a set of configuration data intended to configure a
164 specific device or devices and obtained from a specific source
165 (e.g., user, device, local network or other). Has a concrete
166 representation as an XML document.
168 profile type - a particular category of Profile data in regard to
169 its source (e.g., user, device, local network or other).
171 In addition, this document defines the following terms:
173 profile schema - a definition of a set of possible profiles that are
174 seen as alternative configuration data for a set of UAs. Has a
175 specific XML namespace and a concrete representation in XML Schema
176 Language and/or in Relax NG schema language.
177 profile meta - schema: the schema of the XML namespace
178 "urn:ietf:params:xml:ns:uaprof", from which are derived the
179 various profile schemas
180 user profile - the profile that applies to a specific user. The
181 user profile is that set of profile data the user wants to
182 associate with a given device (e.g. ringtones used when someone
183 calls them, the user's shortcuts) and relate to the user's
184 identity
185 device profile - data profile that applies to a specific device.
186 This is the data that is bound to the device itself independent of
187 the user that is bound to the device. It relates to specific
188 capabilities of the device and/or preferences of the owner of the
189 device.
190 local network profile - data that applies to the user agent in the
191 context of the local network. This is best illustrated by roaming
192 applications; a new device appears in the local network (or a
193 device appears in a new network, depending on the point of view).
194 The local network profile includes settings and perhaps policies
195 that allow the user agent to function in the local network (e.g.
196 how to traverse NAT or firewall, bandwidth constraints).
197 merging - the operation of resolving overlapping settings from
198 multiple profiles. Overlap occurs when the same property occurs
199 in multiple profiles (e.g. device, user, local network).
200 working profile - the set of property values utilized in a SIP User
201 Agent; logically constructed by merging the profiles from the
202 relevant sources
203 property - a named configurable characteristic of a user agent; a
204 named datum within a profile schema. A given property has a well-
205 defined range of possible values. A given property may be defined
206 to have a range of values, allow for simultaneous use of many
207 values (as in a list of allowed possibilities), or a set of
208 related values that collectively form a single profile information
209 item.
210 dataset - a collection of properties.
211 setting - the binding of a specific value or set of values to a
212 given property.
214 Thus, a profile schema defines a dataset, and a profile is a set of
215 settings that conforms to a particular profile schema.
217 3. Overview
219 In this document requirements are specified for containing and
220 expressing profile data for use on SIP user agents. Though much of
221 this can be considered independent of SIP there is one primary
222 requirement that is not well satisfied through more generic profile
223 data mechanisms. SIP User Agent set up requires the agent to merge
224 settings, which may overlap, from potentially three different sources
225 (see [I-D.ietf-sipping-config-framework] ); each source must not only
226 be able to provide profile information, but also express policies
227 regarding how the profile settings may be combined with that from
228 other sources.
230 A schema and syntax is defined in this document to specify properties
231 that may be aggregated to construct profiles. The general design
232 philosophy is that many small datasets provide flexibility to the
233 implementer to support the aggregated set that best matches the
234 capability of the user agent. The actual properties are not defined
235 in this document and will be the subject of derived drafts. However,
236 some examples are provided in Appendix B to illustrate the proposed
237 mechanisms and to validate the requirements.
239 This document defines a set of considerations, syntax and policies
240 that must be specified when defining datasets. These are to help
241 authors of dataset specifications to define datasets that will work
242 in the overall schema defined in this document. The actual
243 specification of these datasets is outside the scope of this
244 document.
246 4. Design Considerations
248 The following section defines some of the design considerations that
249 were taken into account when defining the schema, syntax and policies
250 for generating and applying profile data.
252 4.1. Requirement Descriptions
254 4.1.1. Implementer Extensibility
256 It does not serve user agent administrators to have to require a
257 coordinated and orchestrated upgrade of every user agent and
258 corresponding profile delivery servers for a new capability to be
259 supported. Datasets MUST be extensible without breaking the user
260 agents that support that dataset. This may require the user agents
261 to ignore parts of the extended dataset that it does not support. It
262 may also be possible to tag the extensions with minimum version
263 numbers to facilitate the user agents decision making.
265 4.1.2. Flexible Capabilities
267 Since user agents vary greatly in their capabilities, it MUST be
268 possible for the implementer to tailor the datasets to the
269 capabilities of the user agent device. This implies that the profile
270 is built up of a series of small datasets based upon the capabilities
271 of the user agent. The user agents MAY ignore datasets for
272 capabilities they do not support. This allows the profile delivery
273 server to be agnostic of device capabilities. It is however the
274 implementer's choice to customize the delivered profile to the device
275 capabilities.
277 4.1.3. Access Control
279 There are likely to be properties in various profile datasets that
280 the Operators and Administrators do not want the users to sometimes
281 not be able to modify or even see. It MUST be possible to disallow
282 the user from modifying a property. It MUST be possible to obfuscate
283 the user from seeing a property or its setting. This access control
284 information SHOULD be optional for a given property.This is supported
285 by the admin value of the visibility attribute.
287 4.1.4. Data Constraints and Range Definition
289 Property values are likely to have an allowed set of values under
290 most circumstances rather than completely unconstrained in their
291 values. It MUST be possible for the schema to specify constraints on
292 a property value, viz, as a range or as a set of discrete values.
293 These constraints SHOULD be optional to the dataset and SHOULD be
294 expressible independent of the property itself.
296 4.1.5. Support of User, Device, Local Network Sources
298 [I-D.ietf-sipping-config-framework] specifies a mechanism where the
299 user agent retrieves profile data from as many as three different
300 sources. The separation of the user profile facilitates a hotelling
301 capability and the ability to easily re-assign a user to a different
302 device. The separation of the local network profile facilitates
303 properties specific to operating in the local network in a roaming
304 scenario (e.g. outbound proxy or NAT traversal properties). The
305 device profile facilitates device capability based properties as well
306 as a means for the device owner or manager to impose policy.
308 While increasing the complexity of the user agent in that it must
309 aggregate and consolidate separate profiles into one working profile,
310 constraining the properties of the various profiles to be mutually
311 exclusive, or constraining even the merging rules would severely
312 restrict functionality.
314 Profile merging rules are associated with individual datasets or even
315 associated with individual properties inside a dataset. A profile
316 MUST have a merging algorithm defined. An individual property inside
317 MAY contain a merging rule, in which case this merging rule is
318 specific to the property. If however, there is no merging rule
319 associated with a property, but the profile dataset in its entirety
320 has a merging rule, this merging rule MUST be applied to each of the
321 properties that form part of the profile.
323 A few of the more commonly used merging algorithms are defined in
324 this document. Most settings are likely to use the common set
325 defined in this document. However authors of profile datasets may
326 define new algorithms for merging dataset properties (see
327 Section 5.11 and Section 6.3 ).
329 4.1.6. The Ability to Specify Policy
331 Local Network Operators may wish to impose policy on users and
332 devices on their network such as constraining codecs, media streams,
333 outbound proxy or emergency services. It MUST be possible to impose
334 policy in any of the profile sources that constrains, overwrites or
335 modifies properties provided in datasets from other sources.
337 4.1.7. XML
339 XML is perhaps not really a requirement, but a solution base upon
340 requirements. However it is hard to ignore the desire to utilize
341 readily available tools to manage and manipulate profile data such as
342 XSLT, XPATH and XCAP. The requirement that should be considered when
343 defining the schema and syntax is that many user agents have limited
344 resources for supporting advanced XML operation. The simplest XML
345 construct possible should be used, that support the required
346 functionality. It is not a requirement that user agents validate the
347 profile XML document. This relieves the requirement that the Relax
348 NG schema defined in this and other datasets documents be enforced on
349 the user agent. The Relax NG schema should not be used to strictly
350 validate profile XML documents. Unknown elements and attributes
351 should be ignored to allow extensions to be supported. Strict
352 enforcement of the Relax NG schema would make it very difficult to
353 deploy new user agents without lock step upgrades of the profile
354 delivery server. Guidelines for the Use of Extensible Markup
355 Language (XML) within IETF Protocols [RFC3470] provides useful
356 information in this regard.
358 5. Overall Dataset Schema
360 Notifiers and Subscribers of the event package defined in
362 [I-D.ietf-sipping-config-framework] SHOULD support the content-type:
363 application/uaprofile+xml. The Notifier SHOULD indicate all of the
364 dataset schemas that is supports by listing all of the MIME types for
365 the supported datasets in the SUBSCRIBE request header: Accept. This
366 document defines an Relax NG Schema for that content-type with the
367 namespace: urn:ietf:params:xml:ns:uaprof, for SIP Profile Datasets
368 that provides:
369 o a base element type "setting" from which all settings in other
370 schema definitions inherit (this allows other definitions to
371 specify the content models for ways of combining settings; it is
372 analogous to a C++ virtual base class).
373 o Attributes to the "setting" element that define constraints and
374 other properties used to impose policy that apply to the element
375 value. These attributes are inherited by elements that are
376 derived from the abstract settings element.
377 o A root element for all property sets (the outermost container).
379 The full text of the schema is in Appendix A ; the following
380 describes the usage of the schema in defining properties and
381 combining them to construct the working profile of a User Agent.
383 5.1. Data Primitives
385 Each property in a profile data set is defined using XML Schema
386 Datatypes [W3C.REC-xmlschema-2] and Relax NG Schema. A property is
387 modeled by an XML element derived from the "setting" element in the
388 SIP Profile Data Set Schema. The element content is the setting
389 value.
391 Properties consisting of one single value can be expressed using a
392 single XML element. Properties that may consist of multiple values
393 require the use of container elements. A container element is
394 defined for such a property. This container can contain multiple XML
395 elements, which each defines a possible value for that property (see
396 examples in Section 5.5.2 ).
398 When constructing a property set, the creator of a profile may not be
399 able to know all of the capabilities of the User Agent that will
400 receive that property set. The creator of profile constraints or
401 policies should be aware that a user agent may ignore properties that
402 are unsupported or do not apply to its capabilities.
404 5.2. Use of Namespaces
406 XML namespaces [W3C.REC-xml-names-19990114] provide a means to
407 uniquely identify the elements and datatypes defined in a data set.
408 It is therefore RECOMMENDED that each data set specifies its own
409 namespace. The namespace URIs SHOULD be URNs [RFC2141] , using the
410 namespace identifier 'ietf' defined by [RFC2648] and extended by
411 [RFC3688] . The core schema defined in this document defines the
412 namespace: "urn:ietf:params:xml:ns:uaprof". Profile datasets that
413 extend this schema SHOULD define a new namespace by appending a ":"
414 and a unique name to the "urn:ietf:params:xml:ns:uaprof" namespace.
415 These namespaces MUST be registered with IANA.
417 5.3. The 'propertySet' Element
419 The root element of a property set is "propertySet"; it is the
420 container that is provided to the user agent. The elements contained
421 within a propertySet contain the specific properties which are to be
422 applied to the user agent. The properties may be simple types with a
423 single value, complex types or container elements with a list of
424 properties.
426 5.4. The Abstract 'setting_container' Element
428 The "setting_container" element is the abstract element in which a
429 list of properties which allow multiple values may be contained.
430 Elements derived from the "setting_container" element may contain
431 zero or more elements derived from the "setting" element. The
432 "setting_container" element has an "excludedPolicy" attribute.
434 5.5. The Abstract 'setting' Element
436 The setting element is the abstract element from which all profile
437 properties or settings shall inherit.
439 The setting element has a number of attributes that provide
440 functionalities, which are generally useful for many properties.
441 These attributes are inherited by properties that are derived from
442 the settings element. This enables the re-use of common
443 functionalities and ensures a common syntax for these elements across
444 different data sets. The following functionalities are provided by
445 attributes of the settings element:
447 o Property Access Control: 'visibility' attribute
448 o Policies: 'policy' attribute
450 Additional attributes are defined in the schema that may used in
451 elements derived from "setting". By default these attributes cannot
452 be set. These attribute must be explicitly added to elements derived
453 from the "setting" element:
455 o Unidirectional Properties: 'direction' attribute
456 o Preferences: 'q' attribute
458 5.5.1. The 'visibility' Attribute
460 The attribute "visibility" is defined on the "setting" element to
461 specify whether or not the user agent is permitted to display the
462 property value to the user. This is used to hide setting values that
463 the profile administrator may not want the user to see or know. The
464 "visibility" attribute has two possible values:
466 o user: Specifies that display of the property value is not
467 restricted to the user. This is the default value of the
468 attribute if it is not specified.
469 o admin: Specifies that the user agent SHOULD NOT display the
470 property value. Display of the property value may be allowed
471 using special administrative interfaces, but is not appropriate to
472 the ordinary user.
474 5.5.2. The 'policy' Attributes
476 The setting element has an optional 'policy' attribute. The policy
477 attribute is used to define the constraining properties of an
478 element. It defines how the element value is used by an endpoint
479 (e.g. whether it can or can not be used in a session). The following
480 values are defined for the 'policy' attribute:
482 o allow: the value contained in the element is allowed and SHOULD be
483 used in sessions. This is the default value that is used if the
484 'policy' attribute is omitted.
485 o disallow: the value contained in the element is forbidden and
486 SHOULD NOT be used in sessions.
488 The policy attribute can be omitted if the default policy 'allow'
489 applies.
491 The policy attribute is used only inside containers.
493 5.5.3. The 'excludedPolicy' Attributes
495 The "setting_container" element has an optional 'excludedPolicy'
496 attribute. This attribute specifies the default policy for all
497 values that are not in the container. Elements that are present in
498 the container have their own 'policy' attribute, which defines the
499 policy for that element. The following values are defined for the
500 'excludedPolicy' attribute:
502 o allow: values not listed in the container are allowed and MAY be
503 used in sessions. This is the default value that is used if the
504 'excludedPolicy' attribute is omitted.
505 o disallow: values not listed in the container are forbidden and
506 MUST NOT be used in sessions.
508 The excludedPolicy attribute can be omitted if the default policy
509 'allow' applies. The following example shows a policy that allows
510 the media type audio and disallows all other media types in sessions
511 (effectively, this construct requires the use of audio):
513
514 audio
515
517 5.5.4. The 'direction' Attribute
519 Some properties are unidirectional and only apply to messages or data
520 streams transmitted into one direction. For example, a property for
521 media streams can be restricted to outgoing media streams only.
522 Unidirectional properties can be expressed by adding a 'direction'
523 attribute to the respective element.
525 The 'direction' attribute can have the following values:
527 o recvonly: the property only applies to incoming messages/streams.
528 o sendonly: the property only applies to outgoing messages/streams.
529 o sendrecv: the property applies to messages/streams in both
530 directions. This is the default value that is used if the
531 'direction' attribute is omitted.
533 5.5.5. The 'q' Attribute
535 It should be possible to express a preference for a certain value, if
536 multiple values are allowed within a property. For example, it
537 should be possible to express that the codecs G.711 and G.729 are
538 allowed, but G.711 is preferred. Preferences can be expressed by
539 adding a 'q' attribute to a property element. Elements derived from
540 the "setting" element for which multiple occurrences and values are
541 allowed SHOULD have a "q" attribute if the order is significant.
542 Typically these elements are contained in an element derived from the
543 "setting_container" element. The 'q' attribute is only meaningful if
544 the 'policy' attribute set to 'allowed'. It must be ignored in all
545 other cases.
547 An element with a higher 'q' value is preferred over one with a lower
548 'q' value. 'q' attribute values range from 0 to 1. The default value
549 is 0.5.
551 5.6. The 'profileUri' Element
553 The element contains the URI of this profile on the
554 profile server. The value contained in the profileUri element may be
555 different than the URI subscribe to when retrieving this profile.
556 When the user agent retrieves a profile where the profileUri is
557 different than the subscribe to URI, the user agent SHOULD
558 unsubscribe to the current URI and then subscribe to the new URI.
560 The element is optional and MAY occur only once inside a
561 element. The profileUri element is specific to the
562 local-network, device or user profile in which it occurs. It has no
563 meaning outside of the profile in which it occurs and SHOULD NOT be
564 merged.
566 5.7. The 'profileCredential' Element
568 The element contains the digest authentication
569 information that SHOULD be used for authentication for the profile
570 subscription via SIP or profile retrieval via HTTP, HTTPS, etc. The
571 profileCredential element is optional and MAY occur only once inside
572 a propertySet element. The profileCredential element is specific to
573 the local-network, device or user profile in which it occurs. It has
574 no meaning outside of the profile in which it occurs and SHOULD NOT
575 be merged. The profileCredential element MUST contain exactly one of
576 each of the elements: realm, authUser and one of either a1Digest or
577 password.
579 5.7.1. realm Element
581 The realm element contains the string that defines the realm to which
582 this credential pertains. The value of the realm element is the same
583 as the realm parameter in the [RFC2617] headers: WWW-Authenticate,
584 Authorization and the SIP [RFC3261] headers: Proxy-Authenticate and
585 Proxy-Authorization. If a match of the realm value is found, the
586 user agent uses the values in the authUser and a1Digest elements
587 contained in the profileCredential element. Exactly one realm
588 element MUST be contained in a profileCredential element. A wildcard
589 of "*" MAY be used as the realm value in which case the user agent
590 MUST calculate the A1 DIGEST for the realm given in the
591 authentication challenge. If the wildcard is given for the realm,
592 the clear text form of the password contained in the password element
593 MUST also be used.
595 5.7.2. authUser Element
597 The authUser element contains the string value of the "username"
598 parameter which SHOULD be used in Authorization and Proxy-
599 Authorization request headers when retrying a request that was
600 challenged for authentication. Exactly one authUser element SHOULD
601 be contained in a profileCredential element.
603 5.7.3. a1Digest Element
605 The a1Digest element contains a string with the value of the A1
606 digest of the username, realm and password as defined in [RFC2617] .
607 At most one a1Digest element MUST be contained in a profileCredential
608 element. The a1Digest element MUST NOT exist in a profileCredential
609 element containing a password element. The username and realm used
610 to construct the value of the a1Digest element MUST match the values
611 of the realm and authUser elements contained in the profileCredential
612 element with the a1Digest element.
614 5.7.4. password Element
616 The password element contains the clear text password for use with
617 DIGEST Authentication [RFC2617] . At most one password MUST be
618 contained in a profileCredential element. The password element MUST
619 NOT exist in a profileCredential element containing a a1Digest
620 element. The user agent uses this password along with the realm and
621 authUser elements to calculate the A1 digest used for DIGEST
622 Authentication.
624 5.8. The 'profileContactUri' Element
626 The element contains a contact URI (e.g. a SIP,
627 HTTP URI or email address) under which the issuer of this profile can
628 be reached. The contact element may, for example, contain the
629 address of a support hotline.
631 The element is optional and MAY occur multiple
632 times inside a element. Multiple instances of the
633 profileContactUri element allow multiple URI schemes to be provided
634 for contact information. The user agent MAY use the URI contained
635 profile-contact-info element which has a URI scheme that the user
636 agent supports and can make work to provide support help for the
637 profile. The user agent MAY provide the URIs to the user to contact
638 the creator of the profile through other communication channels. The
639 profileContactUri element is specific to the local-network, device or
640 user profile in which it occurs. It has no meaning outside of the
641 profile in which it occurs and SHOULD NOT be merged.
643 5.9. The 'profileInfo' Element
645 The element provides a short textual description of the
646 property that should be intelligible to the human user. This element
647 may, for example, contain information about the nature of this
648 profile, such as "Access Network Profile". The text in the
649 element is in particular be helpful when a user needs
650 to decide whether or not to use a newly downloaded profile or when
651 problems with a profile (e.g. a policy conflict) occur. A user agent
652 MAY display this information in these cases.
654 The element is optional and MAY occur only once inside
655 a element. The profileInfo element is specific to the
656 local-network, device or user profile in which it occurs. It has not
657 meaning outside of the profile in which it occurs and SHOULD NOT be
658 merged.
660 5.10. Example Profile Dataset
662 The following XML example shows a SIP Profile Dataset with example
663 extension setting elements: ddd, foo, bar, boo, containerElement and
664 setting container elements: myContainer, myContainer1, myContainer2
665 and container3.
667
668
669 sip:a1b2c3d4e5f6@example.com
670
671 example.com
672 fred
673 b6b577fd12aa7e1df8d60735ef56fc2e
674
675
676 tel:+16175551212
677 sip:411@example.com
678
679 http:example.com/sipProfile.html
680
681
682 This is an example profile from example.com
683
684 fff
685
687
688
690
691
692 aaa
693 bbb
694 ccc
695
696 ggg
697
698
699
700
701
702 111
703 222
704 333
705
706
708 5.11. Merging Property Sets
710 A UA may receive property sets from multiple sources, which need to
711 be merged into a single combined document the UA can work with.
713 Properties that have a single value (e.g. the maximum bandwidth
714 allowed) require that a common value is determined for this property
715 during the merging process. The merging rules for determining this
716 value need to be defined individually for each element in the schema
717 definition. Properties that allow multiple values (i.e. property
718 containers) need to be merged by combining the values from the
719 different data sets. The following sections describe recommended
720 common merging algorithms. A data set definition may refer to these
721 algorithms.
723 5.11.1. Single Numeric Value Merging Algorithm
725 A general merging rule for elements with numeric values is to select
726 the largest or the smallest value. For example, a merging rule for a
727 element would be to select the smallest value from
728 the values that are in the competing data sets.
730 5.11.2. Multiple Enumerated Value Merging Algorithm
732 Multiple values in property containers are merged by combining the
733 values from each of the competing data sets. This is accomplished by
734 copying the elements from each property container into the merged
735 container. Elements with identical values are only copied once. The
736 'policy' attribute of two elements with the same value is adjusted
737 during the merging process according to Table 1. If an element
738 exists only in one property container, then the default policy of the
739 other container (i.e. the excludedPolicy) is used when accessing
740 Table 1. For example, if an element is disallowed in one data set
741 and the element is not contained in the other data set but the
742 default policy is allowed for that data set, then the values
743 disallowed and allowed are used to access Table 1. Consequently, the
744 element will be disallowed in the merged data set. Finally, the
745 excludedPolicy attributes of the containers are also merged using
746 Table 1. In addition to these merging rules, each schema may define
747 specific merging rules for each property container.
749 set 1 \ set 2 | allow | disallow
750 --------------+----------+----------
751 allow | allow | disallow
752 disallow | disallow | disallow
754 Table 1: merging policies.
756 The following example illustrates the merging process for two data
757 sets. All elements are merged into one container and the policy
758 attributes are adjusted according to Table 1. The merged container
759 has the default policy disallow, which is determined using Table 1.
760 The entry for PCMA in the merged data set is redundant since it has
761 the default policy.
763 Data set 1:
764
765 PCMA
766
768 Data set 2:
769
770 PCMA
771 G729
772
774 Merged data set:
775
776 PCMA
777 G729
778
780 Some constellations of policy attributes result in an illegal merged
781 data set. They constitute a conflict that can not be resolved
782 automatically. For example, two data sets may define two non-
783 overlapping sets of allowed audio codecs and both disallow all other
784 codes. The resulting merged set of codecs would be empty, which is
785 illegal according to the schema definition of the codecs element. If
786 the use of these properties is enforced by both networks, the UA may
787 experience difficulties or may not be able to set up a session at
788 all.
790 The combined property set MUST again be valid and well-formed
791 according to the schema definitions. A conflict occurs if the
792 combined property set is not a well-formed document after the merging
793 process is completed.
795 5.11.3. Closest Value First Merging Algorithm
797 Some properties require that the values from different data sets are
798 ordered based on the origin of the data set during the merging
799 process. Property values that come from a domain close to the user
800 agent take precedence over values that were in a data set delivered
801 by a remote domain. This order can be used, for example, to select
802 the property value from the closest domain. In many cases, this is
803 the local domain of the user agent. For example, the URI of an
804 outbound proxy could be merged this way. This order can also be used
805 to generate an ordered list of property values during the merging
806 process. For example, multiple values for media intermediaries can
807 be ordered so that the closest media intermediary is traversed before
808 the second closest intermediary and so on.
810 This merging algorithm requires that the source of a data set is
811 considered.
813 If property sets are delivered through the configuration framework
814 [I-D.ietf-sipping-config-framework] , the value received through a
815 subscription using the "local-network" profile-type takes precedence
816 over values received through other profile-type subscriptions,
817 followed by device and then user profile-types.
819 The session-specific policy mechanism
820 [I-D.ietf-sip-session-policy-framework] provides an order among
821 policy servers. This order is based on the order, in which a SIP
822 message traverses the network, starting with the closest domain.
823 This order can directly be used to order property values as described
824 above.
826 5.12. Common Types
828 The schema also defines a set of common types that are used in
829 defining data sets (e.g. DataIpPort). [Need to document common
830 types.]
832 6. Defining Data Sets
834 This section covers several issues that should be take into
835 consideration when specifying new data set schemas. This is intended
836 to be a guide to authors writing specifications defining a new data
837 set schema or extensions to existing ones.
839 6.1. Namespace
841 It is RECOMMENDED that a data set defines a new XML namespace
842 [W3C.REC-xml-names-19990114] to scope all of the properties that are
843 defined in the name space.
845 6.2. Property Definitions
847 The properties defined in a data set schema may be simple (i.e.
848 having a single value) or they may be complex (i.e. a container with
849 multiple values). Each property in the data set SHOULD inherit from
850 the "setting" element. Complex properties and all of their child
851 elements each should inherit from "setting" as well.
853 A data set specification should contain a section which defines the
854 meaning of all of the properties contained in the data set. The
855 objective is to define the property such that implementers have a
856 clear definition and semantics to interpret properties in a
857 consistent way. User agents not only need to use the same profile
858 content, they need to apply the properties in a consistent way to
859 achieve true interoperability.
861 The following information should be defined for each property in a
862 data set:
863 o description: describe the meaning and application of the property.
864 o cardinality: define how many instances of this property element
865 may occur in a data set (e.g. zero, one or many) as well as its
866 relationship to any other properties in this or other data sets.
867 o default value: define the default value of this property if it is
868 not set. Describe if the default is different if the property is
869 present and not set vs. completely absent from the data set.
870 Define if the default varies in relation to another property.
872 6.3. Merging Data Sets
874 User agents may receive data sets from multiple sources. They need
875 to merge these data sets in order to create an overall data set they
876 can work with. Collisions on data sets may occur if multiple sources
877 provide different values for the same properties. These collisions
878 need to be resolved during the merging process.
880 A data set schema MUST define rules for merging data sets from
881 different sources for each property that is defined. Recommendations
882 for merging data sets are discussed in Section 5.11 . A data set
883 schema must define if and how these recommendations apply and MAY
884 define alternative merging rules for specific settings. A data set
885 schema must also identify combinations of properties that constitute
886 a conflict that can't resolved. It may provide additional guidelines
887 for the behavior of a user agent in these cases.
889 7. Candidate Data Sets
891 The following sections name some of the candidate data sets that are
892 or may be defined. These data sets can be aggregated to form
893 profiles appropriate to the capabilities of a user agent
894 implementation.
896 o SIP Protocol Data Set: the lowest common denominator set of
897 properties common to all SIP user agents of any capability. A
898 schema covering the elements of this data set can be found in
899 [I-D.petrie-sipping-sip-dataset] .
900 o Media Data Set: this data set contains media related policies. A
901 schema covering the elements of this data set can be found in
902 [I-D.ietf-sipping-media-policy-dataset] .
903 o Identity Data Set: AORs and lines (see
904 [I-D.petrie-sipping-identity-dataset] )
905 o HTTP Protocol Data Set: server settings. Proxy for clients.
906 o NAT Traversal Data Set: settings for STUN, TURN etc.
907 o SIP Digit Maps Data Set:
908 [I-D.petrie-sipping-voip-features-dataset]
909 o VoIP Features: [I-D.petrie-sipping-voip-features-dataset]
911 8. Security Considerations
913 Security is mostly a delivery problem. The delivery framework SHOULD
914 provide a secure means of delivering the profile data as it may
915 contain sensitive data that would be undesirable if it were stolen or
916 sniffed. Storage of the profile on the profile delivery server and
917 user agent is an implementation problem. The profile delivery server
918 and the user agent SHOULD provide protection that prevents
919 unauthorized access of the profile data. The profile delivery server
920 and the user agent SHOULD enforce the access control policies defined
921 in the profile data sets if present.
922 The point of the access control construct on the data set is to
923 provide some security policy on the visibility and ability to
924 change sensitive properties.
926 Some transport mechanisms for delivery of the profile data do not
927 provide a secure means of delivery. In addition some user agents may
928 not have the resources to support the secure mechanism used for
929 delivery (e.g. TLS).
931 9. IANA Considerations
933 XML name space registration: urn:ietf:params:xml:ns:uaprof
935 9.1. Content-type registration for 'application/uaprofile+xml'
937 To: ietf-types@iana.org
938 Subject: Registration of MIME media type application/uaprofile+xml
939 MIME media type name: application
940 MIME subtype name: uaprofile+xml
941 Required parameters: (none)
942 Optional parameters: charset Indicates the character encoding of
943 enclosed XML. Default is UTF-8.
944 Encoding considerations: Uses XML, which can employ 8-bit
945 characters, depending on the character encoding used. See RFC
946 3023 [RFC3023], section 3.2.
947 Security considerations: This content type is designed to carry SIP
948 user agent profile data, which may be considered private
949 information. Appropriate precautions should be adopted to limit
950 disclosure of this information.
951 Interoperability considerations: This content type provides a common
952 format for exchange of SIP user agent profile information.
953 Published specification: RFC XXXX (Note to RFC Editor: Please fill
954 in XXXX with the RFC number of this specification)
955 Applications which use this media type: SIP user agents and profile
956 delivery servers.
957 Additional information: Magic number(s): File extension(s):
958 Macintosh File Type Code(s):
959 Person & email address to contact for further information: Sam
960 Ganesan EMail: sam.ganesan@motorola.com com
961 Intended usage: LIMITED USE
962 Author/Change controller: This specification is a proposed work item
963 of the IETF SIPPING working group, with mailing list address:
964 sipping@ietf.org
965 Other information: This media type is a specialization of
966 application/xml [RFC3023], and many of the considerations
967 described there also apply to application/uaprof+xml.
969 10. Contributors
971 Sumanth Channabasappa
972 CableLabs
973 858 Coal Creek Circle
974 Louisville, CO 80027
975 US
977 Email: sumanth@cablelabs.com
979 Sam Ganesan
980 Motorola
981 80 Central Street
982 Boxborough, MA 01719
983 US
984 Email: sam.ganesan@motorola.com
986 Volker Hilt
987 Bell Labs/Alcatel-Lucent
988 791 Holmdel-Keyport Rd
989 Holmdel, NJ 07733
990 US
992 Email: volkerh@bell-labs.com
994 11. Acknowledgments
996 The WG version of the document is based on an individual draft
997 authored by Dan Petrie, Scott Lawrence, Martin Dolly and Volker Hilt.
998 It has been reviewed by many members of the SIPPING WG. In
999 particular, we thank Henning Schulzrinne, Henry Sinnreich, Christian
1000 Stredicke for feedback on early versions of the document. We also
1001 thank Mary Barnes for her reviews and assistance with the current
1002 version of the document.
1004 12. References
1006 12.1. Normative References
1008 [I-D.ietf-sip-session-policy-framework]
1009 Hilt, V., Camarillo, G., and J. Rosenberg, "A Framework
1010 for Session Initiation Protocol (SIP) Session Policies",
1011 draft-ietf-sip-session-policy-framework-05 (work in
1012 progress), November 2008.
1014 [I-D.ietf-sipping-config-framework]
1015 Channabasappa, S., "A Framework for Session Initiation
1016 Protocol User Agent Profile Delivery",
1017 draft-ietf-sipping-config-framework-15 (work in progress),
1018 February 2008.
1020 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1021 Requirement Levels", BCP 14, RFC 2119, March 1997.
1023 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
1024 Leach, P., Luotonen, A., and L. Stewart, "HTTP
1025 Authentication: Basic and Digest Access Authentication",
1026 RFC 2617, June 1999.
1028 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
1029 Types", RFC 3023, January 2001.
1031 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
1032 A., Peterson, J., Sparks, R., Handley, M., and E.
1033 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
1034 June 2002.
1036 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1037 January 2004.
1039 [W3C.REC-xml-names-19990114]
1040 Hollander, D., Bray, T., and A. Layman, "Namespaces in
1041 XML", W3C REC REC-xml-names-19990114, January 1999.
1043 [W3C.REC-xmlschema-1]
1044 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
1045 "XML Schema Part 1: Structures", W3C REC-xmlschema-1,
1046 May 2001, .
1048 [W3C.REC-xmlschema-2]
1049 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes",
1050 W3C REC-xmlschema-2, May 2001,
1051 .
1053 12.2. Informative References
1055 [I-D.ietf-sipping-media-policy-dataset]
1056 Hilt, V., Camarillo, G., and J. Rosenberg, "A User Agent
1057 Profile Data Set for Media Policy",
1058 draft-ietf-sipping-media-policy-dataset-07 (work in
1059 progress), March 2009.
1061 [I-D.petrie-sipping-identity-dataset]
1062 Petrie, D., Channabasappa, S., and S. Ganesan, "The
1063 Session Initiation Protocol User Agent Identity Profile
1064 Data Set", draft-petrie-sipping-identity-dataset-02 (work
1065 in progress), November 2007.
1067 [I-D.petrie-sipping-sip-dataset]
1068 Channabasappa, S. and S. Ganesan, "The Core Session
1069 Initiation Protocol User Agent Protocol Data Set",
1070 draft-petrie-sipping-sip-dataset-03 (work in progress),
1071 November 2007.
1073 [I-D.petrie-sipping-voip-features-dataset]
1074 Petrie, D., Channabasappa, S., and S. Ganesan, "The
1075 Session Initiation Protocol User Agent VoIP Features Data
1076 Set", draft-petrie-sipping-voip-features-dataset-02 (work
1077 in progress), November 2007.
1079 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
1081 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
1082 August 1999.
1084 [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for
1085 the Use of Extensible Markup Language (XML)
1086 within IETF Protocols", BCP 70, RFC 3470, January 2003.
1088 Appendix A. Relax NG SIP UA Profile Schema
1090
1091
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209 [0-9,a-f]{32,32}
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220 sip:.*
1222
1223
1224 sips:.*
1225
1226
1227
1228
1229
1230
1231 "?.*"?<?sip:.*
1232
1233
1234 "?.*"?<?sips:.*
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269 allow
1270 disallow
1271
1272
1273
1274
1275
1276
1277 user
1278 admin
1279
1280
1281
1282
1283
1284
1285
1286 sendrecv
1287 sendonly
1288 recvonly
1289
1290
1291
1292
1293
1294
1295
1296 0
1297 1
1298
1299
1300
1301
1302
1303 1
1304 65535
1305
1306
1307
1308
1309
1310 UDP
1311 TCP
1312 TLS
1313 DTLS
1314 SCTP
1315
1316
1317
1319 Appendix B. Use Cases
1321 In the following use case scenarios the device profile is provided by
1322 the device owner/manager. The owner/manager may be a service
1323 provider, an enterprise or a user administering the device setup.
1324 The user is assumed to be the end user operating the user agent. In
1325 the scenarios that the user profile is provided, the user profile
1326 contains user specific properties that the end user has set directly
1327 or indirectly through an administration process. The local network
1328 profiles represent the suggested policy behavior that the local
1329 network operator would like user agents to adhere to
1330 [I-D.ietf-sip-session-policy-framework] . From a security
1331 perspective, the local network operator cannot trust the user agent
1332 to follow the local network profile policy. The local network
1333 operator must use a means external to the user agent to enforce these
1334 policies. The local network profile is intended to express to the
1335 user agent, the policies that the user agent should follow if the
1336 user agent wants to function properly in the local network.
1338 Two different use cases are developed and discussed below. Similar
1339 use cases can be developed for individual datasets. For example,
1340 analysis of Transport protocol settings for SIP can be carried out in
1341 exactly the same fashion as the codec use case described below and a
1342 set of derived requirements to drive the schema for the associated
1343 datset can be arrived at.
1345 B.1. Outbound Proxy Setting
1347 In the case of the outbound proxy, it is unlikely that the user would
1348 want to influence the outbound proxy for SIP signaling. The device
1349 owner/manager or the local network operator are likely to want to set
1350 the outbound proxy property. The device profile may define an
1351 outbound proxy so that the device owner/manager can monitor all
1352 signaling. The local network operator also defines an outbound proxy
1353 because the proxy allows the SIP signaling to get through a NAT or
1354 firewall.
1356 Two possible solutions to this problem are listed.
1357 o Define a policy where the local network profile overrides the
1358 device profile. In this approach the local network profile wins.
1359 o Aggregate the outbound proxies. In this scenario SIP messages
1360 would be sent with a pre-populated route set that had two hops.
1361 First the outbound proxy set in the local network profile, then
1362 the outbound proxy set in the device profile.
1364 The aggregation approach is closest to solving the requirements to
1365 the use case above. By aggregating the two outbound proxies, the
1366 local network provided outbound proxy allows the signaling to get out
1367 of the local network and the device profile provided outbound proxy
1368 is able to monitor all SIP signaling from the user agent.
1370 B.2. Codec Settings
1372 Use cases for the codec properties are likely one of the more
1373 complicated sets of properties with respect to merging and
1374 constraining across more than one profile. There are reasonable
1375 scenarios where requirements can be rationalized that the device,
1376 user and local network profiles may each wish to express preferences
1377 and constraints on permitted codecs. Without getting into details or
1378 syntax of the codec properties, it is assumed that codec properties
1379 will need to express a codec definition and a preference order. This
1380 is the order that these codecs will be put in SDP for codec
1381 negotiation purposes.
1383 The following scenarios illustrate some possible combinations of
1384 sources of codec properties from the device, user and local network
1385 profiles.
1387 B.2.1. Codec Setting Not Set
1389 In the scenario where a device has no profiles or the profiles
1390 contain no codec properties, the device will enable a default set and
1391 preference order of codecs, which could be a subset of the codecs the
1392 device is capable of supporting. The default set and preference
1393 order of codecs is a implemention specific.
1395 B.2.2. Codec Set in Device Profile
1397 This scenario assumes that the device profile is the only source of
1398 codec properties.
1400 The codecs in the device profile may differ from the set of codecs
1401 supported by the device, due to administrative constraints on codec
1402 usage.
1404 In this scenario the device profile data will dictate the ordered
1405 list of codecs to be applied. The use agent will ignore codec types
1406 included in the profile that the user agent does not support.
1408 B.2.3. Set in Device and User Profiles
1410 This scenario covers the case where both the device profile and the
1411 user profile provide an ordered list of codecs. The user may prefer
1412 a higher quality codec to be used, if available. Thereby the user
1413 profile data may provide an ordered list of codecs to be applied.
1414 The device profile also specifies a list of codecs and a default
1415 preference order.
1417 The merging of the data sources is as follows:
1418 o The ordering of the codecs will be determined from the user
1419 profile data, which overrides the codec preference ordering from
1420 the device profile data.
1421 o The set of codecs that may be applied, are the codecs listed in
1422 the user data constrained by the list of codecs from the device
1423 profile data.
1425 The case in which none of the codecs in the resulting merged profile
1426 datasets are supported by the device, the profile data constitutes a
1427 misconfiguration between device and user profiles. It may not be
1428 possible to successfully establish a session in this case. It is
1429 suggested that the user agent provide feedback to the user indicating
1430 the misconfiguration. The user agent may also attempt to function in
1431 the network by ignoring one or more of the profile constraints.
1433 B.2.4. Set in Device and Local Profiles
1435 In this scenario both the local network profile and the device
1436 profile each provide an ordered set of codecs. Both the local
1437 network operator and the device provider may feel the need to
1438 constrain and order the set of codecs used. This scenario is very
1439 much alike to the previous scenario and may be resolved using a
1440 similar method. However, it likely that the local network codec
1441 preferences will override and constrain the device profile, given the
1442 caveat that in the circumstances where the resulting ordered set of
1443 codecs is an empty set. In this case there is a misconfiguration/
1444 incompatibility between the device profile and the local network
1445 profile with regard to the codecs, which may render the device non
1446 functional. The user agent may attempt to function in the network by
1447 ignoring one or more of the profile constraints.
1449 B.2.5. Set in Device, User and Local Profiles
1451 In this scenario all profiles namely, device, user and local network
1452 profiles, provide an ordered set of codecs as preferences. For
1453 example, these may be the result of device capabilities, user's
1454 preference for higher quality media and the network providers desire
1455 to constrain bandwidth usage and or enforce uniformity of codec
1456 usage. The data sources could be merged as follows:
1457 o The ordering of the codecs will be determined from the user
1458 profile data, which overrides the ordering from the device profile
1459 data.
1460 o The set of codecs that may be used are the codecs listed in the
1461 device profile data, constrained by the list of codecs from the
1462 user profile data and further constrained by the list of codecs
1463 from the local network profile data.
1465 A resulting null set of codecs would imply a misconfiguration and may
1466 prevent the device from functioning under these circumstances. The
1467 user agent may also attempt to function in the network by ignoring
1468 one or more of the profile constraints.
1470 B.2.6. Example Derived Requirements
1472 An example set of derived requirements for the codec definition is
1473 presented here. These requirements in turn would drive the profile
1474 definition for codec usage.
1475 1. The list of codecs in the device profile data that get applied is
1476 the subset of the codecs supported by the device. Codecs listed
1477 in profiles that are not supported by the device are ignored.
1478 2. The device profile data will have a default ordered list of
1479 codecs, which implies a preference order to be used in the sdp
1480 offer.
1481 3. The user profile data may provide an ordered list of user
1482 preferred codecs. The ordering of the codecs in the user profile
1483 data will override the ordering of the codecs in the device
1484 profile data. The user list of codecs may further constrain the
1485 list of codecs to be used.
1486 4. The local network profile data may provide a list of codecs
1487 supported. This list will further constrain the list of codecs
1488 that may be offered.
1489 5. The application profile data containing codec data will be
1490 ignored.
1491 6. The profiles need the ability to express codecs that may be used
1492 and codecs that should not be used.
1494 Authors' Addresses
1496 Martin Dolly
1497 AT&T
1498 200 Laurel Ave.
1499 Middletown, NJ
1500 US
1502 Phone:
1503 Email: mdolly@att.com
1504 URI:
1506 Daniel Petrie
1507 SIPez LLC
1508 34 Robbins Rd.
1509 Arlington, MA 02476
1510 US
1512 Phone: +1 617 273 4000
1513 Email: dan.ietf AT SIPez DOT com
1514 URI: http://www.SIPez.com/
1516 Dale R. Worley
1517 Nortel Networks Corp.
1518 600 Technology Park Dr.
1519 Billerica, MA 01821
1520 US
1522 Phone: +1 978 288 5505
1523 Email: dworley@nortel.com
1524 URI: http://www.nortel.com