Дауыс пен бейнеқоңырауларға арналған QoS: желіде баптау және тексеру

Қоңыраулар мен бейне кездесулерде не бұзылады және неге\n\nДауыста және бейнебайланыста пайдаланушылар ең жиі былайша шағымданады: «сөйлеген адам робот сияқты», «сөздер жоғалады», «эхо», «бейне пиксельдерге бөлініп қалады», «картинка тұрып қалады», «кейде естілмейді, кейде естіледі», «экран бөлісуді қосқанда созвон үзіліп қалады». Тест жылдамдығы жақсы көрсетіп тұрғанымен де мәселе сақталуы мүмкін.\n\nКөбіне мәселе «ішкі арнада» емес, трафиктің желі құралдарында қалай кезекке тұратынында. Қайда да бірде перегрузка пайда болса (WAN, коммутатордың uplink-і, Wi‑Fi, VPN-шлюз), пакеттер жинала бастайды. Дауыс пен видео үшін ең маңыздысы — болжамдылық, рекордтық өткізу қабілеті емес.\n\nАжыратып алған дұрыс үш нәрсе бар:\n\n- Кешігу: пакет сізден қарсыға дейін қанша уақыт барады.\n- Джиттер: пакеттер арасындағы кешігулердің қаншалықты «жылжып» отыруы.\n- Жоғалтулар: қанша пакет мүлдем жетпей қалғаны.\n\nТіпті аздап жоғалтулар мен джиттер «бірнеше мегабиттен аз» дегеннен гөрі айқын көрінеді. Дауыстың өзі кейбір рет жоғалтуларды жасыруы мүмкін, бірақ қатарлы жоғалтуларда үзілістер мен роботталған дауыс пайда болады. Интерактивті бейне кешігуді нашар көтереді және кадрлар уақытында құрастыра алмаса, тез артефакті көрсетеді.\n\nПриоритет болмаса, дауыс пен видео кез келген "қалың" трафикпен бәсекелейді: файлдарды жүктеу, жаңартулар, резервтік көшіру, бұлтты синхронизация. Мысал: бухгалтерияда желілік сақтауқа бэкап басталады, коммутатордың uplink-і бітеліп, кезек өсіп, басшының қоңырауы үзіліп-қосылатын фрагменттерге айналады.\n\nДауыс пен бейне үшін QoS мәселені «интернетті жылдамдату» арқылы емес, ережелер арқылы шешеді: не маңызды, трафикті қалай белгілеу және қай кезекке қою керек, сонда жоғары жүктеме кезінде әуелі сөйлесу пакеттери өтеді, аударымдар емес.\n\n## Қандай көрсеткіштер қалыпты және нені өлшеу керек\n\nКезектер мен приоритезация шын мәнінде жұмыс істеуі үшін алдын ала қандай сандарды «жақсы» деп санауға болатынын және оларды қалай өлшеу керектігін келіскен жөн. Әйтпесе ережелерді баптап, кейін жақсарғанын дәлелдей алмайсыз.\n\n### Дауыс пен бейне үшін негізгі метрикалар\n\nӘңгімелер мен кездесулер сапасы үшін әдетте кешігу, джиттер және жоғалтулар маңызды. Олар тікелей «роботталған» дыбысқа, сөздердің үзілуіне және бейненің бұзылуына әкеледі.\n\nВендорға байланбайтын нұсқаулар:\n\n- Кешігу (one-way): дауыс үшін 150 мс-ке дейін қалаулы, видеоға көбінесе 200 мс-ке дейін шыдамды есептеледі.\n- Джиттер: дауыс үшін 20–30 мс-ке дейін жақсы, видео үшін 30–50 мс.\n- Жоғалтулар: дауыс үшін 0–1% деңгейінде ұстауға тырысыңыз, видео шамалы 1%-те де байқалуы мүмкін (әсіресе шоқтарда).\n\nҚосымша пайдалы индикаторлар: қайта жіберулер (қол жетімді жерде) және кезектердегі қысқа шоқтар. Көп жағдайда интерфейстің шығысында орналасқан кезек проблема көзі болады.\n\nБұл мәндер «сиқырлы» емес. Негізгісі — олар тұрақты болып, шоқтарға ұшырамауы.\n\n### Неліктен тұрақтылық маңызды, орташа емес\n\nОрташа кешігу 30 мс тамаша көрінуі мүмкін, бірақ минут сайын 300 мс-ге дейін шығатын бір шоқ болса, адамдар әлі де бір-бірін сөккізіп, қайта сұрайтын болады. Сондықтан тек average емес, 95-перцентильді, максимумды және шоқтардың жиілігін қараңыз.\n\nТүпкі мысал: үлкен файлдарды көшіру кезінде орташа жоғалту нөлге жақын болуы мүмкін, бірақ әр 10–20 секунд сайын қысқа шоқтар пайда болып, дәл сол сәттерде пайдаланушылар шағымданады, әдеттегі «орташа бәрі жақсы» болғанымен.\n\n### Тұрақты түрде қадағалауға болатын 2–3 метрика\n\nГрафиктер арасында адаспау үшін минимумды ұстап отырыңыз:\n\n- дауыс трафигі үшін джиттер мен жоғалтулар;\n- негізгі WAN-интерфейс немесе интернет стығында кешігу (және p95);\n- шығыс интерфейстердегі кезек ұзындығы және drops.\n\nОсылай приоритезациядан кейін жағдайдың жақсарғанын және қай жерде сапа бұзылатынын анықтау оңайырақ болады.\n\n## Инвентаризация: дауыс пен бейне желінің қай бөліктерінен өтеді\n\nБаптауды бастамас бұрын трафиктің жолдарын жасаңыз: қай жерде пайда болады және қай құрылғылар арқылы өтеді. Әйтпесе QoS-ты «желі бойынша» баптайсыз, ал мәселе бір жүктелген коммутаторда, WAN-каналда немесе Wi‑Fi-де қалады.\n\nКөздерден бастаңыз. Дауыс пен видео тек IP-телефондар ғана емес: ноутбуктегі softphone-дар, конференц-жүйелер, корпоративтік Wi‑Fi-дегі мобильді клиенттер, кейде серверлік компоненттер (шлюзтар, SBC, жазу жүйелері, VDI) болады. Әр көз үшін байланысты типті (сымсыз/сымды/VPN) және «бірінші секірісті» (access-коммутатор, Wi‑Fi контроллері, VPN-шлюз) білу маңызды.\n\nСодан кейін бағыттарды тіркеңіз: кеңседе ішкі, филиалдар арасында, ДЦ-ға, бұлтқа, интернетке. Бір пайдаланушы әртүрлі сценарийлерде сөйлесуі мүмкін, және бұл жолдар желіні әртүрлі жүктейді.\n\nЖылдам маршрут картасын және тар жерлерді 1–2 сағат ішінде жинауға болады:\n\n- маңызды аймақтарды белгілеңіз (колл-центр, переговорные, қабылдау, оқу бөлмелері);\n- қай порттарда телефондар мен конференц-жүйелер отырғанын коммутатордан табыңыз (MAC/LLDP, порт сипаттамалары);\n- жылдамдықтың төмендеуі мүмкін нүктелерді жазыңыз: 1G аплинктер, перегруженные межVLAN-интерфейстері, WAN, VPN, Wi‑Fi;\n- осы интерфейстердегі ағымдағы жүктемені және қателерді алыңыз (шоқтар, drops, кезектер);\n- 2–3 типтік қоңырау/видеокездесу сценарийін және олардың маршруттарын сипаттаңыз.\n\nАғыстарды бөлек қарастырыңыз. Медиа (RTP/SRTP) ең маңызды: бұл кешігулер мен жоғалтуларға өте сезімтал. Сигнализация (SIP, бұлттық қызметтер үшін HTTPS) әдетте көлем бойынша аз, бірақ оның істен шығуы «телефон шалмайды» сияқты көрінуі мүмкін.\n\nПрактикалық мысал: филиал мен ДЦ арасындағы видеокездесулер VPN арқылы өтсе, ал IP-телефония тікелей MPLS арқылы жүрсе, егер сіз тек IP-телефонияны бақыласаңыз, видео VPN-шлюзінде приоритет жоғалуын өткізіп жібересіз.\n\n## Трафикті маркировкалау: DSCP және 802.1p шатаспай\n\nDSCP және 802.1p маркировкасы — пакеттерді белгілеудің тәсілі, сол арқылы коммутаторлар мен маршрутизаторлар не бірінші өтуі тиіс екенін біледі. Әдетте IP заголовогындағы DSCP (3-ші деңгей) және VLAN-тегіндегі 802.1p/CoS (2-ші деңгей) қолданылады. Маңыздысы — дұрыс сандарды таңдау ғана емес, меткалардың бір жерде қойылуы, жол бойында сақталуы және барлық түйіндерде бірдей түсіндірілуі.\n\nEndpoints, қосылу нүктелері, коммутаторлар мен шлюздер арасында қысқа сыныптар жиынтығын келісіп алсаңыз ыңғайлы. Типтік минимум:\n\n- дауыc (RTP): DSCP EF (46), CoS 5\n- видео (кездесулер/RTP): DSCP AF41 (34), CoS 4\n- сигнализация (SIP/H.323): DSCP CS3 (24), CoS 3\n- «басқа барлығы»: DSCP 0, CoS 0\n\n### Меткаларды қай жерде қою керек\n\nИдеал — метканы көз қояды: IP-телефон немесе видеоклиент, егер ол қабілетті болса. Бірақ кейбір клиенттер қателеседі немесе намеренно приоритетті үлкейтіп жібереді. Сондықтан практикалық түрде метканы жиі access-портта түзетеді: коммутатор немесе Wi‑Fi контроллері VLAN, порт, ACL, NBAR арқылы ағымды классификациялап, сосын DSCP/CoS қояды.\n\nWAN-шлюзта (немесе шекаралық маршрутизаторда) маркировканы тексеріп, қажет болса қайта метка қою адатта жасалады — дәл сол жерде кезектер мен арналар басталады.\n\n### Сенім шекарасы (trust boundary)\n\nTrust boundary — меткаға «сенетін» және оны өзгертпейтін орын. Жақсы ереже: тек басқарылатын құрылғыларға сеніңіз (IP‑телефондар, корпоративтік бейнетерминалдар), ал қалғанын кіреберісте қайта маркировкалаңыз.\n\nМетка жол бойында жоғалмай тұруы үшін қарапайым логика көмектеседі:\n\n- телефонға қосылған порттарда — телефонға trust, бірақ телефон артындағы ПК-ға емес (PC-port);\n- пайдаланушы порттарында — trust қоспау, классификация және маркировка коммутаторда;\n- trunk-тарда — CoS сақтау және қажет болса CoS \u003c-> DSCP сопоставление;\n- Wi‑Fi/VPN-де — инкапсуляция кезінде DSCP «обнуланбайтынына» көз жеткізу;\n- WAN-шеңінде — сыныптар кестесі бірыңғай және екі жақта DSCP мәндері бірдей болу керек.\n\nМысал: ноутбуктегі видеоклиент дауыс үшін DSCP 46 жіберсе, оған сенбеу керек. Access-те оны AF41-ге қайта меткалап, приоритет беріңіз, бірақ сөйлеуді ығыстырмайтындай шектеу қойыңыз.\n\n## Кезектер және жоспарлаушылар: приоритетті қалай беру керек\n\nQoS кезектері көбінесе интерфейстің шығуында (egress) әсер етеді, ал кіріс жағы онша тиімді емес. Шығаруда құрылғы дәл қашан қандай пакет жіберілетінін шешеді және пакеттерді тәртіпке келтіре алады. Кіріс кезінде пакеттер қазірдің өзінде келген, ал егер порт бітелген болса, тек шектеу, буферлеу немесе тастау қалады.\n\nИдея қарапайым: дауысқа минималды джиттер керек, бейне үшін жоғалтуларды азайту маңызды, ал қалған трафикке сәл күтуге болады. Кәдімгі схема — өте сезімтал трафик үшін приоритеттік кезек және қалғанына салмақталған кезектерді бірге қолдану.\n\n### Әдеттегі жұмыс істейтін кезектер схемасы\n\nБұл «жалғыз дұрыс» емес, бірақ бастауға түсінікті нұсқа:\n\n- дауыc үшін приоритеттік кезек (LLQ) — ең алдымен қызмет көрсетіледі, бірақ өткізу шегі қатаң қойылады;\n- видео үшін бөлек кезек — кепілдік берілген үлес және жоғарғы шегі;\n- бизнес-бағдарламаларға салмақталған кезек — абсолютті приоритетсіз;\n- «барлығы қалғаны» — ең төменгі, бірақ нөл емес.\n\nДауыс пен видеоны «оңаша арнаға» бөлуді көзсіз жасамаңыз. Егер видеоға тым көп өткізу берсеңіз, ол басқа қосымшаларды сығыстыра бастайды. Егер дауысқа шектеусіз приоритет берсеңіз, қате маркировка арқылы кез келген трафик «дауыс сияқтан» шығып, бәрін ығыстыруы мүмкін.\n\n### Burst-трафиктен аман қалу қарапайым әдістері\n\nBurst — трафик жарылыстары (жаңартулар, бэкаптар, үлкен файлдар) болғанда шығады. Екі негізгі құрал тез әсер беріп жатады:\n\n- Шейпинг: жіберуді тегістеп, оны уақытқа созады. WAN-да пайдалы, порт нақты арнадан тезірек болғанда.\n- Полисинг: ағымды қатты шектейді. Кіріс жағында тиімдірек, өйткені планировщик көмектесе алмайтын жерде керек.\n\nWRED-ті «ерте ақылды тастау» деп түсінуге болады: кезек толып жатқанда құрылғы маңызды емес трафиктің бір бөлігін алдын-ала тастайды, толық кептіруге дейін жеткізбей, осылайша фондық ағымдардың баяулауына ықпал етеді және дауыс пен бейне үшін орын қалдырады.\n\n## WAN және интернет-каналдар: шейпинг пен полисинг\n\nLAN-да таршылық көбіне коммутатор порттарында болады, және онда приоритезация сенімді жұмыс істейді. WAN-да бәрі күрделі: арна шектелген және провайдер өз ережелерін қолдануы мүмкін. Internet/MPLS шетінде кешігулер, джиттер және жоғалтулар жиі пайда болады.\n\nНегізгі ой: кезек пен пакеттерді тастау сіздің өз маршрутизаторда болуы жақсырақ, провайдерде емес. Сондықтан WAN-шығысында әдетте шейпинг қойып, шекті нақты каналдың өткізу қабілетінен сәл төмен қояды.\n\nПрактикада жылдамдықты баптау:\n\n- келісім-шарттық және нақты жылдамдықты анықтаңыз (түрлі уақыттарда тексеріңіз);\n- шейперді кепілдендірілген жылдамдықтың 90–95%-ына қойыңыз, провайдердің полисингіне түсіп қалмау үшін;\n- шейперге дейін кезектер мен приоритеттерді қолданыңыз, сонда жоғары приоритетті дауыс/видео бітелгенде бірінші шығады;\n- upload және download үшін бөлек тексеріңіз (көбіне upload қатты ауырады).\n\nҚатты полисинг (әсіресе кенеттен cut-пен) дауыс пен видеоға қауіпті. Ол пакеттерді секіріп тастайды, біркелкі емес жоғалтулар туғызады, нәтижесінде джиттер өседі және дауыс «роботтанады», бейнеде артефактілер пайда болады. Егер полисинг қажет болса (мысалы, қонақтарға немесе ауыр бэкаптарға шектеу қою үшін), оны маңызды емес сыныптарға қойыңыз, ал критикалық трафик шейпингте болсын.\n\nТағы бір тұзақ — инкапсуляцияның қосымша шығындары. PPPoE, VLAN-тегтер, GRE/IPsec, L2TP сияқты туннельдер пайдалы өткізу қабілетін төмендетіп, кадр өлшемін өзгертеді. Егер жылдамдықты «тегіс» есептесеңіз, шейпер нақты желіден жоғары шығып, провайдерде жоғалтулар басталады. Әдетте 5–10% қор және VPN белсенді кезде нақты MTU/MSS тексерісі көмектеседі.\n\nМысал: филиал 50 Мбит/с-пен қосылған, бірақ барлық трафик IPsec арқылы өтіп жатыр. Егер шейпингті дәл 50-ге қойсаңыз, провайдер жүктелгенде пакеттерді кесіп қояды, және видеоқоңыраулар бірінші сезеді. 45–47 Мбит/с шейпинг және приоритетті кезектер көбіне теңгерімді сапа береді.\n\n## Wi‑Fi және VPN: соңғы милияда приоритетті жоғалтпау\n\nКоммутаторларда және WAN-да кезектер бапталған болса да, сапа жиі соңғы милияда — Wi‑Fi және VPN-де құлайды. Сол жерлерде приоритет оңай жоғалады, кешігу мен джиттер кенеттен өседі.\n\nWi‑Fi-де WMM (Wi‑Fi Multimedia) қолдауы шешуші — бұл беспроводной қолжетімділікте кезектер мен приоритет механизмдері. Егер WMM өшірілсе немесе дұрыс жұмыс істемесе, дауыс пен видео тек қана жүктемелермен тең дәрежеде бәсекелейді: бір ноутбук жүктемені бастаса, қоңырауда паузалар, «робот» және бұзылған кескін пайда болуы мүмкін.\n\n### Wi‑Fi: роуминг және AP-тың жүктелуі\n\nДжиттер тек арнадан ғана емес, радиоқоршаған ортадан да шығады. Точкадан точкага роуминг уақыт алуы мүмкін, ал бір нүкте өте жүктелген болса, кезек өсіп, пакеттер «топталып» келеді. Типтік сценарий: переговорная бөлмеде 15 адам видеокездесу өткізіп отыр, тағы бірнеше қонақ жаңартуларды жүктеп жатыр.\n\nКонтроллерден немесе AP-тан қарау керек нәрселер:\n\n- қажетті SSID-де WMM қосылған ба;\n- бір AP-да қанша клиент және airtime/utilization қандай;\n- қоңырау кезінде AP арасында жиі ауысулар бар ма;\n- помехалар немесе әлсіз сигнал салдарынан retries көп пе.\n\n### VPN: DSCP қай жерде жоғалады және қалай тексеруге болады\n\nVPN-де приоритет екі жерде «жұқа» болуы мүмкін: шифрлау кезінде (сыртқы заголовок қажетті маркировканы тасымалдамайды) және желі шекарасында (провайдер немесе құрал DSCP-ты обнулейді). Кейде оңайырақ: туннель ішінде метка бар, бірақ сыртқа шығарда жоқ, сондықтан әрі қарай бәрі best effort болады.\n\nОны лабораториясыз тексеру: тесттік қоңырау қойып, параллель фондық жүктеме жасайсыз және туннельге дейін және туннельден кейін трафикті ұстап (packet capture) салыстырасыз. RTP/бейне пакеттеріндегі және туннель сыртындағы сыртқы заголовоктағы DSCP-ты салыстырыңыз. Егер меткалар жоғалса, VPN-шлюзта қайта меткалау мен шығыс интерфейске кезектер қою қажет.\n\nҚашықтағы пайдаланушылар үшін бақылау шекараларын түсіну маңызды. Сіздің жағыңызда — VPN-шлюз, корпоративтік Wi‑Fi және шекаралық маршрутизаторлар. Үй роутерін түзету мүмкін емес, бірақ тәуекелді азайтуға болады: 5 ГГц-қа қосылуды ұсыну, корпоративтік VPN-да фоновый трафикті шектеу және жұмыс ПК-лар мен тонкие клиенттердің исходящий трафигіне дұрыс маркировка қойылғанын тексеру.\n\n## QoS енгізудің қадамдық жоспары желіде\n\nДауыc және бейне үшін QoS шынымен жүктеме сағаттарында сапаны ұстап тұруы керек. Сондықтан жоспар тар жерлерге бағдарланады, барлық жерде бірдей біртіндеп баптау идеясынан емес.\n\n1) Трафик сыныптарын анықтаңыз. Әдетте 3–4 сынып жеткілікті: дауыс, видео, маңызды бизнес-қосымшалар, «барлығы қалғаны». Классификацияны VLAN/телефония субнеттері, медиа-серверлер IP-адрестері, сигнальдық порттар немесе UC-клиенттің меткалары бойынша жасаңыз.\n\n2) Сенім шекарасын сипаттаңыз. Қолданушы порттарында кез келген DSCP-қа сенбеу керек. Әдетте IP-телефондарға және видеотерминалдарға сеніп, ПК-дан келетін трафикті бірінші коммутаторда немесе edge-роутерде қайта маркировкалау дұрыс.\n\n3) Кезек пайда болатын жерде приоритет беріңіз. Көп желілерде бұл WAN/интернет шығысы және межсегменттік uplink-тер. Осы интерфейстерде кезектер қосып, дауысқа қатты приоритет, видеоға кепілдік берілген доля және қалғанына қалдықтық өткізу мәзірін беріңіз.\n\n4) Фонды бақылауда ұстаңыз. Жұмыс уақытында жаңартулар, бэкаптар және синхронизацияларды уақыттық және өткізу шектеуімен бақылау керек, әсіресе WAN-да.\n\nЖұмыс тәртібі, әдетте бірнеше айларға созылмайды:\n\n- сыныптар мен ережелерді бекіту;\n- access-тен WAN-ға дейін маркировка және trust boundary баптау;\n- ең жүктелген шығыстарда кезектерді қосып, приоритеттің артықшылық тудырмайтынын тексеру;\n- жұмыс уақытында фондық тасымалдарды шектеу;\n- QoS счетчиктерін бақылауға қосып, пилоттан бастау (бір офис немесе бір қабат).\n\nПилоттан кейін сол сценарийлерде: 2–3 параллель қоңырау, видеокездесу және бір уақытта фондық жүктеме — салыстырыңыз. Егер приоритеттік кезектердегі трафиктің үлесі артса және шағымдар азайса, өзгертулерді басқа жерлерге үлгі ретінде таратыңыз.\n\n## Алдында және кейінгі өлшем әдістемесі: әсерді қалай дәлелдеу керек\n\nQoS пайдасы ең жақсысы сандармен көрінеді. Алдымен бастапқы сызықты алыңыз: бірдей метрикалар, бірдей өлшеу нүктелері, бірдей шарттар.\n\n### Алдыңғы сызық: «до» қалай өлшеу\n\nДеректерді бір рет емес, сериямен алыңыз. Әйтпесе «жақсы күнмен» «жаман күнді» салыстырасыз.\n\n- 2–3 типтік кезеңді таңдаңыз: таңертеңгі шың, күндізгі жүктеме, кешкі уақыт;\n- 3–5 жұмыс күн қатарынан жинаңыз, қайталанушылықты көру үшін;\n- WAN жүктемесін, стыктағы жоғалтуларды, белсенді қоңыраулар санын тіркеңіз;\n- қолда бар саясаттарды жазыңыз: маркировка бар ма, кезектер, шейпинг қай жерде;\n- нүктелерді анықтаңыз: access-коммутатор, WAN-край, Wi‑Fi контроллері (бар болса).\n\nСодан кейін белсенді тесттер жасаңыз: сол уақытта 10 минуттық видеоқоңырау бастап, параллель бақылаулы фондық жүктеме жасаңыз (мысалы, үлкен файлды көшіру). Сценарийді бірнеше рет қайталап, деградация қай уақытта басталатынын бақылаңыз.\n\nПассивті деректер UC жүйелерінің есептерінен (MOS/сапа, джиттер, жоғалтулар) және желілік статистикадан алыңыз: интерфейстердегі drops, кезектердің толу деңгейі, policy-map/class-map счетчиктері (немесе баламалары).\n\n### «До/после» салыстыруы адал болу үшін\n\nЕсепте ең тиімділері — қарапайым және салыстырылатын артефактілер:\n\n- кешігу, джиттер және жоғалтулардың сағат бойынша графигі;\n- p95/p99 кестесі (тек орташа емес) до және после;\n- класс бойынша drops үлесі және кезектердің толу деңгейі;\n- арнаның жүктемесімен салыстыру, сол арқылы жақсару провайдер тарапынан артық босату себебінен емес екені көрінеді.\n\nПриоритезация әсерін басқа өзгерістерден бөліп алу үшін маршрутизация мен өткізу қабілетін бір уақытта өзгертпеңіз, трафик жолын тіркеңіз және тест сценарийін бірдей ұстаңыз. Өзгерістер болмаған жағдайда оларды журналда белгілеп, тек бірдей жүктеме аралығын салыстырыңыз.\n\n## QoS-тің типтік қателері және оларды қалай тез табуға болады\n\nКөп кездесетін ситуация: меткалар қойылған, бірақ сапа жақсармаған. Көп жағдайда проблема DSCP/802.1p-де емес, метканың шығыс кезектерде нақты приоритетке айналмауында.\n\n### Меткалар бар, бірақ приоритет жоқ\n\nDSCP немесе 802.1p дұрыс қойылса да, шекаралық роутерде немесе коммутаторда "сынып->кезек" сәйкестендіруі жоқ болуы мүмкін. Сол кезде дауыс пен видео жалпы кезекпен бірге жүреді.\n\nЖылдам тексеру: egress-интерфейстің класс счетчиктерін қараңыз. Егер «дауыc/видео» кластар өсіп жатпаса немесе олар Best Effort-пен бірдей кезекте болса, приоритет іс жүзінде жоқ.\n\n### Қате сенім шекарасы\n\nЕгер пайдаланушы порттарында меткаларға сенсеңіз, кез келген ПК өзін жоғары приоритетпен белгілеп, қоңырауларды ығыстыра алады. Шынайы желілерде trust көбінесе дауыс көзіне жақын қояды (IP-телефон, SBC, MCU) немесе телефон алдында тұрған портта, коммутатор екі ағынды ажырата алатын жағдайда.\n\n### Приоритеттік кезек қате бапталған\n\nҚате екі бағытта болуы мүмкін: приоритеттік кезек тым кіші (дауыс жүктеме кезінде пакет жоғалтады) немесе тым үлкен (дауыс арнаны «жеп қойып», қалғандарын үгіттейді). Қозғалатын белгі: орташа емес жүктеме кезінде приоритет класта drops өседі немесе басқа кластар үнемі аш қалады.\n\nКішкене мысал: видеокездесулер тек біреу файл жүктегенде ғана бұзылады. Себебі видео размечено, бірақ WAN-шығысындағы сәйкес кезек жоқ, ал дауысқа ғана приоритет берілген.\n\n### Сапа тек бір бағытта түседі\n\nКейде QoS-ды бар жерде баптап қойғанымен, бір стыктегі egress-ті ұмытып кетеді. Осылайша «бір жағы» жақсы, «кері жағы» үзіліп кетеді.\n\n15 минутта жиі мәселені табатын қысқа тексерулер жиынтығы:\n\n- проблемалы линктің екі ұшындағы QoS саясаттары мен счетчиктерді салыстыру;\n- қажетті класс тек шығысқа (egress) қолданылғанын тексеру;\n- кезек бойынша drops және микроберсттардың бар-жоғын қарау (қолдау көрсетілсе).\n\n### Полисинг RTP-ны кесіп тастайды\n\nWAN-дегі полисинг қысқа RTP/видео жарылыстарын кесіп тастап, орташа бойынша арна бос болғанымен жоғалтуларға әкелуі мүмкін. Белгі: белгілі бір класта жоғалтулар өседі, бірақ жалпы жүктеме прага астынан төмен. Әдетте жұмсақ шейпинг, burst-параметрлерін түзету және нақты провайдер қабілетіне қарай жылдамдықты сәйкестендіру көмектеседі.\n\nҮлкен ұйымдарда QoS картасын жүргізу пайдалы: қай жерде меткаларға сенеміз, қай жерде кезектер қосылған, қай жерде шейпинг тұр — осылайша жүйеден шығып қалған бір түйін тез табылады.\n\n## Жылдам чек-лист және келесі қадамдар\n\nСапа жақсарса, нәтижені бекітіп, тағы қай жерлер әлсіз екенін тексеріңіз. Бұл қысқа чек-листі желідегі кез келген өзгерістен кейін 30–60 минут ішінде жүргізуге болады.\n\n### Жылдам чек-лист\n\nШын қоңырау немесе тест видеосеанс кезінде шың уақытында тексеріңіз:\n\n- меткалар бар ма: дауыс пен видео endpoints-тен қажетті DSCP-тар шығып тұр ма, коммутаторларда 802.1p көрінеді ме (қолдансаңыз);\n- кезектер белсенді: WAN-жабдықтарда және негізгі коммутаторларда приоритеттік кезек бірінші қызмет көрсетіп жатыр ма, қалғандар аш қалмай ма;\n- «приоритеттің жойылуы» жоқ па: трафик қате match немесе қайта жазу себебінен жалпы класқа кетіп жатқан жоқ па;\n- буферлер бақылауда: кезектердің тұрақты толуы жоқ па, әсіресе тар арналар мен аплинктерде;\n- цифрларда нәтиже: дауыc пен видео үшін кешігу, джиттер және жоғалтулар «до»-дан кейін жақсарған және тұрақты.\n\nЕгер бір нәрсе сәйкес келмесе, маршрутты ретімен тексеріңіз: телефон немесе ПК, access-коммутатор, ядро, шекаралық маршрутизатор және провайдер стыгы. Көбіне меткалар домендер арасындағы шекарада жоғалады (офис пен филиал арасында, VPN алдында, Wi‑Fi-де), ал кезек тар жерде жиналады, онда шейпинг жоқ.\n\n### Нәтижені қалай ресімдеу керек\n\nӨзгерістерді келісіп, баптауларды жоғалтпау үшін қысқа есеп жасаңыз:\n\n- «до/после»: 3–5 өлшеу бірдей шарттарда (шың уақыты, бір маршрут);\n- негізгі счетчиктер скриншоттары: кезектер, drops, utilization тар линктерде;\n- нақты не бапталды: сыныптар, саясаттар, қай жерде меткалар қойылады және қай жерде сенеді.\n\nКелесі қадамдар әдетте айқын: QoS профилін стандарт ретінде шығарып, коммутатормен, Wi‑Fi және WAN үшін шаблондар жасау, филиалдарға тарату және «транзитте маркировканы себепсіз өзгертпеу» қағидатын бекіту.\n\nЕгер аудит, енгізу және қолдау қажет болса, жүйелік интеграторды жалдау орынды. Мысалы, GSE.kz Қазақстанда өндіруші және интегратор ретінде UC пен бейнебайланысқа арналған инфрақұрылымды: желіден бастап серверлер мен жұмыс станцияларына дейін, әрі қарай қолдауға дейін жасап береді.