Vodia PBX

There is something on the Wiki http://wiki.pbxnsip.com/index.php/SonicWall, a little bit outdated maybe. Maybe a time to update it and check what the latest versions are.

The mediation server is like a PSTN gateway. That means the PBX does not register there, the trust is based on IP addresses (which is not very safe compared to Digest). It is a little bit "workaround", but people were able to get it working that way. Of course, registering natively is much easier. That is why we are working on it....

Unfortunately, OCS does not support the standard SIP authentication scheme (which is Digest). They only support NTLM and Kerberos. Microsoft recently published the specification for NTLM, so that technically we would be able to register there. However, we still need to program it... That will defintevely not be in version 2.1 of the PBX. The workaround today is to use the mediation server. Maybe Microsoft can come up with a service pack which adds Digest authentication. A lot of SIP-compliant vendors would appreciate it.

Yea, it is a new topic. We have something on http://wiki.pbxnsip.com/index.php/Office_C...ications_Server, maybe it helps get get started.

2.1.7 will contain only bug fixes, nothing major yet. We'll do release notes when it is ready. 2.1.6.2450 seems to be pretty stable so far.

Check out http://wiki.pbxnsip.com/index.php/Office_w...ic_IP_addresses. Bottom line: If you want something stable, get a public IP address... Also http://wiki.pbxnsip.com/index.php/One-way_Audio might be interesting in this case.

Okay, seems that was really a bug. The timeout for pressing a key kicked in in the 2nd auto attendant. We'll put it into a 2.1.7 version. IMHO not a reason to release it yet, we are still collecting more things.

I am not aware of multicast support from Polycom. 20 is a lot. Are overhead speakers an option?

Did you turn the flag in the extension on that tell the PBX to "Send email on status changes"?

Sure, unicast paging is a CPU- and bandwidth-killer. That's why we offer also multicast paging. I would say keep the unicast groups smaller than 10 extensions, preferrably smaller than 5. Otherwise you are just stressing the system so much that ongoing calls might suffer.

This pattern has the problem that the 2nd pattern group will be in the replacement parameter \2. You probably want "(1[0-9]{10}|[0-9]{10})@.*". There is a closing bracket missing. You can also try 1xxxxxxxxxxx|xxxxxxxxxxx. ERE are fun. If possible stay with the simplified patterns...

I see two things that could be the problem here: 1. There is a nother process occupying the SIP port. Use "netstat -abn" to find out which process is listening on port 5060. Use the task manager to find out what process is using the PID that you see in netstat. 2. For some reason, the domain name "localhost" is not there any more and the domain "192.168.26.130" does not exist. Then the PBX rejects the request.

Yea. The problem is that the OCS has it's own way here... For non-OCS trunks you of course would not set it. At the moment it is something that just cannot be changed. At least I don't know how.

Did you change anything? Are you using a ITSP? Maybe they changed something?

Well, it can happen that one way is RTP passthrough and the other side is codec-aware. No reason for concern.

Did you see the Wiki article on OCS? http://wiki.pbxnsip.com/index.php/Office_C...ications_Server should help you to get the mediation server working. The rest should be no big issue.

Well, then the ITSP may want to see the number in a different way. What about trying out the few modes (RFC 3325, None, Remote-Party-ID)? Usually one of them gives usable results.

Question: Do you use direct trunks between the two offices? Then the OCS-related settings should have no effect.

No, this is the "Parameter 2". It is in the registrations tab of the extension. Using the tel: alias is problematic because then different users cannot share the same outgoing identity.

That is correct, a trunk does not have a call limitation. You need another trunk only if you want to talk to another destination, for example another PSTN gateway or another SIP provider. Check the Wiki - http://wiki.pbxnsip.com/index.php/Domain_A...stration#Trunks If you are using callcentric, I would definitevely have one trunk per domain. That trunk will be used for inbound and outbound calls. That keeps things simple. They all have their own DID number, and you even get bills for every domain. The cost for the SIP trunks is not outrageous, and IMHO it is worth it. Some phones support a "sidecar" (Polycom, snom) that can be used for monitoring extensions. We are also working on a "pbxnsip attendant console" (PAC), which is a piece of software that runs on the attendants PC - but this is only in testing phase yet.

In SuSE, you can use "/sbin/chkconfig --add pbxnsip" to set the links automatically (pbxnsip being the file that you put in /etc/init.d). After the process runs, you must configure the firewall to allow the ports that you want to use (e.g. 5060, 49152-65535).

Fortunately, the trunks are "virtual", that means there is no limit on how many calls you can have on that trunk. I think an important question here is if you register the trunk or use the gateway mode. Depending on that, you might want to choose different strategies. Everything stays in the domain. The admin can see what is going on in the domain - but not outside of the domain.

That AA is on another system, right? The problem was that the AA#2 gets started with DMTF already coming in, and it happily picks that up?

Yes I think having the outbound proxy set on the trunk is extremly useful. You can just set it to the IP address of the other PBX, which is your destination.

Priority: something low enough so that the other entries are processed later Trunk: That would be "AtoB" Pattern: E.g. 6141236543 Replacement: That can be left empty.