Scott Lawrence wrote: > > On Fri, 2008-09-26 at 09:43 -0400, Paul Mossman wrote: > > Hi all, > > > > In the existing 2007-02-28 sipXrls proposal the Polycom's > BLF button > > is configured with a contact that includes the retrieve > code, so that > > pressing the button results in dialing of the unpark code for the > > orbit. The drawback with this is that because the contact > is not the > > Park Orbit's extension, the BLF button cannot then be used when > > parking a call. i.e. "Trnsfr" softkey --> "Blind" softkey --> Park > > Orbit BLF button. > > > > A main goal is that the Park Orbit extension should never > need to be > > composed on the keypad. We can do this today with two > buttons. The > > Park Orbit is BLF monitored with one button, which is only pressed > > while invoking a Transfer to park a call. Parked calls are then > > retrieved by pressing another button which is a basic speed dial > > containing the system Call Park retrieve code followed by the Park > > Orbit's extension. > > > > But two buttons per Park Orbit is confusing. (The boss wants to be > > able to press the button that is lit to retrieve the call.) It is > > also a waste of a button. The challenge with converging > this into a > > single button is that in different situations the phone > would need to > > use a different contact for the Park Orbit button: either the > > extension, or the retrieve code followed by the extension. > > > > > > This proposal would achieve single button retrieve, while still > > allowing the button to be used when parking the call. It > required two > > changes, both to sipXecs only: > > > > 1. sipXpark would intentionally fudge its Dialog Event NOTIFYs to > > report the dialog state of parked calls as "early" instead of > > "confirmed". This would have the following two desirable effects: > > > > > > a) BLF monitoring of an occupied park orbit would show "ringing" > > indication. While the parked calls are not technically ringing, I > > think the user experience is actually desirable. (It is a > queued call > > waiting to be attended to.) And since the park orbit > doesn't actually > > ring for any significant period of time, I think we can > commandeer the > > "ringing" indication without confusing the user. > > > > > > b) Since parked calls show up with "ringing" BLF > indication, they can > > be un-parked by pressing the BLF button to invoke the Polycom's new > > Call Pickup functionality. (XCF-2716 added the required > > configuration...) > > > > > > 2. For b) to happen I think the Call Pickup redirector > will need to > > be a little smart. It will have to know that the Call > Pickup INVITE > > with Replaces for park orbits should not have the > "early-only" flag, > > since the target set is actually in a "confirmed" dialog. > But, this > > redirector already does call un-park anyway, so that shouldn't be a > > big change. > > > > > > There is no change to sipXconfig required. To configure this you > > simply create a User Speed Dial for the Park Orbit, and select > > "Subscribe to Presence" in order to enable BLF monitoring. > > > > This would also effectively remove the need to have distinct Call > > Pickup and Park Retrieve codes. > > > > I've also mimicked a "multiple call" park orbit with a plain user > > extension. The Polycom sets are even smart enough to handle this > > well. i.e. When you hit the "ringing" BLF button during a Transfer > > the set knows to dial the contact, instead of attempting a Call > > Pickup. > > > > > > > > Does anyone see problems, refinements, or anything that > I've missed? Thanks. > > Sounds like the right user experience. > > If it can be implemented in a way that doesn't break other > phones, this sounds like a good approach.
Arjun pointed out that some phones in confirmed dialogs may not obey a REFER with Replaces, as item 2 above depends on. I can eliminate this dependency and reduce the amount of work with an alternate approach: 2. For b) to happen the Call Pickup redirector will need a slight change to its handling of Call Pickups executed on Park Orbits. When a Call Pickup is executed the redirector must determine if the target is a Park Orbit. If so, then the redirector will proceed with an Un-Park, instead of a Call Pickup. (Including using the existing FIFO un-park order functionality.) In this way we are simply mapping the *78 that the Polycom dials into the *4 we want for the existing Un-Park sequence to occur. This should work seamlessly (in theory) on any phones that can already un-park and be un-parked. Thanks. -Paul _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
