Jump to content

shapa

Members
  • Posts

    47
  • Joined

  • Last visited

Posts posted by shapa

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

  2. 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:
  3. 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...

  4. 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:
  5. 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

  6. 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).
  7. 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?

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

  9. "[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)

  10. 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.
×
×
  • Create New...