Vodia PBX

Yes, the PBX supports G.722 (which runs at 64 kbit/s). However, as the prompts are all in 8 kHz you should not expect miracles when taking to the mailbox. But for calls that pass through the PBX the call quality should be great. We don't support G.722.1 (see http://en.wikipedia.org/wiki/G.722.1). That is a different codec. Seems the licensing terms are reasonable and even the CPU overhead is relatively low. So that might mean one nice day we can add this codec as well. Please note that even for G.722, transcoding means loosing quality. If you are transcoding between G.711 and G.722 you will have worse quality than with a pure G.711 call. This is a little bit surprising in the beginning, but it becomes understandable that representing an audio signal with 64 kbit/s in two different ways can result only in a common denominator quality. One more reason to avoid transcoding where ever possible.

I would not manually add them. Just change a global setting from the web interface, this will rewrite the pbx.xml file. Then either edit it there (need restart) or use the web interface to change it (described on the wiki page I mentioned above).

At the moment I would say the answer is no. You can program specific destinations, but you cannot have the user press a key and then enter the remaining digits. The only thing would be entering something like "9" in the beginning (well, that's also a key!) and then deal with the local dial plan on the phone to generate a *90 out of it.

That would be "email_address_change".

If you have several IP addresses, you might have to specify on what IP address the multicast traffic should be set. There is a setting called "Multicast IP-Addresses" in the admin/ports section where you can enter the private IP address. You need to restart the PBX after changing that setting.

We have added STARTTLS, which is probably causing the problem. It works with google, but that seems to be only half the battle. We have another case where it does not work, but maybe you can also send me (PM) a test account for that server and we can test it from the lab.

For media-related issues, PCAP is the preferred way to see what is really going on. Maybe in this case the routing table of the PBX would also be useful.

Well, what header are you looking at? The Request-URI must be 100, because that's what has been registered. The To-Header should contain the destination number that the gateway should dial.

No NAT here. Just wanted to make the general point with TCP that the contact header in SIP is useless for a user-agent ("Contact: <sip:lala@ip;transport=tcp>"), especially behind NAT. Instead of that, they should have taken something like a connection ID. But without NAT is is almost the same problem, because also phones with a routable address typically do not accept incoming TCP connections, because of DoS and general programming pain in embedded environments.

Well, my Wireshark shows that the UDP packet checksums are incorrect... The reason is defintively not the ITSP, as the UDP checksums are generated by the router (as UDP is layer 3). Maybe something stupid like bits flipping around, bytes being chopped off, or just a bad firmware on the router. Checksums are there for a reason and they should be correct!

Yea, that's the reason why we introduced that "call extension" feature...

Is there any reason why you want to register the FXO? Usually you just use the outbound proxy on both the PBX and the gateway to point to each other and use a trunk. If you want to use the "call extension" feature, the replacement is the extension number (e.g. "100", no "sip" or domain name before or after that).

Ehh.... they are hidden, but available. Check the pbx.xml file for names starting with "email_". You can change them in the pbx.xml file (which would require a restart) or use the trick in http://wiki.pbxnsip.com/index.php/Global_Configuration_File.

Practically all carriers that I know do not support that. They are so scared that people abuse this feature for spoofing Caller-ID that they prefer to present only the trunk Caller-ID or even "Anonymous". Maybe we need to introduce a new SIP header that tells the carrier that the call is actually a money-generating cell-phone redirect and corresponds to an incoming call: INVITE sip:cell-number@carrier.com SIP/2.0 From: <sip:outside-number> To: <sip:inside-number> Call-ID: 123 P-Corresponds-To: Call-ID-of-other-call CSeq: 1 INVITE

I don't think that makes a difference. The PBX generally sends the RTP to where it comes from, unless you disable that behavior (this is the "strict RFC mode" because the IETF had nothing better to do than say that RTP can actually come from different ports and even IP addresses). But Polycom and practically all SIP phone vendors that do have an interest to sell phones behind NAT send and receive on the same UDP port.

I see a lot of UDP checksum errors going into the CS410. Maybe the CS410 (Linux) rejects them on the operating system and they do not count as traffic.

Yea, especially if there is only one annoucement it is extremly boring. But you can do a lot if you insert messages like "please hold the line". The more prompts you have the better the impression.

It is an upgrade problem. When you perform an upgrade of the PBX and we update the template on the pbxnsip side, you will not get those updates unless you remove the file from the file system. May not be a major problem, just want to mention it.

We had to change a couple of things with the alias. The calls must now be routed through a trunk to the other domain. The old way is not suitable for server farms where you have no idea on which server a domain (or tel:-alias) is physically located. As we catch up with the documentation we'll elaborate that on the Wiki in further detail.

Well first of all this is a event that you should check. Typically it is a sign that the extension is behind a router that is not suitable for SIP. In 2.1 the only way you can get rid of these messages is to use a rule on your email client that moves them to the trash can. We added flags in 3.0 where you can select what messages you want to receive.

:blush: Well, you never really now. But I would give VPN only 1 % problem probability. TCP for user agents was specified by the IETF in a sick way (they obviously cared more about the proxies). The idea was essentially that you open two TCP connections for each direction, which is a little bit tricky if you come from behind NAT. The new outbound solves that problem. But the X-lite was written way before outbound was proposed. Anyway, the discussion is kind of historical, so I think we should be pragmatic here and just use UDP.

Sounds like trouble with the STARTTLS. Is it possible that we can get a test account on that SMTP server? Then we can play with it in the lab and get it working.

The problem is not on the speech server side. The PBX does try to send a BYE to the phone, but there is nothing coming back. See the BYE packet that the PBX tries to send right after receiving the BYE from the PBX. I think it must have to do with the TCP transport layer. Just for the sake of locating the problem, can you chang ethe X-lite to UDP transport layer and see if the behavior changes?

You can place the template into the html directory (not the tftp directory), and then you can change the value in the template. Attached is the latest template (please note that once you put it into the html directory, you will miss new versions of the template that come with new PBX versions). Do you think it makes sense to make this parameter configurable? We did not really think about this parameter, we just took the default coming from Polycom. This is usually a reasonable approach. There are a lot of configurable parameters (well, the file is 120 KB!!!), so we definitevely don't want to include all of them. For example, we included a parameter that makes it possible to turn the HTTP server off (security leak). Also, if you are using a analog gateway (FXO) you might have to check the gain on the gateway (see http://wiki.pbxnsip.com/index.php/Gain_Adjustment). Maybe the gain there is too low and then you have to increase the volume on the phones to hear something. The default config on the Polycoms is usually pretty good if the incoming gain is okay. Ouch. At least we want to avoid that other guys go through the same pain again. polycom_sip.xml

What OS is it? Is the OS behaving okay apart from that? Any other applications on that system? What about netstat when the system is not accepting anything any more? Is there a firewall in front of the system? Maybe you can quickly run Wireshark when the problem occurs to see if there is anything strange. Also is there any way you can monitor the system with SNMP? Maybe watch the host and also the application (e.g. CPU usage, number of registrations).