1 / 28

CPCP Open Issues

CPCP Open Issues. Hisham Khartabil XCON WG Interim Meeting, Boston 26 th May, 2004 hisham.khartabil@nokia.com. Many manipulations of a conference policy for a certain user require manipulation of the conference policy in multiple locations

christianm
Download Presentation

CPCP Open Issues

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CPCP Open Issues Hisham Khartabil XCON WG Interim Meeting, Boston 26th May, 2004 hisham.khartabil@nokia.com

  2. 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 <resource name=“bob”> <uri>sip:bob@example.com</uri> <access>allowed</access> <dial-out>invite</dial-out> <key-participant/> <moderator floor-id=“abc”/> <privileges> <conf-event-package> <privileges> </resource> <resource name=“alice”> <uri>sip:alice@example.com</uri> <access>allowed</access> <dial-out>refer</dial-out> <Auth-mechanism password="1a2b3c4d">Digest</Auth-mechanism> </resource> <resource name=“example”> <domain>example.com</domain> <access>blocked</access> </resource> CPCP Issue 16: Using resource URI as the key

  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 (list1@example1.com) on RLS1 has: • bob@example1.com • alice@example1.com

  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 <DL-target-URI>http://xcap.example1.com/services/presence-lists/users/bob/list1.xml</DL-target-URI> • Proposal 2: • The focus sends an INVITE to the list just like any other resource. It may result in a cascaded conference <DL-target-URI>sip:list@operator.com</DL-target-URI>

  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 <uri>sip:alice@example.com</uri> <access access-type=“read”> <namespace>urn:ietf:params:xml:ns:conference-dl</namespace> <document> http://xcap.example1.com/services/conference/users/bob/list1.xml </document> • Proposal: Use one namespace • What about privileges? • Option 1: Use XPATH <uri>sip:bob@example.com</uri> <access access-type=“read”> <document> http://xcap.example1.com/services/conference/users/bob/list1.xml/~~/DL </document> • Option 2: semantic approach <privilege>manipulate-dl<privilege>

  8. CPCP Issue 3: Wildcards in ACL • Examples of allowed wildcards are - sip:*@example.com, *@*.com, *@*. • This basically says that we allow access control by domain • Instead of <ACL-target-URI Access-type="Allowed">sip:*@example.com</ACL-target-URI> • We can have: <ACL-target-URI Access-type="Allowed">sip:example.com</ACL-target-URI> • OR introduce a domain element <ACL-target-domain Access-type="Allowed">example.com</ACL-target-URI> New Schema

  9. CPCP Issue 4: refer • Currently, it is possible to ask the focus to refer users to the conference <ACL-target-URI refer=“true” Access-type="Allowed">sip:example.com</ACL-target-URI> • 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). <ACL-target-URI Access-type="Allowed">sip:alice@example.com</ACL-target-URI> <ACL-target-URI Access-type=“Blocked">sip:alice@example.com</ACL-target-URI> • 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 <ACL> <target uri="sip:foobar@example.com>Allowed</target> </ACL> • 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. <DL-target-URI re-invite='1'>sip:alice@operator.com</DL-target-URI> Her entry in the DL is replaced by increasing recur to value 2. <DL-target-URI re-invite='2'>sip:alice@operator.com</DL-target-URI> 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 <DL-target-URI re-invite=‘true'>sip:alice@operator.com</DL-target-URI> • 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. <Conference-media-policy> <Media-types> <Audio/> </Media-types> </Conference-media-policy> • 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 <Conference-media-streams> or <Conference-media-types>

  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 <conference-fp:Conference-floor-policy> <Floor moderator-controlled="true"> <Media-types> <Audio/> </Media-types> <Algorithm> <Moderator-controlled/> </Algorithm> <Max-floor-users>1</Max-floor-users> <Moderator-URI>sip:Alice@example.com</Moderator-URI> </Floor> </conference-fp:Conference-floor-policy>

  22. If you have a session that looks like this: v=0 o=example 2890844526 2890842807 IN IP4 126.16.64.4 s=SDP Seminar c=IN IP4 224.2.17.12/127 m=audio 49170 RTP/AVP 0 a=mid:1 m=video 51372 RTP/AVP 31 a=mid:2 m=video 64202 RTP/AVP 31 a=mid:3 ...and a CPCP document that looks like this: <Floor> <Media-types> <Audio/> <Video/> </Media-types> <Algorithm> <FCFS/> </Algorithm> </Floor> <Floor moderator-controlled="true"> <Media-types> <Video/> </Media-types> <Algorithm> <Random/> </Algorithm> </Floor> ...then we've got two missing links. CPCP Issue 13: Floor Control Policy (Cont.)

  23. CPCP Issue 13: Floor Control Policy (Cont.) • Which video stream corresponds to the which floor • How does one identify a floor? • Proposal (by Adam): • Add a "mid" attribute to each media type in the <Media-types/> 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.) <Floor floor-control="bfcp://floorcontroller.example.com/53280"> <Media-types> <Audio mid="1" /> <Video mid="3" /> </Media-types> <Algorithm> <FCFS/> </Algorithm> </Floor> <Floor floor-control="bfcp://floorcontroller.example.com/53281"> <Media-types> <Video mid="2" /> </Media-types> <Algorithm> <Random/> </Algorithm> </Floor>

  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: <Start-time>2003-06-16T10:00:00Z</Start-time> <Stop-time>2003-06-16T12:00:00Z</Stop-time> • 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 <Start-time> and <Stop-time> to <Mixing-start-time> and <Mixing-stop-time>

  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 <Can-join-after> 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 <Must-join-before> 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 <Invite-users> 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 <Mixing-stop-time> 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 <Mixing-start-time> 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 <Mixing-stop-time> 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 <Invite-users> with values "key-participant" and "participant". • Is "participant" needed? If no, then this attribute can be boolean

More Related