Page 1 of 2 12 LastLast
Results 1 to 10 of 12
  1. #1
    Master Untangler
    Join Date
    Jun 2015
    Location
    NW Arkansas
    Posts
    190

    Default Share SKYPE Bandwidth Control Settings?

    Hi - was wondering if anyone would be willing to share their SKYPE QoS or BANDWIDTH CONTROL app settings from their NGFW? I'm trying to prioritize the SKYPE VOIP traffic to improve my audio quality. My incoming audio is fine, but it appears I'm getting a red/bandwidth low/audio issue warning on calls and am told I am "crackling" periodically.

    I currently have APPLICATIONS - SKYPEBUS, SKYPEOUT and STUN set to HIGH priority and they are very high at top of list of my BANDWIDTH CONTROL rules list.

    Thanks in advance.
    Last edited by miles267; 04-28-2020 at 12:02 PM.

  2. #2
    Untanglit
    Join Date
    Nov 2016
    Posts
    19

    Default

    +1

    I'm interested in too
    miles267 likes this.

  3. #3
    Master Untangler
    Join Date
    Jun 2015
    Location
    NW Arkansas
    Posts
    190

    Default

    Also, I mostly use ZOOM, WEBEX and SKYPEBUS on a daily basis. I suspect whatever I'm doing incorrectly with SKYPE is likely consistent with the other web conferencing providers.

    Also, I currently have 100/20 Mbps cable service. Have set my QoS upstream/downstream limits to 85% or 85/17 Mbps. I've noticed I generally achieve my full bandwidth allowance as a business internet customer.

  4. #4
    Untanglit
    Join Date
    Nov 2016
    Posts
    19

    Default

    I'm use SkypeBus daily from Home Office. If there is any possible improvement on that like QoS it would be helpful. I often have problems while screen share, it took to long time to build up the picture and make it readable at all.

    What for cable equipment do you use, some 'older' Cable Modems / Router has a latency issue in regard to Puma6 Bug. You can test your cable connection here :
    http://www.dslreports.com/tools/puma6

  5. #5
    Master Untangler
    Join Date
    Jun 2015
    Location
    NW Arkansas
    Posts
    190

    Default

    Am using a SB6141 DOCSIS 3.0 modem. (probably upgrading to a SB8200 DOCSIS 3.1 even though my package doesn't need it yet)
    Last edited by miles267; 04-28-2020 at 12:55 PM.

  6. #6
    Untanglit
    Join Date
    Nov 2016
    Posts
    19

    Default

    It seems this modem is not affected by that issue
    Chipset is TNETC4830

  7. #7
    Untangle Ninja Jim.Alles's Avatar
    Join Date
    Jul 2008
    Location
    Central PA
    Posts
    2,012

    Default

    'VOIP' (generically speaking) doesn't require much bandwidth at all.
    It is extremely sensitive to jitter - the time variations visible with the above test.

    If you are using Wi-Fi well just stop. get a cabled connection to your router (switch)

    Although it is possible to mis-configure QoS, etc. resulting in tanking audio quality, I don't think I would start there.
    Also are you using a desktop/laptop/or mobile device? What O.S.?
    What version of NGFW?

  8. #8
    Master Untangler
    Join Date
    Jun 2015
    Location
    NW Arkansas
    Posts
    190

    Default

    Am using a Dell XPS laptop with Windows 10 and NGFW 15.0.

    Also I noticed each time I run that Puma 6 test, I get a "that's not good" result regardless of whether I'm on gigabit ethernet or 5 ghz Unifi wireless.

  9. #9
    Master Untangler
    Join Date
    Jun 2015
    Location
    NW Arkansas
    Posts
    190

    Default

    Today I'm noticing much video conferencing traffic is being classified as the Application = STUN. I've created a BANDWIDTH CONTROL rule to prioritize this APPLICATION = STUN as High priority except if it's PROTO CHAIN = /UDP/STUN/SSL/WEBRTC/FACEBOOK/FB_VOIP which the kids seem to be using.

  10. #10
    Untangle Ninja Jim.Alles's Avatar
    Join Date
    Jul 2008
    Location
    Central PA
    Posts
    2,012

    Default

    you might consider bypassing that conferencing traffic in NGFW, instead. [#config/network/bypass-rules]

    Post a screenshot of that 'puma' test for comparison, as I have not seen these before.
    My test is inconclusive - first, my ISP connection was not completely quiet. second, there were no values below 50ms
    puma.png

    Also, it is not the 'Puma test' that needs the hardwired connection, it is the video conferencing. The puma test is for a specific modem-hardware issue, not for your application.

    The jitter / ping test might also give us some clues.
    https://www.dslreports.com/tools/pingtest?
    Last edited by Jim.Alles; 04-29-2020 at 03:50 PM.

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

SEO by vBSEO 3.6.0 PL2