Jump to content
Vodia PBX forum

Scott1234

Members
  • Content Count

    30
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Scott1234

  • Rank
    Advanced Member

Recent Profile Visitors

831 profile views
  1. I understand what you are saying, but what I am saying is this has changed in operation from previous versions. Which is effecting how my customer agent groups are working. Can you confirm if it's changed ? like i said previously all additional agents would ring when this stage was hit and thats the function I need back.
  2. Sorry I thought my first post was clear, I all ways find it hard to convey stuff here to be as simple as I can the previous versions did the following and had done so for years. Agent group, 'After hearing ringback for (s)' ... include the following additional agents Previously this would ring all additional agents defined in this box at the same time so the call gets answered quickly. But now it's been linked to follow the agent selection settings, meaning it might only be doing 1 agent every 5 seconds or what ever your settings are set to instead of blasting the whole group once the timer had got to that point.
  3. I know I have my other agent group topic; I am going to test that today at some point since going to the latest version, been super busy. Something that has 100% changed with the latest version, but changed somewhere from 57.3.2 was the logic of the setting After hearing ringback for (s) not sure if it was intentional? Example, • Customer may have any number of logged in agents at any one time • Customer has a number of extra agents as part of the, All agents for this ACD including the main agents, these extra agents typically never login. • Customers were using the 'After hearing ringback for (s)' to call the extra agents in, previously this setting would allow for all extra agents defined here to ring at the same time so the call got answered quickly, now it follows the logic set out in the Agent selection settings. I thought the previous logic made sense as if I wanted the 'After hearing ringback for (s)' section to follow the agent selection logic I would have just programmed them in as logged in agents to follow the ring order, now if I want to add in a lot of agents in one go I have to divert off to another agent group that has them all logged in, this makes it more messy as before I could contain it all in one group. Maybe an extra option is needed to control how that works now? or remove it from that logic. Thoughts?
  4. I will give it a test laster and let you know .
  5. I have messed around with the Zoiper stuff for a while and no matter what I do when I provision from a QR code it populates everything correctly except the username field, its all ways inputting "4789" as the 'Account name' and 'user name' in the phone app (iOS). If i update the username manually it connects no worries. I have also deleted the oem Zoiper profile and tried a bunch of stuff there with no success. Any ideas?
  6. Just wanting to know if there is a good list some where of the SSI e-mail tags ? I am wanting to know if it's possible to pull the extensions associated DID or maybe ANI to include in the template ?
  7. Sorry I had forgot about this, I will re do the test and let you know. I still feel its a bug but let me fully re-create it and document 100% to try show my process flow to you better.
  8. Scott1234

    Stripe

    Wow, excited to see this about stripe please keep us posted with info .
  9. What I am saying here is that the service flag is not being checked first when the other triggers are set i.e all agents unregistered even if night service flag is set and active.
  10. Hey ya's, Maybe not a bug as its been around since forever that I can remember but only decided to let you know now It seems that when the setting is defined for either when primary agents are logged out or when all agents are logged out or when all agents are unregistered it takes precedence over the service flag account / night service number , I would think logically that the service flag triggering night mode should take priority over this. For example we use when all agents are unregistered to divert calls to a mobile failover agent group for power/internet outages, however for extended outages that tick over to out of business hours the normal night service flags don't work as they don't have precedence so calls still flow to mobiles. Whats your thoughts on this and do you think it's a logical thing to fix ? I could just have the mobile agent group have the service flags programmed as well with out the agent logged/unregistered setttings but just seems cleaner to contain it all in the primary group. Thanks !
  11. I only have Yealink & Snom phones to test with. As I mentioned in the first post the Yealink works fine on older PBX versions older than 5.5.4 no matter what phone firmware is used. So some thing has changed park orbit wise on the pbx since. if BLF button type is used on the Yealink with DSS Keys set to blind transfer you can park calls, but this is not ideal as attended transfer is preferred method for DSS Key buttons. (Except for when using parks) hence why these buttons are set to Park Type. Maybe I am not explaining well but some thing has changed, I am just trying to under stand what it is and to me it seems PBX as the issue is gone when reverting to older versions.
  12. A customer alerted me to an issue with Yealinks today to do with call parks that was working in the past. I spooled up a vanilla 5.1.0 as I couldn’t exactly remember when it was working so I went to the lowest 5.x i could find and can confrim all is good in 5.1.0. Current Problem 5.5.4~ (not sure when it started, any phone firmware), Reception user is on a call Second call comes in, alert displayed on phone with tone on earpiece User presses park button to park first call, but it parks the second incoming call, but jams the phone and eventually shows a transfer error. You then cant park the original call as the phone is in a diffrent menu layout due to the failed park. In the past (tested on 5.1.0 as ok any phone firmware), Reception user is on a call Second call comes in, alert displayed on phone with tone on earpiece User presses park orbit button, current call placed into park Second call would ring up, parking them as they go to be dealt with if many calls etc. Notes, All test phones auto provisioned Standard PBX supplied configs except, Transfer Mode via Dsskey set @ Attended. T46G handset tested from firmware as low as 28.73.0.50 to current 28.81.0.70 Buttons managed by PBX, refer to further button notes Further Buttons Notes, In the past before ‘Park Orbit’ button type was supported we ran a tweaked config that set a few buttons up as ‘Park Type’ on the Yealink statically as Yealink treats them as blind transfer buttons that way, allowing the other DSSKey’s to be set to use the Attended transfer default. Since 'Park' was supported we have had the PBX manage all button types. The parks have worked since being supported it is only recently that this has started. I have also noticed when testing in 5.1.0 that when you press the Park orbit button with no call going the phone would connect to the orbit and show an active call has been made. In 5.5.4 it just shows that its attempting to connect and never does, I presume this is why the parking has stopped working as the yealink needs it to confirmation connection to hand off the call ? Thoughts? if you need more info let me know.
  13. Hey, I like where you are going in 5.5 user UI just wondering if there is any way for the hosted crew to customised the boot strap so colours can be tweaked and maybe the layout/table design tweaks a bit to match with corporate branding for the lucky people who know how to handle editing that stuff. I can't seem to find any css sheets listed in the root level template edit section that match what is being loaded in the html source?
  14. I thought as much, maybe I should start an holiday aggregation service
×
×
  • Create New...