Jump to content

Vodia PBX

Administrators
  • Posts

    10,090
  • Joined

  • Last visited

Everything posted by Vodia PBX

  1. I think we had our own experience with such a kind of setup. We tried to run the PBX locally through cable modems and other Internet connections. The result was that those connections tended to be so unstable that we got scared of accepting calls. Also, QoS is a huge, practically unsolvable problem. Initially we had a server in New York in a nice colocation with a doubtless Internet connectivity. We thought it would be superflous. But it turned out that is the best way for us. We can register wherever we are (home, travel, office), and usually have a good connectivity. And at least when someone is calling in trough our ITSP, we know that that connection is rock solid. DoS is an issue, but if you don't want to open the SIP ports to the whole world, you can easily move it to an "random" port (e.g. 45456) and DoS is not such a big problem. If you can limit the access to specific IP addresses on the built-in firewall (e.g. possible in SuSE Linux), then the system should be very stable. We also put a DoS protection into the latest versions that simply limits the number of new connections per second, so that the CPU always has enough time to process everything. So far our system on public IP did not get into any trouble. But we are just a small trial - so the 100 % success rate might not be representative...
  2. A very simple trick is to add the IP address as alias name for the domain. Then the PBX will change the IP address to the primary domain name. If the domain is not a local name, it is neccessary to keep the domain name. Otherwise, calls from sip:123@pbxnsip.com to your domain would always appear as a call from extension 123.
  3. T.38 only solves the problem for traffic between the two T.38 endpoints. If you have international carriers, they might tunnel the voice traffic through VoIP and don't deal with packet loss. In that case, you will not be able to receive faxes, no matter what you do on your side. Generally speaking, if your RTP traffic is just in the LAN (where you have no packet loss) and your PSTN termination comes from a PSTN gateway, using T.38 or just G.711 does not make a difference. T.38 makes only sense if you want to send faxes over links that might loose packets.
  4. What version? Try to set the delay explicitly in the user login. http://wiki.pbxnsip.com/index.php/General_User_Settings
  5. What version? There were some old versions that had problems with that. Also check if the domain has other CO lines with the same name.
  6. We never got a Zyltus phone in our hands... So far their support for us was not overwhealming! Maybe we should get a phone in the lab and take a look. I think just by looking at SIP traces this could become difficult. The good news is that the Swedish prompts are ready and we will make them available shortly
  7. Well, realisticly is you want to provide hosted services you need a session border controller anyway. And that realisticly means that you need to relay the media anyway. And realisticly, statistically speaking, most of the calls are external calls anyway and there media path optimization does not give you anything. The biggest problem is delay, and here especially DSL. If you have fast DSL or other access methods, the delay becomes less critical and then it does not really matter anymore if you relay or not. And the good news is that you can easily offer features like call barge in and recording.
  8. You can load the attached file into the html directory of the pbx and restart the service. If the html directory does not exist, create it first (in the working directory of the PBX). The future builds will contain the new file, this file is just for a fix of existing installations. When upgrading to versions after 2.0.2.1668, don't forget to delete the file. timezones.xml
  9. We did get it working some time ago on a very basic level (only showing on/off). But did not look at it again so far.
  10. http://wiki.pbxnsip.com/index.php/Type_of_Service.
  11. Vodia PBX

    Codec

    If you are not using the same codec, you would not hear anything. Choppy audio is usually not a question of the codec per se, it is a question on packet routing. If you want to do a detail analysis, you need a RTP analysis tool. For example wireshark.
  12. Choppy audio is a sign that RTP does not take the direct path. Maybe it is first going out, then taking a trip over one or two continents and finally come back. We have seen such cases. Ethereal/wireshark is your friend here, or check the route on you host. if you have several interfaces make sure the traffic leaves your host the right way.
  13. Whow that is really a long post. You can attach files by using the "Attachments" field below the text edit field. "Loud static" is usually caused by SRTP key negotiation problems. I would say you should try to turn SRTP off on the phones. This is done per identity in the SIP or RTP settings. From what I saw in the log, the phone does offer the SRTP key although it is using UDP, and that might cause confusion with the SRTP key policy. If you want to use SRTP, you must use TLS transport layer also on the phones. You can do this by using a outbound proxy like "sip:1.2.3.4:5061;transport=tls" on the phone or by having the neccessary DNS SRV records for the domain.
  14. You might also have to open the ports for RTP. See the Ports web page in the admin mode for the ports that the PBX uses. This is really weired. When you enter the extension through the firewall, do you have a two-way audio conversation later?
  15. Vodia PBX

    DTMF

    If DTMF does not work, there is most probably a problem with the out of band codec negotiation. There is still a lot of equipment out there which does not properly advertize the RFC 2833 codec, which is frequently leading to problems with the DTMF. The SDP attachment of the INVITE message should contain something like this: v=0 o=root 971198566 971198566 IN IP4 192.168.9.254 s=call c=IN IP4 192.168.9.254 t=0 0 m=audio 61434 RTP/AVP 0 8 9 2 3 18 4 101 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:9 g722/8000 a=rtpmap:2 g726-32/8000 a=rtpmap:3 gsm/8000 a=rtpmap:18 g729/8000 a=rtpmap:4 g723/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=sendrecv The type "telephone-event" tells the PBX that the codec 101 is used for RFC 2833 DTMF. If that codec is present, then the PBX knows where to search for out of band DTMF codecs. If that codec is missing, there is something wrong with the device or service provider that tries to talk to the PBX. Usually devices have an option to turn this feature on.
  16. I start this topic because it is a frequent topic. Please feel free to comment.
  17. We tried doing telephone support. But it was a frustrating experience. There were people on the phone who had simply no clue what they are doing ("I don't care about this QoS thing on my Internet - just get it working in a stable way"), were asking for support for other products ("I have problems with my SER, can you help me setting it up?") and sometime we had to navigate them through the menus ("Now move the mouse up a little bit, then left, press the left mouse button"). The record of a "kindergarden customer" on the phone was six hours (we had to increase the hangup time in the PBX for this customer). Some people on the phone became aggressive when they realized that we will not help them to understand VoIP. If people want this kind of support, they can have it - but we charge extra for that. The nice thing about a forum is that we answer a question once and then many people can use this answer. It "scales" better than 1:1 support.
  18. Well, you can get the message that an extension does not exist when you enter something in the auto attendant. But the auto attendant does not play music on hold and does not ask you to hang up. Therefore, it could be that this message comes from somewhere else.
  19. Check out http://wiki.pbxnsip.com/index.php/Domain_S..._on_Hold_Source
  20. Whow. Sounds like the CPU gets overloaded? There was a problem with the multithreaded priorities in Linux. I think the 1611 might still have that problem, maybe you can try a newer build. We still have a problem with the embedded versions. The Linux scheduler seems to have its own mind. Windows seems to be easier...
  21. Well, a SIP log would be the best. You can capture it on the phone as well as on the PBX. Also a description on how you initiate the transfer. Are you using the outbound proxy on the phone?
  22. Did you try to put a '8' in front of the extension number? http://wiki.pbxnsip.com/index.php/Domain_S...ect_Dial_Prefix
  23. No this is not normal. At the moment that is considered not a serious problem, we'll solve it along the way.
  24. Hmm. Is that the exact prompt? Check the audio_en directory - AFAIK there is no such message available.
  25. SIP has different error classes. If I read it right, the standard says that 4xx class codes should tell the PBX not to try again. For example, 486 means that the user is busy, and also trying another route will not change that fact. In a perfect world, a gateway sends a 5xx class response to tell that the gateway is busy. The problem is that some implementations send 486 if the gateway is busy. In this case it does make sense to try another trunk. That is the reason why we added the setting for the error response class. According to SIP, the request timeout should be in the 30 s area. However, if the Internet is down you don't want to wait so long. That is why the request timeout can explicitly specified for a trunk.
×
×
  • Create New...