I agree with Francois that we might be going to far down the path of emulating 1960's technology. I ran Francois' last post past our HCI guru and he was in complete agreement.
What we are missing from 'normal sip' which I think is useful: * being able to yell an appearance# across the room * being able to pick up/join a call based on that # Then we have the requirements that I don't think we need to support to give people the same workflow: * selecting a particular appearance before a call is placed * binding an appearance to a 'line button' * using the appearance numbers to represent a resource limit. If somebody wants to make a hard phone that has appearance buttons, the appearance light would not turn on until an appearance was acquired. If we wanted to do a very lightweight solution(the first 2 requirments) this could just be done in INVITE messages and INVITE responses by plugging an app server which adds a header for appearences. This could be done as a redirect or spirals. -Derek On Wed, Mar 19, 2008 at 3:21 PM, Francois Audet <[EMAIL PROTECTED]> wrote: > I don't think "let's replicate a 50-year old key-system design" is a good > approach. > > These systems worked like this because back then pressing on the button > would actually > switch the physical line. It's increadibly archaic. > > If some manufacturer wants to sell a SIP phone that looks like a 1960's > desk phone, > good luck to them. I'm okay with that. > > But I really think that it would not be the IETF's job to create an arcane > protocol > to mimimic a 1960's phone behavior. Especially iritating features. > > I believe the behavior your are looking for, including irritating arcane > "features" > (i.e., somebody "seizing" the line before the other one) can be > implemented without > a new protocol such as BFCP or a gazillion PUBLISH/NOTIFYs. > > The two guys in your example are both registed with "line2" as AOR. Call > comes in for > line2, and is forked to the two guys. Normal SIP. Guy 1 answers and gets > the call. Guy 2 > answers slighly later and gets the error tone because the call has already > been answered. > Again, plain Jane SIP. > > Also, if the two guys actually want to see the line "status", they can > subscribe to the > presence (or dialog package) of AOR "line2" and display it on the line > appearance. > > > -----Original Message----- > > From: Rohan Mahy [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, March 18, 2008 17:36 > > To: Audet, Francois (SC100:3055) > > Cc: Venkatesh; Mohsen Soroushnejad; [email protected]; Rohan Mahy > > Subject: RE: [BLISS] MLA with Floor Control > > > > Hi Francois, > > > > The problem I think you are missing here is that we are > > trying to satisfy requirements to generate two very different > > user experiences: > > > > A feature typically associated with every major PBX where > > pressing an unused "line button" on a single shared > > appearance gives me a dial tone. > > If someone else starts to compose a number at the same time, > > the relative order of the calls for this appearance can be > > different and that is OK because these "line buttons" are > > typically not labeled distinctly, they all have the same name. > > > > A feature typically associated with most Key Telephone > > Systems where pressing the button "line2" on two phones > > results in an error tone for whoever is slightly later. This > > feauture, while extremely irritating, allows folks to yell > > out "Hey, Neil, call for you on line 3". Each button has a > > distinct name. > > > > I have personally used these two very different features on > > my desk in a production office setting at different jobs. > > > > This second feature requires exclusive access to a shared > > resource (use of the "line 2" identifier). This is the > > definition of floor control. > > > > If you just want to implement feature 1, you don't need > > exclusive access and therefore you don't need floor control. > > > > We have a working protocol that is pretty easy to implement. > > Since a shared line system with exclusive access needs very > > close proximity, we can probably assume that all the phones > > with shared access are on the same subnet. We don't need to > > do anything fancy for NAT traversal of BFCP among the members > > of one of these groups. As for whining about "another > > protocol", we had a lot of phone vendors implement STUN in a > > short period of time, because it is easy and it added value. > > I don't think BFCP is any different here. > > > > Now let me say a few words about why I think PUBLISH is such > > a bad idea. > > What are the semantics of PUBLISH here? This feature depends > > entirely on a specific composition policy for the feature to > > work. This is the first event package I can think of where > > the composition policy is normative. > > There is also an interoperability problem. How is the UA that > > implements feature 1 supposed to find out that its compositor > > is using the feature 2 composition policy? It can't tell. > > It will get an error for the PUBLISH, but the phone will > > still let the user dial and will keep sending PUBLISH > > requests that will continue to be discarded. You want to > > model two features here, but the proposed PUBLISH approach > > requires that the compositor and all the publishers have the > > same policy, and you are providing no way to tell what the > > policy is. This is a massive opportunity for things to go wrong. > > > > Finally, I think the PUBLISH error message semantics are > > wrong. If I have a presence agent that is spewing presence > > that makes no sense (the chair sensor at my office is stuck > > and reports that I am the office, when I am clearly yacking > > away on my phone in another country), a good compositor > > should *ignore* the publications instead of sending an error, > > since the chair source of presence is no longer credible. > > What you want a compositor to do is not composition, it is > > arbitrating exclusive access. > > These are very different. > > > > thanks, > > -rohan > > > > > > > > > I also have the same opinion. > > > > > > This seems completely overkill to me. > > > > > > I think we should step back and try to see if there is no > > alternative > > > to implementing MLA. Seems to me we are diving head-first > > in über-complexity. > > > > > > I personally think it would be a lot simpler to have each Line > > > Appearance being a AOR that one can Register with and subscribe to > > > it's presence and/or dialog package. > > > > > > The Presence server could "compose" the presence status of the AOR. > > > Similarly, if dialog information is also needed, then a > > sort of Dialog > > > status server could also "compose" the Dialog state for the > > aggregate > > > of UAs. > > > > > > For example. > > > > > > Say we have 5 lines (line1, line2, line3, line4, line5). > > > > > > If my phone is able to make/receive calls for line1, line2, line3, > > > then it will register all 3 lines. If I have a line > > appearance on my > > > phone (LED or whatever), I can also subscribe to either Presence or > > > dialog package for these 3 lines (as appropriate). That > > way, if some > > > other phone picked up line 2, then I'll see the status on > > the phone. > > > (Some server would "compose" the presence/dialog status). > > > > > > For answering calls on various line appearance, it's a no-brainer > > > (call just forks). This is the most common usage. > > > > > > For transfering/conferencing/manipulating calls on various lines, > > > REFER, Replaces, Pickup, Retrieve, etc. and other existing > > mechanism > > > should just work as is. > > > > > > Furthermore, this sort of approach will actually allow > > existing phones > > > with no inherent support for MLA to work in an environment > > where MLA > > > Is used. For example, the same line appearance could be used on a > > > MLA-supporting phone (multiple line) and a normal phone > > that has only > > > one appearance. > > > > > > > > > > > > ________________________________ > > > > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > > Behalf Of Venkatesh > > > Sent: Thursday, March 13, 2008 22:35 > > > To: Mohsen Soroushnejad > > > Cc: [email protected]; Rohan Mahy > > > Subject: Re: [BLISS] MLA with Floor Control > > > > > > > > > Alan, Rohan, et al: > > > > > > I second Mohsen's suggestion. I think it makes sense to > > find out what > > > the disagreements were with using either using NOTIFY's or > > PUBLISH. If > > > either of them violates the RFC, what would it take to > > augment the RFC > > > to accomodate these flows assuming that the changes being requested > > > are reasonable enough and does not drastically break anything else? > > > Finally, the proposal below looks like an overkill to me in > > terms of > > > what it is trying to achieve and is probably going to be left with > > > little implementations. > > > > > > Thanks > > > Venkatesh > > > > > > > > > On Thu, Mar 13, 2008 at 10:24 PM, Mohsen Soroushnejad > > > <[EMAIL PROTECTED]> wrote: > > > > > > > > > Hi Alan - > > > > > > > > > Thanks for leading the discussion on this draft. > > > > > > >>In this week's WG meeting, a number of people > > expressed concern about > > > the use of PUBLISH to select appearance numbers > > as was proposed. Others > > > also object to the use of NOTIFY as well.<< > > > > > > If you don't mind, please provide a synopsis of > > what these concerns > > > were at the meeting w.r.t PUBLISH and NOTIFY usage. > > > > > > In addition to BFCP discussion, I like to see > > discussions on: > > > > > > - Extending NOTIFY usage (why not a NOTIFY 2.0?) > > > - Extending PUBLISH usage (why not a PUBLISH 2.0?) > > > - Hey, let's use INFO -- I know I get shot for > > saying this....;-) > > > > > > My initial reaction w.r.t. goal of BLISS (i.e., > > interoperability on > > > running code) is that by adding yet another protocol that a SIP UA > > > must support (i.e., BFCP), we're pushing it to the next > > decade, if not > > > further. Is this a necessary price to pay? > > > > > > I look forward to discussions on the list. > > > > > > Best Regards, > > > Mohsen > > > > > > > > > On Thu, Mar 13, 2008 at 7:18 AM, Alan Johnston > > <[EMAIL PROTECTED]> > > > wrote: > > > > > > > > > All, > > > > > > In this week's WG meeting, a number of > > people expressed concern about > > > the use of PUBLISH to select appearance > > numbers as was proposed. > > > Others > > > also object to the use of NOTIFY as > > well. Rohan made the suggestion to > > > treat an appearance number as a shared > > resource and use floor control > > > and the Binary Floor Control Protocol > > (BFCP) to do selection. > > > > > > I have done some preliminary thinking > > about how we could manage > > > appearance numbers as a floor and > > utilize BFCP (RFC 4582) to > > > request and > > > learn appearance numbers. We should > > discuss these options on the list > > > and use the resulting consensus in the > > next version of the document. I > > > will leave my opinions out of this > > initial email but will express them > > > in the resulting followup discussion. > > > > > > This design would not modify the dialog > > event package - it would remain > > > as is and would contain dialog > > identifiers. Normal dialog state > > > information would be published to an > > event state compositor (ESC) and > > > notifications would be sent by the ESC > > - none of this would be > > > appearance aware. > > > > > > Each floor would have a floor ID > > associated with it. A simple solution > > > would be for the floor ID to be the > > appearance number, so in this usage > > > of BFCP, only non-negative integers > > would be used as floor IDs. > > > > > > A UA in the group wishing to learn the > > holder of an appearance number > > > would query the floor control server > > and receive a response from the > > > floor control server. Each floor > > would contain the owner which would > > > be the GRUU of the dialog to which the > > floor is associated with. This > > > GRUU could be used be used to lookup > > the dialog identifiers in the > > > dialog package notification so that UAs > > could perform call control > > > operations such as INVITE Join, INVITE > > Replaces, etc. > > > > > > A UA in the group making a call would > > first request a floor from the > > > floor control server. If the floor was > > unavailable, the UA would try > > > again. The floor control server would > > be configured to not do floor > > > request queuing. Once a floor was > > obtained, an INVITE could be sent > > > and the dialog information published. > > > > > > An incoming call to the AOR would > > somehow be known to a moderator > > > client. The moderator client would use > > some predetermined logic (first > > > available, for example) and request an > > available floor from the floor > > > control server. The INVITE would then > > be forked to the UAs in the > > > group. The INVITE would need to carry > > the appearance number, such > > > as an > > > appearance parameter on an Alert-Info > > header field as defined in the > > > current draft. (I don't know of any > > way a UA could learn the floor > > > number from the floor control server > > unless there is a command to list > > > all floors in use and find the one that > > is not associated with any > > > dialog.) > > > > > > With this design, UAs would implement a > > BFCP client and a SIP UA. The > > > ESC would not need any extensions. The > > BFCP server would not need any > > > extensions. The moderator client would > > be a special piece of software > > > that could coordinate with the forking > > proxy to learn of incoming calls > > > and provide an appearance number to > > insert into the Alert-Info header > > > field. > > > > > > When a call ended, the UA would release > > the appearance number to the > > > floor control server which would then > > be free to assign the appearance > > > number for future incoming or outgoing calls. > > > > > > UAs would need to publish their dialog > > state to the ESC and > > > subscribe to > > > the ESC to learn dialog IDs of other > > UAs. UAs would also need to > > > establish a BFCP connection over TCP > > (by sending an INVITE to the floor > > > control server using RFC 4583). We > > would need to define how the UA > > > learns the SIP URI of the floor control server. > > > > > > Of course, this needs further analysis > > but it would be useful to get > > > feedback before more work is put into > > this approach. > > > > > > Thanks, > > > Alan > > > > > > > > > > > > _______________________________________________ > > > 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
