Vodia PBX

The pbxnsip shared lines implicity lock the call to the seized line on the trunk, that is obviously not what you want. Park orbits may be something you want to use instead, they look similar and small groups can still transfer calls with one button push.

Well check with whereever you got the key from what they can do to have a happy customer.

Looks like you are using "STUN" on the phone. That is not good/neccessary, the PBX takes care about devices behind NAT. You should also use TLS as transport layer so that the traffic can get encrypted. Probably the best way is just to automatically provision the phone. But anyway, this is not the problem here. Possible reasons for "403 Forbidden": You set the IP address in the extension settings ("Trusted IP Addresses" in the extension/registration settings) The From- and To-domain are not the same (should not be the problem here) If you try to subscribe to dialog, the endpoint must have the permission for hat (not the case here because you try to register) So my guess is the first one; clear the trusted IP addresses and try again.

When a user dials a number, the PBX has to convert the number into a canonical format. Otherwise, you would for example always have to deal with the problem that the user dials 00321234 or 01234 (area code makes even more cases possible). In the dial plan, you have to deal only with one representation. The representaion is the "local" representation, that means the country code (with the 00 prefix) is only used when neccessary and the area code also only used when neccessary. If you want to use a country code but dont want to use the area code, you can use "-" as the area code. On log level 9 you should see something like "Dialplan: Evaluating so-and-so against so-and-so" (Log IVR events). There are several stages when the PBX needs to convert numbers. The first step is when the call comes in to the PBX (into a global format starting with +), then when it hits the dialplan and finally when it hits the trunk into the format that the service provider would like to see.

Try to simplify the setup, for example by taking the phone into the same LAN where the PBX is. Once that you got a situation where it works you can step-by-step change the setup back to the situation where problem is, then usually there is a big aha-effect. We have seen it many time where there are firewalls in the game, that is why my proposal is to take it out temporatily of the equation.

That is probably because you have the country code set, but not the area code. You can try to use the area code "-" to suppress this message. Then the PBX will convert it into something like +3220495****** (for Belgium). Then in the dial plan you would have to match 00322* instead of 2* (00 is used in ROW for the + symbol). If you dont like the reformatting according to the country code at all, you can of course take it out. But I think it is better to keep it and change the dialplan accordingly. You should see in the log what number the PBX is actually matching. But I guess there is a confusion going on with the country code replacement algorithm.

Sounds like there is a limitation from the license key. Search for "base64 decoder" in the Internet and feed it the license key. Then you can see if the key contains a limitation on the number of calls that you can have on the system.

Well, there are several possibilites on snom phones to implement shared lines. The one above is not the one that the PBX is using. The PBX uses buttons for shared lines. What you can do is clear the settings for the "fkeys" and reprovision the phones. Then you can be sure it is not using the pbxnsip shared lines.

You can see the calls in the web interface. If you check the agent group settings, you can say who will be allowed to the the queue status; then those guys can log into the web interface (as user) and there is a JavaScript that shows the calls in the queue. There are some star codes for supervision, like call barge in, teaching mode, and listen mode. You can also set a rule to record all calls in a group. And the PBX supports popular CSTA commands, so that you might use third party tools, for example for outbound dialling. However make no mistake, a product like the PBX cannot be a replacement for a 200K+ system that you get from a call center specialist. The focus is more on additional functions for regular companies that have support or sales teams and which want to line up incoming calls for proper processing.

Quick questions: Are you using the outbound proxy on the trunks? Possibly also specify the associated addresses (for explicit inbound routing). The old wiki did not have the inbound routing setting, so that might be making a difference. Also, the log (log level 9) can be very interesting when the PBX wants to make decisions where to route the call. Usually it log what trunk it identified and where it wants to send the call.

In the first versions there was actually a possiblity to transfer inside the PBX. However, it was heavily violating the sandbox idea that we have with the domains; so it got "fixed" and transfer is not possible any more between domains. That means you need to think about another domain like someone on the PSTN. So if you want to transfer a call into another domain, you would have to call the DID number (looping it back through the PBX, possibly through a SIP proxy) and then you can connect those two calls. The PBX will then send RTP to itself (probably through the loopback device), and there will be seperate calls showing up in the call log.

Well, that is actually a long topic. We actually had someone on board who was almost deaf, and learned a lot about this topic. There is a RFC out there that specifies how RTP should be able to send text messages instead of voice. We dont support it yet; and I am not sure if there is any equipment out there that supports it. As far as regular equipment is concerned, the problem is mostly the support for modem connections (like in fax). As soon as packets get lots, those connections also drop out or at least run into serious problems. There is a solution for fax (T.38) but for general modem I am not aware about a solution yet. The good news for deaf people is that there is a general trend to support messaging a lot more (SMS and IM), so that the old TTY equipment can be replaced with up-to-date stuff like color-display cell phones and PC.

Can you get the SIP packets between that are exchanged on the trunk? Then we can take a look what is going wrong.

We have seens strange effects that the first xx phones worked more or less fine and then more phones were behaving erratic because the number of ports on the firewall was exhausted. Firewalls are a frequent source for trouble, that's why it does make sense to rule this out. if you are using the same firmware build on the different devices, they pretty much behave the same way on the network side; that's why I recommend to search also in other areas.

Did you enable the multicast (admin/settings/listen to sip.mcast.net)? You can check with "netsh interface ip show joins" if the PBX listens to the sip-mcast.net address, which is 224.0.1.75.

Try putting them in the same LAN to rule out that you have a firewall issue... Firewalls can be tricky beasts, so I would 100 % make sure that the network setup is not the problem.

There is a setting in the agent group that defines what the PBX should put into the "From" header. Are those setting going into the right direction? You may add more if you need.

Right now that is the way it is. With snom blue you can have up to ten third-party registrations, with yellow up to four. If you need more, considering the good old pbxnsip license which does not know the concept of third-party registration.

Just manually edit the pbx.xml file. And wait a little bit after stopping the service like 60 seconds, because the OS might need to flush the pending traffic on the socket (the PBX requests exclusive access to it). Also check other ports like 389 (LDAP!), 80, 443, 5060 and 5061.

Mysterious. Maybe you can ZIP the configuration and give it to us, then we can try to reproduce it here.

We have another discussion right now about mysterious things with the dial plan where we suspect that the phone seizes a specific trunk before placing the call. That would also affect the failover. Maybe you can check if it makes a different to use a factory-reset phone that does not use plug and play (manually set the identity information) or a softphone?

Timeout is not timeout (a lesson that we also had to learn...). The SIP trunk does not listen to 408 responses that might have been generated on the SIP transaction layer. Instead, it sets it's own timer and clears it when it receives a code >= 180 from the trunk. These are two different things because otherwise the transaction layer gets screwed up. Anyway, you should use the settings in the trunk for failover. For the timeout it does not matter if you include busy or not. But you should set the delay that the PBX should wait before it starts the failover (dont make it too short, it might take a few seconds before the trunk can send you a session progress).

Some old firmware version of snom phones also were causing this issue. Maybe during the upgrade they were upgraded as well, silently solving this problem.

A good starting point would be clear documentation... I agree having each and everyone fiddle with the parameters is not efficient for us all.

Well, are you using shared lines on the phones? Or did you use it before (maybe the configuration is still present on the phone)? This would explain such strange behavior: First the phone seizes the line on the on-Exchange trunk and then when it dials the number the PBX actually keeps the promise and looks only at those entries of the dial plan that have this trunk as the destination.