Hi, The following comments are based on feedback I obtained from some developers. Sorry that they are sent last minute.
1. Section 4.2 "Call-Completion procedures" (1st Para.). The text indicates that call completion procedures are not required if the callee's UAs return a success response. This is incorrect and in conflict with the definition of "Failed Call" in the definitions. The requirement for call completion is independent of the success/failure of the SIP INVITE request. 2. Section 4.2. (2nd para.) Again it is implied that the call completion procedures seems tied to the state of the preceding INVITE initiated dialog with the statement "Eventually, the INVITE fails, or the resulting dialog(s) are terminated". However it is not the case that the call completion procedures are independent of the state any proceeding dialog. For example it should be possible to initiate call completion even before the original INVITE dialog is terminated. 3. The abbreviation "CECE" should be added to the terminology section. 4. Section 6.3. States that on receipt of a CC notification the callers agent should terminate or suspend all other subscriptions for the original call and even "for all other original calls". I see this is only SHOULD strength but I don't see why it should be necessary to suspend subscriptions for all other original calls. 5. Section 6.2. Some clarification is needed as to the how multiple monitor URI's are received and in particular whether a single response could contain multiple Call-Info headers with different monitor URI's. 6. Section 6.4. The clause initially implies that the URI from the NOTIFY should be used but does not indicate any standardised strength to this requirement, and then confuses things by indicating that the URI from the Call-Info header (from the response to the original INVITE I assume?) can be used as an alternative. This needs to be clarified and some guidance on the ordering of the URI sources to be used needs to be given in case there is a conflict in the URIs specified by the various sources. Also it is unclear if the 'm' parameter is to be taken from the Call-Info header or from some other source. Can the caller's agent make up their own 'm' parameter value or must only one specified to it in a SIP message be used? 7. Section 6.5. What strength of requirement is this, as it stands it seems like a MAY since it is not stated? A similar comment applies to clause 6.6 There is also a general lack of definition of what is meant by "busy" in this context 8. Section 6.6. The "shall" is not indicated as a standard requirement but seems a little strong since the user may have elected to manually suspend a CC request whilst they were busy. Need to clarify that only those suspension requests sent as a result of the caller being busy are being considered by this clause. 9. Why does the last paragraph of section 7.2 start and end with the "_" character? 10. Section 7.2/7.3. According to RFC 3265 a NOTIFY must be sent on receipt of the initial SUBSCRIBE however there is nothing in these section describing this or what the initial NOTIFY would contain. 11. There is a typo. in the 1st paragraph of clause 7.3 "requestst". 12. There is a typo. in the 2nd paragraph of clause 7.3 "'cc-service-retention". 13. Section 7.4 The last paragraph which states does not read well and is confusing. It should I think be reworded. 14. Section 7.5. Section 7.3 indicates that the selection of requests from a queue can be more complex than simply selecting the next one but this section implies the "next" request in the queue is selected. 15. Section 7.5. This is the 1st reference to a "recall timer" but it is the subject to a mandatory requirement! 16. Section 7.6. States "Receiving a CC resumption When a CC request becomes resumed, then, if the callee is not busy and there is no entry in the CC queue which is currently being processed, the CC monitor SHALL process the queue as described above". Surely the action is to restart or resume the recall timer (need to define which). The reference seems inappropriate (at least a reference to 7.2 is better) Regards Andy > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Shida Schubert > Sent: 14 October 2010 06:13 > To: BLISS > Subject: [BLISS] WGLC for draft-ietf-bliss-call-completion-07 > > > This is an announcement of BLISS WG last call on > "Call Completion" prior to requesting publication the > document as a proposed standard. > > This is a two week working group last call so please send your > comments to the list including nits by the 29th of October. > > http://tools.ietf.org/html/draft-ietf-bliss-call-completion-07.txt > > Regards > Shida Schubert (As WG chair) > _______________________________________________ > BLISS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
