Re: [SIPPING] question on draft-johnston-sipping-cc-conferencing-00.txt

"Arjun Roychowdhury" <aroychow@hns.com> Wed, 06 November 2002 17:48 UTC

Received: via dmail-2000(11) for +imap/ietf/SIPPING; Wed, 6 Nov 2002 11:48:19 -0600 (CST)
Return-Path: <sipping-admin@ietf.org>
Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id gA6HmIWr014272 for <dean.willis@softarmor.com>; Wed, 6 Nov 2002 11:48:18 -0600
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6Hf1v31262; Wed, 6 Nov 2002 12:41:01 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6HeUv31230 for <sipping-admin@optimus.ietf.org>; Wed, 6 Nov 2002 12:40:30 -0500
Received: from gateway.hns.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03434; Wed, 6 Nov 2002 12:37:56 -0500 (EST)
Received: from excore1.hns.com (excore1.hns.com [139.85.52.104]) by gateway.hns.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id gA6HeOk19870; Wed, 6 Nov 2002 12:40:24 -0500 (EST)
Received: from atlas (atlas.hns.com [139.85.177.110]) by excore1.hns.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gA6HeJ128219; Wed, 6 Nov 2002 12:40:19 -0500 (EST)
To: Paul Kyzivat <pkyzivat@cisco.com>
Cc: Michael Hammer <mhammer@cisco.com>, "Even, Roni" <roni.even@polycom.co.il>, sipping@ietf.org, sipping-admin@ietf.org
Subject: Re: [SIPPING] question on draft-johnston-sipping-cc-conferencing-00.txt
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001
Message-ID: <OFEC41A948.B660DDDD-ON85256C69.005F73C8@LocalDomain>
From: Arjun Roychowdhury <aroychow@hns.com>
Date: Wed, 06 Nov 2002 12:40:11 -0500
X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.10 |March 22, 2002) at 11/06/2002 12:38:23 PM, Serialize complete at 11/06/2002 12:38:23 PM
Content-Type: text/plain; charset="us-ascii"
X-Filtered: Sendmail MIME Filter v1.0.7 excore1.hns.com gA6HeJ128219
Sender: sipping-owner@ietf.org
Errors-To: sipping-owner@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Status: O
X-Status:
X-Keywords:
X-UID: 3032

<pk>
If you have a Conference URI, you can give it to all of your friends. Then 
when they call they will all be in the same conference together. But if 
you made a mistake and actually had a Conference Factory URI instead, you 
could still give it to all of your friends, and they could all call it, 
and each would end up in a conference. But they would each end up in a 
distinct conference by themself. So it is important to know which kind of 
URI you have.
</pk>

I would disagree with the outcome you state of connecting to a Factory vs. 
the conference itself.
Practically, as discussed, it is most likely that any conferencing server 
would host a 'FactoryURI'
possibly of the form sip:conference@server.com and each individual 
conference would be something like
sip:xxxid-conf@somenode.server.com.

That does not however mean that if you happen to distribute the factory 
URI, your friends would land 
up each in individual conferences. Most likely, they would land up in a 
prompt request/response
that would provide options of joining a particular conference based on 
some ID or maybe even creating
new conferences -> but all of this is policy. 

If we were to theoretically address this situation, then a job of a 
Factory is to produce new conferences
and therefore, theoretically, an INVITE sent to a factory either creates 
or rejects.
In practical scenarios, the 'FactoryURI' will actually be an 'entry point 
to a conferencing system'
and therefore, what action is taken would be based on a multitude of 
policies, of which creating a new
conference is one.

It may then be useful to properly define what we mean as a 'FactoryURI' -> 
assuming the fact 
that in a conferencing system, there is one 'general conference uri' and 
many 'specific conferenece uris'
-> then from the point of implementation, is FocusFactoryURI really what 
is exposed to users ?

regds
arjun

--
Arjun Roychowdhury @ Hughes Software Systems
11717 Exploration Lane, Germantown MD 20876
(O): 301-212-7860        (M): 240-997-0066