3

Is there an application-agnostic signaling protocol?

The use case is this. We have an open-source library for a multi-agent system that supports several protocols of the application layer of the OSI model. On the moment HTTP, XMPP, and ZeroMQ are supported for example. We would like to add high-bandwidth real-time streaming possibilities. It is logical to use RTP for that.

So, to recapitulate, we already have a connection to the other party that we can use for signalling. We want to negotiate only a new channel for data communication.

However, regarding the current standards, with respect to signaling all of them seem to be tied to their application. These current "standards" seem to be SIP, RTSP, and Jingle. They all seem to use RTP or SRTP on the application layer, and UDP on the transport layer. See e.g. XEP-0167.

The only thing we want to negotiate is another connection to that party that can be used for data transmission. In the Session Description Protocol all kind of stuff about media shows up, optional phone numbers, etc. If someone can point at a signaling protocol that is meant to be application-agnostic, that would be great!

Anne van Rossum
  • 3,091
  • 1
  • 35
  • 39
  • This is not meant as an advertisement, but this is the context: http://eve.almende.com/. If this is improper, feel free to delete this comment. I put it on purpose in a comment, so it is easy to do this. – Anne van Rossum Jan 23 '14 at 15:34
  • Note that I follow OSI terminology here. So, application-agnostic means agnostic towards the application layer in the OSI model. So agnostic with respect to the use of XMPP, HTTP, or ZeroMQ. – Anne van Rossum Jan 24 '14 at 09:44

3 Answers3

1

I'm a big fan of XMPP and I think you'll get what you need with it. However since you already have HTTP as well, I want to mention that PubSubHubbub can also be used for that! The current version of the protocol applies to any mime type that can be transported with HTTP so that would work.

In practice it's just a webhooks API which makes it easy to use and scale via load balancing.

Julien Genestoux
  • 31,046
  • 20
  • 66
  • 93
  • Thanks for the pointer. This means that if the user decides to use HTTP for the agents, she is limited to use PubSubHubbub, and when the user decides to use XMPP, she is limited to use XEP-0167. Apparently, there is no one interested in a signaling protocol that is agnostic towards HTTP, XMPP. Choosing one of these, the user has no subsequent liberty anymore in how to do the signaling... – Anne van Rossum Jan 24 '14 at 09:41
1

Is there an application-agnostic signaling protocol?

Yes there are lots and you already mention a number of them such as XMPP, SIP and RTSP. You could also add the brand new WebRTC protocol to the list.

We would like to add high-bandwidth real-time streaming possibilities. It is logical to use RTP for that.

Yes. RTP is lightweight and as its name suggest was designed for carrying real-time traffic. It's also popular so you will be able to find numerous existing implementations.

The only thing we want to negotiate is another connection to that party that can be used for data transmission. In the Session Description Protocol all kind of stuff about media shows up, optional phone numbers, etc. If someone can point at a signaling protocol that is meant to be application-agnostic, that would be great!

I'm not sure what you mean here. Session Description Protocol (SDP) is a standard way to describe the media capabilities of a device. It's commonly used in SIP and RTSP (and XMPP has something equivalent) however it's separate from those protocols and if you don't want to use it you are free to come up with your own way of describing media.

You may be getting overwhelmed by some of the SDP examples, and they can indeed get very complicated when there are multiple streams and codecs offered. However an SDP payload can also be very simple; below is an SDP example for an RTSP server offering a single MJPEG video stream.

v=0
o=- - 0 IN IP4 0.0.0.0
s=-
t=0 0
m=video 0 RTP/AVP 26
sipsorcery
  • 30,273
  • 24
  • 104
  • 155
  • I think your wording reveals that what SDP does is more than I would expect from it. Describe media is something on top of describing a session. However, I agree with you that I don't need to use SDP at all, and my basic concern is not about SDP. SDP comes namely not alone. It comes with a way how to communicate the SDP messages. This is the ```Offer/Answer``` model described in https://www.ietf.org/rfc/rfc3264.txt. The problem with this model is that it is tied to SDP. It should be up to the user how to describe the session. The Offer/Answer model is close to what I would expect though! – Anne van Rossum Jan 24 '14 at 09:36
0

If you just need a signalling protocol that is system and application agnostic, XMPP is the way to go.

  • XMPP does not define this. The extension XEP-0617 I mention does, this is Jingle. It defines things like ```session-initiate```, ```session-accept```, and ```session-terminate```. Take a look at it and you will agree that this does not look very application agnostic. The SDP is something that comes close, but it only describes(!) a session. It comes however most often with an Offer/Answer model. This is not the only choice! See e.g. http://blog.webrtc.is/2013/02/26/sdp-in-webrtc-who-cares/. However, at first sight it does not seem OpenPeer has this factored out as library or standard. – Anne van Rossum Jan 23 '14 at 15:31
  • well you could extend XMPP to suit your application. this means you can exchange custom xml data between entities. –  Jan 24 '14 at 16:50
  • By extending XMPP it would not become XMPP-agnostic. Custom XML data would serve as an alternative to SDP, not as an alternative to the Offer/Answer model in RFC3264. I admit, ```application-agnostic``` might be confusing, but it is just the OSI interpretation. XMPP is defined on the application layer, hence to be application agnostic through the use of XMPP does not make sense. – Anne van Rossum Jan 25 '14 at 12:15
  • ok, i see what you mean. suppose you wanted to work with WEBRTC, you could use XMPP for exchanging meta data and this would well with XMPP because it doesnt need to know anything about the data because it is only important for the WEBRTC application. so in short, you could use it as that engine to transfer meta data that XMPP agonistic and the other application/protocols do the rest. –  Jan 26 '14 at 19:20