1 / 14

draft-levin-xcon-cccp-03.txt

draft-levin-xcon-cccp-03.txt. Orit Levin oritl@microsoft.com Roni Even roni.even@polycom.co.il Pierre Hagendorf pierre@radvision.com. Introduction. An updated and extended version since -02 – a result of an implementation experience A new protocol

carsyn
Télécharger la présentation

draft-levin-xcon-cccp-03.txt

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. draft-levin-xcon-cccp-03.txt Orit Levin oritl@microsoft.com Roni Even roni.even@polycom.co.il Pierre Hagendorf pierre@radvision.com XCON WG, IETF64

  2. Introduction • An updated and extended version since -02 – a result of an implementation experience • A new protocol • Not data manipulation (vs. XCAP, WEBDAV), rather object manipulation • Runs on an arbitrary reliable transport but does NOT rely on the underlying transport transaction model (vs. SOAP/HTTP) XCON WG, IETF64

  3. Transaction Model • A transaction client-server protocol • Two types of operations: “request” and “response” • Two final responses ("failure" and "success“) and a provisional (“pending”) response are defined • A client issues requests to a server. A server MAY reply with multiple provisional responses before replying with the final response • The server MUST reply with a single final response XCON WG, IETF64

  4. Request Attributes • requestId: A unique string generated by the CCCP client across all its requests • from: A transport URI of the the CCCP client • to: A transport URI which of the CCCP server • originator: A trusted ID of the originator of the request XCON WG, IETF64

  5. Response Attributes • requestId: The original request ID generated by the client and echoed as is by the server • from: A transport URI of the CCCP server • to: A transport URI of the CCCP client • code: The general response code: success, pending, or failure • reason: The general CCCP failure reason • serverBusy • unauthorized • requestMalformed • requestTooLarge • requestCancelled • notSupported • otherFailure • timeout: The updated timeout used with pending responses • retryAfter: The suggested delay used with serverBusy responses In addition, each primitive response defines a dedicated optional set of response codes XCON WG, IETF64

  6. Multiple Primitives ina Single Operation • A single CCCP operation MAY include multiple primitives • Multiple primitives within the same request MUST be executed as an atomic operation. • The primitives within the request operation MUST be performed by the CCCP server one-by-one in the order they appear in the request body. • The corresponding response operation MUST include the response primitive for each of the issued primitives in the exact same order. Note, that the primitives inside the operation bodies are not numbered. • We don’t make usage of this feature in our current implementation • Instead we defined a dedicated primitive each time an atomic property is desirable XCON WG, IETF64

  7. The Object Manipulation Approach • The object is identified by keys and accessed directly without navigating through the whole XML document tree • The sub-elements are accessed, set and modified through the parent object • The currently identified objects are <conference>, <user>, <endpoint>, <media>, <sidebar> • The response codes carry application semantics and can be defined per object per primitive XCON WG, IETF64

  8. A Typical Object Manipulation Primitive <addUser> <conferenceKeys confEntity="sip:conf233@example.com"/> <user entity="sip:bob@example.com“ xmlns="urn:ietf:params:xml:ns:conference-info"> <display-text>Bob Hoskins</display-text> <roles> <entry>presenter</entry> </roles> </user> </addUser> XCON WG, IETF64

  9. Not Object Manipulation Primitives • Define dedicated primitives for operations where at least one the following properties are desirable • Atomic execution (moveUserToSidebar) • Applied to a set of objects (getBlueprints) • Efficiency (modifyUserRoles) • A CCCP server can choose to provide multiple ways (i.e. different primitives) to achieve the same result XCON WG, IETF64

  10. Example <moveUserToSidebar> <userKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com"/> <from>sip:conf233.3@example.com</from> <to>sip:conf233.7@example.com</to> </moveUserToSidebar> XCON WG, IETF64

  11. CCCP and Events • For CCCP clients that don’t natively run SIP, the SIP Events Mechanism can be run using the CCCP additional operation “notify”. • The events logic mechanism uses the SIP Events framework and the SIPPING Conference Package semantics and format • The effect of the SIP re-SUBSCRIBE operation is achieved by CCCP getConference() primitive XCON WG, IETF64

  12. The CCCP Notification Mechanism Logically Runs in Parallel to its Control Client Server SIP Client CCCP Request CCCP Request Control Mechanism Control Mechanism Control Mechanism CCCP Response CCCP Response SUBSCRIBE Notifications Mechanism Notifications Mechanism Notifications Mechanism CCCP Notify NOTIFY XCON WG, IETF64

  13. Next Steps • If XCON WG decides to build on this direction, CCCP is open to modifications • If XCON WG takes a different CCP approach, we are planning to publish this draft as an Informational XCON WG, IETF64

  14. Thanks… XCON WG, IETF64

More Related