RFC 6080
A Framework for Session Initiation Protocol User Agent Profile Delivery
Pages: 54
Proposed Standard
Proposed Standard
Part 1 of 3 – Pages 1 to 14
Internet Engineering Task Force (IETF) D. Petrie Request for Comments: 6080 SIPez LLC Category: Standards Track S. Channabasappa, Ed. ISSN: 2070-1721 CableLabs March 2011 A Framework for Session Initiation Protocol User Agent Profile DeliveryAbstract
This document specifies a framework to enable configuration of Session Initiation Protocol (SIP) user agents (UAs) in SIP deployments. The framework provides a means to deliver profile data that user agents need to be functional, automatically and with minimal or no User and Administrative intervention. The framework describes how SIP user agents can discover sources, request profiles, and receive notifications related to profile modifications. As part of this framework, a new SIP event package is defined for notification of profile changes. The framework provides minimal data retrieval options to ensure interoperability. The framework does not include specification of the profile data within its scope. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6080.
Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Reference Model . . . . . . . . . . . . . . . . . . . . . 6 3.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Profile Types . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Profile Delivery Stages . . . . . . . . . . . . . . . . . 9 3.5. Supported Device Types . . . . . . . . . . . . . . . . . . 10 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Simple Deployment Scenario . . . . . . . . . . . . . . . . 10 4.2. Devices Supporting Multiple Users from Different Service Providers . . . . . . . . . . . . . . . . . . . . 12 5. Profile Delivery Framework . . . . . . . . . . . . . . . . . . 14 5.1. Profile Delivery Stages . . . . . . . . . . . . . . . . . 14 5.2. Securing Profile Delivery . . . . . . . . . . . . . . . . 22 5.3. Additional Considerations . . . . . . . . . . . . . . . . 24 5.4. Support for NATs . . . . . . . . . . . . . . . . . . . . . 33 6. Event Package Definition . . . . . . . . . . . . . . . . . . . 33 6.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 33 6.2. Event Package Parameters . . . . . . . . . . . . . . . . . 33 6.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 36 6.4. Subscription Duration . . . . . . . . . . . . . . . . . . 37 6.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 37 6.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 37 6.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 38 6.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 38 6.9. Handling of Forked Requests . . . . . . . . . . . . . . . 39 6.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 39 6.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 39 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 7.1. Example 1: Device Requesting Profile . . . . . . . . . . . 39 7.2. Example 2: Device Obtaining Change Notification . . . . . 42 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 8.1. SIP Event Package . . . . . . . . . . . . . . . . . . . . 46 8.2. Registry of SIP Configuration Profile Types . . . . . . . 46 9. Security Considerations . . . . . . . . . . . . . . . . . . . 47 9.1. Local-Network Profile . . . . . . . . . . . . . . . . . . 48 9.2. Device Profile . . . . . . . . . . . . . . . . . . . . . . 49 9.3. User Profile . . . . . . . . . . . . . . . . . . . . . . . 50 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 11.1. Normative References . . . . . . . . . . . . . . . . . . . 52 11.2. Informative References . . . . . . . . . . . . . . . . . . 53
1. Introduction
SIP user agents require configuration data to function properly. Examples include information specific to local networks, devices, and users. A configuration data set specific to an entity is termed a profile. For example, device profile contains the configuration data related to a device. The process of providing devices with one or more profiles is termed "profile delivery". Ideally, this profile delivery process should be automatic and require minimal or no user intervention. Many deployments of SIP user agents require dynamic configuration and cannot rely on pre-configuration. This framework provides a standard means of providing dynamic configuration that simplifies deployments containing SIP user agents from multiple vendors. This framework also addresses change notifications when profiles change. However, the framework does not define the content or format of the profile, leaving that to future standardization activities. This document is organized as follows. The normative requirements are contained in Section 5 (framework operations) and Section 6 (the event package definition). The rest of the document provides introductory and supporting explanations. Section 3 provides a high- level overview of the abstract components, profiles, and the profile delivery stages. Section 4 provides some motivating use cases. Section 7 follows with illustrative examples of the framework in use.2. Terminology
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 [RFC2119]. This document also reuses the SIP terminology defined in [RFC3261] and [RFC3265], and it specifies the usage of the following terms. Device: software or hardware entity containing one or more SIP user agents. It may also contain applications such as a DHCP client. Device Provider: the entity responsible for managing a given device. Local Network Provider: the entity that controls the local network to which a given device is connected. SIP Service Provider: the entity providing SIP services to users. This can refer to private or public enterprises.
Profile: configuration data set specific to an entity (e.g., user,
device, local network, or other).
Profile Type: a particular category of profile data (e.g., user,
device, local network, or other).
Profile Delivery Server (PDS): the source of a profile, it is the
logical collection of the Profile Notification Component (PNC) and
the Profile Content Component (PCC).
Profile Notification Component (PNC): the logical component of a
Profile Delivery Server that is responsible for enrolling devices
and providing profile notifications.
Profile Content Component (PCC): the logical component of a Profile
Delivery Server that is responsible for storing, providing access
to, and accepting profile content.
Profile Delivery Stages: the processes that lead a device to obtain
profile data, and any subsequent changes, are collectively called
profile delivery stages.
Bootstrapping: Bootstrapping is the process by which a new (or
factory reset) device, with no configuration or minimal "factory"
pre-configuration, enrolls with the PDS. The device may use a
temporary identity and credentials to authenticate itself to
enroll and receive profiles, which may provide more permanent
identities and credentials for future enrollments.
3. Overview
This section provides an overview of the configuration framework. It
presents the reference model, the motivation, the profile delivery
stages, and a mapping of the concepts to specific use cases. It is
meant to serve as a reference section for the document, rather than
providing a specific logical flow of material, and it may be
necessary to revisit these sections for a complete appreciation of
the framework.
The SIP UA Profile Delivery Framework uses a combination of SIP event
messages (SUBSCRIBE and NOTIFY; [RFC3265]) and traditional file
retrieval protocols, such as HTTP [RFC2616], to discover, monitor,
and retrieve configuration profiles. The framework defines three
types of profiles (local-network, device, and user) in order to
separate aspects of the configuration that may be independently
managed by different administrative domains. The initial SUBSCRIBE
message for each profile allows the UA to describe itself (both its
implementation and the identity requesting the profile), while
requesting access to a profile by type, without prior knowledge of the profile name or location. Discovery mechanisms are specified to help the UA form the Subscription URI (the Request-URI for the SIP SUBSCRIBE). The SIP User Agent Server (UAS) handling these subscriptions is the Profile Delivery Server (PDS). When the PDS accepts a subscription, it sends a NOTIFY to the device. The initial NOTIFY from the PDS for each profile may contain profile data or a reference to the location of the profile, to be retrieved using HTTP or similar file retrieval protocols. By maintaining a subscription to each profile, the UA will receive additional NOTIFY messages if the profile is later changed. These may contain a new profile, a reference to a new profile, or a description of profile changes, depending on the Content-Type [RFC3261] in use by the subscription. The framework describes the mechanisms for obtaining three different profile types, but does not describe the data model they utilize (the data model is out of scope for this specification).3.1. Reference Model
The design of the framework was the result of a careful analysis to identify the configuration needs of a wide range of SIP deployments. As such, the reference model provides for a great deal of flexibility, while breaking down the interactions to their basic forms, which can be reused in many different scenarios. The reference model for the framework defines the interactions between the Profile Delivery Server (PDS) and the device. The device needs the profile data to function effectively in the network. The PDS is responsible for responding to device requests and providing the profile data. The reference model is illustrated in Figure 1. +-------------------------+ +--------+ | Profile Delivery Server | | Device |<==========================>| +---+ +---+ | +--------+ | |PNC| |PCC| | | +---+ +---+ | +-------------------------+ PNC = Profile Notification Component PCC = Profile Content Component Figure 1: Framework Reference Model The PDS is subdivided into two logical components: o Profile Notification Component (PNC), responsible for enrolling devices for profiles and providing profile change notifications.
o Profile Content Component (PCC), responsible for storing,
providing access to, and accepting modifications related to
profile content.
3.2. Motivation
The motivation for the framework can be demonstrated by applying the
reference model presented in Section 3.1 to two scenarios that are
representative of the two ends of a spectrum of potential SIP
deployments.
In the simplest deployment scenario, a device connects through a
network that is controlled by a single provider who provides the
local network, manages the devices, and offers services to the users.
The provider propagates profile data to the device that contains all
the necessary information to obtain services in the network
(including information related to the local network and the users).
This is illustrated in Figure 2. An example is a simple enterprise
network that supports SIP-based devices.
--------------
/ Local Network, \
| Device & Service |
\ Provider /
----------------
|
|
--------
| Device |
--------
|
|
----
|User|
----
Figure 2: Simple Deployment Model
In more complex deployments, devices connect via a local network that
is not controlled by the SIP service provider, such as devices that
connect via available public WiFi hot spots. In such cases, local
network providers may wish to provide local network information such
as bandwidth constraints to the devices.
Devices may also be controlled by device providers that are
independent of the SIP service provider who provides user services,
such as kiosks that allow users to access services from remote
locations. In such cases, the profile data may have to be obtained from different profile sources: local network provider, device provider, and SIP service provider. This is indicated in Figure 3. -------- / SIP \ | Service | -> Provides 'user' profile | Provider | data (e.g., services \ / configuration) -------- -------- | / \ | | Device | -> Provides 'device' profile | | Provider | data (e.g., device specifics) | \ / | --------- | / | / ------- | / / Local \ | / | Network | | | | Provider | -> Provides 'local-network' profile | | \ / data (e.g., bandwidth) | | ------- | | / | | / | | | =================== ( Local Network ) =================== | | -------- | Device | -> Needs the 'local-network' -------- and 'device' profile / \ / \ ------ ------ |User A| |User B| -> Users need 'user' profiles ------ ------ Figure 3: Complex Deployment Model In either case, Providers need to deliver to the device, profile data that is required to participate in their network. Examples of profile data include the list of codecs that can be used and the SIP proxies to which to connect for services. Pre-configuration of such information is one option if the device is always served by the same set of Providers. In all other cases, the profile delivery needs to be automated and consistent across Providers. Given the presence of
a number of large deployments where pre-configuration is neither desired nor optimal, there is a need for a common configuration framework such as the one described in this document. Further, the former deployment model can be accomplished by the device obtaining profile data from a single provider. However, the latter deployment model requires the device to obtain profile data from different providers. To address either deployment or any variation in between, one needs to allow for profile delivery via one or more Providers. The framework accomplishes this by specifying multiple profile types and a set of profile delivery stages to obtain them. These are introduced in the subsections to follow.3.3. Profile Types
The framework handles the presence of potentially different Providers by allowing for multiple profile types. Clients request each profile separately, and obtain them from the same, or different, Providers. A deployment can also choose to pre-configure the device to request only a subset of the specified profile types. The framework specifies three basic profile types, as follows: Local Network Profile: contains configuration data related to the local network to which a device is directly connected, provided by the local network provider. Device Profile: contains configuration data related to a specific device, provided by the device provider. User Profile: contains configuration data related to a specific User, as required to reflect that user's preferences and the particular services to which it is subscribed. It is provided by the SIP service provider. Additional profile types may also be specified by future work within the IETF. The data models associated with each profile type are out of scope for this document.3.4. Profile Delivery Stages
The framework specified in this document requires a device to explicitly request profiles. It also requires one or more PDSs, which provide the profile data. The processes that lead a device to obtain profile data, and any subsequent changes, can be explained in three stages, termed the profile delivery stages.
Profile Enrollment: the process by which a device requests, and if
successful, enrolls with a PDS capable of providing a profile. A
successful enrollment is indicated by a notification containing
the profile information (contents or content indirection
information). Depending on the request, this could also result in
a subscription to notification of profile changes.
Profile Content Retrieval: the process by which a device retrieves
profile contents, if the profile enrollment resulted in content
indirection information.
Profile Change Notification: the process by which a device is
notified of any changes to an enrolled profile. This may provide
the device with modified profile data or content indirection
information.
3.5. Supported Device Types
The examples in this framework tend to associate devices with
entities that are accessible to end-users. However, this is not
necessarily the only type of device that can utilize the specified
framework. Devices can be entities such as SIP Phones or soft
clients, with or without user interfaces (that allow for device
configuration), entities in the network that do not directly
communicate with any users (e.g., gateways, media servers, etc.) or
network infrastructure elements (e.g., SIP servers). The framework
is extensible for use with such device types. However, it is to be
noted that some of these other device types (e.g., network elements)
may also be configurable using other mechanisms. The use of this
framework in conjunction with other mechanisms (specified outside of
this document), is out of scope.
4. Use Cases
This section provides a small, non-comprehensive set of
representative use cases to further illustrate how this framework can
be utilized in SIP deployments. The first use case is simplistic in
nature, whereas the second is relatively complex. The use cases
illustrate the effectiveness of the framework in either scenario.
For security considerations, please refer to Sections 5 and 9.
4.1. Simple Deployment Scenario
Description: Consider a deployment scenario (e.g., a small private
enterprise) where a participating device implements this framework
and is configured, using previously obtained profile data, to request
only the device profile. Assume that the device operates in the same
network as the PDS (i.e., there is no NAT) and it obtains its IP configuration using DHCP. Typical communication between the device and the PDS will traverse one or more SIP proxies, but is not required, and is omitted in this illustration. Figure 4 illustrates the sequence of events that includes device start-up and a successful profile enrollment for the device profile that results in device profile data. It then illustrates how a change in the profile data is delivered via Profile Change Notification. +----------------------+ +--------+ | Provider's Network | | Device | | | | | | | +--------+ | DHCP PDS | +----------------------+ | | | (A) |<============== DHCP =============>| | | | | | | | (B) |<=========== Profile Enrollment ============>| | | Profile data | | is modified | | (C) |<============ Profile Change ================| | Notification | | | | | Figure 4: Use Case 1 The following is an explanation of the interactions in Figure 4. (A) Upon initialization, the device obtains IP configuration parameters such as an IP address using DHCP. (B) The device requests profile enrollment for the device profile. Successful enrollment provides it with a notification containing the device profile data. (C) Due to a modification of the device profile, a profile change notification is sent across to the device, along with the modified profile.
4.2. Devices Supporting Multiple Users from Different Service Providers
Description: Consider a single device that allows multiple users to obtain services from different SIP service providers, e.g., a kiosk at an airport. The following assumptions apply: o Provider A is the device and local network provider for the device, and the SIP service provider for user A; Provider B is the SIP service provider for user B. o Profile enrollment always results in content indirection information requiring profile content retrieval. o Communication between the device and the PDSs is facilitated via one or more SIP proxies (only one is shown in the illustration). Figure 5 illustrates the use case and highlights the communications relevant to the framework specified in this document.
User User A B +----------------------+ +----------------------+ +--------+ | Provider | | Provider | | Device | | A | | B | | | | | | | +--------+ | DHCP PROXY PDS | | PROXY PDS | +----------------------+ +----------------------+ | | | | | | (A) |<====DHCP====>| | | | | | | | | | | | | | | | Profile Enrollment | | | | (B) |<local-network profile>|<====>| | | | | <<Profile content retrieval>> | | | Profile Enrollment | | | | (C) |<== device profile ==> |<====>| | | | | <<Profile content retrieval>> | . . . | Profile Enrollment | | | | (D) |<= user profile (A) => |<====>| | | | | | | | | | <<Profile content retrieval>> . [[User A obtains services]] . . . | | Profile Enrollment | | (E) |<=========== user profile (B) ==========>|<=========>| | | | | <<Profile content retrieval>> | [[User B obtains services]] Figure 5: Use Case 2
The following is an explanation of the interactions in Figure 5. (A) Upon initialization, the device obtains IP configuration parameters using DHCP. This also provides the local domain information to help with local-network profile enrollment. (B) The device requests profile enrollment for the local network profile. It receives an enrollment notification containing content indirection information from Provider A's PDS. The device retrieves the profile (this contains useful information such as firewall port restrictions and available bandwidth). (C) The device then requests profile enrollment for the device profile. It receives an enrollment notification resulting in device profile content retrieval. The device initializes the user interface for services. (D) User A with a pre-existing service relationship with Provider A attempts communication via the user interface. The device uses the user supplied information (including any credential information) and requests profile enrollment for user A's profile. Successful enrollment and profile content retrieval results in services for user A. (E) At a different point in time, user B with a service relationship with Provider B attempts communication via the user interface. It enrolls and retrieves user B's profile and this results in services for user B. The discovery mechanisms for profile enrollment described by the framework, or the profile data themselves, can result in outbound proxies that support devices behind NATs, using procedures specified in [RFC5626].
(page 14 continued on part 2)