Jump to content

Recommended Posts

Posted

We have made 5.1.2v for Win32/64, CentOS64, Debian64, snom ONE mini and FreeBSD64. Those who like to run the latest versions are invited to update to this version, available from http://snomone.com/downloads/snomONE/version-5.1.2v.xml (you can copy & paste that link into the software update page on snom ONE).

 

What you need to look out for:

  • Make sure that you are using the domain country code. We have worked in several areas that interprets the numbers right. The trunk now really uses the settings on how numbers are presented on the trunk, also for inbound calls. This will help in many situations, but if you had it set up wrong you might have problems with inbound calls. We had issues with speed dial and calling the cell phone (*00), but those problems should be under control now.
  • If you are using interoffice trunks you should also see if that works all right.
  • We have changed the default snom phone firmware to 8.7.3.25. It seems that snom has kept their promise and came out with a stable firmware that can be used across all desktop phones.
  • If you have made changes to the web interface you might have to take those changes back. We have worked heavily on the web content, which might conflict with your changes.

What new features you can expect:

  • The PCAP recording per trunk and extension. The blog post already talked about this. I will not repeat it here.
  • The email CDR for the domain will now show the same information like on the web interface. That means not only calls that involved trunks, but all calls will be reported. It should also address the various problems that people had with including all calls from the previous day.
  • Lots of performance improvements. The system behaves much better if you have hundreds of registrations and thousands of CDR and address book entries. Our hosted PBX partners will love to hear that.
  • Inbound WebRTC calls. With this, you might not need a soft phone any more.

There are lots of fixed bugs and also lots of smaller new features. Before the full release, we will of course update the release notes.

Posted

this new version is giving a ton of these errors:

 

One side of the call between sip:801@pbx:5060 and sip:802@customer:5060 did not receive media for 1228974.6 s. It seems the user disconnected the call because of that. The SIP messages are attached.

 

Also its saying version "u" not "v"

Posted

That's a pretty long time! Did you use the XML link from above? So you are using CentOS32? It should definitively say 5.1.2v.

yea doesn't make sense, no customers are complaining.

 

yes i tried it twice, it says "u" centos64

useragent also says "u" (wish this was customizable again)

 

Software-Version: 5.1.2u (CentOS64)

Build Date: Nov 28 2013 21:21:16

Posted

Let me clarify: Did you put the link to the XML file into the software update field of the PBX? Did you make a manual update last time, maybe the name of the executable is not pbxctrl any more?

Posted

yes i used the xml in the software update.

 

i also manually downloaded the file in the xml and replaced pbxctrl, same thing.

the manual file also says "v"

------------------------

[1] 7:42:10.482 WEBC: Performing software upgrade based on http://snomone.com/downloads/snomONE/version-5.1.2v.xml

[3] 7:42:10.845 WEBC: Software update: Removing file pbxctrl-old

[3] 7:42:10.845 WEBC: Software update: Sending request for file http://snomone.com/downloads/snomONE/centos64/pbxctrl-centos64-5.1.2v

[5] 7:42:35.795 WEBC: Succesfully changed the permission for file pbxctrl

 

 

rebooted and

Software-Version: 5.1.2u (CentOS64)

Build Date: Nov 28 2013 21:21:16

 

 

also, before doing this upgrade i was not using "u"

Posted

looks good now.

regarding these messages:
One side of the call between sip:801234@customer:5060 and sip:801320@trunk:5060 did not receive media for 1080383.7 s. It seems the user disconnected the call because of that. The SIP messages are attached.

 

i have determined these are phantom co lines.

 

scenario:

 

incoming call is placed on hold. you then press 801 (to start a new call).. 2 shared lines light up (colines) you hangup the call and a phantom coline is still light up.

 

after it ends up going away I get this email notification.

Posted

in 5.1.2v (Win64): calling an extension shows on snom720 phone display not the dialed number anymore:

running this version at starting the call the phone display changes/updates with the users/extensions Name (or actual used line/account...?)

for our employees it would make much more sense to keep their currently typed/dialed destination number

 

going back to release version 5.1.2 this works as it should: during making a call it shows/keeps displaying the number that I typed/dialed,

(I just changed pbxctrl.exe - not any configuration changes required)

 

I did not find any working configuration-setting for 5.1.2v yet for the old function of displaying the destination number :-(

Is this a little bug or is there some kind of configuration failure on my side?

Posted

regarding these messages:

One side of the call between sip:801234@customer:5060 and sip:801320@trunk:5060 did not receive media for 1080383.7 s. It seems the user disconnected the call because of that. The SIP messages are attached.

 

This is probably a problem with Linux installations that are either using the new PCAP recording feature or RTCP-XR (which is the default). The problem was that the network clock differs from the system clock, which results in those long differences. Next version will have it fixed (hopefully).

Posted

Since we upgraded to version 5.12 and 5.12v, including doing a new install and an upgrade, the PCAP Trace no longer captures any traffic. It generates a pcap file but no packets are in the file. It seems like maybe it is trying to get capture from the Interface that isn't being used on the server? This is on CentOS and Debian systems, but for version 5.12v, it is on CentOS. Also If we do a pcap on an extension level, do we still need to run the pacp trace feature to start the trace?

Posted

Since we upgraded to version 5.12 and 5.12v, including doing a new install and an upgrade, the PCAP Trace no longer captures any traffic. It generates a pcap file but no packets are in the file. It seems like maybe it is trying to get capture from the Interface that isn't being used on the server? This is on CentOS and Debian systems, but for version 5.12v, it is on CentOS. Also If we do a pcap on an extension level, do we still need to run the pacp trace feature to start the trace?

 

The PCAP link on admin mode is superfluous now; we have forgotten to take it out. 5.1.3 will not have that link any more.

 

The only way to get the PCAP is (right now) to get file system access and download the files in the pcap directory. Even for the embedded systems like snom ONE mini that is still okay, as they support SSH access.

Posted

Inbound WebRTC calls. With this, you might not need a soft phone any more.

 

This feature we can use only we have licence the WebRTC ?

 

I think so... actually the last word has not been spoken on this subject. There are thoughts to sell WebRTC extension licenses similar to call licenses, but it has not materialized yet. As for now I suggest that you just use the 30-day trial.

  • 1 month later...
Posted

We have several trunk providers and for some of them including 1 in the country code doesn't represent a big problem. Unfortunately one of our main trunk providers insists that we send them 10 digit number. If we include 1 in the country code we cannot make outbound calls since to them it appears as 11 digit number. How do we solve that issue in any new version 5.1.2V2 or 5.1.3?

 

We have made 5.1.2v for Win32/64, CentOS64, Debian64, snom ONE mini and FreeBSD64. Those who like to run the latest versions are invited to update to this version, available from http://snomone.com/downloads/snomONE/version-5.1.2v.xml (you can copy & paste that link into the software update page on snom ONE).

 

What you need to look out for:

  • Make sure that you are using the domain country code. We have worked in several areas that interprets the numbers right. The trunk now really uses the settings on how numbers are presented on the trunk, also for inbound calls. This will help in many situations, but if you had it set up wrong you might have problems with inbound calls. We had issues with speed dial and calling the cell phone (*00), but those problems should be under control now.
Posted

The trunk has a setting (Rewrite global numbers) where you can tell the trunk how numbers should be read, but also how numbers should be written (it is the same setting). Choose NAPNA (10 digits), that should work with your trunk provider.

 

Also if you have found good settings it would be awesome if you can share the settings, so that we can update or add the dropdown list in the PBX.

Posted

The trunk has a setting (Rewrite global numbers) where you can tell the trunk how numbers should be read, but also how numbers should be written (it is the same setting). Choose NAPNA (10 digits), that should work with your trunk provider.

 

Also if you have found good settings it would be awesome if you can share the settings, so that we can update or add the dropdown list in the PBX.

 

I'll play with this over the weekend so we can restore from the backup if need be... Will let you know what I find out.

Posted

 

I'll play with this over the weekend so we can restore from the backup if need be... Will let you know what I find out.

Well I tried every possible setting with pull down menu's but as soon as we put 1 in the General settings for the domain the incoming call doesn't know where to go. I have a log file for successful and unsuccessful which I would submit privately. The provider uses "Broadvorks" softswitch. This is a problem for us which needs to be resolved since we cannot move forward with ether update.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...