Vodia PBX

I would disable the NAT support on the firewall to see if that is the problem.

So do you see any traces in the log that the phone tries to get to the PBX? Also check http://wiki.pbxnsip.com/index.php/Polycom...

There is something at http://wiki.pbxnsip.com/index.php/Polycom#...transport_layer, maybe just give that a try.

What is the "Generate passwords" (in admin/settings/ports)? Maybe the phone cannot pull down the configuration? Do you see and TFTP requests in the log file of the PBX?

Well, so we just have another reason to do this painful internal conversion into the global telephone number format!

Check this out: http://wiki.pbxnsip.com/index.php/Global_Configuration_File

Well, you can start with http://wiki.pbxnsip.com/index.php/Troubles..._Trunk_Problems, though this is primary for SIP trunks. I would also check if you have a echo problem, a jitter/packets dropping problem or simply a volume problem. If internal calls are fine then there must be something with the PSTN termination/gateway.

You can use sftp (in most Linux systems) or psftp ir SecureSSH to load the files on the system. See http://wiki.pbxnsip.com/index.php/Installi...th_secure_shell on how to log in.

You can do a trick/workaround - just record it with *98 and then repace them on the file system. You usually can easily see by the timestamp what file you have to replace. Also you can quickly listen to them before replacing them.

I checked again http://www.ietf.org/rfc/rfc3842.txt. IMHO the MWI bodies of the PBX are correct. If there is no new message, then the PBX will say "Messages-Waiting: no". That is the correct behavior.

Yes it is in the works. The address book already has a CMC field, and the ACD and the hunt group are able to display the CMC on incoming calls. And with snom phones, you can also enter the CMC code during the call. That CMC will show up in the CDR.

Can you get an Ethereal trace? Then we can see what the problem is.

Yes, that is a "feature" - a few seconds until the FXO has dialtone and a few seconds to dial the ten or eleven DTMF tones. Faster has the risk of getting instable.

Inbound or outbound? Inbound requires to listen to the 2nd ring for caller-ID detection; outbound required (slow) DTMF dialing. SIP trunks are just "instantaneous" - caller-ID is immediately available.

The problem is the initial message after subscribing for BLF. This message contains a list of the buttons, and depending on the length of the names this packet can easily get longer than 1492 bytes. If you just have 6 buttons, then that message size is usually enough.

Well, then you have a problem with the DTMF detection. Try turning the PBX inband detection on (System/Settings) and see if that helps.

That's really strange. Maybe that call was technically never really in connected state? Or maybe there was a problem with a Re-INVITE.

Well, this is not a stupid question. The point about version 3.1 is that address book entries and also other "telephone" numbers are internally stored in the "+" format (e.g. +3912345678). Havnig 003912345678 as well as 012345678 is just creating such a big mess that you can never be sure what number you want to dial. The "9" prefix that indicates an outside line becomes a little bit pointless in SIP. Like on the cell phone you have to push the "dial" button any way, especially in countries like Italy where you can't know how long a number is. If you do want a "9" prefix, the phone has to deal with it and strip it. It is just to make you comfortable to hear a dial tone after entering a nine, but it has no more technical background. Psychology. IMHO we should just get over it and just dial the number that we want to talk to. If you explicity want to route +-numbers in the dial plan then you have to use a pattern like "+*" or "+39*".

I think that's because every cell phone has it this way...

Idle is the state after creating the call object, but having no ringback yet. It is possible to stay in this state if the PSTN gateway does not signal a "ringing" yet. If you are using a ITSP and packets drop on the line, then it can be that the call stays "idle" for a relatively long time (BTW for that reason the PRACK SIP method was invented).

Hmm. That should work (we are using this rule in our Boston office). Can you give a concrete example?

But then there must have been something wrong with these numbers? If you set the country code to "1" the PBX must think that this is a international number. Can you give an example? Well, the point of all these canonicalizations is to solve this problem. There is a conversion rule in the trunk now that you can set. If you choose the 10/11-digit rule then the PBX will assume the trunk is in NAPNA and then automatically convert numbers into the +1(xxx)xxx-xxxx format.

If you are using UDP for sending SIP packets the phones cannot receive the packets because of UDP fragmentation. You have to switch to TCP transport layer (or TLS, if you have a certificate that the phones accept).

Addition: You can use *98*1 to record the first message, *98*2 for the second and so on until *98*5. That was introduced in 3.1.

I have no experience with RV082. Check out http://wiki.pbxnsip.com/index.php/Registration_Duration if that helps.