Jump to content

Article on how to register a counterpath Bria with snom ONE


Vodia support

Recommended Posts

 

Was looking at this for Android but it has mixed reviews and is a little pricey compared to other soft phones

 

It says it has extension presence. Does this mean I can see on the Bria app the other Snom One extensions including snom handsets busy state like a BLF key? Or does it just show a BLF of other Bria extensions?

Link to comment
Share on other sites

  • 3 weeks later...

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

Link to comment
Share on other sites

Bria actually checks the certificate, this is perfectly okay. What you need is to add the snom ONE certificate to the trust chain, then Bria can also work with TLS. You can check and do this by using your web browser and navigate to the snom ONE HTTP web interface and then use the browsers tools to add the certificate. Then Bria will also take it.

Link to comment
Share on other sites

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).
Link to comment
Share on other sites

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

Link to comment
Share on other sites

Okay... TLS_RSA_WITH_AES_256_CBC_SHA would be a candidate, however in TLS1.0 is it vulnerable anyway. RC4 might be old, but does not have the vulnerability. Is there any place where you can control what ciphers are being offered? We have to add TLS1.1 anyway, and then it makes sense to support the AES CBC modes as well.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...