Vodia PBX

Not completely impossible; but we don't provide the front end for the VLAN configuration from the web interface. You would have to use the standard Debian Linux setup. I am not even sure if vconfig is on the file system. Many managed switches are able to retag the traffic on specifc Ethernet trunks. That might be a workaround.

That's okay if you turn the loopback detection off. This is just a notification that there is a loopback request that needs to be processed. Do you have a trunk that has the outbound proxy set to the SIP proxy? Seems the PBX has problems identifying the source of the request. Make sure that this trunk also accepts inbound calls.

Well, well... It seems that you first have to dial a star code on the FXO line and then the number. This is almost two-stage dialling. IMHO the best solution would be if the gateway somehow can deal with the blocking. In theory, the SIP trunk should not know about the details of the termination. I am not a Sangoma expert; maybe it is worth studying the documentation there to see if there is a way to block the caller-ID.

One mailbox for 4 accounts will cause the problems with the MWI and SIP devices. That's why we have one mailbox for each SIP account...

Well, there was already a setting that allowed "sharing" of the mailbox. Previously that was only about the access to the mailbox. Now that setting is used to copy a new message into the mailbox of the listed accounts. The key point here is that one of these persons is saving or deleting the message, that is copied to all other messages as well. For hunt groups, you currently still need to have another extension mailbox handle the group messages. The step to incorporate the mailbox into the hunt group has not been done yet.

The best solution for large system is to use a SIP proxy to route the calls between the domains and the other destinations. The dial plan will then become pretty simple--just send everything to the proxy. The proxy then has to make the decision if the call should be routed to a PBX or to the PSTN gateway (whatever that is). In this setup, you need to turn off loopback detection; because it is perfectly legal that one domain calls another on the same system.

Don't use those settings. Just use the "buttons" in the domain or for the extensions. And you must use PnP with the snom phones if you want to get that working properly.

That is definitevely the best way to address the problem. The loopback is just a "hack" to get small systems working where the usage of a external SIP proxy is not feasable. So do you have a problem with the loop detection? Does the PBX detect a loop when it should not?

snom 820 does it (up to 5 participants).

I believe in version 4 it is done.

There must be something that stresses the system badly. Did you check if there is a lot of HTTP traffic? How many threads and Handles does the process have? Maybe you can send us a PM with RemoteDesktop login so that we can take a look around what could be the problem.

What mode did you use on the trunk to indicate the Caller-ID? Maybe you can try "no indication" on the field "Remote Party/Privacy Indication".

It is somewhere on the list. There are two topics: one is the directory integration (address book); some SIP phones support that alredy and there is no need to do that from the PBX. The other topic is the automatic setup of accounts; this is a lot more complex and IMHO questionable if the PBX should automatically create accounts. Many questions remain, for example what extension number, what dial plan, plug and play. So even if the PBX set the account up automatically, there are still things the admin needs to set up manually.

Try to ping "192.168.200.203" from "216.52.221.144". Does that work? If not, it might explain why the media does not arrive at the PBX. Unless 216.52.221.144 has a session border functionality that can deal with non-routable IP addresses. You may try to enable the SBC functionality of the User-Agent "Cisco-SIPGateway/IOS-12.x", then it should be working fine. Also see https://www.pbxnsipsupport.com/index.php?_m...&ratetype=1.

If they are already registered, then the PBX does not deregister the phone. Only new registrations are rejected if you use the setting. BTW the max registrations setting is available on extension, domain and system level.

Good point. You would have to open a socket for each IP address that you want to use. For example, in the SIP UDP sockets you would write: "12.23.34.45:5060 12.23.34.46:5060 12.23.34.47:5060 12.23.34.48:5060". The PBX remembers what socket was used when receiving a packet and stays with that socket when sending the response.

That is definitely not okay. It also has nothing to do with the trunk. It would be interesting to see the SIP traffic between the PBX and the phone that does not stop ringing. Maybe you can filter the traffic (in the log section, SIP) by the IP address and attach it here (INVITE, CANCEL and the responses that have the same Call-ID).

Well, that means that the PBX could not find that extension. In a single domain environment no problem; just use the name "localhost". However for multiple domains a serious problem, as the Cisco phones seem to have a hard time to use DNS names in the registration. So far the workaround is to use a different IP address for each domain. If someone finds out how to make Cisco phones send DNS names, please let us know... Not sure what RFC "(null)" refers to...

Well. It would be better to get hands on it and see if the interop is okay before rolling this out.

Whow, mabe we need a spell checker in the name field!!!

I doubt that VPN adds latency. Yes, it might add bandwidth. But encrypting the packet does not mean you are adding latency. Only if you are using TCP-based VPN then the fact that lost packets have to be repeated will add significant delay.

You might want to check out the "PAC". I believe it does what you are looking for.

Whow I did not know that we can actually have this cool polling feature on the forum. BTW no need to poll, this is already part of 4.0.

You might use version 3.3? There was a bug in hot desking, you might ran into this one... https://www.pbxnsipsupport.com/index.php?_m...&ratetype=1

Yea, it is amazing that the Exchange (a great product) had a blackout on MWI. The way you are supposed to get the MWI is to poll the Exchange server through SOAP messages. IMHO that is a joke. Then if you actually know that there is a SIP account that has a MWI, then the next step is to tell the PBX about it. Here we go with the next SOAP message. Because pbxnsip also supports SOAP! But of course the two SOAP messages are totally unrelated. I really don't know... If someone can give me an example on how the SOAP messages to Exchange look like it is probably easier to do the SOAP natively in pbxnsip than to use 3rd party software (which is sometimes even more expensive than the IP-PBX!). The Exchange team would everyone do a favor by using the well-established RFC for MWI.