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

From: "Yadavalli, Satyamurthy" <[email-masked]>
Date: Fri, 3 May 2002 16:27:41 -0400

Thanks Rohan for the explanation.

You said, A-C call is released by C and A-B call is released by A.

Does this transpire automatically by the definition of the
INVITE/REPLACE/REFER (I havenot closely read the RFCs so I ask)?

Or is it based on what's stated in the INFORMATIONAL RFC (service-examples)?

If its the later case then....

-satya

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Friday, May 03, 2002 3:58 PM
> To: Yadavalli, Satyamurthy
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: [Sipping] re: comments on cc-framework
> 
> 
> 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
> 
> 
> 
> On Fri, 3 May 2002, Yadavalli, Satyamurthy wrote:
> 
> > 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 13:47:25 -0700 (PDT)

> INVITE/REPLACE/REFER (I havenot closely read the RFCs so I ask)?

the A-C call is released by C because B and C automatically followed the
rules of processing that started when A sent the REFER.

A has to decide when to release the A-B call based on what it is trying to
accomplish.  This is a local implementation matter, but examples of
reasonable choices are given in service-examples and cc-transfer
(informational or BCP).

btw:  If all goes according to plan, then REFER and Replaces become
Standard's Track RFCs round about June 3rd.  At the moment however these
documents are just working group internet-drafts.

thanks,
-rohan