none
Mitel 3300 ICP > Direct SIP Trunk into Lync > Intermittent Issues!

    Question

  • I am running Standard FE to support 150 or so users and another 40 with a DMZ Edge for VPN-less remote access and everything works great. HOWEVER, I am now dipping into Enterprise Voice and still very much in the testing phase and have an intermittent show-stopper.

    I aim to use Voice for a small number of users who travel abroad and for Webinar/Conferencing sessions hosted in Lync so anonymous participants can make use of the dialling in/dialling out features.  My testing consists of myself and three colleague's using Lync from our laptops to make outbound calls where we can. 

    Mostly it's perfect, the voice clarity is as expected and no latency or jitter on any calls - I have tested making from my laptop in India which was perfect (their networks can be bad!). 

    The issue I face is that our Mitel 3300 seems to drop the Sip Trunk only to re-connect it again 2 minutes later - but so very infrequently, perhaps once in every 30/40 calls but I really cannot be sure.   The trunk is configured to always be active and has no encryption (TCP 5068).

    I cannot replicate it, I cannot see a trend. 

    Please help me understand where to begin in terms of tracing this issue.  Mitel support is pretty crap and not forthcoming with any helpful answers or pointers.   We are not using the Live Business Gateway.  

    I have enabled CDR and have a backend database full of data.  I can see logs for the issue in tables:

    ErrorReport

    VoipDetails

    The VoipDetails log seems to suggest it was the user on the other end that disconnected my call ?

    A new user is created on each call as far as I can see, the UserUri reading differently each time like this:

    sip:hostname.fqdn.com@myco.co.uk;gruu;opaque=srvr:MediationServer:Mj7bKS9Ewl-Q1ahGJBBkZgAA;grid=93abb88b8ed34e839ae6901cca61b801

    Any info would be gratefully received.   Could anybody tell me how reliable this is from Lync point of view - Lync is pretty resillient for all other features.  


    Ash Cox

    Tuesday, July 17, 2012 2:22 PM

Answers

  • Ok, turned off Session Timers at both ends (Set to False on global trunk configuration in Lync & disabled in Mitel Sip Peer Trunk configuration).

    Where all Mitel > Lync calls were failing, they are now not!  Will post up some more findings as and when.... however what is the potential with not having timers on the trunks; the help suggests calls could get stuck if they are not closed down properly?

    Ash


    Ash Cox

    • Marked as answer by AshCox Friday, July 20, 2012 4:21 PM
    Thursday, July 19, 2012 7:50 AM

All replies

  • Hi,Ash,

    There isn't so much information for troubleshooting base on your description,if you could elaborate more on your Lync topology and background,also some error message on either Lync server or Mitel it will be more helpful for troubleshooting.

    Anyway,would you please verify that if Media Bypass and SIP Refer has been disabled on your trunk?

    Also please try to get sip traces with enabling Lync server logging tool(Select S4,Sipstack,MediationServer) if possible,the sip log file is very helpful when troubleshoot issues.

    By the way,please make sure your Lync server including Mediation server has fully patched,and the firmware of Mitel 3300 is up to date.

    B/R

    Sharon


    Sharon Shen

    TechNet Community Support

    ************************************************************************************************************************

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question.

    Wednesday, July 18, 2012 7:42 AM
    Moderator
  • I ran into a very similar issue with forwarding calls to Exchagne UM from Mitel 3300.  I am not sure if this will help or not.  I was having an issue where some of the calls were not going through but some were to exchange.

    Change the following on the SIP Trunk and see if it works:

    renegotiate
    SDP to enforce Symmetric Code must be enabled

    Let me know if this helps.  I have a project coming up where I am connecting Mitel to Lync.

    Wednesday, July 18, 2012 2:28 PM
  • Hi Sharon.
    Thank-you for your reply.

    I have started logging using the tool on the server and can see some messages pertaining to the disconnect, however not necessarily any pointer to the cause of the issue!?  Here are the SIP messages that occur just before the hang-up and terminal trunk fall over (which reconnects after two minutes on the Mitel side).

    ___________________________________________

    TL_INFO(TF_PROTOCOL) [1]0DDC.034C::07/18/2012-13:07:10.653.0077df84 (S4,SipMessage.DataLoggingHelper:sipmessage.cs(686))[3226646565]
    <<<<<<<<<<<<Incoming SipMessage c=[<SipTcpConnection_1B09586>], 128.1.1.55:5068<-MITEL3300PBX.NODE.LOCAL:1052
    BYE sip:128.1.1.55:5068;transport=Tcp;maddr=128.1.1.55;ms-opaque=a94ce23df2b31f6e SIP/2.0
    FROM: "+07xxxxxxxx08" <sip:+07xxxxxxxx08@MITEL3300PBX.NODE.LOCAL>;tag=0_653758512-92834029
    TO: <sip:+1602@SRVR--lync01.FQDN.INTERNALDOMAIN.COM>;tag=1b1cfad3ae;epid=D133614F3B
    CSEQ: 3 BYE
    CALL-ID: 653758512-92834027@MITEL3300PBX.NODE.LOCAL
    MAX-FORWARDS: 70
    VIA: SIP/2.0/TCP MITEL3300PBX.NODE.LOCAL:5060;branch=z9hG4bK771878512-92834034
    CONTENT-LENGTH: 0
    USER-AGENT: Mitel-3300-ICP 10.2.0.26_2
    ------------EndOfIncoming SipMessage


    TL_INFO(TF_PROTOCOL) [1]0DDC.1028::07/18/2012-13:07:10.657.0077df85 (S4,SipMessage.DataLoggingHelper:sipmessage.cs(613))[3226646565]
    >>>>>>>>>>>>Outgoing SipMessage c=[<SipTcpConnection_1B09586>], 128.1.1.55:5068->MITEL3300PBX.NODE.LOCAL:1052
    SIP/2.0 200 OK
    FROM: "+07xxxxxxxx08"<sip:+07xxxxxxxx08@MITEL3300PBX.NODE.LOCAL>;tag=0_653758512-92834029
    TO: <sip:+1602@SRVR--lync01.FQDN.INTERNALDOMAIN.COM>;tag=1b1cfad3ae;epid=D133614F3B
    CSEQ: 3 BYE
    CALL-ID: 653758512-92834027@MITEL3300PBX.NODE.LOCAL
    VIA: SIP/2.0/TCP MITEL3300PBX.NODE.LOCAL:5060;branch=z9hG4bK771878512-92834034
    CONTENT-LENGTH: 0
    SERVER: RTCC/4.0.0.0 MediationServer
    ------------EndOfOutgoing SipMessage


    TL_INFO(TF_PROTOCOL) [1]0DDC.1028::07/18/2012-13:07:10.657.0077df87 (MediationServer,GatewayCall.OnGatewayStateChanged:gatewaycall.cs(2413))(0000000001470153)$$START-MEDIATIONSERVER
    MediationCall: b5cf9e0e6231405597c2321ad2a47595
    CallId: 653758512-92834027@MITEL3300PBX.NODE.LOCAL
    From: sip:+07xxxxxxxx08@MITEL3300PBX.NODE.LOCAL
    To: sip:+1602@SRVR--lync01.FQDN.INTERNALDOMAIN.COM
    Direction: Inbound
    Start-Line: GatewayCall SignalingState is disconnected, reason is: TerminatedRemotely
    $$END-MEDIATIONSERVER


    TL_INFO(TF_PROTOCOL) [1]0DDC.1028::07/18/2012-13:07:10.759.0077df8c (MediationServer,ProxyCall.TerminateSession:proxycall.cs(3322))(00000000016B5AB2)$$START-MEDIATIONSERVER
    MediationCall: b5cf9e0e6231405597c2321ad2a47595
    CallId: 55b8e619-0742-4353-9a65-1487325699b7
    From: sip:SRVR--LYNC01.FQDN.INTERNALDOMAIN.COM@my-email.co.uk;gruu;opaque=srvr:MediationServer:Mj7bKS9Ewl-Q1ahGJBBkZgAA;grid=b5cf9e0e6231405597c2321ad2a47595
    To: sip:ashley.cox@my-email.co.uk;gruu;opaque=app:conf:audio-video:id:Q15J79P9
    Direction: Inbound
    Start-Line: Terminating Proxy side call with session state: Connected, sip-response: 200, ms-diag: 10027, ms-diag reason: Normal termination response from gateway after the call was established.
    $$END-MEDIATIONSERVER


    TL_INFO(TF_COMPONENT) [1]0DDC.1028::07/18/2012-13:07:10.759.0077df93 (MediationServer,MediationCall.Terminate:mediationcall.cs(271))(00000000025ECF99)$$START-MEDIATIONSERVER
    MediationCall: b5cf9e0e6231405597c2321ad2a47595
    CallId: 653758512-92834027@MITEL3300PBX.NODE.LOCAL
    From: sip:+07xxxxxxxx08@MITEL3300PBX.NODE.LOCAL
    To: sip:+1602@SRVR--LYNC01.FQDN.INTERNALDOMAIN.COM:5068;transport=tcp
    Direction: Inbound
    Start-Line: Mediation Call Terminate successfully.
    $$END-MEDIATIONSERVER



    TL_INFO(TF_COMPONENT) [1]0DDC.0E14::07/18/2012-13:07:10.759.0077df9b (MediationServer,MediaSessionAgent.TerminateMediaSession:mediasessionagent.cs(5315))(0000000001ACD1A8)$$START-MEDIATIONSERVER
    MediationCall: b5cf9e0e6231405597c2321ad2a47595
    CallId: 55b8e619-0742-4353-9a65-1487325699b7
    From: sip:SRVR--LYNC01.FQDN.INTERNALDOMAIN.COM@my-email.co.uk;gruu;opaque=srvr:MediationServer:Mj7bKS9Ewl-Q1ahGJBBkZgAA;grid=b5cf9e0e6231405597c2321ad2a47595
    To: sip:ashley.cox@my-email.co.uk;gruu;opaque=app:conf:audio-video:id:Q15J79P9
    Direction: Inbound
    Start-Line:  Terminating media session, reason: MediaSessionTerminated
    $$END-MEDIATIONSERVER



    TL_INFO(TF_COMPONENT) [1]0DDC.0E14::07/18/2012-13:07:10.759.0077df9c (MediationServer,MediaSessionAgent.SetNextState:mediasessionagent.cs(5491))(0000000001ACD1A8)$$START-MEDIATIONSERVER
    MediationCall: b5cf9e0e6231405597c2321ad2a47595
    CallId: 55b8e619-0742-4353-9a65-1487325699b7
    From: sip:SRVR--LYNC01.FQDN.INTERNALDOMAIN.COM@my-email.co.uk;gruu;opaque=srvr:MediationServer:Mj7bKS9Ewl-Q1ahGJBBkZgAA;grid=b5cf9e0e6231405597c2321ad2a47595
    To: sip:ashley.cox@my-email.co.uk;gruu;opaque=app:conf:audio-video:id:Q15J79P9
    Direction: Inbound
    Start-Line:  MediaSessionAgent state transition: Confirmed -> Terminated
    $$END-MEDIATIONSERVER

    ____________________________________________

    I can replicate this issue now too - but only when I initate calls from Mitel to Lync, calls travelling the other way tend to stay up but have been affected intermittently as I suggested in the opening post.

    I can delve deeper into the topology etc once you have shed some light (if any?!) on the above SIP messages?


    Ash Cox

    Wednesday, July 18, 2012 2:44 PM
  • I changed that setting, made no difference.   Will ensure all investigation results are posted up here for your upcoming project.  Am more than happy to assist/collaborate...! 

    Ash Cox

    Wednesday, July 18, 2012 2:51 PM
  • Ok, turned off Session Timers at both ends (Set to False on global trunk configuration in Lync & disabled in Mitel Sip Peer Trunk configuration).

    Where all Mitel > Lync calls were failing, they are now not!  Will post up some more findings as and when.... however what is the potential with not having timers on the trunks; the help suggests calls could get stuck if they are not closed down properly?

    Ash


    Ash Cox

    • Marked as answer by AshCox Friday, July 20, 2012 4:21 PM
    Thursday, July 19, 2012 7:50 AM