1 / 23

Gonzalo.Camarillo@ericsson

jewell
Download Presentation

Gonzalo.Camarillo@ericsson

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. Consent-based Communications in SIPdraft-ietf-sipping-consent-reqs-04.txt draft-ietf-sipping-consent-framework-04.txt draft-camarillo-sip-consent-method-00.txt draft-camarillo-sipping-consent-reg-event-00.txt draft-camarillo-sipping-consent-format-00.txt draft-camarillo-sipping-grant-permission-00.txt draft-camarillo-sipping-list-state-00.txt Gonzalo.Camarillo@ericsson.com

  2. Status • Requirements in RFC Editor’s queue • draft-ietf-sipping-consent-reqs-04.txt • WG consensus on the framework • draft-ietf-sipping-consent-framework-04.txt • Drafts defining normative behavior to implement the framework • draft-camarillo-sip-consent-method-00.txt • draft-camarillo-sipping-consent-reg-event-00.txt • draft-camarillo-sipping-consent-format-00.txt • draft-camarillo-sipping-grant-permission-00.txt • draft-camarillo-sipping-list-state-00.txt

  3. Architecture PermissionRequest Permission Server Client Relay Translation Logic Permissions Permission Request Manipulation Permission Grant Recipient

  4. Permission Document Format • Based on the common policy format • Conditions • Actions • Transformations • New conditions • Sender • Target • New action • Trans-handling • Block • Pending • allow

  5. Permission Document Example <cp:rule id="1"> <cp:conditions> <cp:identity> <cp:id entity="bob@example.org" scheme="sip"/> </cp:identity> <target> <cp:id entity="alices-friends@example.com" scheme="sip"/> </target> <sender> <cp:any/> </sender> </cp:conditions> <cp:actions> <trans-handling>allow</trans-handling> </cp:actions> <cp:transformations/> </cp:rule>

  6. B’s Permission Server Add Recipient: B@example.com Pending A@example.com Relay B@example.com

  7. Adding Recipients • XCAP to manipulate URI lists • application/resource-lists+xml • New <consent-status> element <list name="friends"> <entry uri="sip:bill@example.com"> <display-name>Bill Doe</display-name> <cs:consent-status>pending</cs:consent-status> </entry> </list>

  8. B’s Permission Server Add Recipient: B@example.com SUBSCRIBE Event: list-state 200 OK Pending 200 OK 200 OK NOTIFY REFER Refer-To: B@example.com?method=CONSENT A@example.com Relay B@example.com

  9. List-state Event Package • Uses XCAP-diff to inform about changes in the state of the list • Open issue: do we want to use XCAP-patch as well? • New <consent-status> element • pending, granted, denied • Open issue: do we need more values? • Trying: CONSENT has been sent • Failed: Error response received for the CONSENT request <list name="friends"> <entry uri="sip:bill@example.com"> <display-name>Bill Doe</display-name> <cs:consent-status>pending</cs:consent-status> </entry> </list>

  10. B’s Permission Server Add Recipient: B@example.com SUBSCRIBE Event: list-state 200 OK Pending 200 OK 200 OK NOTIFY 202 Accepted REFER Refer-To: B@example.com?method=CONSENT CONSENT B@example.com Permission-Upload: uri-up’ Permission Document A@example.com Relay B@example.com

  11. CONSENT Request • Permission-Upload header field • URI where to send a PUBLISH uploading the permission document • Open issue: header field or part of the permission document?

  12. B’s Permission Server 202 Accepted 200 OK 200 OK NOTIFYuri-upPermission Document SUBSCRIBE Event: grant-permission A@example.com Relay B@example.com CONSENT B@example.com Permission-Upload: uri-up Permission Document

  13. Grant-permission Event Package • Uses XCAP-diff • Open issue: should it use XCAP-patch as well? • Open issue: client needs to delete permission documents • Provides • Permission document • Permission Upload URI • Open Issue: part of the permission document? <permit> <cp:rule id="1"> <cp:conditions> <cp:identity><cp:id entity="bob@example.org" scheme="sip"/></cp:identity> <cr:target><cp:id entity="alices-friends@example.com" scheme="sip"/></cr:target> <cr:sender><cp:any/></cr:sender> </cp:conditions> <cp:actions> <cr:trans-handling>pending</cr:trans-handling> </cp:actions> <cp:transformations/> </cp:rule> <upload>sip:upload@example.com</upload> </permit>

  14. B’s Permission Server 202 Accepted 200 OK NOTIFY 200 OK SUBSCRIBE Event: grant-permission PUBLISH uri-upPermission Document 200 OK 200 OK A@example.com Relay B@example.com CONSENT B@example.com Permission-Upload: uri-up Permission Document NOTIFYuri-upPermission Document

  15. Consent in REGISTRATION • Not applicable when sip-outbound is used • i.e., same connection to register and to receive traffic

  16. SUBSCRIBEEvent: reg-event 200 OK NOTIFY 200 OK A@example.com Registrar A@ws123.example.com

  17. Extension to reg-event • New <consent-status> element <registration aor="sip:user@example.com" id="as9" state="active"> <contact id="76" state="active“ event="registered“ duration-registered="7322" q="0.8"> <uri>sip:user@192.0.2.1</uri><cs:consent-status>pending</cs:consent-status> </contact></registration>

  18. REGISTERContact: A@ws123.example.comSupported: consent-reg 202 AcceptedRequire: consent-regTrigger-Consent: 123@registrar ?Refer-To=<A%40ws123.example.com> REFER 123@registrarRefer-To: A@ws123.example.com 200 OK A@example.com Registrar A@ws123.example.com SUBSCRIBEEvent: reg-event 200 OK NOTIFY 200 OK

  19. CONSENT A@ws123.example.comPermission-Upload: uri-upPermission Document 202 Accepted PUBLISH uri-upPermission Document 200 OK NOTIFY 200 OK A@example.com Registrar A@ws123.example.com REFER 123@registrarRefer-To: A@ws123.example.com 200 OK

  20. Request-contained URI Lists • The URI-list server maintains a list of URI for which it has permission • If the request-contained list has one or mode URIs for which there is no permission, an error is returned

  21. INVITEB@example.comC@example.com 470 Consent NeededTrigger-Consent: 123@relay.example.com ?Refer-To=<B%40example.com>Call-Info: 456@Relay;purpose=list-state ACK A@example.com URI-list Server

  22. Open Issues • Does a URI get added to the list just by arriving in a request? • Alternatively, clients need to use XCAP

  23. Way Forward • WG items?

More Related