Vodia PBX

A large company out of California specified in the old days that the way to talk to the provisioning phones is tftp. Now we all have to live with that default decision. This is not what I would call NAT-friendly. There are plenty of other ways; but this is the default. You can also use HTTP, but then you need to manually tell that the phones and you need to specify the path from which the files need to be downloaded. If the server is behind NAT you will have a very hard time to get it working anyway. VoIP uses UDP for the media transport, and that is extremly NAT unfriendly. Practically speaking, you need a "routable" IP address--one that can be reached from all devices that indent to use the service. AKA known as "public" IP address (but it does not have to be public, e.g. in company VLAN, VPN and so on). If both the PBX and the phones are behind NAT things get (alomost) funny. "If you want to send me media, send it to 10.1.2.3"--"okay, and if you want to send me something send it to 192.168.1.2". Thank you! Fortunately, the last IPv4 address has just been assigned and hopefully soon the whole NAT madness will be over.

In the most simple scenario it looks like this: Run the PBX on public IP, have the tftp port set up, enter the address of the PBX in the "Setting URL" (or option 66) of the phone (snom 8xx or m9), start the phone and everything else goes automatic. The snom 3xx has no certificates built-in, thats why you need to enter the username/password there before the joy can begin. More complications arise when there are firewalls that are not TFTP friendly, PBX with wrong routing tables or no public IP at all, no TFTP port at all, and so on. We are already working on a new chapter in the admin manual that describes the steps on how to get PnP working in a safe way.

Thanks for the PCAP. It shows where the problem is: The PBX uses the standard mechanism for anti-DoS, which is to let the user wait for 5 seconds before answering a login request. There is no CPU spike. I guess we have to fix that in the next build.

The 1000 entries could be a problem, especially if the PBX has to perform a table scan. What you can do is run taskmgr, put it on fast update then hit the directory key a couple of times and see if one of the cores goes to 100 % load.

Well, you need to have a session and spaces must be properly URL-encoded.

Well, from the PBX this is kind of right. The first three stages are seen together from the hunt group perspective. The final stage is more like a call redirection stage. So first the phone misses the call from the hunt group and then later is misses the call from the redirection service... It is not so easy to solve, essentially we need to check if the missed call has the same Call-ID then ignore double entries...

The call log is all about trunks. If there is not trunk involved then there is no cost involved and then it does not show there. If you want to see the activity with extensions, you need to check the extensions call log (which is essentially about missed calls and redial).

Take a look at the good old Wiki http://kiwi.pbxnsip.com/index.php/Office_with_private_and_public_IP_addresses. It describes the pain you are going through. A SIP proxy won't help you as the real problem is not SIP, it is RTP. Plus there are protocols like TFTP, HTTP, HTTPS, LDAP and possibly other ports that are also causing problems. One of the two parties (the PBX) has to advertize a routable IP address (AKA public IP address). You could try to use the "IP routing list", but beware this is tricky and easy to screw a lot of things up. I would try everything to get the PBX NIC on a public IP address. IPv6 address will also do. Okay, I am dreaming now.

Did you try to load this file from the web browser? If that does not work, did you change anything in pnp.xml or did you change this file (either in the web interface or on the file system)? "It should work", I checked here.

Yes thats another possibility if you have only one domain slash all domains should have the same phone dial plan.

That bug was still open in the 4.2 version. In the meantime, we have found another workaround that avoids the XML-based dial plan (which obviously does not work). If you want to get it working, you need to use the templates attached. You can change them in the web interface or place them in the file system in the html directory. dialplans.xml snom_820_phone.xml

The persistent route seems to be the right approach for this. It is interesting, because this is a way to ensure that (no matter what is going on with the other public IP interface) you can ensure that the quality of service on the ITSP trunk is good. If the problem was fixed by choosing a different RTP port range then that's a solution to me.

Whow.

Instead of using redirect all I would just not register an extension (e.g. choose a very difficult SIP password) and set the cell phone number. Then it would count as extension call.

Each call takes two ports towards the service provider (RTP and RTCP). 15K should be more than enough. No, the PBX keeps it strictly B2BUA. That could be a source for trouble. Is there any reason for this? This will only work if the OS routing tables have special entries for the ITSP and the default route goes over the interface that is used by the phones. "route print" would be interesting here (changing the IP addresses in the response to obscure the original one is perfectly okay here!). Yes, that should be no problem unless someone actively messes with it. I would think that the service provider has no problem with the UDP, otherwise other customers would scream very quickly. The local LAN should also be no problem as this happens only when the ITSP is involved. 15000 ports is definitevely enough, no need to search in this area.

The problem remains why the PBX renders private IP addresses to a phone requesting this from a public IP address. This problem must be solved before you can work on the customization issues.

There is a beta firmware available for the M9 that might solve the problem: http://downloads.snom.net/tmp/m9-9.2.53-a.bin

It depends. A redirection does not count as extension call, that is a feature. If the call gets forked to the cell phone, then that call should be recorded as extension call.

It could happen on the IP layer already. For example we have seen cases where there was a simple IP address conflict. If you are not using DHCP, I would check this (over and over). But higher probability has that the router might have a limited number of UDP NAT associations available and the last "steals" an older one, so that traffic gets forwarded to the wrong client. If the problems occur only when talking outside of the LAN this might be a hint that the problem is in this area.

Well you routing tells the PBX to use the private IP address when talking to the public Internet. Check "route print" (Windows) if it uses the right interface when talking to the WAN. You might have to change the default route to use the public IP interface.

It could be that the DNS server is very slow. You would see that when you use Wireshark and filter for DNS records. What you could try is to use and alternative DNS server on public IP (for example, dns.callcentric.com = 204.11.192.12 might be worth a shot). Background: SIP requires a lot of DNS queries, DNS NAPTR, SRV, AAAA, A. Callcentric has a lot of servers hidden behind their primary address, which returns large DNS packets. Maybe because of UDP fragmentation they dont make it and the DNS server then has to eventually swich to TCP to get those records.

If you want to have the custom file, you have to add the line yourself to the snom_821.xml file. Or you just edit the snom_820_phone.xml file (also through the web interface), and then there may be no need for a custom file at all.

Has been done already, the ticket number is SNM-239.

Yes, but it does not solve the problem. The m9 must support early media DTMF, and that must be fixed.

Not 100 % sure. The problem with the DECT device is that before the connect timestamp the device probably believes that the user is entering the destination number (DTMF is used both for dialling the number and for sending tones once the call is established). But "in theory" the snom m9 should also send DTMF when the call is not connected yet and if not, then thats a bug that must be fixed. Do you have another device that you can try for the sake of clarifying that the early media is the problem?