Jump to content
Vodia PBX forum

stoneracer

Members
  • Content Count

    25
  • Joined

  • Last visited

Community Reputation

0 Neutral

About stoneracer

  • Rank
    Member
  1. 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.
  2. this worked many thanks for the fast help
  3. 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?
  4. 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.
  5. 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-----
  6. 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.
  7. 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.
  8. 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.
  9. It would be great if it would be possible to add a hunt group to the list of agents in a agent group
  10. hmmm no answer? Maybe this question should be transferred to the service flags board, but how do I mange this?
  11. 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".
  12. 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.
  13. 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)"
  14. many thanks, this solved my problem. Will this option reintegrated in future versions or do I have to expect to lose this again?
  15. 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?
×
×
  • Create New...