A Schema and Guidelines for Defining Session Initiation Protocol User Agent Profile Datasets

The SIP User Agent Profile Delivery Framework and the Framework for SIP Session Policies specify how SIP user agents locate and retrieve profile data specific to the user, the device, and the local network. It is important for SIP User Agents to be able to obtain and use these multiple sources of profile data in order to support a wide range of applications without undue complexity. While these frameworks define the mechanisms for transmitting profile data, they do not define a format for the actual profile data. This document defines the requirements, the default/mandatory to support content type for , a high level schema for, and guide to how these datasets can be defined. The goal is to enable any SIP user agent to obtain profile data and be functional in a new environment independent of the implementation or model of user agent. The nature of having profile data from three potential sources requires the definition of policies on how to apply the data in an interoperable way across implementations which may have widely varying capabilities. The ultimate objective of the framework described here, together with the SIP User Agent Profile delivery framework, is to a start up experience requiring minimal user intervention. One should be able to take a new SIP user agent out of the box, plug it in or install the software and have it get its profiles without human intervention other than security measures. This is necessary for cost effective deployment of large numbers of user agents.

"The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119." . This document reuses the terms "profile" and "device" as defined in . In addition, this document defines the following terms: a named configurable characteristic of a user agent. A given property has a well-defined range of possible values. A given property may be defined to have a range of values, allow for simultaneous use of many values (as in a list of allowed possibilities), or a set of related values that collectively form a single profile information item. the binding of a specific value or set of values to a given property. the profile that applies to a specific user. The user profile is that set of profile data the user wants to associate with a given device (e.g. ringtones used when someone calls them, the user's shortcuts). data profile that applies to a specific device. This is the data that is bound to the device itself independent of the user. It relates to specific capabilities of the device and/or preferences of the owner of the device. data that applies to the user agent in the context of the local network. This is best illustrated by roaming applications; a new device appears in the local network (or a device appears in a new network, depending on the point of view). The local network profile includes settings and perhaps policies that allow the user agent to function in the local network (e.g. how to traverse NAT or firewall, bandwidth constraints). a collection of properties. the set of property values actually set in a SIP User Agent as a result of merging the profiles from all sources; the actual effective profile for the user agent . the operation of resolving overlapping settings from multiple profiles. Overlap occurs when the same property occurs in multiple profiles (e.g. device, user, local network).

In this document requirements are specified for containing and expressing profile data for use on SIP user agents. Though much of this can be considered independent of SIP there is one primary requirement that is not well satisfied through more generic profile data mechanisms. SIP User Agent set up requires the agent to merge settings, which may overlap, from potentially three different sources (see ); each source must not only be able to provide profile information, but also express policies regarding how the profile settings may be combined with that from other sources. A schema and syntax is defined in this document to specify properties that may be aggregated to construct profiles. The general design philosophy is that many small datasets provide flexibility to the implementer to support the aggregated set that best matches the capability of the user agent. The actual properties are not defined in this document and will be the subject of derived drafts. However, some examples are provided in to illustrate the proposed mechanisms and to validate the requirements. This document defines a set of considerations, syntax and policies that must be specified when defining datasets. These are to help authors of dataset specifications to define datasets that will work in the overall schema defined in this document. The actual specification of these datasets is outside the scope of this document.

The following section defines some of the design considerations that were taken into account when defining the schema, syntax and policies for generating and applying profile data.

It does not serve user agent administrators to have to require a coordinated and orchestrated upgrade of every user agent and corresponding profile delivery servers for a new capability to be supported. Datasets MUST be extensible without breaking the user agents that support that dataset. This may require the user agents to ignore parts of the extended dataset that it does not support. It may also be possible to tag the extensions with minimum version numbers to facilitate the user agents decision making.

Since user agents vary greatly in their capabilities, it MUST be possible for the implementer to tailor the datasets to the capabilities of the user agent device. This implies that the profile is built up of a series of small datasets based upon the capabilities of the user agent. The user agents MAY ignore datasets for capabilities they do not support. This allows the profile delivery server to be agnostic of device capabilities. It is however the implementer's choice to customize the delivered profile to the device capabilities.

There are likely to be properties in various profile datasets that the Operators and Administrators do not want the users to sometimes not be able to modify or even see. It MUST be possible to disallow the user from modifying a property. It MUST be possible to obfuscate the user from seeing a property or its setting. This access control information SHOULD be optional for a given property.This is supported by the admin value of the visibility attribute.

Property values are likely to have an allowed set of values under most circumstances rather than completely unconstrained in their values. It MUST be possible for the schema to specify constraints on a property value, viz, as a range or as a set of discrete values. These constraints SHOULD be optional to the dataset and SHOULD be expressible independent of the property itself.

specifies a mechanism where the user agent retrieves profile data from as many as three different sources. The separation of the user profile facilitates a hotelling capability and the ability to easily re-assign a user to a different device. The separation of the local network profile facilitates properties specific to operating in the local network in a roaming scenario (e.g. outbound proxy or NAT traversal properties). The device profile facilitates device capability based properties as well as a means for the device owner or manager to impose policy. While increasing the complexity of the user agent in that it must aggregate and consolidate separate profiles into one working profile, constraining the properties of the various profiles to be mutually exclusive, or constraining even the merging rules would severely restrict functionality. Profile merging rules are associated with individual datasets or even associated with individual properties inside a dataset. A profile MUST have a merging algorithm defined. An individual property inside MAY contain a merging rule, in which case this merging rule is specific to the property. If however, there is no merging rule associated with a property, but the profile dataset in its entirety has a merging rule, this merging rule MUST be applied to each of the properties that form part of the profile. A few of the more commonly used merging algorithms are defined in this document. Most settings are likely to use the common set defined in this document. However authors of profile datasets may define new algorithms for merging dataset properties (see and ).

Local Network Operators may wish to impose policy on users and devices on their network such as constraining codecs, media streams, outbound proxy or emergency services. It MUST be possible to impose policy in any of the profile sources that constrains, overwrites or modifies properties provided in datasets from other sources.

XML is perhaps not really a requirement, but a solution base upon requirements. However it is hard to ignore the desire to utilize readily available tools to manage and manipulate profile data such as XSLT, XPATH and XCAP. The requirement that should be considered when defining the schema and syntax is that many user agents have limited resources for supporting advanced XML operation. The simplest XML construct possible should be used, that support the required functionality. It is not a requirement that user agents validate the profile XML document. This relieves the requirement that the Relax NG schema defined in this and other datasets documents be enforced on the user agent. The Relax NG schema should not be used to strictly validate profile XML documents. Unknown elements and attributes should be ignored to allow extensions to be supported. Strict enforcement of the Relax NG schema would make it very difficult to deploy new user agents without lock step upgrades of the profile delivery server. Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols provides useful information in this regard.

Notifiers and Subscribers of the event package defined in SHOULD support the content-type: application/uaprofile+xml. The Notifier SHOULD indicate all of the dataset schemas that is supports by listing all of the MIME types for the supported datasets in the SUBSCRIBE request header: Accept. This document defines an Relax NG Schema for that content-type with the namespace: urn:ietf:params:xml:ns:uaprof, for SIP Profile Datasets that provides: a base element type "setting" from which all settings in other schema definitions inherit (this allows other definitions to specify the content models for ways of combining settings; it is analogous to a C++ virtual base class). Attributes to the "setting" element that define constraints and other properties used to impose policy that apply to the element value. These attributes are inherited by elements that are derived from the abstract settings element. A root element for all property sets (the outermost container). The full text of the schema is in ; the following describes the usage of the schema in defining properties and combining them to construct the working profile of a User Agent.

Each property in a profile data set is defined using XML Schema Datatypes and Relax NG Schema. A property is modeled by an XML element derived from the "setting" element in the SIP Profile Data Set Schema. The element content is the setting value. Properties consisting of one single value can be expressed using a single XML element. Properties that may consist of multiple values require the use of container elements. A container element is defined for such a property. This container can contain multiple XML elements, which each defines a possible value for that property (see examples in ). When constructing a property set, the creator of a profile may not be able to know all of the capabilities of the User Agent that will receive that property set. The creator of profile constraints or policies should be aware that a user agent may ignore properties that are unsupported or do not apply to its capabilities.

XML namespaces provide a means to uniquely identify the elements and datatypes defined in a data set. It is therefore RECOMMENDED that each data set specifies its own namespace. The namespace URIs SHOULD be URNs , using the namespace identifier 'ietf' defined by and extended by . The core schema defined in this document defines the namespace: "urn:ietf:params:xml:ns:uaprof". Profile datasets that extend this schema SHOULD define a new namespace by appending a ":" and a unique name to the "urn:ietf:params:xml:ns:uaprof" namespace. These namespaces MUST be registered with IANA.

The root element of a property set is "propertySet"; it is the container that is provided to the user agent. The elements contained within a propertySet contain the specific properties which are to be applied to the user agent. The properties may be simple types with a single value, complex types or container elements with a list of properties.

The "setting_container" element is the abstract element in which a list of properties which allow multiple values may be contained. Elements derived from the "setting_container" element may contain zero or more elements derived from the "setting" element. The "setting_container" element has an "excludedPolicy" attribute.

The setting element is the abstract element from which all profile properties or settings shall inherit. The setting element has a number of attributes that provide functionalities, which are generally useful for many properties. These attributes are inherited by properties that are derived from the settings element. This enables the re-use of common functionalities and ensures a common syntax for these elements across different data sets. The following functionalities are provided by attributes of the settings element: Property Access Control: 'visibility' attribute Policies: 'policy' attribute Additional attributes are defined in the schema that may used in elements derived from "setting". By default these attributes cannot be set. These attribute must be explicitly added to elements derived from the "setting" element: Unidirectional Properties: 'direction' attribute Preferences: 'q' attribute

The attribute "visibility" is defined on the "setting" element to specify whether or not the user agent is permitted to display the property value to the user. This is used to hide setting values that the profile administrator may not want the user to see or know. The "visibility" attribute has two possible values: user: Specifies that display of the property value is not restricted to the user. This is the default value of the attribute if it is not specified. admin: Specifies that the user agent SHOULD NOT display the property value. Display of the property value may be allowed using special administrative interfaces, but is not appropriate to the ordinary user.

The setting element has an optional 'policy' attribute. The policy attribute is used to define the constraining properties of an element. It defines how the element value is used by an endpoint (e.g. whether it can or can not be used in a session). The following values are defined for the 'policy' attribute: allow: the value contained in the element is allowed and SHOULD be used in sessions. This is the default value that is used if the 'policy' attribute is omitted. disallow: the value contained in the element is forbidden and SHOULD NOT be used in sessions. The policy attribute can be omitted if the default policy 'allow' applies. The policy attribute is used only inside containers.

The "setting_container" element has an optional 'excludedPolicy' attribute. This attribute specifies the default policy for all values that are not in the container. Elements that are present in the container have their own 'policy' attribute, which defines the policy for that element. The following values are defined for the 'excludedPolicy' attribute: allow: values not listed in the container are allowed and MAY be used in sessions. This is the default value that is used if the 'excludedPolicy' attribute is omitted. disallow: values not listed in the container are forbidden and MUST NOT be used in sessions. The excludedPolicy attribute can be omitted if the default policy 'allow' applies. The following example shows a policy that allows the media type audio and disallows all other media types in sessions (effectively, this construct requires the use of audio):

audio ]]>

Some properties are unidirectional and only apply to messages or data streams transmitted into one direction. For example, a property for media streams can be restricted to outgoing media streams only. Unidirectional properties can be expressed by adding a 'direction' attribute to the respective element. The 'direction' attribute can have the following values: recvonly: the property only applies to incoming messages/streams. sendonly: the property only applies to outgoing messages/streams. sendrecv: the property applies to messages/streams in both directions. This is the default value that is used if the 'direction' attribute is omitted.

It should be possible to express a preference for a certain value, if multiple values are allowed within a property. For example, it should be possible to express that the codecs G.711 and G.729 are allowed, but G.711 is preferred. Preferences can be expressed by adding a 'q' attribute to a property element. Elements derived from the "setting" element for which multiple occurrences and values are allowed SHOULD have a "q" attribute if the order is significant. Typically these elements are contained in an element derived from the "setting_container" element. The 'q' attribute is only meaningful if the 'policy' attribute set to 'allowed'. It must be ignored in all other cases. An element with a higher 'q' value is preferred over one with a lower 'q' value. 'q' attribute values range from 0 to 1. The default value is 0.5.

The <profileUri> element contains the URI of this profile on the profile server. The value contained in the profileUri element may be different than the URI subscribe to when retrieving this profile. When the user agent retrieves a profile where the profileUri is different than the subscribe to URI, the user agent SHOULD unsubscribe to the current URI and then subscribe to the new URI. The <profileUri> element is optional and MAY occur only once inside a <propertySet> element. The profileUri element is specific to the local-network, device or user profile in which it occurs. It has no meaning outside of the profile in which it occurs and SHOULD NOT be merged.

The <profileCredential> element contains the digest authentication information that SHOULD be used for authentication for the profile subscription via SIP or profile retrieval via HTTP, HTTPS, etc. The profileCredential element is optional and MAY occur only once inside a propertySet element. The profileCredential element is specific to the local-network, device or user profile in which it occurs. It has no meaning outside of the profile in which it occurs and SHOULD NOT be merged. The profileCredential element MUST contain exactly one of each of the elements: realm, authUser and one of either a1Digest or password.

The realm element contains the string that defines the realm to which this credential pertains. The value of the realm element is the same as the realm parameter in the headers: WWW-Authenticate, Authorization and the SIP headers: Proxy-Authenticate and Proxy-Authorization. If a match of the realm value is found, the user agent uses the values in the authUser and a1Digest elements contained in the profileCredential element. Exactly one realm element MUST be contained in a profileCredential element. A wildcard of "*" MAY be used as the realm value in which case the user agent MUST calculate the A1 DIGEST for the realm given in the authentication challenge. If the wildcard is given for the realm, the clear text form of the password contained in the password element MUST also be used.

The authUser element contains the string value of the "username" parameter which SHOULD be used in Authorization and Proxy-Authorization request headers when retrying a request that was challenged for authentication. Exactly one authUser element SHOULD be contained in a profileCredential element.

The a1Digest element contains a string with the value of the A1 digest of the username, realm and password as defined in . At most one a1Digest element MUST be contained in a profileCredential element. The a1Digest element MUST NOT exist in a profileCredential element containing a password element. The username and realm used to construct the value of the a1Digest element MUST match the values of the realm and authUser elements contained in the profileCredential element with the a1Digest element.

The password element contains the clear text password for use with DIGEST Authentication . At most one password MUST be contained in a profileCredential element. The password element MUST NOT exist in a profileCredential element containing a a1Digest element. The user agent uses this password along with the realm and authUser elements to calculate the A1 digest used for DIGEST Authentication.

The <profileContactUri> element contains a contact URI (e.g. a SIP, HTTP URI or email address) under which the issuer of this profile can be reached. The contact element may, for example, contain the address of a support hotline. The <profileContactUri> element is optional and MAY occur multiple times inside a <propertySet> element. Multiple instances of the profileContactUri element allow multiple URI schemes to be provided for contact information. The user agent MAY use the URI contained profile-contact-info element which has a URI scheme that the user agent supports and can make work to provide support help for the profile. The user agent MAY provide the URIs to the user to contact the creator of the profile through other communication channels. The profileContactUri element is specific to the local-network, device or user profile in which it occurs. It has no meaning outside of the profile in which it occurs and SHOULD NOT be merged.

The <profileInfo> element provides a short textual description of the property that should be intelligible to the human user. This element may, for example, contain information about the nature of this profile, such as "Access Network Profile". The text in the <profileInfo> element is in particular be helpful when a user needs to decide whether or not to use a newly downloaded profile or when problems with a profile (e.g. a policy conflict) occur. A user agent MAY display this information in these cases. The <profileInfo> element is optional and MAY occur only once inside a <propertySet> element. The profileInfo element is specific to the local-network, device or user profile in which it occurs. It has not meaning outside of the profile in which it occurs and SHOULD NOT be merged.

The following XML example shows a SIP Profile Dataset with example extension setting elements: ddd, foo, bar, boo, containerElement and setting container elements: myContainer, myContainer1, myContainer2 and container3.

sip:a1b2c3d4e5f6@example.com example.com fred b6b577fd12aa7e1df8d60735ef56fc2e tel:+16175551212 sip:411@example.com http:example.com/sipProfile.html This is an example profile from example.com fff aaa bbb ccc ggg 111 222 333 ]]>

A UA may receive property sets from multiple sources, which need to be merged into a single combined document the UA can work with. Properties that have a single value (e.g. the maximum bandwidth allowed) require that a common value is determined for this property during the merging process. The merging rules for determining this value need to be defined individually for each element in the schema definition. Properties that allow multiple values (i.e. property containers) need to be merged by combining the values from the different data sets. The following sections describe recommended common merging algorithms. A data set definition may refer to these algorithms.

A general merging rule for elements with numeric values is to select the largest or the smallest value. For example, a merging rule for a <max-bandwidth> element would be to select the smallest value from the values that are in the competing data sets.

Multiple values in property containers are merged by combining the values from each of the competing data sets. This is accomplished by copying the elements from each property container into the merged container. Elements with identical values are only copied once. The 'policy' attribute of two elements with the same value is adjusted during the merging process according to Table 1. If an element exists only in one property container, then the default policy of the other container (i.e. the excludedPolicy) is used when accessing Table 1. For example, if an element is disallowed in one data set and the element is not contained in the other data set but the default policy is allowed for that data set, then the values disallowed and allowed are used to access Table 1. Consequently, the element will be disallowed in the merged data set. Finally, the excludedPolicy attributes of the containers are also merged using Table 1. In addition to these merging rules, each schema may define specific merging rules for each property container.

The following example illustrates the merging process for two data sets. All elements are merged into one container and the policy attributes are adjusted according to Table 1. The merged container has the default policy disallow, which is determined using Table 1. The entry for PCMA in the merged data set is redundant since it has the default policy.

PCMA Data set 2: PCMA G729 Merged data set: PCMA G729 ]]> Some constellations of policy attributes result in an illegal merged data set. They constitute a conflict that can not be resolved automatically. For example, two data sets may define two non-overlapping sets of allowed audio codecs and both disallow all other codes. The resulting merged set of codecs would be empty, which is illegal according to the schema definition of the codecs element. If the use of these properties is enforced by both networks, the UA may experience difficulties or may not be able to set up a session at all. The combined property set MUST again be valid and well-formed according to the schema definitions. A conflict occurs if the combined property set is not a well-formed document after the merging process is completed.

Some properties require that the values from different data sets are ordered based on the origin of the data set during the merging process. Property values that come from a domain close to the user agent take precedence over values that were in a data set delivered by a remote domain. This order can be used, for example, to select the property value from the closest domain. In many cases, this is the local domain of the user agent. For example, the URI of an outbound proxy could be merged this way. This order can also be used to generate an ordered list of property values during the merging process. For example, multiple values for media intermediaries can be ordered so that the closest media intermediary is traversed before the second closest intermediary and so on. This merging algorithm requires that the source of a data set is considered. If property sets are delivered through the configuration framework , the value received through a subscription using the "local-network" profile-type takes precedence over values received through other profile-type subscriptions, followed by device and then user profile-types. The session-specific policy mechanism provides an order among policy servers. This order is based on the order, in which a SIP message traverses the network, starting with the closest domain. This order can directly be used to order property values as described above.

The schema also defines a set of common types that are used in defining data sets (e.g. DataIpPort). [Need to document common types.]

This section covers several issues that should be take into consideration when specifying new data set schemas. This is intended to be a guide to authors writing specifications defining a new data set schema or extensions to existing ones.

It is RECOMMENDED that a data set defines a new XML namespace to scope all of the properties that are defined in the name space.

The properties defined in a data set schema may be simple (i.e. having a single value) or they may be complex (i.e. a container with multiple values). Each property in the data set SHOULD inherit from the "setting" element. Complex properties and all of their child elements each should inherit from "setting" as well. A data set specification should contain a section which defines the meaning of all of the properties contained in the data set. The objective is to define the property such that implementers have a clear definition and semantics to interpret properties in a consistent way. User agents not only need to use the same profile content, they need to apply the properties in a consistent way to achieve true interoperability. The following information should be defined for each property in a data set: description: describe the meaning and application of the property. cardinality: define how many instances of this property element may occur in a data set (e.g. zero, one or many) as well as its relationship to any other properties in this or other data sets. default value: define the default value of this property if it is not set. Describe if the default is different if the property is present and not set vs. completely absent from the data set. Define if the default varies in relation to another property.

User agents may receive data sets from multiple sources. They need to merge these data sets in order to create an overall data set they can work with. Collisions on data sets may occur if multiple sources provide different values for the same properties. These collisions need to be resolved during the merging process. A data set schema MUST define rules for merging data sets from different sources for each property that is defined. Recommendations for merging data sets are discussed in . A data set schema must define if and how these recommendations apply and MAY define alternative merging rules for specific settings. A data set schema must also identify combinations of properties that constitute a conflict that can't resolved. It may provide additional guidelines for the behavior of a user agent in these cases.

The following sections name some of the candidate data sets that are or may be defined. These data sets can be aggregated to form profiles appropriate to the capabilities of a user agent implementation. SIP Protocol Data Set: the lowest common denominator set of properties common to all SIP user agents of any capability. A schema covering the elements of this data set can be found in . Media Data Set: this data set contains media related policies. A schema covering the elements of this data set can be found in . Identity Data Set: AORs and lines (see ) HTTP Protocol Data Set: server settings. Proxy for clients. NAT Traversal Data Set: settings for STUN, TURN etc. SIP Digit Maps Data Set: VoIP Features:

Security is mostly a delivery problem. The delivery framework SHOULD provide a secure means of delivering the profile data as it may contain sensitive data that would be undesirable if it were stolen or sniffed. Storage of the profile on the profile delivery server and user agent is an implementation problem. The profile delivery server and the user agent SHOULD provide protection that prevents unauthorized access of the profile data. The profile delivery server and the user agent SHOULD enforce the access control policies defined in the profile data sets if present. The point of the access control construct on the data set is to provide some security policy on the visibility and ability to change sensitive properties. Some transport mechanisms for delivery of the profile data do not provide a secure means of delivery. In addition some user agents may not have the resources to support the secure mechanism used for delivery (e.g. TLS).

XML name space registration: urn:ietf:params:xml:ns:uaprof

Indicates the character encoding of enclosed XML. Default is UTF-8. Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 , section 3.2. This content type is designed to carry SIP user agent profile data, which may be considered private information. Appropriate precautions should be adopted to limit disclosure of this information. This content type provides a common format for exchange of SIP user agent profile information. RFC XXXX (Note to RFC Editor: Please fill in XXXX with the RFC number of this specification) SIP user agents and profile delivery servers. Magic number(s): File extension(s): Macintosh File Type Code(s): Sam Ganesan EMail: sam.ganesan@motorola.com com LIMITED USE This specification is a proposed work item of the IETF SIPPING working group, with mailing list address: sipping@ietf.org This media type is a specialization of application/xml , and many of the considerations described there also apply to application/uaprof+xml.

The WG version of the document is based on an individual draft authored by Dan Petrie, Scott Lawrence, Martin Dolly and Volker Hilt. It has been reviewed by many members of the SIPPING WG. In particular, we thank Henning Schulzrinne, Henry Sinnreich, Christian Stredicke for feedback on early versions of the document. We also thank Mary Barnes for her reviews and assistance with the current version of the document.

&rfc2119; &rfc2617; &rfc3261; &I-D.ietf-sipping-config-framework; &I-D.ietf-sip-session-policy-framework; &rfc3688; &rfc3023; XML Schema Part 1: Structures University of Edinburgh Oracle Corporation Commerce One Lotus Development Corporation XML Schema Part 2: Datatypes Kaiser Permanente Microsoft Namespaces in XML &I-D.petrie-sipping-sip-dataset; &I-D.petrie-sipping-identity-dataset; &I-D.petrie-sipping-voip-features-dataset; &I-D.ietf-sipping-media-policy-dataset; &rfc2648; &rfc3470; URN Syntax AT&T

15621 Drexel Circle Omaha NE 68135-2358 USA +1 402 894-9456 jayhawk@ds.internic.net

[0-9,a-f]{32,32} sip:.* sips:.* "?.*"?<?sip:.* "?.*"?<?sips:.* allow disallow user admin sendrecv sendonly recvonly 0 1 1 65535 UDP TCP TLS DTLS SCTP ]]>

In the following use case scenarios the device profile is provided by the device owner/manager. The owner/manager may be a service provider, an enterprise or a user administering the device setup. The user is assumed to be the end user operating the user agent. In the scenarios that the user profile is provided, the user profile contains user specific properties that the end user has set directly or indirectly through an administration process. The local network profiles represent the suggested policy behavior that the local network operator would like user agents to adhere to . From a security perspective, the local network operator cannot trust the user agent to follow the local network profile policy. The local network operator must use a means external to the user agent to enforce these policies. The local network profile is intended to express to the user agent, the policies that the user agent should follow if the user agent wants to function properly in the local network. Two different use cases are developed and discussed below. Similar use cases can be developed for individual datasets. For example, analysis of Transport protocol settings for SIP can be carried out in exactly the same fashion as the codec use case described below and a set of derived requirements to drive the schema for the associated datset can be arrived at.

In the case of the outbound proxy, it is unlikely that the user would want to influence the outbound proxy for SIP signaling. The device owner/manager or the local network operator are likely to want to set the outbound proxy property. The device profile may define an outbound proxy so that the device owner/manager can monitor all signaling. The local network operator also defines an outbound proxy because the proxy allows the SIP signaling to get through a NAT or firewall. Two possible solutions to this problem are listed. Define a policy where the local network profile overrides the device profile. In this approach the local network profile wins. Aggregate the outbound proxies. In this scenario SIP messages would be sent with a pre-populated route set that had two hops. First the outbound proxy set in the local network profile, then the outbound proxy set in the device profile. The aggregation approach is closest to solving the requirements to the use case above. By aggregating the two outbound proxies, the local network provided outbound proxy allows the signaling to get out of the local network and the device profile provided outbound proxy is able to monitor all SIP signaling from the user agent.

Use cases for the codec properties are likely one of the more complicated sets of properties with respect to merging and constraining across more than one profile. There are reasonable scenarios where requirements can be rationalized that the device, user and local network profiles may each wish to express preferences and constraints on permitted codecs. Without getting into details or syntax of the codec properties, it is assumed that codec properties will need to express a codec definition and a preference order. This is the order that these codecs will be put in SDP for codec negotiation purposes. The following scenarios illustrate some possible combinations of sources of codec properties from the device, user and local network profiles.

In the scenario where a device has no profiles or the profiles contain no codec properties, the device will enable a default set and preference order of codecs, which could be a subset of the codecs the device is capable of supporting. The default set and preference order of codecs is a implemention specific.

This scenario assumes that the device profile is the only source of codec properties. The codecs in the device profile may differ from the set of codecs supported by the device, due to administrative constraints on codec usage. In this scenario the device profile data will dictate the ordered list of codecs to be applied. The use agent will ignore codec types included in the profile that the user agent does not support.

This scenario covers the case where both the device profile and the user profile provide an ordered list of codecs. The user may prefer a higher quality codec to be used, if available. Thereby the user profile data may provide an ordered list of codecs to be applied. The device profile also specifies a list of codecs and a default preference order. The merging of the data sources is as follows: The ordering of the codecs will be determined from the user profile data, which overrides the codec preference ordering from the device profile data. The set of codecs that may be applied, are the codecs listed in the user data constrained by the list of codecs from the device profile data. The case in which none of the codecs in the resulting merged profile datasets are supported by the device, the profile data constitutes a misconfiguration between device and user profiles. It may not be possible to successfully establish a session in this case. It is suggested that the user agent provide feedback to the user indicating the misconfiguration. The user agent may also attempt to function in the network by ignoring one or more of the profile constraints.

In this scenario both the local network profile and the device profile each provide an ordered set of codecs. Both the local network operator and the device provider may feel the need to constrain and order the set of codecs used. This scenario is very much alike to the previous scenario and may be resolved using a similar method. However, it likely that the local network codec preferences will override and constrain the device profile, given the caveat that in the circumstances where the resulting ordered set of codecs is an empty set. In this case there is a misconfiguration/incompatibility between the device profile and the local network profile with regard to the codecs, which may render the device non functional. The user agent may attempt to function in the network by ignoring one or more of the profile constraints.

In this scenario all profiles namely, device, user and local network profiles, provide an ordered set of codecs as preferences. For example, these may be the result of device capabilities, user's preference for higher quality media and the network providers desire to constrain bandwidth usage and or enforce uniformity of codec usage. The data sources could be merged as follows: The ordering of the codecs will be determined from the user profile data, which overrides the ordering from the device profile data. The set of codecs that may be used are the codecs listed in the device profile data, constrained by the list of codecs from the user profile data and further constrained by the list of codecs from the local network profile data. A resulting null set of codecs would imply a misconfiguration and may prevent the device from functioning under these circumstances. The user agent may also attempt to function in the network by ignoring one or more of the profile constraints.

An example set of derived requirements for the codec definition is presented here. These requirements in turn would drive the profile definition for codec usage. The list of codecs in the device profile data that get applied is the subset of the codecs supported by the device. Codecs listed in profiles that are not supported by the device are ignored. The device profile data will have a default ordered list of codecs, which implies a preference order to be used in the sdp offer. The user profile data may provide an ordered list of user preferred codecs. The ordering of the codecs in the user profile data will override the ordering of the codecs in the device profile data. The user list of codecs may further constrain the list of codecs to be used. The local network profile data may provide a list of codecs supported. This list will further constrain the list of codecs that may be offered. The application profile data containing codec data will be ignored. The profiles need the ability to express codecs that may be used and codecs that should not be used.