Vodia PBX

I believe you have to send an empty message...

Yes. There is a settings for this in the phone.

Yea, the problem is that the PBX first sends the MWI, then sends the email and then marks the message as "saved". We will change the sequence so that the PBX will first send the email, mark the message as saved and then send the MWI. That should fix the problem.

I would double check the setup of the card.

You can start two PAC ...

No not CPU intense.

That sounds more like a bug to me: Two guys in the queue, one of then ringing agents. That call is being picked up by *87, and the other call does not advance in the queue and just stays there in the queue listening to music. Right?

Attended transfer or blind transfer? I guess it must be blind? There is a RFC for updating the caller-ID. But the support in existing SIP devices is "weak"....

If you are using a FXO interface check the gain settings. Probably the signal is just too low. It becomes very obvious when you hear the loud IVR prompts and then a relatively low volume recording.

Any insight from the SIP logging? Maybe a request timeout after about 30 seconds?

Hmm. Sounds almost like a problem with the Sangoma setup. Maybe a WAV file missing there? I know a couple of Sangoma setups that work without problems.

If you like give it a try with http://pbxnsip.com/protect/pbxctrl-3.1.1.3089.exe (Win32).

Well, that is the codec for sending the media (which is fine, don't change it). What is the codec for sending RFC4733? Most of the time it is something like 101/telephone-event.

Thinking about hosted environments that sounds like a feature to me... You should not be able to spy on your neighbors!

Make it possible to provide a admin password for all phones in the domain.

Well that's my point: G.722 and PSTN don't make sense. Then better use G.711, because PSTN is G.711. Don't worry about CPU. I would say G.722 is at least ten times faster than G.729A.

As far as I know Mytel still belongs to the service providers who do not provide any kind of session border controller (SBC) functionality to their customers and instead requires that customers have a public IP address. Trying to workaround this fact will not make the solution more stable... If they require a public IP address maybe you should listen to them and get one for the PBX. Why the SonicWall has only one registration is just another mystery. I guess we can spend a lot of time trying to figure out what happens between the service provider and the firewall. I could imagine it is something stupid like the service provider associates a registration with a IP address/port and that is why you can have only one registration. A packet log from the firewall on the public interface will make this problem visible. If you have the time to troubleshoot this, put a Ethernet hub on the public Ethernet interface of the firewall and record the traffic with Wireshark. Then we can all take a look at this and find out if the problem is on the service provider side, the firewall side or somewhere else.

That with the admin login will be difficult, just because we need somehow an ID. Maybe the provisioning account in 3.1 in the domain would be a candidate for this. The CPU intense application is a valid point. But this cannot be a binary decision. We need to say how many calls can be recorded per domain and how many people can be in a conference per domain. A call in the "maximum calls" needs to be weighted according to the complexity.

G.722 is pretty easy. Transcoding is not an issue of CPU performance. G.722 is not G.722.1. G.722.1 is a Polycom codec; that codec has a similar complexity like G.729A. The bigger problem is that transcoding reduces audio quality. Remember that both codecs represent the audio in 64 kbit/s and that formatting the audio from one representation into another reduces the information. Therefore, the PBX has a strong interest in trying to avoid the transcoding anyway - that's why the PBX tries to UPDATE or Re-INVITE after an attended transfer; the typical case for running into a G.722 transcoding situation.

It would be interesting to see what DTMF codec has been negotiated and if the DTMF is inband what level and noise the DTMF has.

Hmm. It could be the we have to provison this specific device a different firmware than the other phones. I remember something like the conference phones need a newer firmware than the good old 2.2.2. If that's the case we are a little bit in trouble, because we have only one tftp directory. Hmm. Maybe we need a kind of "virtual" tftp directory for specifc devices. Otherwise I don't see how we can have different firmware versions for different devices! Ouch.

Well, it is a little bit debatable if that call that should be recorded or not. But probably it should - as the caller probably ideally has no idea the call was redirected. We need to put that into the code. 3.1.1 will have it.

Yes that looks correct. There should be no difference between Linux and Windows; the differnce is probably just when you saved something the last time. After using the link above, the file should contain the setting that you want. We are piling more and more "hidden" settings up. Usually we don't want that customers play with these setting (because it makes support more difficult); however it is always good to be able to make a change when neccessary without changing the code. That settings above would be a candidate for becoming visible...

Okay, so the phone does go to the PBX... Did you drop the Polycom files into the tftp directory? And also, is there at least one extension set up for plug and play? Check the "generated" directory if you can spot the phone's MAC address there.

You can also use psftp on Windows (which it putty), no need to learn shell scripts in Linux!