Vodia PBX

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

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.

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

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.

http://wiki.pbxnsip.com/index.php/Type_of_Service.

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.

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.

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.

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?

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.

I start this topic because it is a frequent topic. Please feel free to comment.

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.

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.

Check out http://wiki.pbxnsip.com/index.php/Domain_S..._on_Hold_Source

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...

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?

Did you try to put a '8' in front of the extension number? http://wiki.pbxnsip.com/index.php/Domain_S...ect_Dial_Prefix

No this is not normal. At the moment that is considered not a serious problem, we'll solve it along the way.

Hmm. Is that the exact prompt? Check the audio_en directory - AFAIK there is no such message available.

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.

Bump answer. On the snom's it is generally better to use the extension mode. It seems that this CO-line topic is still not finished, we did some testing during the past few days and well, there were still problems monitoring CO lines (especially picking up parked calls). Version 2.0.2 will fix it, we will install a trial today. Also, it can always happen that there is a race condition. For example, if two persons pick up a call at the same time, then it is unpredictable who will get the call. But I guess that was not the problem in this case.

The problem is packet loss. T.38 compansates packet loss. That is the reason why T.38 has been specified. Unfortunately, they made it very complicated, so that the product support is still quite poor. The PBX has the additional problem that it has to maintain a constant RTP playout rate. If the input side has too much jitter, the PBX starts to insert packets on its own. For voice that is great, but for Fax it is desastrous. All in all, the bottom line is that you cannot transport Fax over the public Internet using G711. BTW the same is true if you are using compressing codecs.

The "free" support is on best effort basis. It can happen that other items have higher priority and then the public support slows down.

You can see the content of the key with a base64 decoding tool, e.g. http://www.opinionatedgeek.com/dotnet/tools/Base64Decode.

I think you have to use the To-header routing. Did you check http://wiki.pbxnsip.com/index.php/Inbound_Calls_on_Trunk? Maybe a pattern like !(.*)!\1!t! does the job already.