pbx support

If you are upgrading the soho to one of the newer versions, I would suggest to do it manually. From 4.5.0.1075 onward, you can perform the web upgrade as explained in these links - http://wiki.snomone.com/index.php?title=Upgrading_the_Software http://wiki.snomone.com/index.php?title=Coma_Berenicids_(2011-4.5.0.1050)#Software_Update_Procedure

If you are doing the PnP, you should be able program one of the buttons as "intercom". There is a "intercom" item in the button profile drop-down(the last item).

It should generally show the names if it wasn't updated in a really older version. If it does not show up, then navigate to 'webpages' folder and open the xml file using notepad or some other editor. You can see the file name at the (almost)end of each file. Note that this is a crude method to find the name of changed file.

This is the part where "snom is discussing internally how to proceed. There is a solution on the table, but not available yet" comes in handy Jokes apart, we want to support everything that the pbxnsip version did, but make it a license option.

Could you please attach the SIP trace (preferably the pcap, the SIP trace from snomONE is fine it you can't get the pcap)?

Yes, there were other requests too in that area - sorting based on date, caller etc. We will try to cover all of these at one go in the future releases.

Well, there are not too many differences between the pbxnsip and snomONE versions, even though we had few differences at some point. One main difference that still exists is the license, i.e., 3rd party phone plug and play support is now controlled by the license key. The transfers, registration restrictions on 3rd party phones have been already lifted.

Did you turn on the "Log SUBSCRIBE/NOTIFY:" under the "SIP Logging" section too? You need to do that to see the SIP SUBSCRIBE messages on the PBX. If you have turned it on and still do not see the messages, that means the PBX is not receiving the SUBSCRIBE message. That is cause for PnP not working.

First you need to install 4.5.0.1090 version. Second, it is an HTML attachment, not the CSV. If really want the CSV, we can add it to the next version.

Please take a look at this wiki page to understand the logging http://wiki.snomone.com/index.php?title=Logging

Did you take a look at http://wiki.snomone.com/index.php?title=CSTA_example page for the sequence of operations?

Since you do not have the log from the working versions, we may have to recreate it on a older version here and verify the results. Since we do not have the flexor/contact pad in the lab, it is getting slower to see/test which version of PBX software made this to fail. Is this something that can be downloaded or shared for testing? This post sent to the phone I assume - 172.28.1.77:4052, file = /action_connected_url?local=45%40pbx.domain.com.au&remote=%2a6017&callid=08a9273c6eda-9rycw0bd21p6&csta=8&active_url=45%40pbx.domain.com.au&active_user=45&active_host=pbx.sgk.com.au&displocal=BC&disprem=%2a6017 Is that right?

The versions that we release to the wiki are generally production ready, i.e, ran on the internal lab & production networks and some beta customers etc. Note that this may not exercise every test case out in the real world, but covers most cases. The upgrades, to most part, are smooth. But couple of upgrades have caused some heartburn. One such case is switching from 'pbxnsip' versions to 'snomONE' versions. The other case could be the trunk upgrades that we introduced on 4.5.

Joined multicast group x.x.x.x is logged at level 8 of "Log General Events". If that category is set to 8, then you should see this log message. Otherwise, you should see "Could not join multicast group x.x.x.x". This is logged at level 0. So, you should see this message in case of the failure. Obviously, 2 things you can verify - Check the SIP logs on the phone. That should show you "SUBSCRIBE" message (http://downloads.snom.net/snomONE/docs/PnP_Multicast.swf) Check the PBX SIP trace to see if the SUBSCRIBE message is in the PBX log If you don't see the 1st one, then obviously the phone is not doing the multicast PnP. If you see the 1st one but not the 2nd one, then you know there is some issue(i.e., blocking the multicast) in the network or the network interface of the PBX server.

In the latest version we have the support for HTML attachments (instead of coming in as the body of the email). Please check it out and see if that is sufficient.

Yes, it is there for a while now.

Unfortunately we do not have any means to download the CDRs from the web interface at this point.

Alright, now your box is running the latest .1090 version. I see a lot of We have seen this if you run IE to login to the PBX. Not an issue for the PnP though. Assign the MAC address of any snom phone on one of the extensions and reset the phone (here I assume that the phone and the PBX are on the same network).

The issue was /etc/init.d/snomONE was still using link as 'snomONE-ctrl'. All we had to do is to change that to 'pbxctrl' and rename the newly downloaded file as 'pbxctrl'. This solved the problem. This is the recommended method because with this change the future updates can be done from the PBX web interface. This is explained here - http://wiki.snomone.com/index.php?title=Software_Update#Important_Note

...Just to add to the check list - make sure to update your license if you are using 3rd party phones.

I meant "maybe the error handling on the click to dial has some issues". That means the PBX version might have some issues if the call is not completely connected.

Well, this is not a difficult issue. Please PM with the ssh login info to the SoHO. We can take care of that.

There is a setting "Admin->Setting: Delete the call recording files along with the CDRs:". If that is set to "yes", there is a possibility that the recordings are deleted along with the CDRs.

If it is a click-to-dial case, then you will see the "from" and "to" reversed until the call is connected. That is okay. But call being stuck there is not ok. Maybe there error handling on the click to dial has some issues.

One common reason is someone is trying to hack (friendly-scanner or sipvicious). Maybe running the network tracing would help to see if that is the case.