locked
Intermittent Outbound Voice Issue - no outbound audio RRS feed

  • Question

  • I am having in intermittent issues with outbound calls via SIP Trunk.  We have a SonicWall NSA 3500 between the Lync Server with a co-located front end and mediation server and the network.  The appropriate ports are all open according to my provider.

    The problem is not consistent, but seems to occur on about 20% of outbound calls where we can hear the outside party but they can not hear us.  Hanging up and calling again results in a successful call about 95% of the time.

    Other than leaving tracing running all the time, what should I be looking at?

    Thanks


    • Edited by EvanAtDSI Saturday, March 2, 2013 4:31 PM typo
    Friday, March 1, 2013 9:22 PM

All replies

  • I am having in intermittent issues with outbound calls via SIP Trunk.  We have a SonicWall NSA 3500 between the Lync Server with a co-located front end and mediation server and the network.  The appropriate ports are all open according to my provider.

    The problem is not consistent, but seems to occur on about 20% of outbound calls where we can hear the outside party but they can not hear us.  Hanging up and calling again results in a successful call about 95% of the time.

    Other than leaving tracing running all the time, what should I be looking at?

    Thanks


    Do you have sonicwalls on the far side of some of the sites you're tying to connect to?  Are you on hold with Sonicwall as well?  We're also having issues with one way audio between out NSA 3500 and TZ-200W's.  Seems the NSA is randomizing destination/source ports, the sonicwalls on the far side are for some reason unable to recognize this and change translate the ports to the correct destination

    "To understand the complexities of why VoIP becomes such an issue for the Sonicwall to handle correctly one must understand that the SonicWall firewall router will NAT outbound port numbers to different values.  The SonicWall does provide a "Consistent NAT" option to help resolve this issue, but this does not correct the fact that port numbers are actually changed.  Changing outbound port numbers will cause issues with the VoIP traffic.  These issues can result in one-way audio and dropped calls."

    We're able to get two way audio with our NSA and any other generic networking device (linksys) besides a sonicwall on the far end. 

    Sunday, March 3, 2013 10:01 PM
  • Hi,

    How many NICs are there in the Lync FE server which collocates with Mediation role?

    If there are two NICs in the Lync FE server, please make sure their IP address are in the different subnets.

    Please have a test to connect SIP Trunk without the Sonicwall device then check the issue again.


    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. This can be beneficial to other community members reading the thread.

    Sean Xiao
    TechNet Community Support

    Tuesday, March 5, 2013 6:13 AM
  • I am having in intermittent issues with outbound calls via SIP Trunk.  We have a SonicWall NSA 3500 between the Lync Server with a co-located front end and mediation server and the network.  The appropriate ports are all open according to my provider.

    The problem is not consistent, but seems to occur on about 20% of outbound calls where we can hear the outside party but they can not hear us.  Hanging up and calling again results in a successful call about 95% of the time.

    Other than leaving tracing running all the time, what should I be looking at?

    Thanks


    Hi Evant, basically this is why you need an SBC and preferably one approved by Microsoft, the SBC will understand the NAT and will open and close ports dinamically instead of opening (permanently) ports on your firewall to/from mediation/frontend server. An SBC will also protect you against other type of unwanted traffic that you might not be aware of (malicious attacks, register and invite flooding, etc)

    Check for approved SBCs at

     http://technet.microsoft.com/en-us/lync/gg131938#tab=5

    Regards

    Gino

    Tuesday, March 5, 2013 11:19 AM
  • Hi,

    How many NICs are there in the Lync FE server which collocates with Mediation role?

    If there are two NICs in the Lync FE server, please make sure their IP address are in the different subnets.

    Please have a test to connect SIP Trunk without the Sonicwall device then check the issue again.

    Hi Sean,

    There is only one NIC in the FE server.  This is a VM sitting on our production cluster and the SonicWall is our edge router so there is no easy way to directly connect the FE directly. If this was a consistent issue I could try it over a weekend but there is no way I can do this for an intermittent issue.

    Tuesday, March 5, 2013 2:51 PM
  • Hi Evant, basically this is why you need an SBC and preferably one approved by Microsoft, the SBC will understand the NAT and will open and close ports dinamically instead of opening (permanently) ports on your firewall to/from mediation/frontend server. An SBC will also protect you against other type of unwanted traffic that you might not be aware of (malicious attacks, register and invite flooding, etc)

    Check for approved SBCs at

     http://technet.microsoft.com/en-us/lync/gg131938#tab=5

    Regards

    Gino

    Gino,

    Direct SIP Trunking is supported by Lync.  I have a small implementation - under 30 users with no more than 8 SIP trunks concurrently - and I believe that an SBC is overkill here.

    Tuesday, March 5, 2013 3:01 PM
  • Do you have sonicwalls on the far side of some of the sites you're tying to connect to?  Are you on hold with Sonicwall as well?  We're also having issues with one way audio between out NSA 3500 and TZ-200W's.  Seems the NSA is randomizing destination/source ports, the sonicwalls on the far side are for some reason unable to recognize this and change translate the ports to the correct destination

    "To understand the complexities of why VoIP becomes such an issue for the Sonicwall to handle correctly one must understand that the SonicWall firewall router will NAT outbound port numbers to different values.  The SonicWall does provide a "Consistent NAT" option to help resolve this issue, but this does not correct the fact that port numbers are actually changed.  Changing outbound port numbers will cause issues with the VoIP traffic.  These issues can result in one-way audio and dropped calls."

    We're able to get two way audio with our NSA and any other generic networking device (linksys) besides a sonicwall on the far end. 

    My understanding from http://windowspbx.blogspot.ca/2012/03/everything-you-wanted-to-know-about.html is that Consistent NAT is not used with the SonicWall and Lync. 

    Taking another look at this blog, I have disabled Central Media Processing and Media Bypass and then restarted the Mediation service to see if this resolves the issue.

    Tuesday, March 5, 2013 3:08 PM
  • Hi Evant, basically this is why you need an SBC and preferably one approved by Microsoft, the SBC will understand the NAT and will open and close ports dinamically instead of opening (permanently) ports on your firewall to/from mediation/frontend server. An SBC will also protect you against other type of unwanted traffic that you might not be aware of (malicious attacks, register and invite flooding, etc)

    Check for approved SBCs at

     http://technet.microsoft.com/en-us/lync/gg131938#tab=5

    Regards

    Gino

    Gino,

    Direct SIP Trunking is supported by Lync.  I have a small implementation - under 30 users with no more than 8 SIP trunks concurrently - and I believe that an SBC is overkill here.

    Hi again, then I think the fastest way to troubleshoot is the very same that you are avoiding... Take a capture capture between Lync and firewall, until you discover of a call that went bad, the issue would only be that the capture would turn really big (or not if you find one quickly), a small inexpensive switch with port mirroring or even the same Lync server (unless you are using TLS to ITSP of course)

    Monday, March 11, 2013 3:46 PM
  • Hi, Was there a fix or was this resolved ?

    Thanks


    Murali Krishnan| My blogs: UnifiedMe | Twitter: @Mkris9

    Thursday, September 12, 2013 4:02 PM