> -----Original Message----- > From: Mossman, Paul (CAR:9D30) > Sent: Monday, June 22, 2009 2:40 PM > To: Beeton, Carolyn (CAR:9D60); [email protected] > Subject: RE: [sipX-dev] Config for bridged line appearances > (XX-4762/XX-5439) > > Damian wrote: > > > 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. > > What other phones will this support? What will happen if > it's enabled for a phone that does not support it?
At the moment, only Polycom phones support it. > > > Carolyn wrote: > > 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). > > Maybe it doesn't need to be configured at all? > > i.e. The superadmin has configured two Polycoms to both have > a line registered to the same user. Therefore both phones > can make and receive calls on that line. It makes sense that > both phones should then be able to see the status of the line > and pick up call that are on hold. > > This depends of course on how graceful non-supporting phones > can be handled. > > Also, suppose the feature is configured "on" for all users > (in the Shared Line Agent), but no phones in the system are > configured to use it. What is the CPU and SIP messaging > overhead for a user with one registered phone? With more > than one registered phone? > The Appearance Agent still needs a list of AORs to subscribe to, for reg-events. This list could be all the AORs in the system, or just the ones marked as "shared". When the Appearance Agent receives a reg-event NOTIFY for one of these AORs, it SUBSCRIBEs to the Contact given (this would be u...@uax). The UA (set) also SUBSCRIBEs to the Appearance Agent, and dialog;sla events are passed back and forth in NOTIFY messages. In the newer version of the draft-anil I-D (draft-anil-sipping-bla-04), the name of the event package is changed to dialog;ma. If we are going to support both, then we will have to try two SUBSCRIBEs. I do not think that we should attempt to SUBSCRIBE to every AOR defined in the system, in case one of the phones supports shared lines. I would prefer the list of AORs to only include users marked as shared, and that help text wherever that setting is qualifies that it will only work on phones that support it. Then when that AOR is added as a line on a phone that supports shared lines, it should be configured as a shared line. That would allow the current behaviour of lines on different phones having the same user (but not shared), as well as the optional sharing. The newest drafts version of shared line appearances (draft-ietf-bliss-shared-appearances) does not require the Appearance Agent to subscribe to the set; the set still subscribes to the Appearance Agent, but the Agent is plugged into the Proxy to get the call state. This is different enough from the draft-anil that I have not thought much about how it would be implemented. Once we get there, it might not be necessary to mark the AOR as shared because only phones configured to share the line would attempt to SUBSCRIBE. However, there are no phones that currently do this, and even if some become available, we will certainly have a mix for the forseeable future. 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/
