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

From: "Arjun Roychowdhury" <[email-masked]>
Date: Mon, 4 Nov 2002 16:59:57 -0500

Paul,

<snipping away to maintain readability > [ the original mail follows later 
for readers to grab more context of the snips here ]

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

arc> ok

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

arc> Agree that this URI is not useful for a central conference server.
I was sighting it as a URI which the 'server' can advertise to possibly
provide alternate services beyond 'conferencing'. What I was initially
thinking of was if a client sends OPTIONS to 
sip:[email-masked]
it may want to return besides the Focus URI, another URI like 
sip:[email-masked]
that may hint to the client a more generic service URI of which 
conferencing is a subset.
Though its not related to 'conferencing' the client should be prepared to 
possibly
also get a uri from the server which is like the above and it may present 
this to the user
if it wants to act more on it. Anyway - that was just a thought. Again, 
like I said,
I do agree it does not make sense for a pure conferencing server.

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

arc> Well, for a very simple conferencing server, which can host only
one conference at its well known address, it may well be that 
sip:[email-masked]
is the FocusFactory URI as well as a Focus. In this case, FocusFactory and 
Focus are logically
separate, but serviced by the same URI. My point therefore is to enfore 
them as logicall separate
functions but not mandate a phyiscally different URI for each.

pk> (Also note that this is a Conference Factory Policy URI, *not* a 
Conference 
Policy Factory URI.)

arc> True and Ouch - I can pretty much see how this factory terminology 
can soon go out of hand
for confusing terminology if not handled properly ;-)

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

- - - - - - -- - - - - - original mail follows - - - - - - -- - - - - -

Arjun Roychowdhury wrote:
> 
> 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 ;-) ]

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

                 Paul

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

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.

> 
> Therfore, a 'UA' that is capable of hosting a conference will support 
the
> following URI:
> [ and the definitions deviate from the conference draft ]

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

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

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.

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

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.

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

> [ 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).

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.

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

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

---

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

I think we are in sufficient agreement to end this thread.

	Paul

> for readers to grab more context of the snips here ]

Thanks for doing the digest - it helps.

> I do agree it does not make sense for a pure conferencing server.

This is fine with me if it makes sense. 

Having OPTIONS return a bunch of Contacts is only helpful if there is some well defined way to distinguish them. The idea of using callerprefs for this probably satisfies that need.

> functions but not mandate a phyiscally different URI for each.

What is the point of having a factory if there can be only one conference? All you need is the conference URI.

> for confusing terminology if not handled properly ;-)

Yup!

---

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

Paul

> for confusing terminology if not handled properly ;-)

Yup!
_______________________________________________
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