Jump to content

stoneracer

Members
  • Posts

    27
  • Joined

  • Last visited

Everything 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. this worked many thanks for the fast help
  5. 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?
  6. the ""Shared Business CA 4" cert is included - see https://forum.vodia.com/topic/15587-deutsche-telekom-deutschlandlan-sip-trunk/?tab=comments#comment-44974 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.
  7. 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-----
  8. 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.
  9. 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.
  10. 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.
  11. It would be great if it would be possible to add a hunt group to the list of agents in a agent group
  12. hmmm no answer? Maybe this question should be transferred to the service flags board, but how do I mange this?
  13. 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".
  14. well my question was more if the feature will likely be removed from the code in future versions. Since it has been removed from the web interface I'm afraid that it might get completely removed.
  15. 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)"
  16. many thanks, this solved my problem. Will this option reintegrated in future versions or do I have to expect to lose this again?
  17. 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?
  18. I did a test upgrade to version 4.3.0.5020 but the result stays the same :-( Any ideas how to fix this? Are there any other config options which could influence the callback behavior?
  19. 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?
  20. 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
  21. 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.
  22. Hello, 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. 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. 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. 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.
  23. Hi, is there any list of the available variables (with short explanations would be great, but I also take a raw list) which can be used when modifying the email templates? If not I would recommend this a feature request ;-) Thanks in advance.
  24. 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. 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/.
  25. 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...