Vodia PBX

No, it's just that the UPDATE implementation of most devices is actually broken and we had the same effect as you - until we turned the support of UPDATE off. And yes, if the FXS detects FAX it should send a Re-INVITE with T.38 in it. If it does not then that is a sign that the T.38 is not enabled on the device.

How is your IP config? Are you mixing DHCP with static IP addresses? Maybe it makes sense to log in through SSH and take a look at the IP config with ping.

Did you try to enter a key? Maybe you are in the interactive mode where you have to enter a key to drill deeper into the address book (e.g. 2 means ABC). We need to take a look at this here. Maybe the problem is with Italian language, not so much mainsteam on a global perspective...

Well, in those cases you should look into the generated directory and pull out the files that you want to modify and move them into the tftp directory. Then you can edit them there and add or change parameters.

Maybethe problem is that the first pattern already contains a default (396), so it would not try the 2nd one. So try: !13176440274!310!t 396

Ops, very good catch! The PINs were mixed up in the web interface. Emails seem to be okay. Well, the interface is very lax on the start and stop times. Essentially the whole conference scheduling is about agreeing on access codes and being able to send an email out that Outlook can read. There is no resource reservation, and if people want to start earlier or later, that's fine with the PBX. I think that is a feature. Anyway, seems like we'll need a 2.1.11... There is also some stuff for E911 that needs to be addressed.

Hmm. Before changing the cable, maybe it is worth to play with the input gain and/or get a FXO signal booster. Maybe there is also a simple way of getting the cables measured out, the good news about FXO is that it is stoneage technology and there is so much stuff out there for this. Well, those features rely on the Caller-ID detection... The only thing that you can do is setting up a "calling card" account and dial into it (maybe through the AA), then enter the extension number, PIN and then you can place outbound calls from there.

How long is the line? What is the carrier? "Sometimes" sounds like a analog problem. Also, set the log level high and turn PSTN logging on (after that you need another reboot). Then you may see the messages about the Caller-ID in the log.

What PSTN gateway are you using? Sounds like a problem with the hangup detection to me.

Whow a lot of processors... With the support of the USB dongles comes the trouble! Any chance to get that library into the PBX directory?

Do you want to pickup or retrieve the call? Retrieve is *86701... Star codes are not very popular because they are so hard to use!

There differences are few in the conference. The moderator has the right to kick everyone out (*9) and send a email to himself who's in the conference (*1). You need to seperate that list with semicolons and of course the email settings must be okay for the domain. http://wiki.pbxnsip.com/index.php/Conferencing and http://wiki.pbxnsip.com/index.php/Scheduling_Conferences are the latest and greatest.

Go to system settings, and change the password policy. There is something on the phone that prompts for the password when the registration failed.

Well, the "CO lines" on the web are far away from the real hardware. If the lines are still on, the FXO gateway obviously believes that the call is still on. Anything in the log with PSTN? You can turn logging for PSTN events on (requires a reboot, unfortunately).

Calls dropping are usually a problem with the hangup detection. Unfortunately, FXO is not very clear about when to hang up a call. In an extreme case, an operator might play the message "The other side has disconnected the call, now it is time for you to hang up" and wait until the PBX disconnects the line. There are three ways in the CS410 to detect call disconnect: Detect Busy Tone: The PBX tries to detect a busy tone on the line. If the other party plays a busy tone (or something that is similar), well then the PBX things oh that's my time to disconect the call. If your operator does not play busy tone, then shut this off. Detect Dial Tone: Similar, but with dial tone. In doubt, turn this off. Detect Polarity Change: That's another way. The idea is to change the polarity of the analog signal when the call gets connected and when the call gets disconnected. This can be dangerous if you have a long line and the detection is on the edge. If you know how the operator indicates the call disconnect, then you should use only that method. BTW the latest and greatest is http://www.pbxnsip.com/cs410/[color=&qu...update-2914.tgz[/color]

Those brackets are probably not right. Maybe you wanted: Extension: !1(8128675308)!\1!t!301 !1(8128675309)!\1!t!302 300

The cross-talking could be a problem with the analog lines. Maybe there is a line connected twice. Also make sure that you have the RTP ports for the PSTN gateway in a good range (e.g. 2048- 4096).

Regaring the address book: Did you change the user, the domain or the password? If yes, you need to re-provision the phone. The second language requires the appropriate lang_xx.xml files from snom in the tftp directory.

Do you see anything with UPDATE? That was a common problem with some devices that indicate they support it, but when you send UPDATE nothing happens. Otherwise, Wireshark is most useful in these cases... Maybe you can send my a PM and we'll take a look at this.

Maybe you have to update the MSP. Do this by loading http://www.pbxnsip.com/cs410/update-msp.tgz into the software update web page and reboot the device. BTW the latest and greatest to date is http://www.pbxnsip.com/cs410/update-2914.tgz, maybe you can also apply this image.

You can also manually specify the port in the command line with --http-port nnn and --https-port nnn. This helps to get the service up and running when it is not possible to kill the web server that is occupying port 80.

Hmm Anyway glad to hear it works now.

If you are using both Ethernet interfaces make sure that you have only one IP gateway set. This is a problem if you are using DHCP on eth0 and static IP on eth2. In that case you can solve the problem by using statc IP on both ports or by telling the DHCP server not to provide the default IP gateway for the MAC address of eth0. But you are right, PING must work, otherwise it is hopeless.

Maybe take a look at http://wiki.pbxnsip.com/index.php/Inbound_Calls_on_Trunk. Depending on your service provider, you probably find the destination in the To-header. In your case, maybe a pattern like "!([0-9]*)!\1!t!301" make sense.

It is possible to blind transfer participants into the conference. At the moment the ugly part is that the participants have to enter the PIN code for the conference after they are transferred.