Vodia PBX

As always, a great proposal. Will be part of 4.0. The OID will end with 17 (no media established) and 18 (media established, but timeout).

Try sending an instant message to the device; either directly or through the PBX. Check out sipsak, a popular tool for generating SIP messages.

Because he rport parameter is set, the PBX assumes that the device is behind NAT. I admit it is goofy, we'll make it smarter in version 4.

What is the use case here?

It could be that the file system gets jammed, and the OS has to use the CPU to clean up sectors. It might take a long time to find out what exactly caused the problems; IMHO it is easier to just try another hardware platform.

So internal calls are also a problem? If you need more CPU "juice" maybe you have to transfer the domain to a different host. For example, check out SheevaPlug. The reason could be that the codec has changed? I guess the file system still has enough space?

Hmm. If you choose the English prompts then the PBX will provision the US prompts. That is a feature for users in the USA, but understandable not for the users in Australia. We could add a tone language Australia that just contains the busy.wav and the ringback.wav in a audio_au directory. Then it would become possible to provision the tones of the phone accordingly.

This was a kind of workaround because most phones display only the "From" information, but you want to see who is being called. In a perfect world, the SIP phone would do the job and display both from and to.

Yes, the transcoding chain looks like this: IP phone (microphone) -> G.729 -> PSTN (G.711) -> GSM EFR -> Cell phone speaker. So lets say the quality was 100 % in the beginning, then the whole chain might look like this: 80 % (microphone is also "transcoding") * 75 % (G.729) * 90 % (G.711) * 70 % (GSM) * 70 % (speaker, optimistic) = 26 % left. "Illustrative", but it should be possible to get the picture why every transcoding step is a problem. I had a phone call once that must have three or four transcoding steps, and smoke signs would have been easier to understand.

Try binding the button to the identity that you want to use when parking the button. The PnP config leaves this open.

I believe what people would like to see is the company's logo, not the extension number. If we generally add that to the master file, it will mean that also the other models like 320 will download the image. That might be challenging for the internal memory. Apart from that, we can easily add the necessary XML spaghetti to the configuration template and make the link a PnP setting.

IMHO the biggest problem with G.729 is that the audio is compressed so much that customers have the impression that VoIP is inferior to PSTN. Every transcoding step reduces the amount of information transmitted.

I guess we need to change the provisioning template here. Does anyone remember which name in the XML file we are talking about?! I believe the template should make the phone quiet.

The order is "random"... Not really random in the way that it changes every time; but random in the way that it takes the sequence in which the extensions werecreated.

Because it is a embedded CPU, the CPU load is much "higher" as on a GHz CPU. So the spinking should be no worries unless you really hit the 75 % blue line. You can find out if you have a CPU spike problem if the call quality on internal calls (LAN to LAN) are also not okay.

Hmm. Dialog-state BLF remains a pain in the neck. So let me restate: The Polycom with the latest firmware blinks and when someone takes the call (no pickup with a star code or something else fancy) the LED keeps on blinking?

When will a license become invalid? Generally speaking, licenses are not time limited. So either they work or they don't in this case we don't have to worry. There are a couple of exceptions: The MAC address changes. IMHO not our problem. If someone changes the MAC than that's his problem. The license key is time limited. For this we send a email notification out and when someone logs into the web interface there is also a warning. IMHO also reasonable. Someone removes the USB stick. Here we have a serious problem. Because that will really shut down the PBX license with immediate effect. IMHO it is also okay to ask that the USB key must not be removed while the PBX is in operation. Any other exceptions that we need to deal with? Everything else like USB driver goes belly up should be fixed at the root of the problem.

First of all, did you set the country code in the domain to "1"? If the answer is yet, welcome to the NANPA numbering plan! The PBX assumes you stick to it, so there will be all kinds of problems when you try to send 12 digits. In the gateway trunk, there is a setting on how you want the numbers to be displayed. Did you choose "11" digits? Try turning the SIP logging on on the 127.0.0.1 IP address. Then we can see what the PBX sends to the gateway. BTW what SW version were you using? 3.4.0.3201???

Did you try "5" (play envelope information)?

That worries me... Who is sending that? Can you turn SIP logging on and see where that packet comes from?

No the SIP gateway is pretty dumb when it comes to digits. If you give it 11 digits then it dials 11 digits. The gateway waits some time before actually dialling the number. Regarding dial tone detection. Can you log in and check out the file /etc/sipfxo.conf? There can be a line with the following content: PSTNGW_DETECT_DIAL=1. Then the gateway will wait for the dial tone before starting to dial. P.S.: Don't hit the save button on the web interface on the FXO settings after this change, or at least make a backup of the file...

:-) Right now that is available for the cell phone redirection. IMHO it is too complicated for Joe Average to set a service flag up. But if he can use a drop-down list of available flags well then this starts to make sense. We need to keep this on the to-do list.

No, you are right it has to be an extension. Originally there were seperate park orbits; but that had the disadvantage that you always needed to assiciate the extension with a park orbit. Having this in the same number makes it very easy to park the call (almost like holding it) and then later retrieve it from there.

Yea, the presence stuff is kind of work in progress. I believe for that the phones right now would have to publish their presence state; but this never became a reality in the way that you can really use that.

Currently there is nothing you can do. The only thing that influences the behavior is the transport layer, e.g. using TLS may enable SAVP.