Draft: draft-ietf-sipping-cc-conferencing-06.txt Review: Elwyn Davies Date: 25 maj 2005 Document: draft-ietf-sipping-cc-conferencing-06.txt Trigger: IETF Last call, ending 20 May 2005 Reviewer: Elwyn Davies AD: Allison Mankin Review Date: 20 May 2005 Intended status: BCP Summary: In my opinion this document is not ready for submission to the IESG. There appear to be a number of points where the document needs clarification or improvement, and I have difficulty seeing it as a BCP: it contains no 'recommendations' section and, although it contains no new protocol messages or elements, it reads like the definition of how a SIP application needs to work. There are, it is true, definitions of a number of ways of achieving certain ends (such as attaching a new party to a conference at the behest of an existing party), but there is no (or very minimal - one place I can see) discussion of why these should be needed nor any comparative evaluation of the possibilities. In fact, I could see that most of these possibilities would be useful in a complete solution for achieving different aims. Also the descriptions are very much focussed on the 'success' case: there are a number of items where (IMO) the consequences of failure need to be covered. Accordingly, at the minimum the document needs another fairly major revision, and at worst its intended aim needs to be reassessed. Review: Intended Document Status: This document is intended to be classified as BCP. The document as written does not appear to contain any recommendations as between possible alternatives and is only about operational matters to the extent that it defines the protocol exchanges between a set of parties to achieve SIP conference control for a particular form of conferencing using basic SIP messages with one extra specific parameter (isfocus) - this in fact is the stated aim in the Abstract. This feels to me like an application standard definition - clearly it would be highly desirable if (tightly coupled) conferencing implementations all adhered to something like this to achieve interoperability. There may be other ways of going about the problem which would retain interoperability (or maybe break it) but they are not discussed. So I am really rather unsure what the nature of the document really is: it could be recast as a standard (except the IETF doesn't usually define standards for applications), informational or BCP, but I feel it falls between stools at the moment. Detailed Points: These points are a mix of editorial and substantive - the substantive ones are marked. I consider 19 of the issues to be substantive (assuming I can count): Abstract: The Abstract contains the only mention of the term 'tightly coupled'. This is defined in the requirements and framework documents but is so fundamental to what is being discussed that it cries out to be explained in the introduction and possibly in the Abstract itself so that we know why the schemes suggested are being adopted: in essence 'tightly coupled' restricts the conference connections to a 'star' graph around a single focus which provides the majority of conference state and policy management. This would then make it more obvious why the term 'focus UA' is used in the Abstract. Consistent usage of 'dial-in' and 'dial-out': these terms should be hyphenated throughout. S1, Introduction: A very brief introduction to the 'tightly coupled' concept would help make the rest more readily comprehensible. Paragraph after bulleted list: s/opposed to service-related/opposed to using service-related/ S2, use of 'isfocus': This whole section would be much more comprehensible if it followed Section 3, and this would require minimal changes to s3. S2.2, Session Establishment: (SUBSTANTIVE)'isfocus' is presented as an indicator to Conference-aware UAs that a dialog is taking place with a conference. It would be helpful (to those lacking intimate knowledge of SIP) to explain why Conference-unaware UAs, especially those built before 'isfocus' was invented, will not be confused by this parameter. See also s4.5. S2.3, Discovery: (SUBSTANTIVE)'Currently the only met requirement is': Is this an admission that there are others which this solution doesn't meet? Or a statement that this is the only requirement which it has to meet? The requirements document suggests five requirements for the discovery phase. The words in this section seem to tie in with REQ-2 from the requirements, but the rest of the document does seem to suggest that capabilities meeting some of the others are also provided (e.g. obtaining conference state). S3, SIP User Agent Types: (SUBSTANTIVE)Para 2: 'It defines *normative* behavior..'. Hmm, so this is a standard then. S3.1, Focus UA: The explanation of what a GRUU is/does for you would need to be placed here rather than in S2 if ss2 and 3 are reordered. S3.2, Conference factory URI: Para 1: Suggest s/These are open to the conferencing server implementation and/The conferencing server implementation is free to choose from these methods, which include/ Para 1: Expand IVR acronym. S3.3, Conference Unaware UAs: s/support RFC3261/support the basic SIP protocol defined in RFC3261/ (SUBSTANTIVE)Last sentence: 'Note that a conference-unaware UA should be able to process SIP redirections.' - What happens if the UA can't support redirections? Should this 'should' be a 'SHOULD'? Do UAs which don't support redirection exist? Does this imply that this is a MUST for Conference Aware UAs? S3.4, Conference aware UAs: (SUBSTANTIVE)'The SUBSCRIBE to the conference package should be sent outside any INVITE-initiated dialog.': Is this 'should' a 'SHOULD' or is it really a 'MUST'? S4, SIP Conferencing Primitives: Last sentence: s/comprising/implementing/ S4.1, : Joining a Conference using the Conference URI - Dial In: (SUBSTANTIVE)Para 2: 'If the conference is up and running already, the dialing- in participant is joined to the conference by its focus.'... not unconditionally surely? It would probably be appropriate to put in the general words about policy and authorization that are currently briefly mentioned in the security onsiderations somewhere at the beginning of S4. Currently the first mention of authorization is in S4.11. (SUBSTANTIVE)Para 3: ' a UA SHOULD send an INVITE'. This is not a requirement statement, but rather a 'how it is done'. s/SHOULD/will Display of F3 packet: Are the To/From fields back to front? Both OK examples are the same (here and s4.13) are the same and it might be that I don't have a deep enough understanding of SIP :-( S4.2, INVITE: Adding a Participant by the Focus - Dial Out: Display of F9 packet: Status for Carol dialed-in dialed-in s/b dialed-out? S4.3, INVITE: Manually Creating a Conference by Dialing into a Conferencing Application and S4.4, INVITE: Creating a Conference using Ad-Hoc SIP Methods I feel a few words introducing the comparison between these methods would be useful. I found it difficult to understand how they differed at first glance. In particular explaining why 'ad-hoc' is an appropriate description for S4.4. S4.3, INVITE: Manually Creating a Conference by Dialing into a Conferencing Application Para 1: '..MUST re-INVITE the user with the conference URI in Contact with the "isfocus" feature parameter' could be better phrased. Para 2: '..during an early dialog established'. I presume this means something like '... during a prior dialog before the establishment of the conference.' Message sequence diagram:' Alice uses the application to create the conference'. What happens if Alice has inadvertently used a URI which is isn't actually a conference URI but is another SIP UA? The next INVITE will never arrive, and the result might be silence. A timeout may be needed. S4.4: Para 2: 'The main difference between this scenario and Section 4.3 is that no user intervention (IVR, web page form, etc.) is required to create the conference.' This is slightly confusing... this is really about prior user action. *something* has to be done by the user, but in one case it is organised by a simple button press at the UA whereas the other one requires more complex user input generally on some other device. (SUBSTANTIVE)Para 4: ' A SIP entity (such as conferencing server) can distinguish this INVITE request as a request to create a new ad-hoc conference from a request to join an existing conference by the Request-URI.' I may be being dumb, but just *how* can it tell the difference? (SUBSTANTIVE)Para 6: '...Conf-ID Is short for the conference URI.' I think it would be good to say something about how the Conf_ID is generated and uniqueness requirements (I assume there are some!). (SUBSTANTIVE)Para 8: 'Note that with proxy recursion, Alice may never see the redirect...' This appears to impose some requirements on the proxy. Does the proxy have to generate the equivalent of the INVITE that Alice would otherwise have generated? Should this be explained more exactly? Message sequence diagram, packet F3: 302 Moved s/b 302 Moved Temporarily (SUBSTANTIVE)S4.5, REFER: Requesting a Focus to Add a New Resource to a Conference (Dial-out to a new Participant) Should the title be ...(Including Dial-out ...)? It covers more than just this or could do. Para 1: 'Examples include new participants, new real-time media sources, new IM messages, and pointers to passive information references (such as HTTP URIs).' but this section only covers the new participant case in detail. The intention should be clarified. Para 2: s/dependant/dependent/ Para 2: s/the own focus policies/the policies applied by the conference focus/ (SUBSTANTIVE)Para 3: ' The scenario for adding a new UA participant is important to support because it works even if the new participant does not support REFER and transfer call control - only the requesting participant and the focus need to support the REFER and transfer call control.' Is this imposing a requirement? (SUBSTANTIVE)Para 5: 'A conference-unaware UA would simply ignore the conferencing information and treat the session (from a SIP perspective) as a point to point session.' As a SIP neophyte, I would appreciate a pointer to the piece of specification that ensures that this will happen without any further work. S4.6, REFER: Requesting a User to Dial into a Conference Using a Conference URI: (SUBSTANTIVE)Para 4: '...in addition to the notification received through the conference package' This doesn't appear to be shown on the message sequence diagram. (SUBSTANTIVE)Para 5: ' An example is shown in Figure 6. In this call flow, it is assumed that Alice is already a participant of the conference. Alice sends Bob an "out of band" REFER - that is, a REFER outside of an established dialog. Should Bob reject the REFER, Alice might try sending an INVITE to Bob to establish a session first, then send a REFER within the dialog, effectively transferring Bob into the conference [17].' What happens if Bob is Conference Unaware? (SUBSTANTIVE)S4.7, REFER with REFER: Requesting a Focus to Refer a Participant to dial into the Conference: Message sequence diagram: 'Focus REFERs Bob to the conference': Again, what happens if Bob is Conference Unaware? S4.9, Replaces Header Field: Switching User Agents within a Conference: Para 2, last sentence: Bad character in 'participantŪs'. (SUBSTANTIVE)Para 2, last sentence: 'Note that the participant list (roster) has not necessarily changed during this scenario, unless detailed information about participantŪs user agents (i.e. endpoints) is included in the conference state notifications' I think it would be desirable to be explicit about whether the NOTIFY will be sent to other participants, or at least the creator: there might be security issues such as possible hijacking of participants! S4.10, Replaces Header Field: Transferring a Point-to-Point Session into a Conference: (SUBSTANTIVE)The message sequence diagram suggests a 'break before make' solution. Is this a good idea? If the connect to the conference fails (maybe the focus policy doesn't allow Bob to join), Bob has been disconnected from his point-to-point session and is not on the conference either. If it would work, a 'make before break' strategy would be more user friendly in the event of a failure of the 'replace'. S4.12, Deleting a Conference: (SUBSTANTIVE)Para 1: Reading the framework/requirements indicates that conferences will be deleted (also) when the number of participants falls to zero. This para appears to imply that the creator leaving is the main policy for deleteing conferences and should be rephrased. Clearly it would also be useful to have options to allow conferences to continue after the creator leaves. S4.13, Discovery of URI Properties using OPTIONS: (SUBSTANTIVE)Para 2: 'Note that the Allow, Accept, Allow-Events, and Supported header fields should be present in an INVITE from a focus...' Is this a requirement? s/should/MUST/??? (SUBSTANTIVE)Para after packet descriptions: ' Useful information from each of these headers is detailed in the next sections.' It would be useful to define if there is some minimum set that should (must) be supported. S5, Security Considerations: Para 1: 'Normal SIP mechanisms including Digest authentication and certificates can be used.' Maybe a reference would be helpful.