Jump to content
Vodia PBX forum

stoneracer

Members
  • Content Count

    22
  • Joined

  • Last visited

Community Reputation

0 Neutral

About stoneracer

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