> -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of > Krzeminski, Damian (BL60:9D30) > Sent: Monday, June 22, 2009 4:53 AM > To: [email protected] > Subject: Re: [sipX-dev] Config for bridged line appearances > (XX-4762/XX-5439) > > > Carolyn wrote: > > ... > >> There is no "master" in the BLA sense. Any set that > registers with > >> the shared line is part of the group, if it accepts > subscriptions to > >> the proper package (i.e. dialog;sla in the current implementation) > >> and subscribes to the proper package. In my config I don't have > >> "boss/admin" but just "sharedLine" and both sets register to the > >> sharedLine. No phone gets special treatment for the line, and it > >> doesn't need to be the "prime" line anywhere. > > > > We have to implement it in a generic way (not limited to > Polycom sets). > Polycom plugin can recognize that lines are shared and create > a specific configuration. In the sense of "plug-in" vs. > "core" functionality it's no different from let's say > phonebooks or time zone features.
In addition to the set-specific config, the shared user must be saved in some file so that the Appearance Agent (or Shared Line Agent, or other name suggestions welcomed) knows about it. I am not sure if that should be done on the main Add User page, or should be implicit from doing the set-specific config (though I prefer the set-specific stuff to be implicit, and the shared setting done at the user level - which might impose the limitation that all appearances of a user marked shared will in fact be shared - which is not actually required by the I-D, but seems reasonable to me). I admit to some confusion about "user" vs "line" vs "appearance". I think I use them interchangeably. The feature is "shared appearances of an Address of Record" (taken from the draft-ietf-bliss-shared-appearances draft, which is the latest evolution of the feature, though not the one implemented by the Polycom sets or my current implementation for sipx (which is draft-anil-sipping-bla-02)). In practice the AOR is a user, which is added as a line to sets. > > Before we decide how to expose it from UI I have some questions... > > - Is this an admin configurable or user configurable feature? > In other words are users allowed to add shared lines to their sets? I would think the "shared" nature of a line should be only admin-configurable. Can users add regular lines to their sets? I don't think so (but I am not sure). But in any case, since things must be shared between more than one user - it should require agreement between both users, or at least the oversight of the admin, before the line is marked shared. Otherwise I could share someone else's line, and steal any call they put on hold. Of course the feature might be used to transfer calls between two phones owned by a single person (e.g. a softphone and a hardphone). > - "Shared" line is like any other line on the phone (in a > sense you can make and receive calls on it). The only > difference is that others see the status of that line. Is > that correct? Yes and no. The shared line is like any other line on the phone (in the sense that you can make and receive calls on it). And as you say, others see the status of that line. The big difference is that calls can be handed back and forth between sets with an appearance of the shared line just by putting the call on hold on one set and taking it off hold (by pressing the button with the flashing light) on another - no transfer required. > - Can "external" lines (lines registered to a different PBX) > be "shared"? Hmmm... if they are registered to a different PBX then the line would be need to be marked shared on that PBX, but I don't see why it would not work. > - If you were to explain to someone not familiar with SIP (or > phones) the difference between BLA and monitored speed dials > what would you say? > I said it above. The monitored speed dials feature shows the status of the line but does not allow the other sets to grab the call. Future evolutions of the shared line feature allow the other sets to join in the call as well (the first implementation only allows the call to be passed around by holding it). Carolyn _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
