Vodia PBX

First of all, check out http://wiki.pbxnsip.com/index.php/FAX. If the service provider supports T.38 then that's a good start. But both ends need to support T.38. Fortunately, most SIP ATA support T.38 today. Exchange is a difficult topic. I know some people got it working; but it is not easy. There is also another post of available FAX software (see http://forum.pbxnsip.com/index.php?showtopic=1316). It is also worth a try.

Yea, you can get it working. IMHO it was a bug of the old phone systems; you could easily accidentially pick up a call. Lets say someone calls the boss and at the same time you want to call the boss. In the millisecond when the PBX sends out the blinking notification, then the finger already touches the key and instead of talking to the boss you talk to the customer. This is called a "race condition". To make a long story short, you can turn this buggy old behavior on with the flag "offer_pickup"; set it to "true" (see http://wiki.pbxnsip.com/index.php/Global_Configuration_File on how to do that) and then in the BLF mode you can pickup the call.

Do you see the "Rates" tab in the trunk? If yes then you have a license key that checks the prepaid status of the account and then things will get a little bit tricky. Otherwise I assume that you just have a dial plan that conflicts with the country code of the domain. That was the major cleanup for version 3.3. If you put a country code, then the PBX puts the destiantion number in that coutries represetation and you should write the dial plan accordingly. For example, if you set the country code to 33, then the dial plan should use 00* for international calls; if you put a 1 as country code you should use 011* for international calls.

I would set up four service flags (say 85, 86, 87, 88) and then list them in the night service fields: Service Flag Account: 85 86 87 88 Night Service Number: 95 96 97 98

One trunk can have 4 calls. No problem. But many customer feel the desire to run calls on ITSP as in parallel to the FXO termination. For that you need a second trunk.

You should make the "Keep CDR Duration" shorter. Then there are not so many files. Also, you can see the available file system space in the status interface. SNMP: It would be easy to add a OID for the number of CDR in the PBX. That value corresponds to the file system space.

I don't think there a change over the last couple of versions. All version 3 all behave the same IMHO.

Is that the end of FAX? How else would they transport FAX reliably? I would open a bottle if there is something that actually works without headaches and can even be run through SRTP (secure FAX!!!).

The whole problem with G.729 is hold. When someone holds the call, the PBX has to do something, and that thing must perform G.729 encoding. That does take CPU horsepower, and there is no way around it. That is why we are not very excited about G.729 on an embedded system... 488? What is the PBX sending? Can you put the INVITE packet in the post?

I don't understand it, but I would not argue...

We cleaned some stuff up in this corner, and it will be included in the next 3.3.2 build (maybe we call it 3.4!).

You are right. We need to fix that. Workaround is a little bit difficult. But I believe you can trick the JavaScript by entering the number without brackets, don't leave the input field just press enter (that would be another bug, but not so serious).

One side was extremly loud. If you look at the WAV you see the signal jumping from one edge to the other. Maybe a temporary freak out of the audio subsystem.

Well, you could try to add a static registration... This is very close to breaking your fingers and if you want to operate the devices behind NAT simply impossible. IMHO not a real solution. The alternative is to turn the subscription off on the other device as well. But then both devices must accept unsolicited MWI messages.

Sure? Did you see there are exclamation marks (!) and pipes (|)? They look similar, but have a fundamental different meaning!

The PBX believes the call comes from a trunk that redirects the call; using user 100 ("assume call comes from ..."). Is that indended? Usually this is only used for Exchange trunks.

Well, the log tells us, that the PBX is able to detect that the line is ringing; but no caller-ID; not in FSK mode nor in DTMF mode....... AFAIK there are no other modes on his planet. So you are sure that e.g. a phone is able to show the Caller-ID? If that is a yea, the only idea I have left is that you might need to amplify the signal; maybe it is not strong enough and we have an analog problem (do you have a good volume on the line?).

The "0.0.0.0" just means "bind it to all local IPv4 addresses". That is just UNIX style of telling the operating system to which IP address the socket should be bound (Windows does it the same way). That is absolutely okay. We just included the "0.0.0.0" to make that point clear. The 404 not found has nothing to do with this.

Also check out email2db.com or any other tool that can read an email and extract information into a database.

You probably have to dial something like *98xxx*1. If you look at the IVR page of the AA then you see the codes that you can dial ("Record from phone"). I just saw that this one shows all alias names (with a space in between). That hint is misleading. If course you should not dial "*98123 attendant*1", but just "*98123*1". If you have only one name for the auto attendant it is fine, though. And check the dial plan of your phone. E.g. Linksys phones tend to dial after two digits unless you fix their internal dial plan.

As long as they all properly SUBSCRIBE to MWI it should work like a charm. We did the workaround that if there is no subscription for an extension then the PBX sends the MWI also without subscription.

3.3.1 is out and it does fix some issues (see the release notes at http://wiki.pbxnsip.com/index.php/Release_Notes_3.3). There will be another version coming out that fixes some other issues; nothing major IMHO just to let you know.

Not really. This should be "opaque" for you, as the PBX in future versions might add more tables and modify rows. The interesting directories from a admin's perspective are: tftp: That is where firmware and other stuff that should be used during the provisioning of endpoints html: That directory may override content of the internal html folder which is compiled into the PBX. Typically, if you want to make major changes to the web interface, want to change the pnp.xml file or you want to change ringtones in the ringtones.xml file. generated: Here the PBX may write files that were generated on-the-fly by the PBX during the provisioning process.

The watch call setting only affects the provisioning and maybe the permissions (is employee A allowed to see the calls of employee . If you set the BLF up manually on the phone, then that field does not play a role. IMHO BLF is only good for "on" (connected) and "off" (not connected). As the name suggest, it is a "busy lamp"; you are busy (talking) or not. SIP phones do not tell the PBX when they go offhook. Therefore there is little hope that we can emulate that feature of the good old telecom system with dialog state. The problem with dialog-state is that it does not have a "off-hook" state; and even states like alerting are "debatable" (no clear standard for this). That is why we promote the "buttons" document - it clearly and simply says that the PBX wants to turn a button on, and there is no complex XML scheme that needs to be discussed by IETF gurus.

Any chance to get a Wireshark trace on the Comcast IP addresses? Or maybe Comcast is just on its way of disconvering the beautiy of VoIP!