1 / 10

CPCP

CPCP. Hisham Khartabil XCON WG IETF 61, Washington D.C. 8 th November, 2004 hisham.khartabil@nokia.com. Simplifications. Removed floor creation (MPCP issue) Removed floor assignment algorithm (MPCP issue) Removed media correlation Ids (MPCP issue)

quant
Download Presentation

CPCP

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. CPCP Hisham Khartabil XCON WG IETF 61, Washington D.C. 8th November, 2004 hisham.khartabil@nokia.com

  2. Simplifications • Removed floor creation (MPCP issue) • Removed floor assignment algorithm (MPCP issue) • Removed media correlation Ids (MPCP issue) • Simplified media to audio, video, IM, or any combination • Number of streams of the same media and codec restrictions are MPCP issues

  3. In case you haven’t noticed • Draft-ietf-xcon-cpcp-xcap-01 was split into 3: • Conference policy. draft-ietf-xcon-cpcp-00.txt • Conference policy privileges. draft-ietf-xcon-conference-policy-privileges-00.txt • XCAP Usage. draft-ietf-xcon-cpcp-xcap-02.txt

  4. Other changes • Updated security sections for each draft • Removed common policy from schema and just imported it • Added text that <sphere> is ignored • Changed <any> under <identity> to its own <any-identity>

  5. Open Issues

  6. Conference URI creation • Current text in and suggests that a conference URI can be assigned by a conference server • This text is old and wrong. It is the client that assigns the conference URI. The server either accepts or rejects the URI suggested by the client. If it rejects it, it can suggest alternatives • When using XCAP, the alternatives can be communicated in the body of a 409 response. • The conference server can still create additional conference URIs for other signalling protocols

  7. Interpreting the <id> Element • Last IETF we agreed that we will add text interpreting the <id> element for a couple of signalling protocols • We asked interested people to suggest text for protocols other than SIP • SIP text will be copied from presence-authorization documents in SIMPLE • No text has been received yet

  8. “block” in <join-handling> • No rule for a user means a user is denied joining to a conference • Why do we need a “block” value in <join-handling>? • Completeness • Expelling • Proposal: keep.

  9. <actions> and <transformations> Relationship • It is obvious that a <condition> must pass before any <actions> or <transformations> take place • Does the same apply to <actions> and <transformations>. I.e. Must an action allow a user to join a conference before any transformations take place • The believe not, what do common policy folks think? <conditions> <identity> <id>hisham.khartabil@nokia.com</id> </identity> </conditions> <actions> <join-handling>block</join-handling> <transformations> <key-participant/> </transformations>

  10. Conference URI Creation • Agreed that client suggests and server accepts or rejects and has the final say • If server rejects, should it create one or give user further suggestions? • Proposal: server gives user suggestions. eg: user suggests my-weekly-conference@example.com. Server rejects it but suggests the following my-weekly-conference1@example.com my-weekly-conference2004@example.com The user can choose one of the 2 above or suggest a different one like: hisham-weekly-conference@example.com

More Related