XCON Notes Morning, Wed 27 May, 2004
Adam Roach firstname.lastname@example.org
Alan Johnston email@example.com
Aki Niemi firstname.lastname@example.org
Allison Mankin email@example.com
Anwar Siddique firstname.lastname@example.org
Asher Shiratzky email@example.com
Ben Campbell firstname.lastname@example.org
Bill Marshall email@example.com
Brain Stucker firstname.lastname@example.org
Chris Boulton email@example.com
Christer Holmberg firstname.lastname@example.org
Christian Schmidt email@example.com
Christian Stredicke firstname.lastname@example.org
Cullen Jennings email@example.com
Cyrus Shaoul firstname.lastname@example.org
Dan Petrie email@example.com
Dean Willis firstname.lastname@example.org
Dorothy Gellert email@example.com
Francois Audet firstname.lastname@example.org
George Foti email@example.com
Gonzalo Camarillo firstname.lastname@example.org
Henning Schulzrinne email@example.com
Henry Sinnreich firstname.lastname@example.org
Hisham Khartabil email@example.com
John Elwell firstname.lastname@example.org
John Lawser email@example.com
Jon Peterson firstname.lastname@example.org
Jonathan Rosenberg email@example.com
Keith Drage firstname.lastname@example.org
Kumiko Ono email@example.com
Kwok Ho Chan firstname.lastname@example.org
Mahfuzur Rahman email@example.com
Mark Zeren firstname.lastname@example.org
Markus Isomaki email@example.com
Martin Dolly firstname.lastname@example.org
Mary Barnes email@example.com
Mauren Stillman firstname.lastname@example.org
Miguel Garcia email@example.com
Mihko Lonnfors firstname.lastname@example.org
Orit Levin email@example.com
Peter Mataga firstname.lastname@example.org
Radhika Roy email@example.com
Robert Sparks firstname.lastname@example.org
Rohan Mahy email@example.com
Roni Even firstname.lastname@example.org
Shida Schubert email@example.com
Ted Hardie firstname.lastname@example.org
Thomas Froment email@example.com
Tom Phelan firstname.lastname@example.org
Umesh Chandra email@example.com
Volker Hilt firstname.lastname@example.org
Yaron Reinharts email@example.com
Issue: Establishment. Note: We are going to need a way to tie audio channels to floor IDs, either in CPCP, SDP, or both.
Noted: Requirments doc may need to address the SDP approach as well.
Issue: Do we need a BFCP URI in the SDP? This could eliminate ten pages of text from the draft. When used with CPCP, we could express the relevant data as CPCP attributes.
Issue: Co-Media. We will use a "the client connects to the server unless there is other information" in order to avoid a direct dependence on co-media.
Issue: There must be some kind of link between the thing doing the floor control (the media element) and the thing doing the SIP signaling.
Noted that the conference framework already covers a lot of this.
Noted that there is no requirement to use SIP with a conference. It is legitimate to have a conference made up of jabber and RTSP sreams. This means that every stream needs an identifier, and that the only arbitrator of the stream indentifiers is CPCP.
Need to clarify terms:
Agreement: One can use O/A to establish a floor control relationship.
Question: Can one exercise a floor control relationship without using O/A? Discussion seems to be "yes".
Issue: Transport. Argued that SCTP seems to be unattractive as a second protocol choice, and that the specification of multiple protocol transports has been hard, we should consider using just TCP.
Argued that this doesn't work in some mobile environments, and that UDP may be required, especially for notifications. Does this lead to seperating the floor control protocol from the floor notification protocol?
Another possibility would be to have the option to suppress notifications within the floor control protocol, and optionally engage a second protocol for lightweight, non-confirmed notifications.
Discussion around TCP start timers, etc. continued, and appeared to deliver a consensus that the latency aspects of TCP could be tuned to be effective in the FCP role for mobile networks.
The room was polled for consensus on only TCP for floor control protocol. There was no objection noted.
The room was polled for consensus of SUN RPC data representation. There was a strong consensus AGAINST this proposal.
The room was polled for TLV representation. This was agreed, provided we change the corresponding requirement from "Bandwidth efficient" to set specific target numbers for "mandatory elements exclusive of authentication must not exceed 60 bytes"
Issue: Privacy. We seem to have a requirement that precludes other participants from knowing the identity of a floor requester. This protection MUST persist across revelations of identity through speech. That is, the other users should not be able to learn from observation how to correlate the floor control ID used in a floor control request with the identity of the user requesting the floor, when floor privacy mode is engaged. This does not place any requirements on floor privacy mode, as to whether it is activated per user or per floor or per conference.
Discussion: Should we adopt this as a working group effort? Most people agree, although several argue that certain aspects are too immmature to declare a direction on. It was proposed that the document could contain discussion around these aspects, indicating that they are not permanently fixed. It was also requested that usage cases be documented in the draft, and that overall usage cases be establishedas part of the conference framework. Poll on acceptance: One opposed, indicating that rough consensus favors adoption.
Issue: Instance identifiers. Noted that the current text seems to conflate with SIP dialog IDs and probably needs some clarification.
Issue: media stream labeling in a conference. Discussion centered around the label term as "just a label within the scope of a conference". They can be constructed to correlate with SDP.
Issue: Constructing a Coherent State using Partial Notifications. No comments.
Issue: Anonymous Participation. No comments.
Issue 16: Using Resource URI as Key. Proposal to invert the XML schema seems to be agreeable in general. This may require using wildcards in the resource URI to represent domains. However, this could make for problematic expression when a single user is represented by multiple autehnticated identities within a call. It is arguable that this means that some of the reource elements need to be indexed by a URI, some by an ID, etc. The primary issue is around the dial-out list, which appaently doesn't fit the model of permissions inverted back under the AOR indices.
Issue 1: External Lists
Proposal: Continue as-is, allowing external lists. Need to address temporal relationships. What happens if list changes or becomes unavailable between the time the conference is set up and the time it is actuated?
Issue 2: Representing and Using External Lists
Option 1 is to use XCAP or event-list to retrieve/expand the list. This seems to be non-controversial.
Option 2 as given is to send the INVITE to the list. This appears to be non-functional, but easily confused with INVITEing a URI served by another domain, which just happens to be the URI of a conference which also has a dial-out list.
Discussion of this raised the issue that XCAP-lists could be redefined to vertically compose, such that if a referenced list changed, the referencing list would also indicate a state change event. This approach was agreed to.
CPCP Issue 2: Namespaces We need a semantic, rather than syntactic, approach to this problem. This roughly corresponds with Option 2. No concousion.
CPCP Issue 3: Wildcards in ACL. Proposed are "*" token-replacing wildcards. We may also wish to think about this from an identity presentation approach, and consider tel:URI and otehr formats. No conclusion.
CPCP Issue 4: Refer. Do referred-in conference members go into the dial-out list? This would also seem to require an acl addition, too. Discussion favored a two-list approach, but was inconclusive.
CPCP Issue 5: Conflicting rules in ACL. This can be addressed by use of common policy or by Proposal 3, prioritizing the rules. Suggested that we defer this discussion until after the discussion of common policy.
CPCP Issue 11: Relating a Sidebar to a Conference. The conference framework team in SIPPING has greatly refined the sidebar concept and it appears that this work should be applicable.
Questions: would the is-key-participant tag entity need to be further qualified, like conditions under which someone is a key participant?
Durther discussion centered on explanation of the common policy syntax and model, with numerous use cases explained.
Suggested that we should define our own "common policy" that is similar to the existing work, but more specifically adapted to our needs.
Poll: Who thinks we should stay with approach in CPCP? A few.
Poll: Who thinks we should go to a Common-POlicy Like approach? More.
Poll: WHo thinks we need to talk more about it. A few.
The chair reported a judgement of rough consensus in favor of moving toward common policy.
Note from Chairs: None of these drafts have been revved lately. The chairs will designate a small design team and is soliciting for volunteers.
Slides review CPCP/MPCPnaming heirarchy
Comment: If an output aggregration stream is directably subscribable, one could bypass it and go direct to the component.
Question: Why bother with templates? It seems this approach has nothing to add. This devolved into a discussion of composite-in versus composite-outs. If the template as viewed as a compositor that still makes the components available, one needs to be able to reference those outputs from the context of the templat. This leads to a need to have component outputs corresponding to the component inputs of a template. Consequently, these component outputs can be referenced as the inputs to other elements.
Question: Does floor control operate inside the media policy, or does it change the media policy?