[Note: these notes do not constitute official minutes; they are supplimental notes contributed by Spencer Dawkins, and are included here for additional information] 0900 - 0905 Agenda Bash Chairs (5 minutes) 0905 - 0910 Status Chairs (5 minutes) Scenarios document is ready for WGLC MPCP Media team is making progress CPCP requirements mostly finished (still integrating WGLC comments), protocol document will be split into schema and transport to aid in document review BFCP requirements complete, protocol still under development SIPPING conference package is proposed to split -- roster stays in SIPPING, Media and Policy moves to XCON -- split needs to be carefully scoped -- want to make sure policy stuff stands on its own -- how can we close this in SIPPING when we have so many open issues in XCON? 0910 - 0930 Updates to the SIP Conferencing Package Orit Levin (20 minutes) draft-ietf-sipping-conference-package-05.txt Current draft has changes to conference level (partial notifications, recording/streaming, and sidebar), user level ( added "role", renamed to "muted-via-focus", added "user-status-type" values, renamed "media-stream" to "media"), and addition of session level). Cullen has proposed a different structure under "conference" -- adding a "sessions" level of hierarchy between user status and media streams Should we have the same package for participants and moderators? Q&A: Can sidebars contain sidebars? Yes Can you remove a sidebar? Yes, need to make sure we know how. Will you remove sidebars from the SIPPING version of this document? Not my intention. Sidebars still have attributes you wouldn't set for a normal conference -- can we really nail down sidebars while they are still being worked in XCON? We need to finish the work in XCON, not decouple it from SIPPING. Is "user-level" really "user" or "session"? If I have two phones, both ring, but I answer one. How do we handle userids that are not unique (when a user has more than one session)? May have non-unique userids because of a number of reasons (home phone account reuse by family members) -- but maybe we don't need to solve this problem (anonymous users can still be anonymous, but they aren't all one user). Can the SIPPING conferencing design team make a proposal on identification by Friday? 1930 - 2000 Sidebars Alan Johnston, Brian Rosen (30 minutes) draft-rosen-xcon-conf-sidebars-01.txt Want to do detailed discussion of signaling dialog/session reuse for sidebars, detailed sidebar requirements, and SIP/CPCP/Conference Package call flows. Document needs to be clearer on reuse, especially when some media go to the sidebar and some don't. Rohan did the "this is not just for SIP" rant -- need to include PSTN conferencing, too -- need more examples in the document -- but the media requirements aren't SIP-specific. Aren't we recreating H.245 all over again? If a sidebar was a specific thing, we wouldn't be rewriting H.245 in XML instead of ASN.1. Problem is that we're complicating things when we reuse signaling dialog. There is no PSTN way of doing sidebars today using signaling. Should it be possible to do a sidebar with an RTP stream that the conference bridge doesn't have keys to? Yes, with fully distributed mixing. But this is all done by the application today -- there's nothing to break -- but the SIP user agent on the other side now needs to do multiple dialogs -- but the phone needs to be changed to be in two conferences simultaneously anyway -- sidebars are sort of separate conferences, and sort of not, and this is an architectural issue when we try to add anything (see floor control as example of confusion), and this is only going to get worse over time -- we do sidebars in CPCP just so we can support black phones. Many sidebar requirements are already covered by CPCP and SIP, because they are similar to main conferences. But there were some missing -- all these requirements should be handled in CPCP directly. Focus should be able to handle secured sidebar conversation with different keys (this is what you naturally want for a private conversation, right?). There are some additional security considerations for sidebars. Can meet missing requirements in CPCP or use a SIP re-INVITE (need an SDP attribute saying "currently in/should be in a sidebar"). In H.323 you have a separate protocol (H.245) to change media, in SIP, you do re-invites. 2000 - 2100 Media Policy XCON Media Design Team (60 minutes) draft-jennings-xcon-media-control-01.txt Design team meeting weekly, still have some work to do. Will use both Templates and Flow Graphs -- everybody supports templates, some endpoints may also support flow graphs as a way of building templates. Templates are about roles, streams, controls over streams, and parameters that specialize a template. Extend a template into another template? Still thinking about this. Assuming XCAP as transport, but haven't had a lot of discussion about this. Parameter values are set when a conference is instantiated -- this is how they differ from controls that are more dynamic. Roles define the streams and controls available to participants. Conference package maps SDP to a stream name. Control idea is to provide basic level of functionality for endpoints that don't understand a specific template. Templates design (potentially more than one) floor. Have not synchronized with floor control design team yet. Design team needs one more spin at this document. Q&A Design team spending a lot of time thinking about user interface presentation -- need to keep the HTML vision that focuses on high-level semantics, not low-level attributes. Why did you choose inheritance from participants down, instead of a flat model? If roles are additive, ACLs are simpler, and gives the same effect. Conference Policy Control Protocol (CPCP) Hisham Khartabil (60 minutes) draft-ietf-xcon-cpcp-xcap-01.txt Requirements document went through WGLC -- main issue was that requirements document didn't tie to the framework document, especially for definitions, floor control policy, and media policy requirements. We didn't issue framework document as an RFC, just so we can handle additions like floor control and media policy. Introduced Common Policy to replace ACL and PCL, added conditions, transformations, pin and password, and allowed the user of pins and passwords tied to an identity. Pin and Password really are authenticated identities -- should reflect this at a higher level -- no, pin and password can be used by an unauthenticated identity -- and anonymous is just a string, it's not special, and we need to avoid confusion on this. Roster policy is another policy -- we haven't talked this through yet. Doesn't have to matter how a user joins a conference (password, pin, or something else). Pins and passwords for a conference aren't like pins and passwords for a user -- may not even be specified using the same applications. And public key-based mechanisms are still something else. And a PSTN asserting "this is Cullen's phone" is still something else again. Authentication is when you dial into a bridge; this is something else, when you join a conference. We need some use cases to tease out the different things people are trying to do. How do things work when you don't have an identity to base a challenge on? We're confusing things between identities and conference identifiers -- you may have one, the other, or both. Please send use cases to the mailing list! Hisham has also added text on how to use external lists, removed use of wildcards, removed additional namespaces from XML Schemas, added Refer-list, aligned URI assignment and conflicts solutions with list-usage in SIMPLE, minimized the XCAP section, declare that interface between focus and conference policy server out of scope, introducted concept of sidebars/sidebar URIs, changed media-streams, added media ID to allow correlation between media and floor, solved Key-participant problem, changed conference-time to reflect WG consensus, added privilege, plus editorial changes. Issues: Do we need to say more about interpreting elements? Needs to tie to specific signaling protocols -- SIP and H.323? SIP and XMPP? Anything we have text for? How many conference states do we need? In how many pieces? Recommend leaving section the way it is now -- could add states later -- but we haven't defined the conference state yet... leave this simple -- we'll add "confirm". Similar issue with floor control events -- same resolution? OK. "Show Conference information" is all-or-nothing -- more granularity? Leave as it is for now. Do we really need a separate refer list? We said "yes" in the last meeting. Just need more text explaining why this is needed. vs ? Lack of in conditions means any user -- remove ? OK. Media Stream Security Policy? Needed? General or per media type? Don't know all the media types that might be used. Is this part of media policy? Is this a local decision for the focus? Is it enough to say, "I want this conference secured"? Do we need to talk about specific mechanisms? What is media policy, and what is conference policy about media? Does "secured" mean signaling and media? What if I don't have processing power to do secure media? We're headed for creating ad hoc security groups and we don't know what we're doing -- turn to MSEC WG for help with complex scenarios.