We've got a variety of options currently on the table. I'm going to take
a stab at enumerating them, without a discussion of their merits:
1A) Single AoR for the MLA Group. Clients send PUBLISH & compositor
sends NOTIFY
to accomplish a bidirectional exchange of dialog state. Floor
control
accomplished with separate mechanism (ie BFCP) between client & a
distinct
floor control server
1B) Single AoR for the MLA Group. Compositor sends NOTIFY to inform
clients of
dialog state. Server is responsible for monitoring call activity
and
composing dialog state. Floor control managed accomplished with
separate
mechanism (ie BFCP) between client & a distinct floor control
server
2) Single AoR for the MLA Group. Clients sends PUBLISH & Appearance
Agent sends
NOTIFY for bidirectional exchange of dialog state with integrated
floor control (this option is the current MLA draft)
3) Separate AoR for each appearance within the MLA group. Compositor
sends
NOTIFY to inform clients of dialog state. Server responsible for
monitoring
call activity and composing dialog state. Floor control via an INVITE
based
mechanism.
4) "Alternative Features" - utilizing other features such as call
forking,
call park, and simple SUBSCRIBE/NOTIFY for dialog info, to provide
similar or better end-user experience with alternative work flows
that
do not require MLA.
Are there other options, or corrections to the above?
Along the same lines, I think it would be useful to define evaluation
criteria. Here's a first draft of a list
1) End-user experience across a variety of use cases
- 3 use cases listed in the MLA draft. Other suggestions welcome.
2) Resource requirements on client
3) Resource requirements on server
4) Efficiency & robustness of call flows
-Bill
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Francois Audet
Sent: Thursday, March 20, 2008 10:17 AM
To: Elwell, John; Rohan Mahy; Paul Kyzivat
Cc: [email protected]
Subject: Re: [BLISS] MLA with Floor Control
Bingo.
I agree with John 100%.
Aping legacy key systems (or PBXs) should really be a non-goal for
BLISS.
It's a loosing battle.
"Equal" means they won't upgrade to SIP (and I'd argue that in fact, it
won't be "Equal" but "Almost-as-good"). We have to do "Better" if we
want
to be successful.
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Elwell, John
> Sent: Thursday, March 20, 2008 08:38
> To: Rohan Mahy; Paul Kyzivat
> Cc: [email protected]
> Subject: Re: [BLISS] MLA with Floor Control
>
> Catching up on this whole thread, it seems to me that the
> discussion revolves around two aspects: "shout-control" and
> "line seizure".
>
> For shout-control, I believe the proposal from Francois of
> using separate AoRs, rather than a single AoR with multiple
> appearances, can be made to work and can be mapped to current
> UI practices if that is desired. Shortened forms of the AoR
> can be used to make them more user-friendly.
>
> For line seizure, I have to ask why is the IETF worried about
> this? I just did an experiment on my desk SIP phone, and yes,
> I can obtain dial tone, but all the time I have had the phone
> I don't recall using that feature. I either select a number
> from my address book or pre-dial the digits, and then I hit
> "go" (the way people have been doing it on cell phones for
> the last decade or more). When I hit "go" my phone can choose
> an AoR that is free, and that then gives me the "appearance
> number" that I can shout across the room. There is, of
> course, a race condition, whereby two phones hit "go" at the
> same time and attempt to use the same AoR, or an incoming
> call arrives on that AoR at the same time as an outgoing
> call. If you have some agent at the proxy policing the
> one-call-per-AoR rule, it can reject an outgoing call request
> when the race condition occurs and the UA can try again on a
> different AoR.
>
> Defining new protocol just so that I can have this dial tone
> thing and anchor my call to an appearance before I actually
> dial does not seem a compelling feature to me. If it is
> really required, then what about an empty INVITE request that
> somehow gets put into some wait state until a complete INVITE
> request arrives? This would be rather like the horrible
> overlap sending work-around from the days we were doing PSTN
> interworking, but quite frankly dial tone is a PSTN thing.
>
> John
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> > Of Rohan Mahy
> > Sent: 20 March 2008 15:08
> > To: Paul Kyzivat
> > Cc: Rohan Mahy; [email protected]
> > Subject: Re: [BLISS] MLA with Floor Control
> >
> >
> > On Mar 19, 2008, at 6:05 PM, Paul Kyzivat wrote:
> >
> > > kibitzing...
> > >
> > > Francois Audet wrote:
> > >
> > >> The reason why one wanted to "seize the line" for an
> > outgoing call
> > >> back then was
> > >> because it was a physical piece of wire. It was a physical
> > >> limitation of the system.
> > >> Being able to have multiple people use the same line for an
> > >> outgoing call actually seems like a feature to me, not a
> bug. Yet
> > >> another reason why ditching the old key system is good.
> > >
> > > There is a tradeoff...
> > >
> > > If multiple extensions can place outgoing calls from the
> > same line,
> > > then the line doesn't have "binary" status, so it can't
> be indicated
> > > as active or not with a light. And you can't "conference in" by
> > > picking up on the same line.
> > >
> > > While I am not into it myself, I can see how someone can build a
> > > "business process" around the specific way in which lines are
> > > managed by the phones, and then be very upset if they
> can't get that
> > > same user experience.
> >
> > ...and that upset "someone" may not be the actual end user.
> >
> > > Now you can come up with some very nice UIs that provide
> better user
> > > experience, if you have a suitable display instead of
> just a bunch
> > > of lights. (E.g. an entry for the "number" (AOR that
> people call),
> > > and a variable length drop down list of active calls, showing the
> > > callerid of the caller, how long it has been active, and which
> > > extensions are currently connected to it.) But that is
> *different*,
> > > and requires a device with richer UI.
> >
> > my personal favorite UI for handling calls in the environment I
> > described in my mail to Francois is that when I receive an incoming
> > call for a specific person, I can single-step transfer the
> call to the
> > personal parking lot of the person who should take the call.
> >
> > thanks,
> > -rohan
> >
> > _______________________________________________
> > BLISS mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/bliss
> >
> _______________________________________________
> BLISS mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/bliss
>
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
