1 CPCP Open Issues Hisham Khartabil XCON WG Interim Meeting, Boston 26 th May, 2004

2 CPCP Issue 16: Using resource URI as the key Many manipulations of a conference policy for a certain user require manipulation of the conference policy in multiple locations Eg: Adding a user to the DL, allowing him to dial in and making him a key participant requires 2-3 writes to the conference policy We have 4-5 lists that use resource URI: ACL DL PCL SCL (Key-participants List) Proposal: re-structure the XML schema to use the resource URI as the key allowed invite allowed refer Digest example.com blocked

3 CPCP Issue 1: External Lists There has been suggestions that external lists can be placed as a resource in the conference policy dial-out list or dial-in list Issue 1: Should we allow them? Proposal: Yes List1 on RLS1

4 CPCP Issue 1: External Lists (Cont.) Issue 2: How to represent them Proposal 1: Use XCAP URI The focus uses the XCAP list URI to fetch the URIs for the members of the external list. It then sends INVITE (in SIP terms) to the members of that external list lists/users/bob/list1.xml Proposal 2: The focus sends an INVITE to the list just like any other resource. It may result in a cascaded conference

5 CPCP Issue 1: External Lists (Cont.) Issue 3: What if the external list membership changes? Should the focus react in any way

6 CPCP Issue 2: Namespaces xmlns="urn:ietf:params:xml:ns:conference-policy" xmlns:conference-mp="urn:ietf:params:xml:ns:conference-mp" xmlns:conference-fp="urn:ietf:params:xml:ns:conference-fp" xmlns:conference-sc="urn:ietf:params:xml:ns:conference-sc" xmlns:conference-dl="urn:ietf:params:xml:ns:conference-dl" xmlns:conference-pcl="urn:ietf:params:xml:ns:conference-pcl" xmlns:conference-acl="urn:ietf:params:xml:ns:conference-acl" xmlns:conference-time="urn:ietf:params:xml:ns:conference-time" xmlns:conference-info="urn:ietf:params:xml:ns:conference-info" xmlns:conference-settings="urn:ietf:params:xml:ns:conference-settings"

7 CPCP Issue 2: Namespaces (Cont.) Why we did that? We envisioned that privileges will be assigned to users according to namespaces. So, if I want to give you permission to add people to the dial-out list, then in effect I am giving you write permission to that part of the XML document urn:ietf:params:xml:ns:conference-dl Proposal: Use one namespace What about privileges? Option 1: Use XPATH Option 2: semantic approach manipulate-dl

8 CPCP Issue 3: Wildcards in ACL Examples of allowed wildcards are - This basically says that we allow access control by domain Instead of We can have: sip:example.com OR introduce a domain element example.com New Schema

9 CPCP Issue 4: refer Currently, it is possible to ask the focus to refer users to the conference sip:example.com Does this really belong to the dial-out list? Arguments against: The focus is not really dialling out to the users, but merely referring them. DL tells the focus to dial-out. I.e. create a session with the participant. A second entry would be needed in the ACL Arguments for: The ACL seems to only need to accessed by the focus when it receives a request. The DL seems to be the set of actions taken by the focus to get it started. New Schema

10 CPCP Issue 5: Conflicting rules in ACL It is possible that a user creates conflicting rules in an ACL (e.g. both allowed and blocked action is defined for same target). Proposal 1: reject the insertion/creation using the transport protocol (409 in XCAP) Proposal 2: design the schema so the uri is an attribute. I fail to see how that helps Allowed Proposal 3: define clear ordering. Eg: Block is stronger than Allow.

11 CPCP Issue 6: Conference URI conflicts The user can suggest a conference URI. What if that conference URI already exists? Proposal: reject the insertion/creation using the transport protocol (409 in XCAP)

12 CPCP Issue 7: Conference URIs assignment Currently the ID says that the conference policy server must fill the conference URI(s), if a conference URI was not proposed by the client. Proposal: To make it XCAP friendly, we need to reject requests, using the transport protocol, if the creator does not suggest a conference URI

13 CPCP Issue 7: Conference URIs assignment (Cont.) Since a conference server may support, along with SIP, multiple session signalling protocols, does the server still create and populate the conference policy with additional URIs reflecting all the signalling protocols it supports that were not suggested by the creator? Proposal 1: client only suggests Proposal 2: client can suggest some, server can fill in the rest

14 CPCP Issue 8: Re-inviting/re-referring participants that dropped out or did not answer Participants can drop out of a conference for many reasons including: client crash, out of coverage, had to leave for a while. Proposal 1: Modify the conference policy by placing the same user again on the dial-out list. I.e. replacing the exiting entry for that user with exactly the same information. This triggers a notification that a change was made. This might not work will all transport protocols Proposal 2: Introduce an attribute into every target-uri in the dial-out list, say 're- invite', that has an integer value. When a user is needed to be dialled again, the 're- invite' value is increased by 1. The focus realises that 're-invite' value has increased and can then re-invite the user to join the conference. eg: The DL looks like the following and Alice has dropped out. Her entry in the DL is replaced by increasing recur to value 2. The focus is triggered, realises the change an re-invites Alice.

15 CPCP Issue 8: Re-inviting/re-referring participants that dropped out or did not answer (Cont.) Proposal 3: Re-write the whole DL. This triggers the focus to go through the DL a see which participants are currently participating and invite the ones that are not. This does not work very well since the focus might invite users that don't want to re-join. Proposal 4: Remove the user from the DL then add them again. This requires 2 round trips Proposal 5: Make the 're-invite' attribute a Boolean. Default is false. It is set to true when a user is needed to be re-invited. The focus then resets it back to false after it has invited the user Proposal 6: Focus should know if termination was abnormal and it is focus policy decision to re-INVITE (re-REFER). A user that gracefully dropped out can re-join if the moderator adds him/her to the ACL. I’m leaning towards 6.

16 CPCP Issue 9: Separate XML manipulation text from XCAP text Currently, the draft separates XML schema from XCAP There was a suggestion that the XCAP section needs to be reduced again to a very small section just defining the required sections for an XCAP usage document A separate section can then be introduced discussing how certain scenarios can be achieved (eg: adding a user to the conference) and what conference policy XML document manipulations are needed for such scenarios. This section also discusses how a focus reacts when a policy change was made.

17 CPCP Issue 10: Focus and XCAP server, how do they interact? The current version of the draft does not discuss at all how the focus and the conference policy server communicate. There are 2 proposals: WG chairs indicated that this is out of scope of the WG Proposal 1: Mention that it is out of scope of this document Proposal 2: Mention that it is out of scope of this document but suggest that a focus can use the XCAP (or config) event package. I believe this event package can be used regardless whether you use XCAP to manipulate the XML document or not.

18 CPCP Issue 11: Relating a sidebar to a conference Sidebars are not discussed in the current draft Sidebars can be thought of as just media policy manipulation Sidebars can also be thought of as a completely separate conferences from the main conference In both cases the conference policy might be needed to allow/disallow sidebars for a conference. Is this a valid requirement? Is it also a valid requirement that only participants in the main conference can be part of a sidebar?

19 CPCP Issue 12: Media policy vs. Media streams This document defines a very basic media policy that states the media types a conference has. This is used by the focus to know what media types to invite users with and what media types it should accept from dialling in users. This is not really media policy. It just defines the media streams that a conference offers or should offer. Proposal: Change the element name to or

20 CPCP Issue 12: Media policy vs. Media streams (Cont.) Should other SDP like attributes be also indicated? Eg: codecs, framerate, etc Proposal: This should be left to offer/answer negotiation between user and focus

21 CPCP Issue 13: Floor Control Policy 1

22 CPCP Issue 13: Floor Control Policy (Cont.) If you have a session that looks like this: v=0 o=example IN IP s=SDP Seminar c=IN IP /127 m=audio RTP/AVP 0 a=mid:1 m=video RTP/AVP 31 a=mid:2 m=video RTP/AVP 31 a=mid:3...and a CPCP document that looks like this:...then we've got two missing links.

23 CPCP Issue 13: Floor Control Policy (Cont.) 1.Which video stream corresponds to the which floor 2.How does one identify a floor? Proposal (by Adam): Add a "mid" attribute to each media type in the section. Add a "floor-control" attribute to each floor that contains information necessary for working with the floor.

24 CPCP Issue 13: Floor Control Policy (Cont.)

25 CPCP Issue 14: Key Participants I was agreed in the last IETF meeting that we need the concept of key participants in a conference policy. One of the reasons is that a conference focus would not start mixing media unless one key participant joins. 3 options: In the ACL or DL, we introduce an attribute named 'role' with values "key-participant", "participant". The attribute would be optional and has default value of "participant" if not present. In the ACL or DL, we introduce a Boolean attribute name 'key- participant'. Have a separate list. This disadvantage here is that whenever a new key participant is added to the conference, 2 changes are needed to the conference policy in 2 different places. This might be possible with one XCAP PUT, if the proposed addition is made to XCAP. New Schema

26 CPCP Issue 15: Start/Stop times Currently conference start time and stop time can only be represented as follows and do not satisfy the recently agreed requirements: T10:00:00Z T12:00:00Z In order to satisfy the requirements, the following is proposed: REQ-A9: It MUST be possible to define the time when media mixing may start ("don't-mix-before-time") and stop ("cannot-continue-after") operating in the conference. Proposal: Change and to and

27 CPCP Issue 15: Start/Stop times (Cont.) REQ-A10: It MUST be possible to define the time after which users are allowed to join the conference. Proposal: Introduce element REQ-A11: It MUST be possible to define the time after which new users are not allowed to join the conference anymore. Proposal: Introduce element REQ-A12: It MUST be possible to define the time when users or resources on the dial-out list are invited to join the conference. Proposal: Introduce elements REQ-A13: It MUST be possible define whether the conference can be extended. Note: This does not guarantee that resources are available. Proposal: This can be achieved by documenting that can be changed to later time

28 CPCP Issue 15: Start/Stop times (Cont.) REQ-A15a: It MUST be possible to define when media mixing starts based on the latter of the mixing start time, and the time the first participant arrives. REQ X15b: It MUST be possible to define when media mixing starts based on the latter of the mixing start time, and the time the first key participant arrives. Proposal: Introduce attribute 'require-participant' in with values "key-participant" and "participant". REQ-A16a: It MUST be possible to define when media mixing stops based on the earlier of the mixing stop time, and the time the last participant leaves the conference. REQ-A16b: It MUST be possible to define when media mixing stops based on the earlier of the mixing stop time, and the time the last key participant leaves. REQ-A16c: It MUST be possible to define when media mixing stops based on the time only. Proposal: Introduce attribute 'require-participant' in with values "key-participant" and "participant". REQ-A17: It MUST be possible to define that the users and resources on the dial- out list are invited only after first key participant has joined. Introduce attribute 'require-participant' in with values "key- participant" and "participant". Is "participant" needed? If no, then this attribute can be boolean