Способы связи в реальном времени, обеспечивающие паузу и возобновление, и связанные с ними устройства

Изобретение относится к технологиям сетевой связи. Технический результат заключается в повышении скорости передачи данных. Способ содержит этапы, на которых: принимают поток данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени от другого устройства связи, при этом пакеты потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени включают в себя идентификацию потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени; и передают запрос паузы от приемного устройства связи к другому устройству связи, при этом запрос паузы включает в себя идентификацию потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени и порядковый номер запроса паузы. 4 н. и 28 з.п. ф-лы, 11 ил.

 

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

[0001] Настоящее изобретение относится к системам связи, и в частности, к системам и способам, обеспечивающим потоковую связь.

УРОВЕНЬ ТЕХНИКИ

[0002] Проведение мультимедийных конференций может позволить осуществлять потоковую передачу данных в реальном времени между двумя или более оконечными устройствами по сети, такой как Интернет, чтобы обеспечить связь в реальном времени. Каждое из множества оконечных устройств, участвующих в сеансе видеоконференции, например, может генерировать поток данных мультимедийного контента, включающий в себя видео- и аудиоконтент, и центральный узел связи может выбирать поток или потоки данных контента, которые предусматриваются для каждого из оконечных устройств. Узел связи, например, может выбирать поток данных контента на основе сравнения аудиоконтента/громкости, связанного с каждым из потоков данных контента. Другими словами, узел связи может осуществлять попытку выбрать поток данных контента, соответствующий динамику, который в настоящий момент является наиболее активным при конференц-вызове. Однако в таком варианте осуществления выбор потока данных контента может неблагоприятным образом смещаться в сторону оконечного устройства, генерирующего самую большую громкость, например, в силу нежелательного шума.

[0003] Соответственно, в области техники продолжает существовать потребность в усовершенствованной методике выбора потоков данных контента в средах связи, таких как мультимедийная конференц-связь.

РАСКРЫТИЕ ИЗОБРЕТЕНИЯ

[0004] Следовательно, целью является преодоление по меньшей мере некоторых из обозначенных выше недостатков и/или повышение производительности в системе связи.

[0005] В соответствии с некоторыми вариантами осуществления настоящего изобретения приемное устройство связи может принимать поток данных медиаконтента в реальном времени, предоставленный другим устройством связи во время сеанса связи в реальном времени. Способ управления таким приемным устройством связи может включать в себя этапы, на которых принимают поток данных медиаконтента в реальном времени сеанса связи от другого устройства связи, при этом пакеты потока данных медиаконтента в реальном времени включают в себя идентификацию потока данных медиаконтента в реальном времени. Кроме того, запрос паузы может передаваться от приемного устройства связи к другому устройству связи, при этом запрос паузы включает в себя идентификацию потока данных медиаконтента в реальном времени и порядковый номер запроса паузы.

[0006] После передачи запроса паузы, приема, сообщение подтверждения паузы может быть принято от другого устройства связи, при этом сообщение подтверждения паузы включает в себя идентификацию потока данных медиаконтента в реальном времени и порядковый номер запроса паузы. После приема сообщения подтверждения паузы запрос возобновления может быть передан от приемного устройства связи к другому устройству связи, при этом запрос возобновления включает в себя идентификацию потока данных медиаконтента в реальном времени и порядковый номер запроса возобновления, отличный от порядкового номера запроса паузы. После передачи запроса возобновления, сообщение подтверждения возобновления может быть принято от другого устройства связи, при этом сообщение подтверждения возобновления включает в себя идентификацию потока данных медиаконтента в реальном времени и порядковый номер запроса возобновления. Кроме того, порядковый номер запроса возобновления может быть увеличен относительно порядкового номера запроса паузы так, что порядковые номера паузы и возобновления выбираются из одного и того же пространства порядковых номеров.

[0007] Запрос паузы может быть первым запросом паузы, и порядковый номер запроса паузы может быть порядковым номером первого запроса паузы. Второй запрос паузы может затем передаваться от приемного устройства связи к другому устройству связи, в ответ на истечение времени ожидания после передачи запроса паузы от приемного устройства связи, при этом второй запрос паузы включает в себя идентификацию потока данных медиаконтента в реальном времени и порядковый номер второго запроса паузы, отличный от порядкового номера первого запроса паузы. После передачи второго запроса паузы сообщение подтверждения паузы может быть принято от другого устройства связи, при этом сообщение подтверждения паузы включает в себя идентификацию потока данных медиаконтента в реальном времени и порядковый номер второго запроса паузы. В частности, порядковый номер второго запроса паузы может быть увеличен относительно порядкового номера первого запроса паузы так, что порядковые номера первого и второго запросов паузы выбираются из одного и того же пространства порядковых номеров.

[0008] Идентификация потока данных медиаконтента в реальном времени может быть источником синхронизации (SSRC), который уникально идентифицирует поток данных медиаконтента в пределах сеанса связи в реальном времени.

[0009] В соответствии с другими вариантами осуществления настоящего изобретения передающее устройство связи может обеспечивать сеанс связи в реальном времени с другим устройством связи. Способ управления таким передающим устройством связи может включать в себя передачу потока данных медиаконтента в реальном времени сеанса связи от передающего устройства связи к другому устройству связи, при этом пакеты потока данных медиаконтента в реальном времени включают в себя идентификацию потока данных медиаконтента в реальном времени. Запрос паузы может быть принят от другого устройства связи, при этом запрос паузы включает в себя идентификацию потока данных медиаконтента в реальном времени и порядковый номер запроса паузы.

[0010] В ответ на прием запроса паузы передача потока данных медиаконтента в реальном времени сеанса связи может быть приостановлена, тогда как сеанс связи поддерживается. В ответ на прием запроса паузы сообщение подтверждения паузы может передаваться к другому устройству связи, при этом сообщение подтверждения паузы включает в себя идентификацию потока данных медиаконтента в реальном времени и порядковый номер запроса паузы. После передачи сообщения подтверждения паузы может быть получен запрос возобновления от другого устройства связи, при этом запрос возобновления включает в себя идентификацию потока данных медиаконтента в реальном времени и порядковый номер запроса возобновления. В ответ на прием запроса возобновления может быть возобновлена передача потока данных медиаконтента в реальном времени сеанса связи.

[0011] В ответ на прием запроса возобновления сообщение подтверждения возобновления может передаваться к другому устройству связи, при этом сообщение подтверждения возобновления включает в себя идентификацию потока данных медиаконтента в реальном времени и порядковый номер запроса возобновления. Более того, порядковый номер запроса возобновления увеличивается относительно порядкового номера запроса паузы так, что порядковые номера запроса паузы и возобновления выбираются из одного и того же пространства порядковых номеров.

[0012] В ответ на прием запроса паузы сообщение отказа может передаваться к другому устройству связи, тогда как продолжается передача потока данных медиаконтента в реальном времени к другому устройству связи, при этом сообщение отказа включает в себя идентификацию потока данных медиаконтента в реальном времени и порядковый номер запроса паузы.

[0013] В ответ на прием запроса паузы сообщение отсутствия подтверждения (NACK) может передаваться к другому устройству связи, продолжая при этом передавать поток данных медиаконтента в реальном времени к другому устройству связи, при этом сообщение отсутствия подтверждения включает в себя идентификацию потока данных медиаконтента в реальном времени и порядковый номер запроса паузы.

[0014] Кроме того, идентификация потока данных медиаконтента в реальном времени может включать в себя источник синхронизации (SSRC), который уникально идентифицирует поток данных медиаконтента в пределах сеанса связи в реальном времени.

[0015] В соответствии с другими вариантами осуществления настоящего изобретения, приемное устройство связи может включать в себя сетевой интерфейс и процессор, соединенный с сетевым интерфейсом. Сетевой интерфейс может быть выполнен с возможностью обеспечения сетевой связи по сети с другим устройством связи во время сеанса связи в реальном времени. Процессор может быть выполнен с возможностью приема потока данных медиаконтента сеанса связи в реальном времени от другого устройства связи посредством сетевого интерфейса, при этом пакеты потока данных медиаконтента в реальном времени включают в себя идентификацию потока данных медиаконтента в реальном времени. Процессор может быть дополнительно выполнен с возможностью передачи запроса паузы посредством сетевого интерфейса к другому устройству связи, при этом запрос паузы включает в себя идентификацию потока данных медиаконтента в реальном времени и порядковый номер запроса паузы.

[0016] Процессор может быть дополнительно выполнен с возможностью приема сообщения подтверждения паузы от другого устройства связи после передачи запроса паузы, при этом сообщение подтверждения паузы включает в себя идентификацию потока данных медиаконтента в реальном времени и порядковый номер запроса паузы. Кроме того, процессор может быть выполнен с возможностью передачи запроса возобновления посредством сетевого интерфейса к другому устройству связи после приема сообщения подтверждения паузы, при этом запрос возобновления включает в себя идентификацию потока данных медиаконтента в реальном времени и порядковый номер запроса возобновления, отличный от порядкового номера запроса паузы. Процессор также может быть выполнен с возможностью приема сообщения подтверждения возобновления от другого устройства связи посредством сетевого интерфейса после передачи запроса возобновления, при этом сообщение подтверждения возобновления включает в себя идентификацию потока данных медиаконтента в реальном времени и порядковый номер запроса возобновления. Порядковый номер запроса возобновления может быть увеличен относительно порядкового номера запроса паузы так, что порядковые номера паузы и возобновления выбираются из одного и того же пространства порядковых номеров.

[0017] Запрос паузы может быть первым запросом паузы, и порядковый номер запроса паузы может быть порядковым номером первого запроса паузы. Более того, процессор дополнительно может быть выполнен с возможностью передачи второго запроса паузы посредством сетевого интерфейса к другому устройству связи, в ответ на истечение времени ожидания после передачи первого запроса паузы, при этом второй запрос паузы включает в себя идентификацию потока данных медиаконтента в реальном времени и порядковый номер второго запроса паузы, отличный от порядкового номера первого запроса паузы. Процессор дополнительно может быть выполнен с возможностью приема сообщения подтверждения паузы от другого устройства связи посредством сетевого интерфейса после передачи второго запроса паузы, при этом сообщение подтверждения паузы включает в себя идентификацию потока данных медиаконтента в реальном времени и порядковый номер второго запроса паузы.

[0018] Порядковый номер второго запроса паузы может быть увеличен относительно порядкового номера запроса паузы так, что порядковые номера первого и второго запроса паузы выбираются из одного и того же пространства порядковых номеров.

[0019] Кроме того, идентификация потока данных медиаконтента в реальном времени может быть источником синхронизации (SSRC), который уникально идентифицирует поток данных медиаконтента в пределах сеанса связи в реальном времени.

[0020] В соответствии еще с другими вариантами осуществления настоящего изобретения, передающее устройство связи может включать в себя сетевой интерфейс и процессор, соединенный с сетевым интерфейсом. Сетевой интерфейс может быть выполнен с возможностью обеспечения сетевой связи по сети с другим устройством связи во время сеанса связи в реальном времени. Процессор может быть выполнен с возможностью передачи потока данных медиаконтента в течение сеанса связи в реальном времени к другому устройству связи посредством сетевого интерфейса, при этом пакеты потока данных медиаконтента в реальном времени включают в себя идентификацию потока данных медиаконтента в реальном времени. Процессор может быть дополнительно выполнен с возможностью приема запроса паузы от другого устройства связи посредством сетевого интерфейса, при этом запрос паузы включает в себя идентификацию потока данных медиаконтента в реальном времени и порядковый номер запроса паузы.

[0021] Процессор дополнительно может быть выполнен с возможностью приостановления передачи потока данных медиаконтента в реальном времени сеанса связи при поддержании сеанса связи, в ответ на прием запроса паузы, и передачи сообщения подтверждения паузы к другому устройству связи посредством сетевого интерфейса, в ответ на прием запроса паузы, при этом сообщение подтверждения паузы включает в себя идентификацию потока данных медиаконтента в реальном времени и порядковый номер запроса паузы. Процессор дополнительно может быть выполнен с возможностью приема запроса возобновления от другого устройства связи посредством сетевого интерфейса после передачи сообщения подтверждения паузы, при этом запрос возобновления включает в себя идентификацию потока данных медиаконтента в реальном времени и порядковый номер запроса возобновления, отличный от порядкового номера запроса паузы. В ответ на прием запроса возобновления процессор может быть выполнен с возможностью возобновления передачи потока данных медиаконтента в реальном времени сеанса связи и передачи сообщения подтверждения возобновления к другому устройству связи посредством сетевого интерфейса, при этом сообщение подтверждения возобновления включает себя идентификацию потока данных медиаконтента в реальном времени и порядковый номер запроса возобновления. Кроме того, порядковый номер запроса возобновления может быть увеличен относительно порядкового номера запроса паузы так, что порядковые номера паузы и возобновления выбираются из одного и того же пространства порядковых номеров.

[0022] Процессор дополнительно может быть выполнен с возможностью передачи сообщения отказа к другому устройству связи посредством сетевого интерфейса, в ответ на прием запроса паузы, при продолжении передачи потока данных медиаконтента в реальном времени к другому устройству связи, при этом сообщение отказа включает в себя идентификацию потока данных медиаконтента в реальном времени и порядковый номер запроса паузы.

[0023] Процессор дополнительно может быть выполнен с возможностью передачи сообщения отсутствия подтверждения (NACK) к другому устройству связи посредством сетевого интерфейса в ответ на прием запроса паузы, при продолжении передачи потока данных медиаконтента в реальном времени к другому устройству связи, при этом сообщение отсутствия подтверждения включает в себя идентификацию потока данных медиаконтента в реальном времени и порядковый номер запроса паузы.

[0024] Кроме того, идентификация потока данных медиаконтента в реальном времени может включать в себя источник синхронизации (SSRC), который уникально идентифицирует поток данных медиаконтента в пределах сеанса связи в реальном времени.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

[0025] Прилагаемые чертежи, которые включены сюда, чтобы обеспечить дополнительное понимание раскрытия, и объединены и составляют часть этой заявки, иллюстрируют определенный неограничивающий вариант осуществления (определенные неограничивающие варианты осуществления) изобретения. На чертежах:

[0026] Фиг. 1-7 представляют собой блок-схемы последовательности операций, иллюстрирующие операции паузы и возобновления в соответствии с некоторыми вариантами осуществления, раскрытыми здесь;

[0027] Фиг. 8 представляет собой схему, иллюстрирующую формат сообщения обратной связи, относящийся к операциям паузы и возобновления в соответствии с некоторыми вариантами осуществления, раскрытыми здесь;

[0028] Фиг. 9 представляет собой схематичное изображение, иллюстрирующее множество оконечных устройств и узел связи, осуществляющие связь посредством сети в соответствии с некоторыми вариантами осуществления;

[0029] Фиг. 10 представляет собой блок-схему, иллюстрирующую оконечное устройство по фиг. 9 в соответствии с некоторыми вариантами осуществления;

[0030] Фиг. 11 представляет собой блок-схему, иллюстрирующую узел связи по фиг. 9 в соответствии с некоторыми вариантами осуществления.

ОПИСАНИЕ ПРЕДПОЧТИТЕЛЬНЫХ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ ИЗОБРЕТЕНИЯ

[0031] В следующем подробном описании множественные специфические детали изложены с целью обеспечить исчерпывающее понимание изобретения. Однако специалистам в данной области техники следует понимать, что настоящее изобретение может использоваться на практике без этих специфических деталей. В других примерах хорошо известные способы, процедуры, компоненты и схемы не были описаны подробно, чтобы не вносить неясность в настоящее изобретение. Кроме того, термины «должен», «не должен», «требуется», «будет», «не будет», «следует», «не следует», «рекомендуется», «может» и «опционально» могут использоваться здесь в отношении конкретных вариантов осуществления, не ограничивая объем настоящего изобретения. Если выразиться другими словами в качестве примера, элемент(-ы), операция (операции), этап(-ы) и т.д. могут требоваться в отношении конкретного варианта осуществления, не требуясь при этом для всех вариантов осуществления. Соответственно, эти термины не должны рассматриваться как ограничивающие относительно настоящей заявки и формулы изобретения, опускающей упомянутые элемент(-ы), операция (операции), этап(-ы) и т.д. Кроме того, в пределах объема, в котором используются такие термины, как «должен», «не должен», «требуется», «будет», «не будет», «следует», «не следует», «рекомендуется», «может» и «опционально», в следующем раскрытии, эти термины могут быть интерпретированы в соответствии с RFC (запросом на комментарии) 2119 авторства S. Bradner и озаглавленным «Ключевые слова для использования в RFC для индикации уровней требований» (BCP 14, RFC 2119, март 1997). В дополнение к определениям, предложенным в настоящем раскрытии, также могут применяться определения из: RFC 3550, автор H. Schulzrinne и другие, озаглавленный «RTP: транспортный протокол для приложений в реальном времени» (STD 64, RFC 3550, июль 2003); документа RFC 4585, автор J. Ott и др., озаглавленного «Расширенный профиль RTP для обратной связи на основе транспортного протокола управления передачей в реальном времени (RTCP) (RTP/AVPF)» (RFC 4585, июль 2006); и/или документа RFC 5104, автор S. Wegner и др., озаглавленного «Сообщения управления кодеком в аудиовизуальном профиле RTP с обратной связью (AVPF)» (RFC 5104, февраль 2008).

[0032] С ростом популярности мультимедийных приложений для работы в реальном времени пользователи могут потребовать большего контроля над сеансами связи. Варианты осуществления этого раскрытия могут предложить приемное оконечное устройство в мультимедийном разговоре/коммуникации, которое может приостанавливать и/или возобновлять входящий поток(-и) данных от передающего оконечного устройства (устройств) путем отправки сообщений обратной связи в реальном времени. Транспортный протокол управления передачей в реальном времени (RTCP) является родственным протоколом по отношению к транспортному протоколу для работы в реальном времени (RTP), который широко используется для передачи данных в реальном времени. Передающие и приемные оконечные устройства RTP, однако, могут использовать RTCP для сообщения статистики передачи и приема в регулярные интервалы. Варианты осуществления этого раскрытия могут расширить сообщения кодового управления (ССМ) (см. RFC 5104, приведено выше) путем добавления двух новых сообщений обратной связи в реальном времени, которые подлежат отправке от приемного оконечного устройства к передающему оконечному устройству, чтобы приостановить и возобновить потоки данных RTP.

[0033] Коммуникации в реальном времени привлекают больше пользователей, разрабатывается все больше приложений, таких как мультимедийные приложения для разговора. Мультимедийные приложения для разговора могут существовать в виде пиринговых приложений для чата и приложений для многосторонней видео-конференц-связи, управляемых блоком управления многосторонней связью (MCU).

[0034] Видео-конференц-связь может задействовать множество участников, каждый из который имеет свои предпочтения и требования для управления сеансом связи, от начала сеанса связи и также во время сеанса. Варианты осуществления этого раскрытия могут обеспечить мультимедийные коммуникации, когда участник может решить приостановить входящий поток данных от конкретного источника (источников) и возобновить поток данных, когда требуется/необходимо. Приемному оконечному устройству не нужно завершать сеанс связи от источника (источников) приостановленного потока данных и начинать все сначала путем налаживания новых параметров сеанса связи, например, обмениваясь SDP (протоколом описания сеансов). Наоборот, если сеанс связи завершен, приемному и/или передающему оконечному устройству может понадобиться установить новый сеанс связи, который может включать в себя налаживание новых параметров сеанса связи путем обмена SDP.

[0035] Как это используется здесь, термин «поток данных медиаконтента» (или «поток данных») относится к медиа (например, потоку данных видео- и/или аудио медиаконтента), отправляемому от одного конкретного устройства захвата медиа (такого как микрофон для аудиомедиа и/или видеокамера для видеомедиа) на оконечное устройство связи. Термин «оконечное устройство» (также именуемое «оконечной точкой») относится к устройству связи, которое имеет дело с медиа путем создания одного или нескольких потоков данных медиаконтента (например, создавая потоки аудио и/или видео, используя микрофон и/или видеокамеру) и/или завершения одного или нескольких потоков данных медиаконтента (например, генерируя вывод аудио- и/или видеоданных), принятых от одного или нескольких оконечных устройств. Кроме того, каждое оконечное устройство, участвующее в сеансе связи, может быть и передающим оконечным устройством, генерирующим один или несколько потоков данных медиаконтента для представления других оконечных устройств (действующих как приемные оконечные устройства) сеанса связи, и приемным оконечным устройством, обеспечивающим/формирующим выход аудио- и/или видеоданных в ответ на один или несколько потоков данных медиаконтента от другого оконечного устройства (устройств) (действующего (действующих) как передающее оконечное устройство) сеанса связи. В качестве примера блок смешивания RTP (транспортный протокол для работы в реальном времени) может рассматриваться как оконечная точка.

[0036] Фиг. 9 представляет собой схематичное изображение, иллюстрирующее множество оконечных устройств 111-1 - 111-n, участвующих в сеансе связи с потоковой передачей данных (как то сеанс видео-конференц-связи) посредством сети 151 (например, Интернет), и узел 115 связи в соответствии с некоторыми вариантами осуществления. При том что по меньшей мере пять оконечных устройств 111 показаны на фиг. 9 в качестве примера, варианты осуществления настоящего изобретения могут быть реализованы с использованием любого количества - из двух или более - оконечных устройств. Когда установилась видеоконференция, каждое оконечное устройство 111 может генерировать поток данных медиаконтента (включающий в себя аудио и видео), и соответствующие потоки данных медиаконтента от всех оконечных устройств 111 могут передаваться к узлу 115 связи (например, реализованному как блок смешивания или транслятор) посредством сети 151. Для каждого приемного оконечного устройства 111 узел 115 связи затем может выбирать поток или потоки данных медиаконтента, и выбранные поток или потоки данных медиаконтента затем могут пересылаться от узла 115 связи посредством сети 151 к соответствующим оконечным узлам 111. В частности, узел 115 связи может выбрать поток данных медиаконтента для отправки к соответствующему оконечному узлу 111 в ответ на входной сигнал от соответствующего оконечного узла 111. Другими словами, каждое оконечное устройство 111 может выбирать поток данных медиаконтента для представления на том оконечном устройстве 111. При том что центральный узел 115 связи (такой как блок смешивания или транслятор) показан в качестве примера, могут быть реализованы и другие варианты осуществления (например, при сеансе связи «от точки к точке»), с двумя оконечными устройствами 111, осуществляющими связь друг с другом напрямую посредством сети 151.

[0037] Фиг. 10 представляет собой блок-схему, иллюстрирующую оконечное устройство 111 по фиг. 9 в соответствии с некоторыми вариантами осуществления. Оконечное устройство 111, например, может включать в себя процессор 131, соединенный с дисплеем 121 (например, экран с жидкокристаллическим дисплеем, обеспечивающий вывод видео) или выходом дисплея, интерфейс 129 ввода пользователя (например, включающий в себя клавиатуру, реагирующую на прикосновения поверхность 121 дисплея и т.д.), динамик 123 или выход динамика, одну или несколько видеокамер 125 или вход(-ы) видеокамер и один или несколько микрофонов 127 или вход(-ы) микрофонов. Кроме того, сетевой интерфейс 133 может обеспечивать соединение данных/связей между процессором 131 и сетью 151. Оконечное устройство 111, например, может быть смартфоном, планшетным компьютером, нетбуком, портативным компьютером, стационарным компьютером, стационарным телефоном для видео-конференц-связи или любым другим устройством, поддерживающим функцию мультимедийной конференц-связи. Соответственно, соединение между сетевым интерфейсом 133 и сетью 151 может обеспечиваться посредством проводного соединения (например, с использованием модема цифровой абонентской линии, кабельного модема и т.д.), посредством беспроводного соединения (например, посредством беспроводной сети 3G/4G, посредством линии WiFi и т.д.) или посредством их комбинации.

[0038] При реализации в виде беспроводного мобильного терминала, такого как смартфон, планшетный компьютер, нетбук или портативный компьютер, например, все элементы по фиг. 10 (включая видеокамеру 125 и микрофон 127) могут быть представлены в пределах корпуса мобильного терминала. В таком мобильном терминале встроенная видеокамера и/или микрофон может обеспечивать один поток данных медиаконтента, и выход для видео/аудио может быть предусмотрен с использованием встроенного динамика и дисплея. В других вариантах осуществления оконечное устройство 111 может не включать в себя встроенную видеокамеру, микрофон, динамик и/или дисплей. Наоборот, такое устройство может включать в себя входы для одного или нескольких внешних видеокамер и/или микрофонов и выходы для одного или нескольких дисплеев и/или динамиков. Что касается системы видео-конференц-связи для устройства более обширного конференц-зала, например, то множество внешних камер и соответствующих микрофонов может быть расположено вокруг конференц-зала и подсоединено к процессору 131 посредством входов 125/127 для видео/микрофона, а выходы для дисплея и динамика могут быть подсоединены к внешнему дисплею/динамику (например, широкоформатному дисплею, проекционному дисплею и т.д.). Оконечное устройство 111 может, таким образом, обеспечивать один или несколько потоков данных медиаконтента для одной или нескольких пар видео/микрофона. Если оконечное устройство обеспечивает более одного потока данных медиаконтента, каждый поток данных медиаконтента может быть отдельно идентифицирован для выбора другими оконечными устройствами, вовлеченными в сеанс связи.

[0039] Как рассматривается более подробно ниже, каждое оконечное устройство 111 может также обеспечивать/формировать один или несколько потоков данных медиаконтента во время сеанса связи посредством дисплея/динамика 121 и 123 (и/или посредством внешнего дисплея/динамика), и каждое оконечное устройство 111, действующее как приемное оконечное устройство, может динамически приостанавливать и/или возобновлять один или несколько потоков данных медиаконтента из сеанса связи, который/которые подлежат обеспечению/формированию во время сеанса связи. Передающее оконечное устройство, генерирующее поток данных, который был приостановлен соответствующим приемным оконечным устройством, может приостанавливать поток данных, если никакие другие приемные оконечные устройства уже не используют этот поток данных. Кроме того, передающее оконечное устройство может возобновлять отправку приостановленного потока данных в ответ на запрос любого приемного оконечного устройство для возобновления потока данных. В оконечном устройстве 111, таком как смартфон, с ограниченным размером дисплея, в любое время может быть выбран единственный поток данных медиаконтента из сеанса связи. Когда обеспечивается дисплей большего размера (например, у стационарного компьютера, внешний дисплей и т.д.), множественные потоки данных медиаконтента могут выбираться в любое время.

[0040] Фиг. 11 представляет собой блок-схему, иллюстрирующую узел 115 связи по фиг. 9 (также именуемый узлом для конференц-связи) в соответствии с некоторыми вариантами осуществления. Как показано на фиг. 11, узел 115 связи может включать в себя процессор 231 и сетевой интерфейс 133, причем сетевой интерфейс 131 обеспечивает данные/связь между процессором 231 и сетью 151. Процессор 231 может, таким образом, принимать один или несколько потоков данных медиаконтента от каждого оконечного устройства 111, вовлеченного в сеанс связи, и процессор 231 может пересылать один или несколько потоков данных медиаконтента к одному или нескольким оконечным устройствам в ответ на динамические команды паузы и/или возобновления от соответствующих оконечных устройств, действующих как приемные оконечные устройства, и процессор 231 может приостанавливать и/или возобновлять потоки данных, принятые от оконечных устройств, действующих как передающие оконечные устройства, в ответ на команды паузы и/или возобновления, принятые от оконечных устройств, действующих как приемные оконечные устройства.

[0041] Многие приложения для работы в реальном времени используют RTP (транспортный протокол для работы в реальном времени) (см. RFC 3550, процитировано выше) для транспортировки. RTP работает вместе с RTCP (транспортный протокол управления передачей в реальном времени) (см. RFC 3550, процитировано выше), который отвечает за обмен информацией управления во время сеанса связи. Используя RTCP, каждое оконечное устройство 111 может обмениваться отчетами с обратной связью о качестве передачи и приема. Текущие сообщения с обратной связью RTCP могут не поддерживать приостановку и возобновление входящего потока данных. Более того, обмен регулярными отчетами с обратной связью RTCP может следовать конкретному периодическому образцу так, что каждое передающее оконечное устройство, приемное оконечное устройство и/или узел связи передает эти отчеты в конкретные интервалы.

[0042] CCM (сообщения управления кодеком) (см. RFC 5104, процитировано выше) могут увеличивать AVPF (аудиовизуальный профиль с обратной связью) (см. RFC 4585, процитировано выше) добавлением дополнительных сообщений с обратной связью, которые могут потерять свое назначение, если отправляются с регулярными отчетами RTCP (например, если требуется немедленная передача). Варианты осуществления настоящего раскрытия могут расширять CCM путем использования двух новых сообщений с обратной связью RTCP в реальном времени, именуемых запросами PAUSE (паузы) и RESUME (возобновления). Запрос PAUSE может/будет передаваться от приемного оконечного устройства 111 к передающему оконечному устройству, чтобы приостановить поток RTP, а запрос RESUME может/будет отправляться в том же направлении для возобновления прежде приостановленного потока данных. Приемное оконечное устройство 111 может/будет определять SSRC (источник синхронизации) как идентификацию источника (например, передающее оконечное устройство 111 и/или узел 115 связи) в запросах PAUSE и RESUME. Хотя запросы PAUSE и RESUME могут быть сообщениями с обратной связью в реальном времени, рассматриваемые здесь варианты осуществления не запрещают отправку запросов PAUSE и RESUME в регулярном сборном отчете RTCP, если/когда время отправки сообщения PAUSE или RESUME совпадает со времени передачи регулярного отчета RTCP.

[0043] Поскольку RTP не гарантирует надежной передачи данных, приемное оконечное устройство 111 (то есть оконечное устройство, которое принимает поток данных и передает сообщение PAUSE/RESUME) может ожидать подтверждения от передающего оконечного устройства 111 (то есть оконечного устройства, которое передает поток данных и принимает сообщение PAUSE/RESUME) или от узла 115 связи, чтобы гарантировать то, что прежде переданное сообщение PAUSE или RESUME достигает адресата (то есть передающего оконечного устройства 111 или узла 115 связи). Это раскрытие дополнительно определяет четыре различных типа ответа/подтверждения от передающего оконечного устройства RTP к приемному оконечному устройству в представленном ниже разделе, озаглавленном «Подтверждения сообщений».

[0044] Приемное оконечное устройство 111 (или его пользователь) может принять решение о приостановке потока данных от конкретного передающего оконечного устройства 111 RTP в силу следующих причин, таких как:

* Приемное оконечное устройство 111 (или его пользователь) во время многосторонней видеоконференции может принять решение о приеме потоков данных только от выбранного источника или источников (то есть от выбранных передающих оконечных устройств 111) в силу перегрузки сети;

* Приемное оконечное устройство 111 (или его пользователь) во время многосторонней видеоконференции может принять решение о приостановке потока данных от передающего оконечного устройства 111 RTP, которое подвергается повышенному шуму (например, когда передающее оконечное устройство 111 находится в шумном помещении);

* Приемное оконечное устройство (или его пользователь) может приостанавливать поток данных от передающего оконечного устройства, которое подвергается внутренней системной проблеме, до тех пор, пока проблема не решится; и/или

* Пользователь приемного оконечного устройства 111 может приостанавливать поток данных от передающего оконечного устройства 111, поскольку он (пользователь) думает, что участник(-и), использующий (использующие) передающее оконечное устройство 111, не вносит (вносят) значительный вклад в разговор в настоящий момент.

[0045] СООБЩЕНИЯ С ОБРАТНОЙ СВЯЗЬЮ:

[0046] ССМ (сообщение управления кодеком) (см. RFC 5104, процитировано выше) разбивает различные сообщения с обратной связью RTCP (транспортный протокол управления передачей в реальном времени)) на четыре типа: Запрос, Команда, Индикация и Уведомление. Варианты осуществления настоящего раскрытия могут поместить сообщения PAUSE и RESUME в категорию Запроса, поскольку для сообщений PAUSE и RESUME могут быть желательны/могут требоваться подтверждения.

[0047] Подтверждение - это подтверждение от оконечного устройства 111 или узла 115 связи, принимающего сообщение PAUSE/RESUME (то есть оконечного устройства, генерирующего/отправляющего приостанавливаемый/возобновляемый поток данных), к оконечному устройству 111, которое передало сообщение PAUSE/RESUME (то есть оконечному устройству, принимающему приостанавливаемый/возобновляемый поток данных), с подтверждением приема сообщения PAUSE/RESUME.

[0048] Передающее оконечное устройство 111 является объектом RTP (транспортного протокола для работы в реальном времени), который генерирует/отправляет поток данных RTP, и передающее оконечное устройство также может быть приемным оконечным устройством в том же сеансе связи.

[0049] Приемное оконечное устройство 111 является объектом RTP, который принимает поток данных RTP от передающего оконечного устройства 111, и приемное оконечное устройство также может быть передающим оконечным устройством в том же сеансе связи.

[0050] Блок смешивания - промежуточный узел RTP (например, узел 115 связи), который принимает потоки данных от различных узлов (например, от разных передающих оконечных устройств 111), комбинирует потоки данных, чтобы генерировать один поток данных и пересылает этот единственный поток данных адресатам (например, к разным приемным оконечным устройствам).

[0051] Оконечное устройство-участник - участник сеанса связи мультимедийного разговора.

[0052] Приостановленный отправитель - передающее оконечное устройство RTP, которое принимает запрос PAUSE от всех других устройство-участников сеанса связи и прекращает/приостанавливает их передачу на любой заданный период времени, в течение которого никакое другое устройство-участник не принимает его передачу.

[0053] Останавливающий приемник - это принимающее оконечное устройство RTP, которое отправляет запрос PAUSE к другому участнику (другим участникам).

[0054] Возможными причинами, по которым приемное оконечное устройство 111 может приостановить передающее оконечное устройство RTP, рассмотрены выше. Приостановка и возобновление могут быть зависимыми от времени, так, что приемное оконечное устройство 111 может принимать решение о приостановке потока данных RTP передающего оконечного устройства 111 на определенное время, по истечении которого приемное оконечное устройство 111 может захотеть возобновить прием потока RTP от передающего оконечного устройства 111. Эта зависимость от времени может означать, что сообщения, относящиеся к операциям приостановки и возобновления, могут/должны передаваться к передающему оконечному устройству 111 в реальном времени с целью достичь намеченной цели.

[0055] НАПРАВЛЕНИЕ СООБЩЕНИЯ:

[0056] Передача сообщений PAUSE и RESUME может/должна быть ответственностью приемного оконечного устройства 111, которое желает приостановить или возобновить поток данных от передающего оконечного устройства (устройств) 111. Передающее оконечное устройство может быть неспособным осуществлять приостановку/возобновления для себя, не приняв сообщение PAUSE/RESUME от другого устройства.

[0057] ПРИМЕНЕНИЕ SSRC (ИСТОЧНИКА СИНХРОНИЗАЦИИ):

[0058] Сообщения PAUSE и RESUME могут/будут использоваться в отношении SSRC передающего оконечного устройства 111 RTP, что означает, что приемное оконечное устройство 111 может включать в себя SSRC передающего оконечного устройства 111 в запросах PAUSE и RESUME. Если блок смешивания (например, реализованный в узле 115 связи) привлекается для использования между передающим и приемным оконечными устройствами 111, приостанавливающее или возобновляющее оконечное устройство 111 может определять SSRC блока смешивания.

[0059] ПОДТВЕРЖДЕНИЯ:

[0060] RTP не гарантирует надежной передачи данных. Вместо этого RTP зависит от протоколов низкого уровня в этих целях. Возможно, что сообщение PAUSE и/или RESUME, передаваемое от приемного оконечного устройства 111 RTP, может не достичь своего адресата, то есть передающего оконечного устройства 111 RTP. Подобно, также возможно, что сообщение PAUSE или RESUME достигает передающего оконечного устройства 111 RTP, но по каким-то причинам передающее оконечное устройство 111 не отвечает путем приостановки или возобновления потока. Вместо этого передающее оконечное устройство 111 может ожидать запросов также и от других приемных оконечных устройств 111 (как рассматривается ниже в разделе «Подтверждения сообщений»). В этом случае приемное оконечное устройство 111 RTP может сделать вывод, что предыдущее сообщение PAUSE или RESUME было потеряно, и приемное оконечное устройство 111 может ошибочно осуществить его повторную передачу. Чтобы сократить/избежать это, источник RTP (то есть передающее оконечное устройство 111 RTP или узел 115 связи) может/будет отправлять подтверждение в ответ на каждое сообщение PAUSE и RESUME. Раздел «Подтверждения сообщений» этого раскрытия (представленный ниже) описывает различные типы подтверждений для сообщений PAUSE и RESUME.

[0061] ЗНАЧЕНИЕ ВРЕМЕНИ ОЖИДАНИЯ:

[0062] Раздел «Подтверждения» (выше) описывает, что приемное оконечное устройство 111 RTP может ожидать подтверждения от передающего оконечного устройства 111 или узла 115 для конференц-связи для каждого сообщения PAUSE и RESUME, что отправляется от приемного оконечного устройства 111 к передающему оконечному устройству 111 или узлу 115 для конференц-связи. Если приемное оконечное устройство 111 не получает подтверждения в течение периода ожидания, определенного значением времени ожидания, приемное оконечное устройство 111 может осуществлять повторную передачу сообщения PAUSE/RESUME до тех пор, пока приемное оконечное устройство 111 не получит подтверждение от передающего оконечного устройства 111 или узла 115 для конференц-связи или не обнаружит требуемого поведения передающего оконечного устройства или узла для конференц-связи, то есть что или поток данных от передающего оконечного устройства или узла для конференц-связи приостанавливается или возобновляется.

[0063] После отправки сообщения PAUSE и RESUME приемное оконечное устройство 111 RTP может запустить таймер. Если приемное оконечное устройство 111 не получает какого-либо подтверждения или не обнаруживает ожидаемых изменений в поведении до того как выйдет заданное по таймеру время, приемное оконечное устройство 111 может осуществлять повторную передачу сообщения PAUSE или RESUME и заново запускать таймер. По выявлении ожидаемых изменений в поведении или по получении подтверждения приемное оконечное устройство 111 RTP может/будет останавливать повторную передачу сообщения PAUSE или RESUME. Значение времени ожидания может/будет определяться нормальными правилами ширины полосы пропускания RTCP и синхронизации по времени, применимыми к сеансу связи (раздел 6.2 RFC 3550, процитировано выше).

[0064] ПОРЯДКОВАЯ НУМЕРАЦИЯ

[0065] Каждое сообщение PAUSE и RESUME может/должно иметь уникальный порядковый номер, который может/должен увеличиваться на единицу каждый раз, когда сообщение PAUSE/RESUME передается от приемного оконечного устройства 111. Сообщения PAUSE и RESUME, передаваемые одним и тем же приемным оконечным устройством 111, могут/будут использовать одно и то же числовое пространство. Если передающее оконечное устройство 111 RTP принимает множество сообщений PAUSE и/или RESUME от одного и того же приемного оконечного устройства, передающее оконечное устройство может/должно следовать сообщению с самым большим порядковым номером. Преимущество использования одного и того же пространства порядковых номеров заключается в том, чтобы избежать неясности для передающего оконечного устройства по поводу того, какому сообщению PAUSE/RESUME следовать в случае повторной передачи (передач). Например, если передающее оконечное устройство RTP принимает оба сообщения и PAUSE, и RESUME от одного и того же приемного оконечного устройства в одно и то же время или приблизительно в одно и то же время (например, в силу поздней доставки пакета или по другой причине), прежде чем решить, на какое сообщение отвечать, передающее оконечное устройство может/должно следовать сообщению с самым большим порядковым номером. Каждое подтверждение может/должно иметь такой же порядковый номер, как в сообщении (PAUSE или RESUME), на которое дается ответ.

[0066] СОСТОЯНИЯ УЧАСТНИКОВ:

[0067] Это раскрытие представляет два новых состояния передающего оконечного устройства RTP, то есть состояние паузы и состояние возобновления.

[0068] СОСТОЯНИЕ ПАУЗЫ:

[0069] Участник (например, передающее оконечное устройство) может находиться в состоянии паузы, когда оно приостанавливает свои передачи после получения запросов PAUSE от все прочих участников (например, от всех приемных оконечных устройств) сеанса. Передающее оконечное устройство может, таким образом, находиться в состоянии паузы, когда ни один из участников не желает принимать его передачу (передачи). Только передающее оконечное устройство RTP может/будет находиться в состоянии паузы. Следующие подразделы рассматривают потенциальные вопросы, когда передающее оконечное устройство RTP переходит в состояние паузы.

[0070] СООБЩЕНИЕ RTCP BYE:

[0071] Когда оконечное устройство-участник выходит из сеанса связи, оно может отправлять сообщение RTCP BYE. В дополнение к семантике, описанное в разделе 6.3.4 и 6.3.7 RFC 3550 (цитируется выше), следующие два условия также могут/должны учитываться, когда участник RTP отправляет сообщение RTCP BYE.

- Если приостановленный отправитель отправляет сообщение RTCP BYE, никакой приемник не сможет/будет дополнительно отправлять ему запрос PAUSE или RESUME.

- По мере того как передающее оконечное устройство приостанавливает свои передачи по приему запросов PAUSE от всех приемных оконечных устройств сеанса, оно может вести учет всех приемных оконечных устройств, которые желают и которые не желают принимать его передачи. Если приостанавливающее приемное оконечное устройство отправляет сообщение RTCP BYE, передающее оконечное устройство может не принимать/не станет принимать в расчет это приемное оконечное устройство, когда решит приостановить/возобновить свои передачи.

[0072] СООБЩЕНИЕ RTCP BYE:

[0073] Эти условия также могут быть действительны, если транслятор RTP используется при осуществлении связи. Но когда блок смешивания RTP применяется между оконечными устройствами-участниками (где блок смешивания RTP пересылает поток или потоки данных путем предоставления своего собственного SSRC в качестве идентификации в потоке данных RTP), управление отправкой запросов PAUSE и RESUME к передающему оконечному устройству может стать/будет ответственностью блока смешивания. Блок смешивания не сможет/будет отправлять каких-либо запросов PAUSE или RESUME к передающему оконечному устройству, которое отправило сообщение RTCP BYE. Подобным образом, если приостанавливающее приемное оконечное устройство отправляет сообщение RTCP BYE, блок смешивания не сможет/будет принимать во внимание тот приемник, когда решить приостановить поток.

[0074] ВРЕМЯ ОЖИДАНИЯ SSRC:

[0075] Раздел 6.3.5 в RFC 3550 (цитируется выше) описывает время ожидания SSRC оконечного устройства-участника RTP. Каждое оконечное устройство-участник RTP может сохранять списки передающих и приемных оконечных устройств для сеанса связи. Если оконечное устройство-участник не получает каких-либо пакетов RTP или RTCP от другого участника (других участников) в течение последних пяти отчетных интервалов RTCP, оно может удалить участника из списка приемных оконечных устройств. Условия, описанные выше в разделе «Сообщение RTCP BYE» в отношении сообщения RTCP BYE, также могут быть действительны для времени ожидания SSRC и в случае с транслятором, и в случае с блоком смешивания.

[0076] СОСТОЯНИЕ ВОЗОБНОВЛЕНИЯ:

[0077] Передающее оконечное устройство RTP может переходить в состояние возобновления, когда возобновляет передачу потока данных RTP после состояния паузы. Состояние возобновления относится к нормальному состоянию отправки RTP - такому, когда передающее оконечное устройство RTP передает свой поток данных. Целью определения нового состояния «возобновления» является описание того, что передающее оконечное устройство прежде было приостановлено. Передающее оконечное устройство входить в состояние возобновления, когда по меньшей мере одно из приемных оконечных устройств, которые прежде отправляли запрос PAUSE к передающему оконечному устройству, затем отправляет запрос RESUME к передающему оконечному устройству.

[0078] ПОДТВЕРЖДЕНИЯ СООБЩЕНИЙ:

[0079] Учитывая, что RTP не гарантирует надежной доставки данных, приемное оконечное устройство RTP может/будет ожидать подтверждения от передающего оконечного устройства для каждого отправленного запроса PAUSE или RESUME, который отправлялся к передающему оконечному устройству. Если приемник не получает какого-либо подтверждения или не выявляет ожидаемого поведения (то есть приостановленной или возобновленной передачи потока данных) от передающего оконечного устройства, приемное оконечное устройство может/могло бы осуществлять повторную передачу запроса PAUSE или RESUME. Перед повторной передачей приемное оконечное устройство может/будет ожидать значения времени ожидания, что может/будет следовать правилам временной синхронизации RTCP (см. RFC 3550, процитировано выше).

[0080] Каждое подтверждение может/будет иметь тот же порядковый номер, что и сообщение запроса (PAUSE или RESUME), которое оно подтверждает. Передающее оконечное устройство может отвечать на запросы PAUSE или RESUME четырьмя различными способами: отсутствие подтверждения (NACK); подтверждение паузы (PACK); подтверждение возобновления (RACK); и отказ (REFUSE).

[0081] ОТСУТСТВИЕ ПОДТВЕРЖДЕНИЯ (NACK):

[0082] Чтобы приостановить свои передачи, передающее оконечное устройство может/должно получить запросы PAUSE от всех соответствующих приемных оконечных устройств, участвующих в сеансе связи.

[0083] Если N (количество) оконечных устройств-участников присутствует в сеансе связи, когда одно из оконечных устройств-участников (действующее как передающее оконечное устройство) получает запрос PAUSE от другого оконечного устройства (действующего как приемное оконечное устройство), оконечное устройство-участник (действующее как передающее оконечное устройство), которое принимает запрос PAUSE, может/должно проверить, получило ли оно запросы PAUSE от всех из N-1 других оконечных устройств-участников (действующих как приемные оконечные устройства) сеанса связи, прежде чем приостановить свой поток данных. Если количество оконечных устройств-участников, которые передают запросы PAUSE, меньше N-1, оконечное устройство-участник, принимающее запрос PAUSE, может ответить NACK для индикации запрашивающему оконечному устройству того, что хотя запрос PAUSE и был получен, передача потока данных не будет приостановлена на этом этапе, поскольку в сеансе связи участвует еще по меньшей мере одно приемное оконечное устройство, которое желает принять поток данных. Запрашивающее оконечное устройство не нуждается в том, чтобы отправлять дополнительные сообщения PAUSE, до тех пор пока передающее оконечное устройство не перейдет в состояние паузы, но этот документ не запрещает приемной оконечной точке отправлять запросы PAUSE и RESUME, если это может помочь передающей оконечной точке обновить статус этой приемной оконечной точке относительно своей передачи. Однако в этом случае приостанавливающее приемное оконечное устройство может отправлять запрос RESUME к передающему оконечному устройству, от которого прежде получило NACK, что может означать, что оно более не заинтересовано в приостановке потока. Затем передающее оконечное устройство отвечает RACK тому приемнику, как рассматривается ниже в разделе, следующем под заголовком «Подтверждение возобновления».

[0084] NACK может отправляться только в ответ на запрос PAUSE. NACK может/должно иметь такой же порядковый номер, что и запрос PAUSE, на который оно отвечает.

[0085] ПОДТВЕРЖДЕНИЕ ПАУЗЫ (PACK):

[0086] Когда передающее устройство RTP получает запрос PAUSE от всех соответствующих приемных оконечных устройств, участвующих в сеансе связи, оно отправляет подтверждение паузы (PACK) приемным оконечным устройствам, которые отправили запросы PAUSE, и входит в состояние паузы, как рассматривается выше в разделе «Состояния участников». Если в сеансе связи N оконечных устройств-участников присутствует и как передающее оконечное устройство получает запрос(-ы) PAUSE от участника N-1, передающее оконечное устройство приостанавливает свою передачу и отправляет PACK всем оконечным устройствам-участникам, которые отправили запросы PAUSE. PACK может отправляться в ответ на запрос PAUSE. PACK может/должно содержать такой же порядковый номер, что и запрос(-ы) PAUSE, на которые оно отвечает. Например, когда запросы PAUSE были отправлены к передающему оконечному устройству от всех соответствующих приемных оконечных устройств, участвующих в сеансе связи, передающее оконечное устройство может отправлять PACK каждому из передающих оконечных устройств, и каждое из этих PACK может включать в себя соответствующий порядковый номер, который является таким же, как и порядковый номер запроса PAUSE, принятого от соответствующего приемного оконечного устройства.

[0087] ПОДТВЕРЖДЕНИЕ ВОЗОБНОВЛЕНИЯ (RACK):

[0088] Когда передающее устройство RTP находится в состоянии паузы (рассматривается выше в разделе «Состояние паузы») и получает запрос RESUME от любого из соответствующих приемных оконечных устройств, участвующих в сеансе, оно переходит в состояние возобновления (рассматривается выше в разделе «Состояние возобновления») и отвечает подтверждением возобновления (RACK), таким образом, возобновляя передачу своего потока данных к приемному оконечному устройству, которое передало запрос RESUME.

[0089] RACK может отправляться в ответ на запрос RESUME. RACK может/должно включать в себя порядковый номер, совпадающий с порядковым номером запроса RESUME, на который отвечает.

[0090] REFUSE (ОТКАЗ):

[0091] Если какой-либо запрос PAUSE и/или RESUME по какой-либо причине не может быть выполнен передающим оконечным устройством, передающее оконечное устройство может отвечать подтверждением REFUSE. Ответ REFUSE может отправляться в ответ на запросы PAUSE и/или RESUME. REFUSE может/должен содержать такой же порядковый номер, что и запрос PAUSE/RESUME, на который он отвечает.

[0092] СЛУЧАИ ИСПОЛЬЗОВАНИЯ:

[0093] Далее следуют примеры случаев, когда передающему оконечному устройству в сеансе связи может потребоваться использование сообщений PAUSE и/или RESUME:

1. Сеанс «от точки к точке»;

2. «От точки к множеству точек» с использованием блока смешивания;

3. «От точки к множеству точек» с использованием транслятора; и

4. «От точки к множеству точек» с использованием многосторонней передачи.

[0094] СЕАНС «ОТ ТОЧКИ К ТОЧКЕ»:

[0095] Сеанс связи «от точки к точке» включает в себя два (первое и второе) оконечных устройства-участника, каждое из которых действует как передающее и приемное оконечное устройство. Каждое оконечное устройство-участник действует как передающее оконечное устройство в отношении потока данных, который оно генерирует и/или передает, и как приемное оконечное устройство в отношении потока данных, который оно принимает и представляет/воспроизводит от другого оконечного устройства.

[0096] Любое оконечное устройство-участник, действующее как приемное оконечное устройство может передавать сообщения PAUSE и RESUME, чтобы приостановить/возобновить передачи потока данных от другого оконечного устройства (действующего как передающее оконечное устройство). В ответ на отправку соответствующим приемным оконечным устройством RTP сообщений PAUSE и/или RESUME соответствующее передающее оконечное устройство может приостановить и/или возобновить передачу потока данных соответственно.

[0097] Фиг. 1 иллюстрирует операции паузы и возобновления в варианте осуществления «от точки к точке». В момент t1 времени передающее оконечное устройство 111a RTP может отправлять поток данных (например, поток данных медиаконтента из сеанса связи видеоконференции) посредством сети 151 к приемному оконечному устройству 111b RTP (операция 101а). В момент t2 времени приемное оконечное устройство 111b RTP может отправлять сообщение запроса паузы (операция 103), чтобы запросить передающее оконечное устройство 111а о приостановке передачи потока данных. В момент t3 времени передающее оконечное устройство 111а приостанавливает (операция 105) поток данных и отвечает (операция 105) подтверждением паузы (PACK). Несколько позже, в момент t4 времени, приемное оконечное устройство 111b отправляет запрос RESUME (операция 107), чтобы запросить передающее оконечное устройство 111а о возобновлении передачи приостановленного потока данных. В ответ передающее оконечное устройство 111а может ответить сообщением подтверждения возобновления (RACK) в момент t5 времени (операция 109) и возобновить свою передачу потока данных RTP в момент t6 времени (операция 101b).

[0098] На фиг. 1 один и тот же порядковый номер может отражать и передачу от одного устройства, и прием на другом устройстве. Операции 101а и 101b, например, могут отражать передачу потока данных RTP от передающего оконечного устройства 111а и прием потока данных RTP на приемном оконечном устройстве 111b. Операция 103 может отражать передачу сообщения запроса паузы от приемного оконечного устройства 111b и прием сообщения запроса паузы на передающем оконечном устройстве 111а. Операция 105 может отражать передачу сообщения подтверждения паузы (PACK) от передающего оконечного устройства 111а и прием сообщения PACK на приемном оконечном устройстве 111b. Операция 107 может отражать передачу сообщения запроса RESUME от приемного оконечного устройства 111b и прием запроса RESUME на передающем оконечном устройстве 111а. Операция 109 может отражать передачу сообщения RACK от передающего оконечного устройства 111а и прием сообщения RACK на приемном оконечном устройстве 111b. Другими словами, пронумерованные операции по фиг. 1 могут отражать и передачу от одного устройства, и прием на другом устройстве.

[0099] Фиг. 2 показывает, что может произойти, если сообщение PAUSE от приемного оконечного устройства 111b RTP не достигает передающего оконечного устройства 111a RTP (то есть если сообщение PAUSE потеряно). В момент t1 времени передающее оконечное устройство 111а может отправлять (операция 201а) поток данных к приемному оконечному устройству 111b, которое принимает поток данных. После того как приемное оконечное устройство 111b RTP отправляет запрос PAUSE в момент t2 времени (операция 203а), оно может ожидать значения времени ожидания (это значение времени ожидания может быть соответствующим правилам синхронизации по времени RTCP по RFC 3550, процитировано выше), чтобы выявить, приостановило ли передающее оконечное устройство 111а передачу потока данных и/или ответило подтверждением в соответствии с правилами, рассмотренными выше (например, NACK, PACK, RACK и/или REFUSE). Если значение времени ожидания проходит/истекает без приостановки передачи данных и без приема подтверждения, сообщение PAUSE может считаться потерянным (то есть не принятым на передающем оконечном устройстве 111а), и поток данных RTP может продолжать достигать приемного оконечного устройства 111b в момент t3 времени (операция 201b). В ответ на истечение времени ожидания по таймеру без приема подтверждения и без приостановки потока данных (например, по истечении значения времени ожидания) приемное оконечное устройство 111b может осуществить повторную передачу сообщения PAUSE в момент t4 времени (операция 203b). Если второе сообщение PAUSE достигает передающего оконечного устройства 111a RTP, передающее оконечное устройство 111а приостанавливает/прекращает передачу потока данных (операция 204) и отвечает передачей (операция 205) сообщения PACK в момент t5 времени к приемному оконечному устройству 111b, где принимается сообщение PACK.

[0100] Те же самые правила могут применяться в отношении сообщения RESUME, передаваемого от приемного оконечного устройства 111b в момент t6 времени (операция 207) к передающему оконечному устройству 111а, так, что приемное оконечное устройство 111b ожидает значения времени ожидания после отправки сообщения RESUME, до тех пор пока не получит подтверждение RACK в момент t7 времени (операция 209) или пока не начнет принимать возобновленный поток данных, передаваемый от передающего оконечного устройства 111а в момент t8 времени (операция 201с). Если приемное оконечное устройство 111b не принимает поток данных (операция 201с) или подтверждение RACK (операция 209) от передающего оконечного устройства 111а в пределах времени ожидания от отправки сообщения RESUME, приемное оконечное устройство 111b может осуществить повторную передачу сообщения RESUME. Как рассматривается выше со ссылкой на фиг.1, пронумерованные операции по фиг. 2 могут отражать и передачу от одного устройства, и прием на другом устройстве.

[0101] На фиг. 3 запрос паузы отклоняется в варианте осуществления «от точки к точке». В частности, передающее оконечное устройство 111а может передавать поток данных в момент t1 времени (операция 301а), а приемное оконечное устройство 111b может передавать сообщение PAUSE к передающему оконечному устройству в момент t2 времени (операция 303), чтобы приостановить передачу потока данных от передающего оконечного устройства 111а. В ответ на отказ передающим оконечным устройством 111а сделать паузу (например, в силу условий сеанса), передающее оконечное устройство 111а может ответить сообщением REFUSE в момент t3 времени (операция 305), и передающее оконечное устройство 111а может продолжить передачу потока данных в момент t4 времени (операция 301b) без прерывания. Как рассматривается выше со ссылкой на фиг. 1 и фиг. 2, пронумерованные операции по фиг. 3 могут отражать и передачу от одного устройства, и прием на другом устройстве.

[0102] «От точки к множеству точек» посредством блока смешивания:

[0103] Блок смешивания RTP - это промежуточный узел 115 связи, соединяющий два облака транспортного уровня. Блок смешивания принимает потоки данных от разных оконечных устройств-участников 111 RTP, действующих как передающие оконечные устройства. Затем блок смешивания комбинирует потоки данных, например, используя логическую базу, определенную в разделе 7.3 RRC 3550, процитировано выше. Потоки данных затем могут пересылаться/отправляться (отдельно или в сочетании) к различным оконечным устройствам-участникам 111, действующим как приемные оконечные устройства. Блок смешивания может обеспечить свой собственный SSRC в пакетах данных RTP для пересылаемого потока (или потоков) данных вместо оригинального исходного SSRC (или оригинальных исходных SSRC) от соответствующих передающих оконечных устройств.

[0104] Блок смешивания может вести учет всех приемных оконечных устройств, которые приостанавливают и возобновляют конкретный поток данных от конкретного передающего оконечного устройства. Блок смешивания может действовать как мост между передающим и приемным оконечными устройствами. Блок смешивания может не останавливать любой источник (то есть, передающее оконечное устройство) до тех пор, пока приемное оконечное устройство не готово, чтобы принимать поток данных от этого источника (то есть когда запросы паузы были приняты от всех оконечных устройств-участников сеанса, отличных от источника потока данных). С другой стороны, блок смешивания может запросить, чтобы ПРИОСТАНОВЛЕННОЕ передающее оконечное устройство возобновило передачу своего потока данных, как только любое из приемных оконечных устройств передаст запрос RESUME, чтобы запросить прием этого потока данных.

[0105] Фиг. 4 показывает прием данных RTP в отношении паузы и возобновления, когда узел 115 связи реализуется как блок смешивания между передающим и приемным оконечными устройствами 111а и 111b. SSRC передающего оконечного устройства 111а, узла 115 связи (блока смешивания) и приемного оконечного устройства 111b - это S, M и R соответственно. Передающее оконечное устройство 111a RTP отправляет поток данных посредством узла 115 связи (блока смешивания) к приемному оконечному устройству 111b в моменты t1 и t2 времени (операции 421а и 401а). В частности, передающее оконечное устройство 111а передает поток данных, узел 115 связи принимает поток данных в момент t1 времени (операция 421а), используя SSRC S передающего оконечного устройства 111а в пакетах потока данных. Затем узел 115 связи передает/пересылает поток данных и приемное оконечное устройство принимает поток данных в момент t2 времени (операция 401а), используя SSRC М узла 115 связи в пакетах потока данных. Передающее оконечное устройство 111а отправляет поток данных со своим SSRC (S), назначенным для пакетов потока данных, а узел 115 связи (блок смешивания) пересылает поток данных RTP путем назначения своего SSRC (М) для пакетов потока данных.

[0106] В момент t3 времени приемное оконечное устройство 111b передает запрос PAUSE (чтобы приостановить передачу потока данных от передающего оконечного устройства 111а), при этом запрос PAUSE включает в себя SSRC (М) узла 115 связи (блока смешивания) (операция 403), и запрос PAUSE может быть принят узлом 115 связи (блоком смешивания). В ответ на прием запроса PAUSE узлом 115 связи (блоком смешивания) в момент t4 времени узел 115 связи (например, блок смешивания) может приостановить передачу потока данных к приемному оконечному устройству 111b (операция 404), а также может передать сообщение РАСК с SSRC (М) узла 115 связи (например, блока смешивания) к приемному оконечному устройству 111b (операция 405), где принимается сообщение РАСК. В момент t5 времени узел 115 связи (блок смешивания) может переслать запрос PAUSE с SSRC (S) передающего оконечного устройства 111а к передающему оконечному устройству 111а (операция 423), где принимается запрос PAUSE. Поскольку нет другого приемного оконечного устройства, соответствующего передающему оконечному устройству 111а в сеансе, по приеме запроса PAUSE на передающем оконечном устройстве 111а (операция 423) передающее оконечное устройство 111а может немедленно приостановить поток данных RTP (операция 424) и ответить передачей РАСК, включающим в себя SSRC (S) передающего оконечного устройства 111а, к узлу 115 связи (блоку смешивания) в момент t6 времени (операция 425). В момент t7 времени приемное оконечное устройство 111b может передавать запрос RESUME (операция 407), включающий в себя SSRC (М) узла 115 связи (блока смешивания), к узлу 115 связи (блоку смешивания) для передающего оконечного устройства 111а, чтобы возобновить поток данных. В момент t8 времени узел 115 связи (блок смешивания) может пересылать запрос RESUME, включающий в себя SSRC (S) передающего оконечного устройства 111а, к передающему оконечному устройству 111а (операция 427). В момент t9 времени передающее оконечное устройство 111а может отвечать сообщением RACK, включающим в себя SSRC (S), к узлу 115 связи (блоку смешивания), так, что сообщение RACK передается от передающего оконечного устройства 111а к узлу 115 связи (блоку смешивания). В момент t10 времени передающее оконечное устройство 111а может возобновить передачу (421b) потока данных (421b) к узлу 115 связи (узлу) с пакетами потока данных, включающими в себя SSRC (S) передающего оконечного устройства 111а. В ответ на получение сообщения RACK (включающего в себя SSRC (S)) в момент t11 времени узел 115 связи (блок смешивания) может ответить (операция 409) приемному оконечному устройству 111b путем передачи сообщения RACK, включающего в себя SSRC (М), которое принимается на приемном оконечном устройстве 111b. В момент t11 времени узел 115 связи (блок смешивания) начинает пересылку (операция 401b) потока данных от передающего оконечного устройства 111а с пакетами данных, включающими в себя SSRC (М). Как рассматривается выше со ссылкой на фиг. 1, фиг. 2 и фиг. 3, пронумерованные операции по фиг. 4 могут отражать и передачу от одного устройства, и прием на другом устройстве.

[0107] Фиг. 5 иллюстрирует узел 115 связи, реализованный как блок смешивания, осуществляющий операции паузы и возобновления между передающим оконечным устройством 111а и двумя приемными оконечными устройствами 111b и 111с, где S - SSRC передающего оконечного устройства 111а, М - SSRC узла 115 связи (блока смешивания), R1 - SSRC первого приемного оконечного устройства 111b, а R2 - SSRC второго приемного оконечного устройства 111с. В момент t1 времени передающее оконечное устройство 111а передает (операция 521а) поток данных RTP к узлу 115 связи (блоку смешивания) для повторной передачи к приемным оконечным устройствам 111b и 111с, с пакетами потока данных, включающими в себя SSRC (S) передающего оконечного устройства 111а. Узел 115 связи (блок смешивания) пересылает поток данных к приемным оконечным устройствам 111b и 111с (операции 501а и 511а) в момент t2 времени с пакетами данных, включающими в себя SSRC (М) от узла 115 связи (блока смешивания). Приемное оконечное устройство 111b передает (операция 503) и запрос PAUSE с SSRC (М) от узла 115 связи (блока смешивания) к узлу 115 связи (блоку смешивания) в момент t3 времени, чтобы приостановить поток данных от передающего оконечного устройства 111а. Узел 115 связи (блок смешивания) отвечает (операция 505) РАСК в момент t4 времени и прекращает пересылку (операция 504) потока данных от передающего оконечного устройства 111а к приемному оконечному устройству 111b, но узел 115 связи (блок смешивания) продолжает пересылку (операция 511b) пересылку потока данных от передающего оконечного устройства 111а к приемному оконечному устройству 111с в момент t5 времени.

[0108] Через некоторое время (в момент t6 времени) приемное оконечное устройство 111с отправляет (операция 513) запрос PAUSE, включающий в себя с SSRC (М) от узла 115 связи (блока смешивания), к узлу 115 связи (блоку смешивания). В момент t7 времени узел 115 связи (блок смешивания) отвечает (операция 515) сообщением РАСК и прекращает пересылку (операция 514) потока данных от передающего оконечного устройства 111а к приемному оконечному устройству 111с. Теперь узел 115 связи (блок смешивания) может установить, что ни одно приемное оконечное устройство не принимает поток данных от передающего оконечного устройства 111а, и узел 115 связи (блок смешивания) может передать сообщение PAUSE (операция 523), включающее в себя SSRC (S) передающего оконечного устройства 111а, к передающему оконечному устройству 111а в момент t8 времени, чтобы приостановить действующий источник данных. Передающее оконечное устройство 111а может ответить сообщением РАСК (операция 525) в момент t9 времени, включающим в себя SSRC (S) передающего оконечного устройства 111а, а также передающее оконечное устройство 111а может приостановить передачу потока данных (операция 524) к узлу 115 связи (блоку смешивания).

[0109] В момент t10 времени приемное оконечное устройство 111b может передать запрос RESUME (операция 507), включающий в себя SSRC (М) от узла 115 связи (блока смешивания), к узлу 115 связи (блоку смешивания), чтобы возобновить прием потока данных от передающего оконечного устройства 111а, и узел 115 связи (блок смешивания) может переслать запрос RESUME (операция 527), включающий в себя SSRC (S) передающего оконечного устройства 111а, к передающему оконечному устройству 111а в момент t11 времени. В ответ передающее оконечное устройство 111а может ответить сообщением RACK (операция 529), включающим в себя SSRC (S) передающего оконечного устройства 111а, к узлу 115 связи (блоку смешивания) в момент t12 времени, и узел 115 связи (блок смешивания) может переслать сообщение RACK (операция 509), включающий в себя SSRC (М) от узла 115 связи (блока смешивания), к приемному оконечному устройству 111b в момент t13 времени. Передающее оконечное устройство 111а может возобновить передачу потока данных (операция 521b) в момент t14 времени с пакетами потока данных, включающими в себя SSRC (S) передающего оконечного устройства 111а, к передающему оконечному устройству 111а, и узел 115 связи (блок смешивания) может переслать поток данных (операция 501b) от передающего оконечного устройства 111а к приемному оконечному устройству 111b в момент t15 времени с пакетами потока данных, включающими в себя SSRC (М) от узла 115 связи (блока смешивания). Подобные операции могут быть осуществлены в моменты t16, t17 и t18 времени (операции 517, 519 и 511с), чтобы возобновить потоковую передачу к приемному оконечному устройству 111с. Поскольку передающее оконечное устройство 111а уже передает поток данных к узлу 115 связи (блоку смешивания), начиная со времени t15, передача потока данных от узла 115 связи (блока смешивания) к приемному оконечному устройству 111с может быть возобновлена, при этом не требуются дополнительные запросы RESUME и/или ответы RACK между передающим оконечным устройством 111а и узлом 115 связи (блоком смешивания). Как рассматривается выше со ссылкой на фиг. 1, фиг. 2, фиг. 3 и фиг. 4, пронумерованные операции по фиг. 5 могут отражать и передачу от одного устройства, и прием на другом устройстве.

[0110] Когда сеанс RTP имеет одно или более приостановленных передающих оконечных устройств и новый участник присоединяется к конференции, при этом данный новый участник не знает о приостановленном передающем оконечном устройстве (приостановленных передающих оконечных устройствах), отправка запроса RESUME к приостановленному передающему оконечному устройству (приостановленным передающим оконечным устройствам) может быть ответственностью узла 115 связи (блока смешивания), так что поток(-и) RTP может (могут) достигать недавно присоединившееся приемное оконечное устройство. Затем уже от нового в сеансе приемного оконечного устройства зависит - приостановить (PAUSE) или продолжить принимать тот поток.

[0111] «От точки к множеству точек» с использованием транслятора:

[0112] В некоторых вариантах осуществления узел 115 связи может быть реализован как транслятор в сеансе связи RTP, чтобы пересылать сообщения от одного пирингового оконечного устройства к другому. Однако в отличие от сеансов с использованием блока смешивания транслятор не смешивает потоки и не изменяет SSRC сообщений/пакетов.

[0113] Фиг. 6 иллюстрирует использование транслятора в качестве узла 115 связи, чтобы помочь приемному оконечному устройству 111b приостановить и возобновить поток данных от передающего оконечного устройства 111а. Передающее оконечное устройство 111а может передавать может отправлять поток данных RTP (операция 621а) к узлу 115 связи (транслятору) в момент t1 времени, и узел 115 связи (транслятор) только пересылает поток данных (операция 601а), не изменяя SSRC пакетов потока данных, в момент t2 времени. Другими словами, пакеты данных потока данных передаются с SSRC (S) передающего оконечного устройства 111а как от передающего оконечного устройства 111а, так и от узла 115 связи (транслятора) в моменты t1 и t2 времени. Приемное оконечное устройство 111b может отправлять запрос PAUSE (операция 603) к узлу 115 связи (транслятору) в момент t3 времени, и узел 115 связи (транслятор) пересылает запрос PAUSE (операция 623) к передающему оконечному устройству 111а в момент t4 времени. Запрос PAUSE передается и от приемного оконечного устройства 111b, и от узла 115 связи (транслятора) с SSRC (S) передающего оконечного устройства 111а. Передающее оконечное устройство 111а может подтвердить, что нет другого приемного оконечного устройства (других приемных оконечных устройств), которое хочет (которые хотят) принимать поток данных, прежде чем приостановить поток данных (операция 624), и в ответ на подтверждение того, что никакие другие приемные оконечные устройства не принимают поток данных, передающее оконечное устройство 111а может передать сообщение РАСК (операция 625) к узлу 115 связи (транслятору) в момент t5 времени. В ответ на прием сообщения РАСК узел 115 связи (транслятор) может пересылать (операция 605) сообщение РАСК (включающее в себя SSRC (S) передающего оконечного устройства 111а) к приемному оконечному устройству 111b в момент t6 времени. Как показано на фиг. 6, сообщение РАСК передается с SSRC (S) передающего оконечного устройства как от передающего оконечного устройства 111а, так и от узла 115 связи (транслятора).

[0114] Приемное оконечное устройство 111b может инициировать возобновление потока данных от передающего оконечного устройства 111а путем отправки запроса RESUME (операция 607) к узлу 115 связи (транслятору) в момент t7 времени, и узел 115 связи (транслятор) может пересылать запрос RESUME (операция 627) к передающему оконечному устройству 111а в момент t8 времени. Запрос RESUME может включать в себя SSRC (S) передающего оконечного устройства 111а, когда передается обоими - и приемным оконечным устройством 111b, и узлом 115 связи (транслятором). В ответ передающее оконечное устройство 111а может передавать сообщение RACK (операция 629) к узлу 115 связи (транслятору) в момент t9 времени, и узел 115 связи (транслятор) может пересылать запрос RACK (операция 609) к приемному оконечному устройству 111b в момент t10 времени. Сообщение RACK может включать в себя SSRC (S) передающего оконечного устройства 111а, когда передается обоими - и передающим оконечным устройством 111а, и узлом 115 связи (транслятором). Кроме того, передающее оконечное устройство 111а может возобновить передачу потока данных RTP (операция 621b) к узлу 115 связи (транслятору) в момент t11 времени, и узел 115 связи (транслятор) может пересылать поток данных (операция 601b) к приемному оконечному устройству 111b в момент t12 времени. Пакеты потока данных могут включать в себя SSRC (S) передающего оконечного устройства 111а, когда передаются обоими - и передающим оконечным устройством 111а, и узлом 115 связи (транслятором).

[0115] Как рассматривается выше со ссылкой на фиг. 1, фиг. 2, фиг. 3, фиг. 4 и фиг. 5, пронумерованные операции по фиг. 6 могут отражать и передачу от одного устройства, и прием на другом устройстве.

[0116] Фиг. 7 иллюстрирует операции паузы и возобновления, когда узел 115 связи реализуется как транслятор между передающим оконечным устройством 111а и двумя приемными оконечными устройствами 111b и 111с во время сеанса связи RTP. Каждый обмен сообщениями отражается по времени (например, t1-t6), когда это происходит. В момент t1 времени передающее оконечное устройство 111а инициирует потоковую передачу данных (операция 721а) к обоим приемным оконечным устройствам R1 и R2 путем передачи пакетов потока данных к узлу 115 связи (транслятору). В момент t2 времени узел 115 связи (транслятор) пересылает пакеты потока данных (операции 701а и 711а) к приемным оконечным устройствам 111b и 111с. Кроме того, и передающее оконечное устройство 111а, и узел 115 связи (транслятор) - оба передают пакеты потока данных, включающие в себя SSRC (S) передающего оконечного устройства 111а.

[0117] Приемные оконечные устройства 111b и 111с принимают поток данных RTP (операции 701а и 711а) от узла 115 связи (транслятора) в момент t2 времени, с пакетами данных потока данных, включающими в себя SSRC (S) передающего оконечного устройства 111а. Через некоторое время, в момент t3 времени, приемное оконечное устройство R1 может инициировать приостановку потока данных путем передачи запроса PAUSE (операция 703), включающим в себя SSRC (S) передающего оконечного устройства 111а, в момент t4 времени. В ответ на прием запроса PAUSE от приемного оконечного устройства 111b (операция 723а) посредством узла 115 связи (транслятора) в моменты t3 и t4 времени передающее оконечное устройство 111а проверяет, есть ли какое либо другое приемное оконечное устройство (другие приемные оконечные устройства), которое все еще хочет (которые все еще хотят) принимать поток данных. В это время передающее оконечное устройство 111а может понять, что приемное оконечное устройство 111с все еще заинтересовано в приеме потока данных, и в ответ на определение того, что другое приемное оконечное устройство (другие приемные оконечные устройства) принимает (принимают) поток данных, передающее оконечное устройство 111а может ответить сообщением NACK (операция 722), которое передается к узлу 115 связи (транслятору) в момент t5 времени, и узел 115 связи (транслятор) может пересылать сообщение NACK (операция 706) к приемному оконечному устройству 111b в момент t6 времени. Кроме того, сообщение NACK передается с SSRC (S) между передающим оконечным устройством 111а и узлом 115 связи (транслятором), а также между и узлом 115 связи (транслятором) и приемным оконечным устройством 111b. Соответственно, передающее оконечное устройство 111а может продолжать передачу потока данных в интересах приемного оконечного устройства 111с.

[0118] В момент t7 времени приемное оконечное устройство 111с может инициировать приостановку потока данных путем отправки запроса PAUSE (операция 713) к узлу 115 связи (транслятору), и узел 115 связи (транслятор) может пересылать запрос PAUSE (операция 723b) к передающему оконечному устройству 111а в момент t8 времени. Этот запрос PAUSE включает в себя SSRC (S), когда передается от приемного оконечного устройства к узлу 115 связи (транслятору) и когда передается от узла 115 связи (транслятора) к передающему оконечному устройству 111а. Передающее оконечное устройство 111а теперь может понять, что оба/все приемные оконечные устройства 111b и 111с, участвующие в сеансе, запросили, чтобы поток данных был приостановлен, и в ответ на это понимание, передающее оконечное устройство 111а может приостановить передачу потока данных (операция 704/714/724). Передающее оконечное устройство 111а может, таким образом, прекратить передачу потока данных и ответить путем передачи сообщения PACK (операция 725) к узлу 115 связи (транслятору) в момент t9 времени. Узел 115 связи (транслятор) затем может переслать сообщение PACK (операции 705 и 715) к обоим приемным оконечным устройствам 111b и 111с в момент t10 времени. Сообщение PACK может включать в себя SSRC (S), когда передается от передающего оконечного устройства 111а к узлу 115 связи (транслятору) и когда передается от узла 115 связи (транслятора) к каждому из приемных оконечных устройств 111b и 111с.

[0119] Когда любое из приемных оконечных устройств 111b и/или 111с предпочитает возобновить поток данных от передающего оконечного устройства, оно может отправить запрос RESUME посредством узла 115 связи (транслятора) к передающему оконечному устройству 111а (в моменты t11 и t12 времени). В ответ на такой запрос RESUME передающее оконечное устройство 111а может передать сообщение RACK посредством узла 115 связи (транслятора) к запрашивающему приемному оконечному устройству (запрашивающим приемным оконечным устройствам) 111а и/или 111b в моменты t13 и t14 времени и может возобновить потоковую передачу данных посредством узла 115 связи (транслятора) к приемным оконечным устройствам 111b и 111с в моменты t15 и t16 времени. В частности, приемное оконечное устройство 111b может передавать сообщение RESUME (операция 707) к узлу 115 связи (транслятору) в момент t11 времени, и узел 115 связи (транслятор) может переслать сообщение RESUME (операция 727) к передающему оконечному устройству 111а в момент t12 времени. В ответ на сообщение RESUME передающее оконечное устройство 111а может передать сообщение RACK (операция 729) к узлу 115 связи (транслятору) в момент t13 времени, и узел 115 связи (транслятор) может переслать сообщение RACK (операция 709) к приемному оконечному устройству 111b в момент t14 времени. В ответ на сообщение RESUME от одного из приемных оконечных устройств, участвующих в сеансе, передающее оконечное устройство 111а может также возобновить передачу потока данных (операция 721b) к узлу 115 связи (транслятору), и узел 115 связи (транслятор) может переслать поток данных (операции 701b и 711b) ко всем приемным оконечным устройствам 111b и 111с, участвующим в сеансе, в момент t16 времени.

[0120] Как рассматривается выше со ссылкой на фиг. 1, фиг. 2, фиг. 3, фиг. 4, фиг. 5 и фиг. 6, пронумерованные операции по фиг. 7 могут отражать и передачу от одного устройства, и прием на другом устройстве.

[0121] Предположим сеанс RTP, который включает в себя одно или несколько приемных оконечных устройств (например, 111b и 111с), с приостановленным передающим оконечным устройством (приостановленными передающими оконечными устройствами) 111а и узлом 115 связи (транслятором). Если новый участник (то есть новое приемное оконечное устройство) присоединяется к сеансу, то этот новый участник может не знать о приостановленном передающем оконечном устройстве 111а. Получив соответствующие знания о таком недавно присоединившемся к сеансу участнике (например, приняв любой трафик RTP и/или любой отчет RTCP, как то отчет SR или RR) от недавно присоединившегося участника, приостановленное передающее оконечное устройство 111а может возобновить передачу потока данных, поскольку теперь в сеансе есть приемное оконечное устройство, которое не приостанавливало поток данных, сгенерированный передающим оконечным устройством 111а. Передающее оконечное устройство 111а может последовательно приостанавливать передачу потока данных, если новое приемное оконечное устройство передает запрос PAUSE, когда все остальные приемные оконечные устройства находятся на паузе.

[0122] «От точки к множеству точек» с использованием многосторонней передачи:

[0123] Приемное оконечное устройство RTP может приостанавливать множественные передающие оконечные устройства, используя групповую передачу. Варианты осуществления этого раскрытия могут использовать элементы, структуры и/или операции RTP (см. RFC 3550, процитировано выше), AVPF (аудиовизуальный профиль с обратной связью) (см. RFC 4585, процитировано выше) и/или CCM (сообщения управления кодеком) (см. RFC 5104, процитировано выше) для многосторонней передачи. Поведение передающих и приемных оконечных устройств в отношении отправки и приема сообщений PAUSE и RESUME может оставаться таким же, как описывается в разделах «От точки к множеству точек с использованием блока смешивания» и «От точки к точке с использованием транслятора»

[0124] ОПРЕДЕЛЕНИЯ SDP:

[0125] Возможность работы с сообщениями PAUSE и RESUME может подвергаться обмену на высоком уровне, таком как SDP (протокол описания сеансов). Варианты осуществления этого раскрытия могут расширить атрибуты rtcp-fb (обратной связи транспортного протокола управления в реальном времени), описанные в разделе 4 AVPF (см. RFC 4585, процитировано выше), так, чтобы они включали в себя запросы PAUSE и RESUME. Подобно AVPF (см. RFC 4585, процитировано выше), варианты осуществления этого раскрытия могут использовать атрибуты rtcp-fb на уровне медиа и не могут/должны использоваться на уровне сеанса. Варианты осуществления этого раскрытия могут следовать правилам, определенным в AVPF (см. RFC 4585, процитировано выше) для атрибутов rtcp-fb в отношении типа полезной нагрузки в описании сеанса.

[0126] Раздел 7.1 ССМ (см. RFC 5104, процитировано выше) определяет новое значение «ccm» обратной связи, которое отражает поддержку управления кодеком с использованием обратной связи RTCP. ССМ (см. RFC 5104, процитировано выше) определяет четыре различных параметра, которые могут/должны использоваться со значением «ccm» обратной связи для индикации конкретной команды управления кодеком. Варианты осуществления этого раскрытия могут определить новый тип параметра, то есть «пауза», что может совокупно отражать сообщения PAUSE и RESUME и их подтверждения (то есть PACK, NACK, RACK и REFUSE). Например, чтобы продемонстрировать поддержку для приостановки и возобновления потока, приемник RTP может описать свою возможность работать с сообщениями PAUSE и RESUME.

[0127] Следующие форматы SDP (отражающие возможности приостановки и возобновления) могут использоваться в соответствии с вариантами осуществления настоящего изобретения.

v=0

o=alice 3203093520 3203093520 IN IP4 host.example.com

s=Pausing Media

t=0 0

c=IN IP4 host.example.com

m=audio 49170 RTP/AVPF 98

a=rtpmap:98 H263-1998/90000

a=rtcp-fb:98 ccm pause

[0128] ФОРМАТ СООБЩЕНИЙ:

[0129] Раздел 6 RFC 4585 (AVPF) (цитируется выше) определяет три типа сообщений обратной связи RTCP с небольшой задержкой (то есть это сообщения обратной связи транспортного уровня, сообщения обратной связи для полезной нагрузки и сообщения обратной связи прикладного уровня). Варианты осуществления настоящего раскрытия определяют два сообщения обратной связи транспортного уровня (то есть сообщения PAUSE и RESUME) для приостановки и возобновления потока данных RTP соответственно и четыре других типа подтверждений для использования в ответ или на запросы PAUSE, или на запросы RESUME.

[0130] Сообщения обратной связи транспортного уровня могут идентифицироваться посредством FB (обратной связи) RTP (транспортный протокол для работы в реальном времени) в RFC 4585, процитировано выше. Новые сообщения PAUSE и RESUME могут быть идентифицированы с использованием значения типа сообщений обратной связи (FMT) в общем заголовке пакета для сообщения обратной связи, определенного в разделе 6.1 RFC 4585, процитировано выше. IANA может запрашиваться для распределения некоторого количества типа сообщений обратной связи (FMT) в общем заголовке сообщения обратной связи для приостановки и возобновления потоков медиаданных RTP. С верхнего уровня запросы PAUSE и RESUME и их сообщения подтверждения могут совокупно именоваться «сообщениями паузы» и могут идентифицироваться посредством типа полезной нагрузки (РТ), при PT=RTPFB в общем формате пакета для сообщений обратной связи. Поле информации управления обратной связью (FCI) может/будет состоять из одного или нескольких запросов PAUSE, запроса RESUME и/или сообщения (сообщений) подтверждения для запроса PAUSE/RESUME.

[0131] Формат сообщений обратной связи по фиг. 8 может использоваться как синтаксис для ввода информации управления обратной связью (FCI) для сообщений PAUSE и RESUME в соответствии с некоторыми вариантами осуществления настоящего изобретения.

[0132] SSRC для применения (32 бита): значение SSRC передатчика медиа, к которому может/будет применяться это сообщение обратной связи. SSRC уникально идентифицирует источник потока данных в пределах сеанса связи RTP.

[0133] Порядковый номер (16 битов): порядковый номер запросов обратной связи (например, запросы PAUSE и RESUME), который может/будет увеличиваться на единицу после каждой передачи. Оба запроса - и PAUSE, и RESUME - от одного и того же оконечного устройства-источника могут/будут SHALL использовать одно и то же пространство порядковых номеров. Другими словами, порядковые номер для каждого запроса PAUSE/RESUME от приемного оконечного устройства могут увеличиваться относительно порядкового номер предыдущего запроса PAUSE/RESUME, переданного от того же приемного оконечного устройства. В качестве примера, если приемное оконечное устройство передает первое сообщение PAUSE, второе сообщение PAUSE, первое сообщение RESUME, третье сообщение PAUSE и второе сообщение RESUME (в этом порядке, без промежуточных сообщений PAUSE или RESUME), первое сообщение PAUSE может иметь порядковый номер х, второе сообщение PAUSE может иметь порядковый номер х+1, первое сообщение RESUME может иметь порядковый номер х+2, третье сообщение PAUSE может иметь порядковый номер х+3, а второе сообщение RESUME может иметь порядковый номер х+4.

[0134] Тип (4 бита): тип обратной связи, например, или PAUSE, или RESUME. Могут быть предусмотрены следующие значения,

0: сообщение PAUSE

1: сообщение RESUME

2: подтверждение паузы (PACK)

3: подтверждение возобновления (RACK)

4: NACK: отсутствие подтверждения (NACK)

5: REFUSE

6-15: зарезервировано на будущее

[0135] Возможности IANA (Центр по присвоению номеров в Интернете)

[0136] IANA может поступить запрос на распределение некоторого количества типов сообщений обратной связи (FMT) в общем заголовке сообщения обратной связи, чтобы приостановить или возобновить медиапотоки RTP.

[0137] ВОПРОСЫ БЕЗОПАСНОСТИ:

[0138] Варианты осуществления этого раскрытия могут расширить CCM (сообщение управления кодеком) (см. RFC 5104, процитировано выше) и могут определить новые сообщения, например, запросы PAUSE и RESUME. Обмен этими новыми сообщениями может сократить/предотвратить последствия в плане безопасности, которые могут быть адресованы такому пользователю, как:

1. Спуфинг (имитация) идентичности. Атакующий может имитировать, что является аутентифицированным пользователем и может неправильно приостановить или возобновить любую исходную передачу. С целью снизить/предотвратить такой тип атак может использоваться/требоваться надежный механизм аутентификации и защиты целостности.

2. Отказ в обслуживании (DoS). Атакующий может неправильно приостанавливать весь исходный поток, что может привести к отказу в обслуживании (DoS). Протокол аутентификации сможет снизить/предотвратить такой тип атак.

3. Атака через посредника (MiMT). Приостановка и возобновление источника RTP могут подвергнуться атаке через посредника. Аутентификация с открытым ключом может использоваться, чтобы сократить/предотвратить MiMT.

[0139] Дополнительные определения и варианты осуществления:

[0140] Когда элемент называется «подсоединенным», «связанным», «зависимым» или подобным образом в отношении другого элемента, он может быть подсоединен напрямую, связан или зависим от другого элемента, или могут присутствовать один или несколько промежуточных элементов. В противоположность сказанному, когда элемент называется «напрямую подсоединенным», «напрямую связанным», «напрямую зависимым» или подобным образом в отношении другого элемента, никаких промежуточных элементов не присутствует. Идентичные номера относятся к идентичным узлам/элементам во всех аспектах данного раскрытия. Кроме того, «связанный», «подсоединенный», «зависимый» или их вариации, как это используется здесь, могут включать в себя соединение, связь или зависимость беспроводным способом. Как это используется здесь, формы единственного числа подразумевают и формы множественного числа, если контекст четко не обозначает обратное. Хорошо известные функции или конструкции могут не описываться подробно в целях краткости и/или ясности. Термин «и/или», сокращенный до «/», включает в себя любые или все комбинации из одного или более соответствующих упомянутых элементов.

[0141] Как это используется здесь, термины «содержать, «содержащий», «содержит», «включать в себя», «включающий в себя», «включает в себя», «иметь», «имеет», «имеющий» или их вариации не являются окончательными и включают в себя один или несколько указанных признаков, чисел, узлов, этапов, компонентов или функций, но не исключают наличия или дополнения из одного или нескольких других признаков, чисел, узлов, этапов, компонентов, функций или их групп. Кроме того, как это используется здесь, «например» может использоваться, чтобы представить или конкретизировать общий пример или примеры прежде упомянутого элемента, и не нацелен на ограничение этого элемента. Сокращение «т.е.» («то есть») может использоваться, чтобы описать конкретный элемент из более общего упоминания.

[0142] Примерные варианты осуществления описываются здесь со ссылкой на блок-схемы и/или блок-схемы последовательности операций реализуемых компьютером способов, аппаратуры (систем и/или устройств) и/или компьютерных программных продуктов. Следует понимать, что блок/операция блок-схем, блок-схем последовательности операций и/или иллюстраций последовательности операций и комбинации блоков/операций блок-схем, блок-схем последовательности операций и/или иллюстраций последовательности операций могут реализовываться посредством программных команд компьютера, которые выполняются одной или несколькими компьютерными схемами. Программные команды компьютера могут предоставляться процессорной схеме компьютерной схемы общего назначения, компьютерной схеме специального назначения и/или другой программируемой схеме обработки данных для создания машин, так, что команды, которые выполняются посредством процессора компьютера и/или другой программируемой аппаратуры для обработки данных, преобразуют и управляют транзисторами, значениями, хранимыми в памяти, точками расположения и другими компонентами аппаратного обеспечения в пределах подобной схемы, чтобы реализовать функции/действия, описанные на блок-схемах и/или блоке или блоках схемы последовательности операций, и таким образом, создать средство (функциональность) и/или структуру для реализации функций/действий, описанных на блок-схемах и/или блоке или блоках схемы последовательности операций.

[0143] Эти программные команды компьютера также могут храниться на материальном машиночитаемом носителе, который может направлять компьютер или другую программируемую аппаратуру для обработки данных к функционированию определенным способом, так, что команды, хранящиеся на машиночитаемом носителе, создают продукт производства, включающий в себя команды, которые реализуют функции/действия, описанные на блок-схемах и/или блоке или блоках схемы последовательности операций.

[0144] Материальный, постоянный машиночитаемый носитель может включать в себя магнитную, оптическую, электромагнитную или полупроводниковую систему хранения данных, аппаратуру или устройство. Более конкретные примеры машиночитаемого носителя включали бы в себя следующее: портативная компьютерная дискета, схема оперативного запоминающего устройства (RAM), схема постоянного запоминающего устройства (ROM), схемы стираемого программируемого запоминающего устройства (EPROM или флэш-память), портативный компакт-диск без возможности перезаписи (CD-ROM) и портативный цифровой видеодиск без возможности перезаписи (DVD/BlueRay).

[0145] Программные команды компьютера также могут быть загружены на компьютер и/или другую программируемую аппаратуру для обработки данных, чтобы инициировать выполнение на компьютере и/или другой программируемой аппаратуре для обработки данных серии операционных этапов, чтобы создать реализуемый компьютером процесс так, что команды при выполнении компьютером или другой программируемой аппаратурой для обработки данных обеспечивают этапы для реализации функций/действий/операций, описанных в блок-схемах, блок-схемах последовательности операций и/или блоке/операции или блоках/операциях блок-схемы последовательности операций. Соответственно, варианты осуществления настоящего изобретения могут быть реализованы в аппаратном обеспечении и/или программном обеспечении (включая программно-аппаратное обеспечение, резидентное программное обеспечение, микрокод и т.д.), которое работает на процессоре, таком как цифровой сигнальный процессор, который может в общем называться «схемой», «модулем» или вариациями этих терминов.

[0146] Также следует отметить, что в некоторых альтернативных вариантах осуществления функции/действия, отмеченные в блоках, могут происходить не по порядку, отмеченному в блок-схемах последовательности операций. Например, два блока, показанные в последовательности, на самом деле могут реализовываться по большей части одновременно, или блоки иногда могут реализовываться в обратном порядке, в зависимости от задействованной функциональности/действий. Кроме того, функциональность заданного блока/операции блок-схем последовательности операций, диаграмм последовательности операций и/или блок-схем может быть разделена на множественные блоки/операции, и/или функциональность двух или более блоков/операций блок-схем последовательности операций, диаграмм последовательности операций и/или блок-схем может быть по меньшей мере частично объединена. В итоге другие блоки/операции могут быть добавлены/включены между блоками/операциями, которые проиллюстрированы. Кроме того, хотя некоторые из схем включают в себя стрелки на каналах связи, чтобы показать основное направление связи, следует понимать, что связь может осуществляться и в обратном изображенным стрелкам направлении.

[0147] Множество разных вариантов осуществления было раскрыто здесь, в сочетании с представленным выше описанием чертежей. Следует понимать, что описание было бы слишком многословным и запутанным, если буквально описывать и иллюстрировать каждую комбинацию и подкомбинацию этих вариантов осуществления. Соответственно, настоящее описание, включая чертежи, будет истолковано как полное письменное описание различных примерных комбинаций и подкомбинаций вариантов осуществления и способа и процесса их создания и использования и будет поддерживать пункты формулы изобретения для каждой такой комбинации и подкомбинации.

[0148] Другие сетевые элементы, устройства связи и/или способы в соответствии с вариантами осуществления изобретения будут или становятся очевидны специалистам в данной области техники после обзора настоящих чертежей и описания. Целью представленного здесь является, чтобы все подобные дополнительные сетевые элементы, устройства связи и/или способы были включены в пределы этого описания, были в пределах объема настоящего изобретения и были защищены прилагаемой формулой изобретения. Кроме того, целью представленного здесь является, чтобы все варианты осуществления, раскрытые здесь, могли быть реализованы по отдельности или скомбинированы любым способом и/или в любой комбинации.

1. Способ управления приемным устройством (111b, 111с, 115) связи во время многостороннего сеанса конференц-связи в реальном времени с другим устройством (111а, 115) связи, содержащий этапы, на которых:
принимают (101а, 201а, 401а, 421а, 501а, 511а, 521а, 601а, 621а, 701а, 711а, 721а) поток данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени от другого устройства (111а, 115) связи, при этом пакеты потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени включают в себя идентификацию потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени; и
передают (103, 203b, 403, 423, 503, 523, 603, 623, 703, 713, 723a, 723b) запрос паузы от приемного устройства (111b, 111с, 115) связи к другому устройству (111а, 115) связи, при этом запрос паузы включает в себя идентификацию потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени и порядковый номер запроса паузы.

2. Способ по п. 1, дополнительно содержащий этап, на котором:
после передачи запроса паузы принимают (105, 205, 405, 425, 505, 515, 525, 605, 625, 705, 715, 725) сообщение подтверждения паузы от другого устройства (111а, 115) связи, при этом сообщение подтверждения паузы включает в себя идентификацию потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени и порядковый номер запроса паузы.

3. Способ по п. 2, дополнительно содержащий этапы, на которых:
после приема сообщения подтверждения паузы передают (107, 207, 407, 427, 507, 517, 527, 607, 627, 707, 727) запрос возобновления от приемного устройства (111b, 111с, 115) связи к другому устройству (111а, 115) связи, при этом запрос возобновления включает в себя идентификацию потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени и порядковый номер запроса возобновления, отличный от порядкового номера запроса паузы; и
после передачи запроса возобновления принимают (109, 209, 409, 429, 509, 519, 529, 609, 629, 709, 729) сообщение подтверждения возобновления от другого устройства (111а, 115) связи, при этом сообщение подтверждения возобновления включает в себя идентификацию потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени и порядковый номер запроса возобновления.

4. Способ по п. 3, в котором порядковый номер запроса возобновления увеличивают относительно порядкового номера запроса паузы.

5. Способ по п. 1, в котором передача запроса паузы содержит этап, на котором передают (203а) первый запрос паузы, при этом порядковый номер запроса паузы содержит порядковый номер первого запроса паузы, а способ дополнительно содержит этапы, на которых:
в ответ на истечение времени ожидания после передачи запроса паузы от приемного устройства (111b, 111с, 115) связи передают (203b) второй запрос паузы от приемного устройства (111b, 111с, 115) связи к другому устройству (111а, 115) связи, при этом второй запрос паузы включает в себя идентификацию потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени и порядковый номер второго запроса паузы, отличный от порядкового номера первого запроса паузы; и
после передачи второго запроса паузы принимают (205) сообщение подтверждения паузы от другого устройства (111а, 115) связи, при этом сообщение подтверждения паузы включает в себя идентификацию потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени и порядковый номер второго запроса паузы.

6. Способ по п. 5, в котором порядковый номер второго запроса паузы увеличивают относительно порядкового номера запроса паузы.

7. Способ по любому из пп. 1, 2, 3, 4, 5 или 6, в котором идентификация потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени содержит источник синхронизации (SSRC), который уникально идентифицирует поток данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени в пределах многостороннего сеанса конференц-связи в реальном времени.

8. Способ по п. 1, в котором многосторонний сеанс конференц-связи в реальном времени содержит многосторонний сеанс видео-конференц-связи в реальном времени.

9. Способ управления передающим устройством (111а, 115) связи во время многостороннего сеанса конференц-связи в реальном времени с другим устройством (111b, 111с, 115) связи, содержащий этапы, на которых:
передают (101а, 201а, 401а, 421а, 501а, 511а, 521а, 601а, 621а, 701а, 711а, 721а) поток данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени от передающего устройства (111а, 115) связи к первому и второму приемным устройствам (111b, 111с) связи, при этом пакеты потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени включают в себя идентификацию потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени; и
принимают (103, 203b, 403, 423, 503, 523, 603, 623, 703, 713, 723a, 723b) запрос паузы от другого устройства (111b, 111с, 115) связи, при этом запрос паузы включает в себя идентификацию потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени и порядковый номер запроса паузы.

10. Способ по п. 9, дополнительно содержащий этапы, на которых:
в ответ на прием запроса паузы приостанавливают (104, 204, 404, 424, 504, 514, 524, 604, 624, 704, 714, 724) передачу потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени к первому приемному устройству связи, тогда как поддерживают многосторонний сеанс конференц-связи в реальном времени; и
в ответ на прием запроса паузы передают (105, 205, 405, 425, 505, 515, 525, 605, 625, 705, 715, 725) сообщение подтверждения паузы к первому устройству (111b, 111с, 115) связи, при этом сообщение подтверждения паузы включает в себя идентификацию потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени и порядковый номер запроса паузы.

11. Способ по п. 10, дополнительно содержащий этапы, на которых:
после передачи сообщения подтверждения паузы принимают (107, 207, 407, 427, 507, 517, 527, 607, 627, 707, 727) запрос возобновления от первого приемного устройства связи, при этом запрос возобновления включает в себя идентификацию потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени и порядковый номер запроса возобновления, отличный от порядкового номера запроса паузы;
в ответ на прием запроса возобновления возобновляют (101b, 201c, 401b, 421b, 501b, 511c, 521b, 601b, 621b, 701b, 711b, 721b) передачу потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени к первому приемному устройству связи; и
в ответ на прием запроса возобновления передают (109, 209, 409, 429, 509, 519, 529) сообщение подтверждения возобновления к первому приемному устройству связи, при этом сообщение подтверждения возобновления включает в себя идентификацию потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени и порядковый номер запроса возобновления.

12. Способ по п. 11, в котором порядковый номер запроса возобновления увеличивают относительно порядкового номера запроса паузы.

13. Способ по п. 9, дополнительно содержащий этап, на котором:
в ответ на прием запроса паузы передают (305) сообщение отказа к первому приемному устройству (111b) связи, тогда как продолжают передачу потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени к первому приемному устройству связи, при этом сообщение отказа включает в себя идентификацию потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени и порядковый номер запроса паузы.

14. Способ по п. 9, дополнительно содержащий этап, на котором:
в ответ на прием запроса паузы передают (706, 724) сообщение отсутствия подтверждения (NACK) к первому приемному устройству (111b, 115) связи, тогда как продолжают передачу потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени к первому приемному устройству связи, при этом сообщение отсутствия подтверждения включает в себя идентификацию потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени и порядковый номер запроса паузы.

15. Способ по любому из пп. 9, 10, 11, 12, 13 или 14, в котором идентификация потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени содержит источник синхронизации (SSRC), который уникально идентифицирует поток данных медиаконтента реальном времени многостороннего сеанса конференц-связи в реальном времени в пределах многостороннего сеанса конференц-связи в реальном времени.

16. Способ по п. 9, дополнительно содержащий этап, на котором:
в ответ на прием запроса паузы от первого приемного устройства связи приостанавливают (504) передачу потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени к первому приемному устройству связи, тогда как продолжают передачу (511b) потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени ко второму приемному устройству (111с) связи.

17. Способ по п. 16, в котором запрос паузы является первым запросом паузы и порядковый номер запроса паузы является порядковым номером первого запроса паузы, причем способ дополнительно содержит этапы, на которых:
в ответ на прием запроса паузы от первого приемного устройства связи передают (505) первое сообщение подтверждения паузы к первому приемному устройству (111b) связи, тогда как продолжают передачу (511b) потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени ко второму приемному устройству (111с) связи, при этом сообщение подтверждения паузы включает в себя идентификацию потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени и порядковый номер запроса паузы; и
после передачи первого сообщения подтверждения паузы принимают (513) второй запрос паузы от второго приемного устройства (111с) связи, при этом второй запрос паузы включает в себя идентификацию потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени и порядковый номер второго запроса паузы; и
в ответ на прием второго запроса паузы от второго приемного устройства связи приостанавливают (514) передачу потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени к первому приемному устройству связи.

18. Способ по п. 17, в котором передача потока данных медиаконтента в реальном времени содержит этапы, на которых принимают поток данных медиаконтента в реальном времени от оконечного устройства (111а) связи и повторно передают поток данных медиаконтента в реальном времени к первому и второму приемным устройствам связи, при этом способ дополнительно содержит этап, на котором:
в ответ на прием первого и второго запросов паузы от первого и второго приемных устройств связи передают (523) третий запрос паузы к оконечному устройству (111а) связи.

19. Способ по п. 18, в котором идентификация содержит первую идентификацию потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени, при этом прием потока данных медиаконтента в реальном времени от оконечного устройства (111а) связи содержит этап, на котором принимают поток данных медиаконтента в реальном времени, включающий в себя вторую идентификацию, при этом третий запрос паузы включает в себя вторую идентификацию и порядковый номер третьего запроса паузы.

20. Способ по п. 9, в котором многосторонний сеанс конференц-связи в реальном времени содержит многосторонний сеанс видео-конференц-связи в реальном времени.

21. Приемное устройство (111b, 111с, 115) связи, содержащее:
сетевой интерфейс (133, 233), выполненный с возможностью обеспечения сетевой связи по сети (151) с другим устройством (111а, 115) связи во время многостороннего сеанса конференц-связи в реальном времени; и
процессор (131, 231), соединенный с сетевым интерфейсом (133, 233), при этом процессор (131, 231) выполнен с возможностью приема потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени от другого устройства (111а, 115) связи посредством сетевого интерфейса (133, 233), при этом пакеты потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени включают в себя идентификацию потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени, и передачи запроса паузы посредством сетевого интерфейса (133, 233) к другому устройству (111а, 115) связи, при этом запрос паузы включает в себя идентификацию потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени и порядковый номер запроса паузы.

22. Приемное устройство (111b, 111с, 115) связи по п. 21, в котором процессор (131, 231) дополнительно выполнен с возможностью приема сообщения подтверждения паузы от другого устройства связи после передачи запроса паузы, при этом сообщение подтверждения паузы включает в себя идентификацию потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени и порядковый номер запроса паузы.

23. Приемное устройство (111b, 111с, 115) по п. 22 связи, в котором процессор (131, 231) дополнительно выполнен с возможностью передачи запроса возобновления посредством сетевого интерфейса (133, 233) к другому устройству (111а, 115) связи после приема сообщения подтверждения паузы, при этом запрос возобновления включает в себя идентификацию потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени и порядковый номер запроса возобновления, отличный от порядкового номера запроса паузы, и приема сообщения подтверждения возобновления от другого устройства (111а, 115) связи посредством сетевого интерфейса (133, 233) после передачи запроса возобновления, при этом сообщение подтверждения возобновления включает в себя идентификацию потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени и порядковый номер запроса возобновления.

24. Приемное устройство связи по любому из пп. 21-23, в котором многосторонний сеанс конференц-связи в реальном времени содержит многосторонний сеанс видео-конференц-связи в реальном времени.

25. Передающее устройство (111а, 115) связи, содержащее:
сетевой интерфейс (133, 233), выполненный с возможностью обеспечения сетевой связи по сети (151) с первым и вторым приемными устройствами (111b, 111с) связи во время многостороннего сеанса конференц-связи в реальном времени; и
процессор (131, 231), соединенный с сетевым интерфейсом (133, 233), при этом процессор (131, 231) выполнен с возможностью передачи потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени посредством сетевого интерфейса (133, 233) к первому и второму приемным устройствам (111b, 111с) связи, при этом пакеты потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени включают в себя идентификацию потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени, и приема запроса паузы от первого приемного устройства (111b, 111с, 115) связи посредством сетевого интерфейса (133, 233), при этом запрос паузы включает в себя идентификацию потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени и порядковый номер запроса паузы.

26. Передающее устройство (111а, 115) связи по п. 25, в котором процессор (131, 231) дополнительно выполнен с возможностью приостановления передачи потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени к первому приемному устройству связи при поддержании многостороннего сеанса конференц-связи в реальном времени в ответ на прием запроса паузы, и передачи сообщения подтверждения паузы к первому приемному устройству (111b) связи посредством сетевого интерфейса (133, 233) в ответ на прием запроса паузы, при этом сообщение подтверждения паузы включает в себя идентификацию потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени и порядковый номер запроса паузы.

27. Передающее устройство (111а, 115) связи по п. 26, в котором процессор (131, 231) дополнительно выполнен с возможностью приема запроса возобновления от первого приемного устройства связи посредством сетевого интерфейса (133, 233) после передачи сообщения подтверждения паузы, при этом запрос возобновления включает в себя идентификацию потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени и порядковый номер запроса возобновления, отличный от порядкового номера запроса паузы, возобновления передачи потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени и передачи сообщения подтверждения возобновления к первому приемному устройству связи посредством сетевого интерфейса (133, 233) в ответ на прием запроса возобновления, при этом сообщение подтверждения возобновления включает себя идентификацию потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени и порядковый номер запроса возобновления.

28. Передающее устройство связи по п. 25, в котором процессор дополнительно выполнен с возможностью приостановления передачи потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени к первому приемному устройству связи при поддержании передачи (511b) потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени ко второму приемному устройству (111с) связи в ответ на прием запроса паузы от первого приемного устройства связи.

29. Передающее устройство связи по п. 28, в котором запрос паузы является первым запросом паузы, а порядковый номер запроса паузы является порядковым номером первого запроса паузы, при этом процессор дополнительно выполнен с возможностью:
передачи первого сообщения подтверждения паузы к первому приемному устройству (111b) связи при продолжении передачи (511b) потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени ко второму приемному устройству (111с) связи в ответ на прием запроса паузы от первого приемного устройства связи, при этом сообщение подтверждения паузы включает в себя идентификацию потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени и порядковый номер запроса паузы,
приема второго запроса паузы от второго приемного устройства (111с) связи после передачи первого сообщения подтверждения паузы, при этом второй запрос паузы включает в себя идентификацию потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени и порядковый номер второго запроса паузы, и
приостановления передачи потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени к первому приемному устройству связи в ответ на прием второго запроса паузы от второго приемного устройства связи.

30. Передающее устройство связи по п. 29, в котором процессор дополнительно выполнен с возможностью:
передачи потока данных медиаконтента в реальном времени в ответ на прием потока данных медиаконтента в реальном времени от оконечного устройства (111а) связи, и
передачи третьего запроса паузы к оконечному устройству (111а) связи в ответ на прием первого и второго запросов паузы от первого и второго приемных устройств связи.

31. Передающее устройство связи по п. 30, в котором идентификация содержит первую идентификацию потока данных медиаконтента в реальном времени многостороннего сеанса конференц-связи в реальном времени, при этом процессор дополнительно выполнен с возможностью приема потока данных медиаконтента в реальном времени, включающего в себя вторую идентификацию, при этом третий запрос паузы включает в себя вторую идентификацию и порядковый номер третьего запроса паузы.

32. Передающее устройство связи по любому из пп. 25-31, в котором многосторонний сеанс конференц-связи в реальном времени содержит многосторонний сеанс видео-конференц-связи в реальном времени.