locked
Response Group Delay When Edge Enabled RRS feed

  • Question

  • Hi,

    I've read a lot on this including posts on these forums but none quite match the behaviour I'm seeing. I've done quite a few OCS & Lync installs so I'm well aware of the Lync Phone Edition delays when picking up response groups. This is different and effects everyone at this client, Lync phone edition or soft client.

    The delay when picking up a response group is around 7-8s. Direct call is less than 1s. Before I enabled Edge (I suspect the key) response group connect times were 1-2 seconds. The delays are roughly the same whether dialling in from the PSTN, Lync-to-Lync or via federation.

    I've used the Lync protocols workflow poster to double check all ports and routing and is good as far as I can see. Nothing is logged in the event viewer on any server involved to suggest an issue. I've ran Wireshark on the client machine I'm using for testing and traffic goes to and from the Edge server fine.

    I'm sure the Edge is key but all looks good to me and everything can see each other fine, certificates etc all appear valid and good.

    Any suggestions?

    Update - Through edge snooping I can see there's about a 4 second delay in the call where there's nothing happening in SIP. Edge -> FE goes via TMG. Not sure if this is factor.

    Pete


    Thursday, April 5, 2012 10:42 AM

Answers

  • Cracked it. The cause wasn't what was proposed but you got me looking in the right direction. It was the web proxy filtering on the TCP 443 traffic. Disabled this in TMG and call connection times are back to normal. Screen below for info. Thanks all for you help.

    PP

    Monday, April 9, 2012 2:22 PM

All replies

  • This kind of delay is almost always an issue with setting up the the media path from each client to the internal Edge interface. You should verify your clients can contact the internal Edge interface on TCP 443 and UDP 3478, and validate the Edge can actually route a response back to them (may require static route statements on your Edge server)

    Thursday, April 5, 2012 5:45 PM
  • Checked both and they're fine. Have done a Wireshark on both the Edge server (internal interface) and the client and traffic flows fine. It hadn't OK, I fixed this and expected this to fix the delay but it didn't. Both can route to each other OK.

    Any other suggestions or a way to better troubleshoot it? Lync logging just shows a delay but didn't show why.

    Thursday, April 5, 2012 5:50 PM
  • Are you using HLB for Edge ?

    If so for troubleshooting bypass the HLB for the internal interface .. point the clients and servers directly to internal interface and check.

    Also make sure udp 3478 and tcp 443 are open from nternal network to each edge servers Internal IP.

    -Santosh

    Friday, April 6, 2012 4:49 AM
  • No HLB involved, it's a fairly simple Edge deployment. Client machines can access the internal side of the edge fine. Checked this in Wireshark and packets and flowing to and from the internal side of the Edge fine.

    P

    Friday, April 6, 2012 4:25 PM
  • Hi,Peter,

    Sounds like an Edge connectivity problem,maybe client side antivirus blocking the connectivity to the edge or internal Edge certificate misconfiguration.Would you please try to turn off the antivirus on your client or modify it allow traffic to Edge server?Also please verify your internal Edge server certificate,the CN should be the FQDN of your internal Edge server and the SAN shoule be null.

    Hope this help.

    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.


    Monday, April 9, 2012 6:14 AM
  • Hi,

    Disabled Sophos (the installed AV) on the client to no avail. I can confirm the Edge internal side certificate only has a common name - the FQDN of the server, no SANs.

    Any ideas?

    Thanks,

    PP

    Monday, April 9, 2012 2:16 PM
  • Cracked it. The cause wasn't what was proposed but you got me looking in the right direction. It was the web proxy filtering on the TCP 443 traffic. Disabled this in TMG and call connection times are back to normal. Screen below for info. Thanks all for you help.

    PP

    Monday, April 9, 2012 2:22 PM
  • Glad you figured it out.

    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.

    Tuesday, April 10, 2012 9:50 AM
  • A bit late to the party but i am seeing the same behaviour when using tmg as the link between the edge and front end server.

    I would be interested to know what sort of rules you have used on the TMG server to set it up.

    Wednesday, May 30, 2012 9:27 AM
  • I generally prefer hardware firewalls but this setup was already in place. TMG had about 5 NICs and was massively over complicated. Anyway, post seperately for advice on this.

    PP

    Wednesday, May 30, 2012 9:49 AM