Jump to content

Lyndon

Members
  • Posts

    51
  • Joined

  • Last visited

Posts posted by Lyndon

  1. 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?

  2. 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?

  3. 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?

  4. 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.

  5. 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?

  6. On 2/17/2021 at 3:16 PM, rtl said:

    Bear in mind though that although all mobile numbers in the UK start with 07 not all 07 numbers are mobile numbers. Those starting 070 are personal numbers so you really need to block them. I have a comprehensive UK dial plan covering emergency numbers, barring premium rate etc we use for all out customers if you want to get in touch

    Good catch, I hadn't thought about personal numbers. I've DMed you re your default dial plan, thanks!

    On 2/16/2021 at 11:25 AM, Vodia PBX said:

    (07*) means in ERE "0" and then 0, 1, 2 or more "7" characters. I guess you wanted to use ^(07[0-9]*) instead? You should actually use the ^ at the beginning to require that the string starts with 07 and not just random match somewhere in the middle (It becomes clear why we need the simple patterns). 

    The simple match magic is that is just tries to make sense of the pattern as a simple pattern, and if that fails it uses the ERE logic. 

    IMHO this should be a simple case where all you need to do is use the simple 07* and then on the trunk make sure you present the number as "rest of world".

    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?

  7. 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?

  8. 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?

  9. 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

  10. 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?

  11. 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:

    1. 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.
    2. Factory reset handsets.
    3. Login as admin/admin.
    4. Enter http://vodia_public_pbx_ip to provisioning URL
    5. Click "Confirm" then "Auto Provision Now"
    6. Handsets download and then reboot.
    7. 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)

  12. 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

  13. 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!

  14. 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.

  15. 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

  16. 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

  17. Hi everyone, hopefully someone can help me make head or tail of what's going on.... and before anyone says, I've already been through https://doc.vodia.com/domain_dialplans and I find it very lacking and inaccurate.

    So I have a dial plan with pattern *, with the replacement field empty - this works fine. I dial 07299999999 and the call routes to the telco as 07299999999 and the call is successful. However I don't want a wildcard pattern.

    So I try changing the pattern to 07* - to allow calls to numbers beginning 07. I leave the replacement field empty - which according to  https://doc.vodia.com/domain_dialplans  "If the replacement field is empty, then the dialed number is not touched as it is sent to the set trunk."

    However, the call gets passed to telco as 0099999999 - so much for not touching the number...??? And obviously the call fails. For some reason, the PBX is prepending 00 and stripping 072 (or prepending 0 and stripping 72). Why?

    I've tried adding * to the replacement field, dial 07299999999, same output = 0099999999.

    I've tried adding \1 to the replacement field, dial 07299999999, 00 is the output.

    I've tried changing pattern to (07)* leaving replacement empty, dial 07299999999, output = 007

    What on earth is going on?

     

     

×
×
  • Create New...