Vodia PBX

What do you want to change? The log looks fine at first glance. P.S. It is interesting that the provider reveals the routing to you. Now you are probably able to shoot SIP packets to any location in their network!

Yes, it is very interesting to see what Skype is doing recently. I think they did a great job moving towards SIP. SIP trunking will now be even more interesting.

Yes, we put that on the to-do list. If we clean this area up, we want to clean it up once and forever.

Hmm. Any chance to quickly try another provider just to see if that is the problem? Divide and conquer... Or do you have the chance to get a public IP address for the PBX (in addition to the private IP address). That makes it very easy for the provider to give you good SIP trunking service.

I used to tend to agree until I found out how easy and powerful it is to use email for this instead. It is a dinosaur technology, but it just works great. All kinds of workflow, achive, you name it is based on email. Email is not only for human interaction, it is also for machine machine interaction.

They are; there is a file called "helplinks.txt", I attach a current snapshot for reference. helplinks.txt

Well, if I understand the Microsoft guy right, Exchange has a problem when the blind transfer first disconnects the referring call before it establishes the new call. The blind transfer has a long history of problems, that is why we implemented it this way. The biggest problem is that it is not clear who is responsible for hanging up. From today's perspective, it should be the best solution to move the referring call leg to an IVR saying something like "your call has been transferred", then hang up. It is up to the connected user-agent to hang up before the IVR plays back. Obviously that will take some time until we have that.

Well, if you want to use Microsoft stuff then you probably need to check out Exchange. Otherwise there is FAX software, for example faxback (see http://www.pbxnsip.com/news/pbxnsip-faxback.php, http://kb.faxback.com/HOWTO+-+pbxnsip+Integration, http://forum.pbxnsip.com/index.php?showtopic=1358, http://forum.pbxnsip.com/index.php?showtopic=1316).

Well, I think most want it visible. So for those who want to hide it, we need to do something special. Maybe we just add something to the appearance web page, that is easier than generating a "hide" key.

No, we dropped the idea of supporting mySQL natively... First of all, there is email2db available (and probably other tools as well), which makes it very easy and reliable to send the CDR into a database of your choice (mySQL, postgreSQL, SQLServer, Oracle, ...). The other thing is that mySQL does not exist in this form any more, check out the news about Sun Microsystems!

If you sometimes get Caller-ID, then it is probably an analog problem. The CS410 FXO gateway is not very good when the signal is noisy or low. I remember there is some equipment out there that amplifies it so that the signal is clear, you might want to consider this.

Yea, I think we need to expand the size of the managed memory to 16 MB; this will take some more memory but at least we don't run into the problem of having to release it. We'll include that in the next 3.5 build. 50 MB recordings sound unreasonable to me. That would be 8 hours of recording. Unless you don't compress, then it is just one hour.

Would be interesting to know if there are recordings bigger than 4 MB. It is a warning sign, and the next interesting step would be to hit the 2 GB allocated limit (31 bits). If this is a critical server and you have the chance to restart the service at some time consider doing that until we know what is bigger than 4 MB.

Well, the 1760960164-1709445284 means that 1760960164 bytes have been allocated and freed using regular library calls, 1709445284 have been freed. So 51 MB are currrenty being used by the PBX. The problem is that freeing memory is tricky; sometimes the OS cannot use it any more and it just keeps lingering in the process space. It happens only if the PBX needs chunks bigger than 4 MB. Is there anything (e.g. tftp directory) that is bigger than 4 MB?

Well, if you know what you are doing tftp is better than a factory reset!

Don't forget authentication. That was a royal problem for us! How can you trust a provisioning request? We are working on certificate-based authentication, so that devices with fab-certificates can be provisioned out of the box. All other devices must be manually set up with the username and password. Trusting the MAC is just a very pragmatic approach, I guess you guys know how easy it is to trick that. DNS SRV is not really happening. The IETF overengineered it and early Open Source implementations did get it totally wrong. And there is no real need for it, you can use as well DNS A. It might become a topic when people really are able to make peer to peer calls with something like "abc@company.com".

I don't know... Then we have to tell each and everyone which port it is and how to use netstat.

Well, right now these messages show up under the "TFTP" logging. There is no much TFTP going on these days, so maybe we just rename it. Plus you get a lot out of the generated directory.

If you have PnP set up the right way, you should always be able to nuke the phone (well, factory reset it) and it should then pull down the config from the PBX. Having local changes is always tricky; its that old problem of database replication/redundancy where the data originates from--you end up with problems like these where you have an inconsistent configuration.

I would just pay attention to the routing. Make sure that the default route uses the interface with the public IP address. Windows seems to prefer the interface with the highest bandwidth as the default route, and that is in many cases the "LAN" interface. Also all that Internet sharing, bridging could be trouble. I would turn if off (not turn it on) at least in the beginning. In Windows, IMHO it should also be possible to do the same setup with just one NIC. Because it is pretty simple to have multiple IP addresses on the same NIC, this could save some money. But I would do this as a third step, there you really have to be clear on the routing...

It could be a race condition with the loading from the file system. Especially when you have a network-mounted file system, it could be that the loading is too slow and that somehow leads to a stall in the playback procedure. If you have a lab setup, send a email to support with the indication of your OS. It is definivively worth trying out the 3.5 build.

The PBX trusts the Call-ID to a certain degree. This is like a token or session-ID. The Call-ID is challenged only every ~100 registration attempts. When you are using 30 second refresh time, that means after approx. one hour the situation should stabilize. There are devices out there which do not generate unique Call-ID because they don't initialize the random number generator--it always starts with the same number for all devices out there! Not sure if the SPA have that bug. However, if they do that the registration would get pretty much messed up and you will have all kind of "funny" effects, especially inbound calls will be a mess. Needless to say, if all devices have the same random numbers, those devices will not give you any security anyway. Security has a lot to do with randomness and the possibility to predict device behavior.

Yea, the same problem happens when you use speed dial, you see the speed dial number but not the real number and name. It is not as inconvenient as the park/pickup, but technically the same problem. There is a SIP standard for that (poorly supported, though) and we use it. We need to verify we are really sending it out. As for the IVR annoucement that the call was parked, IMHO that is a feature. If the user is very busy, he can just start the next call and the PBX will play the annoucement while that call is on hold, in other words you wont hear it.

Well, those templates should be editable on domain level as well. The point is to get away from the parameters and move towards templates. I have seen how salesforce does it e.g. for the emails. This makes a lot of sense, and I believe it can be extended to the PnP templates as well. Once we have that behind us, I think we can keep it for a long time this way.

Check out the "l" line in the SIP message attachment. The text is generated automatically, depending on the button type.