Session Policy Framework Draft draft-ietf-sip-session-policy-framework-00

1. Session Policy Framework Draftdraft-ietf-sip-session-policy-framework-00 Volker Hilt volkerh@bell-labs.com Gonzalo Camarillo Gonzalo.Camarillo@ericsson.com Jonathan Rosenberg jdrosen@cisco.com

2. Status • Draft moved to SIP WG • Numerous changes and clarifications to address reviewer feedback. • Big thanks to the reviewers! 

3. Changes • Editorial changes. • Updated abstract. • Added a of number additional explanations and examples throughout the text. • Session-independent policies • Removed requirement to support Schema for SIP User Agent Profile Data Sets. • Syntax description • Added a generic-parameter for extensibility to the policy header syntax. • Changed the syntax for policy server URIs from absoluteURI to SIP/SIPS-URI. • Security Section • Included a more detailed thread analysis. • Revised parts of the security section.

4. Changes (cont.) • Session-specific policies • Restructured text and introduced the following new sections: • Caching Policy Server URIs • Storing Policy Server URIs in a Dialog • Contacting the Policy Server • Described UA behavior independent of a specific request types (e.g. INVITE, UPDATE, PRACK) where possible. • Added UA behavior for PRACK requests. • Clarified UA behavior for caching the local policy server URI between session. • Clarified UA behavior for storing all used policy server URIs during a dialog. • Specified UA behavior for storing policy server URIs when the list of policy servers changes during a dialog. • Defined that UAs should always cache the local policy server URI, independent of their role as UAC or UAS. • Defined that UAs MUST honor the non-cacheable parameter of policy server URIs (was SHOULD). • Described the process of contacting a policy server independent of the UAs role as UAC and UAS. • Suppressing the transmission of the answer to the policy server (when indicated) is now SHOULD instead of MAY.

5. Issue: Correlate Policy and INVITE? • Should a proxy be able to correlate a policy and a subsequent INVITE request? • Provides a hint that the UA has acquired policies for a session but no guarantee that UA is actually using the policies received. • Options: O1: Provide session identifier to PS O2: Token passed to UA O3: No correlation • Proposal: O1 • Enables PS and proxy to correlate policy requests and INVITEs. • No change needed in policy framework. Proxy O2: Token 2. Token UA PS O1: Call-ID

6. Next-Steps • Ready for WGLC

7. Event Package for Session-Specific Policiesdraft-ietf-sipping-policy-package-02 Volker Hilt volkerh@bell-labs.com Gonzalo Camarillo Gonzalo.Camarillo@ericsson.com

8. Changes • Streamlined introduction. • Added a of number additional explanations and examples throughout the text. • SUBSCRIBE requests MUST contain a body (was SHOULD). • Added a note that compares the use of an XML format to the use of SDP. • Specified that a notifier can terminate subscription before the end of a session. • Defined behavior for subscriptions without information about an offer. Needed, e.g., for empty INVITE requests. • Defined behavior if the information disclosed in a SUBSCRIBE is not sufficient for a policy decision. • Subscribers MUST refresh the subscription when the session description changes (was SHOULD). • Defined subscriber behavior for the case that a policy subscription fails. • Specified that UAs MUST apply the policies received or they MUST NOT set up (or MUST terminate) the session. • Suppressing the transmission of the answer to the policy server (when indicated) is now SHOULD instead of MAY. • Added a threat analysis to the security section. • Completely revised the security section.

9. Issue: Disclosure of Session Infos • Which information should a subscriber disclose to a policy server when setting up a subscription? • Needs to sufficiently describe a session. • Avoid negotiation! • Proposal: • UA populates all fields of a media policy document it has data for. • Media policy dataset format defines a basic set of elements needed to summarize a session.

10. Next Steps • Resolve remaining open issue. • Ready for WGLC?

11. A User Agent Profile Data Set for Media Policydraft-ietf-sipping-media-policy-dataset-02 Volker Hilt volkerh@bell-labs.com Gonzalo Camarillo Gonzalo.Camarillo@ericsson.com Jonathan Rosenberg jdrosen@cisco.com

12. Status • Changes and clarifications to address reviewer feedback. • Added capability to encode session information. • Definition needs to be moved to Relax NG. • Follow Schema for SIP UA Profile Data Sets (draft-petrie-sipping-profile-datasets-03.txt)

13. Changes • Modified abstract and introduction to reflect the inclusion of encoding session information. • Introduction discusses two usage types: i) encoding session information and ii) encoding policies. • Added new element <session-info> as container for session information. • Defined specific usages of elements and attributes inside a <session-info> and <session-policy> container. • Added new elements to <context> container: • <call-ID> call-ID of request setting up a session. • <request-URI> request-URI of request setting up a session. • Added new elements to <session-info> container: • <streams> container for media stream information. • <stream> describes one media stream used in a session. • <local-URI> contains local address and port (from SDP c= and m= lines). • <remote-URI> contains remote address and port (from SDP c= and m= lines). • Added examples for encoding SDP descriptions. • Removed the “mandatory” policy.

14. Issue 1: Session-Info Elements • Elements for encoding session information: • <request-URI> • <call-ID> • <contact> • <info> • <max-bandwidth> • <stream> containing: • <media-type> • <codec> • <local-URI> • <remote-URI>

15. Example MPDF document: <property-set> <session-info> <context> <contact>sip:alice@any.com</contact> <info>session information</info> <request-URI>sip:bob@ex.com</request-URI> <call-ID>3848276298220188511@any.com</call-ID> </context> <streams> <stream> <media-type>audio</media-type> <codec><mime-type>audio/PCMU</mime-type></codec> <codec><mime-type>audio/GSM</mime-type></codec> <local-uri>h.any.com:49562</local-uri> <remote-uri>h.ex.com:52123</remote-uri> </stream> <stream> <media-type>video</media-type> <codec><mime-type>video/H261</mime-type></codec> <local-uri>h.any.com:51234</local-uri> <remote-uri>h.ex.com:50286</remote-uri> </stream> </streams> </session-info> </property-set> Local SDP session description: v=0 o=alice 2890844526 2890844526 IN IP4 h.any.com s= c=IN IP4 h.any.com t=0 0 m=audio 49562 RTP/AVP 0 1 3 a=rtpmap:0 PCMU/8000 a=rtpmap:1 1016/8000 a=rtpmap:3 GSM/8000 m=video 51234 RTP/AVP 31 34 a=rtpmap:31 H261/90000 a=rtpmap:34 H263/90000 Remote SDP session description: v=0 o=bob 2890844730 2890844730 IN IP4 h.ex.com s= c=IN IP4 h.ex.com t=0 0 m=audio 52123 RTP/AVP 0 3 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 m=video 50286 RTP/AVP 31 a=rtpmap:31 H261/90000 Note: this slightly differs from the format described in the draft. Codec and Media information is encoded on a per-stream basis.

16. Issue 2: Policy Elements • Are the following elements needed? • <ipinip-intermediary>, <iploose-intermediary> • Proposal: remove • <configured-intermediary> • Problem: requires sequential contacting of policy servers. • Should bandwidth-related elements be added? • maximum session bandwidth • maximum bandwidth per stream • Need to add element for local policy server URI.

17. Next Steps • Finalize format and usage for policy and session information. • Move Definition to Relax NG. • Comments, feedback?