Jump to content

Vernon

Members
  • Posts

    61
  • Joined

  • Last visited

Recent Profile Visitors

2,538 profile views

Vernon's Achievements

Newbie

Newbie (1/14)

  • Week One Done Rare
  • One Month Later Rare
  • One Year In Rare

Recent Badges

0

Reputation

  1. I think you misunderstand what the issue is. It's not about the call pick up promises or the blinking, it's about the dialogue the PBX sends. I found a reference picture that can help understand what the BLF buttons look like under the new version. Any call that comes in into an ACD triggers all the agents to go "Talking", which is incorrect, they should be ringing, and only the agent that picks up the call is "Talking". I should have included the captured data from an older PBX that showed the call states, but only included for the tested version. In the new version the ACD sends out a <state>confirmed</state>\r\n packet for an incoming call and this causes all the monitored agents to show up as "Talking" compared to the older PBX that sent <state>early</state>\r\n which would tag the BLF key as "Ringing". This is only a problem for phones that are capable of providing extra BLF information, in my tests it's the Yealink T48S+ models.
  2. Hello, As with my earlier posts and doing more testing i think i found something that doesn't look to be influenced by the phone config settings. The issue is when a manager is monitoring multiple agents and a call comes in, all agents go into "Talking" mode even though the caller is in the early call stage and nobody has picked up. It takes a couple of seconds for the status to clear but it becomes hard to gauge who is picking up calls as it doesn't seem to go through the list of agents before the status changes. This shows up on the T48+ type models that track call states via BLF's on top of other functions. Digging into it, it looks like the call states may be mis-attributed when calls go through an agent group. When calling an extension directly the state is labelled as early and shows appropriately on the phone BLF. Data below bolded. Direct Call <?xml version="1.0"?>\r\n <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="186" state="full" entity="sip:100@test.domain.com:5060">\r\n <dialog id="57" call-id="921e247c@pbx" direction="recipient">\r\n <state>early</state>\r\n <local><identity display="TEST MAIN">sip:1234567890@test.domain.com</identity></local>\r\n <remote><identity display="TEST CALLER ">sip:0987456321@test.domain.com</identity><target uri="sip:*87100@test.domain.com"/></remote>\r\n </dialog>\r\n </dialog-info>\r\n When calling the agent group however, the state is confirmed even though the caller hasn't connected to any agent yet. Agent Group <?xml version="1.0"?>\r\n <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="183" state="full" entity="sip:100@test.domain.com:5060">\r\n <dialog id="56" call-id="b6ae8646@pbx" direction="recipient">\r\n <state>confirmed</state>\r\n <local><identity display="TEST MAIN">sip:1234567890@test.domain.com</identity></local>\r\n <remote><identity display="TEST CALLER ">sip:0987456321@test.domain.com</identity></remote>\r\n </dialog>\r\n </dialog-info>\r\n This is on a test v66.0.7
  3. Hi there, final update. Someone on my team helped me out and investigated the release notes for the Yealink phones and looks like starting from 84.0.90 they started supporting extra BLF functionalities for some of the phones. The BLF functions can be customized via the .cfg Spent some time on their forums looking for answers but the secrets were in the release notes instead Hope this helps anyone looking for this type of information
  4. Just to update. Decided to take a look at the wireshark data being sent for the DND status and the pbxsends the following: old version 57 <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="2" state="full" entity="sip:100@test.domain.com"><dialog id="dummy"><state>confirmed</state></dialog></dialog-info> new version 67 <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="80" state="full" entity="sip:100@test.domain.com"><dialog id="dnd"><state>confirmed</state><remote><identity display="Do Not Disturb"></identity></remote></dialog></dialog-info> So looks like the Yealinks may be interpreting the DND with a flashing light whereas the old status was "dummy" so it was solid red
  5. I think that's the current problem because the latest version i'm testing on does not render the BLF of an extension solid red light, it simply blinks. Like you said when the light is blinking it indicates a status where other users may pick-up the call, but you can't pick up a user that's on DND. I decided to test on an older version of the PBX and it does not seem this behaviour is replicated there. I must say that it would be easier for an administrator to manage the function of the BLF server side than to try and re-train clients on new BLF functionalities. To further test this i checked different Yealink models in case it was a one-off to the T43/46 and the T48+ models make it much more annoying because the buttons are displayed on one screen. If users go on DND it becomes very distracting as you can't hide away the buttons on a different page like the 42/43/46 model. Is the "hack" you mentioned, is that something available to the administrators. Might be helpful for those that stumble upon a similar situation.
  6. Hello, I've been testing the BLF options on the Yealink T43/46 on V 67. and i'm wondering if you could provide some insight into the BLF functionality. From what i remember in the previous versions there used to exist different BLF options (monitor, pickup, call) but now everything is under one button type. Here is a scenario issue, a user goes on DND, and you are monitoring them on a BLF, their button seems to start flashing. When they go on a call, their button starts flashing, the go-to BLF scenario function is flash the button in any situation. That seems a little bit regressive in terms of functionality because most standard setups will show the BLF states in different mode. For instance DND in most setups just have the user as on/ no flash, and flashing reserved for functions when you might be able to pick up a call. I wasn't able to find any documentation referencing these functionalities but i saw this blog post, https://blog.vodia.com/node/11. It mentions using :np with the "permission" setting though not sure where it would come up on a BLF. Is there an expanded list of commands you can attach to an extension BLF button? Thank you
  7. Hello, Thanks for your reply. I ended up playing around with it some more after my post and then read up on the new dial plan documentation. I did use the suggested 011* replacement pattern and setup the trunk with E.164 without leading + and it actually did resolve my issue with outbound calling. Testing it again I realized that I did not check for inbound calling. The inbound calls do show up and they do work, but PBX seems to add 011 to every incoming call in the CDR. So instead of seeing 416-xxx-xxxx, i now see 011416-xxx-xxxx. I mean it still works but this would mess with all the records for inbound calls. Two steps forward, but unfortunately one backwards
  8. Hello, I'm trying to test with a trunk that can do "everything" that means local calling and international calling. I've so far been very successful in creating the trunks for local calling but i'm having some difficulties with the international part. I'm testing this on the latest version and i don't remember it functioning this way but maybe I'm wrong in this regard. So i create a generic trunk with no global number replacements and the system uses area code 1 for local calling and DID representation. Dial Plan 1: This is to catch all calls that start with a 1 Pattern#1: 1xxxxxxxxxx Replacement: * This is to catch calls that did not start with a 1 and to add it afterwards Pattern#2: 2xxxxxxxxx|3xxxxxxxxx|4xxxxxxxxx|5xxxxxxxxx|6xxxxxxxxx|7xxxxxxxxx|8xxxxxxxxx|9xxxxxxxxx Replacement: 1* Last pattern is generic 011* with * replacement to remove the 011 This does seem to work but in some environments it doesn't look like the dial plan is adding the replacements patterns and the trunk takes precedence. What this means that if a switch expects to see a 1 in front of the number it will try to find a local route, otherwise everything goes international. When the trunk is setup for NANPA 11 digits, local calling works excellently, but international does not. Checking the logs it looks like the system matches the international prefix correctly but then the trunk takes over and adds a 1 to match the NANPA 11 digit rule i guess. So it starts to look like this: Dialplan "Test1": Match 011##telephone@pbx.system.com to sip:##telephone@127.0.0.1;user=phone on trunk Trunk #1 replacement":"sip:##telephone@127.0.0.1;user=phone", request-uri":"sip:1##telephone@127.0.0.1;user=phone", Basically what i'm trying to accomplish is this. 1 Trunk solution. If users don't enter a 1 in front of their number, add it. If users enter a one in front of their number, leave it be. If users try to call international, remove the 011 AND not add a 1 in front of their number. Right now i'm able to do either one separately but not together.
  9. The T43U has the EXP43 unit, which is used on the T43U, T46U and T48U. I followed the instructions and you are correct, i am able to manually change the model of the phone but the problem is that the next up Yealink model that has button configuration is the T46 which is a little different from the T42. This is the button configuration for a default T43U that's on the PBX right now. This is the button config for a T46. So in order for the T43u to be able to use the EXT button configurations they would always need to be configured as a T46, the provisioning issues might be minor since the yealink config is just one common file but might cause administration issues.
  10. Hello, I've been testing the T43U unit and it does not have the possibility to edit the EXT/DSS key buttons on the button page even though the hardware can support it. I think the PBX may be tagging it as a T42 style unit after provisioning and prematurely removes the ability to edit those extra keys. While i don't actually have an EXP board plugged into the phone. I tested with some Snom phones and in the same scenario the pbx gave me the extra button options after provisioning.
  11. Not to try and resurrect an old thread but the posted picture of the beta application would be an excellent addition to the app.
  12. Hello, Yes I found that portion, but what it does not answer is if the auto-attendant has to be mapped *only* on the PBX or can the users utilize their own MS Teams Auto-Attendant. That's the part I wanted to confirm because looking at the MS Teams interface they do have an "Auto Attendant" page but i assume that since MS Teams does not have internal accounts like the PBX there wouldn't be a way to direct the calls to it.
  13. Hello, I recently watched your video on the Microsoft Teams integration and i just had a quick question about the inbound portion of the video. It's possible to assign the DID's to an extension and that'll ring on the MS Teams/ Desktop application, but my question is how does the PBX handle calls to an auto-attendant on MS Teams? The video and documentation wasn't very specific about these functionalities and i was just curious how far the integration goes. Thank you!
  14. Was testing the transcription on the latest build and it seems to break the transcription. From the logs I get the following error: [8] 13:04:00.086 Voicemail message is too long for transcription: 6s This error message appears even if the Maximum duration for transcription (s) under Notifications is set to a huge number, including leaving it blank. Downgrading to 66.0.4 doesn't produce this error message.
  15. The scenario I was looking at involves a user that works under appointments. For example in a bank (pre-COVID), you get your client to come in with you and you put yourself on DND so as to not be disturbed by calls or announcements. So in this particular case the user expects privacy but say management who has access to a paging group, decides to broadcast a message "Everyone, there's taco's and donuts in the staff room, feel free to take as many as you like". While it's not terribly inconvenient it could be seen as unprofessional in this type of environment. Looking at the Yealink forums it seems that people are trying to do the reverse of my scenario and to let pages through DND. I only thought to mention in case the implementation could be easily achieved, if it's not feasible then should be as is. Thank you for your time
×
×
  • Create New...