Subject: [Fwd: I-D ACTION:draft-rosenberg-sip-3pcc-00.txt]

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 21 Mar 2000 00:31:45 -0500

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

Subject: I-D ACTION:draft-rosenberg-sip-3pcc-00.txt
From: [email-masked]
To: IETF-Announce:;
Date: Fri, 17 Mar 2000 08:22:29 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Third Party Call Control in SIP
	Author(s)	: J. Rosenberg, H. Schulzrinne, J. Peterson
	Filename	: draft-rosenberg-sip-3pcc-00.txt
	Pages		: 11
	Date		: 16-Mar-00
	
This document discusses the usage of SIP for third party call
control. Third party call control refers to the ability of one entity
to create a call in which communications is actually between other
parties. We present a SIP mechanism for accomplishing third party
call control that does not require any extensions or changes to SIP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rosenberg-sip-3pcc-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-rosenberg-sip-3pcc-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-rosenberg-sip-3pcc-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Li Li" <[email-masked]>
Date: Tue, 21 Mar 2000 12:03:22 -0500

Indeed a very good and very useful feature. 
One question just for clarification.

When the controller sends the separate INVITE's
to the parties to be involved in the call, what
should be used in the from, to and call-id headers
to form the call leg? The two INVITE's may have 
the same call leg, which means the caler and callee
may not know there's a controller involved. 
That's be O.K. Or the controller can use different 
call legs with different from and to headers. 
This would mean that only the controller is
aware of the entire call with different legs. The 
caller and callee cannot send other requests for the
call directly to each other without going through
the controller? (not so good in some of the cases.)
It'll be better to make it clear in the draft.   

li li

Li Li
SS8 Networks Ltd. 
Kanata, Ontario, Canada
tel: 613 592 4686
email: [email-masked] 
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Jonathan
Rosenberg
Sent: Tuesday, March 21, 2000 12:32 AM
To: [email-masked]
Subject: [Fwd: I-D ACTION:draft-rosenberg-sip-3pcc-00.txt]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 22 Mar 2000 01:19:42 -0500

> may not know there's a controller involved.

Whilst this would be nice, I have concerns that this will break every
security capability. Basically, the controller would be lying about its
identity.

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.

> The

No, they can't. Each participant doesn't know about the other from a SIP
perspective. Each believes its talking to the controller. Neither has
even an address for the other for SIP (they do have each others media
addresses). 

There is no reasonable way, as far as I can tell, to allow the two
parties to signal each other directly in the model presented in the
document. The idea is that many services require some central point to
know everything thats going on, and to independently control all parties
in the call. The mechanism achieves that. Its not meant to handle other
models of third party call control. Things like pint present alternative
models with their own pros and cons.

-Jonathan R.

---

From: "Li Li" <[email-masked]>
Date: Wed, 22 Mar 2000 23:02:12 -0500

>security capability. Basically, the controller would be lying about its

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 From field will probably need to contain an identifier for the

Thanks for the clarifications.

li li

Li Li
SS8 Networks Ltd. 
135 Michael Cowpland Drive, Suite 200, 
Kanata, Ontario, K2M 2E9, Canada
tel: 613 592 4686
email: [email-masked]

---

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

> parties that it's the controller who starts this call (in a new header?).

Authentication is done based on the From field, so adding a new header
doesn't help.

> useful in some cases. Would this work?

No. As I said, these call legs are different.

-Jonathan R.