Jump to content

stoneracer

Members
  • Posts

    27
  • Joined

  • Last visited

Posts posted by stoneracer

  1. Our snom phones within the office are connected to the pbx using sip over tls for security reasons. Some of our users also have a second phone within their home office (using a VPN) where the connection has to pass a firewall between home office and the pbx. SIP signaling works without any problems, but RTP could not pass the firewall as the SIP ALG was unable to inspect the SIP traffic to open the necessary ports. As the connections is already secured by VPN it should be ok to revert back to udp (or tcp) in this cases to make RDP work properly without opening a huge port range in both directions.

    To solve this I just have to modify the phone template for phones within the home office and to replace

    <user_outbound idx="{lc}" perm="RW">{outbound-ip}:{outbound-port tls};transport=tls</user_outbound>

    based on the IP address with

    <user_outbound idx="{lc}" perm="RW">{outbound-ip}:{outbound-port udp};transport=udp</user_outbound>

    Based on the Provisioning Tags documentation it should be possible to compare the IP of the phone with if_gt but I miss a if_lt (if lower than) or ifn_gt (if not greater than) and an else construct, could someone explain how to achieve this:

    {if_gt ip "192.168.0.0"}
      {if_lt ip "192.168.255.255"}
        <user_outbound idx="{lc}" perm="RW">{outbound-ip}:{outbound-port udp};transport=udp</user_outbound>
      {el_lt}
        <user_outbound idx="{lc}" perm="RW">{outbound-ip}:{outbound-port tls};transport=tls</user_outbound>
      {fi_lt}
    {el_gt}
      <user_outbound idx="{lc}" perm="RW">{outbound-ip}:{outbound-port tls};transport=tls</user_outbound>
    {fi_gt}

     

  2. Hello,

    I would like to give some feedback regarding quality assurance: it doesn't matter which release we use, each version contains a lot of bugs and if we move to a newer version as we get rid of some bugs, we're aware that we'll get new ones. Some examples:

    In version 62.1 we had much problems with older snom 370 as the BLF did no longer work properly, so we had to update to 63.0.6. Using this version fixed the previous problem but auto provisioning of the snom D385 did no longer work. The next update to 64.0.3 fixed the problem with the D385 auto provisioning but now the phone LEDs for buttons configured with "agent login/logout" do no longer show the login status of the agent group (led is always off). I just tried to update to the new 64.0.4 but this does not fix the agent group led problem.

    Despite from the above mentioned bugs there are a lot of other problems especially with the user GUI (e.g. configuring phone buttons where some of them are assigned from a template simply destroys the preconfigured buttons as template assigned buttons were shown in the user GUI as "not assigned").

    It would be great if you could create a LTS stable release which does not get any new features or changes, just bug fixes until everything works properly and will be supported for some years. We do not need one new feature after the next one, we just need a stable PBX with no known bugs. We also do not want to report one bug after the next one, just to get new problems after the old one has been fixed.

  3. Hello,

    while testing with the snom D385 we noticed that the four display buttons were not configured properly. Within the PBX it's possible to define the "Function Keys" at "Phones -> Parameter -> snom" with individual key events but they are (at least) are not part of the provisioning of the D385.

    To fix this I've included the following to my snom_buttons.xml template:
     

    {if model == "385"}
      <gui_fkey1 perm="RW">{parameter snom-700-f1}</gui_fkey1>
      <gui_fkey2 perm="RW">{parameter snom-700-f2}</gui_fkey2>
      <gui_fkey3 perm="RW">{parameter snom-700-f3}</gui_fkey3>
      <gui_fkey4 perm="RW">{parameter snom-700-f4}</gui_fkey4>
    {fi}
    
    

    Could you please fix this so that we don't have to change the template files manually?

    btw. if you accidentally add a trailing space to the key function like "keyevent F_DIRECTORY_SEARCH " the display button stays empty. Maybe it would be a good advice to automatically remove trailing (and leading) white spaces from the function key value.

  4. We're currently testing the new Snom D385 phone with LCD button labels. When assigning the phone buttons we noticed that the "private line" feature of the phone does not work as expected: If you assign a private line to a button using the phone web interface itself and you do not provide a custom label the button is automatically labeled with "Private line", as soon as you're using this line the label in the button display changed to the remote party number (or name) so that you can see which call is on each line (really cool feature due to the LCD labels).
    If you configure the private line through the Vodia provisioning we can either assign a custom label for the private line, which is always displayed or the PBX automatically assigns the label "extension number: last name, first name" but it's impossible to configure an unlabeled button so that the phone will label it with the current remote party.
    Could you please provide the possibility to provision "private line" buttons without any label so the button LCD can show the current remote party?

     

  5. 11 hours ago, Vodia PBX said:

    Hmm that one was issued by "Shared Business CA 4, T-Systems International GmbH" that does not sound like something which is included in the PBX by default.

    the ""Shared Business CA 4" cert is included - see https://forum.vodia.com/topic/15587-deutsche-telekom-deutschlandlan-sip-trunk/?tab=comments#comment-44974

    Quote

    They don't send the intermediate with the certificate?! That would be clearly a misconfiguration on their server side. The intermediate is signed by "Deutsche Telekom Root CA 2" which should be in your certificate list.  

    Well did you evaluate this? As written in my initial post the DeutschlandLAN SIP-Trunk worked with V61, the errors just occurred since we  updated to V62 (if we downgrade to V61 it works again!). As the certs are included in the PBX and the trunk was setup with the assistant it looks to me like a bug in the Vodia PBX and not an error from Deutsche Telekom.

  6. 1 hour ago, Vodia PBX said:

    If you go with a browser to https://n-ipr-a02.sip-trunk.telekom.de what certificate do you see? Is the Root CA as expected? And is it in the PBX? Unfortunately it seems that we cannot try from here because DT does not allow request from non-DT networks.

    the server dos not respond to https (port 443) requests, you have to connect on SIP/TLS port 5061 to get the cert like this:

    openssl s_client -connect n-ipr-a02.sip-trunk.telekom.de:5061

    I got the following cert:

    -----BEGIN CERTIFICATE-----
    MIIGeTCCBWGgAwIBAgIIXVh5CMjBeKEwDQYJKoZIhvcNAQELBQAwgdYxCzAJBgNV
    BAYTAkRFMSUwIwYDVQQKExxULVN5c3RlbXMgSW50ZXJuYXRpb25hbCBHbWJIMR8w
    HQYDVQQLExZULVN5c3RlbXMgVHJ1c3QgQ2VudGVyMRwwGgYDVQQIExNOb3Jkcmhl
    aW4gV2VzdGZhbGVuMQ4wDAYDVQQREwU1NzI1MDEQMA4GA1UEBxMHTmV0cGhlbjEg
    MB4GA1UECRMXVW50ZXJlIEluZHVzdHJpZXN0ci4gMjAxHTAbBgNVBAMTFFNoYXJl
    ZCBCdXNpbmVzcyBDQSA0MB4XDTE2MDUwMjE1MDMwNFoXDTE5MDUwMjIzNTk1OVow
    gb4xCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR0w
    GwYDVQQLExRTSVAtVHJ1bmsudGVsZWtvbS5kZTESMBAGA1UECxMJU0lQLVRydW5r
    MR0wGwYDVQQDExRzaXAtdHJ1bmsudGVsZWtvbS5kZTENMAsGA1UECBMEQm9ubjEM
    MAoGA1UEBxMDTlJXMSIwIAYJKoZIhvcNAQkBFhN6ZXJ0LXRhc0B0ZWxla29tLmRl
    MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskswF3s0XmU+UKvSjVyP
    OgtZSN7LnsALZOajb6fxlv0fBtuKoMC3W41wfGLeLowMh89bqZyRqDg8WuKLfwFb
    NVZIC5OCeqErK0LKrYbMD7uEbVAwo2PmDKTmWp4CkKBjh53I2Ii2J5+BF/1SnTlK
    bDiK4fuOw3kl7BzPh7FXJmxHCFq2n0Xgre2qhZJxGpIbOaeEPvw1jSFF3gXSSB7U
    XNdsONE/M4iuBQ2QPO6UhWBadcC5ZL3ahL4PiJqar8FHBZOcRPTBbANB8qVoOqDF
    WokE6cjP+ltnzYUN3MVQshpc8SVAsQKDIt0H021mYgdCWXB7XgUALXESlYyfVXvR
    3QIDAQABo4ICXzCCAlswHwYDVR0jBBgwFoAUq/9v0RJvV8rS2NjBvvYTNCJ0gTMw
    HQYDVR0OBBYEFATgLk9ICJnLBMbqT3wt946/QGpgMA4GA1UdDwEB/wQEAwIFoDAd
    BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwEwVwYDVR0gBFAwTjBCBgkrBgEE
    Ab1HDRkwNTAzBggrBgEFBQcCARYnaHR0cDovL3NiY2EudGVsZXNlYy5kZS9kb3du
    bG9hZC9jcHMucGRmMAgGBmeBDAECAjAJBgNVHRMEAjAAMIHuBgNVHR8EgeYwgeMw
    PKA6oDiGNmh0dHA6Ly9jcmwuc2JjYS50ZWxlc2VjLmRlL3JsL1NoYXJlZF9CdXNp
    bmVzc19DQV80LmNybDCBoqCBn6CBnIaBmWxkYXA6Ly9sZGFwLnNiY2EudGVsZXNl
    Yy5kZS9DTj1TaGFyZWQlMjBCdXNpbmVzcyUyMENBJTIwNCxPVT1ULVN5c3RlbXMl
    MjBUcnVzdCUyMENlbnRlcixPPVQtU3lzdGVtcyUyMEludGVybmF0aW9uYWwlMjBH
    bWJILEM9REU/Q2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdDA/BggrBgEFBQcBAQQz
    MDEwLwYIKwYBBQUHMAGGI2h0dHA6Ly9vY3NwMDMuc2JjYS50ZWxlc2VjLmRlL29j
    c3ByMFQGA1UdEQRNMEuCFHNpcC10cnVuay50ZWxla29tLmRlghhyZWcuc2lwLXRy
    dW5rLnRlbGVrb20uZGWCGXN0YXQuc2lwLXRydW5rLnRlbGVrb20uZGUwDQYJKoZI
    hvcNAQELBQADggEBABNamC8D8wE28HGzYdb5vYkqts6P37w/FUx5p8Vl9tlhF6Oe
    DC07dzDg/l7v3138XelZcIEoabrioCG06TILsHVg+OeD2LXKY+vzh3i0N1nksLAM
    puItG8fHLxRwkIIJyZ1Fk/x3Djiv5yTDyibtKpH8ea7PhwTCIbcD3aytANYCneg/
    k6/KXvj0dsrmyZBmNCINni57Xzh2813mMqROIwn6Y/w4Gs+p1GwiHvvRWt16H2Ck
    zDlQYNgsK0lckrw8DoMS1SJfui8+V+isbmYTT4St8GkUBUy+INop3y/I1Bz3EGNR
    SoO97K5Z/u2HdSppQza5Ju6bUlORG5dZBdZHOp0=
    -----END CERTIFICATE-----

     

  7. After upgrading from V61 to V62 our DeutschlandLAN SIP-Trunk from Deutsche Telekom does not work any more, the logfile says the the certificate can not be verified:

    /usr/local/pbx/log_2019-01-09.txt:[5] 20190109173733: Certificate for n-ipr-a02.sip-trunk.telekom.de could not be verified
    /usr/local/pbx/log_2019-01-09.txt:[5] 20190109174313: Certificate for n-ipr-a02.sip-trunk.telekom.de could not be verified
    /usr/local/pbx/log_2019-01-09.txt:[5] 20190109174445: Certificate for n-ipr-a01.sip-trunk.telekom.de could not be verified
    /usr/local/pbx/log_2019-01-09.txt:[5] 20190109180146: Certificate for n-ipr-a02.sip-trunk.telekom.de could not be verified
    /usr/local/pbx/log_2019-01-09.txt:[5] 20190109180157: Certificate for n-ipr-a02.sip-trunk.telekom.de could not be verified
    /usr/local/pbx/log_2019-01-09.txt:[5] 20190109180231: Certificate for n-ipr-a02.sip-trunk.telekom.de could not be verified
    /usr/local/pbx/log_2019-01-09.txt:[5] 20190109180311: Certificate for n-ipr-a01.sip-trunk.telekom.de could not be verified
    /usr/local/pbx/log_2019-01-09.txt:[5] 20190109180354: Certificate for n-ipr-a02.sip-trunk.telekom.de could not be verified

    We've already verified that the certs for " Deutsche Telekom Root CA 2" and " Shared Business CA 4" are still present.

    If we disable TLS by changeing the proxy address in the trunk setup from "sip:reg.sip-trunk.telekom.de" to "sip:reg.sip-trunk.telekom.de;transport=tcp" the trunk works again, but disabling the encryption layer is not an option for us.

  8. And probably another setting saying "when that flag is inactive, this flag is also inactive". Or we may as well add an expression that supports boolean logic, something like this: "(582 || !583) && 589"; this can probably be put into the service flag settings of the accounts.

     

    As this request is more than one year old I would also like to vote for it. Our most important demand is a negating service flag which says "when that flag is active, this flag should be inactive" and the other way around. The boolean logic would be the best solution as it's most flexible and allows any combination of service flags. This would allow us for example to enable the extension cell phones in the out of office hours when the attended is put into night mode.

  9. Hello,

     

    in our setup we've several extensions which are part of more than one hunt group. Since one of the hunt groups is an emergency group we thought how to ring the cell phones of specified extensions when the call is not answered after xx seconds. I've tried to put the cell phone in the second stage by entering *00<extension> but this does not work. The option "When calling the extension in a hunt group" of an extension does also not meet this requirement since it covers all hunt groups and not only specific ones.

     

    So I would request the feature to allow the star code *00<extension> as a member of a hunt group.

     

    btw. I would also be great if *00<extension> could be used as a destination in the night service fields.

  10. Yes, it is intended behavior. The "time boundaries" are used to say when to call the cell phone.

     

    ok, this make sense to me, so I created a new service flag which negates the times of the night mode flag. Negating the daily times is easy, but how do negate the holidays? Example:

    Our night mode service flag (which controls the voice mail) got the daily time frame from 08:00-18:00 with holidays on 12/24 12/25 12/26. So this switch is always on from 18:01 to 07:59 and in the holidays the whole day.

     

    To create a service flag for my cell phone which says this should be active only in the outside office hours I used the daily time frame from 18:01-23:59 and 00:00-07:59. This works well, the switch is always clear while the pbx is in night mode, but how do I enter the holidays? If I enter the same dates as above the cell phone won't work on 12/24 12/25 12/26 the whole day.

     

    Any ideas?

     

    btw I would vote for a new negating service flag which says "this flag is set if flag(s) number xxx and xxx are set".

  11. Hello,

     

    we have a service flag which is active during our non office hours (so it's clear during the office hours). The servie flag is used to control the night mode of the hunt groups for automatic redirection to the voice mail system. This works very well but if I use the same service flag for my cell phone times (Specify time when system calls the cell phone) it simply works the other way around. During the office hours my cell phone is getting called, if the service flag is set in the night no calls go to my cell phone. Is this the intended behavior so that I've to setup a second service flag which negates the first one or is this a bug?

     

    btw we're using "v2011-4.5.0.1030 Beta Corona Austrinids (Debian32)"

  12. We had a setting on the web interface to explicitly control whether that user prefers the PVA. For some reasons, we removed it. But luckily, we removed it only from the web interface, not on the server side. Here is what you can do to get that setting back to the web interface.

     

    Now you can control if the PVA is offered to that user or not.

     

    many thanks, this solved my problem. Will this option reintegrated in future versions or do I have to expect to lose this again?

  13. As far as I understand I'm getting into trouble with this merged option. We've a special extension for emergency calls in the out of office hours which cell phone number is filled by the persons cell phone who is on duty. Since the call should not be connected directly we prefer the "press 1" option. With this new "dual" option the activation of "press 1" also activates the personal assistant for this extension. As the same cell phone number is also used in the extension of the same person I'm not sure which PVA is invoked when the cell phone calls the auto attendant. Since the dial through function of the PVA is protected by the personal pin code a user will get into trouble is the PVA of the emergency extension will answer the call.

     

    Any hints how to solve this problem?

  14. Check the domain settings, there is a field called "Offer Camp On" which will enable a user to callback when a user is busy. Should be turned on by default.

     

    Well "Offer Camp On" is enabled in my setup, I've also tried to disable this feature and after that enable it again, but the result was the same as before. Any ideas how to fix this issue?

     

    btw our setup has several auto attendends, can I choose which one is called from the personal virtual assistent?

  15. Hello,

     

    maybe I'm just to stupid, but I can't find the answer on my own :-(

    I've enabled the personal virtual assistant for one extension and entered the cell phone number. After calling the extension -0 from my cell phone I reached by personal virtual assistant which offers me the following two options:

     

    1: make an outgoing call

    2: go to the auto attended

     

    Since I've disabled by mailbox this feature is not offered, but how do I enable the feature to receive a callback?

    I already thought this might only be available with an active mailbox, but after I enabled the mailbox I just got 3 options:

     

    1: make an ouztgoing call

    2: go to mailbox

    3: go to the auto attended

     

    Could someone please explain how to enable the callback feature?

     

    Version: pbxctrl-debian4.0-2011-4.3.0.5020

  16. Right now we pretty much coded pretty much what is in the templates. There is not more (hidden) stuff... Also, the email subsystem is not the same like the HTML subsystem, it is really just a small subsystem to get the email sent out with the content that we needed. But agreed, at some point we need a documentation for it.

     

    OK, than I've to ask for the specific variable: When I'm using an IVR the SOAP requests transmits a unique call id which represents the current call. How do I include this call id into the mail of the voice box?

     

    Some background: We want to setup an interactive emergency call system where the customer first has to enter his customer id by using an IVR. This customer id is validated through a SOAP request, the server who validates the customer id also opens a trouble ticket with the call data. After this the customer is transferred to a voice mail extension which sends the recorded message to an email parser who should merge the voice message to the previously created ticket. To identify the right ticket I thought the call id should be the easiest way since the data entered at the IVR are not available within the voice message email.

  17. Hello,

     

    We cannot change the rDNS records to an individual site on a shared server. If we had our own dedicated server, that would be a non-issue.

    it's not necessary to get an individual reverse DNS record, just simply a working one would be great. The IP 208.67.212.66 resolves to ips-208-67-212-66.ipslink.com, so it would be enough if there would a DNS record for ips-208-67-212-66.ipslink.com which points to 208.67.212.66.

     

    This has come up before, and the problem is that the recipient email servers are set up "too strictly".

    Well they are not setup "too strictly", forward confirmed DNS is a must have in many popular mail servers and also at most of the well known webmail hoster. I would understand if there's no revers mapping of the IP, but a IP which contains a PTR record must have the corresponding forward mapping to work correctly.

     

    There's unfortunately nothing we can do about that as we do not have input as to your setup.

    Why don't you change the configuration within the forum so that mails are sent out using a different mail server? Using a SMTP account on a well configured mail server should be very easy.

     

    At the moment it appears the best 'workaround' for this is for you to 'white list' our forum permanently.

    Sadly this is no option. Our company does not whitelist badly configured mail servers as the problem should be solved where it originates.

    At the moment I simply can not receive any notification sent out by the forum.

     

    Also I understand that it's not very important that I'm able to receive notifications of the forum, but I guess you'll have a lot of forum registrations which were not confirmed simply because the user is not able to receive the registration email.

     

    Just keep in mind that many users neither won't search why they are not able to register nor they are able to change the mail server configuration to receive your mails. As a result of this they also can not complain because they are not able to post anything and the forum also does not list an email address for help inquiries.

  18. How long is this? There is a upload limit of a megabyte or so; but the templates should not be so long...

     

    It's the default template which is already cut, I did not count the size but it should be just a few KB. I've also attached a screenshot which shows the screen before making any changes.

     

    You can check in the xml directory what the PBX has stored internally.

     

    I do not have a directory called xml unter /usr/local/snomONE/ (Debian Installation). After changing a file the new version is placed in the folder /usr/local/snomONE/webpages/.

    post-14747-0-64091800-1315382392_thumb.png

  19. Sorry, I don't get it. What should the PBX do?

     

    we're not talking about the PBX ;-)

    The bug report is about this forum, the topic of this category says: "Question About The Forum: If you have any problems with the forum please report them here." so I thought it should be in the right place.

    If possible please ask the admin of the forum server for fixing the mailserver, if anything is still unclear feel free to ask :-)

×
×
  • Create New...