Consent Framework draftietfsippingconsentframework02 txt Gonzalo Camarilloericsson com Changes
- Slides: 12
Consent Framework draft-ietf-sipping-consent-framework-02. txt Gonzalo. Camarillo@ericsson. com
Changes • Fundamental architectural change – Consent applies when users are added to a translation at a relay – Not when the translation is executed at the relay – Like in an emailing list • Decoupled – Requesting for permission – Amplification avoidance • Credit-based approach
User A adds User B Add User B User A OK Relay User B
User A Consumes Some Bandwidth REFER User A 200 OK Relay User B
The Relay Sends a CONSENT User A Relay 200 OK User B
User B Uploads a Permission Document to the Relay PUBLISH User A Relay 200 OK User B
Adding Two Users
Authentication Model • Return routability – CONSENT carries an unguessable (e. g. , long and random) URI – The PUBLISH needs to be sent to that URI – The only entity that knows the URI is the recipient of the CONSENT • SIP identity can be used if available
Simplification • The relay is always the one that sends the CONSENT – Allows for an easy migration from return routability to SIP identity • Assume that endpoints cannot sign their permission documents
Simplification (cont. ) • Simple mechanism for Inter-domain scenarios • A different mechanism to deal with your registrar (e. g. , CPL)
Permission Document Format • Target – Relay performing the translation • Sender – Needed for relays that handle requestcontained URI lists • Recipient • Operations – Methods
Permission Revocation • Upload an “empty” permission document to the relay
