Subject: [Sipping] Comments on draft-cc-framework

From: [email-masked]
Date: Fri, 26 Apr 2002 15:42:14 EDT

To all,

I submitted comments on draft-ietf-sipping-cc-framework-00 (Feb) before the 
March meeting, but have seen no responses or other comments. I will repeat 
these comments with some others added:

3.1 Final bullet item: It isn't clear what point is being made about the 
model from H.450.  While the goal says "do not reinvent", the rest of the 
statement seems to say that SIP will not use an existing model, but rather 
reinvent it.

4.1.1 This section notes that existing terms "call" and "conference" are not 
well defined, so it uses a new term "conversation space". While this concept 
seems useful, it is not well defined either. The statement that it is 
"essentially a set of participants who believe they are all communicating 
among one another" is not precise enough.

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

4.7 This statement that "only the invoker[s] of features in SIP know exactly 
which feature they are invoking" sounds good in theory, but the reality for 
telephony services is that often both parties (devices) need to explicitly 
know what service is being performed, not just what signaling primitives are 
being used. It is clear, for example, that the processing of an INVITE or a 
REFER depends on the reason it was sent, whether it is a new call or a 
transfer or a barge in, etc.

The example of Alice calling Bob who transfers to Carol, while Alice has her 
robotic assistant Alice "conferenced" illustrates this. First, the 
independence of these two separate "features" would not be compromised if the 
message from Bob to Alice explicitly said "transfer" rather than the generic 
"REFER". Secondly, one should assume that the interaction between the 
"robotic" feature at Alice with transfer (caused by receipt of the REFER) 
might have to be different than the interaction between this "robotic 
feature" and other features caused by receipt of REFER. When this happens, 
attempts will have to be made at the receiving end (Ann) to deduce what was 
intended in order to figure out what the best course of action is to provide 
a good service.

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 be replaced 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 for B to 
replace C with A.

The note regarding the need to take different action depending on the state 
of the receiving entity "B", refers to a problem that affects many of the 
primitives described. Because of overlapping actions, practically every 
action at the receiving entity needs to consider the state of the receiver 
before taking the described action. However, the model for this work seems to 
be that the sender decides the action required and the receiver must do it.

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..."). Therefore, 
the statement 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".

Mike Pierce
Artel