Vodia PBX

You should use a trunk and configure it as gateway. Make sure that you set the outbound proxy. That should be enough for a simple configuration.

Hmm... Did you check if the M3 has the latest firmware? Wireshark will show what the problem is. Also you can look at the https://www.pbxnsipsupport.com/index.php?_m...kbarticleid=447 checklist.

This never became RFC. Microsoft needs this stuff in order to get Exchange working. I believe that is the only reason why the header is there.

AFAIK you need snom phones to be able to enter CMC during the call. Apart from that, the address book contains a CMC field. That method automatically tags calls with CMC calls if the PBX can match a caller-ID to an address book entry.

Ouch. Yes, don't do that.

Are you using plug and play?

So far no. But the http://kiwi.pbxnsip.com/index.php/Password_Overview (sorry I can't find it in the knowledge database) should be a very good template for this.

This is probably a STUN packet. This should usually not render and problem?!

What we have seen are packet storms that register over and over. This can be just a buggy device that just thinks that it should answer a password change with the wrong password over and over or a device that has a problem with the duration of the registration. We also have seen devices that try passwords out (so better don't choose "123" as password!). In any case, in version 4 we now automatically add the source address to the blocked list for one hour (parameters adjustable). That solves this problem.

It depends on the trunk mode. If you are using proxy mode, the PBX represents anonymous numbers in the IETF way.

Looks like someone accidentially called "*". Probably now listens to the annoucement that this destination is not available...

Well that is only possible with duplicating accounts and using static registrations that point to the other PBX. We (pbxnsip) love this approach because we sell twice as much licenses. If you have below 10 extensions I would use the direct destinations on the AA for this.

Does this always happen or did it happen only once?

That is what the IETF proposes for anonymous SIP calls... You don't even want to let the other party know from what domain you are calling from!

Currently this is only a 4.0 feature. After getting this stable lets see if we can port this back to version 3.

It seems that sometimes the format has still some issues. I am using GoldWave and I was always able to play the file back, even if GoldWave also complanied about the file being buggy. I believe we did fix something with the padding; but it seems that there is still something that causes problems. The other thing that could be a problem is that the email program translated LF into CRLF. You can check if this is the case by taking the WAV from the file system and play it back.

No. Features like recording are system-global. You cannot control that on account level.

When a user is calling from a known cell phone (extension cell phone) the PBX will behave differently. That is supposed to be a feature. No idea why the PBX would redirect him to 333. I would check if there is any redirection or hot desking going on. Loosing voicemail greetings is of course not okay and it should not happen. Does not sound like a know issue to be (no bells ringing). Any more insight would be useful. We will keep the eyes open ...

That is going to be tricky. The only thing that comes to my mind is to loop the request through the PBX to shake off the original caller-ID. Pretty dirty, IMHO not really worth thinking about it. There is no time-of-day ANI representation, that part is clear!

I believe the SPA does support this; however AFAIK (supposed to be a feature) when there is already a call going on and you use the auto answer, then the ongoing call is put on hold (no matter where you are in the conversation) and the auto answer call is on.

The 3.4 release notes mention there was a problem with Hot Desking (see https://www.pbxnsipsupport.com/index.php?_m...&ratetype=1).

You should not use G.711 in this case. Maybe GSM or G.726 or G.729. And you should make the packet length like 40 ms or even 60 or 80 ms (the delay does not matter anyway). Then you can get the bandwidth down from 80 kbit/s to something like maybe 15 kbit/s.

The CS410 PBX does; however the FXO gateway that comes built-in to the CS410 does not.

This is excellent! SIP is about connecting state-of-the-art components together and this is a great example that it works.

So you are using version 3.4? There was a bug with the setup of hot desking. Maybe you have to log out and log in again. Last resort is to delete the extensions and recreate them (in any case, make a backup of the file system).