Vernon

I tried it with your pattern without the square brackets but the test call just ended up staying on the IVR node. Would you happen to have a reference of the full expressions allowed in the matching? It would help to have something up to date to reference. This is the basic list i have so far: Syntax Function ! Delimiter (separates each part) [ ] Lists the digits that are accepted { } Defines the number of digits ( ) Stores the numbers that match \2 Indicates which expression to call * Wild card (any length and character) $ Tells the system to read from end of string

Hello, I'm testing the IVR with FROM based call routing but the documentation is relatively sparse on how to actually perform this task. Reading https://doc.vodia.com/docs/ivrnodes gave some ideas on how to perform this, but to get the ball rolling I've had to piece together the pattern from very old information and posts. For example i was able to create a pretty basic pattern match: !^([(205|251)]{3}[0-9]*)!100!f! !^([(480|520|602)]{3}[0-9]*)!101!f! !^([(239|305|321)]{3}[0-9]*)!800!f! !^(907[0-9]*)!102!f! !^([(319|515|563|641)]{3}[0-9]*)!103!f! !^([(270|364)]{3}[0-9]*)!104!f! !^([(339|351|413)]{3}[0-9]*)!105!f!106! Basically what i'm trying to achieve is that when the first 3 digits match an area code, it should be routed to a specific extension/destination. This seems to work in most cases but i've had random issues where some area codes that match would go to a different destination completely. The logs only indicate that a pattern was matched. Would you be able to provide a sample pattern?

Any updates to these? Would be nice to have the versions consistent across all available avenues.

Hello, I was testing the latest release and i believe i found a small issue with call parks that involve multiple registrations. In older version 66/67/early 68 this wasn't noticed or i wasn't able to replicate it. Summary of issue: When two phones share the same extension and both are on a call at the same time, when one of the phones parks their call, it will instead drop one of the calls and then park the other call. Some clients like to have multiple registrations on the same phone so they don't have to remember, worry, or care about hunt groups or multiple extensions. These are the type of clients that absolutely loved shared line features but have been migrated to park orbits. It seems that the latest version has a negative interaction with extensions that have multiple registrations and using the call park feature. There are two main methods of call parking that i tested. 1. *85 | 2. Transfer call into the parking orbit. I've tested both and it produced the same error with minor variation. Whenever a call park is initiated by either of the phones, at least one of the calls will drop, while the other will be parked. It is odd that transferring into a park orbit would have a negative interaction and at first i thought it was maybe a phone compatibility issue. But i tested this on older 3xx Snoms, newer 7xx Snoms, different Yealink models, and all produced the same error. I haven't tested it with soft phones but i doubt that would be the answer on how to resolve this type of bug.

I'm still a little surprised this hasn't been resolved. From the techs i spoke with, they found it easier to downgrade the phone model for ACD managers than expect a fix. It may not have been the most precise troubleshooting provided, but it's easily replicated. All that would need to be done is to just change how the ACD tags incoming calls. Pre v66.0.7 it sent the correct string, for whatever reason, in 66.0.7 it was changed. Old ACD sent this BLF Status for incoming calls: <state>early</state>\r\n - Shows ACD Agents as "Ringing" until X agent picks up and their BLF status changes to "Talking" New ACD send this BLF status for incoming calls: <state>confirmed</state>\r\n - Shows all ACD agents as "Talking" until X agent picks up and after 5-10 second delay only their ext shows as "Talking" It doesn't look like this has addressed since v66.0.7.

Hello, Just to add to this, i decided to test on 68.0.4. I got the same results. The logs look pretty much identical. It populates on the RPS portion but the server name is blank/null. Tested with an older v67. The problem did not exist and created the entries without issue. The biggest difference between these versions is that on v68. the domains are called "Tenants". Is the PBX trying to send the system name when creating the records? It should always be the DNS of the tenant/pbx. The firmware of the phone doesn't really matter because at this level it's the PBX failing the API call to Yealink's RPS and providing it with a null/blank server name. Any phone will fail provisioning in this condition. You might want to address this ASAP since this affects everyone with a Yealink RPS account.

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.

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

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

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

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.

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

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

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.

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.

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.

Not to try and resurrect an old thread but the posted picture of the beta application would be an excellent addition to the app.

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.

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!

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.

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

Hello, I came across this little quirk, the PBX seems to bypass Yealink's DND functionality in order to page it. I've tried using the several custom settings the Yealinks have such as the Emergency DND Bypass but the PBX pushes through no matter what. Since the phones get provisioned and the DND status should sync up with the PBX, it should make sense that the PBX is able to ignore those phones/devices. It would be worthwhile to add the setting under the Extension permissions or as a setting on the paging group that will ignore devices/phones in DND.

Just to add to this. Can confirm the functionality across different platforms. It does not seem to be relevant to the PBX version but more-so the app/web version and i assume the latest PBX versions run the latest web version of the app. I installed the v1.xx app and tested the parking orbit feature and it worked identical as in the pictures above, but the latest release from the MS store deviates from v1.xx with the issues present.

Hello, I was just wondering how the automatic blacklist operates on the latest version. I've had odd results in the testing environment. I have two test extensions i use to configure phones either through provisioning or manually to test features. Every now and then i may get the SIP password wrong and then i spend 20 minutes troubleshooting the phone trying to figure out why it won't provision, only to find out that it's been black listed, likely due to the wrong SIP password entry. The other test phone works fine since the blacklist seems to block individual ports and creates a listing for the extension and domain it was created so it's easy to find. I just want to understand the logic behind the extreme effectiveness of the blacklist. Just to provide an example i'm able to loop a phone into a provisioning cycle where i can force the PBX to regenerate the same config file 10,000 times and there's nothing in place that stops this. Is there a way to increase the amount of failed registrations attempts the PBX can accept before it ultimately blacklists the IP/device? Thank you

Hello, There is a minor bug/oversight with how the call answer feature works on the app. Typically when a call comes in you'll see a notification pop out from windows, and you can see the pending call in your app. However once the notification goes away/times out, so does the ability to answer the call. So you have about 5 seconds to pick up the call. The app still rings the full duration but you just don't have the opportunity to pick up the call. I tested this by hovering over the notification from windows and the call inside the application stayed for as long as the notification was open. The easiest way to circumvent this bug is to disable the Windows notification alerts for the application, only drawback is you won't get a sliding notification of incoming calls. This was tested on the latest app 1.2.6 i think