Jump to content

cwernstedt

Members
  • Posts

    91
  • Joined

  • Last visited

Recent Profile Visitors

5,260 profile views

cwernstedt's Achievements

Newbie

Newbie (1/14)

  • First Post Rare
  • Collaborator Rare
  • Dedicated Rare
  • Week One Done Rare
  • One Month Later Rare

Recent Badges

0

Reputation

  1. I upgraded to version 68.0.1 . Certificates are still not successfully updated. I see "Could not retrieve directory from directory https://acme-v02.api.letsencrypt.org/directory " in the log.
  2. OK. This is what I see in the log (the real domain name and IP address I've censored out) after renaming the System Management DNS address and then renaming it back. The line with "Could not retrieve directory" looks suspicious. Any idea? LYNC: Creating pbx-admin.xyz.com [6] 13:28:32.009 LYNC: Using IP address 20.203.51.134 for creating DNS A record for pbx-admin.xyz.com [8] 13:28:34.526 LYNC: Create new account [3] 13:28:34.921 LYNC: Could not retrieve directory from directory https://acme-v02.api.letsencrypt.org/directory [8] 13:28:34.921 LYNC: New order pbx-admin.xyz.com [8] 13:28:34.921 LYNC: Done creating pbx-admin.xyz.com
  3. In this case it's Let's Encrypt which sends me expiration warning emails, so it's the PBX which failed to renew the certs for some reason, and they do expire within a week or so, indicating failure to renew quite a long ago. Version is 63.0.1 . I haven't dared to update for fear of breaking something. Some way I can troubleshoot further?
  4. Let’s Encrypt Certs have suddenly begun to expire on our PBX with no configuration change. What might be the cause?
  5. How could that happen? Bug? Server wasn’t touched except for a reboot.
  6. After reboot, the call history shows all calls as having been made on 12/31/1969 7:00:00 PM . Version is 63.0.1 (Debian64) . Any idea of what happened here and how it can be prevented in the future? (Fortunately this time, the log isn't needed.)
  7. DNSmadeEasy provides a user name, and two keys: API Key and Secret Key . From these three, what should go into the two fields provided on the pbx (user name and password) ? [Solved on my own: Should be API Key and Secret Key for user name and password ]
  8. To clarify, this is the situation, and maybe there is a misunderstanding: Twilio utilizes, for example, the below IP-addresses and with 3.122.181.0/24 network for Media being put into use on Monday next week. Is it perhaps the case that only the signalling IP-addresses need to be configured in the Vodia trunk settings, and that media will flow regardless of if the originating Media IP-addresses match trunk settings? If so, Twilio users should be fine...If not, there's a lot of trouble coming. Signalling IPs: 35.156.191.128/30 which translates to: 35.156.191.128 35.156.191.129 35.156.191.130 35.156.191.131 Ports: 5060 (UDP/TCP), 5061 (TLS) Media IPs: 35.156.191.128/25 3.122.181.0/24 Port Range: 10,000 to 20,000 (UDP)
  9. I have this problem now with Twilio as they just added a class C network , and things will stop working next week unless I add it. (Trunk doesn't get properly identified on incoming calls without the IP-addresses specified.)
  10. Ok. Where do I configure these things in this version? Ideally I would like to prefix +423 to all numbers lacking a 00 prefix (local numbers) and replace 00 prefixes with + for international numbers. So 2371336 would turn into +423 2371336 and 0013343456666 would turn into +1 3343456666 . (Incoming calls only)
  11. Hi, Well, it's the inbound (not dialed) that I'm looking to change. In other words, the number that is presented on calees' phones and in logs etc. The trunk provider presents local numbers without the correct international prefix, which makes it difficult to process these calls correctly.
  12. One of our SIP-trunk providers isn't particularly good about how they present the CIDs on inbound calls. Is there a way to rewrite these according to some rules, for example replacing 001 with +1 , or adding a country code to local numbers. Note for clarity: I'm talking about how numbers are presented in the From field in CDRs, logs, etc.
  13. Can you take a look at the packet captures zipped and attached to the earlier message? ( )
  14. Initiate call back after hangup is "No" for the called extension in the tests and the calls are not made from a cellphone or POTS-phone, but from a registered extension.
  15. I assume it's the mailbox, since there is no agent group configured, but mailbox doesn't explicitly offer callback as an option, and "offer camp on" is disabled. The sequence of events from the point of view of the caller seems to be like this: 1) caller places a call to the extension 2) Ring tones are generated . 3) "Something" (probably voicemail) at the PBX picks up and it immediately (before even playing a greeting) for unknown reasons adds the caller to the callback list. 4) The caller hangs up. From the callee's point of view, the phone rings, but when picking up, it's the PBX offering various options. Not sure what it is. (See the file rec_115_13.wav in the attached ZIP. I'm also attaching PCAP files captured on the PBX.) When this happens there is always two calls registered in the log, starting at the same time. A big question is if the callback list option can somehow be triggered before the mailbox has kicked in . It almost appears to be the case, because the mailbox really shouldn't have come into play here. (The callee account had a live registration generated by Counterpath, and the callee picked up well before the call should have landed in voicemail.) weird call with stretto.zip
×
×
  • Create New...