CPCP

1
CPCP

• Hisham Khartabil
• XCON WG
• IETF 61, Washington D.C.
• 8th November, 2004
• hisham.khartabil_at_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 havent 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-conf
  erence-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 ltspheregt is ignored
• Changed ltanygt under ltidentitygt to its own
  ltany-identitygt

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 ltidgt Element

• Last IETF we agreed that we will add text
  interpreting the ltidgt 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-authorizatio
  n documents in SIMPLE
• No text has been received yet

8
block in ltjoin-handlinggt

• No rule for a user means a user is denied joining
  to a conference
• Why do we need a block value in
  ltjoin-handlinggt?
• Completeness
• Expelling
• Proposal keep.

9
ltactionsgt and lttransformationsgt Relationship

• It is obvious that a ltconditiongt must pass before
  any ltactionsgt or lttransformationsgt take place
• Does the same apply to ltactionsgt and
  lttransformationsgt. 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?
• ltconditionsgt
• ltidentitygt
• ltidgthisham.khartabil_at_nokia.comlt/idgt
• lt/identitygt
• lt/conditionsgt
• ltactionsgt
• ltjoin-handlinggtblocklt/join-handlinggt
• lttransformationsgt
• ltkey-participant/gt
• lt/transformationsgt

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_at_example.com
  . Server rejects it but suggests the following
• my-weekly-conference1_at_example.com
• my-weekly-conference2004_at_example.com
• The user can choose one of the 2 above or suggest
  a different one like hisham-weekly-conference_at_exa
  mple.com