locked
Lync call quality issues due to big RTP packets sent by Lync in bursts RRS feed

  • Question

  • Hi Team,

    We have a SFB on-premises deployment wherein multiple countries that are using UCC / Lync for calls are complaining
    about bad quality and frequent disconnections. Sites with 2MB link bandwidth (and more, up to 6MB bandwidth) are having issues with big RTP packets that are being sent by Lync in bursts. This has result of dropping voice packets and degradation or disconnection of the service.

    What should be the ideal RTP packet size which we could configure on router to avoid this big RTP packet bursts and packet drops resulting due to it? Anything else we need to take care of?

    Thanks,
    Imran


    • Edited by Skype-imran Monday, December 11, 2017 7:25 PM
    Monday, December 11, 2017 7:24 PM

All replies

  • Hi Imran, 

    I am not sure if the problem is narrowed down, RTP bursts are majorly depends on user behavior. No application would hold RTP packets and create bursts.

    Size of RTP packets depends on ptime, Codec negotiated etc. RFC 3550 would give you more details about it. But its very dynamic depending on codecs etc. 

    Without having view of what is being negotiated in your scenario also what transport is used it's difficult to comment. But one way overheads on RTP could be reduced is making sure your Audio is on UDP and you have UDP connectivity available for users at these sites. If RTP has to go over TCP that would increase over heads on RTP packets thus making it consume more bandwidth and of course with TCP additional ACKs would also be there to contribute. 

    Thanks

    Amit

    • Proposed as answer by Alice-Wang Tuesday, December 12, 2017 6:43 AM
    Monday, December 11, 2017 8:37 PM
  • Hi Skype-imran,

    Agree with Amit_An.

    Based on your description, I understand that you had bad quality with your Lync call.

    In my opinion, you can use Lync Monitoring report to get the information because Lync monitoring server will provide CDR and QOE.

    I will share the following document for your reference

    http://communicationsknowledge.blogspot.sg/2015/07/how-to-improve-lync-skype-audio-call.html#!/2015/07/how-to-improve-lync-skype-audio-call.html

    Note: Microsoft is providing this information as a convenience to you. The sites are not controlled by Microsoft. Microsoft cannot make any representations regarding the quality, safety, or suitability of any software or information found there. Please make sure that you completely understand the risk before retrieving any suggestions from the above link.


    Regards,

    Alice Wang


    Please remember to mark the replies as answers if they helped.
    If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    • Proposed as answer by Alice-Wang Thursday, December 14, 2017 9:34 AM
    Tuesday, December 12, 2017 9:05 AM
  • Thanks Amit/Alice,

    This is a SFB on-premises set-up and for some reason SFB is using really big RTP packets, about 943 bytes, which are getting dropped by the "police" command on the cisco router. The token bucket size on the router is too small to allow the burst of these packets, however we cannot increase the token bucket size as this is against Cisco token bucket size recommendations.

    What can we specifically look at for this scenario?

    Thanks,
    Imran



    • Edited by Skype-imran Friday, December 15, 2017 10:24 AM
    Thursday, December 14, 2017 10:14 AM
  • You can also contact Cisco to confirm it
    Monday, December 18, 2017 7:33 AM
  • Skype_Imran

    In this situation, I would check with network capture at client PC, and CISCO taken in parallel to confirm and compare with negotiated codec form client logs. 

    To get complete picture if its actually originated by client then what was probable reason behind it, and there is no intermediate network entity which may be adding / altering packet before reaching to CISCO. 

    • Proposed as answer by Alice-Wang Wednesday, December 20, 2017 5:54 AM
    Tuesday, December 19, 2017 4:08 PM