Subject: [Sipping] Comments on cc-framework

From: [email-masked]
Date: Mon, 8 Jul 2002 17:33:31 EDT

To all, 

My comments on draft-sipping-cc-framework-01 as follows. (These are the same 
as submitted on version -00 in both March and April.)

4.5.2 Reference to serving the queue should refer to "the first call in the 
relevant queue" not the "last". 

5.2.2 The statement that "there is no way to distinguish between the desire 
to go on or off hold" is interesting. Is this meant to say that the REFER 
method mentioned won't work for this and some better method is needed? 

5.3 1 Since B apparently has to do something before C replaces A, the 
description of this primitive should be:

       A requests to replace itself with C.

5.3.2 Since B has to do something with the INVITE (stop sending media to C, 
start using media from A rather than C, etc) this really isn't "A forcibly 
replacing C with itself". It's really still just a request from A to replace 
C with A. 

The note seems to indicate an issue which needs to be resolved. That is, the 
actions to be taken when A sends a primitive to B depend on the status of B 
at the moment the primitive is received.

5.3.5 As above, this is just a "request" by A to be inserted into an existing 
space. B must actually do it upon receipt of the INVITE, meaning that B can 
refuse (as implied by the phrase "if B accepted the INVITE..."). The 
description after the conversation space diagram should be:

       A requests to be inserted into a conversation space.

5.3.6 should have a statement added after the depiction of the change of 
conversation space that says what is happening. It appears to be the 
following: 

       A causes conversation space to be split into two with itself and B 
making up the new conversation space. 

5.3.7 It is not clear from the diagram and statement before it what has 
happened. It should say: 

       The conversation space changes like this: 
       ( A , B ) --> (B , A ) & ( A , C ) 
       A creates a new conversation space with C and participates in both as 
the "anchor". 

5.3.8 It is unknown what "sending DTMF somewhere else" means, since no such 
"feature" is defined in Section 3.2. The conversation space change depicted 
would imply that the capability desired is to insert DTMF tones into someone 
else's conversation, but the description of B being the "anchor", and 
presumably being required to send its media to both conversation spaces, 
indicates a whole lot of additional functionality. If A wanted to send DTMF 
somewhere else while in a conversation, it would seem that a completely 
separate conversation space must be established to the intended destination. 
It seems that this might have intended to refer to the one of the parts of 
the "Voice Portal" feature described in Section 7.2.13. This might be better 
shown as:

       -voice portal services (such as whisper, hotwork detection, and 
sending DTMF somewhere else)

Mike Pierce 
Artel