Vodia PBX

Okay, I think we need to try that in our test lab as well, should not be too hard to reproduce.

Well, IMHO the phone should never go belly up, even if complete nonsense has been entered.

As we approaching version 3 release, we have spent some time in getting an image for the MAC world. Especially the MAC mini seems to be very interesting for running a SIP-PBX. For those who are interested, we have prepared a build at: http://www.pbxnsip.com/download/pbxctrl-darwin9.0-3.0.0.2992 Feedback welcome. Maybe there is a MAC guru out there than can explain us how to make something easy installable out of this executable. Macintosh:prj mr$ uname -a Darwin macmini.pbxnsip.com 9.2.1 Darwin Kernel Version 9.2.1: Tue Feb 5 23:08:45 PST 2008; root:xnu-1228.4.20~1/RELEASE_I386 i386 Compilation seems to run smoothly. Only the clock behavior seems to be a little bit different than Linux, we could not figure out how to differentiate between real-time and CPU clock. Anyway, maybe that is just hair-splitting. So keep an eye on that, especially when the NTP client decides to change the time.

It seems that there is a problem with the phone's ability to keep the connection alive during mute. From the PBX perspective the phone is "dead" and that is why the PBX hangs up. What version of the phone are you on? Maybe check release notes of firmware updates if there is anything on this. Dirty workaround is to change the global settings for one-way audio timeout. The parameter has the name timeout_connected and you can see the current value in the pbx.xml file.

The beauty about SIP is that one vendor does not have to offer everything . Check out www.faxback.com, they have a great solution and I heared they are running pbxnsip in their office!

Ouch. What version of the phone?

No. But you can define what "night" is. You can choose a different time zone and then assign the time zone per extension. That will fool the PBX and make it send out the reports at a different time.

Memory does not scare me in this case. It is just that the data collection of moer than 1000 CDR (lets say, 40000) takes a while during which the PBX would not process and new incoming calls. Now think about that call center which is working practically only at night, there we would have a problem. If everybody is sleeping at this time, there is no problem.

In 2.1 you'll have to do this with a email filter on your favourite email client... In 3.0 we introduce flags that control which emails are sent to the admin.

Okay, did you: create a button profile with the park key assigned (e.g. key number 7 assigned as park with parameter 650 for park orbit 650) assign it to a specific extension (registration tab of the extension) Make sure that the MAC of the phone is associated with the extension (registration tab of the extension) reboot the device Then you should see in the phone the fkeys set to button (at least the button number 7).

I think the misunderstanding is that the PBX would authenticate an incoming Ethernet packet based on the MAC address. It does not do that - and it would be actually difficult if the request was send e.g. over the Internet. MAC addresses are kept in the packet only in the "LAN" (whatever that is). As soon as a router comes into the game, the MAC has not much meaning any more. The MAC is only used for the automatic provisioning of devices. Even there the MAC on the Ethernet packet plays no role; whatever MAC the user agents indicates in the provisioning request is used for generating the provisioning data.

Line or registration? And who is keeping it alive? The phone or the PBX? I don't 100 % get it...

What do you have setup on the phones for fkeys? Maybe there is still something from the last plug and play operation. In doubt, just iron the phone (factory reset) and give it another shot.

The support is only for receiving DTMF INFO, no transcoding between signalling layer and media layer. This is just because we don't like to make our live miserable. Think about someone sending RFC2833 (=RFC4833) DTMF tones and then while the tone is playing back someone sends a INFO as well. Plus the support for RFC2833 tones is pretty good these days.

Okay. Incoming calls have nothing to do with MAC addresses. The MAC address is used only for plug and play. Then once the phone is configured it will probably keep the registration alive and that's why the PBX sends the call to that phone.

Where did you enter it? Into the MAC address field? What version?

What did you do? Did you create an extension in the domain? How far did you get? Maybe http://wiki.pbxnsip.com/index.php/Creating_New_Accounts is a good starting point.

Well, definitevely check out http://wiki.pbxnsip.com/index.php/Snom and http://wiki.pbxnsip.com/index.php/Assigning_Buttons. You can select "shared line", but IMHO that is legacy from old key system times and you never get customers happy because their old 1976 system works in a silightly different way... Better "upgrade" them to a PBX functionality and use private lines (managed by the phones) and park orbits instead. Then you can also deal better with a mix of phones that have only two lines and others that have much more.

http://wiki.pbxnsip.com/index.php/Troubles..._Trunk_Problems mentions a few search tips. Maybe it also makes sense to track the registration of extensions (send out an email when the status changes) to see if the registrations are stable. SoHo-Routers can be a problem. Maybe if you have a problem next time try to reboot them to see if that makes any difference. We even had cases where the Ethernet switch gave is a problem and needed to be rebooted. "Divide and conquer" can help to isolate the problem. Of course, if you are able to see where the INVITE from callcentric goes then you should be able to pinpoint the problem. Maybe it makes sense to run Wireshark at critical points. If you filter for port 5060 then the file size should be not outrageous.

Oh yea, that is a good point... But then make the "localhost" a alias name, so that if you get a call for something else than the primary domain the PBX would still take it. The newer versions check your IP configuration in a JavaScript. There are a couple of combinations that screw up the default gateway in Linux. The script checks those when you hit the save button. In the newer software releases there is (AFAIK) no change regarding the handling of NAT and IP routing.

The PBX does not do anything special for G.722, so I would say that is not the point here. Do you have any chance to get a Wiresharl trace? Then we can see if there is a problem on the media level.

Well, make sure that this extension can really dial that number - check the dial plan what was assigned to the domain and the extension. No restart neccessary for this.

3.0 will have it, try http://www.pbxnsip.com/protect/pbxctrl-3.0.0.2992.exe.

Well, currently the PBX does not support TLS for email... Short term workaround is to use another SMTP email relay that uses plain SMTP on TCP. Maybe this is the opportunity to start doing this!

Oh did you put into the trunk an account that "pays" for the call? This is called "Assume that call comes from user" - and that user must have a dial plan that allows dialling this number. And of course the Exchange trunk on the PBX must "accept redirect".