Hi All, These are my review comments on draft-ietf-bliss-shared-appearances-02.
Overall I think the draft covers most of the requirements but needs some editorial work to remove some of the unnecessary sections and text. I also think that it is necessary to explore some scenarios in more detail especially the glare conditions. For example in 10.7 (appearance pickup) what happens if the pickup fails and the already published state needs to be cancelled. It is the glare and recover scenarios that make this feature so hard to implement and the draft says very little about failure scenarios. The inclusion of the appearance number in the incoming INVITE (appendix A) is I believe a must have to make this work and should be a mandatory part of the main specification. My detailed comments are as follows. Section 1 3rd Para. "Different approaches will be discussed including the use of URI parameters....". Can we now remove the discussion on different approaches. 4th Para. "...gives this feature its" - Should this be "..its name" ? Section 3.1 "An assistant can make outgoing calls using the identity of either the executive or their own". This should be removed as making calls with the different identities is not part of this feature. Section 3.2. Replace "SIP Telephony devices" with "SIP UA's" for consistency with other sections. Possibly replace "Another phone can request to be added to an appearance resulting in a conference call" with "Another phone can request to be added joined or bridged in with the existing appearance". Again this is for consistency with section 3.3. Section 4.1. REQ-4 contains the statement "UAs registering against the group AOR should be able to learn about each other and join the appearance group". I don't think it is a requirement that the UA's "learn about each other". Section 4.2. 4th Para. Contains the statement "The next section discusses normal SIP operations used to implement parts of the shared appearance feature". This refers to the bulleted list below which appears to contain many statements that I would not include in "normal SIP operations" and should be part of the normative section. Bullet 4 contains the statement "UAs receive a notification from the Appearance Agent indicating the appearance number to use in rendering the incoming call". I think it is a must that the incoming INVITE contains the appearance number otherwise the UA cannot render the incoming call until it receives this leading to all kind of race and glare conditions. Bullet 7. What does the UA publish in this scenario? Section 5.2.1. The statement "When sent in a notification in state Trying to the Appearance Agent" is incorrect because it is actually a publish which is used. Section 5.2.4 Replace "convey" with "to convey". Section 5.3. 1st Para. "defined in this draft". Please add a reference to the section that defines this. 3rd Para. "Upon initialization and at regular intervals, the UA SHOULD subscribe" should replace the statement about regular intervals with a reference to RFC 3265. 3rd Para. "or returns a 482 Loop Detected" why is this singled out is it just one of many possible failure cases. 4th Para. "User Agents MUST support sending an INVITE with a Join [RFC3911] header field to initiate bridging". Why is this a MUST strength requirement it should be optional for the UA to support bridging so a MAY would seem to be appropriate. 4th Para Note. "Note that the Join operation can be implemented outside the UA, for example, in a B2BUA. This is why UAs must support sending Join header fields even if they do not necessarily support receiving them". I think this can be removed and as previous comment I don't think this is a reason for mandating that a UA can initiate bridging. Section 7 (User Interface Considerations). I don't think we need this section the purpose of the draft is to promote interoperability between SA implementations. Those implementing this will be well aware of the UI considerations that may be different depending on their particular type of UA. Section 8.3. 1st Para. "This type of UA will be detected by the Appearance Agent by the absence of the ma event parameter in SUBSCRIBE or PUBLISH messages" I think the event type is "shared" not "ma" also if the UA does not support SA then I assume it will not PUBLISH to the appearance agent. Section 10.1. I think the REGISTER from bob needs to be shown. Section 10.2 2nd Para. "then the Appearance Agent will need to resolve the situation by moving either Alice or Bob's dialog to a different appearance". This is one glare condition that I worry about what would happen if all other appearances are busy ?. The diagram seems to imply that the INVITE (F7/F8) is not sent to Bob until after the NOTIFY's have been sent but I don't think this is the case and it would therefore seem better to move the sending of the INVITE to before the NOTIFY (F2/F4). Section 10.7. The PUBLISH (F32) indicating the dialog to be replaced is sent before the INVITE/replaces (F38) is this the correct order and if so it introduces some glare conditions that we need to explain how to get out of. Section 10.9. It is not explained how Bob indicates in the PUBLISH that he does not want an appearance number assigned. The NOTIFY (F32) contains the dialog identifiers for the dialog with alice but since the INVITE (F34) has not yet been generated it is likely that Bob's UA will not know this information so it cannot be included in the NOTIFY with state "trying". Section 12 Appendix A. I think this should become part of the main specification and included in the normative section. Section 13 Appendix B. I think this should be removed to reduce the size of the document. Regards Andy _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
