Vodia PBX

You can use the address book as database. But the PBX does not send a request to an external server when the call comes in, this could cause problems e.g. when the other server is not responding in time.

I would just put the IP address of the server into the settings_server field of the phone. This is pretty much like option 66. As far as I remember this is in the webinterface in advanced, then on the very right tab. I also remember that you can hold the pound key down while booting (but after it asks to interrupt the boot process), then you can enter the IP address also from the phone keyboard.

Try to change the Remote Party/Privacy Indication in the trunk to No Indication, or the other possibilities in the drop down. I guess that is the problem here.

Check out the "source" code in the web interface (admin/web/templates). If you see something like "{lng xxx}" then the text is stored in the dictionary, which can also be edited through the web interface. Which one needs to be corrected? Maybe we can also include that in the next build...

Yea I would say Juniper is high quality, and they should have at least a log if they drop traffic and why. Also check if you have remote users working from home, they might use something else than Juniper.

Neither. They are 16 bit/sample.

There is a option to send the registration notifications to the admin (and only to the admin). Firewall: Well, as you know, there are usually two these days. The internal and the external. The internal (Windows Firewall) usually does not have a capacitiy limit, as least I have never seen it. But I have seen a lot of external firewalls that have capacitiy limits, especially small home routers typically have limits like 32 table entries.

Asterisk can do transcoding as well. It all depends on the setup. But this could be another transcoding step. IMHO the easiest is to keep it to G711 by default, then the transcoding to the PSTN (PRI, ISDN) can be loss less.

This feature is available when you park a call. If nobody picks up, the system will call the one who parked the call. But you are right, for unattended transfer this also makes a lot of sense. Maybe we can even enhance it a little and say it will also get transferred back when the call hits the mailbox.

Between mars and earth? Usually when the sound does not sound like packet loss, it is a problem with excessive transcoding. Remember from information theory, transcoding can only reduce the audio quality, even when transcoding "to" a great codec. If you do that a couple of times, it really sounds like smoke signs on a mointain. Least common denominator!

I dont think that the PBX is at its capacitiy limit here. It might be a hint that the firewall has reached the table size for NAT and starts dropping connections. You can check this by turning on sending emails to the admin when a registration changes (in the extension settings, registration tab). Then you can also see if it is specific extensions which have that problem to narrow the source of the problem down.

Klingt nach einem Problem mit dem DialPlan (Rufschema), welches der Nebenstelle zugewiesen ist. Ich würde mir mal das Log ansehen und lesen was da so passiert wenn der Anruf reinkommt.

Make sure you import the certificate that you need for Skype TLS: http://forum.snomone.com/index.php?/topic/4738-problem-with-skype-sip-connection/

In an ideal world... But I know the Meeting poing has (obviously) a different media stack at the bottom, so that might explain why some codecs behave differently...

I would make a backup of the PBX directory and upgrade to the latest release at a time when there are not too many calls going on.

Most service providers use other service providers to terminate their traffic, and the routing can be really unpredictable. So they might not have it in their hands on how exactly the caller-ID is being presented. Especially if they dont use SBC (instead use SIP proxy model), it is practically impossible to keep this 100 % under control. Keep the 20 secs for some time until the dust settles. This is something that should not hurt, except for generating higher traffic. Later you can try to slow it down or seek other ways to keep the connection alive (e.g. put the trunk on a public IP address).

A quick fix is to replace audio_en/ringback.wav with whatever they want to hear.

I would just try to keep the trunk alive by forcing the PBX to re-register every 20 seconds. From what I saw about the provider, they expect the PBX to keep the connection alive.

Well, there is no INVITE coming in at all... So it must be something with the firewall I guess. Firewalls and NAT continue to be a pain in the neck when it comes to SIP, sorry for that. Also, it seems that your service provider does not provide the convenience of a session border controller to keep the connection alive or support something like outbound (which automatically set up STUN as a refresh method). A easy way to fix this is to set the "Keepalive Time" in the trunk to 20 seconds.

Do you see anything in the LOG? Try turning on the log messages and then make an inbound call. If you see nothing at all, this will be most probably a problem with the firewall. If you do see traffic, dive into the log messages, for example maybe the way the number is presented does not match your extension naming any more. Sometimes the providers change the number presentation, and you could have this problem as well.

Maybe just limit it to G.711. Maybe for some reason it will prefer something like G.722 or linear, and has some interop problems. G.711 should be simple and always work.

We are watching it... working on a few parts at least!

SIP interoperability is not the big problem with PSTN gateways. I would focus on having good echo cancellation, and overall stable design. Fortunately, there are a handful of excellent choices, the above included.

The point is that this gets out of the domain sand box. You could "steal" DID number from other domains.

Try to make the phone call without video. It is better to take this out of the equation at this point.