СПОСОБ, УСТРОЙСТВО И СИСТЕМА ДЛЯ УВЕДОМЛЕНИЯ О СОБЫТИЯХ ПРОТОКОЛА ПОТОКОВОЙ ПЕРЕДАЧИ В РЕАЛЬНОМ ВРЕМЕНИ

Данная заявка притязает на приоритет заявки на патент Китая номер 200710130108.2, поданной в Патентное Ведомство Китая 20 июля 2007 года и озаглавленной "Method, Apparatus and System for Notifying Real-Time Streaming Protocol Events", которая полностью содержится в данном документе по ссылке.

Область техники, к которой относится изобретение

Настоящее изобретение относится к технологиям связи, и в частности к способу, устройству и системе для уведомления о событиях протокола потоковой передачи в реальном времени (RTSP).

Уровень техники

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

Как показано на фиг.1, процесс взаимодействия с передачей служебных RTSP-сигналов в предшествующем уровне техники включает в себя:

Этап 101. Клиент отправляет запрос DESCRIBE на сервер, запрашивающий описание представления из RTSP. Запрос переносит описание мультимедийного содержимого и идентификатор каждого мультимедийного потока. Например, описание мультимедийного содержимого включает в себя число мультимедийных потоков в мультимедийном содержимом и сведения по каждому мультимедийному потоку, такие как тип мультимедиа и тип кодирования/декодирования. Клиент - это RTSP-клиент, а сервер - это RTSP-сервер.

Этап 102. Сервер возвращает ответ об успешном выполнении (200 OK) в клиент и описывает запрошенную информацию.

Процесс получения посредством клиента информации описания ресурсов является полностью независимым процессом получения информации до того, как клиент запрашивает мультимедиа из сервера и выполняет операции управления для мультимедиа. Информация также может получаться посредством другого средства, такого как HTTP и электронная почта.

Этап 103. Клиент отправляет сообщение SETUP на сервер, запрашивающее установление мультимедийного потока. Сообщение переносит идентификатор мультимедийного потока, который указывает мультимедийный поток, который должен быть установлен, например мультимедийный аудиопоток или мультимедийный видеопоток в мультимедийном содержимом.

Этап 104. Сервер возвращает ответ об успешном выполнении (200 OK) в клиент, и установление мультимедийного потока завершается.

Этап 103 и этап 104 являются полным процессом установления мультимедийного потока. После завершения установления мультимедийного потока сервер не начинает воспроизведение мультимедиа или передачу мультимедийного потока. Чтобы начинать воспроизведение, клиент должен явно отправлять сообщение PLAY на сервер, запрашивающее воспроизведение мультимедиа. Мультимедийное содержимое, в общем, включает в себя несколько мультимедийных потоков. Чтобы воспроизводить несколько мультимедиа, клиент должен устанавливать несколько мультимедийных потоков с сервером. В RTSP каждый мультимедийный поток, требуемый клиентом, должен устанавливаться между клиентом и сервером по отдельности; т.е. процесс взаимодействия на этапе 103 или этапе 104 осуществляется многократно.

Этап 105. Клиент отправляет сообщение SETUP на сервер, запрашивающее установление мультимедийного потока. Сообщение переносит идентификатор мультимедийного потока, который указывает установленный мультимедийный поток, который должен быть воспроизведен, или переносит идентификатор представления, который указывает воспроизведение всех мультимедийных потоков в установленном пакете представления.

Этап 106. Сервер в ответ на этап 105 возвращает ответ об успешном выполнении (200 OK) в клиент, указывающий начало воспроизведения мультимедийного потока.

Мультимедийный поток передается через мультимедийный канал.

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

В приложении потоковой передачи, после того как клиент запрашивает сервер выполнять команду запроса, если нормальное или анормальное событие возникает, когда сервер выполняет команду, сервер должен уведомлять о событии или последнем состоянии выполнения запроса клиент в определенном режиме. В RTSP-приложении, тем не менее, сервер начинает воспроизведение запрошенного мультимедиа в клиенте после приема сообщения PLAY и одновременно возвращает ответ об успешном выполнении (200 OK) в клиент. Затем, если исключительное событие (например, исключение сервера в считывании мультимедийного файла) в процессе воспроизведения мультимедиа или неисключительное событие (например, в приложении потоковой передачи в реальном времени, пользователь запрашивает ускоренную перемотку вперед, но ход воспроизведения достиг программы текущего времени), которое должен быть обработано посредством клиента, возникает, поскольку предшествующий RTSP-протокол не предоставляет релевантного механизма или технологии, сервер не может уведомлять об исключении или событии клиента. Следовательно, состояние является несогласованным между клиентом и сервером, что создает неудобства в работе пользователя.

Сущность изобретения

Варианты осуществления настоящего изобретения предоставляют способ, устройство и систему для уведомления о RTSP-событии так, что о состоянии события можно уведомлять соответствующий сетевой объект при изменении состояния события.

Задачи вариантов осуществления настоящего изобретения достигаются через следующее техническое решение.

Способ для уведомления о RTSP-событии в варианте осуществления настоящего изобретения включает в себя:

мониторинг состояния события; и

отправку уведомления, служащего признаком изменения состояния события, в объект приема состояний событий при обнаружении изменения состояния события.

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

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

Устройство для уведомления о RTSP-событии в варианте осуществления настоящего изобретения включает в себя:

модуль мониторинга состояний событий, выполненный с возможностью подвергать мониторингу состояние события; и

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

Система для уведомления о RTSP-событии в варианте осуществления настоящего изобретения включает в себя:

устройство уведомлений о RTSP-событиях, выполненное с возможностью подвергать мониторингу состояние события и отправлять уведомление, служащее признаком изменения состояния события, при изменении состояния события; и

устройство приема уведомлений о RTSP-событиях, выполненное с возможностью принимать уведомление.

Техническое решение согласно настоящему изобретению подвергает мониторингу состояние события и уведомляет об изменении состояния события соответствующие сетевые объекты, тем самым обеспечивая совместимость состояния события между сетевыми объектами и повышая удобство работы пользователей.

Краткое описание чертежей

Фиг.1 является блок-схемой последовательности операций способа взаимодействий с передачей служебных RTSP-сигналов в предшествующем уровне техники;

Фиг.2 является блок-схемой последовательности операций способа для уведомления о RTSP-событии в первом варианте осуществления настоящего изобретения;

Фиг.3 является блок-схемой последовательности сигналов способа для уведомления о RTSP-событии во втором варианте осуществления настоящего изобретения;

Фиг.4 является блок-схемой последовательности сигналов способа для уведомления о RTSP-событии в третьем варианте осуществления настоящего изобретения;

Фиг.5 является блок-схемой последовательности сигналов способа для уведомления о RTSP-событии в четвертом варианте осуществления настоящего изобретения;

Фиг.6 показывает структуру устройства для уведомления о RTSP-событии в первом варианте осуществления настоящего изобретения;

Фиг.7 показывает структуру устройства для уведомления о RTSP-событии во втором варианте осуществления настоящего изобретения;

Фиг.8 показывает структуру системы для уведомления о RTSP-событии в первом варианте осуществления настоящего изобретения; и

Фиг.9 показывает структуру системы для уведомления о RTSP-событии во втором варианте осуществления настоящего изобретения.

Подробное описание изобретения

Чтобы делать техническое решение, цели и преимущества настоящего изобретения более понятными, далее подробно описываются варианты осуществления настоящего изобретения со ссылкой на прилагаемые чертежи.

Как показано на фиг.2, способ для уведомления о RTSP-событии в первом варианте осуществления настоящего изобретения включает в себя:

Этап 201. Объект мониторинга состояний событий подвергает мониторингу состояние события.

Объект мониторинга состояний событий может быть сервером или клиентом, который устанавливает мультимедийный канал, или сторонним сетевым объектом.

Мониторинг состояний событий может быть мониторингом возникновения условного события, например возникновения пользовательской операции или исключения, такого как сбой декодирования. Мониторинг состояний событий также может быть мониторингом изменения состояния непрерывного события, например состояния воспроизведения потокового мультимедиа или состояния сети, к примеру изменения с состояния воспроизведения на состояние ускоренной перемотки вперед. Таким образом, мониторинг состояния события включает в себя мониторинг возникновения условного события и мониторинг изменения состояния непрерывного события.

В процессе RTSP, после того как клиент запрашивает сервер выполнять команду запроса, если нормальное или анормальное событие возникает, когда сервер выполняет команду, сервер должен уведомлять о событии или последнем состоянии выполнения запроса клиент и, следовательно, сервер должен подвергать мониторингу состояние события; аналогично, после того как сервер запрашивает клиент выполнять команду запроса, если нормальное или анормальное событие возникает, когда клиент выполняет команду, клиент должен уведомлять о событии или последнем состоянии выполнения запроса сервер и, следовательно, клиент должен подвергать мониторингу состояние события.

Состояние события может подвергаться мониторингу активно или пассивно. При активном мониторинге события, которые должны подвергаться мониторингу, и сетевые объекты для приема информации об изменении состояния события могут задаваться заранее. События могут подвергаться мониторингу по умолчанию. Например, если клиент запрашивает воспроизводить потоковое мультимедиа, сервер, безусловно, подвергает мониторингу состояние воспроизведения потокового мультимедиа. При пассивном мониторинге мониторинг выполняется после того, как запрос на мониторинг состояния события принят от сетевого объекта. Объект может быть любым сетевым объектом, кроме объекта, который подвергает мониторингу состояние события.

Этап 202. Объект мониторинга состояний событий отправляет уведомление, служащее признаком изменения состояния события, в объект приема состояний событий, если изменение состояния события обнаружено.

Объект приема состояний событий варьируется в зависимости от объекта мониторинга состояний событий. Например, если объект мониторинга состояний событий - это сервер, объект приема состояний событий, в общем, - это клиент, но при этом возможно то, что объект приема состояний событий - это другое сетевое устройство.

В частности, поскольку предшествующий RTSP не допускает уведомление о событии, а именно не допускает отправку уведомления, служащего признаком изменения состояния события, предшествующий RTSP должен быть дополнен. Способ для дополнения RTSP варьируется в зависимости от типа события.

Уведомление, служащее признаком изменения состояния события, меняется в зависимости от подвергаемого мониторингу состояния события. Если мониторинг нацелен на то, чтобы проверять, возникает ли событие, уведомление может включать в себя информацию о возникновении события. Если мониторинг нацелен на то, чтобы проверять, изменяется ли состояние события, уведомление может включать в себя, но не только, информацию об измененном состоянии события. Уведомление, служащее признаком изменения состояния события, предназначено для того, чтобы уведомлять о возникновении условного события или изменении состояния непрерывного события объект приема состояний событий (например, изменении с состояния воспроизведения на состояние ускоренной перемотки вперед). При уведомлении об изменении состояния непрерывного события уведомление может включать в себя состояние после изменения и состояние до изменения.

Если состояние события подвергается мониторингу активно, объект, который подвергает мониторингу состояние события, определяет объекты для приема уведомления, служащего признаком изменения состояния события. Если состояние события подвергается мониторингу пассивно, и объекты для приема уведомления, служащего признаком изменения состояния события, заранее заданы, объект, который подвергает мониторингу состояние события, отправляет уведомление в заранее заданные объекты; или если объекты для приема уведомления не заданы заранее, объект, который подвергает мониторингу состояние события, определяет объекты для приема уведомления, служащего признаком изменения состояния события.

Очевидно, что техническое решение согласно настоящему изобретению подвергает мониторингу состояние события и уведомляет об изменении состояния события соответствующие сетевые объекты, тем самым обеспечивая совместимость состояния события между сетевыми объектами и повышая удобство работы пользователей.

Событие в данном документе может быть условным событием, совместимым с заранее заданными условиями, состоянием воспроизведения мультимедийных потоков или состоянием сети; условное событие, совместимое с заранее заданными условиями, является событием, которое приводит к несогласованности между состоянием события объекта мониторинга состояний событий и состоянием события объекта приема состояний событий, например информацией об операции пользователя. Условные события могут быть заданы заранее согласно конкретному случаю.

Как показано на фиг.3, способ для уведомления о RTSP-событии во втором варианте осуществления настоящего изобретения включает в себя:

Этап 301. Клиент отправляет сообщение SETUP на сервер, запрашивающее установление мультимедийного потока.

Этап 302. Сервер возвращает ответ об успешном выполнении (200 OK) в клиент, и мультимедийный поток устанавливается.

Этап 303. Клиент отправляет сообщение PLAY на сервер, запрашивающее ускоренное воспроизведение мультимедийного потока с прошедшего момента.

Этап 304. Сервер возвращает ответ об успешном выполнении (200 OK) в клиент и начинает ускоренное воспроизведение мультимедийного потока.

Мультимедийный поток передается через мультимедийный канал.

Сервер подвергает мониторингу состояние воспроизведения мультимедийного потока. Когда ход воспроизведения достигает определенной точки времени, сервер не может продолжать ускоренное воспроизведение. Например, если сервер воспроизводит программу в прямом эфире, сервер переходит в состояние нормального воспроизведения. Если сервер воспроизводит программу видео по запросу (VoD), когда ход ускоренного воспроизведения достигает текущего времени прямой передачи, воспроизведение, в общем, прекращается. Последующая обработка сервера зависит от программы, которая воспроизводится. Например, если воспроизводится программа в прямом эфире, когда событие, которое изменяет состояние воспроизведения, возникает в определенной точке времени, но клиент не знает, что ускоренная перемотка вперед сменилась на нормальное воспроизведение, клиент продолжает отображение состояния ускоренной перемотки вперед в интерфейсе, тем самым приводя к несогласованности состояния между сервером и клиентом. В это время сервер должен отправлять последнее состояние воспроизведения в клиент.

Этап 305. Сервер отправляет уведомление, служащее признаком изменения состояния события, в клиент. Уведомление может быть сообщением уведомления о событии. Таким образом, клиент уведомляется о последнем состоянии воспроизведения.

Предшествующий RTSP не предоставляет релевантного механизма уведомлений, и, следовательно, RTSP должен быть дополнен так, чтобы сервер мог отправлять уведомление о событии в клиент. Для вышеприведенного сценария приложения возможное сообщение уведомления является следующим:

NOTIFY rtsp://rtspclient.example.com RTSP/2.0

Content-Type (Тип содержимого): application/playback-status (приложение/состояние воспроизведения)

Content-Length (Длина содержимого):…

Allow (Разрешить): play, pause (воспроизведение, пауза)

playback-speed (скорость воспроизведения): 1

playback-scale (шкала воспроизведения): 1

playback-range = now- (диапазон воспроизведения = с текущего момента)

где "Allow: play, pause" означает, что текущие разрешенные операции - это воспроизведение и пауза; "playback-speed: 1" и "playback-scale: 1" указывают воспроизведение на нормальной скорости; а "playback-range=now-" означает нормальное воспроизведение с текущего времени.

Этап 306. После приема уведомления о событии клиент возвращает ответ об успешном выполнении (200 OK) на сервер.

В этом варианте осуществления сервер подвергает мониторингу состояние воспроизведения потокового мультимедиа. Когда состояние воспроизведения изменяется, сервер отправляет последнее состояние воспроизведения в клиент. Следовательно, состояние воспроизведения сохраняется согласованным между клиентом и сервером, и удобство работы пользователей повышается.

Как показано на фиг.4, способ для уведомления о RTSP-событии в третьем варианте осуществления настоящего изобретения включает в себя:

Этап 401. Клиент отправляет сообщение SETUP на сервер, запрашивающее установление мультимедийного потока.

Этап 402. Сервер возвращает ответ об успешном выполнении (200 OK) в клиент, и мультимедийный поток устанавливается.

Этап 403. Клиент отправляет сообщение PLAY на сервер, запрашивающее ускоренное воспроизведение мультимедийного потока с прошедшего момента.

Этап 404. Сервер возвращает ответ об успешном выполнении (200 OK) в клиент и начинает ускоренное воспроизведение мультимедийного потока.

Мультимедийный канал используется для передачи мультимедийного потока.

Этап 405. Третий объект отправляет запрос на сервер, запрашивающий то, чтобы подвергать мониторингу состояние события. Следовательно, сервер уведомляет о последнем состоянии воспроизведения клиент при изменении состояния воспроизведения.

Третий объект может быть любым объектом в сети, например устройством управления сетью и устройством мониторинга, которое подвергает мониторингу сеть. Третий объект также может быть клиентом или сервером.

Поскольку предшествующий RTSP не предоставляет соответствующего сообщения с запросом, RTSP должен быть дополнен. Сообщение с запросом на основе RTSP, предоставленное в варианте осуществления настоящего изобретения, следующее:

EVENTREQ rtsp://rtspserver.example.com RTSP/2.0

Event (Событие): play-status (состояние воспроизведения)

Event-Session (Сеанс события): "сеанс, который должен подвергаться мониторингу"

Notify-To (Кого уведомлять): rtsp://rtspclient.example.com

Notify-Session (Сеанс уведомления): "сеанс для уведомления о событии"

Content-Length: 0

Поля в сообщении описываются ниже:

Event: Это поле указывает событие, которое должно подвергаться мониторингу. Если сообщение не включает в себя это поле, приемное устройство сообщения определяет события, которые должны подвергаться мониторингу, или отклоняет запрос по событию.

Event-Session: Это поле указывает RTSP-сеанс, в котором должно подвергаться мониторингу событие. Если сообщение не включает в себя поле заголовка "Event-Session", по умолчанию, событие в сеансе, соответствующем запросу, должно подвергаться мониторингу, или приемное устройство сообщения определяет сеансы, которые должны подвергаться мониторингу. Например, когда поле "EVENTREQ" включает в себя поле заголовка "Session (Сеанс)", сеанс, который заключает в себе само сообщение EVENTREQ, должен подвергаться мониторингу, или все сеансы должны подвергаться мониторингу.

Notify-To: Это поле указывает объект, который должен уведомляться о событии. Если сообщение не включает в себя это поле заголовка, приемное устройство сообщения может отклонять запрос или определять объект для приема уведомления согласно заранее заданной локальной политике или сохраненному конфигурационному файлу. Например, уведомление о событии отправляется в отправляющее устройство сообщения EVENTREQ, или уведомление о событии отправляется в равноправный объект сеанса, указываемый посредством поля "Notify-Session".

Notify-Session: Это поле указывает сеанс, в котором должно отправляться уведомление о событии. Если сообщение не переносит это поле заголовка, приемное устройство сообщения определяет сеанс, в котором или за пределами которого должно отправляться уведомление о событии.

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

Этап 406. После приема сообщения запроса сервер возвращает ответ об успешном выполнении (200 OK) в третий объект.

Когда ход ускоренного воспроизведения достигает определенной точки времени, сервер не может продолжать ускоренное воспроизведение и обнаруживает изменение состояния воспроизведения.

Этап 407. Сервер отправляет уведомление в клиент. Уведомление указывает изменение состояния воспроизведения и последнее состояние воспроизведения.

Этап 408. Клиент возвращает ответ об успешном выполнении (200 OK) на сервер.

В этом варианте осуществления, после того как RTSP-сеанс установлен между клиентом и сервером, третий объект запрашивает сервер подвергать мониторингу состояние воспроизведения. Следовательно, когда сервер обнаруживает изменение состояния воспроизведения, сервер отправляет уведомление, служащее признаком изменения состояния воспроизведения, в клиент, тем самым сохраняя состояние воспроизведения между сервером и клиентом и повышая удобство работы пользователей; дополнительно, третий объект запрашивает мониторинг состояния воспроизведения, тем самым повышая гибкость сети.

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

Как показано на фиг.5, способ для уведомления о RTSP-событии в четвертом варианте осуществления настоящего изобретения включает в себя:

Этап 501. Клиент отправляет сообщение SETUP на сервер, запрашивающее установление мультимедийного потока.

Этап 502. Сервер возвращает ответ об успешном выполнении (200 OK) в клиент, и мультимедийный поток устанавливается.

Этап 503. Клиент отправляет сообщение PLAY на сервер, запрашивающее воспроизведение мультимедийного потока.

Этап 504. Сервер возвращает ответ об успешном выполнении (200 OK) в клиент и начинает ускоренное воспроизведение мультимедийного потока. Ответ об успешном выполнении (200 OK) переносит сообщение с запросом, запрашивающее то, чтобы подвергать мониторингу пользовательскую операцию.

Этап 505. После приема сообщения запроса клиент отправляет уведомление на сервер, указывающее текущую операцию пользователя.

Этап 506. После приема информации о текущей операции пользователя сервер возвращает ответ об успешном выполнении (200 OK) в клиент.

Клиент подвергает мониторингу пользовательскую операцию. После того как пользовательская операция изменяется в определенной точке времени, клиент обнаруживает изменение.

Этап 507. При обнаружении изменения пользовательской операции клиент отправляет уведомление на сервер, указывающее информацию об измененной пользовательской операции.

Этап 508. После приема информации об измененной пользовательской операции сервер возвращает ответ об успешном выполнении (200 OK) в клиент.

В этом варианте осуществления сообщение с запросом переносится в ответе об успешном выполнении (200 OK); но на практике сообщение с запросом может быть отдельным сообщением с запросом или переноситься в другом сообщении, которым обмениваются между сервером и клиентом. В этом варианте осуществления сервер добавляет сообщение с запросом к сообщению, которым обмениваются в предшествующем уровне техники, чтобы запрашивать клиент подвергать мониторингу пользовательскую операцию. Следовательно, при изменении пользовательской операции, клиент отправляет информацию об измененной пользовательской операции на сервер, и состояние события сохраняется согласованным между сервером и клиентом.

На практике, после приема информации об измененной пользовательской операции, сервер выполняет операции согласно пользовательской операции. Например, если пользовательская операция - это ускоренное воспроизведение потокового мультимедиа, сервер изменяет воспроизведение потокового мультимедиа на ускоренное воспроизведение после приема информации об измененной пользовательской операции; если пользовательская операция - это пауза, сервер приостанавливает воспроизведение потокового мультимедиа, и в частности отправка потоковых данных приостанавливается.

Согласно способу уведомления о RTSP-событии устройство для уведомления о RTSP-событии предоставляется в первом варианте осуществления настоящего изобретения. Как показано на фиг.6, устройство включает в себя:

модуль 601 мониторинга состояний событий, выполненный с возможностью подвергать мониторингу состояние события; и

модуль 602 отправки сообщений, выполненный с возможностью отправлять уведомление, служащее признаком изменения состояния события, когда модуль 602 мониторинга состояний событий обнаруживает изменение состояния события.

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

Устройство для уведомления о RTSP-событии предоставляется во втором варианте осуществления настоящего изобретения. По сравнению с устройством в первом варианте осуществления устройство для уведомления о RTSP-событии во втором варианте осуществления дополнительно включает в себя модуль 700 приема сообщений. Как показано на фиг.7, устройство во втором варианте осуществления включает в себя:

модуль 700 приема сообщений, выполненный с возможностью принимать сообщение с запросом, которое запрашивает подвергать мониторингу состояние события;

модуль 701 мониторинга состояний событий, выполненный с возможностью подвергать мониторингу состояние события после того, как модуль 700 приема сообщений принимает сообщение с запросом; и

модуль 702 отправки сообщений, выполненный с возможностью отправлять уведомление, служащее признаком изменения состояния события, когда модуль 701 мониторинга состояний событий обнаруживает изменение состояния события.

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

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

Система для уведомления о RTSP-событии предоставляется в первом варианте осуществления настоящего изобретения. Как показано на фиг.8, система включает в себя:

устройство 801 уведомлений о RTSP-событиях, выполненное с возможностью: подвергать мониторингу состояние события и отправлять уведомление, служащее признаком изменения состояния события, при изменении состояния события, причем устройство уведомлений о RTSP-событиях может быть сервером или клиентом на практике; и

устройство 802 приема уведомлений о RTSP-событиях, выполненное с возможностью принимать уведомление.

В общем если устройство 801 уведомлений о RTSP-событиях - это сервер, то устройство 802 приема уведомлений о RTSP-событиях - это клиент; если устройство 801 уведомлений о RTSP-событиях - это клиент, то устройство 802 приема уведомлений о RTSP-событиях - это сервер. Однако также можно возможно то, что как устройство 801 уведомлений о RTSP-событиях, так и устройство 802 приема уведомлений о RTSP-событиях - это серверы, или как устройство 801 уведомлений о RTSP-событиях, так и устройство 802 приема уведомлений о RTSP-событиях - это клиенты.

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

Как показано на фиг.9, система для уведомления о RTSP-событии во втором варианте осуществления настоящего изобретения включает в себя:

устройство 900 запросов по мониторингу RTSP-событий, выполненное с возможностью отправлять сообщение с запросом, которое запрашивает подвергать мониторингу состояние события;

устройство 901 уведомлений о RTSP-событиях, выполненное с возможностью: подвергать мониторингу состояние события после приема сообщения запроса и отправлять уведомление, служащее признаком изменения состояния события, при изменении состояния события; и

устройство 902 приема уведомлений о RTSP-событиях, выполненное с возможностью принимать уведомление.

На практике устройство запросов по мониторингу RTSP-событий и устройство уведомлений о RTSP-событиях являются одним сетевым объектом или различными сетевыми объектами.

В этом варианте осуществления, после того как RTSP-сеанс установлен между устройством уведомлений о RTSP-событиях и устройством приема уведомлений о RTSP-событиях, устройство запросов по мониторингу RTSP-событий отправляет сообщение с запросом в устройство уведомлений о RTSP-событиях, запрашивающее то, чтобы подвергать мониторингу состояние события. Следовательно, при обнаружении изменения состояния события, устройство уведомлений о RTSP-событиях уведомляет об изменении состояния события устройство приема уведомлений о RTSP-событиях. Как результат, состояние события сохраняется согласованным между устройством уведомлений о RTSP-событиях и устройством приема уведомлений о RTSP-событиях, и удобство работы пользователей повышается. Дополнительно, устройство запросов по мониторингу RTSP-событий отправляет сообщение с запросом, которое запрашивает подвергать мониторингу состояние воспроизведения, тем самым повышая гибкость сети.

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

1. Объект мониторинга состояний событий подвергает мониторингу состояние события.

2. При обнаружении изменения состояния события объект мониторинга состояний событий отправляет уведомление, служащее признаком изменения состояния события, в объект приема состояний событий.

Носитель хранения данных может быть постоянным запоминающим устройством (ROM), магнитным диском или компакт-диском (CD).

Выше поясняются способ, устройство и система для уведомления о RTSP-событии согласно настоящему изобретению. Хотя изобретение описывается в нескольких примерных вариантах осуществления, изобретение неограничено этими вариантами осуществления. Очевидно, что специалисты в данной области техники могут выполнять модификации и вносить изменения в изобретение без отступления от сущности и объема изобретения. Изобретение имеет намерение охватывать модификации и изменения при условии, что они попадают в область защиты, заданную посредством прилагаемой формулы изобретения или ее эквивалентов.