 |
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
Damian Krzeminski - 2007-02-23 12:50
I am not sure how it can be fixed in sipXconfig: it seems to me that either phone needs to support assigning speeddial extensions to the same buttons that are used as BLF subscriptions (and the phone does not support it now) or we devise some clever trick to retrieve the call from park orbit (which is probably PBX improvement not sipXconfig improvement).
It appears that this cannot be done via Polycom phone configuration. We need to figure out a way we can achieve this with Polycom phones from sipXpbx side. We need to experiment with Polycom phones. Press the button and see what phone sends. With that information, we may be able to cause it to retrieve a parked call. More investigation will be needed.
In regard to BLF buttons, when the user pushes the button, the Polycom sends an INVITE to the URI which the Polycom thinks is the URI being monitored by that button.
The RLS can deceive the Polycom in a way that implements the BLF call-retrieve feature: For instance, if the BLF monitors orbit 700, the RLS can monitor sip:700@example.com. But in its event notices, it can tell the Polycom that the URI being monitored is sip:*4700@example.com. Thus, when the user presses the button, the Polycom initiates a call retrieve operation on orbit 700. In order for the RLS to do this, it needs information beyond what it already receives. Probably the simplest way to do this is to add an optional attribute to the <resource> element which provides the "action URI" to be attached to the button. For instance: <lists xmlns="http://www.sipfoundry.org/sipX/schema/xml/resource-lists-00-00"> <list user="~~rl~2"> <name>111</name> <resource uri="sip:333@maine.pingtel.com"> <name>333</name> </resource> <resource uri="sip:700@maine.pingtel.com" action-uri="sip:*4700@maine.pingtel.com"> <name>700</name> </resource> </list> </lists> (We own the schema of the resource-list.xml file, so we can modify it at will.) I expect that sipXconfig can generate the action-uri field fairly easily, by checking the resource to see if it is a known parking orbit, and if so, composing the action-uri using the call retrieval prefix. In the above 2007-02-28 sipXrls approach 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. ( 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. Polycom also had a proposal, which I will capture here for reference. It allows the BLF button to be used when parking the call, but doesn't deliver single button retrieve. It would require a Polycom firmware enhancement, but on the sipXecs side would require Polycom configuration file changes only.
Marek: "We should be able to use some of the Configurable Soft-key capability to implement this type of UI. The way this could work is that that when a user is active on a call they are presented with a Park soft-key. If they press this they will get a menu to enter the park orbit. Currently this has to be entered by hand (e.g. 1400) but a possible enhancement would be to have the user press the BLF line key to select a particular orbit. When you are in the idle phone start the user would see a Pickup key -pressing this would bring up a dialog [box] asking where to retrieve a call from - enter number (or press BLF key) to Pickup the call. I've attached a draft Tech Bulletin and the SIP 3.1 training slides which describe this type of use case as an example." [Enhanced_Feature_Keys TB42250_d1.pdf & SIP 3_1 Technical Training - Partner_NDAl.pdf] Arjun pointed out that some phones in confirmed dialogs may not obey a REFER with Replaces, as 2008-09-26 08:39 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. Note regarding work item #1 above from 2008-09-26 08:39. Rather than a "fudge" to the NOTIFY when the dialog becomes "confirmed", first try to suppress it instead. An "early" NOTIFY will already have been sent, so simply omitting the "confirmed" NOTIFY should leave the BLFs showing "ringing" for the call. (Hopefully this won't break the un-park sequence.)
Please also add a sipXpark config file entry allowing this behaviour to be toggled on/off. (But on by default.) I can think of one unlikely case where the new behaviour might not be desirable (see below.) If an field issue does happen to come in, it would be very good to have a quick way to turn it off (without having to deploy a patch.) This will work well with LG-Nortel sets, except in the case of a "multiple call" park orbit. The LG-Nortel set is not smart enough to omit the call pickup code when you hit a "ringing" BLF button while performing a transfer. i.e. If you have a call parked in an orbit, and attempt to add another using [Bxfr], then hitting the orbit's BLF key, I think you'll actually un-park the first call and connect it to the caller you were trying to park. Moved to 4.0 because of too many issues with Polycom & LG-Nortel BLF support.
Code is done and tested, however, operation doesn't always work because of incorrect operation on the phone or RLS server. Potential patch. Many issues with BLF still on Polycom phone that seems to affect the reliability of this enhancement.
BLF is improved in the Polycom 3.1.1 firmware, available late next week. (We also have an early release.) The main thing that we're waiting for is the Polycom profile content to be ported from branches/3.10 into main, since Polycoms need to have good profile content in order to be reliable.
Also LG-Nortel 68xx will work with this feature once Still though, sipXrls instability will pose a challenge to the reliability of this feature, as it already does for all BLF functionality. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Add the ability to configure a Polycom phone supporting BLF (e.g. 601) such that a parked call can be retrieved by pushing the button mapped to the park orbit.
