Vodia PBX

Did you try $r/recs/$d/rec-$t-$i-$u-$n.wav? If you link the recs directory to another hard drive, then the server will write it in the other location. In Linux that would be a symbolic link, not sure on Windows.

VPN on a phone is a difficult topic... It is very useful if your SIP infrastructure does not support application layer security. The good thing about pbxnsip is that TLS and SRTP already keep your voice pretty private. I think it is much easier to go this way.

Looks like we can change the NTP strategy now. If Linux has a time, then there is no need to do big changes in the PBX any more. We will just check for time drifts as the internal clock is not very precise.

Oh there is a change in the setting "Explicit Remote Party-ID" (which is now DID): http://wiki.pbxnsip.com/index.php/Outbound...Remote-Party-ID. Maybe you need to change that setting.

Well, the original problem is how to present numbers in a "canonical" format on you server. There are different conflicting styles: 1xxxxxxxxxx, xxxxxxxxxx, and +1xxxxxxxxxx. In the end, the PBX must make a string comparison to get a match. Ideally, all connected devices talk the same way. The dial plan "workaround" puts NANPA numbers into a internal canonical format, so that the comparison works. If you are living outside of the NANPA there is no other choice than getting all connected trunks straight.

ACK. This is something we need to look into.

Okay, sorry if the response was not very clear. The 7.2 version had a feature called buttons (see http://wiki.pbxnsip.com/index.php/Assigning_Buttons), and because 7.2 is still not out snom put the support for buttons also in version 7.1. Therefore, there is no more need to wait until 7.2 is out. 7.1 is also fine now.

You can use the dial plan to block certian numbers (see http://wiki.pbxnsip.com/index.php/Dial_Plan). Just select the "Not Allowed" option in the dial plan.

Well, that is a famous problem. Check if your service provider or gateway supports RFC3325 - that is the standard that can be used to indicate the original caller-ID.

Rebooting the PBX is not an option... To track this problem down, maybe you can set the log so that the PBX watches the IP address of the phone and writes only those messages into the LOG - then it should be possible to see if hte NOTIFY to the phone still make sense. What version are you using on the phone?

Maybe there is a matching problem with the leading 1 (in NANPA area). Check the dialplan scheme of the domains.

At the moment I don't see a need for that - 7.1.x seems to do everything that we can dream of...

Well, UDP packets have a maximum size. In Ethernet networks, thqat is usually 1492 bytes. If the packet gets bigger, the lower networking layers split the packet up into several packets, that is called UDP fragmentation. Unfortunately, the support from embedded operating systems for this feature is poor. Therefore, if you try to send a message longer than this magic number, you might get only the first fragment of it - and the rest missing. Maybe you can try to use TCP layer (see http://www.polycom.com/common/documents/su...39;s_guide.pdf). If you are running version 2.1, you can automatically provision TCP transport layer by using the below settings:

Well, this is the dust cloud around the caller-ID presentation when doing an external call. It looks like it would be a good idea to use the original number also when the call gets diverted (even if internally). If you like, please try the following build (raw executable): http://www.pbxnsip.com/download/pbxctrl-2.2.0.2415.exe.

As far as I know Polycom does not support the Reason header yet: CANCEL sip:42@192.168.9.227 SIP/2.0 Via: SIP/2.0/UDP 192.168.0.206:5060;branch=z9hG4bK-3c72e22ec1814c8612b6c6085db54721;rport From: "Hunt Group (41)" <sip:41@localhost>;tag=39657 To: <sip:72@localhost> Call-ID: 7898709d@pbx CSeq: 20811 CANCEL Max-Forwards: 70 Reason: SIP;cause=200;text="Call completed elsewhere" Content-Length: 0 Answer: SIP/2.0 487 Request Cancelled Via: SIP/2.0/UDP 192.168.0.206:5060;branch=z9hG4bK-3c72e22ec1814c8612b6c6085db54721;rport From: "Hunt Group (41)" <sip:41@localhost>;tag=39657 To: <sip:72@localhost>;tag=F833CB16-42D3D563 CSeq: 20811 INVITE Call-ID: 7898709d@pbx Contact: <sip:42@192.168.9.227> User-Agent: PolycomSoundPointIP-SPIP_550-UA/2.2.0.0047 Content-Length: 0

Well, this setting is neccessary to tell the PBX which dial plan to use (and which acconut to charge) for a call that is initiated by that trunk. Background is Exchange, because that does do that.

Okay, let me try to understand: You are calling the AA, punch in the number of the extension and then the pbx starts the timer and starts saying "calling extension this-is-a-very-long-name-please-wait-a-while"? If that is the case, would it be a workaround to set up a specific redirection time for that account?

In 2.1 - yes. Take a look at the spool directory, there the PBX puts everything that needs to be sent out. It even survives a restart of the service. The file system is something beautiful!

Anything from Wireshark? This is how it looks when the firewall blocks the traffic. Looking at the cable should be able to tell if the computer really tries to open a TCP connection to that location.

Maybe you can use the dial plan's feature to send a call to a registered extension? http://wiki.pbxnsip.com/index.php/Dial_Plan

I think the trick here is that the new logo must be located in the html/img directory.

After changing the port you need to restart the service. You can use the netstat command to see what ports the PBX really uses.

I guess we have to look at OCS in more detail. Just adding a feature here and there is not a good strategy. CSTA is not trivial, and it will take months to get it stable. Therefore I would not count on it. TAPI could be a workaround, there is a lot of TAPI stuff available. But I have no overview if there is soemthing that could convert CSTA into TAPI!

You can add a static registration in the registrations tab of the extension. Maybe that solves the problem?

We could give you a beta image...