Subject: [Sipping] re: comments on cc-framework

From: Rohan Mahy <[email-masked]>
Date: Mon, 29 Apr 2002 09:32:49 -0700 (Pacific Daylight Time)

Hi,

I haven't received enough comments to warrant an update to the draft at
this point.  I am planning to incorporate almost all of Mike's comments. I
would like to reply to one of Mike's comments here however.

----
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.

Rohan> I disagree.  I have run through dozens of features which use these
Rohan> features and I have never had this problem.  I suppose I can't
Rohan> expect you and others to just take my word on faith so I will try
Rohan> to come up with some more convincing examples.  Please feel free
Rohan> to come up with a counter-example.

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".

Rohan> I'm not convinced, but assuming you are correct, what benefit would
Rohan> this have?

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.

Rohan> Why?

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.

Rohan> I disagree.  The basis for the model is that the sender asks the
Rohan> receiver to invoke a well-defined primitive.  The receiver can use
Rohan> very simple rules to figure out whether to authorize whole
Rohan> categories of requests or not.  The sender is free to use these
Rohan> primitives for whatever service they can invoke with the primitives
Rohan> at hand.

thanks,
-rohan

------------

To: [email-masked]
Subject: [Sipping] Comments on draft-cc-framework
From: [email-masked]
Date: Fri, 26 Apr 2002 15:42:14 EDT
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
Sender: [email-masked]

--------------------------------------------------------------------------------
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".

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

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Henry Sinnreich <[email-masked]>
Date: Mon, 29 Apr 2002 16:30:32 -0500

> I haven't received enough comments 

The only comment I have is keep going with this excellent draft!

Henry

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Rohan Mahy
> Sent: Monday, April 29, 2002 11:33 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Sipping] re: comments on cc-framework
> 
> 
> Hi,
> 
> I haven't received enough comments to warrant an update to 
> the draft at this point.  I am planning to incorporate almost 
> all of Mike's comments. I would like to reply to one of 
> Mike's comments here however.
> 
> ----
> 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.
> 
> Rohan> I disagree.  I have run through dozens of features which use 
> Rohan> these features and I have never had this problem.  I suppose I 
> Rohan> can't expect you and others to just take my word on faith so I 
> Rohan> will try to come up with some more convincing 
> examples.  Please 
> Rohan> feel free to come up with a counter-example.
> 
> 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".
> 
> Rohan> I'm not convinced, but assuming you are correct, what benefit 
> Rohan> would this have?
> 
> REFER) might have to be different than the interaction 
> between this "robotic feature" and other features caused by 
> receipt of REFER.
> 
> Rohan> Why?
> 
> 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.
> 
> Rohan> receiver to invoke a well-defined primitive.  The receiver can 
> Rohan> use very simple rules to figure out whether to authorize whole 
> Rohan> primitives for whatever service they can invoke with the 
> Rohan> primitives at hand.
> 
> thanks,
> -rohan
> 
> ------------
> 
> To: [email-masked]
> 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 
> 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 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:
> 
> 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:
> 
> A creates a new conversation space with C and participates in 
> both as the "anchor".
> 
> 
> Mike Pierce
> Artel
> 
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>