70 likes | 78 Views
This draft proposes a framework for configuring SIP profiles and defines the structure of SIP profile datasets. It includes changes from the previous version and better integration with the session-independent policy draft. The draft also discusses merging policies in both user agents and servers.
E N D
Configuration Framework &SIP Profile Datasets Daniel Petrie dan.ietf@SIPez.com SIPez Consulting
Profile Draft Map Event Package - draft-ietf-sipping-config-framework-07.txt SIP – SUBSCRIBE/NOTIFY Profile Delivery Server User Agent HTTP/HTTPS payload General Payload Schema - draft-petrie-sipping-profile-datasets-02.txt Core SIP Properties – draft-petrie-sipping-sip-dataset-00.txt Media & Codec Properties - draft-ietf-sipping-session-indep-policy-03.txt
Changes from 01 • Split out core SIP Protocol dataset into a separate draft • Previously just an example dataset • draft-petrie-sipping-sip-dataset-00.txt • Schema changes • created setting_container • Setting_container has a separate attribute for policy • added q and direction attributes • other tweeks to the schema. • Better integration and coordination with draft-ietf-sipping-session-indep-policy • media/codec dataset is now completely contained in the policy draft
draft-petrie-sipping-sip-dataset-00 Contains: • SIP Transport Protocol and Port Binding • Outbound Proxy & Pre-set Route Set • Methods to Enable/Disable • Option tags as to Enable/Diable
Merging Policy Model • Abstract • Policy Model is abstract and lives in a separate schema • Works like presence (unsolved) • Data Based • Have a policy for whether you are willing to apply a property when received in a subsequent data set • If you are merging a parameter, it merges in a data specific way. (ex: codecs intersect, max-bw take lowest number) • Do you want the merging rules in a separate doc
Next Steps • WG Items? • draft-petrie-sipping-profile-datasets-02.txt • draft-petrie-sipping-sip-dataset-00.txt Need drafts for: • dataset to contain AORs to register • dataset(s) for NAT/Firewall Traversal Properties
Merging in UA vs Server • Merging in UA: • Requires expression of policy and access control in profile • Allows user interface on UA to take advantage of access control information • Allows use of multiple service providers • Allows static profiles (simple delivery server) • Allows UA vendor extension and differentiation • Merging in Server: • Requires profiles always be actively generated • Requires server to understand all configurable features • User agent has no concept what properties may be changed by end user • Simpler user agent implementation (no merging)