Существует ли протокол сигнализации, не зависящий от приложения?

Существует ли независимый от приложения протокол сигнализации?

Вариант использования таков. У нас есть библиотека с открытым исходным кодом для мультиагентной системы, поддерживающая несколько протоколов прикладного уровня модели OSI. Например, на данный момент поддерживаются HTTP, XMPP и ZeroMQ. Мы хотели бы добавить возможности потоковой передачи в реальном времени с высокой пропускной способностью. Логично использовать для этого RTP.

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

Однако, что касается действующих стандартов, то в отношении сигнализации все они, похоже, привязаны к своему применению. Этими текущими «стандартами» являются SIP, RTSP и Jingle. Похоже, что все они используют RTP или SRTP на прикладном уровне и UDP на транспортном уровне. См., например. XEP-0167.

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


session sip signaling xmpp osi
person Anne van Rossum    schedule 23.01.2014    source источник
comment
Это не реклама, а контекст: eve.almende.com. Если это неприемлемо, не стесняйтесь удалить этот комментарий. Я специально написал это в комментарии, так что это легко сделать.   -  person Anne van Rossum    schedule 23.01.2014
comment
Обратите внимание, что здесь я следую терминологии OSI. Таким образом, независимый от приложения означает независимый от прикладного уровня в модели OSI. Такой агностик в отношении использования XMPP, HTTP или ZeroMQ.   -  person Anne van Rossum    schedule 24.01.2014

Ответы (3)


arrow_upward
1
arrow_downward

Я большой поклонник XMPP, и я думаю, что вы получите то, что вам нужно. Однако, поскольку у вас уже есть HTTP, я хочу отметить, что PubSubHubbub можно использовать и для этого! Текущая версия протокола применяется к любому MIME-типу, который можно передавать по HTTP, чтобы он работал.

На практике это просто API веб-перехватчиков, который упрощает использование и масштабирование за счет балансировки нагрузки.

person Julien Genestoux    schedule 23.01.2014
comment
Спасибо за указатель. Это означает, что если пользователь решит использовать HTTP для агентов, он будет ограничен использованием PubSubHubbub, а когда пользователь решит использовать XMPP, он будет ограничен использованием XEP-0167. Судя по всему, никому не интересен сигнальный протокол, агностический по отношению к HTTP, XMPP. Выбирая один из них, пользователь больше не имеет никакой свободы в том, как делать сигнализацию... - person Anne van Rossum; 24.01.2014

arrow_upward
1
arrow_downward

Существует ли протокол сигнализации, не зависящий от приложения?

Да, их много, и вы уже упомянули некоторые из них, такие как XMPP, SIP и RTSP. Вы также можете добавить в список совершенно новый протокол WebRTC.

Мы хотели бы добавить возможности потоковой передачи в реальном времени с высокой пропускной способностью. Логично использовать для этого RTP.

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

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

Я не уверен, что вы имеете в виду здесь. Протокол описания сеанса (SDP) — это стандартный способ описания мультимедийных возможностей устройства. Он обычно используется в SIP и RTSP (и XMPP имеет что-то эквивалентное), однако он отделен от этих протоколов, и если вы не хотите его использовать, вы можете придумать свой собственный способ описания мультимедиа.

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

v=0
o=- - 0 IN IP4 0.0.0.0
s=-
t=0 0
m=video 0 RTP/AVP 26
person sipsorcery    schedule 23.01.2014
comment
Я думаю, ваша формулировка показывает, что SDP делает больше, чем я ожидал от нее. Описание медиа — это нечто большее, чем описание сеанса. Однако я согласен с вами в том, что мне вообще не нужно использовать SDP, и моя основная забота не о SDP. SDP приходит именно не один. Он поставляется со способом передачи сообщений SDP. Это модель Offer/Answer, описанная в ietf.org/rfc/rfc3264.txt. Проблема этой модели в том, что она привязана к SDP. Пользователь должен решать, как описывать сеанс. Однако модель «предложение/ответ» близка к тому, что я ожидал! - person Anne van Rossum; 24.01.2014

arrow_upward
0
arrow_downward

Если вам просто нужен сигнальный протокол, который не зависит от системы и приложения, XMPP — это то, что вам нужно.

person Community    schedule 23.01.2014
comment
XMPP не определяет это. Расширение XEP-0617, о котором я упоминал, это Jingle. Он определяет такие вещи, как session-initiate, session-accept и session-terminate. Взгляните на это, и вы согласитесь, что это не выглядит очень независимым от приложения. SDP является чем-то близким, но он описывает только (!) сеанс. Однако чаще всего это происходит с моделью «предложение / ответ». Это не единственный выбор! См., например. blog.webrtc.is/2013/02/26 /sdp-in-webrtc-who-care. Однако на первый взгляд кажется, что OpenPeer не учитывает это как библиотеку или стандарт. - person Anne van Rossum; 23.01.2014
comment
хорошо, вы можете расширить XMPP в соответствии с вашим приложением. это означает, что вы можете обмениваться пользовательскими данными xml между объектами. - person ; 24.01.2014
comment
Расширяя XMPP, он не станет независимым от XMPP. Пользовательские данные XML будут служить альтернативой SDP, а не альтернативой модели «предложение/ответ» в RFC3264. Я признаю, что application-agnostic может сбивать с толку, но это всего лишь интерпретация OSI. XMPP определяется на прикладном уровне, поэтому быть независимым от приложений за счет использования XMPP не имеет смысла. - person Anne van Rossum; 25.01.2014
comment
хорошо, я понимаю, что вы имеете в виду. предположим, что вы хотите работать с WEBRTC, вы можете использовать XMPP для обмена метаданными, и это будет хорошо с XMPP, потому что ему не нужно ничего знать о данных, потому что это важно только для приложения WEBRTC. Короче говоря, вы можете использовать его в качестве этого механизма для передачи метаданных, которые агонист XMPP, а другие приложения/протоколы делают все остальное. - person ; 26.01.2014