Jump to content

Vodia PBX

Administrators
  • Posts

    11,135
  • Joined

  • Last visited

Everything posted by Vodia PBX

  1. They way we are support mySQL will change in version 4. There we use the SOAP API as a generic interface to the databases. SOAP can be used to talk to a "glue logic" program that will talk natively to the mySQL. This has the benefit that we are much more flexible with different databases. Right now we can offer you a Apache/PHP solution that talks to the DB. Hopefully we can offer a Phython-based solution which is a little bit more lightweight that does the same job. Additionally we will offer Email CDR. Email is very powerful and robust; and there are tons of tools available that can untimately put the CDR into your database.
  2. I wish the world out there would be clear when it comes to representing where the call comes from. It is a pretty big mess. What is clear that the "From" header contains what the call phone should have on the display. Period. The mess is about PAI, PPI, Remote-Party-ID and all that stuff. Everyone uses it in a different way. That is why we have so man options and you always have to guess which one is the right one. Actually, for a proper trunk identification, all you need is the ICID. This is a kind of token that identifies the trunk to the provider, very very simple and does the job 100 %. We also send an additional prorietary header called "Related-Call-ID", which contains the Call-ID for the original call. This should make it possible for the carrier to verify that the content of the From-field is okay and that we are not just spoofing Caller-IDs.
  3. The phone does not answer the challenge it seems. Try a newer firmware version, the one you are using might be buggy.
  4. If you want to split up a server it is usually easier to clone the setup and then delete those domains that are not supposed to be on the respective server. Yea, cloning global numbers is an issue. Essentially the problem is that their scope is not in the domain, that is why we have problems backing them up as well.
  5. Whow, this is big! Seems SQLServer supports SOAP very well. We might be able to interface to the SQLServer very easily! For mySQL I could not find anything except the usual PHP/Apache stuff where you have to program the SOAP processing in PHP.
  6. Ops, edited the "done", thanks. We added a special warning flag that will show in the future if there is no web or sip passwort set. Next version will show it (3/4)
  7. Oh you mean a client matter code? Good point. Maybe we nede to have a drop down for the dial plan that says: 1. No authentication required 2. PIN required 3. CMC required
  8. Right now you have to do it this way. Each account can have one dial plan. For those accounts that would require PIN authorization, you would choose a dial plan that does not allow it. When users want to place a LD call, they need to have a second account that has a different dial plan which allows this. Then those users can call *91 or use a calling card account to place outbound calls. If you choose a very secret password for the second account, then you can make sure that nobody registers a SIP phone there and that those extensions are only used for LD calls. The CDR will show the second extension in the CDR record, so that billing will be easy. We'll see if we can make this easier, e.g. add a field to the dial plan for those entries that require a PIN code. In certian countries, that is a standard PBX feature and we don't want to miss it!
  9. Check this out: http://forum.pbxnsip.com/index.php?showtopic=2080 There are essentially two settings: tos_rtp and tos_sip (see pbx.xml). You can set them to their numberical or also their symbolic value, e.g. "ef" (which is actually the default for RTP) or "af31". The default for SIP is "cs5".
  10. MoH for the hunt group is not possible right now. But you are right, this could be possible. In the old versions a call would just be a call after someone in the hunt group picks up; but now it is still a hunt group call. Anyway, you can at least set up the MoH for each domain; that should help. There is no global address book, only domain address books. You would have to copy the address book to all domains. The best would be to arrange a more or less automatic import, so that later changes can be replicated easily.
  11. Well that's a long story... IMHO SOAP is not the best way to do it, maybe a quick & dirty way to get started. But you better take a look at CSTA. This will make sure the interface will not change later, as CSTA is pretty well defined and documented.
  12. It would be interesting to see why they reject the request. I don't think that the request-URI is "bad". Maybe you can post the REGISTER request here and we can take a look.
  13. Did you change anything in the PBX software recently? Did anything else change in the network? Sometimes the problem with the static IP is that there is a IP address conflict in the network. It would not be the first time when someone else makes a mistake and configures the same IP in the network. IP address conflicts can cause a lot of tricky problems (that is why DHCP makes a lot of sense, even if a specific host should have a specific IP address). Send a PM to me...
  14. Looks to me like there is a problem on the IP config of the system. For example, if the DHCP lease time is just 30 seconds and the DHCP server is very slow, then the PBX host would suffer from temporarily being unable to send out requests to 10.0.3.16 and would log these messages. Check if there is anything with the IP configuration that could cause issues. VPN connections are always a good candidate for trouble. Or if you have multiple IP addresses on the same Ethernet connector, this could also be a problem. In any case, the routing table must be clear and clean. Check "route print" if it makes 100 % sense to you.
  15. Try to log with log level 9 for s short moment. Then you see where the PBX is trying to send those messages.
  16. For outbound calls, the log message probably comes from the call that initiates the call (from the extension). That is of course okay. This message is only interesting for inbound calls from a trunk to the PBX.
  17. No, I think that was already available in V3.
  18. No, it should not send registrations... Strange. Was is a registration trunk before? Maybe there is something dangling.
  19. The other thing you can try is to avoid UPDATE. The service provider proposes the usage of UPDATE: Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,[b]UPDATE[/b],MESSAGE,REFER However, then the PBX sends an UPDATE request to the service provider, there is no response at all (packet number 120 in the pcap). I guess that is where the communication goes wrong. Much later, there is a requets timeout for the UPDATE (packet 1947). There are actually many devides that advertize UPDATE but don't support it or their support is extremly buggy. Because of that we have changed the UPDATE policy in later versions and by default the PBX does nut use UPDATE any more. Anyway, in your case it seems that usage is still activated. Check the pbx.xml file for "support_update" and change it to false (the easiest is to edit the pbx.xml file and restart the service; you can also do it through the webinterface, see https://www.pbxnsipsupport.com/index.php?_m...barticleid=413).
  20. Yes you can. If you go to the admin/configuration page you can schedule a reboot at next convenience (when there is no call going on) or at midnight. That will reboot the whole system. Works in Linux, Windows and also MAC and FreeBSD.
  21. I am not against soft phones. They can be a great thing and PC are extremly powerful. I just want to say be careful what you install on your computer with all you data on it (not only soft phones). Not everything that is free is good for you! Sometimes it is good to have a contract with the company that provides the software, so that you can sue them if they should abuse the trust you gave them! Check out the latest news about China and google, this is just the beginning IMHO.
  22. Running a PBX on a public IP address with no password is pretty very dangerous. I would like to share a little shell script with you that oes through the XML files and pulls out those accounts which are affected: #!/bin/bash # Show the passwords of all users: function get_xml() { gawk -v tag=$1 'BEGIN{regex="<" tag ">([^<]*)</" tag ">";}{ match($0, regex, m); for(i = 1;; i++) { if(!(i in m)) break; printf("%s\n",m[i]);}}' $2 } for user in users/*.xml do name=${user:6} # only the name idx=${name%.xml} # only the number type=$(get_xml type $user) if [ "$type" == extensions ]; then id=$(get_xml id $user) primary=$(get_xml alias $user) password=$(get_xml password extensions/$id.xml) if [ -z "$password" ]; then domain=$(get_xml domain $user) username=$(get_xml name user_alias/$primary.xml) domainname=$(get_xml name domains/$domain.xml) echo $username@$domainname fi fi done Please check if there are accounts that need passwords to be set. Unfortunately "marketing" required that we made it very easy for the user to change their password, so the JavaScript that checks the password quality was turned off by default. I strongly recommend to turn it on again, even it users are complaining that their password "1234" cannot be accepted any more.
  23. Try upgrading from Windows Vista to Windows 7...
  24. If you want free, try the softphone that puts a trojan horse on your computer. Softphones open firewalls, send "IM" messages (with attachments, maybe your data?), maybe encrypt traffic so the firewall cannot check it, runs with your login permission (and file system access locally and in the network), etc etc. Installing network-enabled software on your computer is a leap of faith. You really really need to trust that company. Just my two cents. They also need to pay bills at the end of the month... http://counterpath.com/counterpath-reports...al-results.html. Nothing is for free. http://en.wikipedia.org/wiki/Trojan_Horse F.Y.E.
  25. Thats the time when the flag ist not redirecting the calls, business hours, so in other words the service flag is inactive. You are defining the holes in the swiss cheese. BTW IMHO 24:00 should also be okay. We want to make sure that callers can get through at 23:59:30!
×
×
  • Create New...