locked
Snom Phones drop with Internal Server error RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    We are using Smon 300 and 821 phones. We are on Snom firmware 8.72.16 
    We are experiencing drops from the Snom phones and the phone will display "internal server error". The senerio is internal calls Snom to Lync client or Snom to Snom calls will drop with "internal server error"

    We are not seeing errors from the Lync side other than Lync reports "52043 - Call terminated on hold failure"

    We never have a failure where it is PSTN inbound to SNOM. We never have any failures Lync Client to Lync Client.

    We do not have any errors in the Lync Server event logs and no error in the SIP traces other than Lync sees the call terminate.

    Anyone experiencing anything similar or have any clues to this issue. We have escalated to SNOM but at this time do not have a resolution.

    Thanks

    Steve

    Monday, May 7, 2012 1:50 PM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote

    In snomtastic we changed two settings.

    We set:
    set user_ice to on instead of off
    set send_prack to on instead of off

     Since we made those changes the Snom to Lync client drops have stopped. Prior to this change the connection was dropping consistantly at the 6 minute mark. We have been going now for serveral days without an issue.

    Steve

    • Marked as answer by SteveHDI Tuesday, May 22, 2012 2:20 PM
    Tuesday, May 22, 2012 2:19 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    We've seen odd issues with snom phones, but they should keep a call up.

    Can you grab a sip trace with logger and check what is happening

    thanks

    Tom Arbuthnot, Consultant Modality Systems
    Blog: Lync'd Up Blog Join over 300 UC Pros who subscribe for blog updates: Email or RSS
    Twitter @tomarbuthnot

    Monday, May 7, 2012 3:44 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    The drops are not easy to reproduce. It was easier to capture SIP traces from the phone log because we could immediately pull from the phone. Running the Lync logging tool sometimes calls would go excess of 15 minutes with out a drop so we gave up on the capture. When we were not running Lync logging sometimes the call would drop within 5 minutes. It is very hit and miss but what we determined was there was always a snom phone in the mix and it was an internal call.

    We can try and capture a trace and post it. Thanks again and if anyone else is experiencing similar issues of smom phones reporting "internal server error" please feel free to add imput if you have a resolution.

    Thank you.

    Steve

    Monday, May 7, 2012 4:45 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

    Is there any issue when trying to call from Lync Client to Snom phone? I suggest trying to enable logging tool with S4,SIPStack to  get detailed report.

    Logging tool:

    http://technet.microsoft.com/en-us/library/gg558599.aspx

    http://www.ultimate-communications.com/2010/11/how-to-troubleshoot-lync-using-lync-server-logging-tool-snooper-v4/

    In addition, please try to check if any required web service in IIS is missing. A resolved case for your reference:

    http://social.technet.microsoft.com/Forums/pl-PL/ocsvoice/thread/6f03d4de-5b07-4ba2-a682-523fc094cb83

    Regards,

    Kent

    Wednesday, May 9, 2012 1:44 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I found the internal server error message in the Lync trace with S4 and sip stack. I did not check any flags.

    Can anyone decifer an issue here?

    TL_INFO(TF_PROTOCOL) [0]0C8C.1084::05/09/2012-16:43:38.389.00009e8c (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(125))$$begin_record

    Trace-Correlation-Id: 1633091977

    Instance-Id: 000296DD

    Direction: incoming

    Peer: 10.228.18.131:55944

    Message-Type: response

    Start-Line: SIP/2.0 500 Server Internal Error

    From: "Tim Racioppa" <sip:TRACIOPPA@hanoverdirect.com>;tag=p02v23bbz5;epid=000413458FA001

    To: <sip:+17176333010@hanoverdirect.com;user=phone>;tag=7cfde70fb7;epid=259896278a

    CSeq: 2 INVITE

    Call-ID: 489daa4f4d64081a095b4307f5242929

    Via: SIP/2.0/TLS 10.141.3.5:5061;branch=z9hG4bK72755AEC.9F9D861BD9E38A3A;branched=FALSE;ms-internal-info="dvEWA504iGbXqerBPEUmGDmyoFlfuBY8bsU64-4tJEBHsbhp2f6XgG3wAA"

    Via: SIP/2.0/TLS 10.141.3.104:4257;branch=z9hG4bK-jbnadct8s9bx;rport;ms-received-port=4257;ms-received-cid=265E00

    Record-Route: <sip:lyncpool.hanoverdirect.lcl:5061;transport=tls;ms-fe=pa-lyncsrv1.hanoverdirect.lcl;opaque=state:T:F:Ci.R25de00:Ieh.btoUUCzElLstxJS7dcTQk-QZn3NKn9SweQDPcyXPqBz1K6k1x94WOxT4IQ9nkbhp2fOu-yBwAA;lr;ms-route-sig=dcruJVnuyFtl9mFlA_lDaYUmwvRU42Anlk7gxmYfq7LyQbhp2fOu-yBwAA>;tag=B5B797428A803C90352B003E1E4C96DC

    User-Agent: UCCAPI/4.0.7577.4053 OC/4.0.7577.4061 (Microsoft Lync 2010)

    ms-client-diagnostics: 52001;reason="Client side general processing error."

    Proxy-Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", opaque="C153227F", targetname="pa-lyncsrv1.hanoverdirect.lcl", crand="a93ec563", cnum="330", response="73249f669c547025cec72f715ead68fcea602c97"

    Content-Length: 0

    Message-Body: –

    $$end_record

    TL_INFO(TF_PROTOCOL) [0]0C8C.1084::05/09/2012-16:43:38.389.00009e8d (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(125))$$begin_record

    Trace-Correlation-Id: 1633091977

    Instance-Id: 000296DD

    Direction: outgoing

    Peer: 10.141.3.104:4257

    Message-Type: response

    Start-Line: SIP/2.0 500 Server Internal Error

    From: "Tim Racioppa" <sip:TRACIOPPA@hanoverdirect.com>;tag=p02v23bbz5;epid=000413458FA001

    To: <sip:+17176333010@hanoverdirect.com;user=phone>;tag=7cfde70fb7;epid=259896278a

    CSeq: 2 INVITE

    Call-ID: 489daa4f4d64081a095b4307f5242929

    Authentication-Info: NTLM qop="auth", opaque="41D3E2F8", srand="B0647BDE", snum="175", rspauth="010000006177ee12bb244b1564000000", targetname="pa-lyncsrv1.hanoverdirect.lcl", realm="SIP Communications Service", version=4

    Via: SIP/2.0/TLS 10.141.3.104:4257;branch=z9hG4bK-jbnadct8s9bx;rport;ms-received-port=4257;ms-received-cid=265E00

    User-Agent: UCCAPI/4.0.7577.4053 OC/4.0.7577.4061 (Microsoft Lync 2010)

    ms-client-diagnostics: 52001;reason="Client side general processing error."

    Content-Length: 0

    Message-Body: –

    $$end_record

                   

    Steve

    Wednesday, May 9, 2012 5:52 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

    Please make sure the latest updates have been installed. After installing updates, please restart Lync Front End Server.

    http://technet.microsoft.com/en-us/lync/gg131945

    Regards,

    Kent

    Wednesday, May 16, 2012 8:38 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Been there done that. We tracked it down to an issue with Snomtastic. There is a setting that is set by default that may be the problem. If we provision a phone manually it stays up. If we use Snomtastic the call last 6 minutes then terminated with "internal server error" We are unable to find the setting that cause this error. I am reaching out to see if anyone has had a similar experience

    Steve

    Wednesday, May 16, 2012 11:04 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi Steve,

    could you post the settings of your provisioned snom phones? Then we can have a look and see what setting might affect this error.

    Btw you can try our new BETA Apollo, it does not require the usage of snomtastic anymore - as it can do Software upgrade via lync and supports extension/pin sign in

    Cheers

    Tim

    Tuesday, May 22, 2012 9:32 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    In snomtastic we changed two settings.

    We set:
    set user_ice to on instead of off
    set send_prack to on instead of off

     Since we made those changes the Snom to Lync client drops have stopped. Prior to this change the connection was dropping consistantly at the 6 minute mark. We have been going now for serveral days without an issue.

    Steve

    • Marked as answer by SteveHDI Tuesday, May 22, 2012 2:20 PM
    Tuesday, May 22, 2012 2:19 PM