Draft: draft-ietf-sipping-cc-framework-o7 Reviewer: Xavier Marjou [xavier.marjou@orange-ftgroup.com] Review Date: 2007-04-06 Review Deadline: 2007-04-13 Status: WGLC Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Section 2.3 - Among the advantages of the peer-to-peer approach (ie: REFER msg) over the 3pcc approach (ie: RFC3725), I would somehow underline that the peer-to-peer approach allows the creation of a single SIP dialog directly between the peers. On the contrary, with the 3pcc approach, there are 2 SIP dialogs connected together by a SIP intermediary, the controller. This intermediary thus affects, and may even limit, the communication between the 2 peers. For example, if the controller does not support a given SIP extension (eg: UPDATE message) whereas the 2 peers support it, the peers won't be able to use this SIP extension. Similarly, if the controller supports a given SIP extension and only one of the 2 peers support it, the SIP extension will be used in one dialog but not in the other dialog, which means that the controller will need to implement a complex behavior to mitigate this. (For this later case, the use of OPTIONS before 3pcc could help, but this is something I haven't seen being implemented.) Section 2.7.1 - Elaborate on "calendar reminder": is it "just" a type of network announcement service? Section 2.7.2 - Replace advantage of the fact that the standard SIP URI has a user part. Most services may be thought of as user automatons that participate in SIP sessions. It naturally follows that the user address, or the left-hand-side of the URI, should be utilized as a service indicator. with: advantage of the fact that the standard the left-hand-side of the SIP URI is a user part. Most services may be thought of as user automatons that participate in SIP sessions. It naturally follows that the user part should be utilized as a service indicator. Section 2.7.2 - Replace "represents people. However, the URI can also represent services," with "represents a person. However, the URI can also represent a service," Section 3.1 - Rename "3.1. Early Dialog Actions" into "3.1. Remote Call Control Actions on Early Dialog" Section 3.2 - Rename "3.2. Single Dialog Actions" into "3.2. Remote Call Control Actions on Single Dialog" Section 3.2. - What does CRM stand for? Section 3.2.2. - Replace "be conceptually be" with "conceptually be" Section 3.2.2. - It is currently written that "There is no way to distinguish between the desire to go on or off hold." Reading sip-remote-cc-05, I understand that placing on-hold or off-old is possible, but that it is not possible to do it at a "per" media level. Section 3.3.1 - In case user-A is a "secretary", and user-C is a "boss", it may be that the SIP URI of user-C must not be revealed to any user-B. This is something inherent to 3pcc. It should therefore be mentionned that "the 3pcc helps if privacy is needed for C". Section 3.3.3 - It's not easy to read the following text: "A could send the following requests: REFER B Refer-To: conference-URI INVITE conference-URI BYE B To add a party to a conference: REFER C Refer-To: conference-URI or REFER conference-URI Refer-To: C Using the 3pcc approach to transition to centrally mixed, the controller would send: INVITE mixer leg 1 (w/SDP of A) INVITE mixer leg 2 (w/SDP of B) INVITE C (late SDP) reINVITE A (w/SDP of mixer leg 1) reINVITE B (w/SDP of mixer leg 2) INVITE mixer leg3 (w/SDP of C) To add a party to a SIP conference: INVITE C (late SDP) INVITE conference-URI (w/SDP of C) Features enabled: - standard conference feature - call recording - answering-machine style screening (screening)" Maybe rewrite it with "A could send the following requests: ° REFER B Refer-To: conference-URI ° INVITE conference-URI ° BYE B To add a party to a conference: ° REFER C Refer-To: conference-URI ° or REFER conference-URI Refer-To: C Using the 3pcc approach to transition to centrally mixed, the controller would send: ° INVITE mixer leg 1 (w/SDP of A) ° INVITE mixer leg 2 (w/SDP of B) ° INVITE C (late SDP) ° reINVITE A (w/SDP of mixer leg 1) ° reINVITE B (w/SDP of mixer leg 2) ° INVITE mixer leg3 (w/SDP of C) To add a party to a SIP conference: ° INVITE C (late SDP) ° INVITE conference-URI (w/SDP of C) Features enabled: - standard conference feature - call recording - answering-machine style screening (screening)" Section 3.3.4 - Replace "5.3) For" by "5.3). For" - There is no Section 5.3 Section 6 - I suggest to list example features by alphabetical order in section 6, 6.1, 6.1.1. ... otherwise it's difficulte to look for a given feature among the different sections. Section 6.1 - Update references for [service-examples], [conf-models], [cc-transfer], [cc-framework], [sip-answer-mode] with [6], .... [28] Section 6.1.4 - Replace "dialog state" with "dialog event package" ? If yes, add a reference to [11], RFC 4235 Section 6.1.13 - Replace "Voice Portal Takes" with "Voice Portal takes"