Vodia PBX

Upgrade. There is at least a 1.5.10 version, and as far as I can recall there was something with CO-lines that was fixed between 1.5.6 and 1.5.10. Or even better, upgrade to 2.1.

Yea the references are really done using the literal text "co1" etc. If you remove the source, it breaks the reference. That with the music is strange. You are sure that the call does not run into an agent group? Or maybe you have a funny SIP device that initiates a call in call hold mode?

Nope, that is not possible... The call is on a trunk.

TAPI: http://wiki.pbxnsip.com/index.php/TAPI_Service_Provider Apart from that check out the email support.

It is the same as used in the Service Flag, see http://wiki.pbxnsip.com/index.php/Service_Flag.

We had a case where Asterisk was sending RFC 2833 DTMF, but extremly short ("Blitz DTMF"). It was so short (0 ms) that the PBX never had the chance to transcode it into inband DTMF. Maybe that is the problem here as well.

It being used on the CS410, the music in jack streams data on the MoH port. It uses (mono) G.711. Maybe do you have a Wireshark trace of the VLC stream?

Ah. Yes that helps. The personal greetings should be moved between the same versions. When we introduced the possibility to have several personal greetings, the file format changed. That should happen automatically when performing an update on the same server, but it is not supported when moving a domain from a "old" format to the "new" format.

Start the services manager (Run services.msc) and edit the properties of the pbxnsip service. There is a tab for service failure, you may choose to restart the service after the first failure.

We had a router that was running out of CPU when the number of packets per second was getting too high. Wireshark will show this. The other thing is processor affinity, virtual machines and swapping. Maybe turn off logging to make sure it is not something stupid like the file system.

Okay, let me restate the question... Are you moving the whole server or just a domain? You are really making a ZIP of the whole directory and unzip it on the Linux server? I verified case and slashes - they should be fine. Can you tell me what is in the extension/nnn.xml (look for *.wav) and if that file exists in the recordings directory?

There is a VLAN setting in the PnP parameters of the PBX, did you try that? I saw in the release notes of the snom 7.1.33 that the new version will take one more reboot cycle in order to get the VLAN parameter correctly, maybe that was also part of the problem.

The easiest is to delete the extension and then create a new one. There is no explicit reset button. For hospitality environments, we added a SOAP request so that the PMS can trigger this action when the guest checks out.

All media is subject to the SBC functionality of the PBX, which is very useful if you want to send FAX from one device behind NAT to another device behind NAT. Maybe a video client can also be behind NAT. The good news for video is that the packets are large and the frequency is low, and the CPU has not so much to do shuffling the packets back and forth between the OS and the application.

Hmm. The only thing that comes to my mind are case-sensitive file names. Anything in this direction? The other things are backslashes - anything there in the XML files? Maybe we need a short script that patches the XML files accordingly.

I don't know... I don't think it is okay to say the device is crashing and they don't have any plan to take care about it. Other vendors take crashes pretty serious. I think the only thing that we can do is trying out another version that is not crashing the phone. What you can try is disabling the pass-through RTP. There is a global setting called "allow_pass_through", if you set it to false then it will not simply pass the RTP through, but run it through the jitter buffer. See http://wiki.pbxnsip.com/index.php/Global_Configuration_File on how to set this setting.

Well, a device should not crash if there is something unexpected. Did you contact Grandstream? I think if the device is crashing it should be a high priority trouble ticket and you will get a new firmware soon. We are using an ATA in one office (Grandstream HT-502 V1.1B 1.0.0.44), and it was so far pretty stable and also T.38 is working fine after we disabled UPDATE support on the PBX. BTW don't use STUN, it is instable and IMHO not suitable for enterprise communication.

The problem is the underlying data model. If create a service flag, it will get a number. Then if you reference it from the extension web page, everything is fone. When you delete the service flag and create a new one, that one has a different number, even if the name is the same. Then the reference gets broken. That is perfectly normal to a computer programmer, but not for a end user. We think using more Ajax can address this and make end user's life easier, but we want to stay away from hardcoding the internal database relations and resolve conflicts.

Are you using outbound proxy? Some devices have problems is the domain name is "localhost", that may be the problem with the Grandstream devices as well.

The status is that video works if you first have a audio-only connection and then switch to video (with a Re-INVITE). It is all because of T.38, which is also kind of video (pretty static, though).

For the PBX: http://wiki.pbxnsip.com/index.php/Installa...and_Quick_Start explains some general information. http://www.pbxnsip.com/templates contains a 10 extension configuration that you can import into the PBX to get jump-started. For Polycom: http://wiki.pbxnsip.com/index.php/Polycom has some infos on how to set these devices up. http://forum.pbxnsip.com/index.php?showtop...tart=#entry4014 is a very interesting post on how to set the Polycom phones up.

That does not ring a bell... Any specific information, SIP trace or so? Try hitting the save button again. Maybe the reference got broken somehow, saving it would restore it.

It is a regular version, no feature excluded. The limitatons are the memory, for example call recording will be difficult. But the good news is that it comes with a great PSTN gateway.

We try to make only bugfixes in the 2.1 branch. New features (even if some people don't like it) go to the head branch (we will probably call it 3.0 then).

Probably the Cisco did not like the http in the alert info. Can you give the attached ringback.xml a try? You need to restart the service for that or load it through the special web interface page (Reload Configuration Files in admin/configuration). ringtones.xml