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

From: [email-masked]
Date: Tue, 30 Apr 2002 17:01:43 EDT

In a message dated 4/29/02 12:36:35 PM Eastern Daylight Time, [email-masked] 
writes:

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

It has the benefit of being explicit, allowing processing at Alice to do the 
right thing based on what Bob wants. For example, if Alice has hung up just 
before she receives the REFER (request for transfer) it needs to be processed 
differently. I have not been able to put my finger on a specific case yet, 
since the target seems to keep moving somewhat (the interpretation of REFER 
in different cases). But I certainly get the impression that the desired 
interaction between different services will require that the REFER be 
processed differently depending not only on the exact state the receiver is 
in when she gets it, but also on exactly what the sender intended when he 
sent it. Guess it comes from so much such discussion during the development 
of ISDN standards. Yes, I know what the usual response to that is: "We don't 
want to repeat the mistakes of telephony or base this on their model", but 
the service requirement hasn't changed just because the protocol has changed.

Meanwhile, I'm trying to follow all the twists and turns in the rules for 
processing REFERS and INVITES, etc and to identify specific cases that won't 
work.

> 
> 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 (Alice) 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>

The problem is that, regardless of your protocol model, what the sender 
really wants to do is to invoke a well known service, not a primitive. A 
"primitive" is just one way to attempt to do it. The discussion of the last 
few months should have convinced others besides myself that there are no 
"very simple rules" for how to invoke "a well known primitive". It seems that 
everytime someone has asked a question regarding interaction of one primitive 
with another or with a timeout, that there was a further refinement on the 
"simple rules". Am I wrong here?

Don't get me wrong. There are a lot of things that can be done sending 
"primitives" between end points, just as a lot was done in the PSTN (even 
with ISDN) just by passing basic SETUP and RELEASE messages (or off-hook and 
on-hook) back and forth. It allowed many services that were totally 
controlled by one end (network provider switch). But there are a lot more 
complicated things that we want to do and I haven't seen any movement towards 
establishing a framework for that to happen. Rather, there seems to be a 
complete opposition to it. Is that maybe just considered as being outside of 
SIP, that is, a higher layer protocol portion? That would really raise 
feature interaction concerns!

> thanks,
> -rohan

Mike