Subject: Re: [Sipping] Comments on johnston-sipping-cc-conferencing-00.txt(the second duck in theline ;-)

From: "Arjun Roychowdhury" <[email-masked]>
Date: Mon, 4 Nov 2002 14:05:06 -0500

Paul, 
I (think) I concur with your ideas.
[ i.e.  if my assumptions below are what you also seem to say, then we are 
in agreement else here is another opinion on the plate ;-) ]

Just to summarize:

a) As far as conferencing hosts are concerned, there are two logical 
entities:
        a.1) A FocusFactory -> This is a UA that is capable of creating 
and managing one or more Focii. 
        a.2) A Focus -> This is a UA that is created by a Focus Factory to 
manage a  particular instance of a conference. 
 
Therfore, a 'UA' that is capable of hosting a conference will support the 
following URI:
[ and the definitions deviate from the conference draft ]

a) General-URI: This is a URI that represents an entity and does not 
necessarily have to do anything with conferencing.
e.g:  appserver.hns.com.
Typically, this URI will most likey be a publicly known URI.

b) FocusFactory-URI: This is is URI that represents the well known URI for 
hosting conferences. Typically, a message sent
to this URI to create a conference would return another URI which reflects 
an instance of a created conference.
eg.  conference.appserver.hns.com
[ In the case the entity is purely a 'conferencing server' the general-URI 
would likely be the same as the FocusFactory-URI]

c) Focus-URI: This is the URI that is returned by a FocusFactory that 
reflects a particular focus.
eg. [email-masked]. This will be the URI that 
participants will use for any further
activities within the scope of the created conference. 

So, if this is the case, when a participant wants to have a "sidebar" as a 
conference-within-a-conference does the current
"Focus" now become a "Focus Factory" ? ie . does he send the request to 
the Focus-URI or Focus-Factory URI ?
[ I would think in either case, it should work as the Focus may internally 
bubble the messae to the FocusFactory and that
is impl. dependant ?]

Now my additional comments:

* While "Focus Factory URI" and "Focus URI "  MAY be logically separate, 
they MAY practically reflect the same URI (for 
single-hosting-conferences).

* Theoretically speaking, I could extend the "factory" concept to all 
other entities including Media Server, Policy server etc.
but thats probably complicating things too much. I vote for the Factory 
and Instance only for the Focus and assume
that a Focus, once instantiated, forms relationships with other entities 
(Policy Sever, Media component etc) -> is there an issue
with this ? 

regds
Arjun

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

Paul Kyzivat <[email-masked]>
Sent by: [email-masked]
11/04/2002 10:02 AM

        To:     Orit Levin <[email-masked]>
        cc:     "Rosen, Brian" <[email-masked]>, [email-masked]
        Subject:        Re: [Sipping] Comments on johnston-sipping-cc-conferencing-00.txt(the 
second duck in theline ;-)

Orit Levin wrote:
> 
> Guys!
> It seems that we are debating the least controversial part in the whole 
set
> of the conferencing documents.

That should be a *good* thing! Means the stuff you though was 
controversial isn't.

> Below is my point of view.
> 
> Focus is the "conference factory" or the "conference server" itself.

In this you are in conflict with the framework document.

> (Focus
> is called "host" in the old version of the "requirements" draft.)

Which old version? The ones I can find, including one authored by you, 
don't define "host" or use it as a noun, or in any formal way. 

> According to all focus definitions, "Focus is a UA".

OK. No problem there.

> This UA has special
> capabilities of creating and "hosting" conferences (i.e. instances of
> Conference). Focus has two published AORs: one the general UA AOR, 
second
> the Focus AOR is the entry to its "conference factory".

You are now on shakey ground.

The way I have always thought of it, every distinct address is 
conceptually a unique UA. Since each "conference" gets its own address, 
every conference is itself a separate UA. And since the "factory" that 
creates conferences has an address distinct from the conferences it 
creates, it too is a UA.

"Focus" can be one or the other of these, but not both. According to the 
framework document, the Focus is the UA corresponding to the address of 
the conference itself. You need a different term to refer to the factory. 
(Note that the factory need not reside on the same "server" where the foci 
of the conferences it creates reside.)

> 
> I don't think we would like to start instantiating UAs (i.e. focuses) in 
our
> model (together with their AORs.)

That is exactly what you are doing when you specify that you can create 
new conferences, each with its own address.

This doesn't of course mean that we must start instantiating new physical 
servers to host the UAs. The UA is simply a logical (virtual) concept. All 
it requires is an extra entry in the server that hosts it, listing the 
user part of the address. Why is this a problem?

> 
> Based on current conferencing requirements and conferencing models, I 
don't
> see need for generating additional terminology. I would rather 
streamline
> some redundant definitions than introduce new (unless we identify 
practical
> need for them, of course!)
> 
> If the current focus definition is somehow misleading, I suggest fitting 
the
> definition to the model rather then fitting the model to the definition.

That's what I'm trying to do, and I think that is what the framework is 
trying to do. But clearly others have felt that new terminology is 
required. The term "focus"  doesn't appear in any meaningful way in the 
older requirements or model documents. I presume it has been coined to 
facilitate the creation of more precise definitions. But that doesn't work 
if we end up with "focus" itself having a fuzzy definition.

It is pretty common to mix up the definition of a server and the things it 
serves, or a factory and the things it creates, especially when first 
coming up with a conceptual model for something new. But eventually you 
need to sort out the differences. 

                 Paul

I don't have any problems with the framework.
_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Mon, 04 Nov 2002 14:54:39 -0500

> in agreement else here is another opinion on the plate ;-) ]

I think we are pretty close. More detailed comments follow.

	Paul

> manage a  particular instance of a conference.

For both of the above, I am not sure if it is better to say that the FocusFactory (Focus) *is* a UA, or *has* a UA. A UA is really only defined wrt sip signaling, while additional non-sip capabilities are being ascribed to the entity that creates and manages conferences, and possibly to the entity that represents a single conference too.

> [ and the definitions deviate from the conference draft ]

It might be safer to say "an 'entity' that is capable of hosting a conference ..."

> Typically, this URI will most likey be a publicly known URI.

I'm not sure about this. I'm not even sure if you mean a sip URI here.

I *think* you mean a case like a phone that can host a conference. It would have a general address (e.g. sip:[email-masked]) where private (unconferenced) calls may be directed. The same phone might also have some of the other kinds of addresses that follow below.

Its not clear that this kind of URI is useful for a central conference server.

> would likely be the same as the FocusFactory-URI]

This seems quite useful for a central conference server. But it doesn't seem especially desirable on a private phone that happens to be capable of hosting conferences. The conferences the phone wants to host for its user can probably be created better without this.

So I am inclined to think that (a) and (b) will typically be *the* general address for different kinds of entities. But of course one can imagine cases when both are useful for the same device.

> the Focus-URI or Focus-Factory URI ?

I don't see how any sip URI can help with this. You need a more complex protocol than a simple INVITE to set up the sidebar. There needs to be some way to find a suitable address to use to carry on a conversion using this other protocol. The framework also suggests this need, but doesn't say how it is accomplished. I don't think the -cc-conferencing draft says how to do this either.

There certainly needs to be a way for a participant to do this given nothing more than the URI of the focus, since that is all an average participant will have available.

> single-hosting-conferences).

I don't know what you mean by "practically reflect the same URI". In a very literal way they must be separate URIs, because they do different things in response to an INVITE.

I agree that in many practical situations they may both be URIs served by the same server.

> (Policy Sever, Media component etc) -> is there an issue

I don't know yet for sure. We must make distinctions if we need them. 

In the case of Conference Policy, the kinds of things that have been identified so far are on a per-conference basis, so if there is to be some sort of URI (not SIP) to designate conference policy, I would expect there to be a separate one for each conference - a Conference Policy URI. It may turn out that there is also a need to manipulate policy for the conference factory (perhaps to define the *default* policy setting for new conferences). If so, then there might also be a Conference Factory Policy URI. But I don't think we should define that unless there is need. (Also note that this is a Conference Factory Policy URI, *not* a Conference Policy Factory URI.)

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 04 Nov 2002 14:54:39 -0500

Paul

	Paul