Vodia PBX

Is this a system without IPv4? By default, the system uses a dual stack (IPv4 and IPv6). Try starting the system with the option --ipv4 false; then IPv4 is disabled and it does not try to open IPv4 ports.

Well, the call log in the web page will not refresh unless you reload the page. Version 3.4 supports writing to the file system with in a CSV file. Each CDR record will append a new line. Are you looking for this?

Well, using a domain backup as a template is a absolutely valid way of quickly setting up a new domain. You can even have different domain templates for the different customer types that you want to set up.

Right now we don't do packet ordering for live recording (no jitter buffer). Packets are being played back as they arrive. For G.711 and other simple codecs that is no big problem; but it becomes very obvious with G.729. G.729 was designed for TDM networks and they did not anticipate that packets might ever get lost or arrive in the wrong sequence. Just like FAX. Anyway, we need to fix this later. Right now we just want to get 4.0 out and such a change would bring in a lot of new risks.

Okay as pattern for 7-digit you could use something like this: ([2-9][0-9]{6})@.*

Call log: where do you expect it? In the file system?

Well, you can use several entries, one (or more) for the 7-digit dialling and another one for the *67 processing. Anyway, we need to work on the *67 topic so that this becomes a lot easier.

Oh for that you would have to run another server. That server would talk to your CRM and then make the decision if the domain (and where!) it should be set up. Then after aproval, it would "restore" a template domain on the selected server. In PHP, that should be possible.

Do we need JavaScript to update the clock? The next thing is that people will complain that the time is not accurate!

The other proposal we heared would be "tenant". That might be better and we don't get confusion with the word "PBX".

In version 4, emails about dropped calls & co have the SIP messages attached. That should also make the "postmortem" installation debugging easier.

Depending on your phone type you can just run a very simple redirection service. Then the web server just needs to look up the MAC address and then redirect the request to the right PBX which will do the details.

Not only RTP, but also SIP traffic should have the traffic class set. There is a setting called "tos_sip" (check the pbx.xml) which contains the value that will be set. This should be a valid DiffSrv value. The default is "cs5". The other problem that could cause this problem is that the process itself does not have the permission to set the traffic class granted by the OS.

Does MoH work when you make calls from one PBX extension to another (without OCS being involved)? In the OCS case, who is holding the call? If a PBX extension is holding the call, that feature must work. The other direction is a lot more tricky. But maybe we sort the easy cases out first...

Yea this is a kin of moving target. The first problem is that they sometime just blacklist IP addresses (probably similar to the automatic blacklisting of the PBX). The second problem is the TLS features that they expect. There are different ways to encrypt TLS messages, and I have the feeling sometimes they enable and disable certain mechanisms that the PBX is using. If you run your own email server you have full control over it; if you are using gmail it is a little bit question of luck. SO if you can, use your own email server...

I guess that is the point here. A load balancer would be able to solve the problem that when using just one DNS name for the provisioning the request would be sent to the right node in the cluster. Until this thing is available, the provisioning URL is the key for load balancing. A feasable solution right now is to give every domain a different provisioning DNS name, so that later when you have to move domains from one server to another server, you can just change the DNS entry. The outbound proxy will be set up later down the provisioning process and will be automatically changed by the PBX provisioning mechanism if the server address is different.

Well, I assume that the phone does not overwrite the outbound setting on its own? If it does get changed this is probably because of the provisioning going on. That would be okay if the provisioning server is a DNS address, which may be moved to another cluster.

I dont get it... You mean that the PBX automatically provisions the IP address in the outbound proxy? Generally speaking, the host resolving part should be done in the setting URL. There the phone will make the DNS query and locate the right PBX.

There was a discussion going on about this topic also in another thread. The point is that the PBX already supports the "hiding" of the caller-ID. There is a RFC for that, and the PBX supports it. Now there are two problems: 1. On the trunk side, it is a fact that many providers (especially those who offer FXO) expect a prefix in front of the number that should be dialled. This prefix is usually *67. In addition to the RFC method, the trunk should support this way of indicating anonymous calls. 2. On the extension side there is a similar problem. Although there are some SIP phones that support the RFC method, it is usually difficult to use and easier to just dial *67xxx as well. The PBX should not think that this is a star code, it should treat this call as if it would be the indication of an anonymous call. The pattern would be \*67([0-9]+)@.* and the replacement sip:\*67\1@\r;user=phone.

Yepp, that's when things get tricky. I would vote for making *67 a way for indicating anonymous calls and don't just transparently treat it as any star code. I think that is what customers actually want.

You need to use CO-lines for that. It is a little tricky; anyway specifically for NBE we are working on a easy frontend that makes the setup a lot more simple.

This might help: http://forum.pbxnsip.com/index.php?showtopic=5. See also http://kiwi.pbxnsip.com/index.php/Inbound_...s_the_extension (sorry for the old link, I was not able to find it on https://pbxnsipsupport.com.

Yea that explains it. My other guess would have been the automatic blacklisting of the PBX.

Does the phone have the credentials to download http://voip.vonvox.net/provisioning/snom360-000413291522.htm? When I click on the link, of course the web browser says "who are you". Also, what firmware are you using on the phone?

I guess when you load https://(my PBXNSIP ip address):443/prov/snom_3xx_phone.xml?model=snom370 from a web browser, it works? Was the snom_3xx_phone.xml already in the generated directory for this phone? Maybe the firmware has a bug fetching https URLs (AFAIK it is not a released version).