Vodia PBX

The 1.5 version also offers SRTP even when a insecure transport layer is being used. But there is a flag in the admin settings that says "offer secure calls" or so at the bottom of the admin settings, try turning it off. Then you should not see the SRTP keys in the SDP of the INVITE message any more.

That would be very difficult - a SIP phone does not send a notify to the PBX when it goes offhook.

Plus it is very simple to implement!

Check out http://www.pbxnsip.com/software, http://www.pbxnsip.com/download/pbxctrl-suse10-2.1.0.2115 should be available!

Eehhm... Multiple domains are a complex topic. If this is your first installation, I would recommend to use only one domain and get some experience first. Also, check out http://wiki.pbxnsip.com/index.php/Log_Access for the logging issue. See www.wireshark.org for a tool that helps you find out whats going on.

I think then the best is to take a look at a Wireshark trace or at least at the SIP trace of the involved user agents.

Is that phone registed in the same LAN?

In 2.1, there is a "night service" with the name #l (pound L) that acts like a service flag when all agents are logged out. See http://wiki.pbxnsip.com/index.php/Agent_Group#Night_Service.

That sounds like SRTP trouble. What versions are you using?

No it seems to be fine on the PBX as far as we can tell... In the real world the problem is that the support from PSTN gateways is very poor for the RFC.

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