1 / 6

Enhancing Session Policies in SIP for Unified Communications and Network Adaptability

This document outlines the evolution and challenges of Session Initiation Protocol (SIP) session policies, detailing approaches to enable networks to request and utilize these policies effectively from User Agents (UAs). It discusses session-specific and session-independent policies, along with frameworks for policy server discovery. The document highlights existing open issues, including policy lifecycle management through XCAP and dynamic policy updates during session negotiations. It proposes methods to optimize consent models in policy exchanges to ensure seamless connectivity and user experience.

kenna
Télécharger la présentation

Enhancing Session Policies in SIP for Unified Communications and Network Adaptability

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SIP Session Policies Volker Hilt volkerh@bell-labs.com

  2. History • Problem statement • Enable the network to request the use of session policies from UAs. • History • draft-rosenberg-sipping-session-policy-00 • draft-hilt-sipping-session-policy-00 • draft-camarillo-sipping-policy-package-00 • Session-Specific Intermediary Session Policies • draft-hilt-sipping-session-spec-policy-00 • Created during a specific session. • Affect the current session. • Session-Independent Intermediary Session Policies • draft-hilt-sipping-session-indep-policy-00 • Created outside of a session. • Affect selected sessions during a period of time.

  3. Session-Independent Policies (1) Access Network Policy Server Home Domain Policy Server • Overview • UAs subscribes to policies. • Policy documents conveyed through content indirection. • Defines a framework. • Open issues • Policy server discovery • Assumption: Session policies will most likely be provided by the access network domain and the home domain. • Policy server discovery would simplify deployment. • Issue: Current procedures overload user name “sessionpolicies”. SUBSCRIBE SUBSCRIBE NOTIFY NOTIFY GET Policy GET Policy

  4. Session-Independent Policies (2) • Open issues (cont.) • Policy documents • XCAP event package and XCAP-based documents. • Use the existing XCAP framework to deliver policies. • Define the general properties of policy documents. • But: XCAP event package assumes that the UAs know the path to the relevant documents. • XCAP-based policy documents. • Limits the number of protocols and document formats used in policy packages. • But: simple UAs may prefer plain HTTP and text documents. • Allow any policy document format. • How to proceed?

  5. Session-Dependent Policies (1) • Overview • Policies are requested using MIO/MFO headers individually for each session during an offer/answer exchange. • Defines a framework. • Open issues • Preconditions • UAC may reject policies and terminate the session, which may cause “ghost rings” on the UAS side. • Use of precondition could prevent “ghost rings”. • Subsequent offer/answer exchanges • How to handle policies in subsequent offer/answer exchanges? INVITE(offer) + MIO-1 INVITE(offer) + MIO-1 + MFO-1 MFO-1 MFO-1 MFO-2 OK(answer) + MIO-2 + MFO-1 + MFO-2 OK(answer) + MIO-2 + MFO-1 ACK + MFO-2 ACK + MFO-2 MFO-2

  6. Session-Dependent Policies (2) • Open issues (cont.) • Two party consent vs. one party consent. • The current requirements are based on a two party consent model: • Both UAs need to know all policies (REQ-CON-1 and REQ-CON-2) • Proxies need to know the accepted policies (REQ-CON-5 and REQ-CON-6). • Two party consent requires a three pass policy exchange. • But: the third pass does not exist in “empty” INVITE and UPDATE flows. • Approach 1: Two party consent • Send policy information in a separate message (SUBSCRIBE/NOTIFY, INFO,...). • Approach 2: One party consent (as discussed for OPES in RFC3238) • Only one UA needs to know about and agree to a policies. • Since each UA can set up a session policy locally, one party consent does not change the current model. • Works with the two-way offer answer model. • How to proceed?

More Related