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

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:

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...

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:

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

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

OK, 5.10m fixes the issue. Excellent work!

Hi Unfortunately, there are no any settings regarding ciphers in Bria. Yes, I know that TLS 1.0 is ancient / vulnerable, but Bria developers decided to do that...

Internet Protocol Version 4, Src: 10.0.0.3 (10.0.0.3), Dst: 78.40.149.11 (78.40.149.11) Transmission Control Protocol, Src Port: 58381 (58381), Dst Port: sip-tls (5061), Seq: 1, Ack: 1, Len: 156 Secure Sockets Layer TLSv1 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 151 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 147 Version: TLS 1.0 (0x0301) Random Session ID Length: 0 Cipher Suites Length: 38 Cipher Suites (19 suites) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) Cipher Suite: TLS_DHE_RSA_WITH_DES_CBC_SHA (0x0015) Cipher Suite: TLS_RSA_WITH_DES_CBC_SHA (0x0009) Cipher Suite: TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA (0x0014) Cipher Suite: TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x0008) Cipher Suite: TLS_DHE_DSS_WITH_DES_CBC_SHA (0x0012) Cipher Suite: TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA (0x0011) Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) Compression Methods Length: 1 Compression Methods (1 method) Extensions Length: 68 Extension: ec_point_formats Extension: elliptic_curves Extension: SessionTicket TLS http://gyazo.com/c47eaa2fd42438b2e2191422565ec3d2

Ok, thank you, we'll be waiting for a news

The certificate installed correctly, other clients works fine with TLS and no any browser complaining about - full trust chain is installed. Snom 870 hardware phones accepts certificate without issues as well. The error message is not in the Bria log but SnomOne PBX log (regarding "no common cipher") To be exact: [5] 20130629163907: SIP Tx udp:93.172.32.135:6198: SIP/2.0 200 Ok Via: SIP/2.0/UDP 93.172.32.135:6198;branch=z9hG4bK-d8754z-c3a3f1753276c863-1---d8754z-;rport=6198 From: <sip:3000@pbx.highperf.pro>;tag=b9bf9b48 To: <sip:3000@pbx.highperf.pro>;tag=5ebdc4ecca Call-ID: ZDlmMzIzZDA5MzQ4MDIyNGViMDdjMzZlZDdjZjk0OTM CSeq: 55 REGISTER Server: snomONE/5.0.10k Content-Length: 0 [5] 20130629163912: SIP 93.172.32.135:55773: No common cipher suite in client hello [5] 20130629163918: SIP 93.172.32.135:55774: No common cipher suite in client hello [5] 20130629163920: SIP Rx tcp:82.204.178.98:1107: " Therefore, I could assume that the issue is not related to the missing chain (but I could be wrong).

Looks like the issue with sessions is really fixed in 5.10k, no any complains about that since installation.

Hi The issue is that BRIA (Desktop version to be exact) and SnomOne are not compatible in terms of SSL Ciphers - when we are trying to use TLS with Bria and SnomOne, Bria unable to register with a message in the error log regarding ciphers incompatibility

What about the second issue? Users are not able to change their passwords using GUI. Pretty much annoying for many of them (they'd like to be able to change passwords from pre-generated)...

Perfect! Testing now. PBX system has been started with version 5.0.10k built on Jun 27 2013 at 21:10:59.

Yes, cookie deleting helps (at least with safari). Login page loading correctly, I'm able to log-in. Anyway, it is really hard to advise our users not to use "remember..."... Is it possible to fix the issue? May be not to store session information in a cookie? Or re-generate it in case the session is not exists anymore?

Ok, enabled IPv6. Rebooted the server. Tried to connect. Exactly the same story... CSS is broken, session is not exists, unable to login until browser cache cleared. http://gyazo.com/ea2052131dbf98dbc0b51311f5adfa2f "[5] 20130628162224: Session could not be restored"

Hi I'm really happy that the support forum works, hopefully we will get the fix soon The version is 5.10a and latest beta 5.10i (tried today), the behaviour is exactly the same. I tried to delete all configuration and made full reinstall - the result is the same. Session time is default one - 3600s What is more interesting, in case of something goes wrong - login web page is not loading properly / completely and the only way to restore - complete browser cache clear (it doesn't help with Firefox and I'm forced to delete Firefox data manually), however it works with Safari, Chrome and IE10 This is how it looks like (all browsers) - images are not loaded, broken CSS probably. http://gyazo.com/2d3585e5df095a0645828c77c23d2a00 Errors are exactly the same. BTW, we switched off an IPv6 stack... Is it possible it could be the reason?

"[5] 2013/06/28 10:55:17: Session could not be restored[5] 2013/06/28 10:55:18: Restoring existing session 8xl7xphp99ek4g62tb0o[5] 2013/06/28 10:55:18: Session could not be restored[5] 2013/06/28 10:55:18: Restoring existing session 8xl7xphp99ek4g62tb0o[5] 2013/06/28 10:55:18: Session could not be restored[5] 2013/06/28 10:55:19: Restoring existing session 8xl7xphp99ek4g62tb0o[5] 2013/06/28 10:55:19: Session could not be restored" A lot of issues. Probably, the session number is stored in a cookie, but the PBX behaviour is absolutely incorrect (no session -> new session to create but not to refuse to login)

I've tried to contact support team without any result - virtually all emails are simply ignored. Will try the support forum. We've got some very serious issues with web services 1) Very frequently users (including admin) are not able to log-in. Snom trying to re-use some non-existing session (last time user logged a day ago for example). "[5] 20130628091529: Restoring existing session 8xl7xphp99ek4g62tb0o [5] 20130628091529: Session could not be restored" And user is returned back (without any errors, silently) to the login screen. The only way to restore access is complete browser cache-reset. The same issue for Safari, Chrome, Firefox, IE. 2) Passwords could not be changed at user GUI, once again - no any errors, but passwords are simply not changing at all. Both issues are very serious.

BTW, just played with this option and Axis camera together - everything is fine, video is shown. Cool! There should be some attachment camera made for a snom phones to enable 2-way video

We've made that. Everything is Ok, provided files helps a lot. FW version is 8.3.2, 8.3.3 and 8.3.5