locked
Audio Delay when using SfB 2016 Client and Media Relay. Not the usual Suspects RRS feed

  • General discussion

  • Hi All.

    So I have a really interesting issue and I know its not a scenario many will come across but I will ask all the same.

    Even better, if you are so inclined to reproduce this scenario i'd be facinated to see what results you get.

    Before i start i'll say I have a reasonable amount of experience with Lync / SFB and this issue is NOT a mis-config on the edge routing which would be my first guess!! :-)

    Pre-face:

    The customer has a requirement to record internal Peer to Peer Calls. So we deployed a certified product to do so. This product is in no way responsible for the issue but has just generated the scenario where it happens. It blocks peer to peer and forces media relay. here goes:

    Scenario:

    2 Windows Workstations running O2016 SFB Client. Both register internally to SfB 2015 Server. They are on protected VLANs so cannot communicate Peer to Peer and have to use MRAS for media! This is important for recording audio, peer to peer is blocked by re-writting the candidate list, but for this scenario consider they just cannot communicate peer to peer. We use protected ports on our switch to achieve this.

    User A calls User B. User B answers immediately. No delay

    User A calls User B and User B answers aftter 3 seconds. 4-8 second delay in User A audio connecting

    User B calls User A and User A answers aftter 3 seconds. 4-8 second delay in User A audio connecting

    User A is internal, User B is external. If internal users intiates call there is a delay, if external user starts call. No delay.

    Both Users external, No delay

    Change SfB Client to anything but 2016.. No delay

    Involve a Polycom Handset, no issue.

    Call is answered in under 3 seconds, No issue.

    I beleive its is early media related in the 2016 client or some sort of re-negotiation but I cannot get any further.

    I initially suspected our network so even went to the point of building a new environment on dedicated Hyper-V server with only a direct connection of a single switch and I can re-produce the issue again and again.

    I would be hugely greatful for feedback or advise!

    Thanks

    Rob



    • Edited by Rob Davies1 Wednesday, July 19, 2017 9:03 PM
    Wednesday, July 19, 2017 8:46 PM

All replies

  • Hi Rob,

    serious problem. If you can reproduce the problem, I think only an SfB trace and a Wireshark trace can clarify this.

    Maybe something with the candidate list is wrong or the client chose the wrong candidate and therefore it takes longer to find the correct media path?


    regards Holger Technical Specialist UC

    Friday, July 21, 2017 11:30 AM
  • Hi Holger,

    Thanks for your reply. I have ran traces on the client, fe and edge and dont see anything.

    However there is 1 difference in the client logs from a call with the delay and a call without.

    There is a line as follows in the reinvite:

    PrelimConnChecksSucceeded=0 on a call with no delay

    PrelimConnChecksSucceeded=1 on a call with the delay

    As mentioned the only difference is in the legth of time taken to answer the call.

    Do you think this is in any way responsible?

    Regards

    Rob Davies

    Tuesday, July 25, 2017 9:54 AM
  • did you ever resolve this issue? we have a very similar issue with delay in answering of about 3 seconds

    we have a recorder we have developed internally that uses network level recording.

    Tuesday, August 21, 2018 3:11 PM