Vodia PBX

If you are using the auto attendant then you can set the hangup time to a relatively short time, so that the PBX hangs up relatively quickly. Yea, I love digital lines. Analog is just so much pain.

I believe that feature was a feature of the new Polycom firmware. There is in the XML file something called "call.directedCallPickupString", which is set to the pickup code of the PBX. What you can do: 1. Clear the pickup code from the feature code page; at least during the provisioning 2. Manually configure the Polycom device and take the code out (based on the generated filed) 3. Work on the permissions of the accounts and define who is allowed to pick up calls from where. 4. Or use the Polycom provisioning template (polycom_sip.xml, as support for that file), put it into the html directory and set the "directedCallPickupString" to "" in the XML file.

That is a sign that the registration must be pretty instable. I would tend to change his router (at home or where ever the phone is). There are some routers that are just not suitable for VoIP. Playing with the UDP duration will have a lot of side effects for all other users and if the problem affects just one user then I would not touch this setting.

This is the latest in version 3. login.htm

That is something you should look into. It seems that the routing table on the operating system level has no route to that IP address. This is pretty serious and could be the reason for the problem. Dai Chen!

Intercom from the outside? Hmm... You can dial star codes from your mailbox. So if you can make it into the main menu of your mailbox, then you can dial the star code for intercom and the extension.

Oh, okay. No, I was not aware it was a logging (CDR) issue. What you see in the web interface are the From/To headers of the call. The auto attendant changes the from/to headers when you place a call to an extension, so that it looks like the call originally went to that extension. "Supposed to be a feature", but I agree it is not very systematically. The CDR record (see the XML file in the cdr directory) contains more detailed information. There you would find the information that you need where exactly the call went to. If you are sending the CDR out (in whatever way) you can transport that information. Are you using SOAP, CSV file or some other mechanism to send the CDR from the PBX? Maybe then the problem can be addressed easily.

Usually such SIP ALG doing more trouble than they help. I would turn it off and just use the SBC of the PBX to solve the problem. A proper NAT implementation (even will symmetrical NAT) is no problem for the PBX.

I remember some time ago we had that question already. An I remember there was not simple answer for this. What you can try is turning off services and see one by one if the system is still running. But IMHO I would just do a minimal fresh install and then install the PBX. The important information is that the PBX does not explicitly need any service running - only the networking subsystem must be up and running.

Oh, don't use static IP addresses. Sooner or later you'll have an IP address conflict; and that is very messy (difficult to troubleshoot). Windows XP has a DHCP server included in the server editions; and AFAIK that is pretty stable...

By default, you have to tell the PBX each account on each message. If you want to create a group we would have to add functionality, e.g. (ab)use the hunt group for that. So I assume you want to send one IM to the PBX and you expect that it "explodes" it to a list?

Now we can pull the destination out of the Request-URI. Now the rules in http://wiki.pbxnsip.com/index.php/Inbound_Calls_on_Trunk apply. You can now also just assign an alias name to the extension, and then the PBX will send the call to the right destination. Progress is not success, I agree.

The home user should use hot desking to make the family's life easier. Otherwise if the phone always rings in the office and at home at the same time, people at home get nuts... The TSP uses a proprietary method (still based on SIP) to talk to the PBX. That makes it easy to use the TSP both in the office and also from home. At the moment click to dial works only if there is a registration. A better integration with the cell phone will come in 4.0, so that you can also click to call the cell phone.

In this case just drop the attached file into the html directory (make it if it does not exist yet) and edit it as you like. snom_3xx_phone.xml

Using the software without a license is illegal. Of course it is easy to crack the license. But if a VAR installs the software for a customer and the customer later finds out the VAR sold him a crack version, that VAR is in trouble. Especially the case with the USB license key concerns me. If the USB stick gets lost, it is a big problem for the one who is running the service. I have no problem giving them lets say a week to fix it. But how would you notice the admin? If he logs into the web interface, a huge warning is no problem. But what if not? Sending out emails? What if he does not set up email or does not read it? MAC addresses do not just disappear. This case is not critical.

If you get something else that "anonymous" then that's progress. Maybe you can just post the INVITE message that the PSTN gateway sends to the PBX, and then we should get close!

Well if you have only two CO-lines on that trunk a third call is going to be rejected by the PBX. That is a feature! check the trunk settings and consider adding more CO-lines. (Edit "trunk page->CO Lines" field)

http://pbxnsip.com/cs410/update-4.0.0.3204.tgz (beta!!!)

I would use a calling card account for that. Then you could set up a bogus calling card with maybe two digits and a PIN of two digits and you would have the same effect. However, for this solution you would have to get the 800 number somehow in the INVITE. Otherwise you have no chance to cut the 800-traffic off from the general incoming calls.

Hmm. Interesting idea. You should be able to barge into the call, which would be an interesting experience because all others would be able to hear the conversation as well... The simple workaround is to call the extension and then establish a regular call. The advantage of SIP is here that call waiting is no problem and the SIP handset usually can easily switch to another call.

In principle, there is no hardcoded limit in the PBX. Everything is nicely arranged in maps and lists. So you will be able to send 400 or 4000 IM messages. The only concern is bandwidth. When those little packets walk out of the server there will be a major network hickup. If that's okay, 400 IM messages are fine.

Usually Ethernet runs only 100 meters AFAIK.

Well, it means which extension has the permission to see (for example, on the LED button) what calls this extension has. For example, does a regualer employee has the permission to see the calls of the boss? Probably not. So the boss would put something there like only the extension of the secretary "100" if that is the secretary's extension.

Eh... Multiple area codes per domain? Then you must leave the area code field empty; and that also means you loose the value of that field. You can strip the last seven digits out of the Request-URI or To-header of the request in the trunk. For example, when you put something like "!([0-9]{7}$)!\1" into the setting "Send call to extension" of the trunk, then the other digits are ignored on inbound calls. Check the XML files in the user_alias directory if they have the right alias name. It will work if you don't use the country code; it might also work if you don't put in an area code while creating new accounts.

You can put * into the extensions that cannot be dialled; then the PBX stays silent until a timeout and says this extension number does not exist. IMHO that is absolutely reasonable. The timeout is neccessary because customers don't want "directory attacks" where callers try to find out what extensions exist on the PBX. Sorry, but pound has the meaning of "enter, confirm". If we allow that this becomes a direct destination, this will screw a lot of stuff up; and I believe that this would make it confusing the the caller...