Jump to content

Vodia PBX

Administrators
  • Posts

    11,135
  • Joined

  • Last visited

Everything posted by Vodia PBX

  1. I think the only place where you will have to change anything is on your SIP trunk header. This is not a problem of the dial plan. E.g. there is a setting in the SIP trunk that tells the PBX to present the number in E164 format (which is without the leading +).
  2. The number of SMS providers will probably for us mushroom like the SIP trunk providers—which is a good thing! So lets try to address this in a way we can maintain that for a long time. We'll add a provider "custom" that just collects the username and password (which is stored encrypted in the filesystem so there is no need to have it in clear text lying around in the file system). Then you can drop a JavaScript into the PBX that will do whatever the provider needs to send and receive messages. We'll provide an example on doc.vodia.com on how to use this, maybe just using the pushbullet.com sample.
  3. Yes this setting was made for soft phones that sometimes literally dial what users entered, for example "(617) 399 8147" which should be "6173998147". Especially when dialing from the address book or call history.
  4. Well, there is the possibility to edit a post! 1+ is very confusing indeed. Anyway there is another post about it, in a nutshell I would just look at the logs along the processing of the call and make adjustments so that the numbers make sense in each step.
  5. We should look on the process on how the dialed number gets from the original caller to the trunk. When the PBX feeds the number into the dial plan, it formats the number (by default) into the "human readable" country-code dependent format. In the US that would be 01144xxx. Then the replacement comes up with the destination number, which is then fed into to SIP trunk which may reformat the number once again. Keeping this in mind my approach would be to turn logging on and look at the numbers as they go through this process and then make adjustments to the dial plan and the presentation in the trunk.
  6. Outbound is relatively easy—inbound is the problem (but that's where things get interesting). If you have a provider that works we'll be happy to add them to the drop down. Maybe we should also start adding providers that support only outbound SMS.
  7. The headers are really just about outbound calls. There is no need to come up with headers on inbound calls. Generally the idea is that telephone numbers should be converted into the internal "global" format. That means in the case of the PBX, that the numbers start with a +-symbol. There are a couple of settings for the trunk on how it expects the numbers and that usuually works well (there are a few providers that send e.g. From in international format and To in E164-format which is causing a lot of confusion). So I would recommend to review the format of the trunk and check if the numbers are read correctly. Then there is no need to use the ERE pattern matching for inbound calls.
  8. Was seltsam ist, ist dass nach ein paar Sekunden nachdem offenbar erfolgreich auf T38 gewechselt wurde ein neues Re-INVITE reinkommt. Soll das ein Refresh sein? Oder will da die Gegenseite wirklich noch etwas ändern? Dieses SIP Paket wäre mal interessant zu sehen. Vielleicht wäre es einfacher mal ein PCAP zu machen (bequem über das Web-Interface) und das in einem Ticket an den Support zu schicken.
  9. WebRTC has changed a lot since we started, and Apple has added it also to Safari. We have already made some changes that uses the now-standardized interfaces. This should eventualy make WebRTC calls also possible on Apple Safari.
  10. With the latest dial plan handling you can control how the PBX feeds numbers into the pattern matching. For example you can feed the numbers in E164 format if that makes your life easier. You could then match 011* and replace it with +* (not sure if that works) or sip:+\1@\d (this should work).
  11. Yes. And you'll need version 65.
  12. Well we support the newer models https://doc.vodia.com/mitel_phones now.
  13. If you are on MIPS and OpenWRT you can try http://portal.vodia.com/downloads/pbx/mipsel/pbxctrl-mipsel-65.0.2 (that's just the binary). Try to download it, chmod a+rx and test if it runs with pbxctrl-mipsel-65.0.2 --version.
  14. Just search for CS5 in the pbx.xml, change it and restart the PBX.
  15. ToS = Type of Service? By default the PBX tries to assign EF for RTP and CS5 for SIP. Those settings can be found in the pbx.xml—usually there is no need to change them. Especially for SIP I doubt that it has any positive impact for the user experience.
  16. There is something about resetting the password on https://doc.vodia.com/login maybe that helps?
  17. Ahh... Yes that flag was not checked any more! We'll fix that in the next version.
  18. Oh so you don't want the email at midnight? Or at a different time. Different time, well that is not possible at the moment. It is using the main time zone of the PBX.
  19. For iOS there should be version 1.1 on the iPhone. There is an issue that the phone keeps ringing if it cannot connect to the PBX - the next version will automatically disconnect in that case. The iOS web socket subsystem seems to be a little bit wobbly - we need to better handle network problems.
  20. On 65.0 it did go out - our mail server settings were wrong...
  21. Hmm looks like this is something we need to look into. It seems to be the same problem on 65.0.
  22. You need to make sure that the license includes the collaboration feature - this is in the System Status Overview, Additional license information.
  23. It can happen when the TCP connection got closed why the PBX still had something to write (and did not process the disconnect message yet). Log level 0 is probably too low for this kind of message.
×
×
  • Create New...