EA031556B1 - Способ управления пропускной способностью для голосовой связи по интернет-протоколу (voip) - Google Patents

Способ управления пропускной способностью для голосовой связи по интернет-протоколу (voip) Download PDF

Info

Publication number
EA031556B1
EA031556B1 EA201591211A EA201591211A EA031556B1 EA 031556 B1 EA031556 B1 EA 031556B1 EA 201591211 A EA201591211 A EA 201591211A EA 201591211 A EA201591211 A EA 201591211A EA 031556 B1 EA031556 B1 EA 031556B1
Authority
EA
Eurasian Patent Office
Prior art keywords
value
specified
network delay
way network
receiving device
Prior art date
Application number
EA201591211A
Other languages
English (en)
Other versions
EA201591211A1 (ru
Inventor
Санни Маруэли
Ран Шальги
Original Assignee
Вайбер Медиа С.А.Р.Л.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Вайбер Медиа С.А.Р.Л. filed Critical Вайбер Медиа С.А.Р.Л.
Publication of EA201591211A1 publication Critical patent/EA201591211A1/ru
Publication of EA031556B1 publication Critical patent/EA031556B1/ru

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/11—Identifying congestion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
    • H04M7/1205—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
    • H04M7/1275—Methods and means to improve the telephone service quality, e.g. reservation, prioritisation or admission control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/22—Arrangements for supervision, monitoring or testing
    • H04M3/2236—Quality of speech transmission monitoring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
    • H04M7/0081—Network operation, administration, maintenance, or provisioning
    • H04M7/0084—Network monitoring; Error detection; Error recovery; Network testing

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)
  • Health & Medical Sciences (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Communication Control (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

Компьютеризированный способ оптимизации качества аудиосигнала в голосовом потоке между приложениями для голосовой связи по интернет-протоколу (VoIP) передающего устройства и принимающего устройства, причем указанный способ включает определение посредством указанного приемного устройства множества интервалов времени для указанного голосового потока; определение посредством приемного устройства наличия или отсутствия перегрузки в конце каждого интервала времени путем (i) вычисления односторонней сетевой задержки и (ii) использование двойного экспоненциального сглаживания для вычисления значения направления изменения значений односторонней сетевой задержки; определение значения пропускной способности, доступной указанному передающему устройству, посредством указанного приемного устройства на основании результата вычисления направления изменения значений односторонней сетевой задержки; передачу посредством указанного приемного устройства определенного значения пропускной способности на указанное передающее устройство; использование указанным передающим устройством определенного значения пропускной способности, полученной передающим устройством, в качестве максимально допустимой скорости передачи данных для второго множества пакетов в указанном голосовом потоке приложений голосовой связи по интернет-протоколу (VoIP).

Description

Настоящее изобретение относится к системам голосовой связи по интернет-протоколу (VoIP), и более конкретно к оптимизации качества аудиосигнала с использованием результатов регулировки пропускной способности.
Уровень техники
В отличие от голосовой связи с коммутацией каналов технология голосовой связи по интернетпротоколу (VoIP) должна хорошо работать в условиях изменяющегося состояния сети вследствие конкурирующего трафика (например, просмотра клипов на YouTube), интерференции беспроводной связи и т.д. Некоторые аудиокодеки, например кодек Opus, поддерживают передачу данных на различных скоростях передачи данных. Кроме использования многоскоростных кодеков можно также изменять скорость передачи данных путем изменения размера кадра и путем переключения между кодеками. Даже при наличии кодека, который поддерживает множество скоростей передачи данных (что может включать изменения размера кадра, как указано выше), все еще остается проблема использования наилучшей скорости передачи данных с учетом состояний сети, что требует измерения состояний сети.
Сущность изобретения
Настоящее изобретение предлагает компьютеризированный способ оптимизации качества аудиосигнала в голосовом потоке между приложениями для голосовой связи по интернет-протоколу (VoIP) передающего устройства и принимающего устройства, причем указанный способ включает определение посредством указанного приемного устройства множества интервалов времени для указанного голосового потока; определение посредством приемного устройства наличия или отсутствия перегрузки в конце каждого интервала времени путем (i) вычисления односторонней сетевой задержки и (ii) использование двойного экспоненциального сглаживания для вычисления значения направления изменения значений односторонней сетевой задержки; определение значения пропускной способности, доступной указанному передающему устройству, посредством указанного приемного устройства на основании результата вычисления направления изменения значений односторонней сетевой задержки; передачу посредством указанного приемного устройства определенного значения пропускной способности на указанное передающее устройство; использование указанным передающим устройством определенного значения пропускной способности, полученной передающим устройством, в качестве максимально допустимой скорости передачи данных для второго множества пакетов в указанном голосовом потоке приложений голосовой связи по интернет-протоколу (VoIP).
Определение наличия или отсутствия перегрузки может происходить в соответствии со следующими условиями: если вычисленная односторонняя сетевая задержка больше предварительно вычисленной положительной постоянной или если вычисленное значение направления изменения значений односторонней сетевой задержки больше второй предварительно вычисленной положительной постоянной. Данный способ может дополнительно включать определение уровня перегрузки на основании вычисленного значения направления изменения значений односторонней сетевой задержки.
Данный способ может дополнительно включать определение необходимости выполнения вычисления значения пропускной способности в соответствии с периодическим обновлением или изменением указанного состояния перегрузки, а этапы вычисления значения, передачи и использования вычисленного значения пропускной способности могут быть выполнены только в том случае, если было определено, что необходимо выполнить указанное вычисление значения пропускной способности.
Определение необходимости указанного вычисления значения пропускной способности может включать определение того, истек ли предварительно заданный интервал времени после последнего вычисления значения пропускной способности. Этот предварительно заданный интервал времени является временем двусторонней сетевой задержки.
Определение необходимости вычисления значения пропускной способности может включать определение того, изменилось ли состояние перегрузки. Определение значения пропускной способности может включать: a) определение входной скорости передачи данных; b) в случае отсутствия перегрузки определение того, что значение пропускной способности больше значения входной скорости передачи данных; c) в случае наличия перегрузки определение того, что значение пропускной способности меньше значения входной скорости передачи данных.
Краткое описание графических материалов
Для лучшего понимания изобретения и иллюстрации того, как оно может быть реализовано, только в качестве примера обратимся далее к прилагаемым чертежам. При конкретном обращении к чертежам мы хотим подчеркнуть, что детали показаны только в качестве примера и только с целью пояснительного обсуждения предпочтительных вариантов осуществления настоящего изобретения и представлены, как предполагается, с целью обеспечения наиболее полезного и легко понимаемого описания принципов и концептуальных аспектов данного изобретения. В этой связи попытки показать структурные детали данного изобретения более подробно, чем необходимо для глубокого понимания данного изобретения, не предпринимались, и данное описание в сочетании с чертежами делает очевидным для специалистов в данной области техники, как можно реализовать на практике различные формы данного изобретения. На прилагаемых чертежах:
- 1 031556 на фиг. 1 показана блок-схема, описывающая алгоритм определения перегрузки согласно вариантам осуществления настоящего изобретения;
на фиг. 2 полазана блок-схема, описывающая алгоритм оценки (вычисления значения) пропускной способности согласно вариантам осуществления настоящего изобретения.
Подробное описание вариантов осуществления изобретения
Для достижения наилучшего качества звука в приложениях VoIP мы хотим использовать наивысшую скорость передачи данных (для заданного кодека использование большего количества бит/с для кодировки данных должно привести к более точному воспроизведению входа) при сохранении минимально возможного времени ожидания.
Мы определяем время ожидания как задержку, т.е. как время, которое требуется аудиосигналу для прохождения от стороны 1 (микрофона) к стороне 2 (динамикам). Оно содержит два главных компонента, алгоритмическую задержку (которая в нашем контексте всегда будет временем, которое аудиосигнал будет тратить в одном приложении VoIP), которую мы будем считать фиксированной, и сетевую задержку. Мы будем называть сетевую задержку от 1 к 2 односторонней сетевой задержкой, если добавить одностороннюю задержку в обратном направлении, получим двустороннюю сетевую задержку. В общем случае при воспроизведении потокового видео/аудио (например, во время просмотра клипа на Y ouTube) приемлемой является задержка в несколько секунд. Однако в диалоговом сеансе (то есть, во время разговора) такая задержка сильно влияет на воспринимаемое качество сеанса.
Есть несколько компонентов, влияющих на одностороннюю сетевую задержку. Один из них, который обрабатывается протоколами предотвращения заторов, является задержкой в очереди. Если пакеты прибывают в маршрутизатор быстрее, чем он передает их в следующий транзитный шлюз, они становятся в очередь. Односторонняя сетевая задержка для поставленных в очередь пакетов возрастает. Например, пусть у нас есть источник, который пересылает 2 пакета в секунду в маршрутизатор, который соединен с другой линией передачи данных с пропускной способностью 1 пакет в секунду. При условии, что в начальный момент времени очереди нет, первый пакет передается маршрутизатором почти мгновенно. Однако второй пакет прибывает через 0,5 с и должен ждать отправления до истечения 1 -й секунды. Следующий пакет прибывает через 1 с после начала отсчета времени и должен ждать до истечения 2-й секунды. Односторонняя сетевая задержка из-за постановки в очередь равна 0 с для первого пакета, 0,5 с для второго пакета, 1 с для третьего пакета.
Мы используем это увеличение односторонней сетевой задержки в качестве сигнала перегрузки.
Предполагается, что каждый аудиопакет включает временную метку (например, RTP-пакеты), и это значение обычно увеличивает количество образцов в предыдущем пакете. Значит:
временная метка;=временная метками образцы^.
Поскольку количество образцов в секунду является фиксированным (например, 8000 или 16000), его легко можно преобразовать в секунды. Например, 480 образцов при 16000 образец/с=30 мс.
Мы полагаем, что передающее устройство передает каждый пакет в срок, т.е. в предыдущем примере передающее устройство передает пакет через каждые 30 мс. В идеальном случае пакеты будут прибывать к получающему устройству через одинаковые интервалы времени (т.е. через каждые 30 мс). Однако в случае наличия перегрузки мы ожидаем, что время приема пакетов будет больше (в приведенном выше примере 2 пакет/с пакеты будет отправляться через 0, 0,5, 1, ..., а приниматься через 0, 1, 2, ..., т.е. между двумя отправленными пакетами будет интервал 0,5 с, но между двумя принятыми пакетами будет интервал 1 с). В реальных IP-сетях, таких как сеть Интернет, все не настолько просто, потому что к каждому пакету добавляется случайное искажение, и это приводит к тому, что задержки будут большими или меньшими по сравнению с ожидаемым временем. Обозначим время передачи пакета i как s; и время его приема как r;. Мы определяем межпакетную задержку следующим образом:
di = Г, - Гм - (Si - Si-i)
Если перегрузка отсутствует, мы предполагаем, что d; в среднем будет равна нулю:
Определение перегрузки.
Далее будет описан алгоритм определения перегрузки в привязке к фиг. 1 в соответствии с вариантами осуществления настоящего изобретения. Для определения перегрузки на приемном устройстве его приложение VoIP измеряет количество образцов, полученных за предварительно заданный (этап 100) фиксированный интервал времени, например за 120 мс. Если в каждый интервал времени 120 мс принимается в среднем количество пакетов, соответствующее интервалу 120 мс, то в таком случае перегрузка отсутствует. Однако если за интервал времени 120 мс принимается в среднем меньшее количество пакетов, чем количество, соответствующее интервалу 120 мс, тогда перегрузка существует. При получении достаточного количества образцов перегрузку определить легко. Однако мы хотим определять перегрузку быстро, исключая при этом ложно-положительные результаты, вызванные искажениями.
Мы предпочитаем делать выборку через интервалы времени фиксированной длины С, поскольку это упрощает алгоритм. Таким образом, обозначим 1 интервал (в нашем примере от 0 до 120 мс) как lb 2 интервал как 12 и т.д. и обозначим образцы, полученные в i-м интервале R; (этап 120), в тех же единицах,
- 2 031556 что и указанный интервал, например в мс. Используя протокол RTP, мы можем преобразовать временные метки RTP (отображающие количество образцов) в единицы времени, например в мс, так как частота выборки обычно является фиксированной, например 8000 образец/с для узкополосной голосовой связи и 90000 образец/с для видеосигналов. Получаем: li=C для всех i (в примере выше C=120 мс).
Для измерения перегрузки используем двойное экспоненциальное сглаживание (этап 130): Si=a-(Ri-li)+(1-a)-(Si-1+bi-1) bi=3-(Si-Si-1)+(1-3)-bi-1, где s0 и b0 являются некоторыми заданными начальными значениями (например, 0) (этап 110), а 0<α, β<1 являются постоянными значениями. Si является сглаженной оценкой односторонней сетевой задержки, меньшей или равной некоторому постоянному значению, и должна равняться 0 в случае отсутствия перегрузки. bi является трендом (значением направления изменения значений), положительное bi указывает на увеличение задержки, т.е. на состояние перегрузки.
Теперь мы определим перегрузку в конце интервала li следующим образом:
si> порога S для некоторого порогового значения S>0 или bi> порога T для некоторого порогового значения T>0 (этап 140).
Далее мы можем определить некоторые пороговые значения S и/или T, которые будут отображать степень перегрузки, например отсутствие перегрузки, легкую, нормальную или большую перегрузку.
Если на этапе 150 последние вычисленные перегрузка и скорость передачи данных указывают на отсутствие необходимости повторной оценки фактической пропускной способности в этот момент, процесс возвращается на этап 120 для измерения количества образцов, полученных в следующем интервале времени.
Оценка (вычисление значения) пропускной способности.
Далее будет описан алгоритм оценки пропускной способности в привязке к фиг. 2. На основании оценок перегрузки приложение VoIP принимающего устройства пытается оценить фактическую пропускную способность для передающего устройства и должно ли приложение VoIP передающего устройства увеличить или уменьшить скорость своих посылок.
Мы оцениваем в момент времени t входную скорость передачи данных (например, путем измерения количества битов, принятых за последнюю секунду) - rt. Если сеть перегружена, мы полагаем, что пакеты передаются с максимально возможной скоростью, и поэтому rt можно использовать в качестве оценки фактической пропускной способности. С другой стороны, в случае отсутствия перегрузки входная скорость будет меньше доступной скорости передачи данных. Приложение VoIP принимающего устройства периодически оценивает фактическую пропускную способность для передающего устройства на основании самой последней оценки перегрузки и входной скорости передачи данных. Будем считать, что пропускная способность оценивается в момент времени ti, a результатом является Ati. Начальную пропускную способность At0 можно оценить, например, из входной скорости передачи данных на протяжении начального предварительно заданного интервала времени. Кроме того, начальная скорость передачи данных может быть установлена стандартом или по договоренности как часть начального квитирования или же может быть определена каким-либо другим способом, известным в данной области техники.
Обозначим оценку входной скорости передачи данных в момент времени ti как rti (этап 200).
Если перегрузка отсутствует, мы хотим увеличить оценку фактической пропускной способности (этап 220). Например, если rti>2-Ati-1, мы можем задать Ati=2/3-rti.
С другой стороны, Ati можно увеличить путем умножения на постоянный коэффициент
Ati=C-At-1 (этап 230), где C>1, или путем добавления постоянной Ati=C+At-1, где C>1.
Другой типовый вариант увеличения фактической пропускной способности состоит в запоминании последней оценки фактической пропускной способности Ati-1 и попытке быстрого возврата к ней после периода перегрузки (например, установить новую оценку, которая должна составлять, по меньшей мере, половину последней доступной оценки).
Необходимо отметить, что в некоторых случаях скорость передачи данных не может быть увеличена. Например, максимальная скорость передачи данных может быть задана; входная скорость передачи данных от однорангового узла является значительно более низкой, чем текущая оценка.
И наоборот, если существует перегрузка, и при условии, что текущая входная скорость передачи данных является нашей наилучшей оценкой пропускной способности, мы хотим уменьшить скорость передачи данных (этап 230), чтобы устранить перегрузку. Если перегрузка небольшая, мы может оценить Ati следующим образом:
При более высоких уровнях перегрузки мы можем умножить входную скорость передачи данных на постоянную (D<1), что позволит уменьшить задержку (этап 250).
Если передающее устройство осуществляет передачу пакетов на полной скорости, задержка не будет уменьшаться. В то же время, если передающее устройство использует, например, 80% фактической пропускной способности, это значит, что оно наверстывает, т.е. очередь рассасывается. Могут исполь
- 3 031556 зоваться и другие способы уменьшения оцененной пропускной способности.
Приложение VoIP принимающего устройства передает оценки на приложение VoIP передающего устройства, которое будет их использовать как максимально допустимую скорость передачи данных.
Наконец, мы должны установить, как определять время обновления оценки.
Некоторые типовые варианты следующие.
1. Периодическое обновление. Его можно выполнять через каждую C (например, через 120 мс) или реже. Например, мы может выполнять повторную оценку пропускной способности через каждую секунду. В альтернативном варианте для передачи периодических обновлений может использоваться протокол RTCP.
2. Когда состояние перегрузки показывает изменение, например происходит переход от состояния отсутствия перегрузки к состоянию перегрузки.
3. Так как этот процесс занимает время кругового обращения (принимающее устройство передает оценку передающему устройству и затем ожидает, пока придут первые данные с измененной скоростью передачи данных), каждый раз, когда приемное устройство передает оценку, оно задает время выполнения следующей оценки, например RTT+ε или (1+ e)-RTT, где RTT - оценка времени кругового обращения, ε - некоторая постоянная.
RTT можно измерять целым рядом способов, например следующими способами.
1. Приложение VoIP передающего устройства может передавать пакет подтверждения ack (мы принимаем, что каждый пакет после этого пакета испытал данное изменение).
2. Каждый медиа-пакет может содержать кодировку текущей скорости передачи данных (например, кодек может поддерживать 256 разных скоростей передачи данных, и первый байт закодированного потока может быть используемым режимом). Далее приемное устройство может определить, когда была изменена скорость передачи данных.
3. Могут передаваться заданные в явном виде пакеты RTT.
4. RTT можно вычислить из протокола RTCP.
В качестве расширения возможностей может быть активирована мгновенная оценка скорости передачи данных в случае значительного изменения перегрузки.
Настоящее изобретение может быть реализовано в различных комбинациях программного обеспечения, аппаратных средств и аппаратно-программного обеспечения.

Claims (8)

  1. ФОРМУЛА ИЗОБРЕТЕНИЯ
    1. Компьютеризированный способ оптимизации качества аудиосигнала в голосовом потоке приложений голосовой связи по интернет-протоколу (VoIP) между передающим устройством и принимающим устройством, причем указанный способ включает определение посредством указанного приемного устройства множества интервалов времени для указанного голосового потока;
    определение посредством указанного приемного устройства наличия или отсутствия перегрузки в конце каждого из указанного множества интервалов времени путем (i) вычисления значения односторонней сетевой задержки для каждого из первого множества полученных аудиопакетов в указанном голосовом потоке;
    (ii) использования двойного экспоненциального сглаживания для вычисления значения направления изменения значений односторонней сетевой задержки;
    определение значения пропускной способности, доступной указанному передающему устройству, посредством указанного приемного устройства на основании результата вычисления направления изменения значений односторонней сетевой задержки;
    передачу посредством указанного приемного устройства определенного значения пропускной способности на указанное передающее устройство, использование указанным передающим устройством определенного значения пропускной способности, полученной передающим устройством, в качестве максимально допустимой скорости передачи данных для второго множества аудиопакетов в указанном голосовом потоке приложений голосовой связи по интернет-протоколу (VoIP), причем определение наличия или отсутствия перегрузки происходит в соответствии со следующими условиями: если вычисленная односторонняя сетевая задержка больше первой предварительно вычисленной положительной постоянной или если вычисленное значение направления изменения значений односторонней сетевой задержки больше второй предварительно вычисленной положительной постоянной.
  2. 2. Способ по п.1, дополнительно включающий определение уровня перегрузки на основании вычисленного значения направления изменения значений односторонней сетевой задержки.
  3. 3. Способ по п.1, дополнительно включающий этап определения необходимости выполнения вычисления значения пропускной способности, которая зависит от данных, связанных с периодическим обновлением или изменением указанного состояния перегрузки, при этом указанное вычисление значе
    - 4 031556 ния, передачу и использование вычисленного значения пропускной способности выполняют только в том случае, если было определено, что необходимо выполнить указанное вычисление значения пропускной способности.
  4. 4. Способ по п.3, согласно которому указанное определение необходимости указанного вычисления значения пропускной способности включает определение того, истек ли предварительно заданный интервал времени после того, как было произведено предыдущее вычисление значения пропускной способности.
  5. 5. Способ по п.4, согласно которому указанный предварительно заданный интервал времени является временем двусторонней сетевой задержки.
  6. 6. Способ по п.3, согласно которому определение необходимости вычисления значения пропускной способности включает определение того, изменилось ли состояние перегрузки.
  7. 7. Компьютеризированный способ определения перегрузки в голосовом потоке между приложениями для голосовой связи по интернет-протоколу (VoIP) передающего устройства и принимающего устройства, причем указанный способ включает задание посредством приемного устройства множества интервалов времени для голосового потока, вычисление посредством приемного устройства наличия перегрузки в конце каждого из указанного множества интервалов времени путем (i) вычисления значения односторонней сетевой задержки для каждого из первого множества принятых аудтопакетов в указанном голосовом потоке;
    (ii) вычисления значения направления изменения значений односторонней сетевой задержки указанного множества принятых аудиопакетов с использованием двойного экспоненциального сглаживания;
    определение посредством указанного принимающего устройства наличия перегрузки, если вычисленное значение односторонней сетевой задержки больше предварительно вычисленной положительной постоянной или если вычисленное значение направления изменения значений односторонней сетевой задержки больше предварительно заданной положительной постоянной.
  8. 8. Способ по п.7, дополнительно включающий вычисление посредством указанного приемного устройства значения пропускной способности, доступной указанному передающему устройству, на основании результата указанного вычисления направления изменения значений односторонней сетевой задержки.
    - 5 031556
EA201591211A 2013-04-10 2014-03-16 Способ управления пропускной способностью для голосовой связи по интернет-протоколу (voip) EA031556B1 (ru)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/859,765 US9356869B2 (en) 2013-04-10 2013-04-10 VoIP bandwidth management
PCT/IB2014/059867 WO2014167431A1 (en) 2013-04-10 2014-03-16 Voip bandwidth management

Publications (2)

Publication Number Publication Date
EA201591211A1 EA201591211A1 (ru) 2016-02-29
EA031556B1 true EA031556B1 (ru) 2019-01-31

Family

ID=51686715

Family Applications (1)

Application Number Title Priority Date Filing Date
EA201591211A EA031556B1 (ru) 2013-04-10 2014-03-16 Способ управления пропускной способностью для голосовой связи по интернет-протоколу (voip)

Country Status (13)

Country Link
US (1) US9356869B2 (ru)
EP (1) EP2984790B1 (ru)
JP (1) JP6132972B2 (ru)
KR (1) KR101920114B1 (ru)
CN (1) CN105284077B (ru)
AU (1) AU2014252266B2 (ru)
BR (1) BR112015019272A2 (ru)
CA (1) CA2899836C (ru)
EA (1) EA031556B1 (ru)
HR (1) HRP20180997T1 (ru)
PH (1) PH12015501741B1 (ru)
UA (1) UA113028C2 (ru)
WO (1) WO2014167431A1 (ru)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8707454B1 (en) 2012-07-16 2014-04-22 Wickr Inc. Multi party messaging
US10567349B2 (en) 2013-06-25 2020-02-18 Wickr Inc. Secure time-to-live
US10129260B1 (en) 2013-06-25 2018-11-13 Wickr Inc. Mutual privacy management
US9830089B1 (en) 2013-06-25 2017-11-28 Wickr Inc. Digital data sanitization
US9866591B1 (en) 2013-06-25 2018-01-09 Wickr Inc. Enterprise messaging platform
US9698976B1 (en) 2014-02-24 2017-07-04 Wickr Inc. Key management and dynamic perfect forward secrecy
US9584530B1 (en) 2014-06-27 2017-02-28 Wickr Inc. In-band identity verification and man-in-the-middle defense
US9654288B1 (en) 2014-12-11 2017-05-16 Wickr Inc. Securing group communications
US9559995B1 (en) * 2015-10-19 2017-01-31 Meteors Information Systems Limited System and method for broadcasting contents from web-based browser to a recipient device using extensible messaging and presence protocol (XMPP)
US9584493B1 (en) 2015-12-18 2017-02-28 Wickr Inc. Decentralized authoritative messaging
US10291607B1 (en) 2016-02-02 2019-05-14 Wickr Inc. Providing real-time events to applications
US9591479B1 (en) 2016-04-14 2017-03-07 Wickr Inc. Secure telecommunications
US9602477B1 (en) 2016-04-14 2017-03-21 Wickr Inc. Secure file transfer
JP6805713B2 (ja) * 2016-10-19 2020-12-23 日本電気株式会社 受信トラヒックの高速化装置、高速化方法、および高速化プログラム
CN109922212B (zh) * 2018-12-21 2021-04-09 创新先进技术有限公司 一种时段话务量占比的预测方法及装置
CN115361316B (zh) * 2022-07-20 2023-11-10 慧之安信息技术股份有限公司 基于边缘计算的物联网数据包传输延迟检测方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030091029A1 (en) * 2001-11-13 2003-05-15 Jo Min Ho Routing method based on packet delay
US20140043994A1 (en) * 2013-03-28 2014-02-13 Hcl Technologies Limited Providing Feedback To Media Senders Over Real Time Transport Protocol (RTP)

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5936940A (en) 1996-08-22 1999-08-10 International Business Machines Corporation Adaptive rate-based congestion control in packet networks
US7668968B1 (en) 2002-12-03 2010-02-23 Global Ip Solutions, Inc. Closed-loop voice-over-internet-protocol (VOIP) with sender-controlled bandwidth adjustments prior to onset of packet losses
CN100583785C (zh) * 2004-02-06 2010-01-20 阿派伦特网络股份有限公司 用于表征基于分组的网络的端对端路径的方法和设备
US7460480B2 (en) 2004-03-11 2008-12-02 I2Telecom International, Inc. Dynamically adapting the transmission rate of packets in real-time VoIP communications to the available bandwidth
US7440419B2 (en) * 2005-01-27 2008-10-21 International Business Machines Corporation Methods for detecting nagling on a TCP network connection
JP4884922B2 (ja) * 2006-10-30 2012-02-29 京セラ株式会社 通信装置および通信方法
JP5284355B2 (ja) 2007-07-09 2013-09-11 テレフオンアクチーボラゲット エル エム エリクソン（パブル） 通信システムにおける適応レート制御
CN101557273A (zh) * 2008-04-11 2009-10-14 傅承鹏 一种同时适用于有线和无线网络的实时流媒体传输的方法
CN101997729A (zh) * 2009-08-12 2011-03-30 华为技术有限公司 网络控制方法和装置
US8886790B2 (en) 2009-08-19 2014-11-11 Opanga Networks, Inc. Systems and methods for optimizing channel resources by coordinating data transfers based on data type and traffic
CN101656674B (zh) * 2009-09-23 2011-10-12 中国人民解放军信息工程大学 拥塞控制方法及网络节点
US9007914B2 (en) 2009-09-30 2015-04-14 Qualcomm Incorporated Methods and apparatus for enabling rate adaptation across network configurations
GB2478277B (en) * 2010-02-25 2012-07-25 Skype Ltd Controlling packet transmission
US8553540B2 (en) * 2010-03-05 2013-10-08 Microsoft Corporation Congestion control for delay sensitive applications
JP4911238B2 (ja) * 2010-09-27 2012-04-04 富士通株式会社 パケット通信システム、パケット通信方法、送信装置、及びコンピュータプログラム

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030091029A1 (en) * 2001-11-13 2003-05-15 Jo Min Ho Routing method based on packet delay
US20140043994A1 (en) * 2013-03-28 2014-02-13 Hcl Technologies Limited Providing Feedback To Media Senders Over Real Time Transport Protocol (RTP)

Also Published As

Publication number Publication date
CN105284077A (zh) 2016-01-27
HRP20180997T1 (hr) 2018-08-10
KR101920114B1 (ko) 2019-02-08
US20140307543A1 (en) 2014-10-16
AU2014252266A1 (en) 2015-08-13
BR112015019272A2 (pt) 2017-07-18
CA2899836C (en) 2021-05-04
EP2984790B1 (en) 2018-05-30
US9356869B2 (en) 2016-05-31
EP2984790A1 (en) 2016-02-17
AU2014252266B2 (en) 2017-09-21
EP2984790A4 (en) 2016-12-07
EA201591211A1 (ru) 2016-02-29
PH12015501741A1 (en) 2015-10-19
UA113028C2 (uk) 2016-11-25
CN105284077B (zh) 2018-09-28
PH12015501741B1 (en) 2015-10-19
JP6132972B2 (ja) 2017-05-24
WO2014167431A1 (en) 2014-10-16
CA2899836A1 (en) 2014-10-16
JP2016516377A (ja) 2016-06-02
KR20160002720A (ko) 2016-01-08

Similar Documents

Publication Publication Date Title
EA031556B1 (ru) Способ управления пропускной способностью для голосовой связи по интернет-протоколу (voip)
US8588071B2 (en) Device and method for adaptation of target rate of video signals
RU2304364C2 (ru) Устройство и способ для измерения времени задержки на двустороннее распространение для мультимедийных данных с переменной скоростью передачи битов
JP4299275B2 (ja) マルチメディアデータ転送率の適応的推定方法
WO2017000719A1 (zh) 一种基于队列时延的拥塞控制方法及装置
CN111935441B (zh) 一种网络状态检测方法及装置
WO2013159209A1 (en) Network congestion prediction
Liu et al. Segment duration for rate adaptation of adaptive HTTP streaming
GB2559271A (en) Managing congestion response during content delivery
CN113612649B (zh) 往返估计
JP2013098759A (ja) データ送信装置およびデータ受信装置
GB2540947A (en) Identifying network conditions
US9439100B2 (en) System and method for dynamic rate adaptation based on real-time call quality metrics
JP2007036960A (ja) 動的にセッションを切り替えるｒｔｐ通信用端末、呼接続システム及びプログラム
Jäger et al. How dia-shows turn into video flows: adapting scalable video communication to heterogeneous network conditions in real-time

Legal Events

Date Code Title Description
MM4A Lapse of a eurasian patent due to non-payment of renewal fees within the time limit in the following designated state(s)

Designated state(s): KG TM