Carolyn wrote: ... > The agreement we had in the kick-off call with Martin at the > start of development was that we would not implement support > for the "multiple appearances-per-phone" part of the I-D (the > x-line-id parameter, later called appearance or > sa:appearance). I have basically ignored this parameter and > let the phones deal with it. Especially, I am not at this > time putting the x-line-id parameter into an Alert-Info > header in the INVITE of a call to the shared AOR, as the I-D > requires (which would require the SAA to be plugged into the > Proxy). When the call is answered at one of the phones, it > picks an x-line-id (it knows what numbers are available, > since it sees all the traffic for the group) and sends it in > the dialog;sla NOTIFY. > > In our Polycom config plug-in, you can go into Advanced and > set the lineKeys parameter to 2 or more to get more than one > button per AOR. It is possible that calls would be confused > if more than one was on hold - but I think that would be the > case anyway, even if all sets had the same number of > appearances, because sets can't be counted on to have all the > buttons in the same place, and even if they did, the person > would have to say "your call is on hold on the second from > the bottom button", or "middle button on the right" or some > such nonsense - and even then all phones would have to > guarantee not only the same number of line buttons for the > AOR, but buttons in the same physical place. We could allow > only one appearance of the shared AOR per phone. I would > like people to play with the feature a bit before we make > this decision.
Note also that Polycoms have a 'callsPerLineKey' setting: The number of calls or conferences which may be active or on hold per line key for a specific registration on the phone. The blank default value results in the max value, which is either 8 or 24, depending on the model. I don't think this constitutes "multiple appearances-per-phone", but I'm not as familiar with the draft as you. But it is at least probably something to test. -Paul [email protected] _______________________________________________ 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/
