RFC 6794
A Framework for Session Initiation Protocol (SIP) Session Policies
A Framework for Session Initiation Protocol (SIP) Session Policies 🎀
the RFC deets 📋
- RFC number: 6794
- Publisher: Internet Engineering Task Force (IETF)
- Authors: V. Hilt (Bell Labs/Alcatel-Lucent), G. Camarillo (Ericsson), J. Rosenberg (jdrosen.net)
- Category: Standards Track
- ISSN: 2070-1721
- Date: December 2012
- Obsoletes/Updates: nothing is listed in the title block, so it doesn't obsolete or update any other RFCs 💅
Abstract
okay so proxy servers are literally the main characters of SIP 👑 They're the intermediaries that decide policies on call routing, rendezvous, and other call features ✨ This doc lays out a framework for SIP session policies, which gives proxies a standard way to define or influence policies on sessions, like which codecs or media types get used 🦋 It defines a model, an overall architecture, and new protocol mechanisms for session policies. ✨
Status of This Memo
this is an Internet Standards Track document 🌈
it's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community 🫶 it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more on Internet Standards, check out Section 2 of RFC 5741 📚
for the current status of this document, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6794 🔥
Copyright Notice
Copyright (c) 2012 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) as in effect on the date of publication. please read these carefully, because they explain your rights and restrictions for this document 🙈 Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License. 💜
Table of Contents
1. Introduction ....................................................3
2. Terminology .....................................................5
3. Session-Independent Policies ....................................5
3.1. Architecture and Overview ..................................5
3.2. Policy Subscription ........................................6
3.2.1. User Agent Client (UAC) Behavior ....................6
3.2.2. User Agent Server (UAS) Behavior ....................8
4. Session-Specific Policies .......................................8
4.1. Architecture ...............................................8
4.2. Overview ...................................................9
4.3. Examples ..................................................11
4.3.1. Offer in Request ...................................11
4.3.2. Offer in Response ..................................13
4.4. UA/Policy Server Rendezvous ...............................15
4.4.1. UAC Behavior .......................................15
4.4.2. Proxy Behavior .....................................17
4.4.3. UAS Behavior .......................................20
4.4.4. Caching the Local Policy Server URI ................21
4.4.5. Header Field Definition and Syntax .................22
4.5. Policy Channel ............................................23
4.5.1. Creation and Management ............................24
4.5.2. Contacting the Policy Server .......................25
4.5.3. Using Session Policies .............................26
5. Security Considerations ........................................27
6. IANA Considerations ............................................29
6.1. Registration of the "Policy-ID" Header Field ..............29
6.2. Registration of the "Policy-Contact" Header Field .........29
6.3. Registration of the "non-cacheable" Policy-Contact
Header Field Parameter ....................................29
6.4. Registration of the "policy" SIP Option Tag ...............29
7. References .....................................................30
7.1. Normative References ......................................30
7.2. Informative References ....................................31
Appendix A. Acknowledgements ......................................32
Appendix B. Session-Specific Policies - Call Flows ................32
B.1. Offer in Invite ...........................................32
B.2. Offer in Response .........................................34
B.3. Multiple Policy Servers for the UAS .......................351. Introduction ✨
okay so the Session Initiation Protocol (SIP) [RFC3261] is a signaling protocol for creating, modifying, and terminating multimedia sessions 🦋 the big deal in SIP is the proxy server. proxies are intermediaries that handle request routing, rendezvous, authentication and authorization, mobility, and other signaling services. but here's the tea: proxies are kind of divorced from the actual sessions (audio, video, and session-mode messaging) that SIP sets up 🙈 the details of those sessions ride along in the payload of SIP messages, and they're usually described with the Session Description Protocol (SDP) [RFC4566]. 💅
experience has shown that SIP intermediaries need to be able to impact aspects of a session 🌸 for example, SIP can run over a wireless network, which has limited resources for media traffic. when things get super busy, the wireless network provider might want to cap how much bandwidth each user gets 📶 with session policies, an intermediary in that wireless network can tell the user agent (UA) how much bandwidth it has available. that info helps the UA make a smart choice about how many streams, which media types, and which codecs it can actually use in a session ✨ a network provider can also have a service level agreement with a user that defines which media types the user is allowed to use. with session policies, the network can share its current set of policies with user agents, so they can set up sessions without accidentally breaking any of the network policies 👑
here's another one. a SIP user agent is on a network that connects to the public Internet through a firewall or a network border device 🔥 the network provider wants to tell the UA that it needs to send its media streams to a specific IP address and port on that firewall or border device so it can reach the public Internet. knowing this policy lets the UA set up sessions across the firewall or the network border 🧚 unlike other ways of inserting a media intermediary, session policies don't require inspecting or modifying SIP message bodies. 🫶
domains often need to enforce the session policies they have in place 💅 say a domain has a policy that bans video, and its enforcement mechanism drops every packet that contains a video encoding 💀 the annoying part is that these enforcement mechanisms usually don't tell the user what policies they're enforcing. they just quietly stop the user from doing anything against them 😭 that can make devices malfunction in ways the user has zero clue about 🙈 with session policies, the user knows the current network policies and can either set up policy-compliant sessions or just connect to a domain with less strict policies 🌈 so session policies bring together two important things: consent and enforcement 🎀 the user becomes aware of the policy and has to act on it, but the provider still keeps the right to enforce it. ✨
there are two types of session policies: session-specific policies and session-independent policies 🦋 session-specific policies are created for one particular session, based on that session's session description. they let a network intermediary look at the session description a UA is proposing and send back a policy that's specific to that session description. for example, an intermediary could open pinholes in a firewall/NAT for each media stream in the proposed session description. then it can return a policy for that session description that replaces the UA's IP addresses and ports with the ones opened in the firewall/NAT that are reachable from the outside. session-specific policies give a domain info about a specific session, and the domain can use that to implement policies for opening pinholes on a firewall/NAT 🔥 because they're tailored to one session, they only apply to the session they were made for. they're created session by session, at the time the session is established. 👑
session-independent policies are different: they're created independent of any session and generally apply to all SIP sessions a user agent sets up 🌸 for example, a session-independent policy can tell user agents about an existing bandwidth limit or media type restrictions. since these policies aren't based on a specific session description, they can be created without anyone trying to set up a session. they only need to be conveyed to the user agent when it initializes (for example, when the device is powered on) and whenever the policies change 🧚
this specification defines a framework for SIP session policies 💖 it specifies a model, the overall architecture, and the new protocol mechanisms needed for both session-independent and session-specific policies. since session-specific and session-independent policies have different requirements, this specification defines two different mechanisms for delivering them to user agents 🎀 those mechanisms are independent of each other. depending on whether one or both types of session policies are needed, you can use the session-specific mechanism, the session-independent mechanism, or both to deliver policies to user agents. 🫶
it is RECOMMENDED that UAs and intermediaries use the mechanisms defined in this specification for signaling session policies to endpoints 🌈 to keep backwards compatibility with UAs that don't support this specification, intermediaries may choose to fall back on existing mechanisms, such as rejecting sessions that aren't policy compliant with a 488 response, if a UA doesn't indicate support for session policies. UAs that don't support session policies get the same user experience they get today. 💅 but these techniques are known to have a lot of drawbacks, so it is RECOMMENDED that UAs and intermediaries use explicit signaling of policies using the mechanisms defined in this specification. 🔥
2. Terminology 📖
here's the key words rundown: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 💜
3. Session-Independent Policies ✨
okay so session-independent policies are the chill, long-term rules that aren't tied to any one call 💅 They get created independently of a session and generally apply to every session a user agent sets up. They're pretty stable and apply to any session that gets set up while they're valid. BUT they can change over time 🦋 For example, a bandwidth limit for a user could drop during peak hours and open up again off-peak. When that happens, the policy server tells the UA that the session-independent policies changed 🫶
3.1. Architecture and Overview
+-------------+
/------| policy |
+----+ / | server 1 |
| |---/ +-------------+
| UA | ...
| |---\ +-------------+
+----+ \ | policy |
\------| server n |
+-------------+
Figure 1so a SIP UA can get session-independent policies from one or more policy servers 🌸 Usually, the UA gets them from a policy server in its local network domain (aka the domain it gets IP service from) and maybe also from its SIP service provider domain (aka the domain it registers with). The local network can have policies that support the access network infrastructure. Like, on a wireless network where bandwidth is scarce, a provider can limit how much bandwidth one user gets 📶 The SIP service provider can have policies needed to support services, or policies that reflect the service level agreement with the user 💜 So in most cases, a UA gets session-independent policies from just one or two policy servers, which is honestly so manageable 🙈
Setting up session-independent policies involves these steps:
- A user agent discovers session-independent policy servers in the local network and SIP service provider domain.
- A user agent requests session-independent policies from the discovered policy servers. A user agent typically requests these policies when it starts up or connects to a new network domain.
- The policy server selects the policies that apply to this user agent. The policy server can have general policies that apply to all users, or it can maintain separate policies for each individual user. The selected policies are returned to the user agent.
- The policy server can update the policies, for example, when network conditions change.
3.2. Policy Subscription
3.2.1. User Agent Client (UAC) Behavior
okay this part is SO important 😭 A UA that supports session-independent policies compliant to this specification MUST attempt to retrieve session-independent policies from the local network and the SIP service provider domain. The only exception is if the UA knows (e.g., through configuration) that a domain doesn't provide session-independent policies. In that case, the UA SHOULD NOT retrieve session-independent policies from that specific domain 🎀
A UA that supports session-independent policies compliant to this specification MUST support retrieving them from the local network and the SIP service provider domain using the ua-profile event package, which is defined in "A Framework for Session Initiation Protocol User Agent Profile Delivery" [RFC6080]. The UA MAY support other methods of retrieving session-independent policies from those same domains ✨
The ua-profile event package [RFC6080] gives you a mechanism to subscribe to session-independent policies 🧚 A UA subscribes to the policy server in the local network domain using the procedures defined for the local-network profile-type. For the policy server in the SIP service provider domain, the UA uses the procedures defined for the user profile type 💅
A UA (re-)subscribes to session-independent policies when any of these events happen:
- The UA registers a new address-of-record (AoR) or removes an AoR from the set of AoRs it has registered. In these cases, the UA MUST establish subscriptions for each new AoR using the
userand thelocal-networkprofile-types. The UA MUST terminate all subscriptions for AoRs it has removed. 🔥 - The UA changes the domain it's connected to. The UA MUST terminate all existing subscriptions for the
local-networkprofile-type. Then the UA MUST create a new subscription for each AoR it maintains, using thelocal-networkprofile-type. This way, the UA stops receiving policies from the previous local domain and starts receiving the policies of the new local domain 🌈 The UA does not need to change the subscriptions foruserprofiles.
If a UA can't establish a subscription, it SHOULD NOT retry that subscription unless one of the events above happens again. This keeps the number of SUBSCRIBE requests down within domains that don't support session-independent policies 🙈 That said, a UA SHOULD retry the subscription with a longer time interval (e.g., once every 24 hours). This is how UAs can detect new policies deployed in a network that previously had none ⭐
A UA that supports session-independent policies compliant to this specification MUST support the User Agent Profile Data Set for Media Policy [RFC6796]. To say it wants to receive session-independent policies, the UA includes the MIME type application/media-policy-dataset+xml in the Accept header field of a SUBSCRIBE request 🫶
A UA MUST apply the session-independent policies it has received, and it MUST use these policies in the session descriptions it creates. If the UA decides NOT to use the received policies, then the UA MUST NOT set up a session unless it changes the domain that provided these policies. A UA MAY try to connect to another local network and/or SIP service provider domain with a different set of policies. 💀
Wait, I need to keep the capitalisation exact, so here is the actual rule: the UA decides not to use the received policies, so the UA MUST NOT set up a session unless it changes the domain that provided those policies. Keep it straight, bestie 💖
If a UA receives both session-independent and session-specific policies, the UA MUST apply the session-independent policies to the session description before that session description is sent to the session-specific policy server (see Section 4). So session-independent policies are always applied before session-specific policies get retrieved 👑
3.2.2. User Agent Server (UAS) Behavior
A policy server MAY send a notification to the UA every time the session-independent policies covered by the subscription change 🦋 What counts as a policy change is totally up to the administrator. A change can be triggered by, for example, a change in network status, a change in the time of day, or an update to the service level agreement with the customer 🍓
4. Session-Specific Policies ✨
okay now we're getting into the per-call stuff 🎀 Session-specific policies are created specifically for one particular session of a UA, so they'll usually be different from session to session. They can even change during the course of a session 😭 For example, a user can run out of credit mid-call, which makes the network disallow transmission of all media streams from that point on 💀
4.1. Architecture
domain 1
+-----------+
/------| proxy |----...
+----+ / +-----------+
| |---/ +-----------+
| | | policy |
| UA |============| server |
| | +-----------+
| |**** +-----------+
+----+ * | policy |
*******|enforcement|****...
+-----------+
--- SIP Signaling
=== Policy Channel
*** Media
Figure 2so for session-specific policies you need a few entities (see Figure 2): a user agent (UA), a proxy, a policy server, and possibly a policy enforcement entity 🧚
The proxy's job is to act as a rendezvous mechanism for UAs and policy servers 🌸 It makes sure each UA has the URI [RFC3986] of the policy server in its domain and knows where to retrieve policies from. If a UA hasn't received that URI yet (say, from a previous call or through configuration), the proxy conveys it. The proxy does NOT deliver the actual policies to UAs 💅
The policy server is a separate logical entity, and it can be physically co-located with the proxy 💜 Its job is to deliver session policies to UAs. It receives session information from the UA, uses that info to figure out which policies apply to the session, and returns those policies to the UA. How policies get generated (i.e., how policy decisions are made) is outside the scope of this specification. A policy server can, for example, query an external entity to get policies, or it can directly incorporate a policy decision point and generate policies locally 🔥
A UA gets the URI of a policy server from a proxy and uses it to contact that policy server. It tells the policy server about the current session and receives session policies in response. The UA can also get policy updates from the policy server during the course of a session 🫶
A network can have a policy enforcement infrastructure in place. However, this specification doesn't make any assumptions about how session policies are enforced, and the mechanisms defined here are orthogonal to any policy enforcement infrastructure 🌈
In principle, each domain traversed by SIP signaling messages can define session-specific policies for a session 🦋 Each domain needs to run a policy server and a proxy that can rendezvous a UA with that policy server (as shown in Figure 2). That said, session-specific policies will often only be provided by the local domain of the user agent ⭐
4.2. Overview ✨
okay so the big idea here is that SIP signaling and the policy exchange are totally separate things 💅 SIP is only used to rendezvous the UA with the policy server. From then on, the UA and the policy server talk directly to each other over a separate policy channel 🎀 The opposite vibe is the piggyback model, where the policy info between an endpoint and a policy server in the network gets stuffed onto the SIP signaling messages going between the endpoints. Not it 🙅♀️
the main perk of a separate policy channel is that it decouples the signaling between endpoints from the policy exchange between an endpoint and a policy server 🦋 That decoupling is honestly iconic, because it lets you use separate encryption mechanisms on the signaling path (to secure the communication between endpoints) and on the policy channel (to secure the communication between endpoint and policy server) 🔐 Policies can also be submitted directly from the policy server to the endpoint. They don't have to travel along the signaling path, which can potentially cross many domains 🌍 Endpoints set up a separate policy channel to each policy server and can disclose whatever information that specific policy server requests (e.g., offer or offer/answer) 💜 And policy servers don't need a SIP signaling message flowing by to send policies or policy updates to an endpoint. A policy server can use the policy channel at any time to update session policies as needed ⏰ The one downside? The separate channel model needs additional messages for the exchange of policy information 😭 but ngl it's worth it.
Following this model, signaling for session-specific policies involves the following two fundamental tasks:
- UA/policy server rendezvous: a UA setting up a session needs to be able to discover the policy servers that are relevant to this session. 🔍
- Policy channel: once the UA has discovered the relevant policy servers for a session, it needs to connect to these servers, disclose session information, and retrieve the policies that apply to this session. 🧚
the communication between the UA and the policy server on the policy channel goes through the following steps:
- A user agent submits information about the session it is trying to establish to the policy server and asks whether a session using these parameters is permissible. 🙋♀️
- The policy server generates a policy decision for this session and returns the decision to the user agent. Possible policy decisions are (1) to deny the session, (2) to propose changes to the session parameters with which the session would be acceptable, or (3) to accept the session as it was proposed. ⚖️
- The policy server can update the policy decision at a later time. A policy decision update can, for example, propose additional changes to the session (e.g., change the available bandwidth) or deny a previously accepted session (i.e., disallow the continuation of a session). 🔄 bestie, the server really can change its mind 💀
In many cases, the mechanism for session-specific policies will be used to disclose session information and return session policies 🌸 However, some scenarios only involve disclosing session information to a network intermediary. If an intermediary doesn't intend to return a policy, it can simply accept the session as it was proposed ✅ Similarly, some session-specific policies only apply to the offer (so they only require the offer to be disclosed), whereas others apply to both the offer and the answer. Both types are supported by the session-specific policy mechanism 🫶
4.3. Examples 🎬
this section gives you two examples to show how session-specific policies work overall 🍓 The call flows show the rendezvous mechanism between the UA and the policy server, and they point out where the UA swaps policy information with the policy server.
The example is based on this scenario: there are two domains (domain A and domain B), and both have session-specific policies for the UAs in their own domain. Neither domain gives policies to UAs outside of its own domain 🏠 Each domain has a proxy (Proxy A and Proxy B) and a policy server (PS A and PS B). The policies in both domains involve the session description offer and answer 💖
4.3.1. Offer in Request 📞
The first call flow, shown in Figure 3, is an INVITE transaction with the offer in the request. It's assumed this is the first INVITE request the UAC creates in this domain, so it doesn't have any previous knowledge about the policy server URIs in this domain 🙈
(1) UA A sends an INVITE request to Proxy A. Proxy A knows that policies apply to this session, so (2) it returns a 488 (Not Acceptable Here) response to UA A. Proxy A includes the URI of PS A in the 488 (Not Acceptable Here) response. This step is needed because the UAC has no prior knowledge about the URI of PS A. (3) UA A uses the URI to contact PS A, discloses the session description offer to PS A, and (4) receives policies for the offer. (5) UA A reformulates the INVITE request considering the received policies and includes a Policy-ID header field to indicate that it has already contacted PS A. Proxy A doesn't reject the INVITE request this time and removes the Policy-ID header field when forwarding the INVITE request. Proxy B adds a Policy-Contact header field containing the URI of PS B. (6) UA B uses this URI to contact PS B and discloses the offer and the answer it is about to send. (7) UA B receives policies from PS B and applies them to the offer and answer, respectively. (8) UA B returns the updated answer in the 200 (OK) response. (9) UA A contacts PS A again with the current offer and answer, and (10) retrieves the policies for both from PS A. 🎉
UA A Proxy A Proxy B UA B
| | | |
| INVITE offer | | |
|---------------->| | | (1)
| 488 | | |
| + Policy-Contact| | |
|<----------------| | | (2)
| ACK | | |
|---------------->| | |
| | PS A | |
| | | |
| PolicyChannel | | |
| + InfoOffer | | |
|------------------->| | | (3)
| PolicyChannel | | |
| + PolicyOffer | | |
|<-------------------| | | (4)
| | | |
| | | |
| INVITE offer' | INVITE offer' | INVITE offer' |
| + Policy-ID | | + Policy-Contact|
|---------------->|--------------->|---------------->| (5)
| | | |
| | PS B | |
| | | |
| | | PolicyChannel |
| | | + InfoOffer' |
| | | + InfoAnswer |
| | |<-------------------| (6)
| | | PolicyChannel |
| | | + PolicyOffer |
| | | + PolicyAnswer |
| | |------------------->| (7)
| | | |
| | | |
| OK answer' | OK answer' | OK answer' |
|<----------------|<---------------|<----------------| (8)
| ACK |
|--------------------------------------------------->|
| | | |
| | | |
| PolicyChannel | | |
| + InfoOffer' | | |
| + InfoAnswer' | | |
|------------------->| | | (9)
| PolicyChannel | | |
| + PolicyOffer | | |
| + PolicyAnswer | | |
|<-------------------| | | (10)
| | | |
Figure 34.3.2. Offer in Response 🦋
okay so this one is the flow where the offer shows up in the response 🫶 Figure 4 walks through an INVITE transaction where the offer comes back in the response instead.
UA A sends an INVITE with no offer to Proxy A (1), and Proxy A replies with a 488 (Not Acceptable Here) that carries the URI of PS A (2). UA A uses that policy server URI to set up the policy channel (3),(4). At this point UA A doesn't disclose a session description, because it doesn't have the offer yet 🙈 Then UA A re-sends the INVITE with a Policy-ID header field to show that it already contacted PS A (5). This time Proxy A doesn't reject the INVITE, and it strips the Policy-ID header field when it forwards the request. Proxy B adds a Policy-Contact header field with the URI of PS B. UA B uses that URI to disclose the offer to PS B (6), gets policies back from PS B, and applies them to the offer (7). Then UA B sends the updated offer back in the 200 (OK) response (8).
Here's the lowkey plot twist 👀 UA A goes to the policy server and discloses both the offer and the answer it's about to send (9),(10) before it sends the answer in step (11). This means UA A can put the final answer in the ACK request, and that ACK includes all the applicable policies ✨ The catch is that PS A has to hand back a policy right away, or the ACK gets delayed. Last but not least, UA B sends the current offer and answer to PS B again (12),(13) and applies the policies it gets to both of them before using them 💅
UA A Proxy A Proxy B UA B
| | | |
| INVITE | | |
|---------------->| | | (1)
| 488 | | |
| + Policy-Contact| | |
|<----------------| | | (2)
| ACK | | |
|---------------->| | |
| | PS A | |
| | | |
| PolicyChannel | | |
|------------------->| | | (3)
| PolicyChannel | | |
|<-------------------| | | (4)
| | | |
| | | |
| INVITE | INVITE | INVITE |
| + Policy-ID | | + Policy-Contact|
|---------------->|--------------->|---------------->| (5)
| | | |
| | PS B | |
| | | |
| | | PolicyChannel |
| | | + InfoOffer |
| | |<-------------------| (6)
| | | PolicyChannel |
| | | + PolicyOffer |
| | |------------------->| (7)
| | | |
| | | |
| OK offer' | OK offer' | OK offer' |
|<----------------|<---------------|<----------------| (8)
| | | |
| | | |
| PolicyChannel | | |
| + InfoOffer' | | |
| + InfoAnswer | | |
|------------------->| | | (9)
| PolicyChannel | | |
| + PolicyOffer | | |
| + PolicyAnswer | | |
|<-------------------| | | (10)
| | | |
| ACK answer' |
|--------------------------------------------------->| (11)
| | | |
| | | |
| | | PolicyChannel |
| | | + InfoOffer' |
| | | + InfoAnswer' |
| | |<-------------------| (12)
| | | PolicyChannel |
| | | + PolicyOffer |
| | | + PolicyAnswer |
| | |------------------->| (13)
| | | |
Figure 44.4. UA/Policy Server Rendezvous 🌸
okay this is the bit where the UAs get introduced to the right policy servers ✨ Before you can set up session-specific policies, the UAs need to find out the URIs of every policy server that matters for the session. Once they have those, they're basically matched up and ready to go 💖
4.4.1. UAC Behavior 💜
A UAC that follows this specification MUST include a Supported header field with the option tag policy in every request that can start an offer/answer exchange [RFC3264], like INVITE, UPDATE [RFC3311], and PRACK [RFC3262] requests. Even if a particular request doesn't carry an offer or an answer (like an INVITE with no offer), the UAC MUST still include the policy option tag 🫶 A UAC MAY also put the policy option tag on every request, if it wants to.
A UAC can get a 488 (Not Acceptable Here) response that has a Policy-Contact header field in it. This header is brand new in this spec 🎀 It holds one URI for a policy server, or several alternative URIs. A proxy sends back a 488 (Not Acceptable Here) with this header to tell the UAC where its local policy server is. Once the UAC gets that response, it has to decide whether it actually wants to keep going now that it knows a policy server exists. If it does decide to continue, the UAC MUST use one of those policy server URIs to reach the policy server, using the mechanism described in Section 4.5.
The Policy-Contact header can carry several URIs, each with a different URI scheme but all with an alt-uri parameter that has the same value. They're basically different routes to get the very same policy 🦋 The UAC picks one of them to actually use. The UAC MAY read the order of the alternatives as a hint about which one is preferred. The domain of the proxy might prefer the topmost URI in the list for getting the policy.
After the UAC gets policies from the policy server, it decides whether it wants to accept them. If it accepts them, the UAC MUST apply them to the current request and re-send the updated request. If the policies don't require any changes, or no policies were received at all, the request can be re-sent without any policy-induced changes. But if the UAC decides the list of policy servers or the session policies it received are unacceptable, then the UAC MUST NOT re-send the request 🚫
To keep the integrity of the policy server URI in a Policy-Contact header field safe, the UAC SHOULD use a secured transport protocol such as Transport Layer Security (TLS) [RFC5246] between the UAC and the proxy 🔐
The UAC MUST insert a Policy-ID header field into any request where it has contacted a policy server and accepted the policies it received. The Policy-ID header field is also new in this specification 🌈 The UA MUST create a Policy-ID header field value for each policy server it contacted while preparing the request. Each value has two pieces of info: the policy server URI, and an optional token. The policy server URI is the one the UA used to reach the policy server. The token is an opaque string the UAC might get from the policy server. A token could, for example, be included in the policy document [RFC6796]. If the UAC got a token from the policy server, the UAC MUST include that token in the Policy-ID header field. The format of the Policy-ID header field is defined in Section 4.4.5.
The main job of the Policy-ID header field is to let a proxy figure out whether the UAC already knows the URI of the local policy server. If the UAC doesn't know that URI yet, the proxy can pass it along by rejecting the request with a 488 (Not Acceptable Here) response 💅
Sometimes a request goes through multiple domains that each have a session-policy server. Every one of those domains can send back a 488 (Not Acceptable Here) response with a policy server URI. A UAC contacts a policy server after it gets a 488 (Not Acceptable Here) from a domain, and before it re-sends the request. That creates an implicit order among the policy servers in the different domains 👑 So the UAC contacts the first policy server, re-sends the modified request, contacts the second policy server, re-sends the modified request, and so on. This way the session policies always get applied in the same order that the request travels through the domains. The UAC MUST NOT change this implicit order among the policy servers ✨
A UAC often needs to contact the policy server in its local domain before it sets up a session. To avoid getting the local policy server URI retransmitted in a 488 (Not Acceptable Here) response for every new request, a UA SHOULD keep a cache with the URI of the policy server in its local domain (see Section 4.4.4). The UAC SHOULD use that cached policy server URI to contact the local policy server before sending a request that starts an offer/answer exchange for a new session (like an INVITE request). The UAC SHOULD NOT cache a policy server URI from a different domain than its own, even if it's the first policy server URI that came back. That first URI can be from another domain if the local domain doesn't have a policy server. Also, note that UACs do exact domain comparisons, so foo.example.com and example.com are not considered equivalent 🙈
UAs can renegotiate the session description during a session by starting a later offer/answer exchange, like in an INVITE, UPDATE, or PRACK request. When a UA creates one of these mid-dialog requests, it SHOULD contact all the policy servers it set up a policy channel with during the initial offer/answer exchange (see Section 4.5) before sending the request. That way the policy server URIs don't have to be retransmitted in 488 (Not Acceptable Here) responses for mid-dialog requests 🎀
4.4.2. Proxy Behavior 🎀
okay so a proxy is basically the matchmaker 💅🧚 It's the thing that gets UAs and the policy server to find each other. It does this by passing the URI of a policy server to the UAC or the UAS (or both) whenever it's handling an INVITE, UPDATE, or PRACK request (or any other request that can start an offer/answer exchange) ✨
If an offer/answer exchange starting request has a Supported header field with the option tag policy, the proxy MAY reject it with a 488 (Not Acceptable Here) response, just so it can hand the UAC the local policy server URI 🙈 BUT before rejecting anything, the proxy MUST check that the request doesn't have a Policy-ID header field with the local policy server URI as a value. If there's no such header field, or the local policy server URI isn't in it, then the proxy MAY reject the request with a 488 (Not Acceptable Here) response. The proxy MUST put a Policy-Contact header field in that 488 (Not Acceptable Here) response, and it has to hold one (or several) URI(s) of its associated policy server. The proxy MAY add the header field parameter non-cacheable so the UAC doesn't cache this policy server URI (see Section 4.4.4) 💀
More than one URI for the policy server, each using a different URI scheme, MAY be provided by the proxy as alternative ways to contact the policy 🌈 If a proxy includes multiple URIs for the same policy, it MUST include an alt-uri parameter for every policy server URI that's an alternative for getting that same policy. The alt-uri parameter MUST contain either the domain name of the domain that all the alternative policy server URIs relate to, or a Fully Qualified Domain Name (FQDN) (e.g., the hostname of a policy server). All URIs that are alternatives for the same policy MUST have the same value for the alt-uri parameter. That value MUST be picked so the same value will not show up with other policy server URIs that a UA needs to contact through any other proxy in the same domain or in another domain. One way to make a brand new unique alt-uri value is to look at the existing alt-uri parameters and make sure yours is different. A proxy MAY hint to a UA which URI it prefers by putting the more preferred URI higher in the list than the other alternatives 🍓 URIs with the same alt-uri parameter MUST use different URI schemes. A SIP or SIPS URI MUST be included even if other URI schemes are defined and used in the future.
If a local policy server URI is present in a Policy-ID header field value of a request, then the proxy MUST NOT reject the request as described above (it can still reject the request for other reasons). The proxy SHOULD remove the Policy-ID header field value of its associated policy server from the Policy-ID header field before forwarding the request. Not removing it won't cause harm, but the value isn't relevant to any other proxy on the path and it only makes the message bigger. It would also disclose the policy server URI to subsequent proxies 🫣
The Policy-ID header field has two main jobs. First and most important, it lets the proxy figure out whether a UAC already knows the URI of the local policy server. The second job is letting a domain route all the requests that belong to the same session (the initial request and the requests a UA retransmits after contacting the policy server) to the same proxy and policy server. This matters when a domain has multiple proxy/policy server combinations (e.g., in a proxy/policy server farm that gets requests through a load balancer) that create per-session state in the network. An example is a policy server associated with a session border device. The policy server configures the session border device after it receives a session description from the UAC via the policy channel 📡
Retransmitted requests for such a session need to go to the same proxy/policy server as the initial request, since that proxy/policy server combination has configured the associated border device for the session 🎀
Routing all requests that belong to the same session to the same proxy can be done with the Policy-ID header field token. It requires that the policy server return a token to the UAC that uniquely identifies the specific proxy/policy server combination. The UAC includes this token in the Policy-ID header field, and it can be used (together with the policy server URI) by the proxies in this domain to route the request along the desired path. The format of this token doesn't need standardizing. The only requirement is that the token gives proxies enough info to route the message inside a domain to the desired proxy/policy server. The token can be, for example, a numeric identifier or an IP address 🧚
Note: it has been proposed to use the Policy-ID header field to give a proxy a hint that the UAC has actually contacted the policy server. This usage also requires the policy server to return a token to the UA. In addition, the policy server needs to share valid tokens with the proxy. After receiving a request with a Policy-ID header field, the proxy can determine if the token in the Policy-ID header field is valid. If it is valid, the proxy knows that the UA has contacted the policy server for this session. However, this token doesn't prove that the UA has actually used the policies it received from the policy server. A malicious UA can simply contact the policy server, discard all policies it receives, and still use the token in the Policy-ID header field 😈
The proxy MAY insert a Policy-Contact header field into INVITE, UPDATE, or PRACK requests (or any other request that can initiate an offer/answer exchange) in order to convey the policy server URI to the UAS 💌 If the request already contains a Policy-Contact header field, the proxy MUST insert the URI after all existing values, at the end of the list. A proxy MUST NOT change the order of existing Policy-Contact header field values.
A proxy MUST use the Record-Route mechanism [RFC3261] if its associated policy server has session policies that apply to mid-dialog requests. Record-Route lets a proxy stay in the signaling path and resubmit the policy server URIs to UAs during mid-dialog requests that initiate an offer/answer exchange. Resubmitting the policy server URI to UAs makes sure UAs keep contacting the policy server for mid-dialog requests 🔁
A proxy can find out if the UAS supports this extension by checking the Supported header field of responses. The proxy knows that the UAS supports this extension if the Supported header field of a response contains the option tag policy. A proxy can use this information to determine if the UAS has understood the Policy-Contact header field it inserted into the request ✅
To protect the integrity of the policy server URI in a Policy-Contact header field, the proxy SHOULD use a secured transport protocol such as TLS [RFC5246] between proxy and UAs 🔐
4.4.3. UAS Behavior 💅
A UAS can receive an INVITE, UPDATE, or PRACK request (or another request that can initiate offer/answer exchanges) that contains a Policy-Contact header field with a list of policy server URIs. A UAS that gets a request like this needs to decide whether it wants to accept the session, knowing that policy servers are involved. If the Policy-Contact header contains multiple URIs, each with a different URI scheme and each containing an alt-uri parameter with identical values, then those URI schemes represent alternative policy channel mechanisms for getting the same policy. If the UAS accepts the session, the UAS MUST contact one URI out of each group of URIs with identical alt-uri parameter values to obtain the policy. The UAS MAY take the order of the alternative URIs as a hint about which one is preferred to use. The topmost URI in the list might be the one the proxy's domain prefers for getting the policy 🎯 The UAS MUST contact all policy server URIs in a Policy-Contact header field that are not part of a group of alternative URIs, and MUST contact one URI in each group of alternative URIs. The UAS MUST contact these policy server URIs in the order they were contained in the Policy-Contact header field, starting with the topmost value (i.e., the value that was inserted first).
If a UAS decides it doesn't want to accept a session because policy servers are involved, or because one of the session policies received from a policy server isn't acceptable, the UAS MUST reject the request with a 488 (Not Acceptable Here) response 🙅♀️
The UAS MAY accept a request and carry on setting up a session if it cannot set up a policy channel to the policy server, for example because the policy server is unreachable or returns an error condition that the UAS can't resolve (i.e., error conditions other than, for example, a 401 (Unauthorized) response). This is so a policy server failure doesn't stop a UA from communicating 🫶 Since this session might not be policy compliant without the policy subscription, it can be blocked by policy enforcement mechanisms if they're in place.
A UAS can receive a token from a policy server via the policy channel. Since the UAS doesn't create a Policy-ID header field, it can simply ignore this token 🙃
A UAS compliant to this specification MUST include a Supported header field with the option tag policy into responses to requests that can initiate an offer/answer exchange. The UAS MAY include this option tag in all responses. That way, a proxy that inserted the Policy-Contact header field can know the header field was understood by the UAS 🌸
4.4.4. Caching the Local Policy Server URI ✨
okay so a UAC is constantly going to need the policy server in its local domain before it sets up a session 🧚 so, to avoid sending that local policy server URI again every single time, a UA SHOULD keep a cache holding it 💾
a UA can pick up this URI from a Policy-Contact header field in a request, or from a 488 (Not Acceptable Here) response. it can also get the URI through configuration, like through the configuration framework [RFC6080] 🎀 and if a UA got a local policy server URI from configuration and then sees a different one in a Policy-Contact header field, the UA SHOULD overwrite the configured one with the most recent Policy-Contact URI 🔄 a policy server URI that came in a Policy-Contact header field expires if nobody refreshes it before it hits the maximum cached URI validity 🕰️ and the default maximum cached URI validity is 24 hours ⏳
domains are allowed to stop a UA from caching the local policy server URI 🙅♀️ this is handy when the policy server doesn't need to get involved in every session, or when the URI keeps changing from session to session. a proxy can mark that URI as "non-cacheable" 🏷️ and a UA MUST NOT cache a non-cacheable policy server URI, no exceptions bestie 💅 the UA SHOULD also remove the current URI from its cache when it gets a local policy server URI marked "non-cacheable", so it doesn't end up using an outdated one 🧹
the UA SHOULD NOT cache policy server URIs it got from proxies outside of the local domain 🌍 those policy servers probably won't matter for later sessions, since those can go to a totally different destination and cross different domains.
and the big one: the UA MUST NOT cache tokens it got from a policy server 🚫 a token is only valid for one request, so saving it for later is just not it 💀
4.4.5. Header Field Definition and Syntax 🎀
4.4.5.1. Policy-ID Header Field 🪪
the UAC puts the Policy-ID header field into INVITE, UPDATE, or PRACK requests (or any other request that can start an offer/answer exchange) 📨 it lists all the policy servers the UAC has contacted for that request, so everyone knows who's been involved 👀
the value of a Policy-ID header field is a policy server URI plus an optional token parameter 🔑 that token parameter holds a token the UA might have gotten from the policy server.
here's the ABNF for it, written according to [RFC5234] as an add-on to the ABNF for SIP in [RFC3261] 🧁
Policy-ID = "Policy-ID" HCOLON policyURI
*(COMMA policyURI)
policyURI = ( SIP-URI / SIPS-URI / absoluteURI )
[ SEMI token-param ] *( SEMI generic-param )
token-param = "token=" token4.4.5.2. Policy-Contact Header Field 📇
a proxy can slip the Policy-Contact header field into a 488 (Not Acceptable Here) response to INVITE, UPDATE, or PRACK requests (or other requests that start an offer/answer exchange) 🙌 its value is a policy server URI plus an optional "non-cacheable" header field parameter. the URI tells the UAC which policy server it needs to contact, and "non-cacheable" says that URI isn't meant to be cached by the UAC 🚫💾
a proxy can ALSO put the Policy-Contact header field into INVITE, UPDATE, and PRACK requests (or other requests that can start an offer/answer exchange) 🔀 in this case it holds an ordered list of policy server URIs the UAS needs to contact. the topmost one is contacted first, and new values get added at the end. so it's basically a FIFO queue, first in, first out 🚶♀️🚶♀️
here's the ABNF for it, also according to [RFC5234] and as an extension to the ABNF for SIP in [RFC3261] 💜
Policy-Contact = "Policy-Contact" HCOLON policyContact-info
*(COMMA policyContact-info)
policyContact-info = LAQUOT policyContact-uri RAQUOT
*( SEMI policyContact-param )
policyContact-uri = ( SIP-URI / SIPS-URI / absoluteURI )
policyContact-param = ( "non-cacheable" / policyContact-alt-uri
/ generic-param )
policyContact-alt-uri = "alt-uri" EQUAL hostnameokay so Tables 1 and 2 are extensions of Tables 2 and 3 in [RFC3261] 🗂️ the column "INF" is for the INFO method [RFC6086], "PRA" is for PRACK [RFC3262], "UPD" is for UPDATE [RFC3311], "SUB" is for SUBSCRIBE [RFC6665], "NOT" is for NOTIFY [RFC6665], "MSG" is for MESSAGE [RFC3428], "REF" is for REFER [RFC3515], and "PUB" is for PUBLISH [RFC3903] 📊
Header field where proxy ACK BYE CAN INV OPT REG UPD
_______________________________________________________________
Policy-ID R rd - - - c - - c
Policy-Contact R a - - - c - - c
Policy-Contact 488 a - - - c - - c
Table 1: Policy-ID and Policy-Contact Header Fields
Header field where proxy PRA PUB SUB NOT INF MSG REF
_______________________________________________________________
Policy-ID R rd c - - - - - -
Policy-Contact R a c - - - - - -
Policy-Contact 488 a c - - - - - -
Table 2: Policy-ID and Policy-Contact Header Fields4.5. Policy Channel 🛤️
the main job of the policy channel is letting a UA send info about the session it's trying to set up (that's the offer and the answer) to a policy server 📤 then the policy server sends back the session-specific policies, plus any updates to those policies later on 📥 it's giving teamwork 🫶
the Event Package for Session-Specific Policies [RFC6795] defines a policy channel mechanism based on SUBSCRIBE/NOTIFY [RFC6665] ✨ a UA that's compliant with this spec MUST support the Event Package for Session-Specific Policies [RFC6795] 👑 and the UA MUST use this event package to contact a policy server if the policy server URI is a SIP-URI or SIPS-URI 📞 a UA MAY also support other policy channel mechanisms if it wants 🌈
4.5.1. Creation and Management 🛠️
a UA finds out which policy servers matter for a session during the initial offer/answer exchange (check Section 4.4 for the details) 🔍 a UA that's compliant with this spec MUST set up a policy channel to each of the policy servers it discovered 📡 if the UA does NOT want a policy channel to one of them, it MUST cancel or reject the pending INVITE transaction for the session, or terminate the session if it's already in progress 🙅♀️ no half-measures here!
a UA MUST keep the policy channel to each discovered policy server alive for the whole lifetime of the session 🫡 the only exceptions are when the policy server closes the channel, or when the UA finds out that the policy server isn't relevant to the session anymore (more on that below) 👀
okay this part is a lot 😭 a UAC can get a 488 (Not Acceptable Here) response with a Policy-Contact header field carrying a new policy server URI, in reply to a mid-dialog request 🔁 that means the set of policy servers that matter for the current session has changed 🔀 when this happens, the UAC MUST retry sending the request as if it were the very first request in a dialog (so, without applying any policies except the ones from the local policy server) 🔄 that way the UAC can rediscover the list of policy servers for the session 🧭 this is needed because the UAC has no other way to know when to contact the newly found policy server, relative to the existing ones, or whether any existing ones can be skipped now 🤷♀️ the UAC MUST set up a policy channel to each new policy server 📡 the UAC SHOULD close policy channels to any policy servers that aren't listed anymore 🧹 if those channels stay open, the UAC could receive policies that don't apply to the session anymore 🙈 and the UAC MUST contact policy servers in the order they were discovered in the most recent request 🔢
if a UAS gets a mid-dialog request with a Policy-Contact header field whose list of policy server URIs is different from the list it already has policy channels to, then the UAS MUST set up a policy channel to all the new policy servers and contact them 📬 the UAS SHOULD close policy channels to servers that aren't listed anymore 🧼 if those channels stay open, the UAS could also receive policies that don't apply to the session anymore 😬 and the UAS MUST use policy servers in the order they were contained in the most recent Policy-Contact header field 🎯
last one, and it's a must-do 💅 a UA MUST tell the policy server when a session is terminated (for example, when the UA has either sent or received a BYE) through the policy channel 📴 the exception is if a policy server says through the policy channel that it doesn't need to be contacted at the end of the session 🙅 this is what lets the policy server free up all the resources it allocated for this session 🧹✨
4.5.2. Contacting the Policy Server 💌
Bestie, listen up 👂 A UA MUST contact all the policy servers it has set up a policy channel with before it sends or after it receives a mid-dialog request. It MUST reach them in the order they were most recently discovered in. 🗺️✨
If a UA gets a SIP message with an offer or answer in it, it SHOULD fully process that message first (e.g., according to [RFC3261]) before it contacts the policy server. SIP processing covers stuff like updating dialog state and timers and creating ACK or PRACK requests when needed. This makes sure that talking to a policy server doesn't mess with SIP processing or timing (like accidentally making timers expire 😱). So a UAC that got a response to an INVITE would normally finish handling it, including sending the ACK, before it contacts the policy server. There's one big exception, and it's coming up in the next paragraph 👀
Sometimes a UA needs the offer/answer from a SIP message to build an ACK or PRACK for that same message. That means it has to use the offer/answer before it's done with SIP handling for that message. For example, a UAC that got an offer in the response to an INVITE has to apply policies to the offer and the answer before it can send the answer in an ACK. In these cases, a UA SHOULD contact the policy server even while it's still processing the SIP message. So a UA that got an offer in an INVITE response would normally contact the policy server and apply session policies before sending the answer in the ACK. Iconic 💅
Note: this assumes the policy server can always answer a policy request right away and doesn't need someone to manually create a policy. That's true for most policy servers 🙌 But if a policy server can't hand back a policy right away, it can return a policy that temporarily denies the session and then update it once the real decision is ready. If the policy server is slow to respond, the UA's ACK gets delayed, and that could trigger retransmissions of the INVITE response (also see the recommendations for Flow I in [RFC3725]) 😬
Things get extra messy when multiple policy servers hand policies to the same UA 🌀 A policy from one server can include info the other servers need to know. For example, two policy servers might each want a media intermediary that rewrites the IP addresses and ports of media streams. For media to pass through both intermediaries, each one needs to know the IP address and port where the other is expecting the stream to arrive. If media flows in both directions, each intermediary needs the IP addresses and ports of the other one. Wild, right? 🦋
UACs usually contact a policy server twice during an offer/answer exchange (unless a policy server says it only needs one contact). So when multiple policy servers give policies to a single UAC, no extra steps are needed in most cases 🎀 A UAS, though, usually contacts each policy server only once (see Figure 4). If a session policy from one server requires info to be shared between several servers, and the UAS gets policies from more than one server, then the UAS MUST contact all policy servers a second time after it has contacted all of them the first time. Whether a second round is needed depends on the type of info the policy server returned. A data format for session policies (e.g., [RFC6796]) has to explicitly state whether a second round is needed for a particular data element. If a UA receives an element like that, it knows it's expected to contact the policy servers a second time. If such a data element gets modified during a mid-call offer/answer exchange and multiple policy servers are providing policies to a UA, then all UAs MUST contact policy servers in a first and second round. There's an example call flow in Appendix B.3 📖
A UA that supports session-specific policies compliant with this specification MUST support the User Agent Profile Data Set for Media Policy [RFC6796] as its data format for session policies. No skipping that one, bestie 🫶
4.5.3. Using Session Policies 🎬
A UA MUST disclose the session description(s) for the current session to the policy servers through the policy channel. The UA MUST apply the session policies it receives to the offer and, if one is received, to the answer before it uses the offer/answer. If these policies are unacceptable, the UA MUST NOT continue with the session. That means the UA MUST cancel or reject a pending INVITE transaction for the session, or terminate the session if it's already in progress. If the UA receives an unacceptable policy in an INVITE response, the UA MUST complete the INVITE transaction and then terminate the session. Not it being dramatic, it's literally the rules 💀
When a UA gets a notification about a change in the current policies, the UA MUST apply the updated policies to the current session, or the UA MUST terminate the session. If the policy update changes the session description, the UA needs to renegotiate the modified session description with its peer UA, for example using a re-INVITE or UPDATE request. Like, if a policy update disallows video and video is part of the current session description, the UA will need to create a new session description offer without video. After the peer UA gets this offer, it knows video can't be used anymore and responds with the matching answer 🎥🚫
5. Security Considerations 🛡️
Policy enforcement can stop a UA from communicating with another UA if the UAs aren't aware of the policies being enforced. So enforcement without policy signaling can cause a denial-of-service condition for UAs 😭 This specification gives intermediaries a way to signal the policies they enforce to UAs, so UAs can establish sessions that conform to policy enforcement and pass through it.
Session policies can seriously change how a UA behaves, and an attacker could use them to compromise a UA 🚨 For example, session policies could stop a UA from setting up a session at all (e.g., by setting the available bandwidth to zero). A policy like that can be submitted to the UA during a session, which makes the UA terminate the session.
A UA sends session information to a policy server for session-specific policies. That info can contain sensitive data the user doesn't want an eavesdropper or an unauthorized policy server to see 🙈 It works the other way too: session policies can contain sensitive info about the network or service level agreements that the service provider doesn't want exposed to an eavesdropper or an unauthorized UA.
It's important to secure the communication between the proxy and the UA (for session-specific policies), as well as between the UA and the policy server. Four distinct attributes need to be protected:
- integrity of the policy server URI (for session-specific policies),
- authentication of the policy server and, if needed, the user agent,
- confidentiality of the messages exchanged between the user agent and the policy server and
- ensuring that private information is not exchanged between the two parties, even over a confidentiality-assured and authenticated session.
To protect the integrity of the policy server URI, a UA SHOULD use a secured transport protocol such as TLS [RFC5246] between proxies and the UA. This matters a lot because an attacker could intercept SIP messages between the UA and the proxy and strip out the policy header fields needed for session-specific policies. That would wreck the rendezvous between the UA and the policy server, and since the UA wouldn't contact the policy server, it could stop the UA from setting up a session at all 😵
Instead of stripping out a policy server URI, an attacker could also change it to point the UA at a compromised policy server. It is RECOMMENDED that a UA authenticate policy servers to keep that attack from being effective 🔒
It is RECOMMENDED that the UA only accept session-independent policies from trustworthy policy servers, because those policies affect all sessions of a UA 👑 A list of trustworthy session-independent policy servers can be provided to the UA through configuration. Since any proxy on a path can affect SIP messages, and session-specific policies only apply to a single session, a UA MAY choose to accept session-specific policies from other policy servers as well.
Policy servers SHOULD authenticate UAs to protect the information contained in a session policy. But a policy server can also frequently run into UAs it can't authenticate. In those cases, the policy server MAY provide a generic policy that doesn't reveal sensitive information to those UAs 🧚
It is RECOMMENDED that administrators use SIPS URIs as policy server URIs, so that subscriptions to session policies get transmitted over TLS 🌈
The above security attributes are important for protecting the communication between the UA and the policy server. This document doesn't define the protocol used for that communication. It just refers to other specifications for this purpose, and the security considerations of those specifications need to address the aspects above 💜
6. IANA Considerations 📋
6.1. Registration of the "Policy-ID" Header Field
- Name of Header Field:
Policy-ID - Short form:
none - Normative description: Section 4.4.5 of this document
6.2. Registration of the "Policy-Contact" Header Field
- Name of Header Field:
Policy-Contact - Short form:
none - Normative description: Section 4.4.5 of this document
6.3. Registration of the "non-cacheable" Policy-Contact Header Field Parameter 🍓
- Registry Name: Header Field Parameters and Parameter Values
- Reference: [RFC3968]
- Registry:
Header Field Parameter Name Predefined Reference
Values
_____________________________________________________________________
Policy-Contact non-cacheable Yes this document6.4. Registration of the "policy" SIP Option Tag ✨
Okay, bestie, this one's the SIP option tag registration, and it follows the rules from Section 27.1 of [RFC3261]. 🎀 The tag we're registering is "policy", and it gets its own little row in the "Option Tags" section of the SIP Parameter Registry. 💅
+------------+------------------------------------------+-----------+
| Name | Description | Reference |
+------------+------------------------------------------+-----------+
| policy | This option tag is used to indicate that | this |
| | a UA can process policy server URIs for | document |
| | and subscribe to session-specific | |
| | policies. | |
+------------+------------------------------------------+-----------+Here's the full registration info, all in one place:
Name of option: policy
Description: Support for the Policy-Contact and Policy-ID header
fields.
SIP header fields defined: Policy-Contact, Policy-ID
Normative description: This document7. References 📚
7.1. Normative References 🔒
[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[RFC3261]Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.[RFC3262]Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.[RFC3264]Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.[RFC3311]Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.[RFC3968]Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004.[RFC5234]Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.[RFC6080]Petrie, D. and S. Channabasappa, "A Framework for Session Initiation Protocol User Agent Profile Delivery", RFC 6080, March 2011.[RFC6665]Roach, A., "SIP-Specific Event Notification", RFC 6665, July 2012.[RFC6795]Hilt, V. and G. Camarillo, "A Session Initiation Protocol (SIP) Event Package for Session-Specific Policies", RFC 6795, December 2012.[RFC6796]Hilt, V., Camarillo, G., Rosenberg, J., and D. Worley, "A User Agent Profile Data Set for Media Policy", RFC 6796, December 2012.
7.2. Informative References 🧠
[RFC3428]Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.[RFC3515]Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.[RFC3725]Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.[RFC3903]Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.[RFC3986]Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.[RFC4566]Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.[RFC5246]Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.[RFC6086]Holmberg, C., Burger, E., and H. Kaplan, "Session Initiation Protocol (SIP) INFO Method and Package Framework", RFC 6086, January 2011.
Appendix A. Acknowledgements 💖
A huge thank-you to Allison Mankin, Andrew Allen, Cullen Jennings and Vijay Gurbani for their contributions to this document. 🫶 Thanks also to Roni Even, Bob Penfield, Mary Barnes, Shida Schubert, Keith Drage, Lisa Dusseault, Tim Polk and Pasi Eronen for their reviews and suggestions. 🌸
Appendix B. Session-Specific Policies - Call Flows 🦋
Okay, now for the fun part, the call flows! 🧚 These show how session-specific policies work overall, including the policy channel protocol from "A Session Initiation Protocol (SIP) Event Package for Session-Specific Policies" [RFC6795].
Here's the abbreviation cheat sheet:
o: offer
o': offer modified by a policy
po: offer policy
a: answer
a': answer modified by a policy
pa: answer policy
ps uri: policy server URI (in Policy-Contact header field)
ps id: policy server id (in Policy-ID header field)B.1. Offer in Invite 📞
UA A P A PS A PS B P B UA B
| | | | | |
|(1) INV <o> | | | |
|-------->| | | | |
|(2) 488 <ps uri> | | | |
|<--------| | | | |
|(3) ACK | | | | |
|-------->| | | | |
|(4) SUBSCRIBE <o> | | | |
|------------------>| | | |
|(5) 200 OK | | | |
|<------------------| | | |
|(6) NOTIFY <po> | | | |
|<------------------| | | |
|(7) 200 OK | | | |
|------------------>| | | |
|(8) INV <ps id, o'>| | | |
|-------->| | | | |
| |(9) INV <o'> | | |
| |---------------------------->| |
| | | | |(10) INV <o', ps uri>
| | | | |-------->|
| | | |(11) SUBSCRIBE <o', a>
| | | |<------------------|
| | | |(12) 200 OK |
| | | |------------------>|
| | | |(13) NOTIFY <po, pa>
| | | |------------------>|
| | | |(14) 200 OK |
| | | |<------------------|
| | | | |(15) 200 OK <a'>
| | | | |<--------|
| |(16) 200 OK <a'> | | |
| |<----------------------------| |
|(17) 200 OK <a'> | | | |
|<--------| | | | |
|(18) ACK | | | | |
|------------------------------------------------>|
|(19) SUBSCRIBE <o', a'> | | |
|------------------>| | | |
|(20) 200 OK | | | |
|<------------------| | | |
|(21) NOTIFY <po, pa> | | |
|<------------------| | | |
|(22) 200 OK | | | |
|------------------>| | | |
| | | | | |
| | | | | |B.2. Offer in Response 🌈
UA A P A PS A PS B P B UA B
| | | | | |
|(1) INV | | | | |
|-------->| | | | |
|(2) 488 <ps uri> | | | |
|<--------| | | | |
|(3) ACK | | | | |
|-------->| | | | |
|(4) SUBSCRIBE | | | |
|------------------>| | | |
|(5) 200 OK | | | |
|<------------------| | | |
|(6) NOTIFY | | | |
|<------------------| | | |
|(7) 200 OK | | | |
|------------------>| | | |
|(8) INV <ps id> | | | |
|-------->| | | | |
| |(9) INV | | | |
| |---------------------------->| |
| | | | |(10) INV <ps uri>
| | | | |-------->|
| | | |(11) SUBSCRIBE <o> |
| | | |<------------------|
| | | |(12) 200 OK |
| | | |------------------>|
| | | |(13) NOTIFY <po> |
| | | |------------------>|
| | | |(14) 200 OK |
| | | |<------------------|
| | | | |(15) 200 OK <o'>
| | | | |<--------|
| |(16) 200 OK <o'> | | |
| |<----------------------------| |
|(17) 200 OK <o'> | | | |
|<--------| | | | |
|(18) SUBSCRIBE <o', a> | | |
|------------------>| | | |
|(19) 200 OK | | | |
|<------------------| | | |
|(20) NOTIFY <po, pa> | | |
|<------------------| | | |
|(21) 200 OK | | | |
|------------------>| | | |
|(22) ACK <a'> | | | |
|------------------------------------------------>|
| | | |(23) SUBSCRIBE <o', a'>
| | | |<------------------|
| | | |(24) 200 OK |
| | | |------------------>|
| | | |(25) NOTIFY <po, pa>
| | | |------------------>|
| | | |(26) 200 OK |
| | | |<------------------|
| | | | | |
| | | | | |B.3. Multiple Policy Servers for the UAS
okay bestie, this is the big one 🎀 in B.3 the INVITE from UA A bounces through two policy servers (PS A and PS B) before it gets to UA B, and every hop gets its own SUBSCRIBE, NOTIFY, and 200 OK. it's giving choreography 💃 read it top to bottom and you'll see the whole group chat happen in order ✨
UA A P A PS A PS B P B UA B
| | | | | |
| | | | | |
| | | | | |
|(1) INV <o> | | | |
|-------->| | | | |
| |(2) INV <o, uri PSA> | |
| |---------------------------->| |
| | | | |(3) INV <o, uri PSA, uri PSB>
| | | | |-------->|
| | |(4) SUBSCRIBE <o, a> |
| | |<----------------------------|
| | |(5) 200 OK | |
| | |---------------------------->|
| | |(6) NOTIFY <po, pa>| |
| | |---------------------------->|
| | |(7) 200 OK | |
| | |<----------------------------|
| | | |(8) SUBSCRIBE <o', a'>
| | | |<------------------|
| | | |(9) 200 OK |
| | | |------------------>|
| | | |(10) NOTIFY <po, pa>
| | | |------------------>|
| | | |(11) 200 OK |
| | | |<------------------|
| | |(12) SUBSCRIBE <o", a"> |
| | |<----------------------------|
| | |(13) 200 OK | |
| | |---------------------------->|
| | |(14) NOTIFY <po, pa> |
| | |---------------------------->|
| | |(15) 200 OK | |
| | |<----------------------------|
| | | |(16) SUBSCRIBE <o", a">
| | | |<------------------|
| | | |(17) 200 OK |
| | | |------------------>|
| | | |(18) NOTIFY <po, pa>
| | | |------------------>|
| | | |(19) 200 OK |
| | | |<------------------|
| | | | |(20) 200 OK <a">
| | | | |<--------|
| |(21) 200 OK <a"> | | |
| |<----------------------------| |
|(22) 200 OK <a"> | | | |
|<--------| | | | |
|(23) ACK | | | | |
|------------------------------------------------>|
| | | | | |
| | | | | |Authors' Addresses ✨
these are the people who wrote it, so here's where to find them 🦋
Volker Hilt
Bell Labs/Alcatel-Lucent
Lorenzstrasse 10
70435 Stuttgart
Germany
EMail: volker.hilt@bell-labs.comGonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: Gonzalo.Camarillo@ericsson.comJonathan Rosenberg
jdrosen.net
Monmouth, NJ
USA
EMail: jdrosen@jdrosen.netand that's the whole spec, babe 💖
📦 where this page comes from
- ietf: rfc6794 2012-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms