Vodia PBX

This is still very tight. Keep in mind that every call has several legs and each call leg occupies 2 ports (RTP and RTCP). Because 10001 is a odd port, it is not available, the same for 10020 (because 10021 is not available). So you have essentially 10002..10019, which is 18 ports, 9 legs, equal to 4 x 2-legged calls.

Log in as administrator to the PBX, navigate to settings/ports, then there is "Port Range Start" and "Port Range End". The default is 49152 and 64512, which is roughtly 16000 ports and pretty much guarantees you that the PBX will find a free port pair.

Seems that the number of RTP ports on the PBX was not enough and the PBX was simply running out of RTP ports when forking to another device.

On a second look, seems that the phone was response was because the port on the PBX was set to zero: m=audio 0 RTP/AVP 0 101 a=rtpmap:0 pcmu/8000 a=rtpmap:101 telephone-event/8000 Do you ever see "Could not allocate new ports" in the log (media level, log level 1)? It seems that the PBX has a problem allocating new ports. It does not neem to be a general OS config problem, because other calls do get ports. What is your RTP port range that you have set on the PBX? Maybe you picked a very narrow range and becomes kind of random if the PBX can grab a new port or not.

You probably have to factory reset the phone and provision it again. The PnP from the PBX does not provision all settings which are available on the phone.

Looks like the phone on 192.168.1.113 is configured not to accept u-law codes: SIP/2.0 488 Not Acceptable Here Via: SIP/2.0/UDP 192.168.1.63:5060;branch=z9hG4bK-e97e9b7916393e75fe379f5e4f13718a;rport=5060 From: "BEVERLY MAY" <sip:5198417838@174.137.63.206;user=phone>;tag=34237 To: <sip:2264751002@206.248.136.39:5060;user=phone>;tag=qy7opijznr Call-ID: 11be718c@pbx CSeq: 9947 INVITE Contact: <sip:42@192.168.1.113:2049;line=dexwgw6y>;reg-id=1 Warning: 304 x-snom-adr "No supported media type found" Content-Length: 0

Dazu würde ich das Template ändern. Im Admin-Modus auf Webseiten gehen, dann PnP templates auswählen und dort ändern. Vermutlich muss dann folgende Zeile eigefügt werden: <transfer_on_hangup perm="RW">on</transfer_on_hangup>

If you are using snom phones, PnP and a recent release, the record button should be mapped to a XML browser screen where you should see those options on the screen. If I remember correctly, even suspending of recording should be possible. What version are you running, and are you using PnP?

Are those callers in a agent group? If they are in the connected state of the agent group, then we could have the feature to turn recording on while connected to an agent.

I would send it to a hunt group, where you can set the ring tone.

I am sure that the box is technically still intact, however something got screwed up with the interfaces. A look at the console will tell what the problem is. We will come out with another version that will include a factory reset button, so that such changes from the web interface can be undone by pressing the physical button. However the openess of the system does have the consequence that people can log in, for example delete the whole file system or remove the program which controls the reset button; so there will never be a 100 % way to make sure the box does not get screwed up. People who are taking advantage of the openess should keep the serial console cable ready, so that they can always login on RS232 and get the system back under control. I think this is reasonable: the benefits of giving integrators the possibility to do real cool things with the box outweights the danger that something gets screwed up.

Well, you can still revert back to the last known version or at least keep the CDR in the file system (back up) and then later have to charge them manually. We'll check later (this is a holiday in Boston) if we can provide you with a build today or tomorrow..

Something got screwed up with the automatic black/whitelisting of HTTP traffic. We already found the bug and the fix will be included in the next build.

You should still be able to access it on console. On http://plugcomputer.org/plugwiki/index.php/GuruPlug#Serial there is a description on the PIN layout, and there are affordable hardware tools available to connect your PC with the console. Or just ship it to the snom RMA department, they'll be able to take care about it as well. I wonder why the IPv6 is not available, no matter what that address should always be available.

Yes you must have had a version where we had that bug... http://wiki.snomone.com/index.php?title=Coma_Berenicids is the latest.

It would be good to really find the reason, so that we can put that on our checklist. Reinstallation is not really a solution to me that we can recomment... We also had other topics with voip.eutelia.it (for example, http://forum.snomone.com/index.php?/topic/2741-error-400-bad-request/) and it would be good to know if there is anything that we can do to make this install smooth. If it magically suddenly works we all love to hear it, but it would be better to know why it works again. BTW if you change files on the file system, the PBX does not care about that. The PBX reads most of those files only during the startup phase.

Stability is most important for a PBX, the system should run 24/7 thats the key feature of a telephone system. In the IT world, there are unfortunately a lot of components in the picture that ca make this a problem. I doubt that it is the PBX iteself which has a problem, th "Tx" log entry is pretty low level and from then on there is not much happening between the PBX logging in and putting the packet on the cable. Before it hits the service provider (who BTW also operates an IT system!), the packet has to pass the operating system, and here the biggest enemy is the personal firewall (if present) and hte local interface. The personal firewall is usually only a problem during installation, once it whitelisted the PBX process I dont see a reason why it should filter packets after two weeks. On the interface side, I can think about link loss (no Ethernet connection) and problems with the IP configuration like DHCP server down or an IP address conflict, However in that case the PBX should not be available to anyone on that interface. If there are multiple interface, for example on efor the LAN and another one for the WAN, then it could explain why the LAN registration worked while the WAN did not work. We have seen cases where cables were broken (very difficult to find out). Maybe there is a log entry in the OS that tells about link loss events, this would be an easy way to find out if that was the problem. Then once that the packet physically has left the PBX host, the next problem zone is the firewall. This is a long chapter. We have seen firewalls with 32 UDP NAT entries, and when they were full they simply dropped the traffic. This was also very difficult to trouble shoot. Another "favourite" is when the firewall is "SIP aware", which usually means no good. All the firewall does in such cases it mangle packets or accidentially drop them at all. My standard recommendation for SIP aware firewalls is to turn the madness off, use TLS to hire the traffic from the firewall or purchase another one without the feature.

What dont you use PnP? Then all those settings are set up automatically for you.

Don't replace the domain name; that might confuse the service provider. Only the Proxy Address, which tells the PBX where to send the request. One more thing to check would be the Windows firewall, although it would be very surprising if the firewall suddenly blocks traffic after two weeks of good operation.

Well, what could be is that the service is really not available. This could be because the Internet connection is (temporarily) unavailable, or the service provider does not answer the request. That can be because the IP address where you are sending from suddenly became blacklisted or even worse the service provider has technical problems (can also happen). If you see "Tr" in the log that means the PBX is repeating the request and did not get anything back. Also if you are operating your PBX behind a NAT, maybe the public IP address of the router has changed in case that you have setup the PBX to replace the IP address with the public IP address. If your phones are still registered, you can exclude problems with the server itself. Other problems we have seen especially in Italy are problems with the DNS. Sometimes the service itself available, but cannot be found on DNS any more. In that case you can just "hard code" the IP address instead of the DNS in the outbound proxy of the trunk. It does not win the beauty contest, but solves a real problem with some DNS servers.

We are already working on a solution. The idea is to keep the call recordings pretty much like regular voicemail messages, e.g. use the feature to send it by email and automatically delete the oldest one when the MB is getting full.

WHat is in the "generated" folder? The link http://pbx.wan3.com/snom720.htm does not work, it needs to include the "prov" folder in the pathname (e.g. http://pbx.wan3.com/prov/snom720.htm).

As far as I can see, there was a vulnerability in the Cisco server, so that they added that to the firewall. That does not apply to snom servers. Can you disable the Signature (false alarm)? Also, if you use TLS, then the Cisco server would not have the option to intercept the traffic and the traffic would pass through.

Ergh. That would cause a lot of problems with accounting, free/available scheduling and many more things. When is a hunt group "free", especially when it potentially calls extensions in a couple of seconds? Agent groups are about sequential processing, hunt groups about parallel processing.

Well the hunt group cannot call star codes. You can set the flag in the extension that tells the PBX to fork the hunt group calls also to the cell phone. However that would apply to all hunt groups. We could add a flag in the hunt group that enables or disables the fork to the hunt group. The workaround for right now is to put the cell phone number directly into the hunt group.