Jump to content

Lyndon

Members
  • Posts

    27
  • Joined

  • Last visited

Everything posted by Lyndon

  1. I have a new pbx running 67.0.1, but still had to change yealink_common.txt - where do I find the 'Yealink general parameter' you mentioned above coming in v67.0?
  2. Excellent, or so I thought... I have HTTP set to 80, HTTPS set to 443 Redirect to HTTPS was set to 'Automatic' - so would assume that means enabled, opposed to disabled. Changed to 'On' so there is no guessing, saved settings. Browsed to http:// and don't get redirected? Does this change require a server restart and what does 'Automatic' mean in this sense?
  3. Using a generic SMTP server, not Gmail or 365. One provided by a hosting company using cpanel...?
  4. I think that maybe it. If I display for QR code via http:// it doesn't work. If I display QR code via https:// it works. For overall security, wouldn't it be a good idea to redirect all http to https, or at least have a setting that does this that you can either enable or disable?
  5. Just tested and you're right. Log in as Admin, open an extension then click "Click here to switch into user-mode", then click buttons from the drop down user menu, and a screen similar to the one above appears, however login as the user and the button option doesn't work. It only seems to allow you to select a button template though, rather than allow the users to set buttons individually/independantly - is that by design?
  6. I let some time pass then tried to scan a QR code from a different PBX and extension which worked. I then logged out and scanned the QR code for the original extension I was trying to scan earlier and it worked....?
  7. Tried to scan a QR code but it doesn't work. I'm just taken back to the previous screen that displays the URL field, "Connect" and "Scan QR" buttons. It used to work...? Tried closing and re-opening the app, no difference. Tried clearing app data, no difference. Tried restarting the mobile, no difference. Tried QR code in user portal and admin console, no difference. Scanned the QR code with lens which displays URL, user and pass parameters - all seem correct, obviously can't confirm the password as it's hashed.
  8. I select 'Buttons' from the menu and litterally nothing happens, the screen does not change - it's as though I'm not clicking the button.
  9. I've logged into the user portal, clicked the users extension menu and select 'Buttons' but nothing happens? Tested on 66.0.6 and a pages loads where you can choose what buttons you want. Is v77.0.1 a beta version?
  10. I've provisioned two yealink handset's on Vodia v67.0.1, the handsets pull their general config but don't apply the web password set under Settings > General > Provisioning Parameters - the Yealinks are keeping their default admin/admin credentials. If I provision one of the same two handsets to another PBX running v66.0.6, the password set under Settings > General > Provisioning Parameters - is applied. Have I misconfigured or configured something differently between the two systems (although I can't see what as if I'm entering a password, that's what should get applied?) or has a bug been introduced into v67.0.1?
  11. Good catch, I hadn't thought about personal numbers. I've DMed you re your default dial plan, thanks! I did try 07* originally, but when I did that, keeping the replace field blank, 07299999999 was being sent as 99999999? Is that because of "rest of world" you mentioned?
  12. Disabling cert checking didn't fix it so TLS remains disabled at present. I didn't notice TLS had its own logging level - will try that out. There's currently only one domain on the system, but I tried different email settings and servers, I cleared out the /emails directory (or the .XML files at least), and renamed index/0.bin to o.bin.bak if I recall correctly to clear things out. I'm impatient you see, and there weren't any options in the webUI to flush the queue, hence my original question. Might be good to add a force retry too?
  13. I think the problem was possibly due to entering the MAC address on an extension, but then pressing 'Save', instead of clicking the plus (+) button, which then asks you for the make and model? I haven't tested this to confirm, but following a conversation with a colleague am wondering if that's what might of happened and why the handsets weren't provisioned correctly until I'd assigned them in LAN devices. If so, I think some error handling could be built in to prevent 'Save' from being pressed if a MAC address is entered without clicking the + button?
  14. I have the same query... I'm in the UK, have selected UK language and UK audio files etc in Vodia, yet the time displayed on my Yealink handsets is MM/DD/YY, but for the UK it should be DD/MM/YY. If I look at yealink_common.txt it reads: #Configure the date format; 0-WWW MMM DD (default), 1-DD-MMM-YY, 2-YYYY-MM-DD, 3-DD/MM/YYYY, 4-MM/DD/YY, 5-DD MMM YYYY, 6-WWW DD MMM; local_time.date_format = {enum extension lang_web 1 en=4 uk=4} Based on how I read this, it's saying to use date format 1 (DD-MMM-YY) unless [enum extension lang_web] variable is set to en or uk, in which case use date format 4 (MM/DD/Y). However date format number 4 is not the correct format for the UK, the correct date format for the UK is 3 (DD/MM/YYYY). If I correct this template changing "en=4 uk=4" to "en=3 uk=3", I assume this will resolve the issue, but I also assume that this will only break in the future when an update is performed, as yealink_common.txt will get overwritten? Is this something Vodia needs to fix in their templates so future updates are correct and don't break this change if I make it now? Thanks
  15. So fixed it, but don't understand why I had to do this, so an explanation would be great. Under System Level, I went to Phones > LAN Devices and there I saw the two devices that were struggling to provision. I clicked the Setup button corresponding to each extension, changed the domain from localhost to the correct domain, and selected the appropriate extension then clicked Save. The handsets then provisioned. When I go to Domain > Extensions, I saw the two extensions listed with duplicate MAC addresses. I have therefore removed one of the duplicates. My question is, why did I have to do this for two handsets, and not all, and why is this step even neccesary when the MAC addresses are already listed against an extensionin a domain?
  16. For anyone else trying to do the same, I found this setting which enforces this: At System Level, go to: Phones > Settings > Apps > Extensions to show Options are: All / Same Department / Same Building
  17. Hi! Wonder if you can help, just about to move over to Vodia. Tested with Yealink T48S and everything working. Provisioned Yealink T23G fine also. Trying to provision Yealink T41P and T46S and having issues. This is what I'm doing: Select extensions in Vodia, enable "Open accounts for MAC based provisioning". (MAC address, make & model have already been assigned to the extensions), 30 minute countdown starts. Factory reset handsets. Login as admin/admin. Enter http://vodia_public_pbx_ip to provisioning URL Click "Confirm" then "Auto Provision Now" Handsets download and then reboot. After reboot, can still log into handset with admin/admin (not password set on Vodia), under account details, username = MAC address, not extension. Other extension details remain blank. Server host is just "pbx" rather than "vodia_public_pbx_ip". Provisioning URL has changed to http://vodia_public_pbx_ip/yealink-MACADDRESS.cfg. No link icon displayed next to extensions in Vodia. Time on handsets is incorrect but handset think they are registered (to their MAC address account). Vodia = v66.0.6 Yealink T48S = v66.82.0.20 (working) Yealink T23G = v44.84.0.125 (working) Yealink T46S = v66.85.0.5 (not working) Yealink T41P = v36.81.0.61 (not working)
  18. I'm trying to limit which extensions are displayed in the app, and have read in the v66 release notes that the department field was added for this purpose - to limit the number of the extensions to the same department. So I've added two extensions to the same department, but on the app for one of those extensions, extentions not belonging to that department are still displayed. Am I don't something wrong? Thanks
  19. Hi Vodia I've had a few issues setting the email settings, got it working now although it doesn't work when TLS is enabled? Anyway... What files/directories manage the email settings/queues? The reason I ask is now that emails are working, if I go to Settings > Messaging > Email Setup, at the bottom under 'Currently Used Servers', is a mail server host that is no longer configured in the email settings. State is idle, and Pending is 0. What's causing that to appear, and how do I get rid/tidy that up? The only folder I've manged to find relating to emails/queues is usr/local/pbx/emails, but no mention there of this 'currently used server'? I've seen mentions of a spool directory in old posts (like many years old), so I'm wonding if this spool directory is now no longer in the working directory perhaps? Thanks!
  20. Hi, and thanks for the reply. FYI I found out that our telco was appending the 00 their end, and do so if a number is passed to them that doesn't begin with a zero - their assumption here is that without the leading zero, it must be an international call, so they prefix 00 which is the international dial code for the UK. I'll therefore ignore the 00 displayed at the telco's end when troubleshooting this issue. This however still doesn't explain why the number being passed to the telco seems to get stripped when I wouldn't expect it to... I set logging to 9 for trunks, with a pattern of (07*) and replacement of \1 (and also tried \1*), and when dialing 07299999999, no number is passed to the telco (the whole number is stripped?), and the following is logged: [9] 17:43:00.374 TRUN: Dialplan: Evaluating !(07*)!\1*!i against 07299999999@localhost I'm wondering if the !i is having any bearing on what's actually being passed to the telco, and maybe the cause of the stripping? Is this possible? With a pattern of 07* and replacement empty, 072 is stripped, and only 99999999 is passed to the telco, and log shows: [9] 17:49:00.541 TRUN: Dialplan: Simple match begin of 07299999999 to 07* [9] 17:49:00.541 TRUN: Last message repeated 2 times [9] 17:49:00.541 TRUN: Dialplan: Evaluating 07* against 07299999999@localhost I'm guessing that the lack of brackets in the pattern signifies to Vodia that this is supposed to be a simple match? I'm also wondering if the first three digits (072) are being stripped due to the simple pattern being three digits long? Is this the case, but if so why? I've just changed the pattern to 072*, and found that indeed 4 digits are now stripped from the beginning of the number instead of just 3...? To clarify, when you say "The 'simplified' rules used to be sugar coating for the ERE until we gave up on that and made the simplified rules a separate feature in the dial plan" - does this mean simplified rules don't actually work? And where is this 'separate feature' found in the dial plan?, assuming I've not completely misunderstood you? Thanks for you help and clarifications on these dial plans.
  21. I did see that and I didn't think it would help due to thinking the Telco doesn't respond with an error code - but I've just realised that I might be getting mixed up with something else. I will test on Monday to be sure, fingers crossed they do respond with an error code and the failover will work.
  22. Hi, thanks for the reply. Sadly that wouldn't do it. We don't want to restrict the number of calls - we want the the opposite in fact. Calls are restricted by the main truck provider, but I don't think they issue an error code when the trunk limit is reached, so as not too restrict the number of calls, the PBX would need to know what the maximum is for a particular trunk, so when that limit is reached, it would continue down the dial plan until another trunk with availability is found - does that make sense? Thanks
  23. I've just added the (07[0-9]{9})@.* as the pattern, and sip:\1@\r;user=phone as the replacement, and this works. (07[0-9]*)@.* as the pattern also works. But could somebody explain why the "Simplified Pattern Matching" doesn't work as I would expect, and why the number is replaced even when the replacement field is empty? I see no reason why the more complex "Extended Pattern Matching" needs to be used to achieve something very simple? Thanks
×
×
  • Create New...