Vodia PBX

First of all, you should always make a backup; escpecially before upgrading the system. I believe this upgrade should be smooth. IMHO no big hickups this time. The release notes are here: https://www.pbxnsipsupport.com/index.php?_m...kbarticleid=658

Okay... The problem is that the loopback does not have a explicit trunk so the PBX sticks to the domain name style. The alternative is that we hard code the global number style.

I don't think that the trunk got legs... Haha The only thing I can imagine is that something in the web interface got screwed up and when hitting the save button on the trunk there was a domain variable dangling. For example, when hitting the back button on the web browser that would be a good explanation. Of course it would be perfect to know what exactly caused it.

Not sure if https://www.pbxnsipsupport.com/index.php?_m...kbarticleid=326 helps. Maybe we need a more elaborate example.

The XML file in the trunks folder. What is the "domain" there? Is that the domain which is in the "domains" folder?

Can you check what is in the XML file on the file system? The question is if we have a problem in the web interface or the trunk really moved. Does this also happen when you log in as domain administrator?

Keep in mind that the PBX now converts the number into the respective country code format. If the area code it set, it takes it out if the dialled number is the same.

The old wiki is still online at kiwi.pbxnsip.com

Make sure that anything called "SIP ALG" or "UPnP" is turned off on the router. Or use TLS to tunnel through the router that might mess with the SIP packets. I also used a netgear but had no problems. I guess the models are changing quickly, so I am not sure if that helps. Check if you see the 180 response on the PBX (SIP logging). Last resort would be to use Wireshark on the PBX to see what the PBX receives.

Did you try "If the caller already waited longer than (s) ... redirect to the destination (e.g. "73") ..."?

The caller has to be waiting (i.e. hear music on hold) for that time. So maybe try having two callers going into the queue with one agent, let the first one talk for a long time so that the second one has to wait. Then the redirect should pull him out and some him to the programmed destination.

That was something which was fixed in version 3.4 (the one that was released).

For that you can use the dial plans. Just create another dial plan that restricts long distance, and assign it to the specific extension(s).

Whow. Maybe there was something wrong with the registration on the phone. Did you use the outbound proxy on the phone? Or maybe it is a problem that the extension name is not a number.

That is a simple question, but the answer is complex. The PBX tries to avoid translating from one codec to another ("transcoding"). However, there are situations where this becomes neccessary, for example, when both sides have no common codec, when music on hold needs to be played, when the mailbox needs to render prompts, when the agent group mixes the annoucements with the music. For regular calls, most of the time the PBX can avoid transcoding, however when the user presses the hold button the coder needs to be activated. So you need to see this from a statistical point of view. Hopefully not all of your users press the hold button at the same time! Otherwise, you need to statically define how many calls your system will accept.

Check out wiki.pbxnsip.com. This is a good starting point.

Generally speaking, VLAN should always be used. It just makes sure than the voice infrastructure does not get interrupted for example if someone accidentially puts another DHCP server into the network and another device starts randomly packets that fills up the bandwidth. VLAN with a priority are a nice way to rule such simple network interruptions out. The downside is that this is more work. Especially the provisioning becomes more difficult, especially if after a factory reset the phones get back into VLAN 0. And you have to set up a route from the VLAN into the regular LAN (if you want to be able to access the web interface of the phone) or from the VLAN into the internet if you want to make phone calls over the Internet. You can have the PBX running in different VLAN with different IP addresses. This is very useful because you can have the user access the web interface from the regular VLAN 0 and you can have the phones access the PBX from the voice VLAN. So if your priority is rock solid setup, I would recommend a VLAN.

Did you try multicast PnP? There is a chance that this automatically upgrades to version 7.

Could you be a little bit more specific? Where do you want to display the caller-ID and extension number? Where should the program be running? On the server or on the client (JavaScript)?

909 is not a SIP response code. SIP is only between 100 and 599. I guess there must be something with the base.

You can turn call waiting off on the phone, that should pretty much do what the client wants. We could split the "Lines" up into inbound and outbound lines. However, I would say this will be a version 4 feature.

Okay, that is pretty systematic What flags did you set up for recording? Remeber that you can overrride the domain settings per extension. BTW what version?

If the phone does not register there must be something going on. A couple of reboot cycles is okay to fetch the firmware that has been set up on the PBX (make sure that you are not running version 6 on the phones!!!). But then it should be registered. If not - at least we can say it has nothing to do with the multicast. I would focus on finding out why the phones are not registered.

I would say we can rule out file system space limitations... Any more clue what makes the difference between a regular call and a call not being recorded? The size? Can we exclude that someone accidentially (or intentionally!) removed the file?

Well, SIP has it's own way of dealing with call waiting. Because there is no more "line" SIP wants to leave the decision about call waiting to the phone. It is debatable. I agree with you that the caller perception is not good right now. We need to keep that in mind. Calling a busy person multiple times is a productivity killer, it would be good to get better assistance from the PBX in this case. At least we are able to emulate the physical line pretty well, talking about the one call limitation!