RE: [XCON] CPCP Requirement: Repeat times
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [XCON] CPCP Requirement: Repeat times
- To: "'Michael Hammer'" <mhammer at cisco.com>
- Subject: RE: [XCON] CPCP Requirement: Repeat times
- From: "Rosen, Brian" <Brian.Rosen at marconi.com>
- Date: Fri, 6 Feb 2004 13:33:08 -0500
- Cc: "'petri.koskelainen at nokia.com'" <petri.koskelainen at nokia.com>, fluffy at cisco.com, "Rosen, Brian" <Brian.Rosen at marconi.com>, drage at lucent.com, klantz at cisco.com, xcon at ietf.org, dbieseli at cisco.com
- List-help: <mailto:xcon-request@ietf.org?subject=help>
- List-id: Centralized Conferencing <xcon.ietf.org>
- List-post: <mailto:xcon@ietf.org>
- List-subscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,<mailto:xcon-request@ietf.org?subject=subscribe>
- List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,<mailto:xcon-request@ietf.org?subject=unsubscribe>
- Sender: xcon-admin at ietf.org
> >End when last person leaves is the way many bridges work.
>
> Is that a technical justification?
Actually, I think it means there is a requirement for that to be possible.
>
> >You might
> >not like it, but that's the way they work. Most bridges don't
> >start if the convener is not there. If he arrives, and then leaves,
> >the conference is over.
>
> What is the meaning of conference policy then? I thought
> that it was an
> authorization for something to take place. If the conference
> is authorized
> to start and someone shows up, then it starts. If it is
> authorized to
> stop, and the bridge resources are needed elsewhere, then it stops.
CPCP has two elements, and they each have a role in policy.
A particular implementation, or more properly, a particular administrative
action, may restrict the range of possible policy requests the convener
may ask for. The bridge may not respond the way the convener would like
it to. It must be possible for the bridge to have local policy, and yet
allow the convener to manipulate whatever freedoms the local policy
permits.
You could have the bridge change the start/stop time itself to implement
its local policy, but that makes the function even more twisted.
Better to have explicit mechanisms, and let the bridge implement, or permit
a subset of them if it wishes.
>
> >It also doesn't work to manipulate stop time to end the
> conference because
> >its the bridge that wants to enforce its policy and not the convener.
>
> Who is the authority here? Isnt' the bridge-providing
> service supposed to
> obey policy?
As above, local policy must override.
....snip...
> strategy, and an implementation detail. It seems the
> confusion here stems
> from not separating:
>
> Is a conference authorized at the moment,
> Is a bridge needed at the moment,
> and should a bridge be reserved at the moment.
I don't see it that way. I see it as the bridge has local policy,
the convener wants to exert whatever freedom the local policy permits,
and the participants have to have some way to understand what is
going to happen.
>
> >We have to be explicit.
>
> Yes, particularly as to the semantics of policy. What does
> start time
> mean? What does stop time mean? I keep seeing primary
> meanings tangled up
> with secondary and tertiary implementation implications.
I've proposed that start time is the earliest time at which
mixing starts.
I've proposed that stop time is interpreted by the stop time
enumeration. It could be a hard stop of mixing resources, or it
could be only advisory.
>
> >As to Cullen's objection, what you are worried about is start time,
> >and not stop time. By your definition, the conference never started.
> >If it did start, then it ends when whoever showed up leaves
> (if that's
> >what the conference policy was set to), or when the convener leaves,
> >which is surely the right thing. I don't know how to fix
> your problem
> >actually. Maybe some kind of action that resets start.
>
> The bridge may need to be released and re-captured, but that
> does not mean
> the conference is re-started.
Possibly a minor semantic argument. I think we both agree that
the scheduled conference did not take place. What is the
difference between "release and recapture" and "reset start"?
>
> > The problem is,
> >that would have to be a convener action; you wouldn't want a
> participant
> >to invoke it.
> >
> >Also, Petri, you can't implement a "Meet Me" with
> start/stop. MeetMes don't
> >have start and stop times.
>
> You are asserting what the group is attempting to define.
Well, we can twist start and stop, but to any person, a meet me, by
definition, does not have start and stop times. Could we implement it
by twisting start/stop? I guess, but I don't think its a good idea.
>
> > They start whenever the convener arrives,
>
> What if the convener never arrives, but the rest of the group
> does? To say
> it never starts seems rather limiting in an unnecessary way.
That's the way Meet Me (notice the word "Me") services are defined.
I happen to think its an excellent service. I would not want anyone
to be able to use my Meet Me conference if I was not there.
I am charged for it. If 4 people know my MeetMe URI, they can decide
to have a conference (on my nickle) any time they want if there is
not a restriction that convener starts. That is precisely why MeetMe
works the way it does. Its not a current technology limitation.
I have no problem at all in allowing CPCP to facilitate an ad-hoc
conference, which is what I think you are looking for. Ad-hoc is
a conference starts either by promoting a one on one to a three way,
or by the first person connecting to the conference, and it ends when
the last person leaves (or for some, when the number of participants
drops below 3). Ad-hoc is also a useful service, but usually we use
ad-hoc internally where charging issues are simpler.
>
> >end
> >when he leaves (usually),
>
> This again is not necessary. A convener (payer) may want to
> start the
> conference, but not stay for the full discussion. No reason
> the conference
> can not continue without that person, if the policy says it can.
Agree, but I want you to explicitly say that, and I want local policy
to be able to permit you to say that, or deny you the ability to say that.
>
> >but restart when he arrives again with out regard
> >to start and stop.
>
> A new start and stop time is a new conference, perhaps an ad hoc
> one. There is no reason the conference policy would restrict
> the convener
> from scheduling multiple conferences, unless there is other
> local policy
> that over-rides the ability to do so. But, that again is
> implementation.
Well, a new start/stop MAY be a new conference, or it could be a reschedule
of an existing one. Take a scenario where a couple of participants show,
the convener doesn't, and the participants leave. The convener pushes
start and stop an hour. If its a new conference, there is a new conference
URI.
If its a reschedule, then its the same conference, and the same URI. I
think
that is preferable.
Local policy, as I advocate, is indeed a controlling factor. However, to be
successful, the convener and the participants have to know what the local
policy is, so that their expectations are met. That means CPCP has to have
ways of the participants including the convener to learning the local
policy,
which means the language has to have the ability to express it. It's not
just implementation.
>
> I hope the tone of the above does not sound harsh. I just
> think it would
> be useful to separate the definition of "what" the conference
> is from the
> definition of "how" it is to be supported.
Confused about "what a conference is". I think we are all working on the
"how it is to be supported". I don't even want to think about a definition
of what it is. For example, if I play music on hold to you while you are
waiting for a conference to start, is that part of the conference? You got
there with the conference URI, you can probably manipulate some resources
_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.