Subject: RE: comments on draft-rosenberg-sip-3pcc-00.txt

From: [email-masked]
Date: Thu, 23 Mar 2000 09:48:16 +0530

Hi,
actually initially I too was thinking of methods which would allow a
controller to step out just after indicating to n parties that they
need to contact each other - that way its a clear two-way usual call
without signals going one way and media another.

Infact, if you really want to do it that way, why couldnt a controller
simply send an INFO to A - telling it that it needs to contct B ?
You dont need any call transfer or whatever.
(of course, this INFO has to be understood by both parties - not a problem
if this issue is important enought to standardize the INFO format a little
more)

Anyway, I do agree with Jonathan that this draft specifies a
controller-is-present model and that there are other ways as he said like
pint, and maybe INFO  too - depends on what approach is taken.

Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems

> Or the controller doesn't have to lie. It can indicate to both
>  parties that it's the controller who starts this call (in a new
header?).
>  Then the controller can leave as it doesn't want to stay in the call.
>  If the controller wants to stay, it'd then use different call legs to
>  link the involved parties as described in the 3pcc model. To get
>  other parties connected without itself staying in the call can be
>  useful in some cases. Would this work?

> We can argue that if the controller wants to connect A and B but doesn't
>  want to stay in their call could use call transfer to achieve this,
though
>  that'd require a few more steps.

>> The Call-ID for each of the two INVITEs can be different. The To fields
>> will also be different, reflecting the two addresses being contacted.
>> The From field will probably need to contain an identifier for the
>> controller.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 23 Mar 2000 00:15:55 -0500

> simply send an INFO to A - telling it that it needs to contct B ?

We have discussed that as well (OPTIONS with Also was the initial
proposal). It suffers from the problem that there isn't much feedback on
call state to the controller, and no subsequent control is possible.
Thus, it doesn't solve much.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Jay Batson <[email-masked]>
Date: Sat, 25 Mar 2000 12:48:23 -0500

>Thus, it doesn't solve much.

Jonathan --

Your 3pcc draft is in fact a nice bit of work.  It *does* solve the problem 
for "controller-in-charge" designs.

Arjun's point, however, is valid.  There are going to be plenty of 
circumstances and designs where the central point merely wants to trigger 
-- not "control" a call.  His INFO approach seems much lighter weight and 
appropriate for the task.

Dan P. (our resident SIP expert) isn't here for me to make sure I'm not 
making a fool of myself.... ;-)  But I can imagine that Arjun's method 
would be just *fine* as a way to support 3rd party call control for use in 
"click to dial" from a desktop PIM (e.g. Outlook).  Desktop software could 
simply send an INFO message (containing the SIP URL to be dialed) to a User 
Agent, and then the User Agent does its "normal" thing.  The desktop 
software doesn't need to be "in charge" of the call -- just triggering the 
endpoint to do its normal thing.  In another example, Outlook could send 
similar INFO messages to multiple User Agents to trigger all of them to 
dial a SIP URL for a SIP-enabled conference bridge.

I would be interested in knowing whether Arjun's approach can be done 
without any new syntax/verbs/....  If so, I think it would be appropriate 
to reflect an example in the draft that *isn't* based on a the "controller 
in charge" model.  I know the *point* here is 3rd party call control, but 
his point is that there are varying amounts of 3rd party control 
required.  I think it's appropriate to have the "experts" provide examples 
in the draft that indicate lighter weight methods like Arjun's for those 
who don't want to implement full, state-sensitive, ..., 3rd party control 
for something as basic as triggering a call.

Cheers
-jb

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 25 Mar 2000 17:48:11 -0500

> appropriate for the task.

I wasn't arguing that the 3pcc approach is the only way. I was only
pointing out that I suspected many other applications of 3rd party call
control would need some sort of feedback after the initial "please call
Joe" message. Certainly there are some that don't (you do point out an
example below). I'd like to see how long that list is. I have quite a
long list for 3pcc.

> dial a SIP URL for a SIP-enabled conference bridge.

Actually, the best way to do this is, rather than INFO or OPTIONS, is
the new TRANSFER (or PLEASE-INVITE as was suggested), as it is basically
exactly this function. Overloading these with something new is probably
not a good idea, as its hard to know, when you get an INFO or OPTIONS,
what are the things you actually need to do.

-Jonathan R.