august 2005ietf63 - xcon1 some xcon ideas henning schulzrinne dept. of computer science columbia...

8
August 2005 IETF63 - XCON 1 Some XCON ideas Henning Schulzrinne Dept. of Computer Science Columbia University [email protected]

Upload: tiffany-black

Post on 05-Jan-2016

212 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: August 2005IETF63 - XCON1 Some XCON ideas Henning Schulzrinne Dept. of Computer Science Columbia University hgs@cs.columbia.edu

August 2005 IETF63 - XCON 1

Some XCON ideas

Henning SchulzrinneDept. of Computer Science

Columbia [email protected]

Page 2: August 2005IETF63 - XCON1 Some XCON ideas Henning Schulzrinne Dept. of Computer Science Columbia University hgs@cs.columbia.edu

August 2005 IETF63 - XCON 2

Assumptions

• Avoid transactions and similar constructions– difficult to implement request is atomic

• Map closely to existing conference data structures– avoids having to maintain two similar, but different structures– use superset of existing structure

• Avoid two-level mechanism• Re-use well-known RPC mechanism• Use inheritance (no templates)

– closely related concepts – confusing to have both

• Affinity to CCCP, but further simplified

Page 3: August 2005IETF63 - XCON1 Some XCON ideas Henning Schulzrinne Dept. of Computer Science Columbia University hgs@cs.columbia.edu

August 2005 IETF63 - XCON 3

Avoid two-level design

“dial-out user”

get/set/deletesomething

adds little abstraction depth

Page 4: August 2005IETF63 - XCON1 Some XCON ideas Henning Schulzrinne Dept. of Computer Science Columbia University hgs@cs.columbia.edu

August 2005 IETF63 - XCON 4

Re-use RPC

• No need to design yet another remote procedure call (RPC) mechanism

• Use SOAP – not prettiest, but by far the most popular– clients, servers, tools available in just about

any language and OS• don’t know about Fortran and COBOL

– well-understood by developer community– no need for protocol-level testing

Page 5: August 2005IETF63 - XCON1 Some XCON ideas Henning Schulzrinne Dept. of Computer Science Columbia University hgs@cs.columbia.edu

August 2005 IETF63 - XCON 5

Example

• Does not include standard SOAP header

• e.g., addConference

<conference-description><subject>XCON</subject><service-uris><entry><uri>http://example.com/</uri><purpose>web-page</purpose></entry></service-uris></conference-description>

Page 6: August 2005IETF63 - XCON1 Some XCON ideas Henning Schulzrinne Dept. of Computer Science Columbia University hgs@cs.columbia.edu

August 2005 IETF63 - XCON 6

Operations (~CCCP)

• add/change/get/deleteX– Conference– User– Endpoint– Media (for all users)

Page 7: August 2005IETF63 - XCON1 Some XCON ideas Henning Schulzrinne Dept. of Computer Science Columbia University hgs@cs.columbia.edu

August 2005 IETF63 - XCON 7

Open issues

• For adding users, can request fail partially– may want to add lots of users at once– add some users, but not others– generally want to proceed even if one user

fails– can find out who got added by description

returned

Page 8: August 2005IETF63 - XCON1 Some XCON ideas Henning Schulzrinne Dept. of Computer Science Columbia University hgs@cs.columbia.edu

August 2005 IETF63 - XCON 8

What’s missing?

• Simple start/end time property for conference– no repeats or the like

• Conference media mixing– add floor control property to media– add moderator(s) to user property– define some standard algorithms for now

• tiled: ““video follows audio”• no video mixing: “individual”• extend later

– define video matrix• (label, width, height)