Jump to content


  • Posts

  • Joined

  • Last visited

stoneracer's Achievements


Newbie (1/14)



  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 ""} {if_lt ip ""} <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- Beta Corona Austrinids (Debian32)"
  • Create New...