idnits 2.17.1 draft-ietf-sip-session-policy-framework-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1294. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1305. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1312. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1318. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 952 has weird spacing: '... where prox...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 9, 2007) is 6279 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-08) exists of draft-ietf-sipping-policy-package-03 == Outdated reference: A later version (-16) exists of draft-ietf-sipping-media-policy-dataset-02 == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-10 -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '7') (Obsoleted by RFC 4566) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group V. Hilt 3 Internet-Draft Bell Labs/Alcatel-Lucent 4 Expires: August 13, 2007 G. Camarillo 5 Ericsson 6 J. Rosenberg 7 Cisco Systems 8 February 9, 2007 10 A Framework for Session Initiation Protocol (SIP) Session Policies 11 draft-ietf-sip-session-policy-framework-01 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 13, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 Proxy servers play a central role as an intermediary in the Session 45 Initiation Protocol (SIP) as they define and impact policies on call 46 routing, rendezvous, and other call features. This document 47 specifies a framework for SIP session policies that provides a 48 standard mechanism by which a proxy can define or influence policies 49 on sessions, such as the codecs or media types to be used. It 50 defines a model, an overall architecture and new protocol mechanisms 51 for session policies. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Session-Independent Policies . . . . . . . . . . . . . . . . . 5 58 3.1. Architecture and Overview . . . . . . . . . . . . . . . . 5 59 3.2. Policy Subscription . . . . . . . . . . . . . . . . . . . 6 60 4. Session-Specific Policies . . . . . . . . . . . . . . . . . . 7 61 4.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 7 62 4.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 4.3.1. Offer in Request . . . . . . . . . . . . . . . . . . . 10 65 4.3.2. Offer in Response . . . . . . . . . . . . . . . . . . 13 66 4.4. UA/Policy Server Rendezvous . . . . . . . . . . . . . . . 14 67 4.4.1. UAC Behavior . . . . . . . . . . . . . . . . . . . . . 14 68 4.4.2. Proxy Behavior . . . . . . . . . . . . . . . . . . . . 17 69 4.4.3. UAS Behavior . . . . . . . . . . . . . . . . . . . . . 18 70 4.4.4. Caching the Local Policy Server URI . . . . . . . . . 18 71 4.4.5. Storing Session Policy Server URIs . . . . . . . . . . 19 72 4.4.6. Contacting the Policy Server . . . . . . . . . . . . . 19 73 4.4.7. Header Definition and Syntax . . . . . . . . . . . . . 20 74 4.5. Policy Channel . . . . . . . . . . . . . . . . . . . . . . 22 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 77 6.1. Registration of the "Policy-Id" Header . . . . . . . . . . 24 78 6.2. Registration of the "Policy-Contact" Header . . . . . . . 24 79 6.3. Registration of the "policy" SIP Option-Tag . . . . . . . 24 80 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 24 81 Appendix B. Session-Specific Policies - Call Flows . . . . . . . 25 82 B.1. Offer in Invite . . . . . . . . . . . . . . . . . . . . . 25 83 B.2. Offer in Response . . . . . . . . . . . . . . . . . . . . 27 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 85 7.1. Normative References . . . . . . . . . . . . . . . . . . . 28 86 7.2. Informative References . . . . . . . . . . . . . . . . . . 28 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 88 Intellectual Property and Copyright Statements . . . . . . . . . . 30 90 1. Introduction 92 The Session Initiation Protocol (SIP) [6] is a signaling protocol for 93 creating, modifying and terminating multimedia sessions. A central 94 element in SIP is the proxy server. Proxy servers are intermediaries 95 that are responsible for request routing, rendezvous, authentication 96 and authorization, mobility, and other signaling services. However, 97 proxies are divorced from the actual sessions - audio, video, and 98 messaging - that SIP establishes. Details of the sessions are 99 carried in the payload of SIP messages, and are usually described 100 with the Session Description Protocol (SDP) [7]. Indeed, SIP 101 provides end-to-end encryption features using S/MIME, so that all 102 information about the sessions can be hidden from eavesdroppers and 103 proxies alike. 105 However, experience has shown that there is a need for SIP 106 intermediaries to impact aspects of a session. For example, SIP may 107 be used in a wireless network, which has limited resources for media 108 traffic. During periods of high activity, the wireless network 109 provider wants to restrict the amount of bandwidth available to each 110 individual user. With session policies, an intermediary in the 111 wireless network can inform the user agent about the bandwidth it can 112 currently count on. This information enables the user agent to make 113 an informed decision about the number of streams, the media types, 114 and the codecs it can successfully use in a session. Similarly, a 115 network provider may have a service level agreement with a user that 116 defines the set of media types a user can use. With session 117 policies, the network can convey the current set of policies to user 118 agents, enabling them to set up sessions without inadvertently 119 violating any of the network policies. 121 In another example, a SIP user agent is using a network which is 122 connected to the public Internet through a firewall or a network 123 border device. The network provider would like to tell the user 124 agent that it needs to send its media streams to a specific IP 125 address and port on the firewall or border device to reach the public 126 Internet. Knowing this policy enables the user agent to set up 127 sessions across the firewall or the network border. In contrast to 128 other methods for inserting a media intermediary, the use of session 129 policies does not require the inspection or modification of SIP 130 message bodies. 132 Domains often enforce the session policies they have in place. For 133 example, a domain might have a policy that disallows the use of video 134 and may enforce this policy by dropping all packets that contain a 135 video encoding. Unfortunately, enforcement mechanisms usually do not 136 inform the user about the policies they are enforcing. Instead, they 137 silently keep the user from doing anything against them. This may 138 lead to a malfunctioning of devices that is incomprehensible to the 139 user. With session policies, the user knows about the current 140 network policies and can set up policy-compliant sessions or simply 141 connect to a domain with less stringent policies. Thus, session 142 policies provide an important combination of consent coupled with 143 enforcement. That is, the user becomes aware of the policy and needs 144 to act on it, but the provider still retains the right to enforce the 145 policy. 147 Two types of session policies exist: session-specific policies and 148 session-independent policies. Session-specific policies are policies 149 that are created for one particular session, based on the session 150 description of this session. They enable a network intermediary to 151 examine the session description a UA is proposing and to return a 152 policy specifically for this session description. For example, an 153 intermediary could open pinholes in a firewall/NAT for each media 154 stream in a session and return a policy that replaces the internal IP 155 addresses and ports with external ones. Since session-specific 156 policies are tailored to a session, they only apply to the session 157 they are created for. Session-specific policies are created on a 158 session-by-session basis at the time the session is established. 160 Session-independent policies on the other hand are policies that are 161 created independent of a session and generally apply to all SIP 162 sessions set up by a user agent. A session-independent policy can, 163 for example, be used to inform user agents about an existing 164 bandwidth limit or media type restrictions. Since these policies are 165 not based on a specific session description, they can be created 166 independent of an attempt to set up a session and only need to be 167 conveyed to the user agent when it initializes (e.g. at the time the 168 device is powered on) and when the policies are changed. 170 This specification defines a framework for SIP session policies. It 171 specifies a model, the overall architecture and new protocol 172 mechanisms that are needed for session-independent and session- 173 specific policies. 175 2. Terminology 177 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 178 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 179 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 180 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 181 compliant implementations. 183 3. Session-Independent Policies 185 Session-independent policies are policies that are created 186 independent of a session and generally apply to all sessions a user 187 agent is setting up. They typically remain stable for a longer 188 period of time and apply to any session set up while they are valid. 189 However, session-independent policies may also change over time. For 190 example, a policy that defines a bandwidth limit for a user may 191 change during the day, defining a lower limit during peak hours and 192 allow more bandwidth off-peak. 194 3.1. Architecture and Overview 196 +-------------+ 197 /------| policy | 198 +----+ / | server 1 | 199 | |---/ +-------------+ 200 | UA | ... 201 | |---\ +-------------+ 202 +----+ \ | policy | 203 \------| server n | 204 +-------------+ 206 Figure 1 208 A SIP UA may receive session-independent policies from one or more 209 policy servers. In a typical configuration, a UA receives session- 210 independent policies from a policy server in the access or local 211 network domain (i.e. the domain from which the UA receives IP 212 service) and possibly the home network domain (i.e. the domain the UA 213 registers at). The local network may have policies that support the 214 access network infrastructure. For example, in a wireless network 215 where bandwidth is scarce, a provider may restrict the bandwidth 216 available to an individual user. The home network may have policies 217 that are needed to support services or policies that reflect the 218 service level agreement with the user. Thus, in most cases, a UA 219 will receive session-independent policies from one or two policy 220 servers. 222 Setting up session-independent policies involves the following steps: 224 1. A user agent requests session-independent policies from the 225 policy servers in the local network and home domain. A user 226 agent typically requests these policies when it starts up or 227 connects to a new network domain. 229 2. The policy server selects the policies that apply to this user 230 agent. The policy server may have general policies that apply to 231 all users or maintain separate policies for each individual user. 232 The selected policies are returned to the user agent. 233 3. The policy server may update the policies, for example, when 234 network conditions change. 236 3.2. Policy Subscription 238 A UA requests session-independent policies by subscribing to session- 239 independent policies on the policy server in a domain. Subscriptions 240 to session-independent policies are established using the "ua- 241 profile" event package defined in the Framework for SIP User Agent 242 Profile Delivery [4]. 244 The "ua-profile" event package [4] provides a mechanism to discover 245 policy servers in the local network and the home domain. The "local- 246 network" profile-type enables a UA to discover a policy server in the 247 local domain. The "user" profile type enables the discovery of a 248 policy server in the home domain. A UA compliant to this 249 specification SHOULD attempt to discover and subscribe to the policy 250 servers in these two domains. 252 A UA SHOULD (re-)subscribe to session-independent policies when the 253 following events occur: 255 o The UA registers a new address-of-record (AoR) or removes a AoR 256 from the set of AoRs it has registered. In these cases, the UA 257 SHOULD establish subscriptions for each new AoR using the "user" 258 and the "local-network" profile-types. The UA SHOULD terminate 259 all subscriptions for AoRs it has removed. 260 o The UA changes the domain it is connected to. The UA SHOULD 261 terminate all existing subscriptions for the "local-network" 262 profile-type. It SHOULD then create a new subscription for each 263 AoR using the "local-network" profile-type. This way, the UA 264 stops receiving policies from the previous local domain and starts 265 to receive the policies of the new local domain. The UA does not 266 need to change the subscriptions for "user" profiles. 268 If a subscriber is unable to establish a subscription, it SHOULD NOT 269 attempt to re-try this subscription, unless one of the above events 270 occurs again. This is to limit the number of SUBSCRIBE requests sent 271 within domains that do not support session-independent policies. 273 A UA compliant to this specification MUST support the User Agent 274 Profile Data Set for Media Policy [3]. To indicate that the UA wants 275 to receive session-independent policies, it includes the MIME type 276 "application/session-policy+xml" in the Accept header of a SUBSCRIBE 277 request. 279 A policy server MAY send a notification to the subscriber every time 280 the session-independent policies covered by the subscription change. 281 The definition of what causes a policy to change is at the discretion 282 of the administrator. A change in the policy may be triggered, for 283 example, by a change in the network status, by the change in the time 284 of day or by an update of the service level agreement with the 285 customer. The session-independent policies contained in a 286 notification MUST represent a complete session-independent policy. 287 Deltas to previous policies or partial policies are not supported. 289 4. Session-Specific Policies 291 Session-specific policies are policies that are created specifically 292 for one particular session of a UA. Thus, session-specific policies 293 will typically be different for different sessions. The session- 294 specific policies for a session may change during the course of the 295 session. For example, a user may run out of credit during a session, 296 which will cause the network to disallow the transmission all media 297 streams from this point on. 299 4.1. Architecture 301 domain 1 302 +-----------+ 303 /------| proxy |----... 304 +----+ / +-----------+ 305 | |---/ +-----------+ 306 | | | policy | 307 | UA |============| server | 308 | | +-----------+ 309 | |**** +-----------+ 310 +----+ * | policy | 311 *******|enforcement|****... 312 +-----------+ 314 --- SIP Signaling 315 === Policy Channel 316 *** Media 318 Figure 2 320 The following entities are needed for session-specific policies (see 321 Figure 2): a user agent (UA), a proxy, a policy server and possibly a 322 policy enforcement entity. 324 The role of the proxy is to provide a rendezvous mechanism for UAs 325 and policy servers. It ensures that each UA has the URI of the 326 policy server in its domain and knows where to retrieve policies 327 from. The proxy conveys the policy server URI to UAs in case they 328 have not yet received it (e.g. in a previous call or through other 329 means such as configuration). The proxy does not deliver the actual 330 policies to UAs. 332 The policy server is a separate logical entity that may be physically 333 co-located with the proxy. The role of the policy server is to 334 deliver session policies to UAs. The policy server receives session 335 information from the UA, uses this information to determine the 336 policies that apply to the session and returns these policies to the 337 UA. The mechanism for generating policies (i.e. making policy 338 decisions) is outside of the scope of this specification. A policy 339 server may, for example, query an external entity to get policies or 340 it may directly incorporate a policy decision point and generate 341 policies locally. 343 A UA receives the URI of a policy server from a proxy. It uses this 344 URI to contact the policy server. It provides information about the 345 current session to the policy server and receives session policies in 346 response. The UA may also receive policy updates from the policy 347 server during the course of a session. 349 A network may have a policy enforcement infrastructure in place. 350 However, this specification does not make any assumptions about the 351 enforcement of session policies and the mechanisms defined here are 352 orthogonal a policy enforcement infrastructure. Their goal is to 353 provide a mechanism to convey session information to a policy server 354 and to return the policies that apply to a session to the UA. 356 In principle, each domain that is traversed by SIP signaling messages 357 can define session-specific policies for a session. Each domain 358 needs to run a policy server and a proxy that is able to rendezvous a 359 UA with the policy server (as shown in Figure 2). However, it is 360 expected that session-specific policies will often only be provided 361 by the local domain of the user agent. 363 4.2. Overview 365 The protocol defined in this specification clearly separates SIP 366 signaling and the exchange of policies. SIP signaling is only used 367 to rendezvous the UA with the policy server. From this point on, UA 368 and policy server communicate directly with each other over a 369 separate policy channel. This is opposed to a piggyback model, where 370 the exchange of policy information between endpoint and a policy 371 server in the network is piggybacked onto the SIP signaling messages 372 that are exchanged between endpoints. 374 The main advantage of using a separate policy channel is that it 375 decouples the exchange of signaling messages between endpoints from 376 the exchange of policies between endpoint and policy server. This 377 decoupling has a number of desirable properties. It enables the use 378 of separate encryption mechanisms on the signaling path to secure the 379 communication between endpoints, and on the policy channel to secure 380 the communication between endpoint and policy server. Policies can 381 be submitted directly from the policy server to the endpoint and 382 never travel along the signaling path, possibly crossing many 383 domains. Endpoints set up a separate policy channel to each policy 384 server and can specifically decide which information they want to 385 disclose to which policy server. Finally, policy servers do not need 386 to rely on a SIP signaling message flowing by to send policies or 387 policy updates to an endpoint. A policy server can use the policy 388 channel at any time to update session policies as needed. A 389 disadvantage of the separate channel model is that it requires 390 additional messages for the exchange of policy information. 392 Following this model, signaling for session-specific policies 393 involves the following two fundamental tasks: 395 1. UA/policy server rendezvous: a UA setting up a session needs to 396 be able to discover the policy servers that are relevant to this 397 session. 398 2. Policy channel: once the UA has discovered the relevant policy 399 servers for a session, it needs to connect to these servers, 400 disclose session information and retrieve the policies that apply 401 to this session. 403 The setting up session-specific policies over the policy channel 404 involves the following steps: 406 1. A user agent submits information about the session it is trying 407 to establish to the policy server and asks whether a session 408 using these parameters is permissible. 409 2. The policy server generates a policy decision for this session 410 and returns the decision to the user agent. Possible policy 411 decisions are (1) to deny the session, (2) to propose changes to 412 the session parameters with which the session would be 413 acceptable, or (3) to accept the session as it was proposed. 414 3. The policy server can update the policy decision at a later time. 415 A policy decision update can, for example, propose additional 416 changes to the session (e.g. change the available bandwidth) or 417 deny a previously accepted session (i.e. disallow the 418 continuation of a session). 420 In many cases, the mechanism for session-specific policies will be 421 used to disclose session information and return session policies. 422 However, some scenarios may only involve the disclosure of session 423 information to a network intermediary. If an intermediary does not 424 intend to return a policy, it can simply accept the session as it was 425 proposed. Similarly, some session-specific policies only apply to 426 the offer (and therefore only require the disclosure of the offer) 427 whereas others apply to offer and answer. Both types of policies are 428 supported by session-specific policy mechanism. 430 4.3. Examples 432 This section provides two examples to illustrate the overall 433 operation of session-specific policies. The call flows depict the 434 rendezvous mechanism between UA and policy server and indicate the 435 points at which the UA exchanges policy information with the policy 436 server. 438 The example is based on the following scenario: there are two domains 439 (domain A and domain B), which both have session-specific policies 440 for the UAs in their domain. Both domains do not provide policies to 441 the UAs outside of their domain. The two domains have a proxy (P A 442 and P B) and a policy server (PS A and PS B). The policies in both 443 domains involve the session description offer and answer. 445 4.3.1. Offer in Request 447 The first call flow shown in Figure 3 depicts an INVITE transaction 448 with the offer in the request. It is assumed that this is the first 449 INVITE request the UAC creates in this domain and that it therefore 450 does not have previous knowledge about the policy server URIs in this 451 domain. 453 (1) UA A sends an INVITE to proxy P A. P A knows that policies apply 454 to this session and (2) returns a 488 to UA A. P A includes the URI 455 of PS A in the 488 response. This step is needed since the UAC has 456 no prior knowledge about the URI of PS A. (3) UA A uses the URI to 457 contact PS A, discloses the session description offer to PS A and (4) 458 receives policies for the offer. (5) UA A reformulates the INVITE 459 request under consideration of the received policies and includes a 460 Policy-Id header to indicate that it has already contacted PS A. P A 461 does not reject the INVITE this time and removes the Policy-Id header 462 when forwarding the INVITE. P B adds a Policy-Contact header 463 containing the URI of PS B. (6) UA B uses this URI to contact PS B 464 and discloses the offer and the answer it is about to send. (7) UA B 465 receives policies from PS B and applies them to the offer and answer 466 respectively. (8) UA B returns the updated answer in the 200 OK. (9) 467 UA A contacts PS A with the answer and (10) retrieves answer policies 468 from PS A. 470 UA A P A P B UA B 471 | | | | 472 | INVITE offer | | | 473 |---------------->| | | (1) 474 | 488 | | | 475 | + Policy-Contact| | | 476 |<----------------| | | (2) 477 | ACK | | | 478 |---------------->| | | 479 | | PS A | | 480 | | | | 481 | PolicyChannel | | | 482 | + InfoOffer | | | 483 |------------------->| | | (3) 484 | PolicyChannel | | | 485 | + PolicyOffer | | | 486 |<-------------------| | | (4) 487 | | | | 488 | | | | 489 | INVITE offer' | INVITE offer' | INVITE offer | 490 | + Policy-Id | | + Policy-Contact| 491 |---------------->|--------------->|---------------->| (5) 492 | | | | 493 | | PS B | | 494 | | | | 495 | | | PolicyChannel | 496 | | | + InfoOffer | 497 | | | + InfoAnswer | 498 | | |<-------------------| (6) 499 | | | PolicyChannel | 500 | | | + PolicyOffer | 501 | | | + PolicyAnswer | 502 | | |------------------->| (7) 503 | | | | 504 | | | | 505 | OK answer | OK answer | OK answer | 506 |<----------------|<---------------|<----------------| (8) 507 | ACK | 508 |--------------------------------------------------->| 509 | | | | 510 | | | | 511 | PolicyChannel | | | 512 | + InfoAnswer | | | 513 |------------------->| | | (9) 514 | PolicyChannel | | | 515 | + PolicyAnswer | | | 516 |<-------------------| | | (10) 517 | | | | 518 Figure 3 520 4.3.2. Offer in Response 522 The call flow shown in Figure 4 depicts an INVITE transaction with 523 the offer in the response. 525 (1) UA A sends an INVITE without an offer to proxy P A and (2) P A 526 returns a 488 response containing the URI of PS A. (3) and (4) UA A 527 uses this policy server URI to set up the policy channel. At this 528 time, UA A does not disclose a session description since it does not 529 have the offer yet. (5) UA A re-sends the INVITE request and includes 530 a Policy-Id header to indicate that it has contacted PS A. P A does 531 not reject the INVITE this time and removes the Policy-Id header when 532 forwarding the INVITE. P B adds a Policy-Contact header containing 533 the URI of PS B. (6) UA B uses this URI to discloses the offer to PS 534 B. (7) UA B receives policies from PS B and applies them to the 535 offer. (8) UA B returns the updated offer the 200 OK. (9) and (10) UA 536 A contacts PS and discloses the offer and the answer it is about to 537 send. An important difference to the flow in the previous example is 538 that UA A performs steps (9) and (10) before returning the answer in 539 step (11). This enables UA A to return the final answer in the ACK, 540 which includes all applicable policies. However, it requires that PS 541 A immediately returns a policy to avoid a delay in the transmission 542 of the ACK. (12) and (13) UA B also sends the answer to PS B and 543 applies the policies it receives to the answer before using it. 545 UA A P A P B UA B 546 | | | | 547 | INVITE | | | 548 |---------------->| | | (1) 549 | 488 | | | 550 | + Policy-Contact| | | 551 |<----------------| | | (2) 552 | ACK | | | 553 |---------------->| | | 554 | | PS A | | 555 | | | | 556 | PolicyChannel | | | 557 |------------------->| | | (3) 558 | PolicyChannel | | | 559 |<-------------------| | | (4) 560 | | | | 561 | | | | 562 | INVITE | INVITE | INVITE | 563 | + Policy-Id | | + Policy-Contact| 564 |---------------->|--------------->|---------------->| (5) 565 | | | | 566 | | PS B | | 567 | | | | 568 | | | PolicyChannel | 569 | | | + InfoOffer | 570 | | |<-------------------| (6) 571 | | | PolicyChannel | 572 | | | + PolicyOffer | 573 | | |------------------->| (7) 574 | | | | 575 | | | | 576 | OK offer | OK offer | OK offer | 577 |<----------------|<---------------|<----------------| (8) 578 | | | | 579 | | | | 580 | PolicyChannel | | | 581 | + InfoOffer | | | 582 | + InfoAnswer | | | 583 |------------------->| | | (9) 584 | PolicyChannel | | | 585 | + PolicyOffer | | | 586 | + PolicyAnswer | | | 587 |<-------------------| | | (10) 588 | | | | 589 | ACK answer | 590 |--------------------------------------------------->| (11) 591 | | | | 592 | | | | 593 | | | PolicyChannel | 594 | | | + InfoAnswer | 595 | | |<-------------------| (12) 596 | | | PolicyChannel | 597 | | | + PolicyAnswer | 598 | | |------------------->| (13) 599 | | | | 601 Figure 4 603 4.4. UA/Policy Server Rendezvous 605 The first step in setting up session-specific policies is to 606 rendezvous the UAs with the relevant policy servers. This is 607 achieved by providing the URIs of all policy servers relevant for a 608 session to the UAs. 610 4.4.1. UAC Behavior 612 A UAC compliant to this specification MUST include a Supported header 613 field with the option tag "policy" into all requests that can 614 initiate an offer/answer exchange [8] (e.g. INVITE, UPDATE and PRACK 615 requests). The UA MUST include the "policy" option tag into these 616 requests even if the particular request does not contain an offer or 617 answer (e.g. an INVITE request without an offer). 619 A UAC may receive a 488 response that contains a Policy-Contact 620 header field. The Policy-Contact header is a new header defined in 621 this specification. It contains the URI of a policy server. A 488 622 response with this header is generated by a proxy to convey the URI 623 of the local policy server to the UAC. After receiving a 488 624 response with a Policy-Contact header, a UAC compliant to this 625 specification needs to decide if it wants to continue with the 626 session now knowing that there is a policy server. If the UAC 627 decides to continue, it MUST use the policy server URI to contact the 628 policy server using mechanism defined in Section 4.5. After 629 receiving policies from the policy server, the UAC decides if it 630 wants to accept these policies or not. If it accepts these policies, 631 it MUST apply them to the current request and resend the updated 632 request. If no changes are required by policies or no policies have 633 been received, the request can be resend without any policy-induced 634 changes. If the UAC decides that the list of policy servers or the 635 received session policies are unacceptable, it MUST NOT resend the 636 request. 638 The UAC MUST insert a Policy-Id header into a request if it has 639 contacted a policy server and accepted the policies received for this 640 request. The Policy-Id header is a new header that is defined in 641 this specification. The UA MUST create a Policy-Id header value for 642 each policy server involved in the preparation of a request. A 643 Policy-Id header value contains two pieces of information: the policy 644 server URI and an optional token. The policy server URI is the URI 645 the UA has used to contact the policy server. The token is an opaque 646 string the UAC may have received from the policy server after 647 contacting it. If the UA has received a token from the policy server 648 it MUST include the token in the Policy-Id header. The format of the 649 Policy-Id header is defined in Section 4.4.7. 651 The Policy-Id header serves two main purposes: first and most 652 importantly, it enables a proxy to determine if the UAC already knows 653 the URI of its policy server. A proxy can pass through a request if 654 the URI of its policy server is included in the Policy-Id header. If 655 the policy server URI is not yet known to the UAC, the proxy can 656 convey this URI to the UAC by rejecting the request with a 488 657 response. 659 The second purpose of the Policy-Id header is to enable a domain to 660 route all requests that belong to the same session (i.e. the initial 661 request and requests a UA retransmits after contacting the policy 662 server) to the same proxy and policy server. This is important if a 663 domain has multiple proxy/policy server combinations (e.g. in a 664 proxy/policy server farm that receives requests through a load 665 balancer) and the proxies/policy servers create per-session state in 666 the network. An example for such a scenario is a policy server that 667 is associated with a session border device. The policy server 668 configures the session border device after receiving a session 669 description from the UAC via the policy channel. Retransmitted 670 requests for such a session need to be routed to the same proxy/ 671 policy server as the initial request since this proxy/policy server 672 combination that has configured the associated border device for the 673 session. 675 Routing requests that belong to the same session to the same proxy 676 can be achieved by using the Policy-Id header token. It requires 677 that the policy server returns a token to the UAC that uniquely 678 identifies the specific proxy/policy server combination. The UAC 679 includes this token in the Policy-Id header and it can be used 680 (together with the policy server URI) by proxies in this domain to 681 route the request along the desired path. The format of this token 682 does not require standardization. The only requirement is that the 683 token provides sufficient information for proxies to route the 684 message inside a domain to the desired proxy/policy server. The 685 token can, for example, be a numeric identifier or an IP address. 687 Note: it has been proposed to use the Policy-Id header to provide 688 a hint for a proxy that the UAC has actually contacted the policy 689 server. This usage also requires the policy server to return a 690 token to the UA. In addition, the policy server needs to share 691 valid tokens with the proxy. After receiving a request with a 692 Policy-Id header, the proxy can determine if the token in the 693 Policy-Id header is valid. If it is valid, the proxy knows that 694 the UA has contacted the policy server for this session. However, 695 it is important to note that this token does not provide any proof 696 that the UA has actually used the policies it has received from 697 the policy server. A malicious UA may simply contact the policy 698 server, discard all policies it receives but still use the token 699 in the Policy-Id header. 701 In some cases, a request may traverse multiple domains with session- 702 policies in place. Each of these domains may return a 488 response 703 containing a policy server URI. Since the UAC contacts a policy 704 server after receiving a 488 response from a domain and before re- 705 sending the request, session policies are always applied to a request 706 in the order in which the request traverses through the domains. The 707 UAC MUST NOT change this implicit order among policy servers. 709 A UAC frequently needs to contact the policy server in the local 710 domain before sending a new request. To avoid the retransmission of 711 the local policy server URI in a 488 for each new request, a UA 712 SHOULD maintain a cache that contains the URI of the local policy 713 server (see Section 4.4.4). The UAC SHOULD use the cached policy 714 server URI to contact the local policy server before sending the 715 initial request that starts an offer/answer exchange (e.g. an INVITE 716 request). 718 A UA may decide to change the session description of a session and to 719 initiate subsequent offer/answer exchanges (e.g. using INVITE, UPDATE 720 or PRACK requests) to re-negotiate the session description. When 721 creating such a mid-dialog request, a UA SHOULD contact the same 722 policy servers it has contacted during the initial offer/answer 723 exchange (see Section 4.4.5) before sending the request. This avoids 724 the retransmission of all policy server URIs in 488 responses for 725 mid-dialog requests. 727 4.4.2. Proxy Behavior 729 A proxy provides rendezvous functionality for UAs and a policy 730 server. This is achieved by conveying the URI of a policy server to 731 the UAC or the UAS (or both) when processing INVITE, UPDATE or PRACK 732 requests (or any other request that can initiate an offer/answer 733 exchange). 735 If such a request contains a Supported header field with the option 736 tag "policy", the proxy MAY reject the request with a 488 response to 737 provide the local policy server URI to the UAC. Before rejecting a 738 request, the proxy MUST verify that the request does not contain a 739 Policy-Id header field, which has the local policy server URI as a 740 value. If the request does not contain such a header or the local 741 policy server URI is not present in this header, then the proxy MAY 742 reject the request with a 488. The proxy MUST insert a Policy- 743 Contact header in the 488 response that contains the URI of its 744 associated policy server. The proxy MAY add the header field 745 parameter "non-cacheable" to prevent the UAC from caching this policy 746 server URI (see Section 4.4.4). 748 If the local policy server URI is present in a Policy-Id header value 749 of a request, then the proxy MUST NOT reject the request as described 750 above (it may still reject the request for other reasons). The proxy 751 SHOULD remove the Policy-Id header value for this policy server from 752 the Policy-Id header field before forwarding the request. This value 753 only increases message size and is not relevant to other proxies on 754 the path. It also would disclose the policy server URI to subsequent 755 proxies. 757 The proxy MAY insert a Policy-Contact header field into INVITE, 758 UPDATE or PRACK requests (or any other request that can initiate an 759 offer/answer exchange) in order to convey the policy server URI to 760 the UAS. If the request already contains a Policy-Contact header 761 field, the proxy MUST insert the URI ahead of all existing values at 762 the beginning of the list. A proxy MUST NOT change the order of 763 existing Policy-Contact header values. 765 4.4.3. UAS Behavior 767 A UAS may receive an INVITE, UPDATE or PRACK request (or another 768 request that can initiate offer/answer exchanges), which contains a 769 Policy-Contact header filed with a list of policy server URIs. A UAS 770 that receives such a request needs to decide if it wants to accept 771 the session knowing that there are policy servers involved. If it 772 accepts, it MUST contact all policy server URIs in a Policy-Contact 773 header. The UAS MUST contact the policy server URIs in the order in 774 which they were contained in the Policy-Contact header, starting with 775 the topmost value. 777 If a UAS decides that it does not want to accept a session because 778 there are policy servers involved or because one of the session 779 policies received from a policy server is not acceptable, the UAS 780 MUST reject the request with a 488 response. 782 A UAS may receive a token from a policy server via the policy 783 channel. Since the UAS does not create a Policy-ID header, it can 784 simply ignore this token. 786 4.4.4. Caching the Local Policy Server URI 788 A UAC may frequently need to contact the policy server in the local 789 domain before sending a request. To avoid the retransmission of the 790 local policy server URI for each new request, a UA SHOULD maintain a 791 cache that contains the URI of the local policy server. A UA may 792 receive this URI in a Policy-Contact header of a request or a 488 793 response. The UA may also receive the local policy server URI 794 through configuration, for example, via the configuration framework 795 [4]. If a UA has received a local policy server URI through 796 configuration and receives another local policy server URI in a 797 Policy-Contact header, it SHOULD overwrite the configured URI with 798 the most recent one received in a Policy-Contact header. 800 Domains can prevent a UA from caching the local policy server URI. 801 This is useful, for example, if the policy server does not need to be 802 involved in all sessions or the policy server URI changes from 803 session to session. A proxy can mark the URI of such a policy server 804 as "non-cacheable". A UA MUST NOT cache a non-cacheable policy 805 server URI. It SHOULD remove the current URI from the cache when 806 receiving a local policy server URI that is marked as "non- 807 cacheable". This is to avoid the use of policy server URIs that are 808 outdated. 810 The UA SHOULD NOT cache policy server URIs it has received from 811 proxies outside of the local domain. These policy servers may not be 812 relevant for subsequent sessions, which may go to a different 813 destination, traversing different domains. 815 The UA MUST NOT cache tokens it may receive from a policy server. A 816 token is only valid for one request. 818 4.4.5. Storing Session Policy Server URIs 820 A UA discovers the list of policy servers relevant for a session 821 during the initial offer/answer exchange. It SHOULD store this list 822 of policy server URIs, as part of the dialog state. The UA SHOULD 823 maintain this list until the session is terminated. It SHOULD store 824 policy server URIs in this list even if they are marked as "non- 825 cacheable". The non-cacheable parameter only refers to caching 826 policy server URIs for re-use between sessions. 828 If a UAC has contacted all stored policy servers before sending a 829 mid-dialog request and receives a 488 in response to this request 830 with a Policy-Contact header containing a new policy server URI, it 831 MUST discard the stored policy server URI list for the current 832 dialog. Receiving a 488 response at this point indicates that the 833 set of policy servers relevant for the current dialog has changed. 834 The UAC SHOULD retry sending the request as if it was the first 835 request in a dialog (i.e. without applying any policies except 836 policies from the local policy server). This way, the UAC will re- 837 discover the list of policy server URIs relevant for the current 838 request. 840 If a UAS receives a mid-dialog request with a Policy-Contact header 841 containing a list of policy server URIs that is different from the 842 list stored for the dialog, then the UAS SHOULD replace the stored 843 list with the one received in the Policy-Contact header field. 845 4.4.6. Contacting the Policy Server 847 A UA compliant to this specification MUST contact the discovered 848 policy servers and apply session policies to an offer or answer 849 before using the offer or answer. If the UA does not want to contact 850 the policy servers provided or the policies received for a session 851 are unacceptable, it MUST NOT continue with the session. This means 852 that, the UA MUST cancel or reject a pending INVITE transaction for 853 the session or terminate the session if it is already in progress. 855 A UA that receives a SIP message containing an offer or answer SHOULD 856 completely process the message (e.g. according to [6]) before 857 contacting the policy server. The SIP processing of the message 858 includes, for example, updating dialog state and timers as well as 859 creating ACK or PRACK requests as necessary. This ensures that 860 contacting a policy server does not interfere with SIP message 861 processing and timing (e.g. by inadvertently causing timers to 862 expire). This implies, for example, that a UAC which has received a 863 response to an INVITE request SHOULD finish the processing of the 864 response including transmitting the ACK before it contacts the policy 865 server. An important exception to this rule is discussed in the next 866 paragraph. 868 In some cases, a UA needs to use the offer/answer it has received in 869 a SIP message to create an ACK or PRACK response for this message, 870 i.e. it needs to use the offer/answer before finishing the SIP 871 machinery for this message. For example, a UAC that has received an 872 offer in the response to an INVITE request needs to apply policies to 873 the offer and the answer before it can send the answer in an ACK. In 874 these cases, a UA SHOULD contact the policy server even if this is 875 during the processing of a SIP message. This implies that a UA, 876 which has received an offer in the response of an INVITE request, 877 SHOULD contact the policy server and apply session policies before 878 sending the answer in the ACK. 880 Note: this assumes that the policy server can always respond 881 immediately to a policy request and does not require manual 882 intervention to create a policy. This will be the case for most 883 policy servers. If, however, a policy server cannot respond with 884 a policy right away, it may return a policy that temporarily 885 denies the session and update this policy as the actual policy 886 decision becomes available. A delay in the response from the 887 policy server to the UA would delay the transmission of the ACK 888 and could trigger retransmissions of the INVITE response (also see 889 the recommendations for Flow I in [9]). 891 A UA MUST inform the policy server when a session is terminated via 892 the policy channel. This enables a policy server to free all 893 resources it may have allocated for this session. A policy server 894 can indicate via the policy channel that it does not need to be 895 contacted at the end of a session. In this case, the UA SHOULD NOT 896 inform the policy server about the termination of the session. 898 4.4.7. Header Definition and Syntax 899 4.4.7.1. Policy-Id Header 901 The Policy-Id header field is inserted by the UAC into INVITE, UPDATE 902 or PRACK requests (or any other request that can be used to initiate 903 an offer/answer exchange). The Policy-Id header identifies all 904 policy servers the UAC has contacted for this request. 906 The value of a Policy-Id header consists of a policy server URI. A 907 Policy-Id header value may have an optional token parameter. The 908 token parameter contains a token the UA may receive from the policy 909 server. If the UA has received a token, it MUST be included in the 910 Policy-Id header. 912 The syntax of the Policy-Id header field is: 914 Policy-Id = "Policy-Id" HCOLON policyURI 915 *(COMMA policyURI) 916 policyURI = ( SIP-URI / SIPS-URI ) 917 [ SEMI token-param ] *( SEMI generic-param ) 918 token-param = "token=" token 920 The BNF for SIP-URI, SIPS-URI, token and generic-param is defined in 921 [6]. 923 4.4.7.2. Policy-Contact Header 925 The Policy-Contact header field can be inserted by a proxy into a 488 926 response to INVITE, UPDATE or PRACK requests (or other requests that 927 initiate an offer/answer exchange). It contains a policy server URI 928 that needs to be contacted by the UAC. A proxy MAY add the "non- 929 cacheable" header field parameter to indicate that a UA MUST NOT 930 cache this policy server URI. 932 The Policy-Contact header field can also be inserted by a proxy into 933 INVITE, UPDATE and PRACK requests (or other requests that can be used 934 to initiate an offer/answer exchange). It contains an ordered list 935 of policy server URIs that need to be contacted by the UAS. The UAS 936 starts to process the header field at the topmost value of this list. 937 New header field values are inserted at the top. The Policy-Contact 938 header field effectively forms a stack. 940 The syntax of the Policy-Contact header field is: 942 Policy-Contact = "Policy-Contact" HCOLON policyContactURI 943 *(COMMA policyContactURI) 944 policyContactURI = ( SIP-URI / SIPS-URI ) 945 [ SEMI "non-cacheable" ] *( SEMI generic-param ) 947 The BNF for SIP-URI, SIPS-URI and generic-param is defined in [6]. 949 Table 1 is an extension of Tables 2 and 3 in [6]. The column 'UPD' 950 is for the UPDATE method [5]. 952 Header field where proxy ACK BYE CAN INV OPT REG UPD 953 _______________________________________________________________ 954 Policy-Id R rd - - - o - - o 955 Policy-Contact R a - - - o - - o 956 Policy-Contact 488 a - - - o - - o 957 Table 1: Policy-Id and Policy-Contact Header Fields 959 4.5. Policy Channel 961 The main task of the policy channel is to enable a UA to submit 962 information about the session it is trying to establish (i.e. the 963 offer and the answer) to a policy server and to receive the resulting 964 session-specific policies and possible updates to these policies in 965 response. 967 A UA compliant to this specification MUST implement the Event Package 968 for Session-Specific Session Policies [2]. It contacts a policy 969 server by subscribing to this event package. 971 A UA MUST use the policies it has received from the policy server in 972 the current session. If these policies are unacceptable, the UA MUST 973 NOT attempt to establish the session. When a UA receives a 974 notification about a change in the current policies, it MUST apply 975 the updated policies to the current session or it MUST terminate the 976 session. If the policy update causes a change in the session 977 description of a session, the UA may need to re-negotiate the 978 modified session description with its peer UA, for example, using a 979 re-INVITE or UPDATE request. For example, if a policy update 980 disallows the use of video and video is part of the current session 981 description, then the UA will need to create an new session 982 description offer without video. After receiving this offer, the 983 peer UA knows that video can't be used any more and responds with the 984 corresponding answer. The re-INVITE or UPDATE message need to be 985 generated in accordance to Section 4.4.1. 987 5. Security Considerations 989 Session policies can significantly change the behavior of a user 990 agent and can be used by an attacker to compromise a user agent. For 991 example, session policies can be used to prevent a user agent from 992 successfully establishing a session (e.g. by setting the available 993 bandwidth to zero). Such a policy can be submitted to the user agent 994 during a session, which may cause the UA to terminate the session. 996 A user agent transmits session information to a policy server for 997 session-specific policies. This session information may contain 998 sensitive data the user may not want an eavesdropper or an 999 unauthorized policy server to see. For example, the session 1000 information may contain the encryption keys for media streams. Vice 1001 versa, session policies may also contain sensitive information about 1002 the network or service level agreements the service provider may not 1003 want to disclose to an eavesdropper or an unauthorized user agent. 1005 It is important to secure the communication between the proxy and the 1006 user agent (for session-specific policies) as well as the user agent 1007 and the policy server. The following four discrete attributes need 1008 to be protected: 1010 1. integrity of the policy server URI (for session-specific 1011 policies), 1012 2. authentication of the policy server and, if needed, the user 1013 agent, 1014 3. confidentiality of the messages exchanged between the user agent 1015 and the policy server and 1016 4. ensuring that private information is not exchanged between the 1017 two parties, even over an confidentiality-assured and 1018 authenticated session. 1020 To protect the integrity of the policy server URI, a UA SHOULD use a 1021 secured transport protocol such as TLS between proxies and the UA. 1022 Protecting the integrity of the policy server URI is important since 1023 an attacker could intercept SIP messages between the UA and the proxy 1024 and remove the policy headers needed for session-specific policies. 1025 This would impede the rendezvous between UA and policy server and, 1026 since the UA would not contact the policy server, may prevent a UA 1027 from setting up a session. 1029 Instead of removing a policy server URI, an attacker can also modify 1030 the policy server URI and point the UA to a compromised policy 1031 server. To prevent such an attack from being effective, it is 1032 RECOMMENDED that a UA authenticates policy servers. 1034 Policy servers SHOULD authenticate UAs to protect the information 1035 that is contained in a session policy. However, a policy server may 1036 also frequently encounter UAs it cannot authenticate. In these 1037 cases, the policy server MAY provide a generic policy that does not 1038 reveal sensitive information to these UAs. 1040 It is RECOMMENDED that administrators use SIPS URIs as policy server 1041 URIs so that subscriptions to session policies are transmitted over 1042 TLS. 1044 The above security attributes are important to protect the 1045 communication between the user agent and policy server. This 1046 document does not define the protocol used for the communication 1047 between user agent and policy server and merely refers to other 1048 specifications for this purpose. The security considerations of 1049 these specifications need to address the above security aspects. 1051 6. IANA Considerations 1053 6.1. Registration of the "Policy-Id" Header 1055 Name of Header: Policy-Id 1057 Short form: none 1059 Normative description: Section 4.4.7 of this document 1061 6.2. Registration of the "Policy-Contact" Header 1063 Name of Header: Policy-Contact 1065 Short form: none 1067 Normative description: Section 4.4.7 of this document 1069 6.3. Registration of the "policy" SIP Option-Tag 1071 Name of option: policy 1073 Description: Support for the Policy-Contact and Policy-Id headers. 1075 SIP headers defined: Policy-Contact, Policy-Id 1077 Normative description: This document 1079 Appendix A. Acknowledgements 1081 Many thanks to Allison Mankin for the discussions and the suggestions 1082 for this draft and to Roni Even, Bob Penfield, Mary Barnes and Shida 1083 Schubert for reviewing the draft and providing feedback. Many thanks 1084 to Vijay Gurbani for the comments and feedback. 1086 Appendix B. Session-Specific Policies - Call Flows 1088 The following call flows illustrate the overall operation of session- 1089 specific policies including the policy channel protocol as defined in 1090 [2]. 1092 The following abbreviations are used: 1094 o: offer 1095 o': offer modified by a policy 1096 po: offer policy 1097 a: answer 1098 a': answer modified by a policy 1099 pa: answer policy 1100 ps uri: policy server URI (in Policy-Contact header) 1101 ps id: policy server id (in Policy-Id header) 1103 B.1. Offer in Invite 1104 UA A P A PS A PS B P B UA B 1105 | | | | | | 1106 |(1) INV | | | | 1107 |-------->| | | | | 1108 |(2) 488 | | | | 1109 |<--------| | | | | 1110 |(3) ACK | | | | | 1111 |-------->| | | | | 1112 |(4) SUBSCRIBE | | | | 1113 |------------------>| | | | 1114 |(5) 200 OK | | | | 1115 |<------------------| | | | 1116 |(6) NOTIFY | | | | 1117 |<------------------| | | | 1118 |(7) 200 OK | | | | 1119 |------------------>| | | | 1120 |(8) INV | | | | 1121 |-------->| | | | | 1122 | |(9) INV | | | 1123 | |---------------------------->| | 1124 | | | | |(10) INV 1125 | | | | |-------->| 1126 | | | |(11) SUBSCRIBE 1127 | | | |<------------------| 1128 | | | |(12) 200 OK | 1129 | | | |------------------>| 1130 | | | |(13) NOTIFY 1131 | | | |------------------>| 1132 | | | |(14) 200 OK | 1133 | | | |<------------------| 1134 | | | | |(15) 200 OK 1135 | | | | |<--------| 1136 | |(16) 200 OK | | | 1137 | |<----------------------------| | 1138 |(17) 200 OK | | | | 1139 |<--------| | | | | 1140 |(18) ACK | | | | | 1141 |------------------------------------------------>| 1142 |(19) SUBSCRIBE | | | 1143 |------------------>| | | | 1144 |(20) 200 OK | | | | 1145 |<------------------| | | | 1146 |(21) NOTIFY | | | | 1147 |<------------------| | | | 1148 |(22) 200 OK | | | | 1149 |------------------>| | | | 1150 | | | | | | 1151 | | | | | | 1153 B.2. Offer in Response 1155 UA A P A PS A PS B P B UA B 1156 | | | | | | 1157 |(1) INV | | | | | 1158 |-------->| | | | | 1159 |(2) 488 | | | | 1160 |<--------| | | | | 1161 |(3) ACK | | | | | 1162 |-------->| | | | | 1163 |(4) SUBSCRIBE | | | | 1164 |------------------>| | | | 1165 |(5) 200 OK | | | | 1166 |<------------------| | | | 1167 |(6) NOTIFY | | | | 1168 |<------------------| | | | 1169 |(7) 200 OK | | | | 1170 |------------------>| | | | 1171 |(8) INV | | | | 1172 |-------->| | | | | 1173 | |(9) INV | | | | 1174 | |---------------------------->| | 1175 | | | | |(10) INV 1176 | | | | |-------->| 1177 | | | |(11) SUBSCRIBE | 1178 | | | |<------------------| 1179 | | | |(12) 200 OK | 1180 | | | |------------------>| 1181 | | | |(13) NOTIFY | 1182 | | | |------------------>| 1183 | | | |(14) 200 OK | 1184 | | | |<------------------| 1185 | | | | |(15) 200 OK 1186 | | | | |<--------| 1187 | |(16) 200 OK | | | 1188 | |<----------------------------| | 1189 |(17) 200 OK | | | | 1190 |<--------| | | | | 1191 |(18) SUBSCRIBE | | | 1192 |------------------>| | | | 1193 |(19) 200 OK | | | | 1194 |<------------------| | | | 1195 |(20) NOTIFY | | | 1196 |<------------------| | | | 1197 |(21) 200 OK | | | | 1198 |------------------>| | | | 1199 |(22) ACK | | | | 1200 |------------------------------------------------>| 1201 | | | |(23) SUBSCRIBE 1202 | | | |<------------------| 1203 | | | |(24) 200 OK | 1204 | | | |------------------>| 1205 | | | |(25) NOTIFY 1206 | | | |------------------>| 1207 | | | |(26) 200 OK | 1208 | | | |<------------------| 1209 | | | | | | 1210 | | | | | | 1212 7. References 1214 7.1. Normative References 1216 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1217 Levels", BCP 14, RFC 2119, March 1997. 1219 [2] Hilt, V. and G. Camarillo, "A Session Initiation Protocol (SIP) 1220 Event Package for Session-Specific Session Policies.", 1221 draft-ietf-sipping-policy-package-03 (work in progress), 1222 January 2007. 1224 [3] Hilt, V., Camarillo, G., and J. Rosenberg, "A User Agent Profile 1225 Data Set for Media Policy", 1226 draft-ietf-sipping-media-policy-dataset-02 (work in progress), 1227 October 2006. 1229 [4] Petrie, D. and S. Channabasappa, "A Framework for Session 1230 Initiation Protocol User Agent Profile Delivery", 1231 draft-ietf-sipping-config-framework-10 (work in progress), 1232 January 2007. 1234 [5] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 1235 Method", RFC 3311, October 2002. 1237 [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1238 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1239 Session Initiation Protocol", RFC 3261, June 2002. 1241 7.2. Informative References 1243 [7] Handley, M. and V. Jacobson, "SDP: Session Description 1244 Protocol", RFC 2327, April 1998. 1246 [8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 1247 Session Description Protocol (SDP)", RFC 3264, June 2002. 1249 [9] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, 1250 "Best Current Practices for Third Party Call Control (3pcc) in 1251 the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, 1252 April 2004. 1254 Authors' Addresses 1256 Volker Hilt 1257 Bell Labs/Alcatel-Lucent 1258 101 Crawfords Corner Rd 1259 Holmdel, NJ 07733 1260 USA 1262 Email: volkerh@bell-labs.com 1264 Gonzalo Camarillo 1265 Ericsson 1266 Hirsalantie 11 1267 Jorvas 02420 1268 Finland 1270 Email: Gonzalo.Camarillo@ericsson.com 1272 Jonathan Rosenberg 1273 Cisco Systems 1274 600 Lanidex Plaza 1275 Parsippany, NJ 07054 1276 USA 1278 Email: jdrosen@cisco.com 1280 Full Copyright Statement 1282 Copyright (C) The IETF Trust (2007). 1284 This document is subject to the rights, licenses and restrictions 1285 contained in BCP 78, and except as set forth therein, the authors 1286 retain all their rights. 1288 This document and the information contained herein are provided on an 1289 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1290 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1291 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1292 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1293 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1294 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1296 Intellectual Property 1298 The IETF takes no position regarding the validity or scope of any 1299 Intellectual Property Rights or other rights that might be claimed to 1300 pertain to the implementation or use of the technology described in 1301 this document or the extent to which any license under such rights 1302 might or might not be available; nor does it represent that it has 1303 made any independent effort to identify any such rights. Information 1304 on the procedures with respect to rights in RFC documents can be 1305 found in BCP 78 and BCP 79. 1307 Copies of IPR disclosures made to the IETF Secretariat and any 1308 assurances of licenses to be made available, or the result of an 1309 attempt made to obtain a general license or permission for the use of 1310 such proprietary rights by implementers or users of this 1311 specification can be obtained from the IETF on-line IPR repository at 1312 http://www.ietf.org/ipr. 1314 The IETF invites any interested party to bring to its attention any 1315 copyrights, patents or patent applications, or other proprietary 1316 rights that may cover technology that may be required to implement 1317 this standard. Please address the information to the IETF at 1318 ietf-ipr@ietf.org. 1320 Acknowledgment 1322 Funding for the RFC Editor function is provided by the IETF 1323 Administrative Support Activity (IASA).