XCON Meeting Minutes
Friday July 31, 2009
Chairs: Alan Johnston, Adam Roach

CCMP

New version: draft-ietf-xcon-ccmp-03

Presenter: Simon Pietro Romano

CCMP requests are carried in HTTP POST messsage, and responses are carried in 200 response.

Complies with XCON data model.

New error responses: userNotFound and invalidConfUserID

Assumption is that users (and profiles) are not created via

CCMP, rather, it is for adding existing users to a conference.

Mary Barnes: I agree.

Alan Johnston: I want to clarify that it's the user of the CCMP protocol?

Simon: Until you are in a conference, you are a user, but not a conference user

Mary Barnes: All participants must be users. If somebody dials from the PSTN dials in, it needs to be some sort of user. Maybe we need to think about it.

Simon: This protocols manipulates conference objects. Creating users  are something different.

Discussion on if we need a mechanism to create users are to be moved to the list.

Open issues:

1.     How to behave in the case  of "success" with "create" and/or "update" operations? Should we extend such approach also to responses carrying a response code of "modified"?

Preference is to not include the payload in the response, so that implementor use always and explicit query for information when required.

2.     When creating sidebars or conferences through blueprint cloning: Should we include the modifications that we want to be applied to the cloned object directly in the cloning request?

 Mary Barnes: Use similar treatment as previous.

 Simon: First create the new object, then update the newly created object.

Recommendation is to have a single request, but allow the two  steps process as well.

3.     Should we consider adding "filters" to CCMP requests?

 e.g., give me just active conferences, or give me blueprints associated with "no video" content

Goal is to reduce traffice and avoid overwhelming clients. This is not in parameter now: could be xpath queries.

Mary Barnes: It was in the use cases.

Adam Roach: Personally, I think this is a useful feature

Adam Roach is requesting dedicated document reviewers reviewers.

Jonathan Lennox, Tom Kristensen & Simo Veikkolainen are volunteers for reviewing. Roni Even *might* find time to review.

Richard Barnes will replace Adam Roach as co-chair moving forward.

XCON examples

Presenter: Lorenzo Minjero

WG document aligned with draft-ietf-xcon-ccmp-03. Integrated with MEDIACTRL.

Scenarios: Conference creation, General Examples, Sidebars

Conference creation: using cloning from default, driven with descripbion, or cloning from existing conference or a blueprint.

Open Issues

Parent/child for blueprint

Protocol says that when cloning is done, there is a clear parent/child relationship. But there is no guidance on the case where a blueprint in cloned? Current draft assume that there is no <cloning-parent>.

Mary Barnes: We don't think we need blueprint cloning to inherit the parent/child property.

 Consensus from group. To confirm on mailing list.

Adding a party

Several approaches: userRequest/create (current approach in document) or userRequestUpdate.

<password> was added to CCMP. Is this sufficient? Or do we need both a password and an IVR mechanism.

Jonathan Lennox: Need strong notion of SIP identity which is tought.

Adam Roach: We want to make sure it works well with non-voice conferences (e.g., text).

Question: Is password enough?

 Next version of draft will have both password, and password + IVR.

Muting a party

Update to send "recvonly".

Conflicts with BFCP. We could assume it's a wrapper to BFCP. Prefers to have double level of muting/unmuting.

Consensus: weĠre better off having CCMP muting operate independently of BFCP muting.

Sidebars

Internal or external sidebars?

Chose to use sidebars by val for internal, and sidebar by ref for external. But both are allowed.

Future work

Correct scenarios, add new ones.

SDP Source Selection

Presenter: Jonathan Lennox

Warning: we have potential IPR on this.

This draft defines a way to request sources using SDP.

RFC 4575 doesn't specify the representation of SSRC values in src-id. Presumably interpret as 32-bit network byte order.

Jonathan will post summary to XCON list.