5.1.3

[Vodia PBX]

We have made builds for all supported operating systems (Windows 32/64, Debian 32/64, CentOS 32/64, FreeBSD 64, Apple MacOS Intel/PowerPC, snom ONE mini) for the 5.1.3 release. The release notes can be found on http://wiki.snomone.com/index.php?title=Release_5.1 there are many fixes, we consider this release a major milestone regarding stability and features.

 

Before you upgrade we recommend as usual to make a backup of the old installation. Also consider resetting your webpage changes or at least review them (webpages directory, html directory) as many things have been changes in the web interface.

 

This version introduces a new firmware for snom phones. If you automatically provision snom phones, the phones will load a new firmware on the next reboot. Polycom phones that are running version 4 or higher will start using TLS and SRTP for phone calls after the next provisioning cycle.

[hosted]

excellent work!

[Steve B]

We have made builds for all supported operating systems (Windows 32/64, Debian 32/64, CentOS 32/64, FreeBSD 64, Apple MacOS Intel/PowerPC, snom ONE mini) for the 5.1.3 release. The release notes can be found on http://wiki.snomone.com/index.php?title=Release_5.1 there are many fixes, we consider this release a major milestone regarding stability and features.

 

Before you upgrade we recommend as usual to make a backup of the old installation. Also consider resetting your webpage changes or at least review them (webpages directory, html directory) as many things have been changes in the web interface.

 

This version introduces a new firmware for snom phones. If you automatically provision snom phones, the phones will load a new firmware on the next reboot. Polycom phones that are running version 4 or higher will start using TLS and SRTP for phone calls after the next provisioning cycle.

 

On webRTC when i make a call from the browser, am I missing where the keypad is or is that a work in progress? For instance if I call the voice mail, how do I enter a number

 

You guys are making this thing hard to beat, keep up the good work.

[Vodia PBX]

Good question. I know that for the call button there is a dial pad. Looks like this has been forgotten in the console!!

[hosted]

i cant get the UCclient to work.. fyi

 

seems like its trying to TLS on port 5060

[Vodia support]

it's working fine on my end.... using 5.1.3

 

[8] 0:07:00.917 TFTP: HTTP: Received request for file snom-m9-settings-000413000000.xml from 10.0.0.3 [8] 0:07:00.917 TFTP: Provisioning file snom-m9-settings-000413000000.xml looking for MAC 000413000000 [8] 0:07:00.917 TFTP: PnP: Using the credentials of 40@10.0.0.3 for file snom_m9_settings.xml [8] 0:07:00.925 TFTP: HTTP: file snom-m9-settings-000413000000.xml based on template snom_m9_settings.xml is sent to 10.0.0.3 [8] 0:07:00.930 SIP: Packet authenticated by transport layer

 

 

What does your logs say?

[hosted]

i guess i need to wireshark.. I receive the config file just fine then the client tries to register TLS (on port 5060) according to the client log then it times out.

the pbx doesn't show any attempt.

 

wireshark time. (ill do it tomorrow)

 

 

 

 

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

2013/12/09 22:47:23 SIP Tx tls:198.**.**.**:5060:

REGISTER sip:***.pbx.io SIP/2.0

Expires: 120

Call-ID: yjrj0n0o@snom

To: "David Burr" <sip:200@***.pbx.io>

From: "David Burr" <sip:200@***.pbx.io>;tag=zs35vg

Supported: path, outbound, buttons

User-Agent: snom wsss 10.1.1

CSeq: 29451 REGISTER

Contact: <sip:200@10.1.0.183:53437;transport=tls;line=k3ryju>;reg-id=1;+sip.instance="<urn:uuid:778603d0-63f0-40c7-8e0a-689b08cb53bd>"

Via: SIP/2.0/TLS 10.1.0.183:53437;branch=z9hG4bK-yy457x;rport

Content-Length: 0

[Vodia support]

Also try to start from scratch remove all the information from the settings save the UC, close the application, make sure the firewall allows the application as well then try to register the account again. You can always use the PCAP on the pbx to get more data.

[hosted]

well were getting closer.

I can verify from the UCclient the connection is TLS and its trying to talk to the PBX on port 5060.
and the PBX is not accepting tls on that port.
(I changed the PBX to TLS 5060 and it worked *for the most part*)


after i got the TLS on port 5060, i was able to register and the pbx picture was downloading. but the call log and the other users didn't show up (and i did veryify the PBX sent the information to the client in the SIP NOTIFY stuff)

UPDATE: i changed the snom transport method to TCP. and its working... except for the missing contacts/call log

 

(i don't get why the picture downloaded but not the contacts)

[Chappo]

Caller ID appears to be broken yet again?

 

Any phones that are answering a shared line (through line hunt) are only showing their own name and extension number? Received calls are showing outbound calls which have been made to other users.

 

Dialed numbers is showing incoming calls - just the star code entry for the pickup.

 

Snomone server user login is not showing any call history.

 

Phone settings are as follows (Using Firmware-Version: snom821-SIP 8.7.3.25) - (Phone is extension 45) -

 

<callrecord_received_local idx="0" perm="">45@pbx.domain.com.au</callrecord_received_local>

<callrecord_received_local idx="1" perm="">45@pbx.domain.com.au</callrecord_received_local>

<callrecord_received_local idx="2" perm="">45@pbx.domain.com.au</callrecord_received_local>

<callrecord_received_local idx="3" perm="">45@pbx.domain.com.au</callrecord_received_local>

<callrecord_received_local idx="4" perm="">45@pbx.domain.com.au</callrecord_received_local>

<callrecord_received_remote idx="0" perm="">sip:44@pbx.domain.com.au</callrecord_received_remote>

<callrecord_received_remote idx="1" perm="">sip:40@pbx.domain.com.au</callrecord_received_remote>

<callrecord_received_remote idx="2" perm="">sip:40@pbx.domain.com.au</callrecord_received_remote>

<callrecord_received_remote idx="3" perm="">sip:40@pbx.domain.com.au</callrecord_received_remote>

<callrecord_received_remote idx="4" perm="">sip:40@pbx.domain.com.au</callrecord_received_remote>

<callrecord_dialed_local idx="0" perm="">45@pbx.domain.com.au</callrecord_dialed_local>

<callrecord_dialed_local idx="1" perm="">45@pbx.domain.com.au</callrecord_dialed_local>

<callrecord_dialed_local idx="2" perm="">45@pbx.domain.com.au</callrecord_dialed_local>

<callrecord_dialed_local idx="3" perm="">45@pbx.domain.com.au</callrecord_dialed_local>

<callrecord_dialed_local idx="4" perm="">45@pbx.domain.com.au</callrecord_dialed_local>

<callrecord_dialed_remote idx="0" perm="">sip:*601236@pbx.domain.com.au</callrecord_dialed_remote>

<callrecord_dialed_remote idx="1" perm="">sip:*9044@pbx.domain.com.au</callrecord_dialed_remote>

<callrecord_dialed_remote idx="2" perm="">sip:*601223@pbx.domain.com.au</callrecord_dialed_remote>

<callrecord_dialed_remote idx="3" perm="">sip:*601134@pbx.domain.com.au</callrecord_dialed_remote>

<callrecord_dialed_remote idx="4" perm="">sip:*9048@pbx.domain.com.au</callrecord_dialed_remote>

[Chappo]

Also any update on getting the coloured buttons implemented? Hold, pickup, ringing?

[Vodia PBX]

Well, as for the call pick up CDR on the phone. If you tell me how we can write the phones CDR, we could take a look at this! But the call pickup is a star code.

 

As for the colors of the phone; I believe there is more flexibility on the phone for this now; however we are currently glad that we have a stable firmware that works well with snom ONE (if you forget about the problems with the 870 incoming calls for a second). 5.1.3 will not be the last version; we still have work do to trying to get the extension board provisioned.

[shapa]

Some very strange / weird issues with web interface...

Neither client login (web status / calls / etc) nor admin "active calls" working properly... Always "disconnected" and ERROR: undefined

 

https://www.dropbox.com/s/pij6i6i4uq0735g/Screenshot%202013-12-11%2021.13.24.png

 

https://www.dropbox.com/s/stwqikzw8fvonff/Screenshot%202013-12-11%2021.13.45.png

[Vodia PBX]

Some very strange / weird issues with web interface...

 

Neither client login (web status / calls / etc) nor admin "active calls" working properly... Always "disconnected" and ERROR: undefined

 

https://www.dropbox.com/s/pij6i6i4uq0735g/Screenshot%202013-12-11%2021.13.24.png

 

https://www.dropbox.com/s/stwqikzw8fvonff/Screenshot%202013-12-11%2021.13.45.png

 

If you have that problem, your web browser or firewall has problems with websocket. You can try www.websocket.org/echo.html to see if your setup supports websocket.

[shapa]

Thank you, you are right. SSL connection work fine,but not http.

 

Strange...

[Chappo]

Well, as for the call pick up CDR on the phone. If you tell me how we can write the phones CDR, we could take a look at this! But the call pickup is a star code.

 

But to the end user the star code is irrelevant.

 

My main issue with this revision is that the phones are not updating the Caller ID of an external party when the call is picked up via star pickup. Previously on 5.1.2 this worked ok. Currently the screen will only display the current logged in users name and extension on the line below.

 

See: https://dl.dropboxusercontent.com/u/56065335/screen%20external%20call%20no%20clid.bmp

 

I have gone back to 5.1.2v and this is what you get when you answer a call via star code - https://dl.dropboxusercontent.com/u/56065335/CLIDcorrect_screen.bmp

 

The dialled / received behaviour is still the same other than the received list would show the internal party that transferred the call and next to it display the caller ID of the external call. Now it only shows the internal extension.

 

Edit:

5.1.2v - Outgoing CLID broken

5.1.2w - Incoming CLID broken

5.1.3 - Incoming CLID broken

[shapa]

OK, inter-domain calling is completely broken. Very bad situation.

 

Nothing changed in configuration, inter-domain user matching works, but "no trunk info" and call refused...

 

[5] 14:31:50.172 APP: Port 126: Incoming call in domain pbx.highperf.pro on port 126 extension 3000

[5] 14:31:50.172 APP: Port 126: New call created with number 83

[5] 14:31:50.173 APP: Dialplan "Max Plan": Match 7000@pbx.highperf.pro to sip:7000@pbx.navica.highperf.pro;user=phone on Try Loopback trunk

[5] 14:31:50.175 GENE: Received incoming call without trunk information and user has not been found

[5] 14:31:50.180 SIP: set codec: codec G722/8000 is set to call-leg 126

[5] 14:31:50.180 GENE: Port 128: Received incoming call without trunk information and user has not been found

[5] 14:31:50.181 SIP: INVITE Response 404 Not Found: Terminate dd4335a1@pbx

[5] 14:31:50.322 SIP: set codec: codec G722/8000 is set to call-leg 126

[5] 14:31:51.033 PACK: SIP Rx tls:195.94.250.101:22319:

[hosted]

make sure you put a 1 in the country code for each domain

[Vodia PBX]

Okay, we need to look into the call pickup and how it looks like. We have tested the inter-domain calling, at least in the lab it was working. However you must make sure that the numbers are presented in the +-notation (e.g. +16173998147).

[shapa]

We are trying inter-domain with local extensions - i.e. from 3000 at one domain to 7000 at another.

 

Loopback works fine - 7000 location identified correctly ("[5] 14:31:50.173 APP: Dialplan "Max Plan": Match 7000@pbx.highperf.pro to sip:7000@pbx.navica.highperf.pro;user=phone on Try Loopback trunk")

 

What does it mean "GENE: Received incoming call without trunk information and user has not been found" ?

 

Downgraded back to 5.1.1 - everything is fine again, -> it is broken in 5.1.3...

[shapa]

Just checked 5.1.2v - it is broken also.

 

[5] 6:09:15.852 APP: Dialplan "Max Plan": Match 7598@pbx.highperf.pro to sip:7598@digitallines500.com;user=phone on Try Loopback trunk

[5] 6:09:15.854 GENE: Received incoming call without trunk information and user has not been found

[5] 6:09:15.859 SIP: set codec: codec G722/8000 is set to call-leg 4

[5] 6:09:15.860 GENE: Port 6: Received incoming call without trunk information and user has not been found

[5] 6:09:15.861 SIP: INVITE Response 404 Not Found: Terminate 494f6d14@pbx

[5] 6:09:15.973 SIP: set codec: codec G722/8000 is set to call-leg 4

[9] 6:09:22.851 WEBS: Load modified file email_header.htm

[9] 6:09:22.852 WEBS: Load modified file email_footer.htm

[5] 6:09:33.328 PACK: SIP Rx udp:184.73.248.111:40482:

[shapa]

Correct behavior (5.1.1)

 

[5] 2013/12/13 02:19:41: Dialplan "Max Plan": Match 7598@pbx.highperf.pro to sip:7598@digitallines500.com;user=phone on Try Loopback trunk

[5] 2013/12/13 02:19:41: set codec: codec G722/8000 is set to call-leg 0

[5] 2013/12/13 02:19:41: set codec: codec G722/8000 is set to call-leg 2

[5] 2013/12/13 02:19:41: Last message repeated 2 times

[5] 2013/12/13 02:19:41: set codec: codec G722/8000 is set to call-leg 1

[5] 2013/12/13 02:19:41: set codec: codec G722/8000 is set to call-leg 0

[5] 2013/12/13 02:19:45: BYE Response: Terminate fa9c758f@pbx

[Vodia PBX]

We are trying inter-domain with local extensions - i.e. from 3000 at one domain to 7000 at another.

 

Loopback trunk calls must use global names. You must assign at least one alias name to the account that looks like a telephone number (starting with +) and they must be unique in the system. You can archive that by using a prefix per domain, for example +1777123 for domain 1 and +1777124 for domain 2 (if you are in the NANPA region). If 3 is already your domain, then just put a + in front of it; that should also work (+3000).

[shapa]

Sorry, but still it is not very clear.

 

It used to work without any prefixes for a long time (v3, v4, v5 up to 5.1.1)

 

We don't like to set any additional aliases for each account as it is completely meaningless

 

However, it is not a big deal to set prefixes per domain, but what does it mean under "prefixes"? How to set it?

 

Finally, what is the reason to change normal behavior and to force customers to use workarounds? We've got plenty of internal users (without access to outside) and we don't need any external numbers / aliases attached to them.

[Vodia PBX]

For lookback trunks you MUST use global names. For example, sip:+3000@domain1.com would work, while sip:3000@domain1.com does not work. It was actually a requirement also in earlier versions, but if the domain name was right it would also take it. However this method lead to a lot of problems with calls ending up in the wrong domain, which is very confusing for callers.

 

Just give your accounts names that look like "real" telephone numbers with more than 6 digits. Then it will be a lot easier.