Page 1 of 4 123 ... LastLast
Results 1 to 10 of 33

Thread: Park key

  1. #1

    Default Park key

    Hi there,

    I would like it if the park feature on the SNOM handsets = *5%23 was automatically provided as a drop down of the advanced key configuration for the telephone - for Epygi deployed Snoms...

    You already have the Park position keys being auto deployed, so it would be nice to do the initiate park key too...

    *5 and the %23 ( SNOM for # ) I normally have to deploy on a handset by handset basis, it would be great to be able to deploy it from within the Epygi.

    Regards

    Kevin

  2. #2
    Quadro Architect
    Join Date
    Jun 2006
    Location
    Around myself
    Posts
    2,075

    Default

    I am afraid people will confuse that "Call Park" with the Park Orbit button type on Snom..

  3. #3

    Default

    I agree with Kev here. The Park feature is accessed by dialing *5, but can not be accessed by doing a blind transfer to, say *5. On an Aastra phone, when you put a call on hold, the Aastra does not automatically pick up a second line, so we have to teach the customer to press line 2 instead of hold if they are on a call, then *5 then <dial> (or wait 4 seconds). If we could blind transfer to *5 as a way of initiating park, we could use the Aastra speeddial/xfer key to initiate a one button park operation. We would then just set up a couple of park position BLF keys and a park key.

    What would also be nice is the ability to assign, through the advanced page in the IP extensions, more of the keys on the Snom and Aastra phones with user fields for parameter and label (in the case of the Aastra phones with LCD labels).

    Regards

    Mark Dutton

  4. #4
    Quadro Architect
    Join Date
    Jun 2006
    Location
    Around myself
    Posts
    2,075

    Default

    Well, guys, you are telling different things actually...
    I have some questions to you as real-world integrators:

    1. Don't you think that having a special button for "*5" (park), and different buttons for pickup will confuse users? Do you feel they are ok with such approach?

    2. The same way, will the method of transfwrring to *5 be more user friendly than having a separate button for *5.

    3. Do you think that having one special key per parking extension, used both for parking (if the park slot is free), and pickupping (if the park slot is used) the call, will be user more/less user friendly or convenient than the methods above?

    Best regards,
    David

  5. #5

    Default

    Quote Originally Posted by davrays View Post
    3. Do you think that having one special key per parking extension, used both for parking (if the park slot is free), and pickupping (if the park slot is used) the call, will be user more/less user friendly or convenient than the methods above?

    Best regards,
    David
    I would go for this option as more user friendly, this reduce the number of key press. That's what our people are used to.

  6. #6

    Default

    Hi there David, to be honest I believe that the call park feature to place and pickup a parked call will fall flat when you have the need to creat multiple keys across the telephone system.

    If you had to monitor the keys and also extensions then the 80 BLF limit will crash the call manager when you have multi lines ISDN/PSTN/VoIP you might find you will need to have 3 - 6 park keys programmed on the system.... if it is 4 handsets then on any of the Epygi range if you were to use the Park facility in lets say to cover for 4 concurrent Park locations - would mean a maximim of 20 handset extension deployment, if you added Receptionist duties would decrease the amount of Park keys to be able to be deployed which would mean you might end up running out of Park positions.

    If you didnt have to worry about blf on the Park position then it isnt a worry period but you would need to remember the position is allocated.

    Kev

  7. #7
    Quadro Architect
    Join Date
    Jun 2006
    Location
    Around myself
    Posts
    2,075

    Default

    Well, I see your point Kevin.. So in fact even now you don't use the BLF of park extensions in your installations, not to hit the 80 BLF limit.. Just using the *5 to park and listen to the message informing about the park extension number?

  8. #8

    Default

    David, I think option 3 is best if you can do this. This is how a traditional key system would work. However, if this can't be done, a single park key, which simply parks the call would suffice as a second best option. It is just to reduce the keystrokes on the phone.

    I was trying to get to a point where I could get an Aastra to do the job within its current capability set. As the Aastrs can do a blind transfer from a single key, I thought transferring to *5 would be easy.

    Knowing that you use BLF logic for park monitoring now (more ubiquitous than park orbit), if you could simply make a call to a park position that is currently free to park the call, this would make the park/unpark function work off the current call. However, the logic in an Aastra phone when a user presses a BLF key whilst still conversation (I.E. They press relevant park button) the action is to simply send the BLF key digits as a DTMF string to the remote party. Doh!

    Regards

    Mark

  9. #9

    Default

    Is the 80 BLF key limit, the total number of monitored keys across all extensions?

    Regards

    Mark Dutton

  10. #10

    Default

    Quote Originally Posted by davrays View Post
    Well, I see your point Kevin.. So in fact even now you don't use the BLF of park extensions in your installations, not to hit the 80 BLF limit.. Just using the *5 to park and listen to the message informing about the park extension number?
    David if you could increase the CPU's and memory utilisation / optimisation so that the BLF limit of 80 is surpassed then having a PARK key retrieve notification would be an ideal.

    Now one of the things that Arias, Siemens, Samsung systems do well is to allow you to segregate department functions and in the case of Park keys ... allows you to be able to define Park positions for groups of people.

    What this means in a nutshel if we take the following 2 digit extensions ..

    Extensions 15 to 24 could use Park 1 through to 3
    Extensions 25 to 34 could use Park 4 through to 6
    Extensions 35 to 44 could use Park 7 through to 8

    The Park BLF feature would described above would reduce the amount of BLF notifications on the Network and reduce the possibility of crashing the call manager.

    Regards

    Kev

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. How to choose a specific extention to park a call on
    By woods in forum 'How Do I' Questions
    Replies: 6
    Last Post: 05-12-2014, 08:53 PM
  2. Call Park
    By andy.collins in forum General Discussions
    Replies: 7
    Last Post: 02-12-2008, 02:51 AM
  3. Direct call park
    By ssteiner in forum 'How Do I' Questions
    Replies: 14
    Last Post: 11-05-2007, 06:36 AM
  4. Call Park from IP Phone
    By threebit in forum 'How Do I' Questions
    Replies: 2
    Last Post: 07-05-2006, 01:52 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •