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

From: "Yadavalli, Satyamurthy" <[email-masked]>
Date: Fri, 3 May 2002 15:37:39 -0400

Lets take a simple service: call transfer with consult (i.e., attended
transfer as per draft-ietf-sip-service-examples).

Endpoints "A" and "B" have a call setup. "A" intends to transfer this call
to Endpoint "C" after an A-C call (consultation). Upon accomplishing the
transfer (B-C call setup) using REFER method etc., which endpoint(s) shall
initiate, among the three endpoints involved , release of the call(s) A-B,
A-C ? Each implementation of the endpoint may think the other would release
the call and atlast none may have done it.

Shouldn't there be specifications to implement features that (are supposed
to) interoperate across domains? 
I guess, if not IETF some other body must be working on such things. Is it
true?

-satya

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Thursday, May 02, 2002 1:27 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Sipping] re: comments on cc-framework
> 
> 
> 
> 
> On Thu, 2 May 2002 [email-masked] wrote:
> 
> > Rohan,
> >
> > your disagreement on "needing to know exactly what's going" 
> on, seems
> > to stem from experience with "dozens of features" that are typically
> > used on "dumb" terminals on intelligent, centralised systems (e.g. a
> > PBX). In those cases it is normally true that the terminal does not
> > need to know a lot about what's going on. Typically it is sufficient
> > to simply instruct it to put something on the display 
> and/or to switch
> > some LED(s) on or off.
> 
> You seem to be missing several points:  SIP endpoints can create,
> terminate, render, relay, or combine media based on local policy
> decisions.  The User Interface of SIP endpoints can vary radically
> so SIP call control primitives make no attempt to specify the user
> interface behavior; that is a local implementation issue.  
> SIP endpoints
> can operate more or less autonmously across multiple administrative
> domains in private networks and in the Internet as a whole.  Stimulus
> protocols can't do this.
> 
> No one is disputing that you could offer services to a closed 
> user group
> of dumb terminals using a PBX or an MGCP or MEGACO media gateway
> controller.  The problem with this is that this only works 
> for homogenous
> dumb terminals in a single adminsitrative domain.  SIP has no such
> contraints.  It is a protocol for the Internet that works on 
> a variety of
> endpoints.
> 
> thanks,
> -rohan
> 
> 
> > Unfortunately (or fortunately?), this is the
> > realm of protocols like MGCP/Megaco/(Euro)Packetcable, etc. So, if
> > this is all that SIP is going to bring, why should I use it?
> >
> > I usually try to compare the use of protocols like SIP (and H.323)
> > with the use of protocols like QSIG, DPNSS and the likes. These
> > protocols are an attempt to create distributed systems by linking
> > systems in such way that much of the information that is known by
> > one system is also known by the other system(s) involved in a call.
> >
> > If what you're proposing were true, it would not be necessary to
> > have these complicated networking protocols to have "linked"
> > systems appear as one.
> >
> > The real complication here is that it is difficult to 
> determine which
> > information needs to be shared. In practice (as demonstrated by the
> > protocols that I mentioned), this is service dependent.
> >
> > Regards,
> >
> > Frank
> >
> >
> >
> >
> >
> >
> > Rohan Mahy <[email-masked]>
> > Sent by: [email-masked]
> > 29-04-2002 06:32 PM
> >
> >
> >         To:     [email-masked]
> >         cc:     [email-masked]
> > (bcc: Frank Derks/HVS/BE/PHILIPS)
> >         Subject:        [Sipping] re: comments on cc-framework
> >         Classification:
> >
> >
> >
> > 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
> >
> >
> >
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: Rohan Mahy <[email-masked]>
Date: Fri, 3 May 2002 12:57:39 -0700 (PDT)

Hi,

All this is documented in
draft-ietf-sipping-service-examples-01.txt
 (as well as draft-sip-ietf-cc-transfer-05.txt
  which will be updated shortly as draft-ietf-sipping-cc-transfer-00.txt)

but to briefly summarize...

A is the invoker of the service.  It is going to use a few well defined
primitives to make sure the service it wants to invoke happens.

A might have a held call with B and an active call with C.

If A sends a REFER to B, B can accept or refuse the REFER.  Assuming B
accepts the REFER, it sends the triggered request which it build according
to the Refer-To header it received from A.

In this case, the triggered request is an INVITE to C with a Replaces
header indicating the dialog in use by A and C.

Assuming C accepts the INVITE with Replaces header, it matches the
existing dialog it has with A and replaces its resources, sending a BYE to
A.

B notifies A that the triggered request caused by A's REFER was
successful.

this chain of activities was caused by a single request sent by
the invoker.  it required no knowledge in B or C about what
service A was attempting to invoke.  As far as C was concerned, the INVITE
with Replaces might have been another feature (call center take for
example).  As far as B was concerned, the REFER could have been to migrate
from a locally mixed conference to a centrally mixed one.  they don't
know, they don't care, and there is no need for them to care.  if they did
try to care they would probably get it wrong.

whenever A decides it is a good time to do so, it can send a BYE to B.
depending on when A does this, you can get different services.  this is a
good thing.

i hope this explains some of the philosophy around invoker-oriented call
control.

thanks,
-rohan