Vodia PBX

Did you set up a button group for the extension that your register with?

Can Metropolis show information like waiting time and that this call was a ACD call? How should it look like?

The bind() message should not be the problem (we already took it out in a later build). The PBX just tries to get a port, and if that port is not available, it tries another one. Of course, make sure that you have a large RTP port range, so that you are not running out of RTP ports. I still don't clearly understand what makes the difference between the failed call and the successful call. Do you say that is depends on what port it chooses? If that is the case, can you double-check the firewall port range? Other potential reasons for such behavior are usually race conditions, e.g. the answer comes earlier or later. Is there anything in this direction?

Hmm. Maybe you can call the mailbox or some other IVR which has "digital" audio quality (e.g. the conference room without anyone in it). If the problem persists, then maybe there is some parameter on the conference phone wrong? Maybe the echo of the room generates a loop or something like that.

You really should get them every day. We do get them every day (and it has become a valuable morning lecture for me). In the beginning they were often classified as SPAM, but once that we told the email system it is not SPAM it works quiet stable.

Well, there are two things. First, there are two places for settings the SMTP server. One is on admin level, and there is another one on domain level. The other thing is that once that emails are being put into the spool directory, the email server is fixed. That means, you might have to manually delete the emails from the spool directory to get them out of the system.

Yes, it is on the short list. But it will be in the version 3.

It would probably better to split this topic off to a new topic, as it is not directly related to the 2.1.7 release.

There are a couple of differences. MAC OS is a little bit like BSD. Not sure if MAC is a significant market, we were also thinking about Solaris. Sun has a very good reputation in the server market, and that is what you want to hear when you are talking about a PBX platform.

Do you have a LOG with the SIP messages? No problem if they don't support other messages, they only need to support REGISTER, MESSAGE and properly reject incoming INVITE messages (e.g. with 500 Not Implemented).

The SIMPLE support is very simple. The PBX practically works like a SIP proxy in this case, it just takes a MESSAGE request and sends it to all registered user agents. There is no store/forward. I would say, register the device and give it a try. So far I have seen it working with Counterpath (did not try anything else).

When I hear "static" the first thing that comes to my mind is SRTP trouble. Is there a crypro heder in the SDP? If you can still hear the real audio it is not SRTP. The PBX itself is "pure digital" and does not introduce noise into the RTP stream. Does it make a difference what you are calling? Maybe there is a audio loop if you are talking to something in the room or in the office.

That indicates that the PBX received the same amount as it send (probably the 20 seconds time difference come from ringing). From that persoective, it does not "sound" like one-way audio problem. The packet size for the 200 okay is in the 1200 bytes range. There are only 300 bytes left until you will experience UDP fragmentation. That might be a problem when you offer more codecs or add another Record-Route into the packet (or just dial a very long name). Also check http://wiki.pbxnsip.com/index.php/One-way_Audio. It would probably better to split this topic off to a new topic, as it is not directly related to the 2.1.7 release.

Why not for "no answer"? I think it is nice if someone is out for lunch, you want to talk to him and get a call back after he is back from lunch and finishes the first call.

That is a "famous" problem... Some operators accept foreign caller-ID, others (most) don't. I think in SS#7 is it quite okay to have one "display name" caller-ID which is presented to the end user, and at the same time the network-asserted caller-ID, which is primary used for billing purposes and maybe legal stuff, and which is (usually) not presented to the end user. Tricky topic, as there are companies that spoof caller-ID this way and make people call back on expensive numbers. That is why operators are so scared about presenting any caller-ID, they might be afraid of being liable for these fraud cases.

Ehh... actually I have some experience with that from a previous project. Problem is, we gotta support that! I agree, it is extremly flexible, but it also means that you have to deal with endless loops, stack overflows, in other words with the programming language comes the debugger. The next thing is VoiceXML. Out intention was to create a PBX that can be used by people who don't want to do programming, it should just cover 95 % of the cases which are out there. If you want to customize to a higher lever, you can still use an external VoiceXML processor and run the call there...

Is that a phone problem or a PBX problem? 2nd call coming in is usually a problem for the phone. Or is it the one-way media timeout because the call on hold is not being refreshed? I would say DTMF interference should be extremly unprobable.

You should receive a black one. They use a new SoC chip which was a major step regarding stability. If you receive a white one tell us and we'll take care about this. All new devices sold should be black.

There is a "mailbox escape account" (see http://wiki.pbxnsip.com/index.php/Extension#Redirection) that should do that job.

You mean from any external number? Or just numbers that are listed as cell phone in an extension?

There is a settings called "Offer Camp On" in the admin settings. This will turn this feature off. You mean the clients prefer to hear music on hold while the other side is talking talking talking talking? What if it takes 5 minutes, 10 minutes, one hour?

Well if the router creates a NAT binding, it is supposed to keep that binding when there is traffic on that binding. When it drops the binding, and during that time the PBX sends a request to the old binding port, the request will not be forwarded to the phone. This creates a blind spot. We have seen routers that have exactly 32 entries for NAT. If you open the binding 33, then it just drops binding 1. This especially happens when a PC behind that router does some kind of activity, practically kicking out SIP during that time. If you see the log message in the PBX, you should check if the router is responsible for that. If you have several routers in operation, it should be easy to check the model and maybe easy to isolate the router that is causing this kind of problem. The ugly thing is that is works fine most of the time and it is extremly difficult to find out why devices are offline from time to time. That is why we put that log in. BTW The same applies to changing IP addresses. Service providers in Asia now start to change/recycle IP addresses every 4 (four!) hours because if the address shortages there. I think everybody understands that this is not increasing the registration stability. Bye bye, NAT. Here you go, IPv6!

This is a serious message because the NAT router is not really ready for VoIP. There are some routers on the market that change the port during re-registration, leaving a blind spot for the reachability for the registered device. In the above case, the registration changes every 90 seconds - don't be surprised if calling that phone will result in random call drops.

So did you read http://wiki.pbxnsip.com/index.php/Installing_in_Linux? Be careful copying the script, copy & paste is sometimes tricky... Windows XP is fine, you can also use it.

Check the spool directory, there is probably an old email lingering. Just delete the file...