Vodia PBX

You can use something like this in the outbound proxy: For UDP: 192.168.1.2:5060 For TCP: 192.168.1.2:5060;transport=tcp For TLS: 192.168.1.2:5061;transport=tls The plug and play files are really hard coded to TLS. Try to mode to 6.5.10, which seems to work stable. If you have unstable Internet connection, you might have problems, as the snom re-register very slowly after loosing the registration.

Are you using the "extension" mode in the function keys of the snoms?

Take a look at http://wiki.pbxnsip.com/index.php/Office_w...ic_IP_addresses, it should cover this topic. 2.0.4 will contain two more features that make this setup easier. The first one allows to have several IP addresses on one NIC (Windows only, sorry) and the second one allows to use NAT for DMZ. Then the PBX can have a private IP address behind NAT - however it must still be clear on what IP address requests are being routed and if the configuration uses IP addresses in the same subnet things get tricky. Therefore it is still better to use one public and one or more private IP address.

Agree. We need to work on telling people what features we have, otherwise they are of no value. Did anybody see http://www.pbxnsip.com/download/flyer070522.pdf?

You can also do many tasks with regular shell scripts that behave like a user accessing the web interface: http://wiki.pbxnsip.com/index.php/Shell_Scripts

Right. When you call a hunt group the PBX will not call the cell phone. We believe that this would cause a major chaos in most installations. Only direct calls to the extensions make the cell phone ring.

We will include the email files in the next version. Check out http://www.pbxnsip.com/download/email_203.tgz and http://www.pbxnsip.com/download/email_203.zip for timebeing.

WOW. Respect!

We do that on the CS410. But in Windows so far not. You can buy overhead speakers, e.g. CyberData. Those are very simple to integrate.

"Also, from our experience dynamic IP addresses will cause a lot of random instability and problem searching." SIP is not HTTP...

Do you want to write something up for the Wiki?

You can use Dialogic cards. There are rumors that Sangoma also comes out with a SIP-capable software API for their cards, but we have not seen anything working yet. There are tons of external gateways available in all price categories.

I don't think that the Xlite is the problem here. It would be interesting to see what the IVR answeres in the 200 Ok, especially the SDP. It should indicate what codec it is using as RFC2833.

Well, first of all check out http://wiki.pbxnsip.com/index.php/Office_w...ic_IP_addresses and http://wiki.pbxnsip.com/index.php/Troubles..._Trunk_Problems. Also, from our experience dynamic IP addresses will cause a lot of random instability and problem searching. When the IP address changes you will have "blind spots" where the PBX is not connected to the remote phones. Also, we learned that our ISP likes to do service windows at times when we didn't expect it. Needless to say, that if the ISP does not support QoS routing and/or does not use a session border controller, you will sooner or later end up with choppy audio. Our sad experience is that when an ISP also provides (TDM-based) telephony services, they have zero interest to respect QoS. Just setting expectation levels - you get what you pay for.

Overlap dialling and SIP - ouch... We know this problem very well. Cell phones work (the do not do overlap dialling), regular ISTN phones don't get through. But I believe you can still address the problem by using the whole number and then send it either directly to the extension or to an auto attendant.

Is this the first packet that the SPA sends? In T.38 the end point first needs to establish a G711 call and then after the fax tone detection switch to T.38.

There was a bug in the SRTP. Make sure that you either turn SRTP off or use version 2.0.3 on pbxnsip and 6.5.9 or higher on snom (see http://www.snom.com/wiki/index.php/Snom360.../Beta_Versions).

Well, in most countries is it quite normal that the From header contains something anonymous - typically if the caller does not want to reveal the identity. However in this case the To-header is "anonymous". I don't get the use-case here. Does the caller not want to say which number he wants to talk to? Maybe you can make the gateway send the whole "DID" number (don't strip the prefix) - then we are able to route it somehow. Might be a kind of workaround to get it working with the current version, then later we might have to think about routing calls without extension numbers.

In the end, only a PCAP trace (either from the phone or from the PBX) helps. snom phones support making PCAP traces right from the phone. Then we see if it gets media at all, and we can see if someone in the middle is blocking the traffic. There are also other possible problems like wrong SRTP MAC, which also result in one-way audio. The PCAP trace will help to hunt them down. A very simple way is also looking at the statistics in the BYE packets. Both the PBX and the snom phones sends a Rx/Tx statistics. You can match them and see if there must have been a significant packet loss. That would help to find the problem even without having PCAP traces. If we find the problem, we can later say if it was "trivial" or not :-))

One thing that you can check is if the route on the host is preferring the public interface. In Windows, the default is to use the fastest interface, no matter if it is using a public or private IP address. Also, you need to make sure that the port forwarding does not introduce NAT. The firewall should transparently forward the packets to the public interface.

Use the pattern E for this purpose (see http://wiki.pbxnsip.com/index.php/IVR_Node). For example: Put "!E!100!" into the DTMF match list to route a call to 100 after the end of the file has been reached.

Ehhhh.... I would say the PSTN gateway should know which number is being called. There must be something in the gateway that should be configured in order to do this. There is nothing like an "anonymous destination"... Alternatively, you can try the pattern "!(.*)!\1!t! 25" (see the space between the two party of this pattern). Then the PBX should route the call to 25 if the pattern resolution does not come up with a match.

Incoming calls on Telco1: Set in the "Extension" field of the trunk: "!(.*)!\1!u!25!" (see http://wiki.pbxnsip.com/index.php/Inbound_Calls_on_Trunk). If your operator sends the extension in the To-header, choose "!(.*)!\1!t!25!". Outgoing calls: Create two dial plans. Make Plan1 your default dial plan for the domain (http://wiki.pbxnsip.com/index.php/Domain_Settings#Default_Dial_Plan), and assign Plan2 to the fax extension. Both plans just use the star as the pattern (no replacement) and route to the Telco1 and Telco2, respectively (see http://wiki.pbxnsip.com/index.php/Dial_Plan). If you want, you can use a pattern like 0* as a prefix for the dial plan. However, my suggestion is not to use any prefixes. Just make the numbers diallable as they are - on a cell phone you also don't use a prefix to dial a number. That makes the address book much easier and you can call back missed calls.

The trunk may use STUN to allocate a public IP address. This is very unreliable, therefore we strongly recommend not to use this feature. However, there are stupid marketing people who believe that if that feature does not show up in the datasheet the product is inferior. We all know that this is bulls*** and STUN is just creating huge support problems. When an extension registers, it should just point the outbound proxy towards the PBX. On the snom phones, you can use even use TCP (or TLS) transport layer. Just use an outbound proxy like "sip:2.3.4.5:5060;transport=tcp". Then the NAT problems should also disappear, because even crappy routers support TCP connections. Of course, do not use STUN on the phones as well.

When a user receives a new voicemail, the PBX calls the users' cell phone and reads out the new message. Of course Caller-ID is not secure. That's why you must enter a PIN e.g. if you want to go to "your" mailbox or place an outbound call. A good reason to choose a different PIN than just "1234".