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
